Remember: If you have a particular port that’s not building in DragonFly, there may be a patch in pkgsrc that could be brought over, as John Marino points out.
Poudriere is the tool for building all of ports/dports, and Michael W. Lucas has written up his experience using it to build a custom ports set. He’s doing on FreeBSD, but if you ignore the geom-specific parts, it should generally apply to DragonFly.
If you are upgrading packages on your DragonFly 3.6 system, and you have docbook installed, there’s an extra step needed because of the moving around of several docbook packages. If you don’t have docbook installed – nothing to see here.
If you’re using the i915 driver for xorg, and xorg dies with a “No monitor specified for screen” error, there’s a config change to fix that, or you can just update.
We’ve got Go builders running for DragonFly, but nobody actively maintaining Go itself on DragonFly. The dports version builds, but there’s a Go release coming up and having native support would be much better than relying on chance FreeBSD build compatibility.
The current error as I type this is a TLS problem that sounds like a simple fix, if only I knew where it was.
Brad Fitzpatrick showed up on the users@ list and mentioned that for DragonFly to be supported in Go, it needed to show up in the Go Dashboard with building reports. I now have the Go builder running on pkgbox32/pkgbox64.dragonflybsd.org. Check the builder page to see status.
Note: Installing the port of Go from Dports works just fine; this is the mechanism for testing Go on a per-commit basis for the people who work on Go – so a ‘fail’ notice on the builder page doesn’t necessarily mean anything, unless you are developing Go itself. This may already be clear to you.
There are no binary packages built for dports, on DragonFly 3.7, for 32-bit machines, at this time. Pierre Abbat found this out. You can build from source, of course, or just use 3.6 packages. Don’t forget -DBATCH to avoid getting asked for build options when building from source.
Warren Postma found that hal and dbus caused a crash in VMWare for DragonFly. The answer is to use moused, not dbus.
Also, if you want to keep a custom or just older package from dports on your system, as karu.pruun did, ‘pkg lock’ is the answer.
A reminder based on a question from Pierre Abbat: John Marino isn’t working on 32-bit packages for dports; there’s a volunteer who will, but until the volunteer is ready, 3.7 users will want to build from source.
Here’s how my upgrade from DragonFly 3.4 to 3.6 for this server went.
The system install went normally. I rebooted before performing ‘make upgrade’, as noted in UPGRADING and elsewhere.
I already have dports installed, so a binary upgrade should be possible. I had heard of people with older version of pkg, having trouble getting it to notice upgrades. I rebuilt pkg, and ran ‘pkg upgrade’. A number of the updates coredumped. Here’s one example:
[156/160] Upgrading gtk2 from 2.24.19 to 2.24.19_2...Segmentation fault (core dumped)
After the upgrade, I had two problems: PHP wasn’t working for the website, and some programs would segfault.
The random segfault was fixable by forcing a binary upgrade of all packages. Since there were some programs on the system that were still new enough that the version number was the same as on the remote repository, pkg didn’t upgrade them. Those packages were linked against old versions of system libraries that predated the locale changes in DragonFly 3.6, so they’d crash. Forcing the update for all packages fixed the issue.
The other problem, PHP on the web server, is not new to me. The binary package for PHP does not include the module for Apache. The solution is to build from source with that option selected. I understand that pkg is destined to support (some?) port options in the future. There’s also an immediate workaround for locking it.
However, the port would not build because of a security issue. The binary package installed without any warning. This, I am told, will change to pkg giving you the option to install if you are aware of the security problem, and whether it really affects you. (which is just what I want, yay!)
Anyway, other than the system changes biting me because I didn’t realize some packages weren’t updated, it went very quickly. That is the reason for binary updates through pkg, or at least a major one.
Odds and ends for the quieter holidays.
- Hubert Feyrer spotted this video interview of Amitai ‘schmonz’ Schlair about NetBSD.
- OpenBSD has tmpfs.
- PC-BSD has made it through a pkg upgrade.
- pkgsrc is frozen until at least the end of the month, for pkgsrc-2013Q4.
- OpenBSD wants to shift electrical costs. (via)
- The DiscoverBSD weekly roundup.
- Managing custom ports. (can apply to dports too)
- Building tcsh on 4.3BSD-Quasijarus. This led me to…
- 4.5BSD. An ambitious project.
- A pfSense video review.
- Steryana Shopova is this past week’s Faces of FreeBSD.
- OpenBSD had a head start on not trusting RNGs.
- OpenBSD has a new vioscsi(4) driver.
- Michael W. Lucas’s books are available through OpenBSD.
- FreeBSD Kitten. (via NYCBUG)
If you have a DragonFly 3.4 system that has already been switched over to dports, and you upgrade it to DragonFly 3.6, you might see an odd problem. Rebuild pkg, and it will work.
I’ve only seen a few reports, so I don’t know if this is even likely to happen to most upgraders.
I had a sometimes-great, sometimes-difficult trip to New York City over the past few days, and while I was there, I met the ball of energy that is George Rosamond of NYCBUG (which is having a huge party right now.) He and I talked for a bit about various aspects of the BSD ecosystem, and one thing he noted was that people aren’t generally aware of all the licenses in use for the different software packages on the system, or even the individual licenses in the system files.
There is an ACCEPTABLE_LICENSES setting in pkgsrc, where software licensed under terms not in that list won’t install. That’s useful, but frustrating, because it keeps people from getting what they asked for – a software install. Something that would be useful – and it could be cross-BSD very easily – would be a license audit summary.
There’s meta-data on every package in FreeBSD’s ports and DragonFly’s dports and pkgsrc and OpenBSD’s port system. Why not say ‘pkg licenses’ in the same way you can say ‘pkg info’, and get a summary of the licenses you have installed in the system? (or pkg_licenses, etc. You get the idea) This wouldn’t prevent people from installing software, but it would give a very quick view of what you were using.
> pkg licenses
Software package License
---------------- -------
foo-2.2.26 Apache license
bar-7.999999 Donateware
baz_ware-20131209 MIT
quux-silly-6.5 BSD
It could be extended to the base system, but I’d like to see this in all the packaging systems as a common idea, in the same way that ‘info’ in a packaging command always shows what’s installed.
Rett Kent has volunteered for maintaining i386 support under dports. Good luck! 3rd-party software management is difficult.
pkg 1.2 is coming out. This brings a number of new features, but as John Marino posted, you may want to delete your old pkg.conf to keep the new version from complaining about an old config file. This upgrade is a step on the way to signed packages, which is a Good Idea.
If you’re upgrading dports (and you probably are if you are going from DragonFly 3.4 to 3.6), there’s a minor issue in dports, inherited from FreeBSD ports: you need to manually remove perl before upgrading. It’s all of one command, so it’s not a huge burden. Joris Giovanngeli spotted it first.
John Marino isn’t interested in supporting the i386 architeecture for DragonFly and dports, so he’s not going to actively work on it. (Packages for DragonFly 3.6 are already built, so that’s not a problem for release.) If you feel like taking on a significant but interesting workload, check his message about the work involved.
Matthew Dillon wrote a roundup post summarizing all the changes he’s made to DragonFly to improve SMP performance in the last few weeks. He’s removed almost all contention from DragonFly. This means better performance, scaling upward depending on the number of processors.
‘monster’, the system that builds all 20,000 items in dports, can complete the run in 15 hours. Compare this to the 2 weeks it used to take me to build the 12,000 packages in pkgsrc. This is admittedly on different hardware and different packaging systems, but it gives a sense of the scale of the improvement.
As a followup to news that the git feed of pkgsrc through dragonflybsd.org is not being updated, Max Herrgard wrote out how to fetch pkgsrc via CVS, or tarball, or another git feed. CVS is still the ‘official’ way.
Matthew Dillon’s been working to make huge parallel software builds (i.e. dports) go a bit faster, so watch out. This only affects you if you are running DragonFly 3.5, of course.