Tooling Integration and Developer Experience
On 1/30/23 02:54, Julian H. Stacey wrote: > Jamie Landeg-Jones wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix >> to an admittedly trivial issue, but it's soon going to hit one year old, >> and has not had any feedback. Not even "this is rubbish. close ticket" >> >> | jamie@catwalk:~ % stat 'so good they named it twice' >> | stat: so good they named it twice: stat: No such file or directory >> >> As such, it's the oldest of my patches to be completely ignored, but then, >> most of my fixes I haven't even submitted, because, what's the point? >> I've instead spent time writing something so the patches are automatically >> aplied to my src tree, and distributed to all my servers. Forked from: 1 year src-patch anniversary. I feel Jamie's pain, this kind of experience can be very discouraging to any contributor without commit bit. All developers like quick feedback loops. Nobody wants to wait a year. I think FreeBSD project looses a lot of potential contributors due to issues of this kind. I don't believe there is any ill intent, there is no elite cast of grumpy commit-bit holders who only work on what they are interested in, ignoring the project as a whole. Far from it. But I do hope that the situation can be improved and I want to offer my view and opinion. The Problem --- I do believe that the source of all problems is lack of integration in tooling and communication. Let me elaborate: FreeBSD project has a lot of tools, but the tools are not well integrated together: - There are too many places where a patch can be posted: phabricator, github, bugzilla, mailing list. - There are too many places to have a conversation: mailing lists, phabricator reviews, bugzilla comments, github issues and PRs, forum, multiple IRC channels spanning multiple IRC servers, etc. - A posted patch is cat in the bag, there is no pre-commit CI to do some basic sanity-checking, commit-bit holders need to do a lot of work to verify the commit (run CI on it) - Tools are not integrated. There is no information flow between them, no effective cross-referencing, lookup or discover, etc. - Bugs in Bugzilla are not visible in Phabricator. - Commits in Phabricator do not resolve bugs in Bugzilla - Jenkins CI/CD and Phabricator don't know about each other. ... there are probably more examples, but this is enough to draw a few conclusions: 1. Information is fragmented and is easily lost or forgotten. 2. It takes manual human effort to update information in multiple systems. 3. Human attention (developers, contributors, etc.) to different systems is spread unequally. This leads to poor developer experience, regardless of commit-bit status. A patch posted in bugzilla went unnoticed for a year until frustrated and desperate contributor started complaining about it in the mailing list, and was committed hours later. The is also a lack of designated maintainers (I am drawing the analogy from Linux kernel) A role who's job is to integrate: collect all patches, feedback, reports about a specific area (kernel subsystem, userland tool or whatnot), and update/curate the knowledge and communication around this area. In my 15+ year career in IT I've seen multiple projects fail due to communication and integration issues. Without concentrated effort and strong leadership these problems rarely go away on their own. Proposed Solutions -- In the order of implementation: 1. Tooling integration: This can be as easy as moving everything into Phabricator. Phabricator, apart from features that we already use, has support for CI/CD, bug reports, wiki, project planning and milestones, chat, etc. Alternative platforms can be used as well: GitLab, SourceHut The main idea: to prevent information fragmentation and improve discoverability, cross-referencing abilities, search, etc. The challenge: is inertia and migration of existing information out of currently used tools. The sentiment: we don't need more tools, we need fewer tools that work better together. 2. Growing the community: Integrated tooling improves productivity and allows focusing on quickening the feedback loop: accepting/rejecting/commenting one-off contributions faster. Regular contributors will be more visible and will get commit-bit faster. With enough commit-bit holders focused maintainership practice can be started. In the end this is just my opinion, I hope it will spark some conversation. Thanks for reading this far :) -- Ihor Antonov
Re: 1 year src-patch anniversary!
Jamie Landeg-Jones wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix > to an admittedly trivial issue, but it's soon going to hit one year old, > and has not had any feedback. Not even "this is rubbish. close ticket" > > | jamie@catwalk:~ % stat 'so good they named it twice' > | stat: so good they named it twice: stat: No such file or directory > > As such, it's the oldest of my patches to be completely ignored, but then, > most of my fixes I haven't even submitted, because, what's the point? > I've instead spent time writing something so the patches are automatically > aplied to my src tree, and distributed to all my servers. I wrote a tool in 1993 I still use http://www.berklix.com/~jhs/bin/.csh/customise to apply trees of generic & personal diffs to src & ports, for multi releases http://www.berklix.com/~jhs/src/ to apply diffs, where some are submitted, some committed for some versions, some diffs still needed for older versions, & some not submitted or committed. I guess many, especially non-commiters, maintain trees of uncommited diffs & there's probably other applicator scripts, numerous re-inventing of wheels for decades, 'cos send-pr / https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid commiters can't keep up with submissions. & non committers can't afford to wait months or years, remembering what's been seen commited to Release X.Y & what still needs to be kept to apply to other inc. older releases. Probably lots of re-invented wheels: trees of diffs & applicator scripts, but to different standards, not uniformly exportable, not immediately familiar to & usable by others. While retaining the model of "This generic src/ ports/ doc/ tree has been built from patches blessed by commiters as fit for all" FreeBSD hackers(especially non commiters who must wait for commits to reduce their heap of candidate diffs) would benefit from a unified set of tools & directory formats to allow individuals to maintain & export trees of candidate diffs etc to some common standards. It wouldnt obviate / replace send-pr & https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would be an optional normalied convenience, especially beneficial to those who are Not commiters but who have growing heaps of uncommited patches. Maybe a summer of code or other person might look at Jamie's & my applicator scripts, & diff tree shapes, not for our actual current diffs, but to design common unified standards to export trees of candidate diffs that can be applied by one common applicator tool ? Hacker who are not committers presumably accumulate an an ever growing heap of diffs, a burden best normalised & automated. > I know it's a volunteer effort, but I've been here 25 years, and whilst > I could (and should) take on more port-maintainership, any other offers > of help have fallen on deaf ears. > > *shrug* I miss Mark Linimon. Cheers, -- Julian Stacey http://StolenVotes.UK/jhs/ Arm Ukraine, Zap Putin.
Re: 1 year src-patch anniversary!
On 1/29/23, Mateusz Guzik wrote: > On 1/29/23, Jamie Landeg-Jones wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix >> to an admittedly trivial issue, but it's soon going to hit one year old, >> and has not had any feedback. Not even "this is rubbish. close ticket" >> >> | jamie@catwalk:~ % stat 'so good they named it twice' >> | stat: so good they named it twice: stat: No such file or directory >> >> As such, it's the oldest of my patches to be completely ignored, but >> then, >> most of my fixes I haven't even submitted, because, what's the point? >> I've instead spent time writing something so the patches are >> automatically >> aplied to my src tree, and distributed to all my servers. >> >> I know it's a volunteer effort, but I've been here 25 years, and whilst >> I could (and should) take on more port-maintainership, any other offers >> of help have fallen on deaf ears. >> > > Well I was not aware of it. > > mail me with git format-patch result and I'll commit. > also make sure the commit message starts with: stat: -- Mateusz Guzik
Re: 1 year src-patch anniversary!
On 1/29/23, Jamie Landeg-Jones wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix > to an admittedly trivial issue, but it's soon going to hit one year old, > and has not had any feedback. Not even "this is rubbish. close ticket" > > | jamie@catwalk:~ % stat 'so good they named it twice' > | stat: so good they named it twice: stat: No such file or directory > > As such, it's the oldest of my patches to be completely ignored, but then, > most of my fixes I haven't even submitted, because, what's the point? > I've instead spent time writing something so the patches are automatically > aplied to my src tree, and distributed to all my servers. > > I know it's a volunteer effort, but I've been here 25 years, and whilst > I could (and should) take on more port-maintainership, any other offers > of help have fallen on deaf ears. > Well I was not aware of it. mail me with git format-patch result and I'll commit. -- Mateusz Guzik
1 year src-patch anniversary!
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix to an admittedly trivial issue, but it's soon going to hit one year old, and has not had any feedback. Not even "this is rubbish. close ticket" | jamie@catwalk:~ % stat 'so good they named it twice' | stat: so good they named it twice: stat: No such file or directory As such, it's the oldest of my patches to be completely ignored, but then, most of my fixes I haven't even submitted, because, what's the point? I've instead spent time writing something so the patches are automatically aplied to my src tree, and distributed to all my servers. I know it's a volunteer effort, but I've been here 25 years, and whilst I could (and should) take on more port-maintainership, any other offers of help have fallen on deaf ears. *shrug* I miss Mark Linimon.
Re: vt and keyboard accents
Hans Petter Selasky wrote:
> On 1/29/23 09:48, Yuri wrote:
>> Hans Petter Selasky wrote:
>>> On 1/29/23 01:54, Yuri wrote:
Looking into an issue with accents input for vt and cz (so
/usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
working and other result weird unrelated characters output.
Checking kbdcontrol -d output, there is an obvious difference with
keymap contents -- all mappings are trimmed down to 1 byte after
reading:
kbdcontrol:
dacu 180 ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
( 'y' 253 )
keymap:
dacu 0xb4 ( 0xb4 0xb4 ) ( 'S' 0x015a ) ( 'Z'
0x0179 )
( 's' 0x015b )
( 'z' 0x017a ) ( 'R' 0x0154 ) ( 'A'
0xc1 )
( 'L' 0x0139 )
( 'C' 0x0106 ) ( 'E' 0xc9 ) ( 'I'
0xcd )
( 'N' 0x0143 )
( 'O' 0xd3 ) ( 'U' 0xda ) ( 'Y'
0xdd )
( 'r' 0x0155 )
( 'a' 0xe1 ) ( 'l' 0x013a ) ( 'c'
0x0107 )
( 'e' 0xe9 )
( 'i' 0xed ) ( 'n' 0x0144 ) ( 'o'
0xf3 )
( 'u' 0xfa )
( 'y' 0xfd )
Source of the problem is the following definition in sys/sys/kbio.h:
struct acc_t {
u_char accchar;
u_char map[NUM_ACCENTCHARS][2];
};
While the keymaps were converted to have the unicode characters for vt
in the commit below, the array to store them (map) was missed, or was
there a reason for this?
---
commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
Author: Stefan Eßer
Date: Sun Aug 17 19:54:21 2014 +
Attempt at converting the SYSCONS keymaps to Unicode for use with
NEWCONS.
I have spent many hours comparing source and destination formats,
and hope
to have caught the most severe conversion errors.
---
I have tried the following patch and it allows me to enter all accents
documented in the keymap, though I must admit I'm not sure it does not
have hidden issues:
diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
index 7f17bda76c5..fffeb63e226 100644
--- a/sys/sys/kbio.h
+++ b/sys/sys/kbio.h
@@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
struct acc_t {
u_char accchar;
- u_char map[NUM_ACCENTCHARS][2];
+ int map[NUM_ACCENTCHARS][2];
};
>>>
>>> Hi,
>>>
>>> Using "int" for unicode characters is probably good for now. Your patch
>>> looks good, but please also consider the "umlaut" case while at it
>>> (multiple characters that become one)!
>>
>> I think umlauts are already part of "accents" (duml keyword), e.g. in
>> cz.kbd:
>>
>> duml 0xa8 ( 0xa8 0xa8 ) ( 'A' 0xc4 ) ( 'E' 0xcb )
>> ( 'O' 0xd6 )
>> ( 'U' 0xdc ) ( 'a' 0xe4 ) ( 'e' 0xeb )
>> ( 'o' 0xf6 )
>> ( 'u' 0xfc )
>>
>> So pressing Alt+Shift and "=/+" key, and then pressing one of AEOUaeou
>> keys would produce ÄËÖÜäëöü, respectively, and it currently works as all
>> of the ÄËÖÜäëöü characters can be written as single-byte unicode.
>>
>> And the following dcar (that is, "caron") characters are all broken as
>> they need at least 2 bytes, pressing Shift and "=/+" key, and any of the
>> LSTZlstzCEDNRcednrUu would print nothing at all, produce garbage, or
>> print some control character (last byte only):
>>
>> dcar 0x02c7 ( 0x02c7 0x02c7 ) ( 'L' 0x013d ) ( 'S' 0x0160 )
>> ( 'T' 0x0164 )
>> ( 'Z' 0x017d ) ( 'l' 0x013e ) ( 's' 0x0161 )
>> ( 't' 0x0165 )
>> ( 'z' 0x017e ) ( 'C' 0x010c ) ( 'E' 0x011a )
>> ( 'D' 0x010e )
>> ( 'N' 0x0147 ) ( 'R' 0x0158 ) ( 'c' 0x010d )
>> ( 'e' 0x011b )
>> ( 'd' 0x010f ) ( 'n' 0x0148 ) ( 'r' 0x0159 )
>> ( 'U' 0x016e )
>> ( 'u' 0x016f )
>
> Hi Yuri,
>
> Do you happen to know if we currently support these Norwegian-only umlauts?
>
> For example written as "umlauts":
>
> å b̊ c̊
>
> Only the single-characters å and Å are of interest in the Norwegian
> language.
Looking at the share/vt/keymaps/no.kbd we don't, but if I understood you
correctly and only å/Å are required, it should be easy to add:
diff --git a/share/vt/keymaps/no.kbd
Re: buildworld failed after deleting /usr/obj
--- Original Message ---
On Monday, January 23rd, 2023 at 1:44 PM, qroxana
wrote:
> --- Original Message ---
> On Monday, January 23rd, 2023 at 10:02 AM, Dimitry Andric d...@freebsd.org
> wrote:
>
>
>
> > On 23 Jan 2023, at 04:05, qroxana qrox...@protonmail.com wrote:
> >
> > > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.
> > >
> > > --- all_subdir_usr.bin ---
> > > --- objwarn ---
> > > Warning: Object directory not changed from original
> > > /usr/src/usr.bin/clang/llvm-objcopy
> >
> > This is usually an indication that your source directory contains object
> > files, e.g. is "dirty". Run "make clean" from the top level, or clean up
> > your source checkout with something like "git clean".
> >
> > -Dimitry
>
>
> I had tried it with a clean source directory and empty /usr/obj
>
> # find /usr/src/usr.bin/clang/llvm-objcopy
> /usr/src/usr.bin/clang/llvm-objcopy
> /usr/src/usr.bin/clang/llvm-objcopy/llvm-objcopy.1
> /usr/src/usr.bin/clang/llvm-objcopy/Makefile
>
> and "make buildworld" still ended with the same error.
>
> In /usr/src/Makefile.inc1, the _NO_INCLUDE_COMPILERMK=t option prevents
> creating
> the obj directories for the stuff in usr.bin/clang/.
>
> 1098 _obj:
> 1099 @echo
> 1100 @echo "--"
> 1101 @echo ">>> stage 2.2: rebuilding the object tree"
>
> 1102 @echo "--"
> 1103 ${+}cd ${.CURDIR}; ${WMAKE} _NO_INCLUDE_COMPILERMK=t obj
>
> > --- all_subdir_usr.bin ---
> > --- objwarn ---
> > Warning: Object directory not changed from original
> > /usr/src/usr.bin/clang/llvm-objcopy
>
>
> This happens in stage 4.4, and there's no ${MAKEOBJDIR} directory created
> for usr.bin/clang/llvm-objcopy
>
It appears buildworld doesn't create the obj directory for
usr.bin/clang/llvm-objcopy in stage 2.2 after this commit.
commit adc3c128c6603054586a993d117e5dd808deac17
Author: John Baldwin
AuthorDate: Fri Nov 18 20:12:28 2022 -0800
Commit: John Baldwin
CommitDate: Fri Nov 18 20:12:28 2022 -0800
src.opts.mk: Require C++20 for C++ support.
libc++ requires C++20, so mark C++ (MK_CXX) as broken if the compiler
does not support C++20.
Reviewed by:emaste
Differential Revision: https://reviews.freebsd.org/D36893
diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk
index f69208f21556..5089a034350d 100644
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -348,6 +348,11 @@ __DEFAULT_YES_OPTIONS+=OPENMP
__DEFAULT_NO_OPTIONS+=OPENMP
.endif
+# libc++ requires C++20
+.if !${COMPILER_FEATURES:Mc++20}
+BROKEN_OPTIONS+=CXX
+.endif
+
.include
#
Re: vt and keyboard accents
On 1/29/23 09:48, Yuri wrote:
Hans Petter Selasky wrote:
On 1/29/23 01:54, Yuri wrote:
Looking into an issue with accents input for vt and cz (so
/usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
working and other result weird unrelated characters output.
Checking kbdcontrol -d output, there is an obvious difference with
keymap contents -- all mappings are trimmed down to 1 byte after reading:
kbdcontrol:
dacu 180 ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
( 'y' 253 )
keymap:
dacu 0xb4 ( 0xb4 0xb4 ) ( 'S' 0x015a ) ( 'Z' 0x0179 )
( 's' 0x015b )
( 'z' 0x017a ) ( 'R' 0x0154 ) ( 'A' 0xc1 )
( 'L' 0x0139 )
( 'C' 0x0106 ) ( 'E' 0xc9 ) ( 'I' 0xcd )
( 'N' 0x0143 )
( 'O' 0xd3 ) ( 'U' 0xda ) ( 'Y' 0xdd )
( 'r' 0x0155 )
( 'a' 0xe1 ) ( 'l' 0x013a ) ( 'c' 0x0107 )
( 'e' 0xe9 )
( 'i' 0xed ) ( 'n' 0x0144 ) ( 'o' 0xf3 )
( 'u' 0xfa )
( 'y' 0xfd )
Source of the problem is the following definition in sys/sys/kbio.h:
struct acc_t {
u_char accchar;
u_char map[NUM_ACCENTCHARS][2];
};
While the keymaps were converted to have the unicode characters for vt
in the commit below, the array to store them (map) was missed, or was
there a reason for this?
---
commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
Author: Stefan Eßer
Date: Sun Aug 17 19:54:21 2014 +
Attempt at converting the SYSCONS keymaps to Unicode for use with
NEWCONS.
I have spent many hours comparing source and destination formats,
and hope
to have caught the most severe conversion errors.
---
I have tried the following patch and it allows me to enter all accents
documented in the keymap, though I must admit I'm not sure it does not
have hidden issues:
diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
index 7f17bda76c5..fffeb63e226 100644
--- a/sys/sys/kbio.h
+++ b/sys/sys/kbio.h
@@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
struct acc_t {
u_char accchar;
- u_char map[NUM_ACCENTCHARS][2];
+ int map[NUM_ACCENTCHARS][2];
};
Hi,
Using "int" for unicode characters is probably good for now. Your patch
looks good, but please also consider the "umlaut" case while at it
(multiple characters that become one)!
I think umlauts are already part of "accents" (duml keyword), e.g. in
cz.kbd:
duml 0xa8( 0xa8 0xa8) ( 'A'0xc4) ( 'E'0xcb)
( 'O'0xd6)
( 'U'0xdc) ( 'a'0xe4) ( 'e'0xeb)
( 'o'0xf6)
( 'u'0xfc)
So pressing Alt+Shift and "=/+" key, and then pressing one of AEOUaeou
keys would produce ÄËÖÜäëöü, respectively, and it currently works as all
of the ÄËÖÜäëöü characters can be written as single-byte unicode.
And the following dcar (that is, "caron") characters are all broken as
they need at least 2 bytes, pressing Shift and "=/+" key, and any of the
LSTZlstzCEDNRcednrUu would print nothing at all, produce garbage, or
print some control character (last byte only):
dcar 0x02c7 ( 0x02c7 0x02c7 ) ( 'L'0x013d ) ( 'S'0x0160 )
( 'T'0x0164 )
( 'Z'0x017d ) ( 'l'0x013e ) ( 's'0x0161 )
( 't'0x0165 )
( 'z'0x017e ) ( 'C'0x010c ) ( 'E'0x011a )
( 'D'0x010e )
( 'N'0x0147 ) ( 'R'0x0158 ) ( 'c'0x010d )
( 'e'0x011b )
( 'd'0x010f ) ( 'n'0x0148 ) ( 'r'0x0159 )
( 'U'0x016e )
( 'u'0x016f )
Hi Yuri,
Do you happen to know if we currently support these Norwegian-only umlauts?
For example written as "umlauts":
å b̊ c̊
Only the single-characters å and Å are of interest in the Norwegian
language.
--HPS
Re: poudriere jail -u: install: …: No such file or directory (was: install: wdatwd.4.gz: No such file or directory)
On 18/01/2023 07:49, Graham Perrin wrote: … install -N /usr/src/etc -o root -g wheel -m 444 ERR_put_error.3.gz /usr/local/poudriere/jails/main/usr/share/openssl/man/man3/ --- realinstall_subdir_sbin --- install: mntopts.3.gz: No such file or directory --- realinstall_subdir_secure --- make[3]: stopped in /usr/src --- realinstall_subdir_sbin --- make[3]: stopped in /usr/src make[2]: stopped in /usr/src 166.55 real 56.12 user 25.21 sys *** [installworld] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src make: stopped in /usr/src [00:03:38] Error:Failed to 'make installworld' root@mowa219-gjp4-8570p-freebsd:~ # I realised the cause of the main (CURRENT) jail failing to update from /usr/src: WITHOUT_MANCOMPRESS= in /etc/src.conf OpenPGP_signature Description: OpenPGP digital signature
Re: vt and keyboard accents
Hans Petter Selasky wrote:
> On 1/29/23 01:54, Yuri wrote:
>> Looking into an issue with accents input for vt and cz (so
>> /usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
>> working and other result weird unrelated characters output.
>>
>> Checking kbdcontrol -d output, there is an obvious difference with
>> keymap contents -- all mappings are trimmed down to 1 byte after reading:
>>
>> kbdcontrol:
>> dacu 180 ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
>> ( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
>> ( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
>> ( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
>> ( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
>> ( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
>> ( 'y' 253 )
>>
>> keymap:
>> dacu 0xb4 ( 0xb4 0xb4 ) ( 'S' 0x015a ) ( 'Z' 0x0179 )
>> ( 's' 0x015b )
>> ( 'z' 0x017a ) ( 'R' 0x0154 ) ( 'A' 0xc1 )
>> ( 'L' 0x0139 )
>> ( 'C' 0x0106 ) ( 'E' 0xc9 ) ( 'I' 0xcd )
>> ( 'N' 0x0143 )
>> ( 'O' 0xd3 ) ( 'U' 0xda ) ( 'Y' 0xdd )
>> ( 'r' 0x0155 )
>> ( 'a' 0xe1 ) ( 'l' 0x013a ) ( 'c' 0x0107 )
>> ( 'e' 0xe9 )
>> ( 'i' 0xed ) ( 'n' 0x0144 ) ( 'o' 0xf3 )
>> ( 'u' 0xfa )
>> ( 'y' 0xfd )
>>
>> Source of the problem is the following definition in sys/sys/kbio.h:
>>
>> struct acc_t {
>> u_char accchar;
>> u_char map[NUM_ACCENTCHARS][2];
>> };
>>
>> While the keymaps were converted to have the unicode characters for vt
>> in the commit below, the array to store them (map) was missed, or was
>> there a reason for this?
>>
>> ---
>> commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
>> Author: Stefan Eßer
>> Date: Sun Aug 17 19:54:21 2014 +
>>
>> Attempt at converting the SYSCONS keymaps to Unicode for use with
>> NEWCONS.
>> I have spent many hours comparing source and destination formats,
>> and hope
>> to have caught the most severe conversion errors.
>> ---
>>
>> I have tried the following patch and it allows me to enter all accents
>> documented in the keymap, though I must admit I'm not sure it does not
>> have hidden issues:
>>
>> diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
>> index 7f17bda76c5..fffeb63e226 100644
>> --- a/sys/sys/kbio.h
>> +++ b/sys/sys/kbio.h
>> @@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
>>
>> struct acc_t {
>> u_char accchar;
>> - u_char map[NUM_ACCENTCHARS][2];
>> + int map[NUM_ACCENTCHARS][2];
>> };
>>
>
> Hi,
>
> Using "int" for unicode characters is probably good for now. Your patch
> looks good, but please also consider the "umlaut" case while at it
> (multiple characters that become one)!
I think umlauts are already part of "accents" (duml keyword), e.g. in
cz.kbd:
duml 0xa8( 0xa8 0xa8) ( 'A'0xc4) ( 'E'0xcb)
( 'O'0xd6)
( 'U'0xdc) ( 'a'0xe4) ( 'e'0xeb)
( 'o'0xf6)
( 'u'0xfc)
So pressing Alt+Shift and "=/+" key, and then pressing one of AEOUaeou
keys would produce ÄËÖÜäëöü, respectively, and it currently works as all
of the ÄËÖÜäëöü characters can be written as single-byte unicode.
And the following dcar (that is, "caron") characters are all broken as
they need at least 2 bytes, pressing Shift and "=/+" key, and any of the
LSTZlstzCEDNRcednrUu would print nothing at all, produce garbage, or
print some control character (last byte only):
dcar 0x02c7 ( 0x02c7 0x02c7 ) ( 'L'0x013d ) ( 'S'0x0160 )
( 'T'0x0164 )
( 'Z'0x017d ) ( 'l'0x013e ) ( 's'0x0161 )
( 't'0x0165 )
( 'z'0x017e ) ( 'C'0x010c ) ( 'E'0x011a )
( 'D'0x010e )
( 'N'0x0147 ) ( 'R'0x0158 ) ( 'c'0x010d )
( 'e'0x011b )
( 'd'0x010f ) ( 'n'0x0148 ) ( 'r'0x0159 )
( 'U'0x016e )
( 'u'0x016f )
