Re: pkg_dry on DragonFlyBSD
Hi all, pkgin (formerly known as pkg_dry) has been now released to pkgrsc WIP. Please do some testing and report any errors you may encounter: o If you already have the pkgsrc WIP tree: # cd /usr # make pkgsrc-wip-update # cd cd pkgsrc/wip/pkgin # bmake install clean o If you don't have pkgsrc WIP tree: # cd /usr # make pkgsrc-wip-checkout # cd cd pkgsrc/wip/pkgin # bmake install clean o If you just want to install the already built package (it may not work on DFBSD 2.x.x): # pkg_add http://earthborder.quantumachine.net/pub/DragonFlyBSD/pkgin-20090511.tgz Now, you will need to set the PKG_REPOS environment variable. You can choose a mirror from the ones listed here: http://www.dragonflybsd.org/mirrors/ and select the appropiate URL for your DragonFlyBSD release: For example, for HEAD you do: # setenv PKG_REPOS http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-2.3.0/All/ # pkgin update processing local summary... updating database: 100% downloading pkg_summary.bz2: 100% processing remote summary (http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-2.3.0/All/)... updating database: 100% Please, adapt your shell profile file to set PKG_REPOS environment variable. You can now manage your pkgsrc packages in a easy way :-) PD: Any bugs you encounter with pkgin, please report them to pkgsrc wip lists (https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-review), not to DFBSD bugs list. Cheers, Antonio Huete
Re: pkg_dry on DragonFlyBSD
Steve O'Hara-Smith wrote: OTOH handling API changes required by the client code is hard within the tree, it would pretty much require two modules. I don't think that it's a good idea to solve problems which don't exist (yet). -- Hasso Tepper
Re: pkg_dry on DragonFlyBSD
Steve O'Hara-Smith wrote: Like kqemu it's a kernel module with only one client, kqemu is only used by qemu and the DRM kernel module is only used by the Xorg server. They are both bridge modules with one end of their interfaces determined by the client (and thus not under the control of the DragonFly project) and one end determined by the kernel interfaces of DragonFly. Both of these interfaces are subject to change over time. There is many things not under control of the DragonFly project. There may well come a time for either of these where there are two incompatible versions extant supporting two actively used versions of their client (think around a major version bump). This situation just isn't acceptable. It isn't acceptable even for Linux (as DRM upstream). It would be much easier to maintain multiple active versions in the pkgsrc framework than in the kernel source tree. Have you tried it? How do you manage kernel interface changes? It isn't hypothetical, DRM depends closely on many things in kernel (agp(4), pci(4)). How do you manage having pkgsrc package files outside of pkgsrc prefix? -- Hasso Tepper
Re: pkg_dry on DragonFlyBSD
On Sat, 9 May 2009 10:08:16 +0300 Hasso Tepper ha...@estpak.ee wrote: Steve O'Hara-Smith wrote: Like kqemu it's a kernel module with only one client, kqemu is only used by qemu and the DRM kernel module is only used by the Xorg server. They are both bridge modules with one end of their interfaces determined by the client (and thus not under the control of the DragonFly project) and one end determined by the kernel interfaces of DragonFly. Both of these interfaces are subject to change over time. There is many things not under control of the DragonFly project. Indeed there are, but few of them are kernel related and subject to change at the whim of another project. My main point though was that kqemu and drm are similar in this respect. There may well come a time for either of these where there are two incompatible versions extant supporting two actively used versions of their client (think around a major version bump). This situation just isn't acceptable. It isn't acceptable even for Linux (as DRM upstream). Acceptable or not, I don't see any way of preventing it from happening. It would be much easier to maintain multiple active versions in the pkgsrc framework than in the kernel source tree. Have you tried it? How do you manage kernel interface changes? It isn't hypothetical, DRM depends closely on many things in kernel (agp(4), pci(4)). I see two possible ways - options or multiple packages. I agree that handling the kernel interface changes is easier when the code is in the DragonFly tree. OTOH handling API changes required by the client code is hard within the tree, it would pretty much require two modules. How do you manage having pkgsrc package files outside of pkgsrc prefix? Er wasn't the suggestion upthread to have pkgsrc/dfly or thereabouts, ie. within the pkgsrc prefix but presumably not in the pkgsrc repository. -- Steve O'Hara-Smith | Directable Mirror Arrays C:WIN | A better way to focus the sun The computer obeys and wins.|licences available see You lose and Bill collects. |http://www.sohara.org/
Re: pkg_dry on DragonFlyBSD
On Fri, May 08, 2009 at 10:27:16PM +0100, Steve O'Hara-Smith wrote: There may well come a time for either of these where there are two incompatible versions extant supporting two actively used versions of their client (think around a major version bump). It would be much easier to maintain multiple active versions in the pkgsrc framework than in the kernel source tree. What is more likely? The kernel interface changing enough to require fixing the module or an incompatible version to appear? I am against pushing kernel modules into pkgsrc because I strongly believe based on experience from watching different kernels and external modules for years, that the former happens a lot more often. Why does it make it better to keep them in base? Because that way the exposure is much greater. Heck, if it is part of the normal buildworld, people do care about breaking it... Joerg
Re: pkg_dry on DragonFlyBSD
On Sat, 9 May 2009 15:15:48 +0200 Joerg Sonnenberger jo...@britannica.bec.de wrote: On Fri, May 08, 2009 at 10:27:16PM +0100, Steve O'Hara-Smith wrote: There may well come a time for either of these where there are two incompatible versions extant supporting two actively used versions of their client (think around a major version bump). It would be much easier to maintain multiple active versions in the pkgsrc framework than in the kernel source tree. What is more likely? The kernel interface changing enough to require fixing the module or an incompatible version to appear? The kernel interface almost certainly changes more often than incompatible versions appearing. IMHO the question is not which is more likely but rather where can both problems be solved most elegantly. I am against pushing kernel modules into pkgsrc because I strongly believe based on experience from watching different kernels and external modules for years, that the former happens a lot more often. That's not what's being suggested, quite. What's being suggested is having it in a an area outside the base but still within the DragonFly repository. Putting it under the pkgsrc hierarchy when installed makes it possible to use pkgsrc tools with it. All I'm pointing out is that kqemu and drm are very similar in the scope of problems they pose and that a good solution for one is likely to be a good solution for the other - whatever that good solution may be. Why does it make it better to keep them in base? Because that way the exposure is much greater. Heck, if it is part of the normal buildworld, people do care about breaking it... However it becomes messy to keep two versions in the base. -- Steve O'Hara-Smith | Directable Mirror Arrays C:WIN | A better way to focus the sun The computer obeys and wins.|licences available see You lose and Bill collects. |http://www.sohara.org/
Re: pkg_dry on DragonFlyBSD
Johannes Hofmann wrote: Matthew Dillon dil...@apollo.backplane.com wrote: :I'm not sure about kqemu - it's very useful, but since it's a kernel :module, it has a different status. : :However, pkg_dry is a normal software application, and I suspect will :turn into a pkgsrc package quickly. If that's the case, we could just :install it along with other packages as part of the installer. Keeping it :in a /usr/src/ dir could cause some minor headaches in terms of updating :it, so pushing it into pkgsrc solves that nicely. : :In fact, would it be worth packaging DragonFly-specific items in pkgsrc :format even if they weren't in pkgsrc CVS? It'd give us some ready-to-go :management tools for software maintenance. Hmm. Maybe. I'm not so worried about updating... the idea is that the stuff in /usr/src/stuff is not integrated into the build, it's just a place to save things. Once that thing gets integrated elsewhere it can be removed from /usr/src/stuff. Having a local package sub-tree is an interesting idea. Sounds good to me. Regarding kqemu Joerg suggested on pkgsrc-wip-discuss not to put BSD* kernel modules into pkgsrc because of the changing kernel APIs. But a directory with DragonFly specific pkgsrc directories within the DragonFly repository could be a solution. I'd use a separate repository though -- no need to put everything under /usr/src, if we could put it under /usr/pkgsrc/dfly cheers simon
Re: pkg_dry on DragonFlyBSD
Simon 'corecode' Schubert corec...@fs.ei.tum.de wrote: Johannes Hofmann wrote: Matthew Dillon dil...@apollo.backplane.com wrote: :I'm not sure about kqemu - it's very useful, but since it's a kernel :module, it has a different status. : :However, pkg_dry is a normal software application, and I suspect will :turn into a pkgsrc package quickly. If that's the case, we could just :install it along with other packages as part of the installer. Keeping it :in a /usr/src/ dir could cause some minor headaches in terms of updating :it, so pushing it into pkgsrc solves that nicely. : :In fact, would it be worth packaging DragonFly-specific items in pkgsrc :format even if they weren't in pkgsrc CVS? It'd give us some ready-to-go :management tools for software maintenance. Hmm. Maybe. I'm not so worried about updating... the idea is that the stuff in /usr/src/stuff is not integrated into the build, it's just a place to save things. Once that thing gets integrated elsewhere it can be removed from /usr/src/stuff. Having a local package sub-tree is an interesting idea. Sounds good to me. Regarding kqemu Joerg suggested on pkgsrc-wip-discuss not to put BSD* kernel modules into pkgsrc because of the changing kernel APIs. But a directory with DragonFly specific pkgsrc directories within the DragonFly repository could be a solution. I'd use a separate repository though -- no need to put everything under /usr/src, if we could put it under /usr/pkgsrc/dfly Right. That would also make it easy to place it into an existing pkgsrc tree. What else except the kqemu package could we put there? Cheers, Johannes
Re: pkg_dry on DragonFlyBSD
On 08 May 2009 17:19:26 GMT Johannes Hofmann johannes.hofm...@gmx.de wrote: Simon 'corecode' Schubert corec...@fs.ei.tum.de wrote: Johannes Hofmann wrote: Matthew Dillon dil...@apollo.backplane.com wrote: :I'm not sure about kqemu - it's very useful, but since it's a kernel :module, it has a different status. : :However, pkg_dry is a normal software application, and I suspect will :turn into a pkgsrc package quickly. If that's the case, we could just :install it along with other packages as part of the installer. Keeping it :in a /usr/src/ dir could cause some minor headaches in terms of updating :it, so pushing it into pkgsrc solves that nicely. : :In fact, would it be worth packaging DragonFly-specific items in pkgsrc :format even if they weren't in pkgsrc CVS? It'd give us some ready-to-go :management tools for software maintenance. Hmm. Maybe. I'm not so worried about updating... the idea is that the stuff in /usr/src/stuff is not integrated into the build, it's just a place to save things. Once that thing gets integrated elsewhere it can be removed from /usr/src/stuff. Having a local package sub-tree is an interesting idea. Sounds good to me. Regarding kqemu Joerg suggested on pkgsrc-wip-discuss not to put BSD* kernel modules into pkgsrc because of the changing kernel APIs. But a directory with DragonFly specific pkgsrc directories within the DragonFly repository could be a solution. I'd use a separate repository though -- no need to put everything under /usr/src, if we could put it under /usr/pkgsrc/dfly Right. That would also make it easy to place it into an existing pkgsrc tree. What else except the kqemu package could we put there? It might make sense to move the drm kernel modules there. -- Steve O'Hara-Smith | Directable Mirror Arrays C:WIN | A better way to focus the sun The computer obeys and wins.|licences available see You lose and Bill collects. |http://www.sohara.org/
Re: pkg_dry on DragonFlyBSD
Steve O'Hara-Smith schrieb: I'd use a separate repository though -- no need to put everything under /usr/src, if we could put it under /usr/pkgsrc/dfly Right. That would also make it easy to place it into an existing pkgsrc tree. What else except the kqemu package could we put there? It might make sense to move the drm kernel modules there. Why? Sascha -- http://yoyodyne.ath.cx
Re: pkg_dry on DragonFlyBSD
On Fri, 08 May 2009 21:46:31 +0200 Sascha Wildner s...@online.de wrote: Steve O'Hara-Smith schrieb: I'd use a separate repository though -- no need to put everything under /usr/src, if we could put it under /usr/pkgsrc/dfly Right. That would also make it easy to place it into an existing pkgsrc tree. What else except the kqemu package could we put there? It might make sense to move the drm kernel modules there. Why? Like kqemu it's a kernel module with only one client, kqemu is only used by qemu and the DRM kernel module is only used by the Xorg server. They are both bridge modules with one end of their interfaces determined by the client (and thus not under the control of the DragonFly project) and one end determined by the kernel interfaces of DragonFly. Both of these interfaces are subject to change over time. There may well come a time for either of these where there are two incompatible versions extant supporting two actively used versions of their client (think around a major version bump). It would be much easier to maintain multiple active versions in the pkgsrc framework than in the kernel source tree. -- Steve O'Hara-Smith | Directable Mirror Arrays C:WIN | A better way to focus the sun The computer obeys and wins.|licences available see You lose and Bill collects. |http://www.sohara.org/
Re: pkg_dry on DragonFlyBSD
Hi all, I've updated getpkgdry.sh script so it can handle the last CVS version of pkg_dry. Get it here: http://leaf.dragonflybsd.org/~tuxillo/archive/getpkgdry.sh You are encouraged to updated to the latest version as there have been many changes, features included, bug fixes and improvements over the previous versions. You can get more information about pkg_dry usage here: http://imil.net/pkgdry/ Note: Please, delete your old database (rm -f /var/db/pkg_dry/*.db) and file ddb_create.h (rm -fr $HOME/pkg_dry/ddb_create.h) before running the new script, because there have been changes on the DB structure. Antonio Hi again, As recommended by pkg_dry author (iMil), it is better to use CVS code instead the milestone from 04-14 because it include a lot more changes. For those who are interested on testing, you can grab the attached script and it will: - Install dependencies - Checkout source and apply patches - Compile and install - Create initial data for pkg_dry It will need root privileges and a inet connection. Regards, Antonio Huete Hi, The other day I heard about a new tool for handling pkgsrc binary packages called pkg_dry, so I decided to give it a try. You can see the original post here: http://mail-index.netbsd.org/tech-pkg/2009/04/14/msg003070.html There is a small set of steps to make it work on DFBSD. You will need libfetch (thanks joerg ;) and sqlite3 from pkgsrc. I've attached a small patch that changes the paths for pkgtools (pkg_add, pkg_delete, pkg_info) fetch http://imil.net/NetBSD/pkg_dry-20090414.tgz tar xvzf pkg_dry-20090414.tgz cd pkg_dry patch -p1 pkgdry_pkgtools.patch bmake NOGCCERROR=1 Then you'll need to set PKG_PATH environment variable to one of our binary packages server, for example chlamydia so pkg_dry can grab pkg_summary and the binary packages. You'll also have to create manually the directory where pkg_dry DB and cache is stored. setenv PKG_PATH http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-2.3.0/All/ mkdir -p /var/db/pkg_dry/cache Ok, now you can sync the package list from the remote repo. #./pkg_dry -u For further information about the usage you can consult the main post of the utility in the URL I pasted above. I've attached also a sample output with some basic tests I've done. Regards, Antonio Huete
Re: pkg_dry on DragonFlyBSD
:Hi all, : :I've updated getpkgdry.sh script so it can handle the last CVS version :of pkg_dry. Get it here: :http://leaf.dragonflybsd.org/~tuxillo/archive/getpkgdry.sh : :You are encouraged to updated to the latest version as there have been :many changes, features included, bug fixes and improvements over the :previous versions. This is like the third recent patch that has stuff which we can't really integrate into the base tree. I'm also thinking of the kqemu stuff. I'm thinking of creating a new sub-directory, /usr/src/stuff, which would be similar to /usr/src/test... a place where we can put 'stuff' that can't be integrated into the base tree but which we also do not want to lose. What do people think? -Matt
Re: pkg_dry on DragonFlyBSD
Matthew Dillon dil...@apollo.backplane.com wrote: :I'm not sure about kqemu - it's very useful, but since it's a kernel :module, it has a different status. : :However, pkg_dry is a normal software application, and I suspect will :turn into a pkgsrc package quickly. If that's the case, we could just :install it along with other packages as part of the installer. Keeping it :in a /usr/src/ dir could cause some minor headaches in terms of updating :it, so pushing it into pkgsrc solves that nicely. : :In fact, would it be worth packaging DragonFly-specific items in pkgsrc :format even if they weren't in pkgsrc CVS? It'd give us some ready-to-go :management tools for software maintenance. Hmm. Maybe. I'm not so worried about updating... the idea is that the stuff in /usr/src/stuff is not integrated into the build, it's just a place to save things. Once that thing gets integrated elsewhere it can be removed from /usr/src/stuff. Having a local package sub-tree is an interesting idea. Sounds good to me. Regarding kqemu Joerg suggested on pkgsrc-wip-discuss not to put BSD* kernel modules into pkgsrc because of the changing kernel APIs. But a directory with DragonFly specific pkgsrc directories within the DragonFly repository could be a solution. Johannes
Re: pkg_dry on DragonFlyBSD
However, pkg_dry is a normal software application, and I suspect will turn into a pkgsrc package quickly. If that's the case, we could just install it along with other packages as part of the installer. Keeping it in a /usr/src/ dir could cause some minor headaches in terms of updating it, so pushing it into pkgsrc solves that nicely. Yes, it will soon be in pkgsrc.
Re: pkg_dry on DragonFlyBSD
On Thu, May 7, 2009 2:20 pm, Jeremy C. Reed wrote: However, pkg_dry is a normal software application, and I suspect will turn into a pkgsrc package quickly. If that's the case, we could just install it along with other packages as part of the installer. Keeping it in a /usr/src/ dir could cause some minor headaches in terms of updating it, so pushing it into pkgsrc solves that nicely. Yes, it will soon be in pkgsrc. Yay! This solves several issues for us - a decent binary install tool for packages, plus it removes maintenance from DragonFly and moves it over all the pkgsrc-supported platforms. This way, we don't have to worry about updating or improving pkg_radd; just about supporting pkg_dry.
Re: pkg_dry on DragonFlyBSD
Hi again, As recommended by pkg_dry author (iMil), it is better to use CVS code instead the milestone from 04-14 because it include a lot more changes. For those who are interested on testing, you can grab the attached script and it will: - Install dependencies - Checkout source and apply patches - Compile and install - Create initial data for pkg_dry It will need root privileges and a inet connection. Regards, Antonio Huete Hi, The other day I heard about a new tool for handling pkgsrc binary packages called pkg_dry, so I decided to give it a try. You can see the original post here: http://mail-index.netbsd.org/tech-pkg/2009/04/14/msg003070.html There is a small set of steps to make it work on DFBSD. You will need libfetch (thanks joerg ;) and sqlite3 from pkgsrc. I've attached a small patch that changes the paths for pkgtools (pkg_add, pkg_delete, pkg_info) fetch http://imil.net/NetBSD/pkg_dry-20090414.tgz tar xvzf pkg_dry-20090414.tgz cd pkg_dry patch -p1 pkgdry_pkgtools.patch bmake NOGCCERROR=1 Then you'll need to set PKG_PATH environment variable to one of our binary packages server, for example chlamydia so pkg_dry can grab pkg_summary and the binary packages. You'll also have to create manually the directory where pkg_dry DB and cache is stored. setenv PKG_PATH http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-2.3.0/All/ mkdir -p /var/db/pkg_dry/cache Ok, now you can sync the package list from the remote repo. #./pkg_dry -u For further information about the usage you can consult the main post of the utility in the URL I pasted above. I've attached also a sample output with some basic tests I've done. Regards, Antonio Huete getpkgdry.sh Description: Bourne shell script
pkg_dry on DragonFlyBSD
Hi, The other day I heard about a new tool for handling pkgsrc binary packages called pkg_dry, so I decided to give it a try. You can see the original post here: http://mail-index.netbsd.org/tech-pkg/2009/04/14/msg003070.html There is a small set of steps to make it work on DFBSD. You will need libfetch (thanks joerg ;) and sqlite3 from pkgsrc. I've attached a small patch that changes the paths for pkgtools (pkg_add, pkg_delete, pkg_info) fetch http://imil.net/NetBSD/pkg_dry-20090414.tgz tar xvzf pkg_dry-20090414.tgz cd pkg_dry patch -p1 pkgdry_pkgtools.patch bmake NOGCCERROR=1 Then you'll need to set PKG_PATH environment variable to one of our binary packages server, for example chlamydia so pkg_dry can grab pkg_summary and the binary packages. You'll also have to create manually the directory where pkg_dry DB and cache is stored. setenv PKG_PATH http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-2.3.0/All/ mkdir -p /var/db/pkg_dry/cache Ok, now you can sync the package list from the remote repo. #./pkg_dry -u For further information about the usage you can consult the main post of the utility in the URL I pasted above. I've attached also a sample output with some basic tests I've done. Regards, Antonio Huete --- b/actions.c 2009-04-17 15:18:33 +0200 +++ a/actions.c 2009-05-01 01:32:28 +0200 @@ -2,8 +2,8 @@ #include pkg_dry.h -#define PKG_DELETE /usr/sbin/pkg_delete -#define PKG_ADD /usr/sbin/pkg_add +#define PKG_DELETE /usr/pkg/sbin/pkg_delete +#define PKG_ADD /usr/pkg/sbin/pkg_add #define LOCALBASE /usr/pkg /* see DISCLAIMER below */ --- b/pkg_dry.h 2009-04-17 14:24:12 +0200 +++ a/pkg_dry.h 2009-05-01 01:32:38 +0200 @@ -9,7 +9,7 @@ #include tools.h #include lib.h -#define PKGTOOLS /usr/sbin +#define PKGTOOLS /usr/pkg/sbin #define PKG_SUMMARY pkg_summary #define PKG_DRY_LOG PKG_DRY_DB/pkg_dry.log #define PKG_DRY_CACHE PKG_DRY_DB/cache vmware# ./pkg_dry -u processing local summary... updating database: 100% downloading pkg_summary.bz2: 100% processing remote summary... updating database: 100% vmware# ./pkg_dry -i screen nothing to upgrade. 1 packages to be installed: screen-4.0.3nb2 proceed ? [y/N] y downloading packages... downloading screen-4.0.3nb2.tgz: 100% installing packages... pkg_add: Warning: package `/var/db/pkg_dry/cache/screen-4.0.3nb2.tgz' was built for a different version of the OS: pkg_add: DragonFly/i386 2.2 (pkg) vs. DragonFly/i386 2.3.0 (this host) screen-4.0.3nb2: setting permissions on /usr/pkg/bin/screen-4.0.3 (o=root, g=wheel, m=4511) screen-4.0.3nb2: adding /usr/pkg/bin/screen to /etc/shells screen-4.0.3nb2: registering info file /usr/pkg/info/screen.info === $NetBSD: MESSAGE,v 1.5 2005/12/28 17:53:24 reed Exp $ You may want to create and edit the file: /usr/pkg/etc/screenrc to customize screen globally. Example configuration files have been installed to: /usr/pkg/share/examples/screen/screenrc /usr/pkg/share/examples/screen/etcscreenrc === processing local summary... updating database: 100% vmware# ./pkg_dry -l screen |grep screen screen-4.0.3nb2 / Multi-screen window manager vmware# ./pkg_dry -r screen 1 packages to delete: screen proceed ? [y/N] y removing screen... screen-4.0.3nb2: unregistering info file /usr/pkg/info/screen.info screen-4.0.3nb2: removing /usr/pkg/bin/screen from /etc/shells processing local summary... updating database: 100% vmware# ./pkg_dry -i clamav warning: /usr/pkg/lib/libgmp.so.3.4.4 is not present in this system (may me installed by this package) warning: /usr/pkg/lib/libclamunrar_iface.so.5.0.4 is not present in this system (may me installed by this package) warning: /usr/pkg/lib/libclamunrar.so.5.0.4 is not present in this system (may me installed by this package) warning: /usr/pkg/lib/libclamav.so.5.0.4 is not present in this system (may me installed by this package) warning: /usr/pkg/lib/libgmp.so.3.4.4 is not present in this system (may me installed by this package) nothing to upgrade. 2 packages to be installed: gmp-4.2.4nb1 clamav-0.94.2 proceed ? [y/N] y downloading packages... downloading gmp-4.2.4nb1.tgz: 100% downloading clamav-0.94.2.tgz: 100% installing packages... pkg_add: Warning: package `/var/db/pkg_dry/cache/gmp-4.2.4nb1.tgz' was built for a different version of the OS: pkg_add: DragonFly/i386 2.2 (pkg) vs. DragonFly/i386 2.3.0 (this host) gmp-4.2.4nb1: registering info file /usr/pkg/info/gmp.info pkg_add: Warning: package `/var/db/pkg_dry/cache/clamav-0.94.2.tgz' was built for a different version of the OS: pkg_add: DragonFly/i386 2.2 (pkg) vs. DragonFly/i386 2.3.0 (this host) clamav-0.94.2: Creating group ``clamav'' clamav-0.94.2: Creating user ``clamav'' clamav-0.94.2: copying /usr/pkg/share/examples/clamav/daily.cvd to /var/clamav/daily.cvd clamav-0.94.2: copying
