
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Okay. I’d like to make a dport when I’ve got some insight into why my last attempt to go to master failed. </div><div><br></div><div>Since then, I’ve reimaged one of my HAMMER drives to a GPT layout (instead of the results of a raw `newfs_hammer /dev/serno/WWZABTRY` which wrote an fdisk label for a 8tib partition — `fdisk` on the other fdisk formatted drives complains about it being an invalid label as the end offset exceeds 2TiB lol). I think this is the likely issue as my hammer2 GPT root drive worked fine but couldn’t recognize the partition map for the MBR formatted hammer drives. I’m only able to do this because I’ve PFS mirroring between my data drives so rebuilding one is doable.</div><div><br></div><div>If I can get a master userland/kernel built, then a reboot with the new kernel will reveal if it really is that (as opposed to something else breaking which would be worse and requiring help from a developer to gather WTF is wrong…)</div><div><br></div>I bumped my src to latest master today - it added two commits.<div><br></div><div>However I’m getting a build failure. I’m going to try the following steps to see if I can get an actionable *something*.</div><div><br></div><div>1. Remove MAKEOBJDIRPREFIX, try build</div><div>2. Reset master to HEAD~2, try build </div><div><br></div><div>Autumn</div><div><br></div><div>Build failure 1:</div><div>$ sudo -H git -C /usr/src switch master</div><div>$ sudo -H git -C /usr/src pull</div><div>$ sudo -H git -C /usr/src rev-parse HEAD</div><div>447e693def340f0816784a1567986dda486bb2f9</div><div>$ sudo -H cp /usr/src/sys/config/X86_64_GENERIC /usr/src/sys/config/NYX</div><div>$ sudo -H make -C /usr/src MAKEOBJDIRPREFIX=/usr/obj/master KERNCONF=NYX build-all</div><div>… /snip</div><div><div>--- grep_stub.c ---</div><div>make[6]: don't know how to make /usr/src/gnu/usr.bin/grep/libgreputils/libgreputils.a. Stop</div><div><br></div><div>make[6]: stopped making "exe" in /usr/src/initrd/rescue</div><div>*** Error code 2</div><div><br></div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><blockquote type="cite"><br>On Mar 1, 2026, at 2:17 PM, Aaron LI <aly@aaronly.me> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><blockquote type="cite">On Mar 2, 2026, at 04:08, Autumn Jolitz <autumn.jolitz@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">I was able to compile Python 3.14 just now. It took some finagling.</div></blockquote><blockquote type="cite"><div dir="ltr"><div><br></div><div>I’ve added a patch for getting process memory usage.</div></div></blockquote><div><br></div>Cool. I suggest you open a PR to <a href="https://github.com/DragonFlyBSD/DeltaPorts">https://github.com/DragonFlyBSD/DeltaPorts</a> to include it. Or best submit to the upstream :)<div><br><blockquote type="cite"><div dir="ltr"><div>I would have liked to do this on dragonfly/master instead of dragonfly/6_4_RELEASE but the latest kernel doesn’t seem to recognize disklabels for MBR formatted SATA drives.</div></div></blockquote><div><br></div>What was the error? Could you provide the steps to reproduce it? It would be a serious problem and I’ll have to look into it.</div><div><br></div><div>Thank you.</div><div><br></div><div>Aaron</div><div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=us-ascii"><div></div></div></blockquote></div></div></blockquote></div></div></body></html>