Hi,
Currently smtpd-filters.7 is not installed by default, which looks like an
oversight.
The patch below adds smtpd-filters.7 to usr.sbin/smtpd/smtpd/Makefile
untrusted comment: verify with signify key for exoticsilicon.com
On Thu, Aug 26, 2021 at 12:20:58AM +0100, Stuart Henderson wrote:
> On 2021/08/25 19:58, Crystal Kolipe wrote:
> > On Wed, Aug 25, 2021 at 06:02:11PM +0100, Stuart Henderson wrote:
> > > If I manually configure a link-local the interface is successfully
> > > adde
On Wed, Aug 25, 2021 at 06:02:11PM +0100, Stuart Henderson wrote:
> If I manually configure a link-local the interface is successfully
> added.
>
> Anyone have an idea what the behaviour should be here? For passive
> would it make sense to accept an interface without link-local?
Is there a
Hi,
I sent this to bugs a while back, but it doesn't seem to have been picked up by
anyone.
On both i386 and amd64, the machine boot command in the bootloader has an off
by one bug, which has been present since revision 1.20 in 1998.
The machine boot command is implemented by patching the
The gpt driver was completely deleted from the tree in 2016, and removed from
the i386 GENERIC config in revision 1.819.
It has, however, remained in the amd64 GENERIC config commented out, which
seems like an oversight.
This patch removes it from amd64 GENERIC:
--- GENERIC.origMon
--- sys/dev/pci/drm/amd/display/dc/dce110/dce110_hw_sequencer.c.origTue Jul
6 23:38:25 2021
+++ sys/dev/pci/drm/amd/display/dc/dce110/dce110_hw_sequencer.c Mon Jan 3
15:04:44 2022
@@ -1271,25 +1271,25 @@
switch (pipe_ctx->plane_res.scl_data.format) {
case
Ping?
The patch below fixes an off-by-one in /arch/amd64/stand/libsa/cmd_i386.c.
The affected code path is handling the machine boot command in the bootloader.
Currently, trying to boot from MBR partition 'a', with a command such as
machine boot hd0a, will in fact boot from whichever partition
Surf 2.1 was released seven months ago, but we still have 2.0 in ports.
The attached files update us to 2.1.
COMMENT = simple webbrowser based on webkit/gtk+
DISTNAME = surf-2.1
CATEGORIES =www
HOMEPAGE = http://surf.suckless.org/
REVISION = 0
MAINTAINER= Joerg Jung
When running with kern.securelevel=2, trying to add an existing softraid volume
with bioctl -c fails with:
softraid0: invalid metadata format
This occurs as the call to VOP_OPEN in sr_meta_probe requests read/write
access, which is obviously disallowed at securelevel 2.
Considering that
On Fri, Oct 29, 2021 at 02:08:32PM +0200, Ingo Schwarze wrote:
> Then, much later, because firefox is a monster and a slug:
>
> 12. firefox attempts to open "$tmpfile",
> which was already deleted long before
Set the user immutable flag on the temporary file ;-)
Another one I sent to bugs@ a while ago.
I'm assuming that having 'i386' in the original subject line made everyone hit
their 'd' key, without realizing that this affects amd64 too...
The patch below fixes an off-by-one in /arch/amd64/stand/libsa/cmd_i386.c.
The affected code path is handling
I sent this to bugs@ a while back, but it seems to have been missed.
smtpd-filters.7 is not installed by default.
--- usr.sbin/smtpd/smtpd/Makefile.dist Wed Apr 21 04:54:10 2021
+++ usr.sbin/smtpd/smtpd/Makefile Mon Oct 25 11:54:39 2021
@@ -76,7 +76,7 @@
SRCS+= stat_ramstat.c
src/usr.sbin/smtpd/smtp_session.c contains the following code:
1892 static void
1893 smtp_proceed_wiz(struct smtp_session *s, const char *args)
1894 {
1895 smtp_reply(s, "500 %s %s: this feature is not supported yet
;-)",
1896 esc_code(ESC_STATUS_PERMFAIL,
On Mon, Nov 08, 2021 at 06:13:14PM +, Stuart Henderson wrote:
> On 2021/11/08 14:52, Crystal Kolipe wrote:
> > I'm not aware of a 'wiz' command in any SMTP related RFC.
> This will become clear if you look into sendmail history :)
Got it :).
I assume that this won't be implemente
On Fri, Nov 05, 2021 at 08:24:21AM -0600, Theo de Raadt wrote:
> prx wrote:
>
> > I think this remark should be placed into perspective.
> >
> > When a file is requested, its gzipped version is send if :
> > * The client ask for it with appropriate header.
> > * The server admin configured
On Wed, Nov 03, 2021 at 11:55:41AM +, Stuart Henderson wrote:
> On 2021/11/03 05:47, Crystal Kolipe wrote:
> > > Your OptiPlex 9020 is probably a modern i5/i7, which probably contains
> > > C states similar to this:
> > >
> > > acpicpu0 at acpi0: C2(2
On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt wrote:
> Paul de Weerd wrote:
>
> > A recent commit by Theo changed the hw.perfpolicy behavior to always
> > run at full speed when AC power is on. This means that my workstation
> > (and servers, once I upgrade them) now consumes
On Wed, Jan 05, 2022 at 03:51:32PM -0500, fo...@dnmx.org wrote:
> Hello? I am new to mailing lists
You are successfully subscribed to the list and your posts are being received.
On Mon, Jan 17, 2022 at 01:00:44PM +, Klemens Nanni wrote:
> These don't hurt on !VMM architectures but I was still surprised to see
> them on e.g. sparc64:
>
> # arch -s ; btrace -l | grep vmm
> sparc64
> tracepoint:vmm:guest_enter
> tracepoint:vmm:guest_exit
>
>
On Mon, Jan 17, 2022 at 08:34:39AM -0500, Dave Voutila wrote:
> vmm(4) was removed from i386 hosts a couple years ago if my memory is
> correct.
Ah, my bad. It was indeed removed on 20190118.
Summary:
In function sr_meta_init in softraid.c, there are two bugs which cause the
chunk checksum stored in scm_checksum to be incorrectly calculated. This
affects all newly created softraid volumes.
Details:
The MD5 checksum in scm_checksum should be calculated over the first 72 bytes
of
Since revision 1.2, these SCSI entries have been duplicated in the arm64
GENERIC config file.
The attached patch removes the ones near the top of the config and leaves the
ones lower down, for consistency with the layout of other architectures.
--- GENERIC.origThu Jan 6 14:39:45 2022
On Mon, Oct 23, 2023 at 11:04:07AM +, Klemens Nanni wrote:
> 10/16/23 04:02, Klemens Nanni ??:
> > The current check implies one could use, e.g. SWAP or MSDOS partitions
> > as softraid(4) chunks, but sys/dev/softraid.c always expects FS_RAID,
> > thus using chunks with different
Hi Theo, it's a long time since we last conversed.
On Mon, Oct 23, 2023 at 03:44:17PM -0600, Theo de Raadt wrote:
> What user without OpenBSD experience is booting from 'd'?
>
> Which also poses the question -- what user with OpenBSD experience
> is booting from 'd'?
>
> Why?
Some disklabel
On Thu, Sep 21, 2023 at 11:26:11AM +0200, Omar Polo wrote:
> Do we really need the two checks?
WFIW, my original suggestion made off-list was about checking for 0xfe and
0xff only:
Crystal wrote:
> 0xfe and 0xff are invalid in utf-8.
>
> It _might_ be worth detecting them and in this case not
On Sat, Sep 23, 2023 at 12:10:41PM +0200, Walter Alejandro Iglesias wrote:
> > On Thu, Sep 21, 2023 at 02:12:50PM +0200, Stefan Sperling wrote:
> > > Your implementation lacks proper bounds checking. It accesses
> > > s[i + 3] based purely on the contents of the input string, without
> > >
On Sun, Sep 24, 2023 at 12:37:08PM +0200, Walter Alejandro Iglesias wrote:
> +static int
> +not_utf8(FILE *message, int len)
> +{
> + int n, ulen;
> + unsigned char s[len];
Please re-read Omar's advice about large unbounded arrays.
Following on from the "Send international text with mail(1)" thread...
There is some interest in making mail(1) add relevant MIME headers to allow:
* Correctly sending UTF-8 email.
* Identifying 7-bit ASCII emails with an appropriate content type.
... and possibly other things in the future.
Hi Marc,
On Tue, Sep 19, 2023 at 03:24:41PM +0200, Marc Espie wrote:
> On Tue, Sep 19, 2023 at 09:48:25AM -0300, Crystal Kolipe wrote:
> > deroff chokes when given lines > 2048 bytes, and produces non-deterministic
> > output on little endian archs.
>
> Since
On Wed, Sep 27, 2023 at 02:05:14PM -0600, Todd C. Miller wrote:
> On Wed, 27 Sep 2023 10:59:26 -0600, "Todd C. Miller" wrote:
>
> > I think we want support for arbitrary line lengths. There is only
> > one place where we need to reallocate the line buffer.
>
> The correct check is for "lp -
Two display format bugs seems to have crept in to ls due to the addition of
scaled human readable values and large minor numbers.
A provisional patch is attached, but an aesthetic decision about column padding
needs to be made, (8 vs 13 columns to handle large minor numbers cleanly, see
further
deroff chokes when given lines > 2048 bytes, and produces non-deterministic
output on little endian archs.
Reproducer:
$ jot -s '' -b blah 513 > /tmp/blah
$ for i in 1 2 3 4 ; do deroff /tmp/blah | md5 ; done
2d8f4eebd61ed2a07101419169fc9997
ae19be78a09e6b371787003bf76f5937
On Thu, Oct 12, 2023 at 12:36:48AM +0200, Steffen Nurpmeso wrote:
> Non-7-bit clean headers need RFC 2047 (and/or RFC 2231) encoding.
The use of MIME encoded words to encode header content is no longer
considered best practice. See, for example RFC 6532.
But as Omar said, let's get the basics
On Thu, Oct 12, 2023 at 02:10:47AM +0200, Steffen Nurpmeso wrote:
> Crystal Kolipe wrote in
> :
> |On Thu, Oct 12, 2023 at 12:36:48AM +0200, Steffen Nurpmeso wrote:
> |> Non-7-bit clean headers need RFC 2047 (and/or RFC 2231) encoding.
> |
> |The use of MIME encoded w
Hi,
On Sun, Oct 08, 2023 at 07:07:27PM +0200, Matthieu Herrb wrote:
> I can confirm that there's an issue here. However in my tests, I don't
> see a garbled error message.
> If I set MALLOC_OPTIONS=F then a double free is reported, which I
> tracked down to the realloc() calls in getNextLine()
Hi Ingo,
On Thu, Oct 05, 2023 at 05:32:07PM +0200, Ingo Schwarze wrote:
> In general, ls(1) strives to dynamically determine the required
> column width. It already does that for the file size column.
> Given that device numbers use the same column, i think the solution
> that is cleanest, most
This is an interesting one...
There is a use after free bug in the X config parser, which can be trivially
demonstrated by creating a config file with the first line being a comment and
the second line containing invalid syntax:
$ echo "#foo\nfoo" > custom_config
$ X -config custom_config
[...]
On Tue, Oct 24, 2023 at 01:44:08AM +, Klemens Nanni wrote:
> Rereading the code, I now question why it checks the 'a' label type at all.
>
> Taking your sd0d example through devboot():
>
> |#ifdef SOFTRAID
> | /*
> | * Determine the partition type for the 'a' partition of the
> |
On Sat, Oct 14, 2023 at 07:14:29PM +0200, Matthieu Herrb wrote:
> On Sun, Oct 08, 2023 at 02:50:10PM -0300, Crystal Kolipe wrote:
> > Hi,
> >
> > On Sun, Oct 08, 2023 at 07:07:27PM +0200, Matthieu Herrb wrote:
> > > I can confirm that there's an issue here. However
On Sun, May 15, 2022 at 11:44:29AM +0200, Otto Moerbeek wrote:
> On Sun, May 15, 2022 at 04:27:30AM -0500, Luke Small wrote:
> > How did someone prove the current implementation was cryptographically
> > sound? Did they run massive simulations which ran the gamut of the uint32_t
> > range which
On Fri, May 20, 2022 at 09:48:28PM -0500, Luke Small wrote:
> Crystal: You can prove that for random, repetitive, correct, database
> record name generation using small upperbounds, the demonstrated 1/3-1/2
> runtime isn???t worth it for an upperbound like 26 - 92 in a business context
> that
On Sat, May 28, 2022 at 01:46:18PM -0700, Seth David Schoen wrote:
> We're also interested in talking about whether there's an appropriate
> path for supporting non-broadcast use of addresses within 127/8, our
> most controversial change. In Linux and FreeBSD, we're experimenting
> with the ideas
Ping?
This is a trivial but useful fix.
- Forwarded message from Crystal Kolipe -
Date: Thu, 5 May 2022 16:52:11 -0300
From: Crystal Kolipe
To: tech@openbsd.org
Subject: Fix console screen blanker - timeout of zero cannot be set
Summary:
A bug in wsdisplay.c prevents the console
On Mon, Jul 25, 2022 at 10:19:25AM -0600, Theo de Raadt wrote:
> +number generators, so the security properties cannot be gauranteed.
s/gauranteed/guaranteed
Otherwise OK.
Summary:
A bug in wsdisplay.c prevents the console screen blanker from being disabled
once it has been enabled.
Details:
The console code includes a screen blanker facility, controlled with wsconsctl:
# wsconsctl display.screen_off
display.screen_off=0
By default, the screen blanker is
On Sun, Sep 04, 2022 at 07:08:51PM +, Mikolaj Kucharski wrote:
> I have strange setup on some of my machines, when I want to encrypt disk
> where OpenBSD is installed, but still be able to boot them up without
> any user interaction, like passphrase entry for CRYPTO softraid(4). I
> have this
On Thu, Sep 15, 2022 at 08:31:06AM -0600, Theo de Raadt wrote:
> RCS file: lib/libc/sys/mimmutable.2
...
> +Unmapped pages in the region do not retain immutability, but this
> +behaviour should not be relied up.
s/relied up/relied on/
or
s/relied up/relied upon/
On Tue, Sep 20, 2022 at 10:54:10AM +, Klemens Nanni wrote:
> Does this negation of the main sentence add anything I don't get?
Yes. The wording you are proposing to remove makes it clear that
setting -R sets the 'default' behaviour, (which can be overridden
by other flags), rather than
On Tue, Sep 20, 2022 at 02:34:08PM +0100, Jason McIntyre wrote:
> On Tue, Sep 20, 2022 at 08:37:27AM -0300, Crystal Kolipe wrote:
> > On Tue, Sep 20, 2022 at 10:54:10AM +, Klemens Nanni wrote:
> > > Reads like pointing out the obvious and the next sentence also explains
&
On Sun, Dec 25, 2022 at 08:07:11PM +, Miod Vallat wrote:
> Indeed! So the third copystr() call could be replaced with this:
>
> Index: sys/kern/vfs_lookup.c
> ===
> RCS file: /OpenBSD/src/sys/kern/vfs_lookup.c,v
> retrieving
Hi Miod,
On Sun, Dec 25, 2022 at 05:21:50PM +, Miod Vallat wrote:
> In other words,
> copystr(src, dst, dstsiz, len)
> is equivalent to:
> if (strlcpy(dst, src, dstsiz) >= dstsiz)
> return ENAMETOOLONG;
> if (len != NULL)
> *len = strlen(dst);
The attached patch adds a new -q option to cp that allows ignoring file flags
whilst copying with the existing -p, (preserve), option. Without -p, the new
-q option does nothing.
Rationale:
File flags are not widely used, but we use them on copies of local data that
is not expected to change,
I've only read through 50% of this so far, but there are a few issues:
On Thu, Dec 22, 2022 at 06:31:23PM -0500, Paul Tagliamonte wrote:
> Index: lib/libcurses/base/resizeterm.c
> ===
> RCS file:
On Mon, Dec 26, 2022 at 07:34:04AM +, Jason McIntyre wrote:
> On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote:
>
> hi. i've committed the parts of this diff relating to libssl.
> jmc
>
> > ===
> > Index:
On Mon, Dec 26, 2022 at 11:25:22AM +0100, Theo Buehler wrote:
> On Mon, Dec 26, 2022 at 07:18:45AM -0300, Crystal Kolipe wrote:
> > On Mon, Dec 26, 2022 at 07:34:04AM +, Jason McIntyre wrote:
> > > On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote:
>
OK, I've looked through the other 50% of the original diff, (I've not looked
at the new one).
Comments in-line:
On Thu, Dec 22, 2022 at 06:31:23PM -0500, Paul Tagliamonte wrote:
> Index: lib/libssl/test/pkits-test.pl
> ===
> RCS
The following patch adds five escape sequences to the wscons vt100 emulation.
It's one part of a larger set of patches I am working on to make the console
more like xterm.
Note: Casual readers of -tech and those not familar with terminfo might
prefer to read my write-up at
The KASSERT macro is a NOP unless DIAGNOSTIC is defined, so it doesn't need to
be in an #ifdef here:
--- dev/wscons/wsemul_vt100.c.dist Mon May 25 06:55:49 2020
+++ dev/wscons/wsemul_vt100.c Sat Dec 31 20:37:14 2022
@@ -204,9 +204,7 @@
if (console) {
edp =
Here is an updated version of this patch.
Unlike the first version which just added some new control sequences in order
to fix the display, this also touches some input code.
New in this version:
* F1 - F4 now send different sequences.
* F13 - F24 now send different sequences, but see notes
This version of the patchset updates a few things since the one posted early
on Wednesday:
NEW - Fix two off-by-ones that caused spurious trailing null characters when
requesting the terminal IDs. (Noticed by Paul running tmux.)
NEW - Discard any parameters passed to a CSI 38 m or CSI 48
On Fri, Jan 06, 2023 at 06:21:41PM +, Nicholas Marriott wrote:
> You should strictly only discard the following two arguments or stuff like
> SGR 38;5;100;1 won't work.
Well I was initially in two minds about that, because I thought there might be
other un-official extensions that used 38
On Sat, Jan 07, 2023 at 11:09:00AM +, Nicholas Marriott wrote:
> As far as SGR 38/48 with anything except 2 and 5 goes - the only terminals
> I have at hand do not discard but I think either of discarding or not
> discarding would be reasonable. What does xterm do here? It would probably
> be
Ah, here is a trivial program to demo the new 256 color palette on the console:
#include
int main()
{
int i;
printf ("\x1b[m\n");
for (i=0;i<256;i++) {
printf ("\x1b[38;5;%dm#%03d %s",i,i, ((i+1) % 16 ? "" : "\n"));
}
printf ("\x1b[m\n");
for (i=0;i<256;i++) {
printf
On Sat, Jan 07, 2023 at 09:05:21AM -0300, Crystal Kolipe wrote:
> In any case, I'll post an updated version with 256 in an hour or so.
It's here!
NEW - 256 colour support! (Not extensively tested yet).
NEW - Interpret SGR 38/48 sequences instead of just discarding the following
paramet
Fix a fairly obvious comment typo:
--- wsdisplay.c.distTue Jan 10 09:42:14 2023
+++ wsdisplay.c Tue Jan 10 09:42:59 2023
@@ -2212,7 +2212,7 @@
}
/*
- * Switch rhe console display to its ddb screen, avoiding locking
+ * Switch the console display to its ddb screen, avoiding locking
*
Hi Stuart,
On Tue, Jan 10, 2023 at 11:05:24AM +, Stuart Henderson wrote:
> On 2023/01/09 18:39, Crystal Kolipe wrote:
> > Another update to the console patchset...
>
> i386 ramdisk still fits.
>
> ; diff /tmp/old /tmp/new
> --- /tmp/oldTue Jan 10 03:56:19 2023
&
On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
> Hi Crystal,
>
> I tried your patch on my laptop. With it applied, and my TERM set to
> 'xterm', I do get colors in mutt and tmux.
Great! Thanks for testing :).
> The latter, however, shows
> '^@^@' before the PS1 prompt upon
On Wed, Jan 04, 2023 at 08:08:48PM +0100, Paul de Weerd wrote:
> On Wed, Jan 04, 2023 at 02:33:57PM -0300, Crystal Kolipe wrote:
> | On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
> | > Hi Crystal,
> | >
> | > I tried your patch on my laptop. With it
Continuing the move towards xterm becoming the default termtype for the
console...
This third version of the patchset adds the following features. New features
since the last version are highlighted first:
NEW - Control sequences for dim text, invisible text, strike through, italic,
and
Another update to the console enhancement patchset.
Some of the code from previous versions is now in -current, but if you want
the full experience, (256 colours, extra text attributes, etc), you'll still
need to apply the following diff.
This is against -current as of an hour or so ago.
NEW -
# New escape sequences and two one-line bugfixes
--- dev/wscons/wsemul_vt100_subr.c.dist Mon May 25 06:55:49 2020
+++ dev/wscons/wsemul_vt100_subr.c Sat Jan 7 12:39:58 2023
@@ -231,7 +231,7 @@
switch (A3(edp->modif1, edp->modif2, c)) {
case A3('>', '\0', 'c'): /* DA
# New key function key definitions
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
On Sat, Jan 07, 2023 at 02:46:04PM +, Nicholas Marriott wrote:
> If possible can you now give me your latest patches without 256 colours and
> I will test them and see if we can get them in.
Sure, here is the latest version with _most_ of the 256 colour stuff removed.
I've left in the CSI
# Obviously :)
--- /etc/ttys.dist Fri Dec 23 13:58:58 2022
+++ /etc/ttys Sat Jan 7 14:44:26 2023
@@ -3,19 +3,19 @@
#
# name getty typestatus comments
#
-console"/usr/libexec/getty std.9600" vt220 off secure
-ttyC0 "/usr/libexec/getty
On Sun, Jan 08, 2023 at 08:55:46PM +, Nicholas Marriott wrote:
> This is still too big for one go so I think it needs split further. I
> suggest that first we get three diffs with the very easy stuff:
>
> 1) The two bug fixes
>
> 2) HPA/VPA/INDN/RIN
You didn't mention '3' :-)
But anyway,
Another update to the console patchset...
At this point, my focus has shifted to testing the currently implemented
functionality rather than adding anything new. Unless there is breakage that
I am not aware of, this version of the diff already allows the use of
TERM=xterm with no loss of
On Sat, Dec 24, 2022 at 11:56:37AM +0100, Florian Obser wrote:
> This is at least supported by FreeBSD's units(1) as well as by
> systemd/Linux.
Looks good, just one typo noted below:
>
> diff --git units.1 units.1
> index d7a45f729b3..916d1b03d32 100644
> --- units.1
> +++ units.1
> @@ -79,6
On Fri, Dec 23, 2022 at 03:03:15PM +, Stuart Henderson wrote:
> Overall imho this is too much churn to do in huge swathes across the
> tree.
>
> Fixes for spelling/grammar in comments etc are often more usually
> done by people working on a particular part of the tree or trying to
>
On Sun, Dec 18, 2022 at 08:53:26PM -0500, Geoff Steckel wrote:
> nc of 0's from one rge to another at full speed crashes
> in the input interrupt path with corruption of the memory
> pool used for the mbufs
> It's 100% reproduceable.
I have not, (yet), been able to reproduce this between two of
Here are a few more instances of KASSERT being placed in an #ifdef DIAGNOSTIC
block. This is redundant, as KASSERT is already a nop if DIAGNOSTIC is not
defined.
Index: crypto/blake2s.c
===
RCS file: /cvs/src/sys/crypto/blake2s.c,v
On Sat, Jan 21, 2023 at 10:43:08AM +, Stuart Henderson wrote:
> Test machines are less of a problem, because they're test machines.
Sure, we're talking about two different scenarios.
> Machines where things have been enabled to debug a problem and then
> forgotten are a bigger issue.
> I'm
On Fri, Jan 20, 2023 at 01:15:29PM -0700, Theo de Raadt wrote:
> Todd C. Miller wrote:
> > I wonder if it makes sense to have a version of sysctl.conf that
> > only gets used for the next reboot and then is removed, kind of
> > like /etc/rc.firsttime. Maybe call it /etc/sysctl.once.
>
> Well
I've separated out the 256 colour code from the rest of my console enhancement
patchset, because it seems that the bold and italic code was causing some
problems that I haven't yet fully resolved.
Also, various bits from the previous mega-patch are now in cvs, so it no
longer applies cleanly.
We recently removed rasops_isgray, but this got left behind.
Index: rasops.h
===
RCS file: /cvs/src/sys/dev/rasops/rasops.h,v
retrieving revision 1.25
diff -u -p -r1.25 rasops.h
--- rasops.h25 May 2020 09:55:49 - 1.25
Here is the latest version of the double underline and strikeout parts of my
console patchset.
Previously, the double underline was always painted two pixels above the
normal underline. This worked well for most font sizes, but to improve the
visual effect with the smallest and largest fonts the
On Mon, Jan 30, 2023 at 04:53:02PM -0700, Theo de Raadt wrote:
> Whoosh, you missed the point.
>
> I've used xterm for decades and never used any of that.
>
> If those operations turn into "no-op" or perform the minimum rendering
> change, it is still valid xterm escape processing.
>
> There is
On Tue, Jan 31, 2023 at 12:03:53AM +0100, Christian Weisgerber wrote:
> Crystal Kolipe:
>
> > Here is the latest version of the double underline and strikeout parts of my
> > console patchset.
>
> I'm sorry, but I gotta ask: Who or what uses something like this??
On Mon, Jan 30, 2023 at 09:15:51PM -0300, Crystal Kolipe wrote:
> But just because the original goal is well within sight, I didn't see that
> as a reason to stop.
Just to clarify, I mean a reason to stop writing further code for evaluation.
Not 'not a reason to stop', as in continue bl
Wouldn't it be nice if we could do italic text on the console?
Well, now we can!
I've separated out this diff from my main 'console enhancement' patchset for
easier testing.
This is against -current as of a few minutes ago, and adds just the following
features:
* Italic text.
* Bold text using
Here is a trivial program to test the italic text patch I just sent to -tech:
#include
int main()
{
printf ("\n\x1b[mThis is normal text.\n");
printf ("\x1b[1mThis is bold text.\n");
printf ("\x1b[22;3mThis is italic text.\n");
printf ("\x1b[1mThis is bold and italic text.\n");
printf
Hi Daniel,
On Sun, Jan 15, 2023 at 05:54:39PM -0500, Daniel Dickman wrote:
> Hi Crystal,
>
> I tried your patch but it seems to tickle something on my lenovo laptop.
>
> I see this message:
> entry point at 0x1001000
>
> and then nothing further seems to show up.
Thanks for testing.
* Is
On Sun, Jan 08, 2023 at 09:15:04PM -0300, Crystal Kolipe wrote:
> I've just had a casual look through all of the rasops code, including
> rasops2.c which has been moved to the attic, and I can't see where these
> values are used.
Seems like the only use was in rasops24.c and this use wa
On Sun, Jan 08, 2023 at 10:34:23PM +, Nicholas Marriott wrote:
> > > - Why do you change RS_SCROLLBACK_SCREENS?
> >
> > To more closely mirror xterm behaviour. The current scrollback buffer is a
> > tiny fraction of what xterm offers by default. It's not that important,
> > but
> > if we're
On Fri, Jan 20, 2023 at 02:51:31PM +, Jason McIntyre wrote:
> On Fri, Jan 20, 2023 at 12:35:05PM +, Klemens Nanni wrote:
> > 19.01.2023 19:11, Jason McIntyre ??:
> > > On Thu, Jan 19, 2023 at 06:50:14PM +, Klemens Nanni wrote:
> > >> $ man -h rdsetroot
> > >> rdsetroot [-dx]
The earlier version of this patch leaked memory if a font was locked multiple
times.
This version fixes the leak:
Index: dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.69
diff -u -p -r1.69
On Fri, Jan 20, 2023 at 05:00:37PM +, Klemens Nanni wrote:
> Alright, sorry for the noise.
>
> Is this minimal sync plus stdout mention fine?
>
> Index: rdsetroot.8
> ===
> RCS file: /cvs/src/usr.sbin/rdsetroot/rdsetroot.8,v
>
On Tue, Jan 31, 2023 at 11:27:17AM +0100, Marc Espie wrote:
> I'm curious about the new enforcement strategies. Unfortunately I'm a bit
> lost in the 1000+ pages of the intel manual.
>
> Could someone point me to the document that describes PKU, specifically ?
Well the intel SDM is surely the
Currently it is not possible to use unicode codepoints > 0xFF on the console,
because our UTF-8 decoding logic is badly broken.
The code in question is in wsemul_subr.c, wsemul_getchar().
The problem is that we calculate the number of bytes in a multi-byte
sequence by just looking at the high
On Sat, Feb 25, 2023 at 08:29:54PM +0100, Steffen Nurpmeso wrote:
> Crystal Kolipe wrote in
> :
> |Currently it is not possible to use unicode codepoints > 0xFF on the \
> |console,
> |because our UTF-8 decoding logic is badly broken.
> |
> |The code in ques
The iskmemdev function checks for minor number 14 in addition to 0 and 1 on
the following archs:
amd64, arm64, i386, and riscv64
Device 2, 14 was traditionally /dev/io, which we don't support and so opening
it will always return ENXIO from mmopen anyway.
We only use iskmemdev in one place in
1 - 100 of 113 matches
Mail list logo
