Re: BRT copying feature

(Forgot to include screen grabs)

Re: BRT copying feature

On 11/7/24 07:31, Ronald Klop wrote: Another option is this. The installer /usr/sbin/bsdinstall uses a script called /usr/libexec/ bsdinstall/zfsboot. Zfsboot defines this: # # Default options to use when creating zroot pool # : ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O compress=lz4 -O atime=off} Yo

[screen-devel] [bug #66160] 5.0.0 outputs escape sequences where 4.9.1 uses carriage returns

: None Planned Release: None Work Required: None ___ Follow-up Comments: --- Date: Sun 01 Sep 2024 09:47:29 AM PDT By: Craig Leres I routinely use the xterm "log to file&

Re: FreeBSD 14.x localhost source address

On 7/2/24 01:40, Ronald Klop wrote: Could it be that this mail thread also applies to your situation? https://lists.freebsd.org/archives/freebsd-current/2024-June/006047.html It has a follow-up about a fix in https://l

Re: FreeBSD 14.x localhost source address

On 7/1/24 15:53, Michael Proto wrote: What netmask are you using for 127.0.0.2? I'd treat it as I would an IP alias (only on localhost) with a /32 netmask, should keep it isolated. Just tried it myself on a test box and iperf works as expected, using 127.0.0.1 as the source when connecting. I

Re: BIND 9.19.24 not listening to rndc port (953)

On 7/1/24 10:17, Bakul Shah wrote: On Jul 1, 2024, at 9:18 AM, Craig Leres wrote: On 6/30/24 04:46, sth...@nethelp.no wrote: Short description: Fresh install of bind9-devel-9.19.24_1 doesn't listen to localhost port 953, with the result that rndc doesn't work. Problem is 100% re

Re: BIND 9.19.24 not listening to rndc port (953)

On 6/30/24 04:46, sth...@nethelp.no wrote: Short description: Fresh install of bind9-devel-9.19.24_1 doesn't listen to localhost port 953, with the result that rndc doesn't work. Problem is 100% reproducible. bind-tools-9.18.27_1 with 14.1-RELEASE-p1 suffers from this as well.

FreeBSD 14.x localhost source address

When I upgraded ~10 systems from 13.3 to 14.1 recently, 90%+ of my breakage was due to the localhost source address changing from 127.0.0.1 to 127.0.0.2. This was on two of my systems. My lo0 config is standard: mote 20 % ifconfig lo0 lo0: flags=1008049 metric 0 mtu 16384

Re: ZFS space allocation

On 6/14/24 22:18, Gordon Bergling wrote: I just upgraded a 13.3-RELEASE system to 14.1-RELEASE, which has two ZFS pools, z for ZFS-on-root and storage for asorted stuff. While a 'pkg upgrade' fails, I discovered something strange with the free disk space. [...] In general I don't have any cl

Re: How to configure a U24XL adc/dac for digital input

On 3/1/24 13:50, Craig Leres wrote: I've been using an ESI U24XL for about 8 years to simultaneously record and play back S/PDIF (using in-house C programs under FreeBSD). Recently recording stopped working (playback is still fine) and I believe the cause is that the device has so

How to configure a U24XL adc/dac for digital input

I've been using an ESI U24XL for about 8 years to simultaneously record and play back S/PDIF (using in-house C programs under FreeBSD). Recently recording stopped working (playback is still fine) and I believe the cause is that the device has somehow switched to using its analog input. I insta

Re: net/libpfctl: needs to be updated for 13.3

On 2/26/24 17:04, Craig Leres wrote: While building a bunch of ports under 13.3-RC1 I find that libpfctl does not (build). I freely admit I do not understand how this port works; I started to create a PR but I don't have the first idea on how the distfile is generated. Meanwhile 1136

Re: net/libpfctl: needs to be updated for 13.3

On 2/26/2024 5:07 PM, Edward Sanford Sutton, III wrote: While building a bunch of ports under 13.3-RC1 I find that libpfctl does not (build). I freely admit I do not understand how this port works; I started to create a PR but I don't have the first idea on how the distfile is generated. `mak

net/libpfctl: needs to be updated for 13.3

While building a bunch of ports under 13.3-RC1 I find that libpfctl does not (build). I freely admit I do not understand how this port works; I started to create a PR but I don't have the first idea on how the distfile is generated. Meanwhile 1136 other ports built for me without issue.

Re: nvme controller reset failures on recent -CURRENT

I had issues with a nvme drive in an intel nuc. When I asked freebsd-hackers, overheating was the first guess: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-May/052783.html I blew the dust out of the fan assembly and changed the bios fan settings to be more aggressive and the syste

13.3-BETA1 vs. ports

I installed a test system (via the amd64 memstick image), copied my port options to /var/db/ports, my poudriere make.conf options to /etc/make.conf and tried to build a few hundred ports. This stalled out trying to build textproc/man2html because of a missing dependency: ===> man2html-3.

Re: Proposal: Disable compression of newsyslog by default

On 12/23/23 06:52, Konstantin Belousov wrote: This is strange change at best. I have no opinion about the disabling of compression of the rotated logs by default, but we already have knobs to do that. Adding a knob that disables (or enables) other knobs to work is weird. I totally agree. This

Re: nvme timeout issues with hardware and bhyve vm's

On 12/7/23 15:09, Tomoaki AOKI wrote: If I myself encounter this kind of problem ON BARE METAL HARDWARE, I would usually suspect *Overheating caused hang of NVMe controller or PCI bridge on SSD, or This would also be my first guess. Five years ago I had an nmve in an intel nuc that would so

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

On 10/7/23 11:07, Viktor Dukhovni wrote: On Sat, Oct 07, 2023 at 01:38:10PM -0400, Viktor Dukhovni wrote: So, it looks like "unbound" is not fond of empty NODATA replies with no SOA. It is I think reasonable to ask Microsoft to address the "no SOA" NODATA response. This was addressed upstrea

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

On 10/7/23 18:37, Noel Butler via dns-operations wrote: I don't use unbound, but interface is strange, usually its 127.0.0.1 for localhost, but maybe you have a reason for using that so likely nothing to do with it. The host itself is a nameserver and I'm told it's bad practice for an authori

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

On 10/6/23 18:37, John Levine wrote: I run the FreeBSD package of unbound and it has no trouble even when I specifically set an edns0 option. What else might be odd about your setup? One thing I see is that my host is dual-stack, I see now that I get SERVFAIL or a timeout if I ask for the

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

On 10/6/23 11:34, Viktor Dukhovni wrote: While the nameservers behind that domain have various unfortunate limitations, they're minimally usable, and you should be able to resolve the A/ records of the MX hosts with no issue. What specific problems is your unbound running into. I also use "

[dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

I routinely find messages stuck in my sendmail queue with the error, "Deferred: Name server: outlook-com.olc.protection.outlook.com". This system uses unbound (with DNSSEC validation enabled -- perhaps not relevant) and the only way I was able to get one message I really needed to deliver was t

Re: FreeBSD Port: chromium-98.0.4758.102 Error build on 13-stable

On 2/21/22 09:05, Alex V. Petrov wrote: In file included from ../../third_party/nasm/asm/assemble.c:178: ../../third_party/nasm/include/compiler.h:249:21: error: static declaration of 'mempcpy' follows non-static declaration static inline void *mempcpy(void *dst, const void *src, size_t n)  

Re: FreeBSD Port: chromium-98.0.4758.102 Error build on 13-stable

On 2/21/22 09:05, Alex V. Petrov wrote: In file included from ../../third_party/nasm/asm/assemble.c:178: ../../third_party/nasm/include/compiler.h:249:21: error: static declaration of 'mempcpy' follows non-static declaration static inline void *mempcpy(void *dst, const void *src, size_t n)  

[Zeek-Dev] Re: netmap 2.0.0 vs. zeek 4.0.0

On 3/16/21 1:10 PM, Christian Kreibich wrote: Hey Craig, It's been a while! :) Yep! Thanks for the help. On 3/16/21 10:54 AM, Craig Leres wrote: Due to the way FreeBSD packages are built at this point zeek is installed but in /wrkdirs/usr/ports/security/zeek/work/stage/usr/local, not

[Zeek-Dev] netmap 2.0.0 vs. zeek 4.0.0

I'm trying to update the FreeBSD zeek port for 4.0.0 and am having trouble getting netmap 2.0.0 to build which seems to assume that zeek will be installed in /usr/local when it is built: [ 40%] Building CXX object CMakeFiles/Zeek-Netmap.freebsd-amd64.dir/src/Plugin.cc.o In file include

svn commit: r364502 - in stable/12: contrib/netbsd-tests/usr.bin/grep usr.bin/grep

Author: leres (ports committer) Date: Sun Aug 23 17:46:10 2020 New Revision: 364502 URL: https://svnweb.freebsd.org/changeset/base/364502 Log: MFC r363381: Fix some regressions with the zgrep(1) wrapper. PR: 247126 Modified: stable/12/contrib/netbsd-tests/usr.bin/grep/t_grep.

svn commit: r363381 - in head: contrib/netbsd-tests/usr.bin/grep usr.bin/grep

Author: leres (ports committer) Date: Mon Jul 20 23:57:53 2020 New Revision: 363381 URL: https://svnweb.freebsd.org/changeset/base/363381 Log: Fix some regressions with the zgrep(1) wrapper. - Handle whitespace with long flags that take arguments: echo 'foo bar' > test z

svn commit: r363381 - in head: contrib/netbsd-tests/usr.bin/grep usr.bin/grep

Author: leres (ports committer) Date: Mon Jul 20 23:57:53 2020 New Revision: 363381 URL: https://svnweb.freebsd.org/changeset/base/363381 Log: Fix some regressions with the zgrep(1) wrapper. - Handle whitespace with long flags that take arguments: echo 'foo bar' > test z

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

bird 2.0: show only IPv4 or IPv6 routes from birdc

We've been using bird 1.6.8 to advertise nullzero routes from a FreeBSD box to our routers for awhile. (We use quagga to the same for IPv4.) We're in the process of upgrading to 2.0.7 and will use bird for IPv4 and IPv6. I'm so far unable to come up with good ways of dumping only IPv4 or IPv4

Re: [dns-operations] GPS time glitch last night

On 2020-01-02 03:15, Mukund Sivaraman wrote: We use the Garmin GPS 18x LVC model in NMEA mode, and they run current firmware. There appear to be two hardware versions of the Garmin GPS 18, most of the units I have refuse to upgrade past 3.30, some newer versions have 4.40. Cr

Re: svn commit: r507836 - in head/devel/llvm80: . files

On 2019-08-05 07:19, Brooks Davis wrote: I've committed Craig's change for now since it works and doesn't change the DEPEND list (and thus doesn't require a PORTREVISION bump). It looks like this could be relaxed further, but that is hard to test since problem tend to occur in partially updated

Django versions

I'm working on a port for mailman 3. I want to use django 2.1 because that's what I'm using on the systems I'm currently running mailman 2 on you can't really run different version of django on the same system). But it turns out a lot of ports have RUN_DEPENDS for www/py-django111. One possibl

[Bro-Dev] Building bro 2.6 with static broker/caf libraries

I've read up on cmake variable scope but I can't figure out how to build bro with static libraries. The bro-bundled caf already has CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to turn it on when building caf as part of a bro build. For example I'd like is to optionally (i.e

[Bro-Dev] Building Bro with openssl 1.1.1

The FreeBSD security/bro port does not build under the latest FreeBSD 12.0 alpha due to compile errors in the X509 module. I verified that this is due to openssl 1.1.1 by building on 11.2-RELEASE with the openssl111 port. I've attached an example failing build log. Is openssl 1.1.1 support on

Small mistake in the flavors section of the porters handbook

Example 7.2 on this page has a mistake: https://www.freebsd.org/doc/en/books/porters-handbook/flavors-using.html The conditional needs to use == instead of = or else you get: make: "/usr/ports/devel/subversion/Makefile" line 53: warning: String comparison operator should be either == or !

Re: Could we please add a CUPS option for www/chromium?

On 03/10/18 09:17, Carlos J. Puga Medina wrote: Or one can build their own copy of Chromium with printing support turned off, and that will get rid of the CUPS dependency. Could you please help with that? Once I figured out the only way to disable cups was to disable printing I couldn't find t

Could we please add a CUPS option for www/chromium?

I recently started using the chromium and although I didn't figured it out until today this it was what recently broke my ability to print with lpr. The problem is that chromium has a hard dependency on cups and cups installs its version of lpr in /usr/local/bin. I'm content using the base sys

Re: Parallel build problems with dovecot 2.2.32

On 10/10/17 06:24, Timo Sirainen wrote: Looks like this was already fixed in master, as part of some other changes: https://github.com/dovecot/core/commit/b200bc3875fa06d42c8619865cc306c3297fcacc We're planning to get v2.3 releases out in not-many-more-months, so may have to wait for it.

Parallel build problems with dovecot 2.2.32

I use dovecot under FreeBSD 10.3 and build using poudriere. My build server has 12 cores builds typically happen in parallel and I find software that is not parallel make friendly will fail once every month or so. Attached is a build log from this afternoon that failed because doveadm-util.o

svn commit: r323602 - head/share/misc

uot;Yen-Ming Lee\nle...@freebsd.org\n2002/08/14"] ler [label="Larry Rosenman\n...@freebsd.org\n2017/01/09"] +leres [label="Craig Leres\nle...@freebsd.org\n2017/10/10"] lev [label="Lev Serebryakov\n...@freebsd.org\n2003/06/17"] lifanov [label="Nikolai Lifanov\nlifa...@f

svn commit: r323602 - head/share/misc

uot;Yen-Ming Lee\nle...@freebsd.org\n2002/08/14"] ler [label="Larry Rosenman\n...@freebsd.org\n2017/01/09"] +leres [label="Craig Leres\nle...@freebsd.org\n2017/10/10"] lev [label="Lev Serebryakov\n...@freebsd.org\n2003/06/17"] lifanov [label="Nikolai Lifanov\nlifa...@f

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: 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 ra

Re: [Bro-Dev] Broker & CAF includes

This all makes sense to me; what you describe as the current situation (two packages defining the same data structure) seems broken to me. And I see caf/config.hpp defines CAF_VERSION so you're set if broker now or in the future requires a minimum version of caf. Craig ___

Re: [Bro-Dev] current_time() vs network_time()

On 11/18/2015 10:58 AM, Aashish Sharma wrote: > So, I am trying to have bro send me report/alerts at specific timeslots. > > Given current_time is the wall-clock time, I am relying on current_time() > function to get time and then, my code is : if (hh:mm:ss == desired time), > run a report. M

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: >

Re: [dns-operations] bug in Apache handling of real FQDNs

On 06/08/15 08:09, TOURNAT Guillaume wrote: > Yes, mod_rewrite is already loaded. If it was not, "apache2ctl configtest" > would have complained. Hum... It looks like the problem is that the rewrite rule only works for http, not https. Here are some working examples: http://ee.lbl.gov./ h

Re: [dns-operations] bug in Apache handling of real FQDNs

On 06/08/15 01:32, TOURNAT Guillaume wrote: > Here are apache rewrite rules that redirect to the url without the trailing > dot: > > RewriteEngine On > > # Don't switch protocols > RewriteCond %{HTTPS} =on > RewriteRule ^(.+)$ - [env=myproto:https] > RewriteCond %{HTTPS} !=on

Re: [dns-operations] bug in Apache handling of real FQDNs

On 6/6/2015 10:56 AM, Fred Morris wrote: > By "real" I mean "really fully qualified", as in "ending in a dot". > > Try this: > > https://apache.org. > > Take note of the final dot. (Try https://apache.org./foo if you like.) In any > case what you'll see is: > > 1) You get asked to accept an

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 _

[avrdude-dev] [bug #43898] atmega644p remains stopped after JTAG transaction

URL: Summary: atmega644p remains stopped after JTAG transaction Project: AVR Downloader/UploaDEr Submitted by: leres Submitted on: Sun 28 Dec 2014 11:42:04 AM PST Category: None

Re: svn commit: r354587 - in head: ftp/proftpd ftp/proftpd-mod_geoip ftp/proftpd/files security/proftpd-mod_clamav

On 08/06/14 12:55, Marcus von Appen wrote: > We're planning for a python-tools port, which will install the tools and > scripts properly on a per version (python27, python32, python33, ...) basis. > The port will take some more days (work on it probably won't happen before the > USES=python convers

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 shoul

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 "Appro

Re: [Bro-Dev] Fwd: [REL - 10amd64-default][security/bro] Failed for bro-2.2 in build

On 12/03/13 08:09, Robin Sommer wrote: > Which clang version is this? I've tried it with a recent version of > the clang 3.4 release branch, and that works fine for me. > > But based on the error message, I'm attaching a patch; does that help > by any chance? I submitted a PR with your patch and

Re: [Bro-Dev] Fwd: [REL - 10amd64-default][security/bro] Failed for bro-2.2 in build

On 12/03/13 08:09, Robin Sommer wrote: > Which clang version is this? I've tried it with a recent version of > the clang 3.4 release branch, and that works fine for me. I dunno, I've asked them them to include the clang version before; I'll ask again. > But based on the error message, I'm attachi

Re: [REL - 10amd64-default][security/bro] Failed for bro-2.2 in build

On 11/30/13 00:08, pkg-fall...@freebsd.org wrote: > ---Begin Environment--- > OSVERSION=1000500 > UNAME_v=FreeBSD 10.0-BETA1 r256420 > UNAME_r=10.0-BETA1 > BLOCKSIZE=K > MAIL=/var/mail/root > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > STATUS=1 > MASTERM

[Bro-Dev] Fwd: [REL - 10amd64-default][security/bro] Failed for bro-2.2 in build

Sounds like FreeBSD has upgraded to a newer version of clang and it doesn't like to build /src/logging/writers/SQLite.cc anymore. It's the last few lines of the attached message that shows the problem, is there an obvious fix? Thanks! Craig --- Begin Message --- You are receiving

Re: [REL - 10i386-default][security/bro] Failed for bro-2.1_3 in build

On 10/24/13 03:28, pkg-fall...@freebsd.org wrote: > Maintainer: le...@ee.lbl.gov > Last committer: tabtho...@freebsd.org > Ident: $FreeBSD: head/security/bro/Makefile 330864 2013-10-19 > 13:24:59Z tabthorpe $ > Log URL: > http://beefy1.isc.freebsd.org/bulk/10i386-default/2013-

Re: [REL - head-amd64-default][security/bro] Failed for bro-2.1_1 in build

On 10/18/13 05:48, pkg-fall...@freebsd.org wrote: > Log URL: > http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2013-10-17_23h06m42s/logs/bro-2.1_1.log Could you please retest with bro-2.1_2 (committed on Wednesday)? Craig _

Re: [REL - head-i386-default][security/bro] Failed for bro-2.1_1 in build

On 10/18/13 02:26, pkg-fall...@freebsd.org wrote: > Log URL: > http://beefy1.isc.freebsd.org/bulk/head-i386-default/2013-10-17_19h54m49s/logs/bro-2.1_1.log Could you please retest with bro-2.1_2 (committed on Wednesday)? Craig __

Re: [REL - 10i386-default][security/bro] Failed for bro-2.1_1 in build

On 10/17/13 09:00, pkg-fall...@freebsd.org wrote: > Log URL: > http://beefy1.isc.freebsd.org/bulk/10i386-default/2013-10-17_04h52m04s/logs/bro-2.1_1.log Could you please retest with bro-2.1_2 (committed yesterday)? Craig ___ free

Re: [REL - 10amd64-default][security/bro] Failed for bro-2.1_1 in build

On 10/17/13 12:10, pkg-fall...@freebsd.org wrote: > Log URL: > http://beefy2.isc.freebsd.org/bulk/10amd64-default/2013-10-17_07h20m58s/logs/bro-2.1_1.log Could you please retest with bro-2.1_2 (committed yesterday)? Craig ___ fre

Re: [REL - head-amd64-default][security/bro] Failed for bro-2.1_1 in build

On 10/03/13 04:49, pkg-fall...@freebsd.org wrote: > You are receiving this mail as a port that you maintain > is failing to build on the FreeBSD package build server. > Please investigate the failure and submit a PR to fix > build. [ 56%] Building CXX object src/CMakeFiles/bro.dir/Expr.cc.o > cd /

[Bro-Dev] bro 2.1 vs clang

There's a FreeBSD ports bug report that says clang 3.3 doesn't like bro 2.1: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182127 /home/ports/security/bro/work/bro-2.1/src/Expr.cc:2392:9: error: reference to 'is_assignable' is ambiguous if ( ! is_assignable(op->Type()) ) ^

kern/182217: [PATCH] dev/ppc/ppc_pci.c: add SIIG/Oxford OXPCIe952 pci-e parallel-port

>Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Sep 18 23:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Craig Leres >Release:FreeBSD 9.1-RELEASE amd64 >Organization

"ndp -s" doesn't join the solicited node multicast group (9.1-RELEASE)

I've been using openvpn to tunnel IPv4 into work for a few years now. By using addresses from the same subnet as the endpoint at at work and "arp -s" I can work from home and access services as if I am on the subnet at work. I recently tried to add IPv6 to my openvpn setup. It wasn't difficult to

Re: bin/165384: [PATCH] rtadvd(8): Add option to suppress RA prefix info

The following reply was made to PR bin/165384; it has been noted by GNATS. From: Craig Leres To: bug-follo...@freebsd.org, le...@ee.lbl.gov Cc: Subject: Re: bin/165384: [PATCH] rtadvd(8): Add option to suppress RA prefix info Date: Tue, 29 Jan 2013 00:26:55 -0800 It appears this issue was

[PATCH] Add stdlib.h to examples

When attempting to compile libftdi on FreeBSD, the lack of stdlib.h in the example programs prevents them from compiling: simple.c: In function 'main': simple.c:18: error: 'EXIT_FAILURE' undeclared (first use in this function) simple.c:18: error: (Each undeclared identifier is r

bin/165384: [PATCH] Add option to suppress RA prefix info

>Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Feb 22 04:20:11 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Craig Leres >Release:FreeBSD 8.2-RELEASE amd64 >Organization: Lawrence Berkeley Nationa

Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE

> The fact you have this happening on multiple systems is uncomfortable. > It makes me uncomfortable because we use Supermicro hardware > exclusively. The kernel I building is somewhat unique; I suspect 8.2-RELEASE worked ok for older supermicro motherboards and 8-RELENG works for newer motherboa

Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE

I have a lot of supermicro motherboards and the newest ones have igb chipsets; they've been quite a headache with respect to FreeBSD 8. I'm running 8.2-RELEASE but have upgraded parts of my kernel to 8-RELENG (as of a few months ago). Some of them work ok while others panic on bootup. Upgrading to

Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954

The following reply was made to PR kern/147583; it has been noted by GNATS. From: Craig Leres To: John Baldwin Cc: bug-follo...@freebsd.org Subject: Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954 Date: Mon, 09 May 2011 17:48:34 -0700 On 05

Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954

The following reply was made to PR kern/147583; it has been noted by GNATS. From: Craig Leres To: John Baldwin Cc: bug-follo...@freebsd.org Subject: Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954 Date: Mon, 02 May 2011 16:51:58 -0700 This is

Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954

The following reply was made to PR kern/147583; it has been noted by GNATS. From: Craig Leres To: John Baldwin Cc: bug-follo...@freebsd.org Subject: Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954 Date: Mon, 02 May 2011 10:43:30 -0700 This is

Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954

The following reply was made to PR kern/147583; it has been noted by GNATS. From: Craig Leres To: John Baldwin Cc: bug-follo...@freebsd.org Subject: Re: kern/147583: [puc] [patch] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954 Date: Fri, 29 Apr 2011 13:53:05 -0700 This is

bin/154988: [PATCH] lib/libfetch/ftp.c add LIST feature

>Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Feb 23 22:20:05 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Craig Leres >Release:FreeBSD 8.2-RELEASE amd64 >Organization: Lawrence Berkeley National La

xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE

I recently upgraded my desktop from 7.2-RELEASE to 8.1-RELEASE and noticed that I no longer get biff messages in my "console" xterm window. I traced this to: xterm: cannot open console: Operation not permitted and see that the TIOCCONS code in tty_generic_ioctl() is checking for PRIV_TTY_CONS

bin/153667: [PATCH] libexec/comsat/comsat.c: gratuitous newline

>Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 04 00:20:06 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Craig Leres >Release:FreeBSD 8.1-RELEASE amd64 >Organization: Lawrence Berkeley National La

Re: cvs commit: ports/net/beacon Makefile ports/net/beacon/files beacon.in patch-Makefile.in patch-common-beacon.patch patch-libbeacon-Makefile.in

Philip M. Gollucci wrote: > Can you please test this change paying special attention to dougb's > additional comment below. > > http://people.freebsd.org/~pgollucci/beacon.in.txt I tested it on my box and had to make a couple of tweaks before it worked. Quotes were missing and buser and procname w

kern/147583: [PATCH] sys/dev/puc/pucdata.c: incorrect clock value for Oxford OX16PCI954

eywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jun 06 21:20:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Craig Leres >Release:FreeBSD 7.2-RELEASE amd64 >Organization: Lawrence Berkeley Nationa

[Mjpeg-users] 1.9.0rc2: jpeg2yuv loops forever when reading filenames from stdin

If you do something like: echo 000136_0.jpg | jpeg2yuv -f 25 -I p > /dev/null jpeg2yuv loops forever processing the last filename seen on stdin. I see 1.9.0rc3 is out and it appears to also have this issue. Patch attached. Craig =