The binary package repository for DragonFly-current has been updated with the latest build of all packages, thanks to tuxillo and others on EFNet #dragonflybsd doing a lot of work.
Tuxillo noted: there’s new rust, thunderbird, firefox, nginx, several llvm versions, and a new chrome (version 72). freerdp is temporarily broken; use remmina with the rdp plugin instead. openvpn isn’t upgraded yet cause the build was with libressl, which is a broken combination – it’ll all be built with openssl in a future run.
Issues go here, submissions of work go there.
As mentioned last week, there’s a new build of dports for 5.4, now available. No surprise, but a reminder to keep third-party software up to date is never wasted.
Thanks to tuxillo and others, there’s a new build of dports on the way for DragonFly 5.4 that includes packages that weren’t building before – mongodb, kodi, mysql80, and I imagine more that I don’t know about. If the synth build is still running when you read this, you can look at its status page. If it isn’t running, the packages are of course in the normal place and you can use ‘pkg upgrade’ to get them.
‘mazocomp’ has updated the DragonFly mirrors list to include HTTPS links where appropriate, which would be most everywhere. An excellent idea.
While I’m talking about mirrors, there’s some new DPorts pkg mirrors too.
Chromium, the open sourced base of the Chrome browser, builds on BSDs, including DragonFly. But not without some work.
DragonFly’s default compiler is now gcc-8. This will help with some amount of dports builds.
DragonFly now has a port of the ena(4) driver from FreeBSD. If you aren’t familiar with it, it’s the Elastic Network Adapter used for running on Amazon EC2. That link for the commit message points at several dports tools useful for anyone wanting to try the next logical step.
A little while back I linked to an excellent deep dive into Ravenports, and added my own bit of statistical guessing at popular packages. John Marino wants to know what packages people find most useful/most required. If you have opinions, and I’m sure you do, post something on the Ravenports Google Groups page.
If you are saying to yourself “Gee, what packages did I install and what came in as a dependency?”, here’s an easy way to find out:
pkg query -a '%n %a' | grep 0 | cut -d ' ' -f 1 | less
This lists all “vital” packages, which usually means ones installed with intent, rather than automatically. This might be a useful thing to post for Ravenports…
The article I linked yesterday about Ravenports got me wondering about what package are most popular. avalon.dragonflybsd.org is the default binary package archive for pkg, and it has httpd logs back to 2013, so I collated some information.
I read out a list of packages, and weighed them according to how recently they were downloaded. I also mushed together all the py/ruby/p5/php numbered packages, and excluded lib*.
After all that… there’s a lot of noise. One install of any desktop environment pulls in hundreds of packages automatically, so it’s hard to tell what’s installed by a human and what’s installed by dependency. That being said, here’s some highlights. This is me applying an arbitrary value and then arbitrarily snipping out a list… but it’s fun to see if nothing else.
eerielinux has written an exploratory article about Ravenports. It’s worth a read; Ravenports has been growing actively. You can install it in parallel with dports on DragonFly, or on a number of other operating systems.
Mixed in with the other documentation on the DragonFly website is a “how to build a release” explanation. I use it every time there’s a new DragonFly version. If you were wanting to build a DragonFly ISO/IMG with changes or different preinstalled dports, I’ve added some notes about what’s relevant for non-release building.
We used to have “GUI” releases of DragonFly which were based on the nrelease process installing pkgsrc packages and adding some configuration files. It doesn’t happen now mostly because nobody has had the time to reconfigure for dports; if you were looking for a project this weekend, may I suggest…?
DragonFly has had NX (Non-eXecutable) support for some time. It’s now on by default for read operations in DragonFly master – not the current release. You can step it up to level 2, for write operations, with a loader tunable, but it may cause issues with dports.
If you’ve ever wondered what packages are needed to build a DragonFly release: here they are in one dports metapackage.
Reduce, the “second oldest computer algebra system”, has been ported to DragonFly (and there’s work on other BSDs). The post about this has lots of links to more information; if you’re a Maple or Mathematica user, this will definitely interest you.
There’s a plugin for pkg, called pkg-provides, which will tell you what package(s) contain the filename you provide – installed or not. I didn’t even know pkg had a plugin system. Anyway, it works on DragonFly, as the author notes.
Totally last-minute summary, but I’m hitting every BSD category.
The default options on the math/py-numpy port slowed it down. Francois Tigeot noticed, and committed a change that takes advantage of all processors. Read his note to users@ for details.
I say “one more” like I know when this saga will end. If you are using the devcpu-data port to update your processors, you’ll need to add
to your /etc/rc.conf, as Sepherosa Ziehau points out.
A full slate of BSDs this week.
Because of the major version number change, there’s no packages built for DragonFly 4.9. Your options are to either update to 5.1 (which you probably meant to do anyway if you are running current) or manually point to the newest packages. Or just build from dports.
For clarity, this does not affect you at all if you are running 5.0 release. It only affects you if you are running DragonFly-current and have not updated in a while.