Category: DPorts

pkg upgrade tip for pkg 1.3


DragonFly’s using pkg 1.3, at least on master, and I’ve seen a few people report an error message when performing ‘pkg upgrade’.   The error message usually includes something like:

pkg: need to re-create repo Avalon to upgrade schema vers

If you get this, do ‘pkg update -f’ and it will complete.

Posted by     Categories: DPorts, DragonFly     0 Comments

Moving past ports


Here’s a nice advantage for dports and DragonFly: since it’s an overlay on FreeBSD ports, it’s possible to move to newer or different versions of software without waiting for it to happen in FreeBSD.  For example: there’s a newer version of the xorg intel driver now in dports - newer than what’s in ports.

Posted by     Categories: DPorts, DragonFly     0 Comments

pkg 1.3 out


There’s a new version of pkg out – 1.3.  (via)  That’s an announcement on the FreeBSD-ports-announce list.  Since DragonFly also uses pkg, that means it’s available for DragonFly too.  John Marino reported on IRC that he’s testing a bulk build now, using it on DragonFly.

Posted by     Categories: DPorts, DragonFly, FreeBSD     0 Comments

pkg and conflicts


Some dports packages can’t be installed in combination with others.  The easy way to find the conflict without doing the install?  Look for CONFLICTS= in the Makefile.  If you don’t have the dports tree on disk, you can always look online.

Posted by     Categories: DPorts, DragonFly, Goings-on     0 Comments

DragonFly 3.4 packages removed


The dports binary packages built for DragonFly 3.4 are removed.  If you have a 3.4 system, you can build from source, or preferably just upgrade.  Note that the 3.4 release images are still out there if needed.

Posted by     Categories: DPorts, DragonFly     0 Comments

Building with the system OpenSSL


If you’re building ports, it will treat OpenSSL as a dependency and bring in whatever version is available.  If perhaps you want to use the version of OpenSSL installed as part of your base system, Robin Hahling has the answer for how.  (This probably works on FreeBSD too.)

Portmaster tip: you are using the new version


Portmaster, if you install it, tells you to upgrade your packages.  If you are on DragonFly, you are already upgraded.

Posted by     Categories: DPorts, DragonFly     0 Comments

One weird trick for dports


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.

Posted by     Categories: DPorts, DragonFly, pkgsrc     1 Comment

Setting up Poudriere


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.

Posted by     Categories: DPorts, DragonFly, FreeBSD     0 Comments

Note for docbook and upgrading


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.

Posted by     Categories: DPorts, DragonFly     0 Comments

For Intel graphics users who can’t find a monitor


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.

Posted by     Categories: Device support, DPorts, DragonFly     0 Comments

Go maintainer for DragonFly needed


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.

Posted by     Categories: DPorts, DragonFly     0 Comments

Go testing for DragonFly


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.

Posted by     Categories: DPorts, DragonFly     2 Comments

32-bit DragonFly 3.7 and dports


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.

Hal, dbus, and VMWare tip. Also pkg locking


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 about 32-bit dports


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.

Posted by     Categories: DPorts, DragonFly     0 Comments

My DragonFly 3.6 upgrade adventure


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.

In Other BSDs for 2013/12/21


Odds and ends for the quieter holidays.

Posted by     Categories: BSD, DPorts, OpenBSD, PC-BSD, pkgsrc     0 Comments

A pkg fix for 3.4 upgraders


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.

A BSD plan: license summaries


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.

Posted by     Categories: BSD, DPorts, DragonFly, FreeBSD, NetBSD, OpenBSD, pkgsrc     4 Comments

Someone for i386 and dports work


Rett Kent has volunteered for maintaining i386 support under dports.  Good luck!  3rd-party software management is difficult.

Posted by     Categories: DPorts, DragonFly     0 Comments

New pkg 1.2 on the way


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.

Posted by     Categories: DPorts, DragonFly, Goings-on, Heads Up!     0 Comments

Minor upgrade step with dports


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.

Posted by     Categories: DPorts, DragonFly     0 Comments

i386 dports maintainer wanted


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.

Posted by     Categories: DPorts, DragonFly     0 Comments

Discontented with contention? Be content.


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.

 

Posted by     Categories: Committed Code, DPorts, DragonFly, pkgsrc     4 Comments

Getting pkgsrc


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.

Posted by     Categories: DPorts, DragonFly, pkgsrc     0 Comments

Flush and sync changes ongoing


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.

Posted by     Categories: DPorts, DragonFly, Heads Up!     0 Comments

Why dports?


DragonFly has generally shifted over to dports for 3rd-party software management, away from pkgsrc.  Because of that, I haven’t been building binary packages of the quarterly pkgsrc releases.  Pierre Abbat asked why on users@, and here’s my explanation of the change.

Posted by     Categories: DPorts, DragonFly, pkgsrc     1 Comment

My dports upgrade experience


Since there’s a newer set of dports binary packages uploaded, I thought I’d spend my weekend upgrading, to catch up.

‘pkg upgrade’

And that was it.  Well, not really.  I had to dump and restore my Postgres databases, cause of the switch from 9.0 to 9.2 as default.  I had to build php5 from source to get the Apache module.  Those two things together took longer than the entire download and upgrade of the rest of my system – some ~200 packages?

Posted by     Categories: DPorts, Goings-on     3 Comments

Ansible and dports


Michael W. Lucas wrote a blog post about pkgng and Ansible on FreeBSD.  Will it work on DragonFly?  We already have pkgng on DragonFly in the form of dports, and Ansible… might work?  Please, someone try.

Posted by     Categories: DPorts, DragonFly, FreeBSD     1 Comment

About dports, packages, and servers


In part of a long thread about dports packages on the users@ list, Matthew Dillon notes that a new set of packages for i386 and x86_64, for 3.4 and for “3.6″ (meaning bleeding-edge DragonFly, even though that’s numbered 3.5) is mostly uploaded.  He also notes that a Haswell-processor-based blade server for DragonFly is in the works, so much of the dragonflybsd.org infrastructure is going to move from his house to a datacenter, with the benefits that provides.  It’ll also help automate binary package building.

Posted by     Categories: DPorts, DragonFly     0 Comments

KDE 3.5 going out of dports


FreeBSD ports, and therefore Dragonfly dports, will drop KDE 3.5 items sometime very soon.  It’s possible to continue to build them in dports, but it’s extra work.  If you need them, volunteer, because otherwise they will be dropped.  (An idea I fully support.)

Posted by     Categories: DPorts, DragonFly     0 Comments

OpenJDK7, everywhere


It looks like OpenJDK7 works in pkgsrc for DragonFly, thanks to Ryo ONODERA, and I think it’s working in dports too.

Posted by     Categories: DPorts, DragonFly, pkgsrc     0 Comments

BSDCan 2013 videos


FreeBSDNews.net has a nice summary up of video from all (?) the presentations at BSDCan 2013.   Of particular interest to DragonFly users: a video about pkg, the tool used for package maintenance in dports.  In this presentation, it’s talking about use on FreeBSD, but the future stuff applies to DragonFly too.

Posted by     Categories: BSD, Conventions, DPorts, DragonFly     0 Comments

Adding to dports


Since dports uses FreeBSD ports as a base, adding something to FreeBSD ports means it will show in dports, too.  However, it doesn’t have to go that way.  It’s possible to have dports packages that exist only in dports.  If you have changes to a port that make it compile on DragonFly, that can be added too.  For all of that, go to the dports issues page on GitHub.

Getting dports without pkg installed


I pointed out in my converting-to-dports post from yesterday that I had to download dports and build pkg by hand in order to install binary packages.  This was because my DragonFly system was upgraded from 3.2 to 3.4 and therefore didn’t have pkg installed.

John Marino has added a ‘pkg-bootstrap’ option to /usr/Makefile, for fixing exactly that problem.  It downloads a static version of pkg, which then lets you upgrade to the full pkg and install binaries as you’d expect.

Posted by     Categories: DPorts, DragonFly     0 Comments

Switching to dports software


I changed shiningsilence.com over from pkgsrc to dports over the last 48 hours or so.  Here’s how it went, in a series of bullet points:

  • I had to download dports source and build the pkg tool by hand; since this system was upgraded from DragonFly 3.2 to DragonFly 3.4, pkg wasn’t automatically present as it would be for a new installation.
  • I took the output of ‘pkg_info’ and culled it down to the applications I knew I used, and that formed my ‘to-install’ list for dports.  That worked in a very straightforward way.
  • It took so long mostly because of two things: I was also dealing with an email problem at my workplace, which usually took precedence.  Also, I had several applications that I had previously installed by hand and needed to reconfigure to work as a dports item.
  • Installing from binaries is really fast!  Really, the dports part of this was possibly the most brief.
  • The only thing I needed to compile from source was php, in order to get the Apache plugin.  I’m sort of surprised the option isn’t on by default.
  • Using ‘pkg search packagename’ is a good idea, because ‘pkg install’ can pick up multiple versions of a package.  e.g. ‘pkg install mysql-server’ selects mysql-server51, mysql-server55, and mysql-server56.  You probably don’t want to install all three.  Or even one, depending on your opinions.
  • Overall, it went more easily than I had expected, given it only had half of my attention.
Posted by     Categories: About This Site, DPorts, DragonFly     4 Comments

Pardon my dust


I’m switching this server from pkgsrc to dports.  No post while I fight with old, stale configs and etc.

Posted by     Categories: About This Site, DPorts     0 Comments

3.4.2 images uploaded


I finally got DragonFly 3.4.2 img/iso files uploaded, so they are available now or at least soon at your local mirror.  These are built using pkgsrc, so if you want dports, go for a snapshot image.

Posted by     Categories: DPorts, DragonFly, pkgsrc     0 Comments

Is anyone using KDE 3.5?


Are you using it and unable to upgrade to KDE4 for a specific reason other than aesthetic preference?  You should check this thread about support for 3.5, at least in dports.

Posted by     Categories: DPorts, DragonFly     0 Comments

More download statistics


There’s more download statistics on dports and pkgsrc packages, from Francois Tigeot.  There’s a heck of a lot of dports activity, though there’s probably much more pkgsrc building from source than this would report on.  So, not necessarily representative of actual numbers, but an interesting ratio none the less.

Posted by     Categories: DPorts, DragonFly, pkgsrc     0 Comments

DPorts and snapshots


Matthew Dillon and Sascha Wildner have converted snapshot/release building over to use dports instead of pkgsrc.  If you want to try one of those snapshots, look in the snapshots directory…  Oh, and here’s the mention of this on kernel@.

Posted by     Categories: DPorts, DragonFly, pkgsrc     0 Comments

More experimenting with dports


Here’s another “getting started with dports” article.  It runs through the basic range of commands, similar to my existing writeup – but much less verbose.

Posted by     Categories: DPorts, DragonFly     0 Comments

Man page for dports


Sascha Wildner’s added a man page for dports.  Don’t forget the existing how-to page.

Posted by     Categories: DPorts, DragonFly     0 Comments

DPorts updates


New builds of dports have been uploaded and updated, for x86_64 and i386.  (x86_64 was already done; I linked the note about i386)  This means you can change PACKAGESITE in /usr/local/etc/pkg.conf to point at LATEST instead of RELEASE and get newer packages.  ‘pkg upgrade’ is all it takes, with dports.

Posted by     Categories: DPorts, DragonFly     0 Comments

Usage for dports and pkgsrc


In the week after DragonFly 3.4 was released, Francois Tigeot was tracking downloads for each type of packaging system.  It looks like dports downloads far outnumber pkgsrc.  I think there’s reasons it appears different in uptake, but it’s still neat to see people trying the new system.

Posted by     Categories: DPorts, DragonFly, pkgsrc     1 Comment

How about Ansible?


Ansible seems to be a configuration management system that’s lighter than puppet or salt.  I had a student talking about it in my class tonight.  BSD users Hubert Feyrer and Michael W. Lucas have both posted about it recently.  Anyone want to repeat their experiences?

Posted by     Categories: BSD, DPorts, pkgsrc, Someday you will need this     3 Comments

Howto: dports and xfce4


‘william opensource4you’ posted a summary of the steps he took for setting up a DragonFly system with XFCE4, using dports.  It’s pretty straightforward, and thanks to dport’s binary nature, should be exactly reproducible.

Posted by     Categories: DPorts, DragonFly, Goings-on     0 Comments

DragonFly 3.3/3.5 users and dports


If you’re running DragonFly-current, which right now means version 3.3 and very soon 3.5, you are probably running pkgsrc.  If you want to transition to dports, this pair of posts from John Marino will tell you how.

Hey, mirror operators!


If you administer one of the DragonFly mirrors, there’s a new /dports directory that can be mirrored.  See that second link for details.

Posted by     Categories: DPorts, DragonFly, Goings-on     0 Comments

DPorts and DragonFly 3.5 cheatsheet


John Marino published a ‘cheatsheet‘ (also, typo fix)for DragonFly 3.5 users who want to try dports, using DragonFly 3.4 packages.

dports and gcc versions; an explanation


John Marino has a concise explanation of why dports mostly uses gcc 4.4 still to compile, even if you’re building DragonFly itself with the default 4.7.  It’s a reason to not use NO_GCC44 – yet.

Posted by     Categories: DPorts, DragonFly, Goings-on     0 Comments

entr(1); Run arbitrary commands when files change.


Eric Radman sent along a plug for a utility he is working on called entr(1).  The desciption is “Run arbitrary commands when files change.”  The site for it has several nifty examples – run make when *.c files change, or convert Markdown files to HTML as soon as they are modified.  The really nice thing about it is that it’s perfectly BSD-friendly, and uses kqueue, but will also work on Linux.  This beats the “This runs on the one flavor of Linux I use, in one particular shell!” approach I’ve seen from some other developers.  See the reddit discussion of it for comparisons to inotify.  No, it’s not in pkgsrc/ports yet.

Update: And thanks to Thomas Klausner, it’s in pkgsrc as sysutils/entr, and in ports as sysutils/entr thanks to Eitan Adler.  You have no reason not to try it now.

Posted by     Categories: BSD, DPorts, Goings-on, pkgsrc     0 Comments

How to put completely new software in DPorts


DPorts is based off of FreeBSD’s ports, but it’s possible to add software packages to it that don’t exist in FreeBSD’s ports system and have them build as any other packages.  This is briefly detailed in this GitHub bug report, along with a number of the ports that already exist that way.

Posted by     Categories: DPorts, DragonFly     0 Comments

Over 19500!


John Marino has posted about the state of dports: over 19500 ports built, build logs available, and patches to add even more can be sent through github.  XFCE4, KDE3, and KDE4 are building, though he could use some help with GNOME2.

over9000

Man, I’m stretching it to make that “Over nine thousand!” joke, now.

Posted by     Categories: DPorts, DragonFly     0 Comments

Lazy Reading for 2013/03/31


I hope you like reading; there’s some very meaty links this week.  Go get a cup of tea and settle in.  You drink tea, don’t you?  You ought to.

  • Reading about KDE’s repository near-meltdown makes me think we need more checks for DragonFly.  We have the advantage of Hammer, of course, which would help in the same way that the linked article names ZFS as a ‘fix’.  (via multiple places)
  • We know that Apple will reject apps it disagrees with.  Google also will do so.  Has there ever been a program rejected from pkgsrc or (FreeBSD/OpenBSD) ports on content grounds?  Not that I know of – anyone remember differently?  I’d argue that’s a favorable point for the BSD packaging systems, though it may just be that no application has tested those boundaries yet.
  • Portscanning all IPv4 addresses on the planet.  Possibly the largest distributed effort ever?  The detail in the maps and returned services is especially interesting.  (via)
  • Scale Fail, a Youtube video of a 2011 talk about screwing up your services.  Mostly about the humor, but the underlying points are valid.   (via #dragonflybsd IRC)
  • There’s still improvement possible to fsck, apparently based on this.  That’s UFS2 fsck.
  • What is your most productive shortcut with Vim?  A very thorough explanation of verbs, marks, and registers.  Holy cow, I wish I had known about ‘: … v’ before.  It’s long, but worth it.  (via)
  • Matthew Garret’s description of Secure Boot vs. Restricted Boot with UEFI, (via a coworker who went to Libreplanet 2013).  I’m still not sure what DragonFly will need to do about this.
  • I missed mentioning this earlier: 20 years of NetBSD.  We’re coming up on 10 soon.
  • Dragonfly drones.  Unrelated except for name.
  • That guy who starts to froth madly every time BSD is mentioned on Phoronix is still there (see comments).
  • Mainframe computer supercut.  (via)

Your unrelated comics link of the week: Tom Spurgeon of the Comics Reporter asked people for their lists of webcomics that could go in a ‘Hall of Fame’.  The resulting list is a lot of really, really good material.  Go use up a few hours reading.

A 3.4 release clarification


I saw this Hacker News post and figured I should emphasize: pkgsrc is still going to be available in the 3.4 release of DragonFly; we’re not suddenly switching to dports.  I don’t want anyone to think they’re going to have to rip out all their packages and go to a new, untried system, all at once.

Posted by     Categories: DPorts, DragonFly, pkgsrc     0 Comments

Lazy Reading for 2013/03/03


I am all over the place with links this week – some of them pretty far off the path.  There’s a lot, too, so enjoy!

Your unrelated link of the week: I’ve already been offbeat enough in this Lazy Reading; I don’t have anything else.

3 very different commits


Here’s 3 recent and different commits to DragonFly that I’m commenting on all at once:

  1. Peter Avalos upgraded libarchive in DragonFly to 3.1.2, with a note of the changes.  An ordinary and appreciated update.
  2. Sascha Wildner updated the ISO639 file to include the newest update: “Standard Moroccan Tamazight”.  There’s no particular utility to that; I just like saying “Standard Moroccan Tamazight” out loud.
  3. Work on poudriere, the utility for bulk-building DPorts packages, has caused some nice speedups for DragonFly in extremely stressful situations.  See one of Matthew Dillon’s recent commits.

I really wish the other BSD projects would include commit lines in the mail message subjects, so it was easier to catch things like these.

Posted by     Categories: BSD, Committed Code, DPorts, DragonFly     0 Comments

DPorts packages for 64-bit DragonFly available


If you want to take advantage of the binary packages of DPorts, and have a x86_64 system with a recent DragonFly 3.3 on it: Francois Tigeot has you covered.  There’s no i386 packages yet, which are the ones I could use right now, darnit.

If you want to try DPorts, see my earlier article.

 

Posted by     Categories: DPorts, DragonFly, Goings-on     0 Comments

More tips for DPorts


I meant to post this a while ago; it’s a few days old but still useful.  John Marino gave some stats on DPorts progress, plus he and Francois Tigeot also had some tips on xorg setup.  The successful build count is  higher by now, and I think KDE3 is done, though I haven’t tried it.

Posted by     Categories: DPorts, DragonFly, Goings-on     0 Comments

An early DPorts education


John Marino’s DPorts project, mentioned here briefly before, is interesting.  I had two separate people ask me how it works, so a better explanation is in order.  I’ve tried it out on a test machine over the past few weeks.

Background:

Dports is an effort to use FreeBSD’s ports system as a base for DragonFly, and the pkg tool as a way to manage binary packages built from DPorts.  This is complicated, so I’ll explain each part in order.

  • FreeBSD ports are a FreeBSD-specific collection of software installation files that automate building 3rd-party software on FreeBSD.  You’ve probably already heard of them.  (Note there’s no mention of DragonFly.)
  • DPorts is a collection of files that map to existing FreeBSD ports, and contain any changes necessary to make that port also build on DragonFly.  Many of those programs build without changes on DragonFly.  DPorts builds from source.
  • pkg is used for package management, and is usable on FreeBSD and on DragonFly.  The binary packages produced from building with DPorts can be installed from remote locations and managed separately using pkg, so that software upgrades and installation can be performed with binaries only.  (It’s much faster that way.)

Every port seen in DPorts is known to build on DragonFly.  John Marino adds a port only after it builds successfully, using poudriere as a bulk software tool.   Ports are only updated to a newer version when that newer version builds, too, so once something arrives in DPorts, it should never break from being updated at some point in the future.

Installing:

To use DPorts, you need two things:

  1. DragonFly 3.3 or later, though 3.3 is the most recent right now.
  2. You need to rename /usr/pkg so that your existing pkgsrc binary programs don’t get accidentally used while working with DPorts, causing confusion.  If anything goes wrong with DPorts when you are installing it and you want to go back, remove all the DPorts packages and rename /usr/pkg back to normal.

(Don’t confuse pkg, the management tool, with /usr/pkg, the normal installation directory for pkgsrc. ) For the installation of the base port files:

cd /usr
make dports-create-shallow

If you’ve already renamed your /usr/pkg directory, git won’t be in your path any more.  You can instead download a tarball and unpack it, which also happens to be possible automatically via that same Makefile.

cd /usr
make dports-download

Downloading via git is fastest, so if you do need to use the tarball via make dports-download, build devel/git, delete /usr/dports, and then pull it again with make dports-create-shallow.  This all comes from John Marino’s Github site for DPorts.

Managing DPorts

DPorts doesn’t use pkg_info, pkg_add, and the other tools traditionally seen on DragonFly for pkgsrc.  Instead, package management is done with pkg.   Use pkg info, pkg install, pkg remove, and pkg update to list, install, delete, and upgrade various packages on your system.  Packages built from source or downloaded as prebuilt binaries are managed the same way, using these tools.

See some of the other writing about pkg for FreeBSD for details on how it works.

Since DPorts doesn’t update a package until it gets a successful build, and installations are of successfully built binary packages, upgrades with prebuilt packages should always succeed.  Since they’re binary, they should be fast.  There’s a lot of ‘shoulds’  in this sentence, but these are reasonable suppositions.

What about pkgsrc?

Pkgsrc and DPorts shouldn’t be used at the same time, since one system’s packages may be at different versions but still get picked up during building for the other system.  That’s about it for restrictions.

I intend to try building an experimental release of DragonFly with DPorts, to see if all the right packages can be added, but no guarantees.  DPorts is brand new and does not yet have a repository for downloading packages, so the normal caveats apply; don’t install it on a mission-critical machine, and be ready to deal with any surprises from using it if you do try it out.

What packages are available?

Browsing the Github repo will show you all listed packages.  More complex packages like xorg, openjdk7, and libreoffice install, as does xfce.  Parts of KDE 3 and KDE 4 are in there.  (I haven’t tried either.)  I’m not sure about Gnome, but I don’t think anyone ever is.  There’s no vim, but there is emacs.

That’s just what I see at this exact minute.  It changes daily as more packages are built.  Changes from DragonFly builds are sometimes relevant to the original FreeBSD port, so there’s benefits for everyone here.

What next?

Try it now if it has all the packages you need, or wait for a binary repository to be created to speed things up.  Remember, this is a new project, so a willingness to deal with problems and contribute to fixes is necessary.

Posted by     Categories: DPorts, DragonFly, Goings-on, pkgsrc     17 Comments