error during package installation
how to direct ouput by a command to file (so I can report error here) pkg_add nedit t1 doesn't work Thanks!
Re: error during package installation
Hi, Long Wind wrote on Sun, Aug 17, 2014 at 07:27:09AM +0800: how to direct ouput by a command to file (so I can report error here) pkg_add nedit t1 doesn't work That only catches standard output, not standard error. Both of the following should work: $ pkg_add nedit t1 21 # to the file only $ pkg_add nedit 21 | tee t1 # to the file and to the screen Let me take a blind guess regarding your problem: http://www.openbsd.org/faq/faq15.html#NoFun Yours, Ingo
Re: error during package installation
Thank STeve Andre' I use script method I probably will disappoint Ingo Schwarze, perhaps it's not really error, but it made me feel uneasy: Error from http://ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz Redirected to http://211.167.105.78:82/1Q2W3E4R5T6Y7U8I9O0P1Z2X3C4V5B/ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz I often see msg like above during installation BTW what's quirks anyway? I often see it Thanks!
Re: error during package installation
On Sat, Aug 16, 2014 at 5:07 PM, Long Wind longwind2...@gmail.com wrote: Thank STeve Andre' I use script method I probably will disappoint Ingo Schwarze, perhaps it's not really error, but it made me feel uneasy: Error from http://ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz Redirected to http://211.167.105.78:82/1Q2W3E4R5T6Y7U8I9O0P1Z2X3C4V5B/ftp.sunet.se/pub/os/OpenBSD/5.5/packages/i386/quirks-1.113.tgz That's presumably just the nature of how that site handles the mirror, via a redirect among their servers. With signed packages, you can be confident that an interposer can't use that subvert your pkg_add by replacing the package files. BTW what's quirks anyway? I often see it It's a package used by the package system itself. c.f pkg_info quirks Philip Guenther
Re: Package installation
On 08/02/14 07:17, Gustav Fransson Nyvell wrote: On 08/02/14 13:13, Gustav Fransson Nyvell wrote: On 08/02/14 12:54, Marc Espie wrote: On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; This puts more strain on the file system actually, which is probably the main reason we don't do it. Also, there is generally a lot of churning to do to make the package self-contained. As far as policy goes, having stuff set up like that looks more flexible, but it is a fallacy. Instead of having the distribution solve issues concerning incompatible versions and updates, the toll falls instead on the individual sysadmin, to make sure things they have work together. It can lead to security nightmares, because it's so simple to have the newer version alongside the old version that sticky points of updating take much longer to resolve. It's a bit like having mitigation measures that you can turn on and off... if it's possible to turn these off, there's not enough incentive to actually fix issues. Likewise for packages. By making it somewhat LESS convenient to install several versions of the same piece of software, we make it more important to do timely updates. Also, we don't have the manpower to properly manage lots of distinct versions of the same software. So this kind of setup would be detrimental to actually testing stuff. I guess there could be both. But I think that if there's a security issue with one version of a software then there quite possibly are multiple ways of limiting the impact of that issue. Disallowing multiple versions to force people to upgrade is not really a good reason, from how I see it. Old software will always have more holes, because they're older and more well observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on Lenovo X41 from 2005, but probably has bugs. Of course none of these systems will stop someone who wants to run version x of a software. Maybe something entirely different is needed? Okay, maybe I should complain about the status quo... thing is when packages install in /var, /usr, /etc and /opt they're so spread out it's hard to know what is what. This might be because I'm new but/and scripts can find orphan files in this structures, but you need the scripts for that. Having everything in /pkgs/PKG/VER would not cause this splatter. Programs without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. BTW, you create multiple versions by your mere existence. There are lots of old versions laying around, but they can't be installed together right now. No, I have multiple versions by experience and usage of a package. If I want multiple versions of something, I'll take the older version of and modify it to call the older version of it's libraries, etc. I have done this on one occasion. It wasn't fun but it was doable, for the period I wanted both around. OpenBSD's philosophy of packages bound together, with a specific version of the OS is entirely reasonable. You don't want to have versions of the same thing running, or at least you shouldn't. If you do, virtualizing might be a more sane way to go. This is all open source, and you have the freedom to change, or mangle things as you wish.. --STeve Andre'
Package installation
Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Package installation
On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; This puts more strain on the file system actually, which is probably the main reason we don't do it. Also, there is generally a lot of churning to do to make the package self-contained. As far as policy goes, having stuff set up like that looks more flexible, but it is a fallacy. Instead of having the distribution solve issues concerning incompatible versions and updates, the toll falls instead on the individual sysadmin, to make sure things they have work together. It can lead to security nightmares, because it's so simple to have the newer version alongside the old version that sticky points of updating take much longer to resolve. It's a bit like having mitigation measures that you can turn on and off... if it's possible to turn these off, there's not enough incentive to actually fix issues. Likewise for packages. By making it somewhat LESS convenient to install several versions of the same piece of software, we make it more important to do timely updates. Also, we don't have the manpower to properly manage lots of distinct versions of the same software. So this kind of setup would be detrimental to actually testing stuff.
Re: Package installation
On 08/02/14 12:54, Marc Espie wrote: On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; This puts more strain on the file system actually, which is probably the main reason we don't do it. Also, there is generally a lot of churning to do to make the package self-contained. As far as policy goes, having stuff set up like that looks more flexible, but it is a fallacy. Instead of having the distribution solve issues concerning incompatible versions and updates, the toll falls instead on the individual sysadmin, to make sure things they have work together. It can lead to security nightmares, because it's so simple to have the newer version alongside the old version that sticky points of updating take much longer to resolve. It's a bit like having mitigation measures that you can turn on and off... if it's possible to turn these off, there's not enough incentive to actually fix issues. Likewise for packages. By making it somewhat LESS convenient to install several versions of the same piece of software, we make it more important to do timely updates. Also, we don't have the manpower to properly manage lots of distinct versions of the same software. So this kind of setup would be detrimental to actually testing stuff. I guess there could be both. But I think that if there's a security issue with one version of a software then there quite possibly are multiple ways of limiting the impact of that issue. Disallowing multiple versions to force people to upgrade is not really a good reason, from how I see it. Old software will always have more holes, because they're older and more well observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on Lenovo X41 from 2005, but probably has bugs. Of course none of these systems will stop someone who wants to run version x of a software. Maybe something entirely different is needed? Okay, maybe I should complain about the status quo... thing is when packages install in /var, /usr, /etc and /opt they're so spread out it's hard to know what is what. This might be because I'm new but/and scripts can find orphan files in this structures, but you need the scripts for that. Having everything in /pkgs/PKG/VER would not cause this splatter. Programs without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Package installation
On 08/02/14 13:13, Gustav Fransson Nyvell wrote: On 08/02/14 12:54, Marc Espie wrote: On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; This puts more strain on the file system actually, which is probably the main reason we don't do it. Also, there is generally a lot of churning to do to make the package self-contained. As far as policy goes, having stuff set up like that looks more flexible, but it is a fallacy. Instead of having the distribution solve issues concerning incompatible versions and updates, the toll falls instead on the individual sysadmin, to make sure things they have work together. It can lead to security nightmares, because it's so simple to have the newer version alongside the old version that sticky points of updating take much longer to resolve. It's a bit like having mitigation measures that you can turn on and off... if it's possible to turn these off, there's not enough incentive to actually fix issues. Likewise for packages. By making it somewhat LESS convenient to install several versions of the same piece of software, we make it more important to do timely updates. Also, we don't have the manpower to properly manage lots of distinct versions of the same software. So this kind of setup would be detrimental to actually testing stuff. I guess there could be both. But I think that if there's a security issue with one version of a software then there quite possibly are multiple ways of limiting the impact of that issue. Disallowing multiple versions to force people to upgrade is not really a good reason, from how I see it. Old software will always have more holes, because they're older and more well observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on Lenovo X41 from 2005, but probably has bugs. Of course none of these systems will stop someone who wants to run version x of a software. Maybe something entirely different is needed? Okay, maybe I should complain about the status quo... thing is when packages install in /var, /usr, /etc and /opt they're so spread out it's hard to know what is what. This might be because I'm new but/and scripts can find orphan files in this structures, but you need the scripts for that. Having everything in /pkgs/PKG/VER would not cause this splatter. Programs without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. BTW, you create multiple versions by your mere existence. There are lots of old versions laying around, but they can't be installed together right now. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Package installation
On Sat, Aug 02, 2014 at 01:13:56PM +0200, Gustav Fransson Nyvell wrote: entirely different is needed? Okay, maybe I should complain about the status quo... thing is when packages install in /var, /usr, /etc and /opt they're so spread out it's hard to know what is what. This might be because I'm new but/and scripts can find orphan files in this structures, but you need the scripts for that. Having everything in /pkgs/PKG/VER would not cause this splatter. Programs without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. That's right, you're new. We have all the tools to deal with that. Want to know where a file comes from ? install pkglocatedb. The base system also has locate databases now (new for 5.6) Want to check your file system for weird shit ? pkg_check does that now. There are some rough edges, but I have everything to know exactly what belongs where. Oh, and inter-dependencies are trivially recorded. Simpler is better. You're free to leave if you don't like it :)
Re: Package installation
On 08/02/14 06:25, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; no. Plain and simple. You have to understand a few things about Solaris and OpenBSD. Solaris takes great pride in binary compatibility between versions -- Solaris 6 binaries can run on Solaris 11, etc. OpenBSD takes great pride in its unified system approach -- your third party apps will be compiled for the version you are running, and you are expected to upgrade all together regularly. Now, a lot of people will look at that and think, Solaris is better! It's easier to maintain!. Having worked for companies with decade-old applications on Solaris (or a long-term support version of RedHat) because no one really understands them anymore, I'd argue the real life impact of the Solaris model is sloppy administration, because it permits it. And ten years later, you have a mission critical app no one understands, no one is willing to touch...and it's got more security holes than a fresh Windows 2000 install. It is much better to be looking at dmesg with a date one year old saying to you, you need to upgrade me, you bum! than a ten year old system that is one crash away from shutting you down. Nick.
Re: Package installation
The need for multiple versions of an application on one machine doesn't manifest that often. Asking the system to tie itself into knots for this purpose is likely to result in bloat, convolution and less reliability. Some contexts support and indeed encourage the notion of many versions. For instance, the Ruby Version Manager (RVM) allows different versions of the Ruby interpreter and its attendant libraries to be in use at a given time. It seems to work perfectly well, but one has to wonder if this is really a good thing. Do you really want the mental overload that results from having to deal with multiple versions of a language, library, API, user tool, or whatever? The original poster might want to consider whether this kind of thing is necessary or desirable. It sounds symptomatic of half-baked ideas about what needs to be accomplished and how to accomplish it. Also worth considering is OpenBSD's stance on how to maintain a system. You are encouraged to refresh the system at six month intervals and, in so doing, become familiar with the nature of the software you're running. Chances are, the version they've packaged works well enough, probably better than older incarnations. Incidentally, you can learn what files comprise a package with: pkg_info -L package-name You can learn about the package related commands by typing: apropos pkg_ And then reading the listed manpages. As always with OpenBSD, these documents are of high quality. Chuck On Aug 2, 2014, at 4:17 AM, Gustav Fransson Nyvell gus...@nyvell.se wrote: On 08/02/14 13:13, Gustav Fransson Nyvell wrote: On 08/02/14 12:54, Marc Espie wrote: On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; This puts more strain on the file system actually, which is probably the main reason we don't do it. Also, there is generally a lot of churning to do to make the package self-contained. As far as policy goes, having stuff set up like that looks more flexible, but it is a fallacy. Instead of having the distribution solve issues concerning incompatible versions and updates, the toll falls instead on the individual sysadmin, to make sure things they have work together. It can lead to security nightmares, because it's so simple to have the newer version alongside the old version that sticky points of updating take much longer to resolve. It's a bit like having mitigation measures that you can turn on and off... if it's possible to turn these off, there's not enough incentive to actually fix issues. Likewise for packages. By making it somewhat LESS convenient to install several versions of the same piece of software, we make it more important to do timely updates. Also, we don't have the manpower to properly manage lots of distinct versions of the same software. So this kind of setup would be detrimental to actually testing stuff. I guess there could be both. But I think that if there's a security issue with one version of a software then there quite possibly are multiple ways of limiting the impact of that issue. Disallowing multiple versions to force people to upgrade is not really a good reason, from how I see it. Old software will always have more holes, because they're older and more well observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on Lenovo X41 from 2005, but probably has bugs. Of course none of these systems will stop someone who wants to run version x of a software. Maybe something entirely different is needed? Okay, maybe I should complain about the status quo... thing is when packages install in /var, /usr, /etc and /opt they're so spread out it's hard to know what is what. This might be because I'm new but/and scripts can find orphan files in this structures, but you need the scripts for that. Having everything in /pkgs/PKG/VER would not cause this splatter. P! rograms without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. BTW, you create multiple versions by your mere existence. There are lots of old versions laying around, but they can't be installed together right now. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: package installation script hints
On Fri, Aug 26, 2005 at 12:06:29AM +0200, Marc Espie wrote: | 2 - How is pkg_add -u working for people? | | It works fine for me. I don't know about other people yet, you tell me... I haven't used it very much yet, but so far everything works great for me. But this is just basic pkg_add -u/pkg_add -r use, couple of packages, nothing fancy. Good stuff so far ;) So thanks, Marc. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: package installation script hints
Paul de Weerd wrote: On Fri, Aug 26, 2005 at 12:06:29AM +0200, Marc Espie wrote: | 2 - How is pkg_add -u working for people? | | It works fine for me. I don't know about other people yet, you tell me... I haven't used it very much yet, but so far everything works great for me. But this is just basic pkg_add -u/pkg_add -r use, couple of packages, nothing fancy. Good stuff so far ;) So thanks, Marc. I tried cd /usr/ports/cat/someport and then make update clean and it worked like a charm for updating-after-building.
Re: package installation script hints
On Fri, Aug 26, 2005 at 09:28:04AM -0400, Will H. Backman wrote: 2 - How is pkg_add -u working for people? It works fine for me. I don't know about other people yet, you tell me... Aug 24 snapshot, trying just pkg_add -u causes it to say updating package - package for every single one of my installed packages, and it then asks me to run pkg_add -r for every installed package. Unfortunately, it is asking me to install the version that I already have. This is the expected behavior (for now). pkg_add -r will not reinstall a package unless its signature changed, so you will end up only installing the package that actually changed.
Re: package installation script hints
-Original Message- From: Marc Espie [mailto:[EMAIL PROTECTED] Sent: Friday, August 26, 2005 9:39 AM To: Will H. Backman Cc: misc@openbsd.org Subject: Re: package installation script hints On Fri, Aug 26, 2005 at 09:28:04AM -0400, Will H. Backman wrote: 2 - How is pkg_add -u working for people? It works fine for me. I don't know about other people yet, you tell me... Aug 24 snapshot, trying just pkg_add -u causes it to say updating package - package for every single one of my installed packages, and it then asks me to run pkg_add -r for every installed package. Unfortunately, it is asking me to install the version that I already have. This is the expected behavior (for now). pkg_add -r will not reinstall a package unless its signature changed, so you will end up only installing the package that actually changed. Shouldn't it suggest what packages to update because of a newer version?
Re: package installation script hints
-Original Message- From: Marc Espie [mailto:[EMAIL PROTECTED] Sent: Friday, August 26, 2005 11:31 AM To: Will H. Backman Cc: misc@openbsd.org Subject: Re: package installation script hints On Fri, Aug 26, 2005 at 09:58:20AM -0400, Will H. Backman wrote: Shouldn't it suggest what packages to update because of a newer version? pkg_add -u doesn't have a notion of `newer version'. It stops at `this is the package whose name most closely matches your existing package'. It matches the current model of OpenBSD development, where you point your PKG_PATH at a location that contains all the packages from a given release, with very few exceptions. There is also the fact that the pkgname is not enough to identify the package completely. Specifically, packages may need to be updated when system libraries change. All of this is known, and registered correctly. pkg_add -u was under serious time constraints to get into OpenBSD 3.8. It is expected that the next version will be much less wasteful. If you prefer, pkg_add -u in 3.8 is not at all perfect. But having to figure out all package names for pkg_add -r by hand was ways more cumbersome... ;) Got it. I was just looking at the man page, and noticed that it mentioned this new feature and that it would need testing. I'm hoping to test it a lot, but I was unsure of the expected behavior.
Re: package installation script hints
-Original Message- From: Marc Espie [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 6:43 PM To: Will H. Backman Cc: misc@openbsd.org Subject: Re: package installation script hints On Wed, Aug 24, 2005 at 04:35:13PM -0400, Will H. Backman wrote: 1. Packages get installed in a sub-optimal order. Quite often one package on the list will have already been installed as a dependency. I think my script downloads the redundant package before deciding that it was already installed. Good ways to stop that? Put the full list in the single pkg_add you want to run, this will get sorted appropriately. PKG_PATH=ftplocation pkg_add `cat pkglist` is about what you want. Nice to see that pkg_add doesn't actually need the .tgz when PKG_PATH is specified. That reduces the need for a lot of my code. Just ls /var/db/pkg pkglist and move that list to a new host and run pkg_add `cat pkglist`, with PKG_PATH properly set of course. Two more interesting things (assuming you found any of this interesting). 1 - If the new host happens to have one of those packages installed, perhaps because I stopped the installation of packages the first time, then pkg_add will stop when it hits an already installed package. I can fix that with pkg_delete `ls /var/db/pkg` and start over, but perhaps there is a better way? 2 - How is pkg_add -u working for people?
Re: package installation script hints
On Thu, Aug 25, 2005 at 10:08:53AM -0400, Will H. Backman wrote: 1 - If the new host happens to have one of those packages installed, perhaps because I stopped the installation of packages the first time, then pkg_add will stop when it hits an already installed package. I can fix that with pkg_delete `ls /var/db/pkg` and start over, but perhaps there is a better way? There is no better way yet. It's a new feature in my development copy, but with too much a potential for breaking things for it to get committed before 3.8 gets out. Note that pkg_add -r will do more or less what you want, since it won't replace packages if they're already installed, and will go on. You might end up updating some packages you did not intend to, though... 2 - How is pkg_add -u working for people? It works fine for me. I don't know about other people yet, you tell me...
Re: package installation script hints
On Wed, Aug 24, 2005 at 04:35:13PM -0400, Will H. Backman wrote: 1. Packages get installed in a sub-optimal order. Quite often one package on the list will have already been installed as a dependency. I think my script downloads the redundant package before deciding that it was already installed. Good ways to stop that? Put the full list in the single pkg_add you want to run, this will get sorted appropriately. PKG_PATH=ftplocation pkg_add `cat pkglist` is about what you want.
package installation fatal error
Folks:
Brand new to openbsd.
Just installed obsd without any of the X sets, game*, or bsd.mp
installed, on an intel pc. Every seems to be on the up and up except
that installing packges gives a fatal error, and there is nothing in
the log files to tell me anything about this particular error.
Note:
The network is up and running and I can surf with lynx
Shell is sh. I also received this error using csh
I can ftp to ftp.openbsd.org
Here are the steps I took:
#PKG_PATH=ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/
#export PKG_PATH
#
#pkg_add snort-2.1.2.tgz
Can't find snort-2.1.2.tgz
/usr/bin/pkg_add: snort-2.1.2.tgz:Fatal error
I get this error using pkg_add as above or by prepending $PKG_PATH to
the package name:
#pkg_add ${PKG_PATH}snort-2.1.2.tgz
OR
#pkg_add
ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/snort-2.1.2.tgz
What could be the issue here.
TIA
Re: package installation fatal error
On Friday 24 June 2005 09:23 am, Qv6 wrote: Folks: Here are the steps I took: #PKG_PATH=ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/ #export PKG_PATH # Never mind folks. I found out the cause: PKG_PATH was not properly defined. here is the original PKG_PATH definition: PKG_PATH=ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/ and here is the corrected version PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/3.7/packages/i386/ My bad!
Re: package installation fatal error
Qv6 wrote:
Folks:
Brand new to openbsd.
Just installed obsd without any of the X sets, game*, or bsd.mp
installed, on an intel pc. Every seems to be on the up and up except
that installing packges gives a fatal error, and there is nothing in
the log files to tell me anything about this particular error.
Note:
The network is up and running and I can surf with lynx
Shell is sh. I also received this error using csh
I can ftp to ftp.openbsd.org
Here are the steps I took:
#PKG_PATH=ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/
s/OPENBSD/OpenBSD and lose the trailing slash
#export PKG_PATH
#
#pkg_add snort-2.1.2.tgz
Can't find snort-2.1.2.tgz
/usr/bin/pkg_add: snort-2.1.2.tgz:Fatal error
I get this error using pkg_add as above or by prepending $PKG_PATH to
the package name:
#pkg_add ${PKG_PATH}snort-2.1.2.tgz
OR
#pkg_add
ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/snort-2.1.2.tgz
What could be the issue here.
TIA
Re: package installation fatal error
Thanks all! s/OPENBSD/OpenBSD/
Re: package installation fatal error
Qv6 ([EMAIL PROTECTED]) dixit: Folks: Brand new to openbsd. Brand new to *nix too? #PKG_PATH=ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/ (...) ftp://ftp.openbsd.org/pub/OPENBSD/3.7/packages/i386/snort-2.1.2.tgz The issue is that OpenBSD is not the same as OPENBSD. -- |--| | Florin (Slippery) Iamandi
