I committed the patch to make RabbitMQ compatible with Elixir 1.9.0 (D20781). Hopefully this will unblock the work on this update.

Ok, the last patch worked: Poudriere is happy, RabbitMQ CI is happy, I'm happy, everyone is happy!

Apparently, mix(1) now uses $XDG_CONFIG_HOME and $XDG_DATA_HOME variables, before $HOME, to determine its own directory. Poudriere also explicitly set them, which defeats our workaround. Again, I adapted our CI and will prepare another workaround.

The RabbitMQ CI is green again, but Poudriere is still unhappy. Investigating...

Ok, setting $HOME on the Make command line in CI is enough to reproduce the failure. I can now work on the workaround.

There is a copy of the cache in the source archive. RabbitMQ's Makefile messes with $HOME in particular to point mix(1) to that copy.

I see the failure in Poudriere and I now understand the problem: Poudriere sets $HOME in the environment and as a Make variable. And setting it as a Make variable defeats my brilliant hack to convince mix(1) it has everything locally already. This is something we don't do in the RabbitMQ CI. I will add that right away so our test environment is closer to package builders' one.

Trying to reproduce inside Poudriere (with the Elixir update patch from this review + RabbitMQ patch to accept Elixir 1.9.0). I will keep you posted.

To be exact, it does have network but no DNS configured. So far, it was enough to catch any issue with the source archive missing some bits.

I couldn't reproduce the issue. I added Elixir 1.9.0 in the RabbitMQ packaging CI to make sure we catch that error, but so far it succeeds.

I suppose RabbitMQ is compiled offline like in Poudriere in your case?

I suppose the int2float() function comes from one of the removed file, is that right? If yes, could you please add a comment indicating the initial source filename?

Yes, I confirm the patch is working for me. I'm using both the internal keyboard of the laptop and a USB keyboard (also connected to that laptop when at my desk).

I tested (poudriere testport) a similar patch to lang/rust on 10.4 and 11.1, both amd64 and i386, and it works.

I was about to test a similar change during the week-end and that's what OpenBSD does (the maintainer is quite active in the Rust community). So yes, let's try that!

I didn't test it yet but this looks good to me.

In D16206#343725, @jrm wrote:

There must have been package fallout from this? Let's wait until we hear back from @dumbbell.

Already committed in rP474363.

Here is a bit of feedback after nearly a month: the system is stable with only the evdev_set_flag(evdev, EVDEV_FLAG_LOCKLESS); line in kbdmux commented out.

One callout per window, plus flushing all windows twice per second is probably inefficient, on top of a vt(4) which is already slower than syscons(4).