the one thing that beats a Jet2 holiday (episode 2)

Hello.

It's been a minute since mid-June when BSDCan in Ottawa and FreeBSD Kitchener–Waterloo Hackathon happened. It's been an even longer minute since my last episode of open source despatches, so welcome to episode 2.

Too much has happened, and I can't really remember all the details either. So I will cut to the chase: this episode is low-key sponsored by BSDCan (thank youse!) and the people are awaiting a recap of sorts, particularly of conference operation things, from my slice of it all.

BSDCan 2025

I got a very late start to my drive to Ottawa from northeast PA (Pennsylvania) on Tuesday. So late that I missed out on the Goat BOF, which is essentially a pregame to the rest of the conference week. Always great to catch up with the regulars, some who I only get to see once a year around this time, and meet new charactersfolks and bring them into the fold in a relaxed setting. I blame emergency house work that needed done since it would be two weeks before I returned. At least the border crossing at dark o'clock was painless and the late night donair poutine slapped.

After only a couple hours of sleepnaptime and a short-as-in-exactly-one-bus-ride-from-the-airbnb-to-almost-directly-in-front-of-the-venue commute, the FreeBSD Developer Summit, co-hosted at and before the regular BSDCan conference, was on. I get inside Desmarais Building on the University of Ottawa campus, into the main lecture hall where the devsummit had already started, to find the audio/video crew in the usual spot in the very back.

This year, after my programme on DJing and music production on FreeBSD at the main conference last year, I was slyly voluntold to help out with the A/V, which I obliged since it's fun, the fundamentals are nothing new to me and Andrew and Patrick can use the consistent help. This is the crew that gets all the programmes live-streamed for those who cannot make it in-person and recorded for future reference on video sharing platforms n dat. Apart from setup and teardown at the beginning and end of each day, much of the work involves making sure the wireless microphones for the presenter and audience work properly and their levels set appropriately, cameras behaving themselves and pointed in the correct direction, and flipping between scenes to give presenter, slides or the BSDCan Screen of Deathcommercial break equal or greater emphasis.

For the devsummit duration, there was only one room to mind, the main room, as the tutorials happening concurrently in the other rooms the conference booked are not streamed or recorded. Once the main conference hit on Friday, we had to staff each room, rotating amongst ourselves as needed depending on which programmes we wanted to catch for ourselves and other reasons.

The goal is to get the streamed footage good enough, not only for those watching live, but also such that Andrew and Patrick have to do as little post-processing and editing as possible for the video postings. Here is the result from when I handled Olivier's (olce@FreeBSD) programme seen above:

Secondarily, hang out on IRC and other chat platforms so those heckling from afar can also join in on the fun and more importantly ask the hard-hitting questions.

After securing all the equipment in locked rooms, we and a bunch more headed to Father & Son's, a bar directly across the street from campus and where the Goat BOF happened, for dinner and drinks. Needed my smoked meat poutine fix.

Ended up being my only foray there all week, especially since a particular Irish character was so dearly missed that a fellow conference attendee made a joke obituary slide. Hopefully we will get to see and hang with him at EuroBSDCon in September.

The hacker lounge, especially after dinner, is always a nice feature of BSDCan and other BSD conferences. It was less populated than previous years however. We must be getting old.

Saturday was more of the same in terms of operations. As there are other recaps of BSDCan floating around on the internets, I will spare youse content about the programmes. Over lunch I got to check into an amateur radio net back in the States using my American callsign with proper Canadian suffix, with Diane (db@FreeBSD) as a bonus station under her Canadian callsign. Obviously we had to sync about ham radio stuff in FreeBSD/ports. We got a new committer in the fold too!

The closing session and especially the auction are always a highlight. Always make sure you keep your important stuff with you, otherwise you may have to bid for it back! However certain items like a $20 CAD banknote are perenially auctioned off because lore.

The aforementioned Patrick was announced as next year's conference chair. That means we A/V people will need more help next year, since Patrick will be juggling so much more in that role. For now, good yard. To the closing reception (after packing everything up)!

One conference attendee, and now FreeBSD committer, wanted to celebrate his 21st birthday (even though the drinking age in Ontario is 19) so a few of us went out quite a bit longer.

In Philly, this would constitute a citywide special, but the can of PBR is too big.

In previous years, there would be a group who went to brunch at Father & Sons on Sunday morning, where their breakfast special can't be beat, but for some reason it seemed that people were in a hurry to get out of Ottawa this year. Sadge. I did manage to find Michael Dexter and we got brunch at Cora. Somehow we ran into a couple other conference folks just leaving.

What is Dexter's significance you may ask? He is probably the one most responsible for getting the monies needed to make this, and other BSD conferences and initiatives, happen. So make sure to thank the hell outta him.

FreeBSD Kitchener–Waterloo Hackathon

After some abbreviated exploring of Ottawa, I started making my way down to Kitchener–Waterloo for the post-conference hackathon. A few of us spend another week in the same place getting stuff done and having fun with one another. Details to come in the next episode since it will get more technical-technical after all. For now, have a shot of my drive on a not-congested Highway 401 through Toronto:

club dispatch (episode 1)

writing during yet more FreeBSD port builds must be a theme innit

I also happen to be in my local transit agency's dispatch office writing most of this. Yes, I sometimes dispatch buses, usually for night service so it's often chill enough to do other things whilst maintaining watch. Don't worry, shit does hit the fan sometimes, which means I get to be first to get remedies or corrective action moving. Yes I get monies for this, but more importantly gets me out of the house when I otherwise don't have plans for the week, particularly social or scheming for world domination.

Anyway, here is another episode of…open source despatches.

DJ-BSD

Technically my hardware setup was complete during the drawn-out writing process of the last episode, but I had no idea what I was doing. I still don't know what I'm doing, but at least I figured out how to beatmatch two easier-to-me tracks by ear, after the last episode dropped. Wait, what?!

"day zero posterity pic"

Yes, I am indeed learning how to DJ. Despite the computer monitor's presence, it is and will not be used to display audio waveforms like CDJs and controllers/software do. I think phonograph records and turntables are the purest form of this art, even if dialing up digital tracks for the timecode record to control.

So far I've started amassing my first crate of records and playing around with them. Genres for now are all 140-bpm grime and dubstep (specifically not the brostep branch). Once I set up my mixer, the last hardware to arrive, I attempted to mix two grime tracks together (as shown in the pic, if you know you know) and it was an epic fail. Then I tried one grime one dubstep, later both dubstep, even later almost indiscriminately selecting anything that would make sense, all to no avail. First attempts in learning.

I eventually realised that I needed to isolate some percussive element on the downbeat ("the one"). In many electronically-produced genres, following a 4/4 time signature, this would be a snare. With grime, percussive elements are all over the place, vocals included. In dubstep, the snare usually falls on the three, but there are less percussive elements overall so it is easier to pick something. So a few days later, I dialed up two dubstep tracks on the turntables and focused on the kicks starting from the bass drop. DJ Rob Swift, a longtime hip-hop turntablist, calls this "building a relationship". After a couple tries, I had the two tracks synced, so rinse and repeat those exact two a few more times to make sure I really had them. Luck would have it that these two tracks were at the same bpm so no pitch adjustments needed, but if I dropped the second track just a bit off, I would have to nudge the second record forward or touch the platter ever so slightly. It's fun when you start to get it in this manner, even with needed adjustments.

If this was on a controller or CDJ, the former of which would have been much easier on the wallet, I would have gotten up to speed a bit more quickly but with some bad habits in tow. Looking at waveforms to beatmatch would be like using a debugger on a problem program without fully understanding program architecture and control outside of specific code segments. Beatmatching by ear, ie "building a relationship", is exactly that, building a relationship with your program from a total lifecycle standpoint before diving into code at all.

I still need to practise matching before or without any bass drops, because sometimes I do want the intros heard in the mix. I also still haven't fired up Mixxx, the open source DJ program, to enable playing with my timecode records and thus control my digital tracks. We'll see how it behaves with my setup on FreeBSD. To this end, I'll turn it over to an old SEPTA slogan:

i don't think the gift shop has these to sell

DankPad omissions and update

I forgor to mention that the DankPad does have on-board wifi. In fact, ThinkPad X13 users get a random selection between three different M.2 wireless cards, none of which I believe work in FreeBSD as of this writing. My machine has the Qualcomm QCNFA765, which on Linux is driven by ath11k(4). Some machines get an Intel AX-series card, which is iwlwifi(4) territory. On FreeBSD, our home-grown iwm(4) driver supports Intel cards up to the AC-series, but anything newer uses iwlwifi(4). Our grand total of one (funded) FreeBSD committer working on wireless support started porting some Linux drivers over along with improving our LinuxKPI in our kernel, but some things are just incomplete:

ath11k_pci0: <ath11k_pci> mem 0xfd000000-0xfd1fffff at device 0.0 on pci3
ath11k_pci0: MSI vectors: 32
ath11k_pci0: wcn6855 hw2.0
linuxkpi_mhi_register_controller: XXX-BZ TODO

At some point I would like to help out in this effort. Funding would be nice too, since this is a hard but lucrative-outside-of-FreeBSD problem space. Let's not forget that I attempted to start porting not one but two Linux Realtek wireless drivers, one for the meme machine's built-in wifi and other for a TP-Link USB 3 dongle, but I stumbled over how to write a new Makefile with the existing C sources. I should build a relationship in that area before thinking about bigger things…

In the meantime my wireless needs are met by another TP-Link USB 2.0 dongle driven by rtwn_usb(4). Ethernet is through a USB 3.0 hub with a ure(4)-driven device at the end.

As for my suspend saga, the "Linux" sleep state, ie S3, BIOS option was the correct one. Our copy of ACPICA does not support S0ix so of course the `hw.acpi.suspend_state` sysctl came up empty when set to "Windows". With S3, the system suspends fine, but resuming is a different story: when I perform the actions in the X graphical environment, the AMD graphics hang the entire system on resume. I should be fine when I suspend in the console, which I have had to do on the other ThinkPad when I change monitor configurations, but again let's see what happens.

setuptools reduction act

I finally committed the setuptools-scm update discussed last time, after slightly tweaking my poudriere (port build automation) setup on the HP air fryer to add a separate environment for build verification runs. There is still some minor cleanup to do, because some Python packages have still not adopted PEP 517, and the latest setuptools-scm only officially works with setuptools versions that exclusively support the PEP 517 method…

…which brings me to why this section title.

tl;dr a long and winding history exists. For those ports still using the old method, direct setup.py execution, setuptools is a build dependency but also a run dependency. The latter part, in a blanket sense, is wrong. The only reason why setuptools would be a run dependency outside of a Python package build context is when the package uses the included pkg_resources, which itself is deprecated and replaced by other modules. Further, setuptools itself deprecated direct setup.py execution in version 58 and unsupported after, so all ports using this method will eventually specify setuptools 58 specifically. Two setuptools versions cannot exist in the same environment, at least not in the same Python distribution as they call it. The work is cut out twofold: an experimental build run to see how all ports using direct setup.py execution behave after removing the setuptools run dependency at the framework level, and finding individual ports that explicitly specify the setuptools run dependency.

More Will Be Revealed

open source despatches, dankpad edition (episode 0)

Whilst I wait for my complete FreeBSD Ports rebuild to finishIn typical vishwin fashion where I let the post rot before I muster effort to finish writing, I introduce, hopefully, an excuse to write on this blog more regularly. And not in a New Year's resolution manner, because many of us know how well those go…

Welcome to Open Source Despatches, where I try to talk about not-the-most-public happenings in my open source world. As in, not formal releases, not public comments on bug trackers, patch submissions, etc. But maybe some of the public-facing stuff gets included for context.

Before I continue with this first episode, I think we need to address the elephant in the roomcabin: what the hell is a DankPad?

The DankPad

The DankPad is my colloquial name for my new-to-me ThinkPad X13 Gen 2 AMD. Not sorry to disappoint.

my active ThinkPad fleet as of Winter Field Day: W550s on left, X13 Gen 2 AMD (DankPad) on right

My ThinkPad W550s has been my primary machine through thick and thin since 2015. However, despite being a certified Ultrabook (ie thin-and-light, laugh out loud), the 15-inch form factor has gotten more cumbersome to carry around when I need to do so. Even with the machine this one replaced, I have always had a need for a smaller form factor secondary machine to both carry around and distribute processing loads. Thin doesn't cut it; the other dimensions matter more.

In 2022, Micro Center apparently got a boatload, spread across all their stores, of Evolve III Maestro netbooks (you read that right), initially retailing at $89 but later dropping to $59 a pop. At least within my circles, JonathanD jumped on early in the year to see how far he could go with them, particularly with running Linux and amateur radio applications. He eventually reported in two blog posts, but the initial vibes over IRC were good enough that jedijf got a fleet to play, break, learn.

Field Day comes around, he brings his entire Evolve fleet (amongst all the other stuff he brings) and invites me to get FreeBSD running on one.

trying to remember how to manually ZFS-on-root on a flash drive before Field Day ended

It's one thing to run an operating system from a removable disk (big up Damn Small Linux, my first Linux distribution I ever used), it's another to run from the internal disk, or in the Evolve's case, the 4 GB eMMC.

get in bitches, we're going to the toy store

I officially had to call this the meme laptop when I brought it around. See how far I could go with FreeBSD on it, which resulted in a wiki page. All for $59.

the early stages of getting Cinnamon set up

Fast forward to September 2023 (IRC log dated 18 October 2023):

[08:18:25] <vishwin> welp looks like my evolve is properly dead
[08:18:37] <vishwin> "incurable" boot looping...
[08:44:37] <JonathanD> :(
[08:54:25] <vishwin> jawn won't stay on past a few seconds, power
button doesn't take any input, just powers itself on and off anymore
[09:02:20] * waltman pours one out
[09:02:46] <waltman> vishwin: Fortunately you can switch over to
one of the other 5 you bought, right? :)
[09:03:28] <JonathanD> all mine are still going strong.
[09:04:36] <waltman> Having it die right before OKT POTA is
unfortunate.
[09:04:42] <vishwin> it was actually dead last month

I sure as hell got my meme's worth of $59 outta that jawn. However, that made me down a small form factor machine, so back to just the W550s, again, cumbersome to carry around too often (and I was bringing it around a lot during the intervening period).

January 2024 comes around and I see a good deal on a refurbished X13 Gen 2 AMD. Low key, I'd been waiting for an opportunity to acquire an AMD machine, especially a Ryzen. Done.

eventually the stickers are getting transferred over

It is a little bigger at 13 inches compared to the Evolve's 11.6 inches, but this is practically a rounding error. Did I mention this is my first AMD machine in…12 years?

getting here took longer than it should have

The DankPad came with some Chinese no-name 256 GB NVMe SSD pre-loaded with Windows 10. I knew this would be insufficient capacity for the ZFS boot environments and other crap like source code I would load on here, especially considering this only takes a single internal disk, so the first order of business was to install a higher capacity SSD. But I needed to have the machine in hand to buy the correct new SSD, so that took a few days after I received the machine and built my first FreeBSD images for it. In the meantime, I attempted to put FreeBSD on the "stock" SSD, multiple times, to errors on first boot. I guess Windows stuff wasn't completely blown away from that SSD, but no harm no foul considering the new SSD. However, this did confirm that only UEFI boot on GPT works; all legacy MBR-based boot is off the table. Don't bother setting up both on the disk, you'd be wasting space.

This is also the first machine I own with a graphical BIOS. I guess nothing new for x86 machines released this decade, as all the Dell Optiplex 7010s I imaged for a now-completed contract had graphical BIOSes, but my last owned machine vintage is 2015 (the W550s). In the BIOS, there is a sleep state option, set to "Windows" by default but has a "Linux" option. Apparently these are bad labelling for selecting the warm suspend state presented to the operating system: "Windows" is S0ix whereas "Linux" is S3. Even though FreeBSD-CURRENT gets ACPICA updates into the base system fairly regularly, we still don't support S0ix. We don't even support S4 (hibernate) "unless S4BIOS is available" according to acpi(4). Need to play around with this a bit more, when I can carve some time when I don't need stuff running on it, but in the meantime no warm suspend for now. (The meme laptop never warm suspended under my tutelage.)

Built-in sound output generally works. Dolby Audio speaker system, however, Laugh Out Loud. Built-in microphone audio input is dodgy at best, even after adjusting mixer(8) and other userspace utilities from Ports. Built-in webcam doesn't appear to work with webcamd, at least derived from the Linux kernel version webcamd is on. No Discord voice/video calls with this machine anytime soon, unless I connect (supported) USB webcams and audio inputs. hselasky@ did all the work with webcamd and other USB class devices, but unfortunately he became another tragic victim of 2023; may he rest in peace.

Otherwise the DankPad is a major upgrade from the meme laptop and a great addition to my fleet. Zen 3 Ryzen has been worth every bit of money I dropped on it. I could use this to build all my ports and then some if I didn't already have an HP air fryer (HP ProLiant DL380 gen 7) for this role, but I do build the FreeBSD base system for this machine on this machine. With 12 threads, the first time building an entire world (everything but the kernel, configure files in /etc and release media/images) took 4060 seconds. In comparison, the HP air fryer took 3336 seconds with 24 threads and a few more LLVM machine targets. Only about a ten-minute difference which is impressive.

FreeBSD ports behind the scene

This is the part where I try to shed some light on why certain things I work on in FreeBSD Ports seem like they can take forever for no reason.

First, I'm actually being slowed down, erm crippled, by another large undertaking in the tree: mass realignment of man page locations. Because the package interiors have changed, we need to bump the revision number, as shown:

[00:00:11] Deleting libidn-1.38.pkg: new version: 1.38_1
[00:00:13] Deleting lynx-2.8.9.1_1,1.pkg: missing dependency: libidn-1.38

The revision number bumping doesn't seem like a big deal, but when your package dependency metadata consist of all = instead of >=, everything that depends on the bumped package has to get rebuilt just to "correct" the metadata. For some heavy ports, this means the whole hog gets recompiled and such. Port Makefiles hardly have this kind of specificity; only the resulting package metadata end up like this. There is work in progress (not by me) to relax this. But in the meantime, every little bump can be costly on productivity, so I try to take every precaution to avoid them, until package metadata is relaxed.

One casualty from this and general tree churn is getting setuptools-scm updated. Not only updated, but the official name changed ever so slightly to use a hyphen rather than an underscore (both are equivalent in Python package metadata), so good to ensure we follow suit. Every so often, gotta rebase these changes on top of the tree as other stuff gets committed. Then everything has to get tested for build breakages at the very least.

Two more things are still being dogfooded: libxml2 2.12 and webkitgtk 2.42. The latter requires a change in our base system's copy and configuration of the libc++ API in order to build at all, let alone run. Otherwise, much of the work consisted of consolidating into one port three flavours depending on library combinations. Meanwhile libxml2 2.12 introduced some major API breakages even with a configure option, to be enabled in the port by default, to enable parts of the legacy API. Before getting there, still need to test an update to a consumer, libxslt, to make sure it behaves with the current libxml version in our tree (I don't see any obvious problems but this could be a jinx). After that I will offer the libxml2 update for wider testing.

any final words?

That's it for now. This post is long enough as it is, brain dumping without any coherency whatsoever. Plus this has been delayed for time. Some choice happenings, details and flames were omitted since I want to be done with this one already, but…more will be revealed.