#redo — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #redo, aggregated by home.social.
-
I'm not idle, by the way. I've resurrected an old project that was a C++ preprocessor that generates redo files, which I once mentioned on Hacker News, and am bringing it up to date.
The fun part is that *of course* it eats its own dog-food. Its own build system uses redo, and it uses itself, once built, to re-generate its redo files. So every re-build is a clean and re-build from scratch when it isn't working, and every test is first-off to build it twice. (-:
-
Decided to bite the bullet and do the 15hr rover rear-end print again. Im not makering today but itll be ready after this round of workys
#3dprinting
#redo-redo -
Sooo for those not hinging on my every post for the last..ohh.. 8 months..lol
This is what Im rebuilding.
The black thing is a web cam. It streams back to a cell phone and is controlled by wireless xboxish controller.I had it going but ran it off a counter and busted it up. Ive also got some lower torque motors to try for better rolling control..
(to be continued) -
Ok, I think just I found my obsession for the next few days : ** redo ** [1,2]
It has a very simple (yet powerful) approach to the build system problems.
The question is now : how can I abuse it to describe and run my experiments workflows ? 😈
[1] Original post : https://cr.yp.to/redo.html
[2] Reimplementation but with nice documentation / discussion : https://redo.readthedocs.io/en/latest/ -
Excellent.
Yes, the latest released versions are supposed to be a version behind the actual development source. I freeze the source, do a binaries release, and start a new development version.
So #redo latest binary release is 1.5, and #nosh is 1.41.
#djbwares is at version 12, with version 13 under development. I must have forgotten to update the WWW page.
-
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 -
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.
-
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.
-
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.
-
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.
-
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. (-:
-
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.
-
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.
-
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. (-:)
#djbwares 10 is next.
-
-
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. (-:
-
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.
-
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.
-
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.
-
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.
-
As implied, the #NetBSD port of #nosh, #redo, and #djbwares is pretty much done.
NetBSD doesn't make it as easy to switch between process 1 programs as FreeBSD does, so the system manager is not tested. But many of the other tools from tai64nlocal, cyclog, and setterm; through login-envuidgid and envdir; to the service manager and console-tty37-viewer; have now been used in earnest.
There are known missing bits in #ifconfig and list-process-table. And UVT realizers are not tested at all yet.
-
The not-very-secret GOPHER server is well on its way to being back up; and those of you who know GOPHER will soon be able to get the latest development source snapshots of #nosh 1.41 and #djbwares 10 again.
*Of course* it is a machine running those self-same nosh and djbwares to serve up GOPHER et al.. The last one ran #OpenBSD. This one is running #NetBSD, hence the recent porting work.
It's not in its intended location yet. But it is facing the Internet now.
-
I've been talking about things coming in the next versions of #djbwares, #nosh, and #redo. You're probably wondering when, since COVID and Brexit and other things created a quintuple limbo.
There's a big hurdle of getting a Linux build machine, which has sat with a faulty DASD for some years, back up and running.
But there's a plan, and it's in motion.
One step is the not-very-secret GOPHER server with the development source snapshots coming back up.
-
This was not supposed to be when I was doing #NetBSD adjustments to #redo, #nosh, and #djbwares at all. That was supposed to be on the *next* #RaspberryPi.
This was *supposed* to be the point at which I checked that the #OpenBSD parts of the code, untested since before COVID Lockdown, still worked.
(There are a lot of changes in 1.41.)
This was *supposed* to be getting me a vanilla Pi in a non-fancy case running #OpenBSD, nosh, and djbwares; sitting in a corner quietly.
NetBSD, now.
-
The second attempt — coming soon — thus has promise. The errors were mainly the holes in the code that I'd left ready inside if defined(__NetBSD__) blocks, and hadn't coded for how NetBSD does things. I am from that experience expecting few problems with building #djbwares .
I'm doing half-hour-long backups at stages during the installation process, this time.
