#Redo Architects https://ift.tt/CoOcAnX | posted by afasia | daily entries on contemporary art and architecture #afasiaarchzine #afasiaarq |

#architecture #arquitectura #design

Bairro Padre Cruz Market Hall . Lisbon Redo Architects The renovation o…

Ack. I didn't rinse the top of my coffee mug out well enough, apparently, and it tastes like fucking soap.
#REDO

@JdeBP I can confirm that redo-1.5, djbwares-11, and nosh-1.41 build packages just fine on both #FreeBSD 13.5 and 14.3.

Build logs on 14.3 in case you end up spotting something interesting:

- redo-1.5: https://gist.github.com/ermo/98d627c15c7768e16c42d460356bbd7e
- djbwares-11: https://gist.github.com/ermo/238af242324aabca481bb9ebd37e1ff4
- nosh-1.41: https://gist.github.com/ermo/166ecefe1599104e668cf7dafd833263

#redo #djbwares #nosh

@ermo

That may well be useful.

#redo version 1.2 (sic!) is in the #FreeBSD ports tree. I was just talking to @schmonz about the state of that port and how I have no real way to let the person behind it know that it's in very poor shape.

Neither #djbwares nor #nosh are in the FreeBSD ports tree. Presumably there are people working on ports, but that one of them was a decade ago an undergraduate on the other side of the planet shows the kind of barriers in place here.

@schmonz @lukeshu

I actually looked for contact details for Po-Chuan Hsieh, for the FreeBSD port, so that I could let xem know how messed up that port was; as I noted before. But there's only a wildly (a decade) out of date LinkedIn listing and an opaque FreeBSD account.

The Parabola packaging of redo is several versions out of date, and has the pre-pre-Brexit URLs. Arch is on 1.4 at least but using the pre-Brexit URLs.

I don't even know about Void, Hyperbola, et al.

#redo #djbwares #nosh

@schmonz @lukeshu

I think that you possibly hadn't noticed before because it wasn't NetBSD; but now I've ported all three of #redo, #djbwares, and #nosh to NetBSD (testing on a non-amd64 architecture, no less!), as you've probably seen over the past few months. So now there's a system for building #NetBSD packages alongside Debian's, FreeBSD's, and OpenBSD's.

@schmonz @lukeshu

It has always been capable of building its own packages, by the way. (And since it's slashpackage, one can by design just package/compile it self-contained and not do the subsequent packaging step.)

https://jdebp.uk/FGA/slashpackage.html#OSPackaging

It's not a Debian thing. Quite the opposite. For a long time no-one packaged any of this at all, so I made packages for people myself. Even now, no-one at all packages djbwares and there is only one that packages nosh.

#redo

@schmonz @lukeshu

I'm curious how knowledge of the 1.5 source archive even reached any packagers.

That was not listed on the WWW pages at all but only on a GOPHER site that's explicitly for people to get bonus content such as access to in-development source, and comes with an explicit warning in the GOPHER menu.

The published source archives listed on the WWW, as well as the GitHub snapshot, were still at 1.4. I had only just ticked them over to 1.5 when I sent that nudge out. (-:

#redo

@ermo

I'm doing #djbwares 10 next; right now, in fact (although I need to make a trip to the shops).

When I put it out, that's a good intermediate step to try next. It will test that you have a working redo without being a massive build that builds hundreds of things (as is the case for nosh).

It has the same basic command workflow as for building redo. There's a new accompanying Guide that details building from source but there aren't any real surprises over building #redo.

@ermo

That's possibly a good approach with 1.41, until I sort out the #GhostBSD machine.

You can take the first step in trying it again, right now. #redo version 1.5 is out.

(Ignore the one in ports. Whoever is in charge of that hasn't made it past version 1.2 and is still using a WWW site that preceded the WWW site that I lost to Brexit half a decade ago.)

As you can see from package/debian/control it has a build dependency upon perl; but I think that that and base are all that you need.

@lukeshu

You're the only name in the log. (-:

https://git.parabola.nu/abslibre.git/tree/pcr/jdebp-redo

I'm just giving the packagers (those that I know about and are easily contactable, at any rate) a tap on the shoulder before the rest of the world explicitly learns that #redo 1.5 is up.

https://jdebp.uk/Softwares/redo/

(Po-Chuan Hsieh of #FreeBSD is still using a URL that has not worked since Brexit. 17 million people voted that I should not have my domain name. (-:)

@schmonz

#djbwares 10 is next.

tick.

#redo

Right.

I've got Debian and FreeBSD systems with both the system and service manager running things, and a NetBSD system with just the service manager; all of the services under service management; a sprinkling of many of the #djbwares services running, including regular clock synchronization with sntpclock, dnscache, and tinydns private roots; and my test HP USB 104-key keyboard auto-connecting to the #uservt system when plugged in.

I'm running out of release blockers. (-:

#nosh #redo

My little login.conf(5) shim is working nicely on Debian Linux.

login.conf(5) is one of the things that #FreeBSD (and to a lesser extent #NetBSD) does better than Debian.

I'm testing the stuff on #Debian as I mentioned a few days ago. It is going fairly well so far. I'm now at the point of setting up some #djbwares services.

#nosh #redo

The new battery is now in, but of course the machine is now powered up and doing stuff.

It is a "Plattboj" from #Ikea, best before 2023 according to the blister pack. So I probably have a rude surprise waiting the next time that I power the machine off. (-:

I *could* publish the new #redo right now, as building #djbwares and #nosh with it has given it a fairly thorough test on Debian. Not that there was much scope for it going wrong given that it was already working on FreeBSD and NetBSD.

The good news is that with only a modicum of tweaking the long-pending new versions of #nosh, #djbwares, and #redo build on Debian Linux.

The bad news is now I have to do a lot of testing.

And I still haven't fixed the build machine's battery.

So whilst it is powered off because of the excessively hot weather, it has lost all of its firmware settings and has gone back to 2012 again. (-:

The partition that wouldn't clone contained the compiler and operating system, so alas there's going to be a jump in operating system support.

Fortunately, I already did the work of fixing old DJB K&R code to eliminate all of the warnings (from a 2024 compiler) that K&R C syntax will be going away when 2023 rolls around, when porting to #NetBSD. So using an updated compiler should not be too much of a problem.

#nosh #djbwares #redo

Slowly I progress.

I've managed to clone most of the disc of the broken Linux build machine, and after a number of false starts (We are past the Age of DUET, it turns out.) have got the build machine booting with some replacement hardware.

It still needs a new NVRAM battery and is complaining about a "221" memory error, so I'm not out of the woods, yet,

But things are creeping towards getting the new #nosh, #redo, and #djbwares versions built.

#EFI #DUET

ok so i am trying to get wireguard working - it runs but i think it is the mangle/fwd/ nat in the fw? have to checks rules and chains and probably just try another client box to see if i can start to narrow down client or server side issues, before it mostly just worked #redo #rev3

There are some things around the edges as yet not implemented or tested. I haven't tested the uhid or ugen realizers yet. But #NetBSD looks the same as #FreeBSD in this regard, and I'm expecting that to be fairly trivial to fix if it just doesn't in fact work straightaway.

And there is still that known gap in the ifconfig command.

Nonetheless, this is a large part done of the porting of #nosh, #djbwares, and #redo not only to NetBSD but to a non-amd64 processor architecture too.