jperkin

jperkin, 9 days ago to llvm

So unfortunately #LLVM 17 has hit #pkgsrc, which means I need to turn off support for the full LLVM suite in #clang on #illumos

We offered to provide build hosts and maintain support, but upstream weren't interested, and removed all of the code.

Given it was working absolutely fine, this is a real shame. Especially as I spent a significant chunk of time getting it working.

It'll now have to go back to depending on GCC's libstdc++, and I'll work on avoiding dependencies on clang where I can.

jperkin, 14 days ago to random

Recent changes in pkgsrc broke many packages 😭.

I took it upon myself to fix the mess, and ended up falling down a rabbit hole of ncurses support, with cruft going back 25 years.

I've proposed a bunch of fixes, including merging the ncurses and ncursesw packages, as well as making the ncursesw API the default (similar to what FreeBSD and others have done).

Interested to hear of potential issues, especially with older software. Will be testing it thoroughly!

https://github.com/NetBSD/pkgsrc/compare/trunk...TritonDataCenter:pkgsrc:review/ncurses-rework

#pkgsrc

jperkin, 17 days ago to programming

We're hiring!

https://www.mnxsolutions.com/careers/senior-backend-developer

Come and help us maintain and enhance a fully open-source operating system and cloud stack that has been battle-tested in very large production environments.

There are plenty of interesting problems to solve, all the way from writing device drivers and debugging early boot issues, to writing new UIs in Rust.

I think we're a pretty friendly team to work alongside too ;)

Happy to answer any questions.

#SmartOS #illumos #nodejs #rust #DTrace #pkgsrc

jperkin, 28 days ago to macos

For anyone using my macOS binary package repository, I've switched to building against MacOSX12.3.sdk.

Build results look good, and over 24,000 packages are available for both arm64 and x86_64.

Full details on why I had to change, and how to switch to the new repository, are in my post to pkgsrc-users:

https://mail-index.netbsd.org/pkgsrc-users/2024/04/19/msg039367.html

The 11.3 repository will no longer be updated, but will remain available for anyone unable to upgrade past Big Sur.

Any problems, let me know!

#macos #pkgsrc #pkgin

jperkin, 1 month ago to random

Joyent's DNS has finally been turned off, so if for some reason you were still using pkgsrc.joyent.com for the past few years, you definitely need to switch over to pkgsrc.smartos.org.

jperkin, 2 months ago to random

Speaking of GCC, does anyone know of any lawful impediment why I may not drop gccgo from my GCC packages?

Feels like something that hasn't been necessary since 2013.

#illumos #gcc #go

jperkin, 2 months ago to running

It was that kind of run today.

5th at #parkrun though! Ok, so there was hardly anyone there because the weather was atrocious, but still, I'll take it 😁

#running #ultrarunning

jperkin, 3 months ago to random

Pondering removing these identifiers from <iso/ctype_iso.h> in my build sandboxes:

#define _U 0x00000001
#define _L 0x00000002
#define _N 0x00000004
#define _S 0x00000008
#define _P 0x00000010
#define _C 0x00000020
#define _B 0x00000040
#define _X 0x00000080

Software authors don't respect namespace rules, and I have to patch around them every so often.

If anyone wants a trivial but tedious #illumos bug to work on, rename them to CTYPE* like the BSDs.

jperkin, 5 months ago to ipv6

I have many, many issues with #IPv6, but at least there was always the confidence that the address space was never going to run out, because nobody would be dumb enough to repeat the mistakes learned from IPv4 allocation, right?

https://whois.arin.net/rest/net/NET6-2630-2

Oh.

jperkin, 5 months ago to random

I've always tried to ship the most robust #pkgsrc packages I possibly can, with a whole suite of checks to avoid releasing packages that link against unregistered libraries.

So I was pretty embarrassed when @Neirac discovered our nodejs packages were somehow not depending on libiconv correctly.

Turns out to be a pretty thorny problem, which I've tried to summarise here:

http://mail-index.netbsd.org/tech-pkg/2023/11/24/msg028516.html

For now I've enhanced the checks in our fork, and tightened up our GCC specs. Still more to do.

jperkin, 6 months ago to random

Compiler folks!

Let's say I'm using _Float16 on a system which doesn't support FP16.

If I compile it directly to a program then libgcc does its thing and __extendhfdf2 etc is pulled in transparently. All good.

If I compile it as a shared library, it is not, and I have to add -lgcc manually to avoid undefined symbols.

Is this expected behaviour? If not, where should I start looking?

Thanks!

#gcc

jperkin, 7 months ago to random

Today I learned Speculative Tracing in #DTrace to help narrow down a bug in #Unbound 1.18.0 on #illumos

https://github.com/NLnetLabs/unbound/issues/945#issuecomment-1744835397

Definitely adding that to my toolkit for next time. Was only after spending a number of hours code reading and writing manual probes to try and figure out where the EINVAL was bubbling up from.

Would be great if we had a repository somewhere of D scripts to cover a huge range of analysis areas, and help folks bootstrap themselves into writing their own.

jperkin, 8 months ago to random

That feeling of dread when you need to patch some golang software because a dependency has incorrect OS assumptions.

In a reasonable language it's a one or two line change.

In golang I have to make modified copies of files, patch others to exclude the build for that OS, fight with upstreams to get patches accepted then wait 3 years for downstream software to update their dependencies, and then fight with go.mod and go.sum patches to get a forked version used in the meantime.

So very tiring.

jperkin, 8 months ago to random

It's a pity that Mastodon lacks quote tweets, but in addition to the post I boosted yesterday, I just wanted to say my own thanks for #DTrace reaching 20.

I use it all the time, and struggle when working on other systems that do not have it. Only yesterday I wrote a quick script to verify a code path that lead to this fix: https://github.com/NetBSD/pkgsrc/commit/def71d1c1f988e3a2cf3bb86716a2937ce6f48fc.

It has found significant performance wins in #pkgsrc and #pkgin, fixed numerous bugs, and helped me understand systems.

Thanks @bcantrill and @ahl!

revk, 8 months ago to random

FFS

jperkin, 9 months ago to random

As part of my recent #pkgin work I came across another optimisation for "pkg_admin rebuild-tree" using #DTrace that makes it a further 12x faster on my test system.

http://mail-index.netbsd.org/tech-pkg/2023/08/07/msg027952.html

This is in addition to the 13x speedup I committed a few years ago:

https://gist.github.com/jperkin/98550d5bd07f4179ebfeea825fc3ec20

Reviews appreciated. #pkgsrc #netbsd

jperkin, 1 year ago to random

Those of you who use my #pkgsrc trunk repositories for #illumos #macos #netbsd etc may notice a change during your next "pkgin upgrade".

pkg_install will no longer print script messages for packages that are being refreshed or upgraded.

This avoids confusion where the deinstall script may tell you it is ok to remove certain files, despite them still being required after upgrade.

The output should be a lot cleaner, errors more visible, and no more confusing messages or duplicated output.