Expect to see something about this on this year's Community Survey and the
Core Team will do something with this information.
Cloud has been an increasingly important workload for FreeBSD users. Or at
least, our community is moving a fair number of workloads to virtualized
metal, and running on t
To be clear, this is a known issue that needs attention: it is not a
benchmarking setup problem. Network throughput has a similar problem and
needs similar attention. Cloud is not a fringe server workload. -sc
On Fri, Feb 5, 2021 at 3:00 PM Jin Guojun[VFF] wrote:
> On 2021-02-05 12:45, Gunth
The 23rd. Sorry for the confusion - there were some scheduling conflicts
that caused this to be pushed back. Cheers. -sc
On Wed, Sep 16, 2020 at 1:05 AM Jakob Alvermark wrote:
> On 2020-09-15 16:12, FreeBSD Core Team Secretary wrote:
> > Based on the continuity of our last CORE Office Hours T
Author: seanc (ports committer)
Date: Fri Jul 12 18:50:46 2019
New Revision: 349952
URL: https://svnweb.freebsd.org/changeset/base/349952
Log:
usr.sbin/bhyve: close backend file descriptor during tap init error
Coverity CID: 1402953
Reviewed by: scottl, markj, aleksandr.fedorov -at- itgl
Author: seanc (ports committer)
Date: Fri Jul 12 18:50:46 2019
New Revision: 349952
URL: https://svnweb.freebsd.org/changeset/base/349952
Log:
usr.sbin/bhyve: close backend file descriptor during tap init error
Coverity CID: 1402953
Reviewed by: scottl, markj, aleksandr.fedorov -at- itgl
Author: seanc (ports committer)
Date: Fri Jul 12 18:38:18 2019
New Revision: 349949
URL: https://svnweb.freebsd.org/changeset/base/349949
Log:
usr.sbin/bhyveload: don't leak an fd if a device can't be opened
Coverity CID: 1194167
Approved by: markj, jhb
Differential Revision:ht
Author: seanc (ports committer)
Date: Fri Jul 12 18:38:18 2019
New Revision: 349949
URL: https://svnweb.freebsd.org/changeset/base/349949
Log:
usr.sbin/bhyveload: don't leak an fd if a device can't be opened
Coverity CID: 1194167
Approved by: markj, jhb
Differential Revision:ht
Author: seanc (ports committer)
Date: Fri Jul 12 18:33:58 2019
New Revision: 349947
URL: https://svnweb.freebsd.org/changeset/base/349947
Log:
usr.sbin/bhyve: only unassign a pt device after obtaining bus/slot/func
Coverity CID: 1194302, 1194303, 1194304
Approved by: jhb, markj
Differe
Author: seanc (ports committer)
Date: Fri Jul 12 18:33:58 2019
New Revision: 349947
URL: https://svnweb.freebsd.org/changeset/base/349947
Log:
usr.sbin/bhyve: only unassign a pt device after obtaining bus/slot/func
Coverity CID: 1194302, 1194303, 1194304
Approved by: jhb, markj
Differe
Author: seanc (ports committer)
Date: Fri Jul 12 18:20:56 2019
New Revision: 349946
URL: https://svnweb.freebsd.org/changeset/base/349946
Log:
usr.sbin/bhyve: free resources when erroring out of pci_vtcon_sock_add()
Coverity CID: 1362880
Approved by: markj, jhb
Differential Revision:
Author: seanc (ports committer)
Date: Fri Jul 12 18:20:56 2019
New Revision: 349946
URL: https://svnweb.freebsd.org/changeset/base/349946
Log:
usr.sbin/bhyve: free resources when erroring out of pci_vtcon_sock_add()
Coverity CID: 1362880
Approved by: markj, jhb
Differential Revision:
Author: seanc (ports committer)
Date: Fri Jul 12 18:17:35 2019
New Revision: 349945
URL: https://svnweb.freebsd.org/changeset/base/349945
Log:
usr.sbin/bhyve: prevent use-after-free in virtio scsi request handling
Coverity CID: 1393377
Approved by: araujo, jhb
Differential Revision:
Author: seanc (ports committer)
Date: Fri Jul 12 18:17:35 2019
New Revision: 349945
URL: https://svnweb.freebsd.org/changeset/base/349945
Log:
usr.sbin/bhyve: prevent use-after-free in virtio scsi request handling
Coverity CID: 1393377
Approved by: araujo, jhb
Differential Revision:
Author: seanc (ports committer)
Date: Fri Jul 12 18:13:58 2019
New Revision: 349944
URL: https://svnweb.freebsd.org/changeset/base/349944
Log:
usr.sbin/bhyve: don't leak a FD if the device is not a tty
Coverity CID: 1194193
Approved by: markj, jhb
Differential Revision:https://
Author: seanc (ports committer)
Date: Fri Jul 12 18:13:58 2019
New Revision: 349944
URL: https://svnweb.freebsd.org/changeset/base/349944
Log:
usr.sbin/bhyve: don't leak a FD if the device is not a tty
Coverity CID: 1194193
Approved by: markj, jhb
Differential Revision:https://
Author: seanc (ports committer)
Date: Fri Jul 12 05:53:13 2019
New Revision: 349937
URL: https://svnweb.freebsd.org/changeset/base/349937
Log:
usr.sbin/bhyve: unconditionally initialize the NVMe completion status
Follow-up work to improve the handling of unsupported/invalid opcodes
is bei
Author: seanc (ports committer)
Date: Fri Jul 12 05:53:13 2019
New Revision: 349937
URL: https://svnweb.freebsd.org/changeset/base/349937
Log:
usr.sbin/bhyve: unconditionally initialize the NVMe completion status
Follow-up work to improve the handling of unsupported/invalid opcodes
is bei
Author: seanc (ports committer)
Date: Fri Jul 12 05:19:37 2019
New Revision: 349935
URL: https://svnweb.freebsd.org/changeset/base/349935
Log:
usr.sbin/bhyve: free resources when erroring out of pci_vtnet_init()
Coverity CID: 1402978
Approved by: vmaffione
Reviewed by: jhb
Different
Author: seanc (ports committer)
Date: Fri Jul 12 05:19:37 2019
New Revision: 349935
URL: https://svnweb.freebsd.org/changeset/base/349935
Log:
usr.sbin/bhyve: free resources when erroring out of pci_vtnet_init()
Coverity CID: 1402978
Approved by: vmaffione
Reviewed by: jhb
Different
Author: seanc (ports committer)
Date: Thu Jul 11 23:54:50 2019
New Revision: 349925
URL: https://svnweb.freebsd.org/changeset/base/349925
Log:
usr.sbin/bhyve: send an initialized value to wake up blocking kqueue
This is a no-op initialization because nothing reads this value. "This
wasn'
Author: seanc (ports committer)
Date: Thu Jul 11 23:54:50 2019
New Revision: 349925
URL: https://svnweb.freebsd.org/changeset/base/349925
Log:
usr.sbin/bhyve: send an initialized value to wake up blocking kqueue
This is a no-op initialization because nothing reads this value. "This
wasn'
Author: seanc (ports committer)
Date: Thu Jul 11 19:51:33 2019
New Revision: 349919
URL: https://svnweb.freebsd.org/changeset/base/349919
Log:
usr.sbin/bhyve: commit miss from r349918
Submitted by: markj
Approved by: markj
Differential Revision:https://reviews.freebsd.org/D2091
Author: seanc (ports committer)
Date: Thu Jul 11 19:51:33 2019
New Revision: 349919
URL: https://svnweb.freebsd.org/changeset/base/349919
Log:
usr.sbin/bhyve: commit miss from r349918
Submitted by: markj
Approved by: markj
Differential Revision:https://reviews.freebsd.org/D2091
Author: seanc (ports committer)
Date: Thu Jul 11 19:41:14 2019
New Revision: 349918
URL: https://svnweb.freebsd.org/changeset/base/349918
Log:
usr.sbin/bhyve: free leaked memory during option parsing
Also update to use strsep(3) instead of strtok(3).
Most of this commit inadvertently e
Author: seanc (ports committer)
Date: Thu Jul 11 19:41:14 2019
New Revision: 349918
URL: https://svnweb.freebsd.org/changeset/base/349918
Log:
usr.sbin/bhyve: free leaked memory during option parsing
Also update to use strsep(3) instead of strtok(3).
Most of this commit inadvertently e
Author: seanc (ports committer)
Date: Thu Jul 11 19:26:35 2019
New Revision: 349915
URL: https://svnweb.freebsd.org/changeset/base/349915
Log:
usr.sbin/bhyve: initialize return value in xhci device interrupt handler
Coverity CID: 1357340
Approved by: scottl, markj
Differential Revision
Author: seanc (ports committer)
Date: Thu Jul 11 19:26:35 2019
New Revision: 349915
URL: https://svnweb.freebsd.org/changeset/base/349915
Log:
usr.sbin/bhyve: initialize return value in xhci device interrupt handler
Coverity CID: 1357340
Approved by: scottl, markj
Differential Revision
Author: seanc (ports committer)
Date: Thu Jul 11 19:07:45 2019
New Revision: 349914
URL: https://svnweb.freebsd.org/changeset/base/349914
Log:
usr.sbin/bhyve: free resources if there is an initialization error in rfb
Coverity CID: 1357335
Approved by: markj, jhb
Differential Revision:
Author: seanc (ports committer)
Date: Thu Jul 11 19:07:45 2019
New Revision: 349914
URL: https://svnweb.freebsd.org/changeset/base/349914
Log:
usr.sbin/bhyve: free resources if there is an initialization error in rfb
Coverity CID: 1357335
Approved by: markj, jhb
Differential Revision:
Author: seanc (ports committer)
Date: Wed Jul 3 17:24:24 2019
New Revision: 349656
URL: https://svnweb.freebsd.org/changeset/base/349656
Log:
bhyve/audio: don't leak resources on failed initialization.
Coverity CID: 1402793
Approved by: markj, jhb, bhyve
Differential Revision:
Author: seanc (ports committer)
Date: Wed Jul 3 17:24:24 2019
New Revision: 349656
URL: https://svnweb.freebsd.org/changeset/base/349656
Log:
bhyve/audio: don't leak resources on failed initialization.
Coverity CID: 1402793
Approved by: markj, jhb, bhyve
Differential Revision:
Author: seanc (ports committer)
Date: Fri Jun 28 23:40:58 2019
New Revision: 349528
URL: https://svnweb.freebsd.org/changeset/base/349528
Log:
Temporary suspension.
Approved by: core
Modified:
svnadmin/conf/access
Modified: svnadmin/conf/access
=
Author: seanc (ports committer)
Date: Fri May 24 20:36:07 2019
New Revision: 348252
URL: https://svnweb.freebsd.org/changeset/base/348252
Log:
Release rgrimes@ from mentorship.
Discussed with: bde@, phk@
Approved by: core@
Modified:
svnadmin/conf/mentors
Modified: svnadmin/conf/mento
ic CAs
in base (or change a default in the installer to install a port), modernizing
docs or other maintenance activities that improve our security posture is a +1
activity from core@'s perspective.
-sc (on behalf of core@)
--
Sean Chittenden
signature.asc
Description: PGP signature
ic CAs
in base (or change a default in the installer to install a port), modernizing
docs or other maintenance activities that improve our security posture is a +1
activity from core@'s perspective.
-sc (on behalf of core@)
--
Sean Chittenden
signature.asc
Description: PGP signature
ed down to ~8K. We have to read the
entire record in before we can modify half of the page. I suspect eliding
prefaulting FPWs will always be a performance loss for nearly all hardware.
* If there is sufficient interest in these experiences, contact me offline (or
via PostgreSQL Slack) and I
Author: seanc (ports committer)
Date: Thu Jul 5 15:40:14 2018
New Revision: 335987
URL: https://svnweb.freebsd.org/changeset/base/335987
Log:
Update with the members of the 10th core team, core.x.
Modified:
head/share/misc/organization.dot
Modified: head/share/misc/organization.dot
Author: seanc (ports committer)
Date: Thu Jul 5 15:40:14 2018
New Revision: 335987
URL: https://svnweb.freebsd.org/changeset/base/335987
Log:
Update with the members of the 10th core team, core.x.
Modified:
head/share/misc/organization.dot
Modified: head/share/misc/organization.dot
eid...@freebsd.org\n2011/11/06"]
+seanc [label="Sean Chittenden\nse...@freebsd.org\n2002/08/15"]
sem [label="Sergey Matveychuk\n...@freebsd.org\n2004/07/07"]
sergei [label="Sergei Kolobov\nser...@freebsd.org\n2003/10/21"]
shaun [label="Shaun Amott\nsh...@freebsd
eid...@freebsd.org\n2011/11/06"]
+seanc [label="Sean Chittenden\nse...@freebsd.org\n2002/08/15"]
sem [label="Sergey Matveychuk\n...@freebsd.org\n2004/07/07"]
sergei [label="Sergei Kolobov\nser...@freebsd.org\n2003/10/21"]
shaun [label="Shaun Amott\nsh...@freebsd
Author: seanc (ports committer)
Date: Thu Apr 26 17:13:58 2018
New Revision: 333020
URL: https://svnweb.freebsd.org/changeset/base/333020
Log:
Add myself back to the ranks of being mentored
Approved by: swills (mentor)
Modified:
head/share/misc/committers-ports.dot
Modified: head/share
Author: seanc (ports committer)
Date: Thu Apr 26 17:13:58 2018
New Revision: 333020
URL: https://svnweb.freebsd.org/changeset/base/333020
Log:
Add myself back to the ranks of being mentored
Approved by: swills (mentor)
Modified:
head/share/misc/committers-ports.dot
Modified: head/share
Background: https://github.com/joyent/pg_prefaulter#background
Cheers. -sc
--
Sean Chittenden
signature.asc
Description: PGP signature
GUC as suggested. What's your take on the
attached patch?
-sc
--
Sean Chittenden
se...@joyent.com
On Oct 4, 2017, 10:56 AM -0700, Andres Freund , wrote:
> Hi,
>
> On 2017-10-04 10:47:06 -0700, Sean Chittenden wrote:
> > Hello. We identified the same problem. Sam Gwydir
w if there are any questions. -sc
--
Sean Chittenden
se...@joyent.com
w if there are any questions. -sc
--
Sean Chittenden
se...@joyent.com
ism.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I think you mean, "when will Apple update its DTrace to be more compatible with
FreeBSD?" The version of DTrace that ships with macOS is out of date and yes,
we would love it if it were more up to date in macOS. :( -sc
-sc
--
Sean Chittenden
On Apr 12, 2017, 22:19 -0700, Jan Bei
I think you mean, "when will Apple update its DTrace to be more compatible with
FreeBSD?" The version of DTrace that ships with macOS is out of date and yes,
we would love it if it were more up to date in macOS. :( -sc
-sc
--
Sean Chittenden
On Apr 12, 2017, 22:19 -0700, Jan Bei
regions.
At this point in time this could be replaced with kqueue(2) EVFILT_PROC, but no
one has done that yet.
-sc
--
Sean Chittenden
s...@chittenden.org
> On Jun 22, 2016, at 07:26 , Maxim Sobolev wrote:
>
> Konstantin,
>
> Not if you do sem_unlink() immediately, AFAIK. And
regions.
At this point in time this could be replaced with kqueue(2) EVFILT_PROC, but no
one has done that yet.
-sc
--
Sean Chittenden
s...@chittenden.org
> On Jun 22, 2016, at 07:26 , Maxim Sobolev wrote:
>
> Konstantin,
>
> Not if you do sem_unlink() immediately, AFAIK. And
ve and provided there aren't any
unaddressable concerns by the rest of the team, I expect we will adopt
iocage.
My quick $0.02. -sc
--
Sean Chittenden
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
direction before.
>
> If you meant to propose using *unnamed* POSIX semaphores, that might be
> a reasonable change, but it would still need some supporting evidence.
https://lists.freebsd.org/pipermail/svn-src-stable-10/2014-October/003515.html
-sc
--
Sean Chittenden
s...@chittende
54:53.854165855 +0300
> +++ src/template/freebsd2014-05-26 23:55:12.307880900 +0300
> @@ -3,3 +3,4 @@
> case $host_cpu in
>alpha*) CFLAGS="-O";; # alpha has problems with -O2
> esac
> +USE_NAMED_POSIX_SEMAPHORES=1
-sc
--
Sean Chittenden
s...@chittenden
/kib/pgsql_perf.pdf
[2]
http://www.freebsd.org/cgi/man.cgi?query=mmap&apropos=0&sektion=0&manpath=FreeBSD+10.0-stable&arch=default&format=html
[3]
http://www.freebsd.org/cgi/man.cgi?query=madvise&sektion=2&apropos=0&manpath=FreeBSD+10.0-stable
--
Sean Chittende
s between
> Pg 9.2 and 9.3 on UFS2 (RAID10 + Dell H710p (mfi) raid controller with
> 1GB NVRAM)
When the working set fits in RAM (OS + PG), there isn't a performance
difference between 9.2 and 9.3.
This is a good data point. I will try and reproduce this workload and will run
the per
and have the results available:
http://people.freebsd.org/~seanc/pg9.3-fbsd10-profiling/
There are some investigations that are ongoing as a result of these findings.
The dfly methodology was observed when generating these results. Stay tuned. -sc
--
Sean Chittenden
s...@chittenden.org
>
>
attachment-0001.pdf
>>>
>>
>>
>> Do you have the ability to test with FreeBSD 8.x and 9.x to see if this is
>> regression?
>>
>> Also you don't mention the FS used in each case, so I'm wondering if you
>
).
I made a cursory pass over the code and found one other instance where write
status wasn’t being checked and also included that.
-sc
pg_dump_check_write.patch
Description: Binary data
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers
so I thought
I’d prod and ask. Thanks in advance. -sc
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
oned above re: breaking out of the loop, there
should probably be a ssl_renegotiation_min tunable so that the client
can't renegotiate too fast.
The default ssl_ciphers in the examples should also be updated as well
(e.g. we still allow SSLv2):
ssl_ciphers =
'ECDHE-RSA-AES128-SHA256:AES128-GC
w releases... and while we're at it, can we prefer PFS ciphers?
> I have still to find where the actual problems are happening in
> unreliable networks ...
I'm guessing you're blocking on /dev/random on some systems and that's
the source of unreliability/timeouts.
> [1] c
at one.
Sounds good to me and is clear enough that it would unblock me w/o having to
resort to the source tree. -sc
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tly what the
problem was. Attached is an improved error message:
> "ERROR: XX000: no schemas in search_path are available for CREATE EXTENSION"
-sc
src-backend-commands-extension.c.patch
Description: Binary data
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers ma
didn't dig in to. Upon learning the WAL
files were removed as a temporary solution to the space problem, I opted to
dump, re-initdb, and load the data, which worked without any errors or warnings
being reported.
I've saved the data if there are pointed questions about their conte
run in to this before and in some scripts I run a CHECKPOINT before
sending a SIGINT, which reduces the size of the CHECKPOINT, but doesn't
necessarily eliminate it all of the time. In fact, I'm not sure it happens 100%
of the time either, but today I was bit by this shutdown/startup dela
recommending that a cluster not be created at
> a mount point; it should be created in a directory underneath the
> mount point.
Giving filesystem advice is a large topic that I'm sure is covered someplace in
the handbook. A general warning isn't a bad idea, however. *
re of any special directories exposed by
>> filesystems that aren't dot directories so this seems like a relatively
>> futureproof solution, too.
> lost+found
It's been a long time since I've seen that directory. Patch updated. -sc
--
Sean Chittenden
s...@chittenden.org
ll be set to "english".
>
> initdb: directory "/tmp/pginit-test" exists but is not empty
> If you want to create a new database system, either remove or empty
> the directory "/tmp/pginit-test" or run initdb
> with an argument other than "/tmp/pgi
ent and useful, and the 0/8 network seems to
have been defined for exactly this purpose. I admit the address range isn't in
wide use atm, but I don't see a reason for it to not be.
The fix Andre made appears to be correct, and IMO, should be merge
ou be more specific? I read "other addresses within 0.0.0.0/8 may be used
to refer to specified hosts on this network" as an indication that use of 0/8
is intended to be supported.
> Regardless, why are you trying to do something that is unsupported by pretty
> much every vendor/oper
it doesn't work on
> most systems (Linux, network appliance vendors included) so this working
> *should* be a bug, IMO.
Where does it say that it shouldn't be used? Which RFC & §? There are plenty of
RFCs and I haven't exhaustively read things, so I reserve the righ
up a test methodology. Using INT8 internally was too
convenient at the time.
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ite/data center local
There were a host of convenience things that came for free with this, including
easy to identify what traffic should be on the segment, etc. DNS would be at
0.42.53.{10,20}, etc. Answering questions like "this data center's DNS server
is at 172.29.167.4&qu
CMP.
?? Any thoughts as to why? It doesn't appear that the current behavior abides
by RFC5735.
-sc
--
Sean Chittenden
s...@chittenden.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsub
fully
(supposedly).
START WAL LOCATION: 9F/3620 (file 0001009F0036)
CHECKPOINT LOCATION: 9F/37E9D6D8
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2012-10-06 17:48:10 UTC
LABEL: repmgr_standby_clone_1349545601
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ites safe, but that slaves are
still making assumptions about full page WAL entries being the MTU during some
corner cases. My observations lead me to believe that replication works fine
with full_page_writes disabled until the master cleans up a zero-filled or
damaged page.
For the arch
arios that come from a system running
out of FDs (though seek(2)'ing consuming an FD seems odd), it's more that it's
still possible for a master DB's VACUUM to clean up a bogus or partial page
write, and have the slave crash when the WAL entry is shipped over.
Are there any
alid pages
Oct 6 17:26:44 db02 postgres[19614]: [14-2] @ 19614 0: CONTEXT: xlog redo
vacuum: rel 1663/16387/20196; blk 2944, lastBlockVacuumed 2403
Oct 6 17:26:44 db02 postgres[19608]: [12-1] @ 19608 0: LOG: startup process
(PID 19614) was terminated by signal 6: Abort trap
Oct 6 17:26:4
0.%driver: hpet
dev.hpet.0.%location: handle=\_SB_.HPET
dev.hpet.0.%pnpinfo: _HID=PNP0103 _UID=0
dev.hpet.0.%parent: acpi0
--
Sean Chittenden
se...@freebsd.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
Howdy. Is there any reason that someone can't shepherd kern/160496 in to SVN?
This seems like a reasonably easy fix and basic patch. -sc
--
Sean Chittenden
s...@chittenden.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
advertisements instead.
? Thanks in advance. -sc
http://forum.pfsense.org/index.php?topic=39995.0
http://ouliakk.blogspot.com/2011/08/using-openospfd-with-freebsd-78.html
--
Sean Chittenden
s...@chittenden.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
f you included (a scrubbed) the output of a 'fossil
status'. -sc
--
Sean Chittenden
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
have their firewall
rules reloaded (e.g. /etc/rc.d/pf reload) to reflect this changed default
route. In previous 7.X, pf(4) picked up this change without needing to reload
the rules.
--
Sean Chittenden
s...@chittenden.org
___
freebsd-net@freebsd.org ma
Howdy. I somehow managed to import a file that should have had it's execute
bit set, but didn't. Not the end of the world, but pretty irritating to always
have to chmod(2) the file. I see file_isexe() in file.c, but I don't understand
how I can update the status of vfile to match the file syst
whether or not the
library was present or not based on its existence.
-sc
PS After revisiting bjam to get boost-log working, my feelings towards bjam
are much more closely aligned with the statement "writhing hatred."
--
Sean Chittenden
s...@chittenden.org
___
-
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to million
Have you asked Christian about this? -sc
--
Sean Chittenden
On Nov 21, 2009, at 5:24 AM, Pau Garcia i Quiles
wrote:
> Hello,
>
> Answering myself (in a different mailing list, no less!), I'd say
> deadline_timer is broken.
>
> I've tested with the time_t_timer.
is addresses all of the
concerns listed below. -sc
http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/reference/deadline_timer.html
--
Sean Chittenden
s...@chittenden.org
--
Let Crystal Reports handle
t results from that for a few hrs. -sc
--
Sean Chittenden
s...@chittenden.org
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
st_foo::test_method() in foo_unittests.cc.o
I can populate the list of libs that I need by hand, but am looking
for guidance on what's the right way forward.
Is there a correct way to use find_package(Boost...) with an installed
1.41.0 atm? I notice Boost_VERSION is
lt to ON, same concept for
linker flags
include("${CONTRIBOBJ}/lib/Boost.cmake")
find_package(Boost ${Boost_VERSION} COMPONENTS thread NO_MODULE)
# no need for include(${Boost_INCLUDE_DIR}) with Boost_SET_INCLUDE=ON
Food for thought. -sc
--
Sean Chittenden
s...
related code in boost?
I know it's a part of Boost, but I just don't care about python 99% of
the time 'cause well... I'm programming in C++ :~] -sc
--
Sean Chittenden
s...@chittenden.org
___
Boost-cmake mailing li
process that you message from
Wt, and have it fork(2) + exec(2) your new child commands. Have the
child manager pass a fd resource back to your Wt process (via dup(2),
see Steven's for examples) and have it check the status of the fd with
0 by
1.40 now and let you know. git or tarball? URL? -sc
--
Sean Chittenden
s...@chittenden.org
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
f what
cmake has to offer. Slowly but surely I'm pushing various variables
out of autogen.sh in to cmake files.
On Thu, Oct 29, 2009 at 3:37 PM, Sean Chittenden
wrote:
I've been running with the following snippet in my boost build
directory for
a while.
IF(CMAKE_COMPILER_IS_GNU
cmake2, it looks like CMAKE_CXX_FLAGS is being reset
somewhere along the lines. Is there a correct/better way to pass this
in to CMake or is there a way to have Boost cmake automatically set -
gdwarf-2 using the above logic? tia. -sc
--
Sean Chittenden
s...@chittenden.org
___
Right now there's no version info on the .so's. Going forward
with .so version info that's unique, it won't. :) -sc
--
Sean Chittenden
On Oct 29, 2009, at 12:51 PM, Vladimir Prus
wrote:
Sean Chittenden wrote:
/usr
local
lib
boost-1.40.0
boost-1.41.0
even comes with ASCII
art!):
http://www.snow.nl/dist/htmlc/ch14s05.html#id2838038
I'm still coming up to speed on boost's convention for micro versions,
but couldn't the SONAME be set to "*.so.1.41" instead of "*.1.41.0" ?
-sc
--
Sean Chittenden
s...@chittend
asant is a symlink from lib/libboost_foo.so to lib/boost-1.40.0/
libboost_foo.so. That's the only scenario that should be prevented at
all costs, the one above is a preference from having hunted down
FreeBSD ports bugs in the past.
-sc
--
Sean Ch
uires:
Libs: -L${libdir} -lfreetype -lz -Wl,-framework,CoreServices,-
framework,ApplicationServices
Cflags: -I${includedir}/freetype2 -I${includedir}
and dump it in a directory. All of those bits of info should be
available from cmake. If a user has pkg-config, they win. If not, no
1 - 100 of 865 matches
Mail list logo
