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

Avec la prise de position de #Debian et l'augmentation des prix chez #Hetzner (et tellement d'autres), je suis tellement tenté de migrer vers #NetBSD et https://www.netcup.com/en

Je vous me renseigner sur #pkgsrc https://www.netbsd.org/docs/pkgsrc/ :-D

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.

@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.

I should find a time to update #pkgsrc packages. I had spent many hours for MS-DOS programming and ia16-elf toolchain...

Excited to try this, have wanted a Rust alternative to ShellCheck for a long time now.

https://github.com/ewhauser/shuck

The main issue with ShellCheck is that the Haskell infrastructure in pkgsrc is sub-optimal, and it currently pulls in the full ghc as well as lots of hs-* dependencies.

This brings the total disk size required for a simple tool to 2.5GB(!), and a lot of additional downloads for every update.

~/.cargo/bin/shuck on the other hand is a much more reasonable 22MB.

#pkgsrc #rustlang

@wideshut Yep, I've been using #pkgsrc on macOS for about 20 years. @jperkin even provides binary packages these days - https://pkgsrc.smartos.org/install-on-macos/

はてなブログに投稿しました
NetBSD/amd64,i386 11.0 ておくれLive Image 20260809版 - tsutsuiの作業記録置き場
https://tsutsui.hatenablog.com/entry/teokure20260809

#はてなブログ #NetBSD #pkgsrc #mikutter

I've been working on some optimisations to bob's dynamic scheduler, which has resulted in a huge new personal best for a from-scratch pkgsrc bulk build:

Built 26943 in 17h 40m 23s (22688 succeeded, 0 cached, 2577 failed, 1678 skipped)

Not quite an apples-to-apples comparison as I've been using a slower host but with more cores, but previously this was taking just under 24 hours.

#pkgsrc #bob

If you're running the SmartOS trunk package set, then ensure you have the latest pkg tools installed:

$ pkg_add -U pkg_install pkgin

This will help avoid a potential issue I discovered when upgrading a host that hadn't been updated for a long time:

https://smartos.topicbox.com/groups/smartos-discuss/Tdc4610e7190947a4/heads-up-potential-upgrade-issues-from-old-pkg-tools

For now I've only published the "tools" set, I'll hold off a bit before publishing the main x86_64 set to ensure everyone is ready.

Apologies if you hit this. The modern versions are a lot more robust.

#pkgsrc #smartos

A nice little usability improvement coming in the next version of bob: you can specify a dewey pattern for commands that accepts a package match, e.g.:

$ ./target/debug/bob history -o pkgname,outcome,duration 'nodejs>22<26'
PKGNAME OUTCOME DURATION
nodejs-24.15.0 failed 6m34s
nodejs-22.22.2 success 53m39s

If it's not a dewey pattern then it'll fall back to the usual regular expression matching.

Makes it easier to be specific, especially in required pkg lists.

#pkgsrc #bob

@alephoto85 could you be more specific about pkgin slowness? I've done a huge amount of performance work on it over the last few years (e.g. https://federate.me.uk/@jperkin/110900896074569984) and would be curious to know what's left on the table as I've not been able to find much. #pkgsrc #pkgin

Early next week I'll be updating the SmartOS trunk package sets to be built on 20250612, as per announcement to smartos-discuss:

https://smartos.topicbox.com/groups/smartos-discuss/T4d2e6741534082c1-M55c62305fa736b387d1fd04f/bumping-the-minimum-pi-requirement-for-trunk-packages

This also migrates them over to bob, and an improved build host configuration that will result in much faster and more reliable builds.

No need to do anything other than ensure you're running at least 20250612 (we release every 2 weeks with new features and security fixes, why wouldn't you?!) and "pkgin upgrade".

#pkgsrc #smartos #bob