Re: blacklist -> blocklist in current

[Marc Balmer]

> Am 16.06.2020 um 04:53 schrieb Mayuresh :
> 
> On Mon, Jun 15, 2020 at 03:44:22PM -0400, Christos Zoulas wrote:
>> We should be all doing whatever we can to correct social/race/gender/sex
>> injustices/prejudices around us, and every little bit helps.
> 
> I am a great fan of bla^Hocklistd and I'd be happily using it even if you
> name it say timbuktud.
> 
> But I think we are stretching above argument a bit too far. By any stretch
> of imagination I couldn't find any trace of racist link in a very commonly
> used word in Comp Sc like blacklist. Even tried searching its origin[1]
> and doesn't look like it has anything to do with any race.
> 
> Just a quick grep in an arbitrary snapshot of the source tree of NetBSD
> shows the word 'black' appearing at 4146 places...
> 
> There are `blackholes', `blackballs', `blacklist' (other than in
> bla^Hocklistd's code), blackfin (of course some like this are not names
> chosen by NetBSD but of 3rd party hardware, such as a processor or a
> company name), `black magic', `blackjack', `blackboard', `blackbook',
> `blackbox', `blackcrow', `blackberry', `black cathedral', `black
> helicopter', `black tree' ...
> 
> And I am done only with 6% of the grep output.
> 

Well, obviously anything with the word black in it must be considered racist 
these days.

Re: blacklist -> blocklist in current

[Marc Balmer]

And you just do that based on you own opinion, without previous discussion, 
breaking existing confugurations, and all you have to offer is a „sorry for the 
inconvenience“?

That inconvenience was not needed and nobody asked for it.

> Am 15.06.2020 um 04:02 schrieb Christos Zoulas :
> 
> 
> Hello folks,
> 
> I've renamed blacklist to blocklist, so if you are currently using it,
> you should rename things accordingly:
> 
>- rc.conf variable
>- /var/db/blacklist.db file
>- npf table name
> 
> Apologies for the inconvenience,
> 
> christos

Re: blacklist -> blocklist in current

[Marc Balmer]

Maybe we should remove support for black-and-white (b/w) displays as well. Only 
supporting poc‘s, panels of color.

And, fortune -o, oh boy...

> Am 15.06.2020 um 20:05 schrieb Alexander Nasonov :
> 
> Christos Zoulas wrote:
>> 
>> Hello folks,
>> 
>> I've renamed blacklist to blocklist, so if you are currently using it,
>> you should rename things accordingly:
>> 
>>- rc.conf variable
>>- /var/db/blacklist.db file
>>- npf table name
>> 
>> Apologies for the inconvenience,
> 
> I doubt that you can express a concept of exclusion without offending
> anyone. E.g. the new term reminds me of blockades.
> 
> https://en.wikipedia.org/wiki/List_of_historical_blockades
> 
> -- 
> Alex

Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)

[Marc Balmer]

I would be very happy if a decision would be taken in a timely manner. I prefer 
git over mercurial, but any of them is better than cvs.



> Am 14.05.2020 um 17:27 schrieb Martin Husemann :
> 
> On Wed, May 13, 2020 at 09:16:31PM -0700, Greg A. Woods wrote:
>> I.e. the final repo DAG should contain all submitted commits, and all
>> that history should be visible to those who look for it (just as is the
>> case with merges from github "pull requests").
> 
> This is the case in our setup. In the "draft" phase you can revert,
> rewrite, collapse and change a few things, but in the end you have
> a line of changesets that on final push are made visible on the tip
> of the trunk (still as individual changes).
> 
> Martin

Re: github.com/NetBSD/src 5 days old?

[Marc Balmer]

> Am 28.04.2020 um 10:50 schrieb m...@netbsd.org :
> 
> On Tue, Apr 28, 2020 at 08:30:43AM +0200, Marc Balmer wrote:
>> 
>> 
>>> Am 28.04.2020 um 08:29 schrieb Andreas Gustafsson :
>>> 
>>> m...@netbsd.org wrote:
>>>> Yes, I believe joerg and spz are changing the conversion from
>>>> cvs->??->git to hg->git, to match what will be done once we stop using
>>>> CVS.
>>> 
>>> Has there been a formal decision choosing hg over git?
>> 
>> I am also interested in this.
>> 
>> 
> 
> This feels like a protest. Since it's addressing me, I'd like to point
> out I'm just letting people know why the conversion is down, and don't
> get any more of a say over things than others.

No, that was not to be understood as a protest, and addressing you personally 
was by mistake - I hit reply-to-all and did not check the adresses.

Well, this time it is not by mistake, as I intended to reply to you ;)

> As a reminder, hg/git offer far better interoperability (than CVS).
> Much of my own NetBSD work is done on Git, and even if I don't stop
> doing this, I would be happier if the backend was Mercurial.
> 
> The CVS->??->git conversion loses information on the parents of branch
> merges, so we carry a growing graft file, and it has to be adjusted
> whenever there's a forced push.
> 
> Having Mercurial at the back would eliminate ~all forced pushes and have
> real merge commits. Exporting the commits would require a lot less
> threats and custom scripts on current-users, because pushing is
> distinct from committing.

Thanks for your explanations.

Re: github.com/NetBSD/src 5 days old?

[Marc Balmer]

> Am 28.04.2020 um 08:29 schrieb Andreas Gustafsson :
> 
> m...@netbsd.org wrote:
>> Yes, I believe joerg and spz are changing the conversion from
>> cvs->??->git to hg->git, to match what will be done once we stop using
>> CVS.
> 
> Has there been a formal decision choosing hg over git?

I am also interested in this.

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[Marc Balmer]

> Am 19.11.2017 um 21:03 schrieb Andrew Cagney :
> 
> 
> 
> 
> On 19 November 2017 at 13:14, > wrote:
> I still think that we should remove offensive quotes, and if people
> cannot agree on it, all of fortune.
> 
> Don't confuse my interest in de-escalation with giving up.
> 
> Yes, remove.  Be it the file or the entire program.   NetBSD is technical.  
> If living in the past is your desire, start here: 
> http://www.tuhs.org/archive_sites.html 
> 
> 

We have become a sad spot on the planet...

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[Marc Balmer]

> Am 19.11.2017 um 16:44 schrieb Joerg Sonnenberger :
> 
> On Sun, Nov 19, 2017 at 10:04:41AM -0500, William D. Jones wrote:
>>> Seriously, if you don't know who Hitler was and why quotes from him
>>> should be seen
>> in a certain perspective, you should take a lesson on modern world
>> history and not run around being offended.
>> 
>> It's not about being offended, it's about normalizing/trivializing his
>> impact. Evidence: Clearly, little thought was put into whether
>> these quotes belong in a silly Unix program, rather than history textbooks
>> or museums which are equipped to temper the
>> intended impact of the Nazi party.
> 
> As has been said elsewhere in this thread already: a lot of the behavior
> of Adolf Hitler was quite normal or at least calculated to be normal.
> There is no trivialisation going on here. While I can't stand his
> choice in the tonal sense, he was a brilliant orator and there are many
> useful quotes from him. Heck, he is often found on the list of most
> inspirational quotes. If anything, there should be more and better
> quotes from him in the database.


„Wollt Ihr den totalen Krieg?“

  — Hitler, Adolf (probably when first introduced to systemd)

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[Marc Balmer]

> Am 19.11.2017 um 19:01 schrieb co...@sdf.org:
> 
> I had the commit message written out and everything.
> I'm not sure why we have such a lengthy discussion about a game.
> 
> If we care so much about games, I'm gonna plug my pkgsrc games wishlist:
> https://github.com/SuperV1234/SSVOpenHexagon
> https://github.com/ppy/osu
> 
> They should be really good.

Ok. Can we we now have the Adolf Hitler quotes back?  Or did xtos already take 
care of that?

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[Marc Balmer]

> Am 19.11.2017 um 18:33 schrieb co...@sdf.org:
> 
> On Sun, Nov 19, 2017 at 05:58:12PM +0100, Marc Balmer wrote:
>> You should grow some balls.  Not in the biological sense, of course.
> 
> I did, that's why I went ahead and removed them. christos reverted my
> commit.

See.  He grew even more balls.  Your removal of that quotes was not very smart.

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[Marc Balmer]

> Am 19.11.2017 um 17:53 schrieb m...@netbsd.org:
> 
> The quotes I removed personally offend me. I assume I've done enough for
> netbsd to not be considered an evil outsider company who is here to
> spoil fun.
> 
> I'm not too excited to contribute to a project that insists on keeping
> a quote on how women should be stupid by a man who tried to exterminate
> my family.

You should grow some balls.  Not in the biological sense, of course.

Lua updated to version 5.3.1

[Marc Balmer]

Today I updated Lua in NetBSD -current to version 5.3.1.  If you use Lua, 
please let me know of any regressions you run into (ideally with patch to fix 
the issue...).  Of course I hope there are none...

Re: [patch] give gpioctl.c some love

[Marc Balmer]

Am 22.08.15 um 02:22 schrieb Timo Buhrmester:

 I was troubleshooting a GPIO problem and came across 
 usr.sbin/gpioctl/gpioctl.c. The code is well-written, but I figured it needs 
 some love, readability-wise.  It uses unnecessarily deep nesting while trying 
 to stay witin 80 characters per line at tabstop 8; I refactored parts of it 
 to eliminate that problem (maintaining the 80-colums invariant, of course).
 
 Apart from that, a few other things were changed here and there:
  - const correctness
  - meaningful prototypes
  - avoidance of redundancies
  - fix (and isolate) converting a string to `unsigned` (it errorneously 
 accepted some negative values before, and didn't zero/restore errno (not that 
 it has restore, but it certainly is good manners to do)
  - declutter main() a bit
 
 Overall, a patch that removes (slightly) more lines than it adds, so it must 
 be good, no? :)
 I'll inline it here for easier commenting, if there are objections.

as the original author of gpioctl I add my comments inline  I am
mostly against this patch, but to make it clear:  that is not against
you, but against the patch ;)

Imo, this patch does not solve a problem, but creates new ones, maybe...
 The constness that you sprinkle is definitely not needed, only makes
the code cluttered imo.


 
 
 Cheers,
 
 Timo Buhrmester
 
 P.S.: gpioctl's functionality or behavior is not changed, apart from the 
 integer parsing issue (a missing `lval  0`)
 
 
 --8-
 
 --- usr.sbin/gpioctl/gpioctl.c.orig
 +++ usr.sbin/gpioctl/gpioctl.c
 @@ -36,17 +36,21 @@
  #include string.h
  #include unistd.h
  
 -static char *dev;
 +static const char *dev;
  static int devfd = -1;
  static int quiet = 0;
  static int state = 0;
  
  static void getinfo(void);
 -static void gpioread(int, char *);
 -static void gpiowrite(int, char *, int);
 -static void gpioset(int pin, char *name, int flags, char *alias);
 -static void gpiounset(int pin, char *name);
 -static void devattach(char *, int, uint32_t, uint32_t);
 +static void gpioread(int pin, const char *gp_name);
 +static void gpiowrite(int pin, const char *gp_name, int value);
 +static void gpioset(int pin, const char *name, int flags, const char *alias);
 +static void gpiounset(int pin, const char *name);
 +
 +static unsigned get_uint_or_die(const char *str, const char *name);
 +static void devattach(const char *driver, const char *offset,
 +const char *mask, const char *flags);
 +

This is wrong.  We don't use variable names in function prototypes for
good reason.

  __dead static void usage(void);
  
  static const struct bitstr {
 @@ -67,19 +71,14 @@ static const struct bitstr {
   { 0, NULL },
  };
  
 +

What does it gain you to add an empty line here?

  int
  main(int argc, char *argv[])
  {
   const struct bitstr *bs;
   int pin, ch, n, fl = 0, value = 0;
   const char *errstr;
 - char *ep;
 - int ga_offset = -1;
 - uint32_t ga_mask = 0;
 - uint32_t ga_flags = 0;
 - long lval;
   char *nam = NULL;
 - char *flags;
   char devn[32];
  
   while ((ch = getopt(argc, argv, qs)) != -1)
 @@ -115,84 +114,54 @@ main(int argc, char *argv[])
   }
  
   if (!strcmp(argv[1], attach)) {
 - char *driver, *offset, *mask;
 -
   if (argc != 5  argc != 6)
   usage();
  
 - driver = argv[2];
 - offset = argv[3];
 - mask = argv[4];
 - flags = argc == 6 ? argv[5] : NULL;
 -
 - ga_offset = strtonum(offset, 0, INT_MAX, errstr);
 - if (errstr)
 - errx(EXIT_FAILURE, offset is %s: %s, errstr, offset);
 - lval = strtol(mask, ep, 0);
 - if (*mask == '\0' || *ep != '\0')
 - errx(EXIT_FAILURE, invalid mask (not a number));
 - if ((errno == ERANGE  (lval == LONG_MAX
 - || lval == LONG_MIN)) || (unsigned long)lval  UINT_MAX)
 - errx(EXIT_FAILURE, mask out of range);
 - ga_mask = lval;
 - if (flags != NULL) {
 - lval = strtol(flags, ep, 0);
 - if (*flags == '\0' || *ep != '\0')
 - errx(EXIT_FAILURE,
 - invalid flag locator (not a number));
 - if ((errno == ERANGE  (lval == LONG_MAX
 - || lval == LONG_MIN))
 - || (unsigned long)lval  UINT_MAX)
 - errx(EXIT_FAILURE, flag locator out of range);
 -
 - ga_flags = lval;
 - }
 - devattach(driver, ga_offset, ga_mask, ga_flags);
 + devattach(argv[2], argv[3], argv[4], argv[5]);
 +
   return EXIT_SUCCESS;
 - } else {
 - char *nm = NULL;
 -
 - /* expecting a pin number or name */
 - pin = 

Re: [patch] give gpioctl.c some love

[Marc Balmer]

Am 22.08.15 um 11:20 schrieb Felix Deichmann:
 Am 22.08.2015 um 10:15 schrieb Marc Balmer:
 Imo, this patch does not solve a problem, but creates new ones, maybe...
   The constness that you sprinkle is definitely not needed, only makes
 the code cluttered imo.
 
 This constness is mainly adding pointers to const in function
 arguments and for strings. Some will consider this good style to say the
 least (MISRA, CERT C Coding Standard), and some even claim it will allow
 for better compiler optimization.

I agree for libraries, but not for tools where such functions are only
used internally.  And only that some committees consider sth good style
does not mandate that I use it.

The code is perfectly valid as is and there is no need for such changes.

 
 CERT has for example:
 DCL00-C. Const-qualify immutable objects
 DCL13-C. Declare function parameters that are pointers to values not
 changed by the function as const
 STR05-C. Use pointers to const when referring to string literals
 STR30-C. Do not attempt to modify string literals
 etc.
 
 Regards,
 Felix

Re: Fwd: snprintf?

[Marc Balmer]

Am 08.06.15 um 18:24 schrieb Andrew Cagney:
 FYI, want a bug report?

I think this is best handled on the Lua mailing list.

 
 -- Forwarded message --
 From: Andrew Cagney andrew.cag...@gmail.com
 Date: 8 June 2015 at 12:22
 Subject: snprintf?
 To: lu...@lists.lua.org
 
 
 Hi,
 
 I just found a bug in an embedded port of lua which didn't support
 sprintf().  Specifically, the work-around:
 
 #define sprintf(s,fmt,...)  snprintf(s, sizeof(s), fmt, __VA_ARGS__)
 
 is broken.  Consider correct code such as:
 
 char *b = ...; sprintf(b, %d, 1);
 
 found in lstrlib.c.
 
 This, however, begs the question: should lua switch to snprintf()?
 
 First, I don't think anyone will dispute that snprintf() is more
 robust than sprintf().  Rather, the problem is with portability.
 While snprintf() was formalized in c99, and almost all the C compilers
 have been supporting it since forever, there's been one holdout -
 Microsoft - they have had a somewhat recalcitrant attitude towards C
 standards compliance and, consequently, snprintf wasn't an option
 (Microsoft does have sprintf_s()  and _snprintf() but they have
 different semantics).
 http://en.cppreference.com/w/c/io/fprintf
 https://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.120%29.aspx
 
 However, recently we've been seeing something of a shift in
 Microsoft's attitude. Specifically Visual Studio 14/15 should support
 things like snprintf:
 http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx
 
 So I'd like to float the idea of adopting snprintf(), for instance:
 
 - just assume snprintf (which would require a very recent Microsoft C 
 compiler)
 
 - define Lsnprintf() as snprintf() and use that, except on old windows
 systems which can wrap _snprintf() and deal with the different
 semantics
 
 - define Lsnrintf() as snprintf() and use that, except on windows
 where it is re-defined as sprintf() (ignore the length parameter);
 this means things are no worse than what we have now
 
 Andrew
 

Re: Base lua gpio binding vs. pkgsrc lua extensions like lua-socket

[Marc Balmer]

Am 25.03.15 um 20:38 schrieb Martin Mersberger:
 Good afternoon,
 
 I'm playing around with my RPI running current and the gpio binding.
 Using the base lua(1), the gpio binding works really fine, but I also
 like to use the pkgsrc lua-socket extension. By default, the pkg has
 pkgsrc/lang/lua* as dependency and also installs into /usr/pkg.
 
 How would I stick it together to have a lua(1) environment having both,
 gpio binding and the socket extension? I've tried to adjust LUA_PATH and
 LUA_CPATH to make lua able to find the extensions, but it seems to have
 some incompatibilities:
 
 /usr/bin/lua: error loading module 'socket.core' from file
 '/usr/pkg/lib/lua/5.3/socket/core.so':
 /usr/pkg/lib/lua/5.3/socket/core.so: Undefined PLT symbol
 luaL_checkint (symnum = 49)
 
 
 Any ideas?

I could add my 'net' Lua module to NetBSD, which is superior to the
sockets module insofar as it is actively maintained, supports IPv6, and,
supports TLS.

Lua in base is Lua 5.3 btw, maybe the version from pkgsrc you are using
is different (.e.g 5.2)?

Re: Removing openldap?

[Marc Balmer]

Thomas,

 
 lukem imported openldap into NetBSD in 2008 and had big plans for
 working on it, but they didn't materialize; and as I understood him
 last weekend, he doesn't have these plans any longer. (Correct me if
 I'm wrong, Luke.)
 
 I think there is no particular need to have openldap in the base
 system; I don't see any particular integration, and it puts more
 burden of maintenance on us. I think that installing openldap from
 pkgsrc should be good enough.
 
 So I suggest removing it from the base system.
 
 Comments welcome!
 Thomas

I want to keep it in base, I use LDAP a lot, I was even about to commit a Lua 
LDAP binding.

Actually lukem and I are working on a project that could make heavy and good 
use of LDAP.

So please leave it in the tree, and I hereby volunteer to maintain it (client 
and server parts).

- Marc

EuroBSDCon 2014 submissions deadline extended until June 2nd, 2014

[Marc Balmer]

The deadline for submissions to the EuroBSDCon 2014 conference has
been extended until June 2nd 2014.

A number of high quality proposals for talks and tutorials have been
received by the program commitee already, but we have reason to
believe that there are potential authors out there who may just be too
busy at the moment or haven't heard about the opportunity to meet with
BSD-minded colleagues in Sofia in late September yet.

Remember the first rule of EuroBSDCon: You talk about EuroBSDCon.

So if you suspect somebody you know has not yet submitted a proposal
to submiss...@eurobsdcon.org but should, please remind them that the
June 2nd deadline will be final. At midnight CEST, no more proposals
will be entertained.

Please see the Call for Papers page, 
http://2014.eurobsdcon.org/calendar/call-for-papers/ for further guidance.

Looking forward to see you in Sofia.
On behalf of the EuroBSDCon 2014 program committee
Marc Balmer

Re: Running makemandb on every boot

[Marc Balmer]

Am 19.05.2014 um 01:31 schrieb David Brownlee a...@absd.org:

 Currently the system runs 'makemandb -Q' in the background on every boot. 
 This updates the apropos database (for 'man -k').
 
 On an system with an existing man database this will stat(2) every manpage 
 and update /var/db/man.db (an around 18MB sqlite database on a new amd64 
 system, maybe around 40MB on the same system with a reasonable selection of 
 packages)
 
 On a modern system rich in disk, memory and CPU this is unnoticeable. On a 
 slower system (mac68k, vax, embedded 486), this renders the system 
 effectively unusable for some time.
 
 Given that makemandb is run nightly and weekly by cron anyway, it would 
 probably be best for those systems to not have makemandb run on boot.
 
 My first thought would be to allow setting it in sysinst, with a per port - 
 default on for i386, amd64, modern (arm, powerpc, mips), off for others.
 
 What do people think?
 

What say does make sense to me.  I run several small machines and I also suffer 
from this effect.  Maybe the behaviour would better be defined in /etc/rc.conf 
(with sensible per-port default values)?

- mb

Re: evbarm and evbcf -current builds broken

[Marc Balmer]

Am 31.10.13 18:30, schrieb Dennis Ferguson:
 
 On 31 Oct, 2013, at 12:40 , Marc Balmer m...@msys.ch wrote:
 
 Am 30.10.13 20:36, schrieb Dennis Ferguson:

 On 29 Oct, 2013, at 22:38 , Dennis Ferguson dennis.c.fergu...@gmail.com 
 wrote:
 #   compile  lua/lua_tramp.o
 /build/beagle/obj/tooldir.NetBSD-6.99.24-amd64/bin/armv7--netbsdelf-eabihf-gcc
  -I/usr/src/common/include --sysroot=/build/beagle/obj/destdir.evbarm 
 -include /usr/src/sys/modules/lua/luaconf.h  
 -I/usr/src/sys/../external/mit/lua/dist/src -I/usr/src/common/include  
 -nostdinc -I. -I/usr/src/sys/modules/lua -isystem /usr/src/sys -isystem 
 /usr/src/sys/arch -isystem /usr/src/sys/../common/include -D_KERNEL -D_LKM 
 -D_MODULE -DSYSCTL_INCLUDE_DESCR -x assembler-with-cpp -clua_tramp.S
 ./arm/int_types.h: Assembler messages:
 ./arm/int_types.h:45: Error: bad instruction `typedef signed char __int8_t'
 ./arm/int_types.h:46: Error: bad instruction `typedef unsigned char 
 __uint8_t'

 This patch seems to fix the problem that arm builds are still having:

 Index: sys/modules/lua/Makefile
 ===
 RCS file: /cvsroot/src/sys/modules/lua/Makefile,v
 retrieving revision 1.1
 diff -u -r1.1 Makefile
 --- sys/modules/lua/Makefile16 Oct 2013 19:44:57 -  1.1
 +++ sys/modules/lua/Makefile30 Oct 2013 19:34:32 -
 @@ -42,7 +42,8 @@
strpbrk.c \
strspn.c

 -CPPFLAGS+= -include ${.CURDIR}/luaconf.h \
 -   -I${S}/../external/mit/lua/dist/src
 +CFLAGS+=   -include ${.CURDIR}/luaconf.h
 +
 +CPPFLAGS+= -I${S}/../external/mit/lua/dist/src

 .include bsd.kmodule.mk

 This works for the sys/modules/lua, thank you.  However, whith this
 patch applied it stops at the next module, luacore:

 dependall === sys/modules/luacore
 #   compile  luacore/luacore_tramp.o
 /usr/tools/bin/arm--netbsdelf-gcc -I/usr/src/common/include
 --sysroot=/usr/distrib/evbarm
 -I/usr/src/sys/../external/mit/lua/dist/src  -I/usr/src/sys/modules/lua
 -I/usr/src/common/include  -nostdinc -I. -I/usr/src/sys/modules/luacore
 -isystem /usr/src/sys -isystem /usr/src/sys/arch -isystem
 /usr/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE
 -DSYSCTL_INCLUDE_DESCR -x assembler-with-cpp -cluacore_tramp.S
 luacore_tramp.S: Assembler messages:
 luacore_tramp.S:2: Error: bad instruction `kmodtrampoline(lua_mod_register)'
 luacore_tramp.S:3: Error: bad instruction
 `kmodtrampoline(lua_mod_unregister)'
 luacore_tramp.S:4: Error: bad instruction `kmodtrampoline(memcpy)'

 etc.

 What's this trampoline stuff?
 
 With that patch my builds complete.  Maybe you need to try a clean build?  The
 KMODTROMPOLINE() thing is supposed to be expanded from the macro definition in
 machine/asm.h.

Indeed.  I cleared everything and the build seem to have finished.

Thanks for your patch, btw!

(and apologies for the inconvencience)

amd64 hangs during boot

[Marc Balmer]

Kernel from freshly built sources from this morning on amd64 hangs
during boot.

Last message:

xhci0: xhci_open addr 0 depth 0 port 0 speed 3

Lua manual pages

[Marc Balmer]

I just committed a man page gpio(3l) that documents the Lua binding to
access gpio(4) pins.  Since this is the first man page that describes a
Lua binding, and more have to come, I would be happy for some feedback
from Lua users.  Is the format useful or does it lack important information?

(Note that you have to update your system _and_ /etc/man.conf to be able
to view Lua man pages).