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
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
On Sat, 9 May 2009 15:15:48 +0200
Joerg Sonnenberger 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 (
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
> mai
On Sat, 9 May 2009 10:08:16 +0300
Hasso Tepper 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
>
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
On Fri, 08 May 2009 21:46:31 +0200
Sascha Wildner 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
> >>
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?
On 08 May 2009 17:19:26 GMT
Johannes Hofmann wrote:
> Simon 'corecode' Schubert wrote:
> > Johannes Hofmann wrote:
> >> Matthew Dillon 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
Simon 'corecode' Schubert wrote:
> Johannes Hofmann wrote:
>> Matthew Dillon 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
Johannes Hofmann wrote:
Matthew Dillon 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 j
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/
> 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
Matthew Dillon 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
On Thu, May 7, 2009 12:48 pm, Matthew Dillon wrote:
> 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 remov
On Thu, May 7, 2009 12:23 pm, Matthew Dillon wrote:
> 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 woul
: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
: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 improv
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
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 pa
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 n
21 matches
Mail list logo
