Re: ports/devel/xtensa-esp32-elf version
On 2020-06-03 02:42, Peter Jeremy wrote: > I notice that the Espressif ESP32 toolchain port is currently at version > 1.22.0.g20171219 (which uses gcc 5.2.0), though the current stable version > of esp-idf (v4.0.1) requires toolchain esp-2019r2 and gcc-8.2.0. Do you > have any plans to update the port? I've been in contact with Gerald Pfeifer (the gcc ports maintainer) about upgrading the port as it is the last consumer of gcc7. I worked up a version of the port that uses the esp-2020r1 release of https://github.com/espressif/crosstool-NG but I had not planned on upgrading to this until the project I wrote the port for has upgraded to esp-idf v4.X (this is in progress). I will create a version for esp-2020r2 (which only came out about a week ago) in the near future. The two options I see are (a) I can provide you a copy of what I current have working or (b) if there's enough interest I could create a new devel/xtensa-esp32-elf-devel port using esp-2020r1 or esp-2020r2. > [I tried sending this to your FreeBSD address but it bounced because of > an SPF failure: You forward your email but the FreeBSD mail servers > aren't a valid source of rulingia.com mail] (I received both copies, maybe the bounce was from the ports@freebsd mailing list?) Craig ___ 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: poudriere: devel/llvm39: runaway_process
On 01/18/17 13:49, Craig Leres wrote: My poudriere build servers have been unable to build devel/llvm39 ever since some ports changed from llvm37 (January 17th?) The error is runaway_process and this happens during the package phase. It looks like pkg-static spins for one hour at which point poudriere gives up on it. To close the loop on this the issue turned out to be "CFLAGS=-g" in make.conf. Removing -g caused llvm39 to build in a reasonable amount of time. Craig ___ 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"
poudriere: devel/llvm39: runaway_process
My poudriere build servers have been unable to build devel/llvm39 ever since some ports changed from llvm37 (January 17th?) The error is runaway_process and this happens during the package phase. It looks like pkg-static spins for one hour at which point poudriere gives up on it. Yesterday I raised max_execution_time for package on one build server to 2 hours which did not help. My three servers are all at 10.3-RELEASE-p16 and I'm attempting to build packages for the same version. I'm still able to build llvm37 ok. Since it takes ~2 hours for the failure to occur I'm hoping for ideas on how to diagnose this. Craig ___ 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: Trouble after Cacti upgrade
Today, seeing the security advisory, I upgraded cacti to 0.8.8f on a 9.3/amd64 box. Then I connected to the web interface and I was offered the upgrade procedure; after that I get a blank web page. The upgrade did not complete, so Cacti is not available. In httpd-error log, I see: PHP Warning: include(): Failed opening '0_8_8f_to_0_8_8f.php' for inclusion (include_path='.:/usr/local/share/pear') in /usr/local/ share/cacti/install/index.php on line 471, referer: https://x.x/cacti/install/index.php In fact I don't see this file neither installed, neither in work/cacti-0.8.8f. Any hint? I was upgrading from cacti-0.8.8d and saw this as well. I bet you also have: PHP Fatal error: Call to undefined function upgrade_to_0_8_8f() in /usr/local/share/cacti/install/index.php on line 472 I added a symlink from 0_8_8f_to_0_8_8f.php to 0_8_8e_to_0_8_8f.php and was able to complete the upgrade. Craig ___ 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: [Bug 197107] [MAINTAINER] security/bro, security/broccoli: Update to 2.3.2 (includes two CVE fixes)
I posted a PR to update security/bro and security/broccoli last week: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197107 But nothing has really happened since then. I'm not entirely sure I understand how maintainer updates work these days; what am I doing wrong? Craig ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
How do maintainer updates work with bugzilla?
At the end of last month I used send-pr to post a maintainer-update to security/bro and security/broccoli. I see now I should have used the new bugzilla web interface. That day I received a request an email asking for maintainer approval. I immediately replied to that but the status is still Approval Needed. What am I doing wrong? Craig ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How do maintainer updates work with bugzilla?
On 08/03/14 12:18, Matthew Seaman wrote: I take it you mean PR 192105 ? (Sorry, I meant to include a link to the PR.) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192105 By virtue of sending a PR into the system a le...@ee.lbl.gov account will have been created in Bugzilla. You should be able to use the 'Forgot Password' link to set a password on that account, then log in and add a flag to the attached diff to say 'maintainer approved'. I was able to access my bugzilla account back when I created the PR. I assume setting a '+' flag on the attachment means I approve it. Once that's done it should get triaged and if you're lucky, set to 'Patch Ready' in which case someone with a commit bit can go ahead and commit the update. Triaged is something that an admin does manually? You'll help that to happen if you can supply a link to Redports or the output from 'poudriere testport' or similar showing that your update passes some sanity checks. (It's not mandatory for PR submitters to supply this sort of testing output, but it pretty much is mandatory for all patches to be tested in this way before they are committed. So if you do it yourself, you can make it quicker and easier for any committer to proceed.) Redports looks pretty cool; I just updated the PR with build logs. I appreciate your help. Craig ___ 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
