It looks like I'm going to break @schmonz's #pkgsrc patches, but in a good way.

It's looking like close to time to put #redo 1.6 out.

@kyonshi

Both nettle and and mbedtls3 are packaged in #pkgsrc. So it looks like the only things missing are pihole-FTL, which is probably fairly straightforward to package, and a version of that vast install shell script that doesn't have all of the wacky creating secret packages nonsense in it and just does the configuration parts. (pkgsrc itself can handle creating and depending from a pihole-meta package.)

#NetBSD

Enjoying my #NetBSD side quest, but did not spot a slicer in #pkgsrc. Any suggestions?

#pkgsrc on macOS continues to improve - I did a full rebuild of all of my packages (many with custom options) from the -current branch last week and had only 2-3 failures out of 500+ packages. Some packages that failed to build for me previously (eg, lang/ghc910) now build without issue. Very impressed.

For those looking for a gentle intro: https://pkgsrc.smartos.org/install-on-macos/

Today's rabbit hole:

* gitea broken due to sqlite.go update
* sqlite.go blocked by libsqlite3.go
* libsqlite3.go blocked by libc.go
* fix libc.go
* libsqlite3.go now blocked by upstream sqlite bug
* caused by "-Wl,-R" in shell scripts getting brace expanded when converted to tcl array

Turtles.

#pkgsrc #illumos

Hmm... #pkgsrc/audio/pavucontrol does not drawn properly by pkgsrc/wip/mesa-26. It emits DRI3 error storm.

@nafmo

The Xu #Debian #AlmquistShell now has a patch for ;& in case statements.

https://github.com/jdebp/slashpackage/blob/trunk/shells/dash-0.5.13.5-xu/package/patches/case_fall_through.patch

This is against the latest Xu version, so should be a fairly simple drop-in for everyone who builds from that, including #FreeBSD ports, #pkgsrc, and so forth.

I'm not entirely happy about the EV_EXIT flag interaction, and how -e is supposed to affect case fallthrough.

@mirabilos @rl_dane

Alt...

A terminal session in white on black. At the Xu Debian Almquist Shell prompt, first the read_os shell function is run, showing the PRETTY_NAME of the operating system to be Debian 13 (trixie). Then $DASH_VERSION is echoed, which is 0.5.13.5. Finally, a case statement making use of the now standardized ";&" clause terminator is entered. The output generated shows that it fell through from the clause where the pattern "t" matched, to the next clause down.

#pkgsrc/wip/mesa-26 works fine for me. pkgsrc/www/firefox-155.0.1 does not crash anymore when F11 key is pressed.

#pkgsrc/wip/mesa-26 works fine for my #NetBSD/amd64-current. pkgsrc/www/firefox does not crash anymore when F11 key is pressed.

I am trying #pkgsrc/wip/mesa again.

Looks like, with the great help of @AnachronistJohn , @abs0 and @jaypatelani , I switched my NetBSD system from using binary packages via pkgin to the pkgsrc and building packages from source

https://eugene-andrienko.com/2026-09-07-bsd-pkgsrc-ports.html

For now, it works and I'm able to have some packages in my system, with the necessary compile-time options. And only one version of Python interpreter installed, not two . Also removed a lot of unnecessary packages, so the disk space usage went down from 18 Gb to 17 Gb

#NetBSD #pkgsrc

@raster

Which package is it?

And have you ensured that the make that you are running is BSD make, not GNU make? (It does say bmake in the instructions, notice; but your posts said make and Debian.)

#pkgsrc #Debian #make #NetBSD

While I am a firm believer in using all available tools to improve the software I work on, I do really like that NetBSD's firm and unequivocal anti-LLM stance is proving popular, and helping it to gain traction.

To all the new users I'm seeing over the past few weeks, welcome! Hope we can help you get up and running.

#netbsd #pkgsrc

Hmm... #pkgsrc/wip/mesa causes many build failures. And they are not trivial.

My machine is building #pkgsrc packages with pkgsrc/wip/mesa. I want to check the crash when F11 key is pressed in pkgsrc/www/firefox window.

I have just updated #pkgsrc/www/epiphany to 50.6. It works without major problems under NetBSD...

Last night, I sneakily upgraded #pkgsrc to use Go 1.27 as default version.

And we already have the first package that won't build with older versions.

It seems that #pkgsrc/www/firefox-155 under #NetBSD/amd64-current has no major problems...

Toot from #pkgsrc/www/firefox-155.0rc1...

Right. I've done the same. I've been more forthright than the #pkgsrc people.

The #xmlto in #slashpackage here removes 'type' completely, gets rid of all of the other #Bashisms that I can find, uses sh as the interpreter, and in a modicum of testing (re-building the nosh manual set) works with dash on #Debian and the #FreeBSD and #NetBSD Almquist shells.

It also defaults the wwwbrowser configuration setting to www-browser (as used in Debian's alternatives system).

https://github.com/jdebp/slashpackage/tree/trunk/textutils/xmlto-0.0.29

@JdeBP #pkgsrc has a tendency to patch packages to depend on the system posix shell where viable, to avoid an unnecessary dependency on bash. This helps smaller systems in avoiding the build time and disk space for bash, and the scripts also tend to run faster.

It's less of an obvious win for normal systems, and can cause odd edge issues like you've described

BSD goo has been applied as somehow after recent #Pkgsrc builds, my VLC on #NetBSD can see media servers via DLNA. Yay.
Before I'd get "no driver pal" failures.

Alt...

Photo of VLC playing Daredevil on NetBSD 11.0.

Here's the #slashpackage for #Debian #dash 0.5.12.

As a bonus, I've added a small patch that sets up a DASH_VERSION variable and defaults PATH correctly (if unset) on #NetBSD, which neither Debian nor Xu dash actually do. If you know the #pkgsrc dash person, please let xem know.

https://github.com/jdebp/slashpackage/tree/trunk/shells/dash-0.5.12-debian

The Z, Korn, Bourne Again, and Watanabe shells all have similar xxSH_VERSION variables.

#AlmquistShell

@andrew_shadura

There's the one that you maintain, and there's the one from M. Xu directly that observably has very different code and does different things.

One of the observably different things is what got me here in the first place. Everyone non-Debian (e.g. Arch AUR, #OpenBSD, #FreeBSD, #pkgsrc) builds dash from Xu's dash source, and that has a bug.

One cannot reproduce, because of the different input.c (which doesn't even have that eof flag), this bug on the Debian dash.

@meluzzy

Finally, the end! I managed to replace binary packages from remote repo with some home-build packages from pkgsrc

#NetBSD #pkgsrc

Alt...

Output in the home server's console: 1.0.2nb2 => Creating binary package /usr/pkgsrc/packages/All/fail2ban-1.0.2nb2.tgz ===> Replacing for fail2ban-1.0.2nb2 ===> Updating using binary package of fail2ban-1.0.2nb2 /usr/bin/env /usr/pkg/sbin/pkg_add -K /usr/pkg/pkgdb -U -D /usr/pkgsrc/security/fail2ban/work/.packages/fail2ban-1.0.2nb2.tgzRR> Packaging fail2ban-1.0.2nb2 ===> Cleaning for fail2ban-1.0.2nb2 RR> Re-checking for unsafe installed packages (unsafe_depends_strict=YES) RR> Packages to rebuild: rr> MISMATCH_TODO=[] rr> REBUILD_TODO=[] rr> UNSAFE_TODO=[] RR> No more packages to replace; done. + fail2ban + munin-master + py312-numpydoc + py312-requests + py312-sphinx drag0n-server#

I have updated #pkgsrc/www/anubis to 1.27.0. It works behind cvsweb.NetBSD.org almost two weeks.

Hmm... I have completely forgotten to update #pkgsrc/www/anubis to 1.27.0. It stays in my CVS tree on the server...

Herbert Xu: No FediVerse account.

The listed #Debian people for the Debian #AlmquistShell are Gerrit Pape, who has been incommunicado for years, and @andrew_shadura.

However, this isn't a bug in the *Debian* dash, but in the Xu dash. It might become one if they bring the Debian source back into step with the original, though.

#FreeBSD port person is Bryan Drewery: no FediVerse account. #pkgsrc person Aleksey Cheusov: likewise.

Here's a patch, for the record:

https://github.com/jdebp/slashpackage/blob/trunk/shells/dash-0.5.13.5/package/patches/fleeting-terminal-eof.patch

I will update #pkgsrc/misc/screen to 5.0.2 later.

I want to commit the other changes in my local #pkgsrc tree. However I am exhausted...

I have just committed #pkgsrc/www/firefox-154.0.

Ok. These patches fix the build of #pkgsrc/mail/thuderbird-154.0 under #NetBSD.

Made a small PR towards Forgejo to allow its build on NetBSD (I found out that the pkgsrc-wip contributor is already working on packaging it, but was blocked) and illumos - as these are broken at the moment, in 16.x branch: pretty much dumb addition or removal of type cast to int64 in one particular module.

#Forgejo #illumos #NetBSD #pkgsrc

@jperkin I posted this topic to the #pkgsrc list, and saw 1 reply so far.

https://mail-index.netbsd.org/pkgsrc-users/2026/07/13/msg043194.html

2 packages to install:
p5-DBD-postgresql-3.14.2nb5 postgresql16-client-16.14

1 package to remove:
postgresql18-client-18.4

#Fail #PkgSrc
wrong direction...

#pkgsrc/wm/jwm under NetBSD/amd64 11.99.7 get frozen when pkgsrc/www/firefox plays some videos...

Hmm... It seems that the problem in #pkgsrc/lang/libjpeg-turbo has much simpler.

I can reporduce #pkgsrc/graphics/libjpeg-turbo under NetBSD/i386 11 sadly. https://releng.netbsd.org/pkgreports/shadow/HEAD/NetBSD-11.0-i386/20260811.1414/libjpeg-turbo-3.2.0nb2/build.log It seems that it has same problem as lang/nodejs.

@evgandr for managing #pkgsrc you might want to look at pkg_chk

It lets you define a list of packages, with optional tags so you can share the list across machines

You can then run pkg_chk -aks to: add all missing packages, keep going on errors, source build

pkg_chk -Br is an absolute chainsaw to remove all packages with mismatched build information

There are much more sophisticated ways to manage your packages (looking at "bob" here), but pkg_chk is a (painfully) simple way to start

Whew, I successfully updated my kitchen-server from NetBSD 10.1 to NetBSD 11.0 via the sysupgrade.

Now, I'm thinking about transforming this system, having a lot of binary packages from remote repository — to the system where each package is built locally via pkgsrc.

Since it is just a server, I don't see any problems with > 24h compile time of something like Rust of Librewolf
BTW, I didn't find an easy way (just launch one script and go to sleep) to convert the system from using remote built packages to the locally built packages
So, looks like I'll use some one-liner to get list of packages where build host != my server hostname. And then rebuild and update these packages with the help of pkgsrc.

#NetBSD #pkgsrc

Hmm... #pkgsrc/lang/nodejs24 under #NetBSD/i386 has another problem...

#pkgsrc/lang/nodejs24 may have similar problem. I will visit later.

The some major software discontinue 32-bit architecture support recently. It is sad for me... I am testing a patch for #pkgsrc/lang/nodejs now. It is required to build pkgsrc/www/firefox.

@leaf you can find me as leot on #pkgsrc at Libera.chat that's IRC, but I think there is a Matrix mirror as well.

Possible examples on my mind... Prometheus (net/prometheus)! I don't know how heavily is used NPM. Another possible way to do that, much easier, possibly persuade upstream to have all the UI as an artifact so we do not need any NPM. That's how it is done for Prometheus LTS (wip/prometheus-lts) (I think that one is only in pkgsrc-wip).

@alexshendi I posted about my patches to #pkgsrc/www/firefox-154 in my local tree. No one can read the code yet.

Toot from #pkgsrc/www/firefox-154.0b10 under #NetBSD/amd64 11.99.7.

My attempts for #pkgsrc/www/firefox-154 get progress and all C++ syntactic problems are solved. However my Makefile fragment is not perfect. I get undefined references from linker.