Hi there,
ext2fs currently has #if 0 around the size check for lengthening a
file. This allows ftruncate(2) calls for very large files to succeed,
but result in a smaller file than was requested. I noticed the problem
while trying to create vmd(8) images on an ext2fs filesystem.
Below is a patch
The pkg-config files for libcrypto and libssl claim to be version
1.0.0. This was noticed on the openvpn-devel mailing list when they
started requiring OpenSSL 1.0.1 or newer:
https://sourceforge.net/p/openvpn/mailman/message/35785095/
While I don't think their approach of testing specific vers
On Mon, 17 Apr 2017 09:20:21 +0200 (CEST)
Mark Kettenis wrote:
> These instructions may not be 100% accurate yet ;).
I also had to build libcxx before doing a full build:
# cd /usr/src/lib/libcxx
# make obj
# make depend
# make includes
# make
# make install
It looks like revision 1.10 of cert.pem (which was intended only to
sort the contents of the file) accidentally removed the GlobalSign R2
CA -- probably because it has the same CN as the R3 CA. The CN is used
as a hash key in the script used for sorting
(https://spacehopper.org/format-pem.20160201)
On Sat, 29 Aug 2015 21:48:34 +1000
Steven McDonald wrote:
> Index: lib/libutil/opendev.c
> ===
> RCS file: /cvs/src/lib/libutil/opendev.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 opendev.c
> --- lib/libuti
Same diff, corrected formatting. Sorry for the noise.
Index: lib/libutil/opendev.3
===
RCS file: /cvs/src/lib/libutil/opendev.3,v
retrieving revision 1.22
diff -u -p -r1.22 opendev.3
--- lib/libutil/opendev.3 15 Jan 2015 19:06:3
Same diff, corrected formatting. Sorry for the noise.
Index: lib/libutil/opendev.c
===
RCS file: /cvs/src/lib/libutil/opendev.c,v
retrieving revision 1.15
diff -u -p -r1.15 opendev.c
--- lib/libutil/opendev.c 30 Jun 2011 15:04:5
Sorry, my terminal seems to be mangling tabs into spaces. Here's a
properly copypasted diff:
Index: bin/chmod/chmod.c
===
RCS file: /cvs/src/bin/chmod/chmod.c,v
retrieving revision 1.34
diff -u -p -r1.34 chmod.c
--- bin/chmod/chmod.c
Hi Theo,
I think chmod fits in the "cannot be tamed" category. tame(2) says of
chmod(2) and friends:
Setuid/setgid bits do not work, nor can the user or group be
changed on a file.
This breaks 'chmod u+s'. It might be possible to tame only if it looks
like a mode is being set which is al
On Sun, 23 Aug 2015 19:45:17 +1000
Steven McDonald wrote:
> fd = opendev(name, flags, 0, devicep);
> if (fd == -1 && errno == ENOENT)
> - devicep = &name;
> + *devicep = name;
I'm actually wondering if opendev(3) itself s
On Sun, 23 Aug 2015 19:21:42 +1000
Steven McDonald wrote:
> Also, section 6.9.1 clause 9 of C99[0] says that "each parameter has
> automatic storage duration", so I think it's not safe to rely on a
> function parameter still being a valid object outside of openpartition
The openpartition function in tunefs(8) will currently set devicep, a
char** passed in from main, to the path it attempted to opendev(3).
This doesn't actually work as intended; it should be setting the value
devicep points to instead of devicep itself.
Also, section 6.9.1 clause 9 of C99[0] says
Hi,
Below is a diff to avoid masking errno from DIOCMAP in opendev(3). The
intention of the existing code appears to be to try using path as a
device name rather than a DUID in case of failure, but as far as I can
tell, this is only desirable if DIOCMAP returns ENOENT anyway. Other
kinds of error
Hi,
Here's a patch for current.html telling users how to handle the sudo
removal from base.
Index: faq/current.html
===
RCS file: /cvs/www/faq/current.html,v
retrieving revision 1.614
diff -u -p -r1.614 current.html
--- faq/current.h
On Sat, 4 Apr 2015 15:23:45 -0300
Gleydson Soares wrote:
> but we shouldn't change macrodef here.
Regardless of whether macrodef is being changed, you're still returning
if macrodef is true, so there is no way for it to be true at the point
where you're adding a test for it.
On Sat, 14 Mar 2015 01:49:22 -0400
"Ted Unangst" wrote:
> Thanks. I restored the systm.h include instead. It's rare for C files
> to include libkern headers directly. I think systm.h remains the
> correct header for strcmp.
Thanks for the clarification. I was going by the SYNOPSIS section of
ker
The recent change to db_variables.c to not include sys/systm.h revealed
a missing include that breaks kernel builds on macppc (and possibly
other arches). The problem is that db_variables.c makes use of
strcmp(9), which requires lib/libkern/libkern.h, and that was being
included via systm.h.
This
17 matches
Mail list logo
