On 2016-02-21 04:16 PM, Gregor Best wrote:
On Sun, Feb 21, 2016 at 12:41:06PM -0700, Theo de Raadt wrote:
It makes no sense to renumber the FT232_1 entry. That is just creating
churn.
As to the 0x entry, I'm wondering whether it should be named something
like the following, as a historical
On Sun, Feb 21, 2016 at 10:56:43PM +0200, li...@wrant.com wrote:
> [...]
> Others followed suit too, HL_340 bricked clones here. Not sure how to
> resolve the 0x mapping uniformly. Have to invent a separate twerp
> category.
> [...]
USB product IDs only need to be unique under the ven
On Sun, Feb 21, 2016 at 12:41:06PM -0700, Theo de Raadt wrote:
> It makes no sense to renumber the FT232_1 entry. That is just creating
> churn.
>
> As to the 0x entry, I'm wondering whether it should be named something
> like the following, as a historical reminder:
>
> +product FTDI FT232_
Hi,
debugging my setup at home I realized that NAT-T on IPv6 is broken.
I know that NAT in IPv6 sucks, but apparently my dsl modem does not
reliably forward ESP packets, so I use NAT-T instead... *sigh*
Moving that setup from IPv4 to IPv6 I noticed that pf was blocking
outgoing packets and its sr
patch(1) doesn't recognize ed-style diffs that start with an insert
command as such. Same holds true for substitution command, but with the
current state of support for s/, I don't think it makes sense to support
diffs starting with s/.//.
Thoughts?
natano
Index: pch.c
=
It makes no sense to renumber the FT232_1 entry. That is just creating
churn.
As to the 0x entry, I'm wondering whether it should be named something
like the following, as a historical reminder:
+product FTDI FT232_JERKS 0x Serial
> some time back, FTDI released a driver for thei
On Sun, Feb 21, 2016 at 07:04:27PM +0100, Martin Natano wrote:
> The expected order of lines would be, x, y, z but patch produces y, z, x
> instead. The first line is inserted at the correct position, but then
> the other lines are inserted before the first one. The following diff
> solves that pro
When inserting multiple lines with the insert or change command the
lines get reordered when the file is empty before inserting. e.g.
following ed script produces incorrect output (apply to a file with
three lines in it).
1,3c
x
y
z
.
The expected order of lines would be, x, y, z but patch produ
On Sun, Feb 21, 2016 at 05:15:34PM +0100, Martin Natano wrote:
> While testing your suggestion with the example I run into a bug with
> ed-style diff handling in patch(1), resulting in incorrect output
> (fix in the works). Applying the generated diff with ed(1) works fine,
> though.
Yeah, patch h
Hi people,
some time back, FTDI released a driver for their USB RS232 adaptors that
changed the USB device ID of aftermarket devices to 0x, so that they
wouldn't work on any machine, even with the older FTDI drivers, from
then on ([0] has further info on that).
The fix for that is relati
> Hmm, something still does not seem right. For example, try
> diff -e on the contents below (some other tests attached):
>
> A
> B
> C
>
> vs.
>
> W
> X
> .
> Y
> Z
>
> [...]
>
> About the changes below, is something like this the idea behind it?
> The first change command has already removed
> Thank you for your work on the FAQ, one minor nitpick / suggestion with
> a patch[1] attempt, to swap the and tags near document end
> to fix the below bug alarms. A comment below[2]:
>
> [http://validator.w3.org/check?uri=http://www.openbsd.org/faq/index.html]
> Line 427, Column 3: document
Todd C. Miller wrote:
> On Sun, 21 Feb 2016 11:49:55 +0100, Martin Natano wrote:
>
> > The diff below addresses the issues you mentioned. It converts
> > mnt_maxsymlinklen to unsigned and adds a check to ffs_validate() that
> > makes sure, that fs_maxsymlinklen is >= 0. That function is called
> >
On Sun, 21 Feb 2016 11:49:55 +0100, Martin Natano wrote:
> The diff below addresses the issues you mentioned. It converts
> mnt_maxsymlinklen to unsigned and adds a check to ffs_validate() that
> makes sure, that fs_maxsymlinklen is >= 0. That function is called
> during mount and on fsck. This sh
Sat, 20 Feb 2016 17:09:36 -0700 (MST) T.J. Townsend
> CVSROOT: /cvs
> Module name: www
> Changes by: t...@cvs.openbsd.org2016/02/20 17:09:36
>
> Modified files:
> faq: faq13.html index.html
>
> Log message:
> - remove section 13.8 "tell me about ogg vorbis and mp3
Martin Natano wrote:
> When diff encounters a line that consists of a single dot, it emits two
> dots instead, stops the current command and emits a substitute command
> to replace the double dot with a single one. Then it restarts the
> (original) command if necessary and inserts further lines. Th
On Wed, Feb 17, 2016 at 11:27:29AM -0700, Todd C. Miller wrote:
> There is currently code that checks for mnt_maxsymlinklen <= 0.
> Removing the cast will cause other problems for ffs if the maxsymlinklen
> value is negative. I don't think it is safe to make this change
> unless mnt_maxsymlinklen
Martin Natano wrote:
> The fusefs_fhtovp() function makes use of the ROOTINO ((ufsino_t)2)
> define instead of using FUSE_ROOTINO ((ino_t)1), which is used
> everywhere else in the fuse filesystem. This causes a file handle for
> the filesystem root to be falsely rejected with ESTALE.
>
> Comments
Martin Natano wrote:
> The fusefs_checkexp() function returns 0, indicating that export via NFS
> is allowed, while in fact fusefs doesn't support NFS at all. (There is
> a vfs_export() call missing in fusefs_mount() and maybe other stuff too.)
>
> Furthermore, it does so without setting *extflags
19 matches
Mail list logo
