Re: pkg_add.1

2020-06-26 Thread Marc Espie
On Wed, Jun 24, 2020 at 05:32:57PM +0100, Jason McIntyre wrote:
> On Tue, Jun 23, 2020 at 07:28:09PM -0400, sven falempin wrote:
> > Dear readers,
> > 
> > It may not be very obvious that 'dry run' mode of pkg_add
> > actually downloads packages.
> > It is a good feature and maybe the pkg_add man could use an EXAMPLES
> > section.
> > 
> 
> hi.
> 
> it might not be obvious, but it is documented:
> 
>-n   Don't actually install a package, just report the
> steps that would be taken if it was.  Will still
> copy packages to PKG_CACHE if applicable.
> 
> if you look through the page for how the PKG_CACHE stuff works, it
> seems clear.
> 
> anyway, i'll defer to espie on whether the diff is wanted or not.
> comments on your text inline:

I don't think it adds much, and it's indeed already documented, and used
for instance by bsd.port.mk



Re: pkg_add.1

2020-06-24 Thread Jason McIntyre
On Tue, Jun 23, 2020 at 07:28:09PM -0400, sven falempin wrote:
> Dear readers,
> 
> It may not be very obvious that 'dry run' mode of pkg_add
> actually downloads packages.
> It is a good feature and maybe the pkg_add man could use an EXAMPLES
> section.
> 

hi.

it might not be obvious, but it is documented:

 -n   Don't actually install a package, just report the
  steps that would be taken if it was.  Will still
  copy packages to PKG_CACHE if applicable.

if you look through the page for how the PKG_CACHE stuff works, it
seems clear.

anyway, i'll defer to espie on whether the diff is wanted or not.
comments on your text inline:

> Index: pkg_add.1
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
> retrieving revision 1.163
> diff -u -p -r1.163 pkg_add.1
> --- pkg_add.1   24 Jan 2020 21:10:46 -  1.163
> +++ pkg_add.1   23 Jun 2020 23:25:12 -
> @@ -836,6 +836,18 @@ information about individual packages
>  database of installed
>  .Xr packages 7
>  .El
> +.Sh EXAMPLES
> +It is possible to download packages before installing them to separate
> download and installation process.

this would have to be sth like:

...before installing them,
in order to separate the download and installation processes.

> +.Pp
> +.Dl PKG_CACHE=/tmp/pkgs pkg_add -I -u -n
> +.Pp
> +will download the package(s) to be updated into .Dq /tmp/pkgs

then you have a new paragraph started, mid-sentence. so it's better to
structure the text like this:

...installation processes.
To download the packages to
.Dq /tmp/pkgs :
.Pp
.Dl $ blah ...
.Pp
They can then be installed at a later date:
.Pp
.Dl $ blah ...

note also that the Dq stuff should be on a separate line.
plus we normally show commands with "$" or "#" prompts.

> +directory
> +and they can be installed later
> +.Pp
> +pkg_add -I /tmp/pkgs/*
> +.Pp
> +.El

and you didn;t start a list (Bl) so no need to end one (El).

jmc

>  .Sh SEE ALSO
>  .Xr ftp 1 ,
>  .Xr pkg_create 1 ,
> 
> Best,



pkg_add.1

2020-06-23 Thread sven falempin
Dear readers,

It may not be very obvious that 'dry run' mode of pkg_add
actually downloads packages.
It is a good feature and maybe the pkg_add man could use an EXAMPLES
section.

Index: pkg_add.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
retrieving revision 1.163
diff -u -p -r1.163 pkg_add.1
--- pkg_add.1   24 Jan 2020 21:10:46 -  1.163
+++ pkg_add.1   23 Jun 2020 23:25:12 -
@@ -836,6 +836,18 @@ information about individual packages
 database of installed
 .Xr packages 7
 .El
+.Sh EXAMPLES
+It is possible to download packages before installing them to separate
download and installation process.
+.Pp
+.Dl PKG_CACHE=/tmp/pkgs pkg_add -I -u -n
+.Pp
+will download the package(s) to be updated into .Dq /tmp/pkgs
+directory
+and they can be installed later
+.Pp
+pkg_add -I /tmp/pkgs/*
+.Pp
+.El
 .Sh SEE ALSO
 .Xr ftp 1 ,
 .Xr pkg_create 1 ,

Best,


Re: new feature in pkg_add(1)

2016-07-10 Thread Patrik Lundin
On Thu, Jun 23, 2016 at 06:44:19AM +0200, Patrik Lundin wrote:
> 
> I will play around with this and see what I can come up with, thanks!
> 

For any interested parties there is now support for the pkg_add
branch-syntax in the openbsd_pkg package management module in ansible
upstream:
https://github.com/ansible/ansible-modules-extras/blob/devel/packaging/os/openbsd_pkg.py

Using the "pkg_info -Iq inst:" syntax was actually a lot easier to
work with than -e, so that helped me remove some additional cruft from
the module as well.

Thanks to espie@ for pointing out that way of using the tool.

-- 
Patrik Lundin



Re: new feature in pkg_add(1)

2016-06-24 Thread Marc Espie
On Thu, Jun 23, 2016 at 06:44:19AM +0200, Patrik Lundin wrote:
> On Wed, Jun 22, 2016 at 02:19:26PM +0200, Marc Espie wrote:
> > On Tue, Jun 21, 2016 at 10:43:07PM +0200, Patrik Lundin wrote:
> > > The reason for doing this is that it is much faster than just blindly
> > > trying to install a package, and does not hammer mirrors needlessly.
> > > 
> > > Are there any plans to teach pkg_info -e about "%"? Is it even possible?
> > 
> > Okay, just committed the exit code fix.
> > 
> > pkg_info -Iq inst:python%3.5
> > will perform just as you would expect.
> 
> Awesome :).
> 
> I will play around with this and see what I can come up with, thanks!

Actually, I think there's something deeply wrong with this process.
This is not Unix.

The philosophy has always been: you want something, you try to do it.
You do not check whether it's already there, and then do it if it's
not.  So the bigger problem is that there's no quick mode for pkg_add
that checks very quickly on the installed system, stops if it's already
there, and otherwise goes installing.

Right now, you're doing the same check twice, which is not so cool.

So I'll see if I can speed up pkg_add  at some point for the cases things
are already there.



Re: new feature in pkg_add(1)

2016-06-22 Thread Patrik Lundin
On Wed, Jun 22, 2016 at 02:19:26PM +0200, Marc Espie wrote:
> On Tue, Jun 21, 2016 at 10:43:07PM +0200, Patrik Lundin wrote:
> > The reason for doing this is that it is much faster than just blindly
> > trying to install a package, and does not hammer mirrors needlessly.
> > 
> > Are there any plans to teach pkg_info -e about "%"? Is it even possible?
> 
> Okay, just committed the exit code fix.
> 
> pkg_info -Iq inst:python%3.5
> will perform just as you would expect.

Awesome :).

I will play around with this and see what I can come up with, thanks!

-- 
Patrik Lundin



Re: new feature in pkg_add(1)

2016-06-22 Thread Marc Espie
On Tue, Jun 21, 2016 at 10:43:07PM +0200, Patrik Lundin wrote:
> The reason for doing this is that it is much faster than just blindly
> trying to install a package, and does not hammer mirrors needlessly.
> 
> Are there any plans to teach pkg_info -e about "%"? Is it even possible?

Okay, just committed the exit code fix.

pkg_info -Iq inst:python%3.5
will perform just as you would expect.



Re: new feature in pkg_add(1)

2016-06-22 Thread Marc Espie
On Tue, Jun 21, 2016 at 10:43:07PM +0200, Patrik Lundin wrote:
> However, "pkg_info -e" does not understand it:
> ===
> # pkg_info -e python%2.7
> Invalid spec: python%2.7
> ===
> 
> I use pkg_info -e to check if a requested package is installed or
> not prior to attempting to install/remove it.
> 
> The reason for doing this is that it is much faster than just blindly
> trying to install a package, and does not hammer mirrors needlessly.
> 
> Are there any plans to teach pkg_info -e about "%"? Is it even possible?

Doesn't fit within the model, but you can already do that thing in a
different way, by choosing the right repository, namely inst.

e.g.,
pkg_info inst:python2.7
ought to give you the right result.

I need to make sure you get a sensible rc code though, which isn't okay right
now.



Re: new feature in pkg_add(1)

2016-06-21 Thread Patrik Lundin
On Fri, Jun 17, 2016 at 04:02:36PM +0200, Marc Espie wrote:
> I was waiting for snapshots to come up with the new stuff, but it
> looks like amd64 will be a bit late.  Someone is still hiking in
> the mountains...
> 
> 
> A week ago or so, I committed support for some disambiguating
> filter in pkg_add.
> 
> This means that you can now simply install packages for ports which
> have several versions in the tree without having to know the exact
> version.
> 
> For instance,
> 
> pkg_add python%2.7
> will install a python from the lang/python/2.7 branch.
> 

I am the maintainer of the OpenBSD package handling module in ansible
and have for a long time had a request to support more relaxed package
names. Until now the suggested solution has been to use the pkg_add -z
invocation.

My main problem with using pkg_add -z has been that the package names it
allows can not be used with "pkg_info -e" or "pkg_delete".

I notice that pkg_delete does understand "%" which is very nice:
===
# pkg_delete python%2.7
python-2.7.11p1: ok
[...]
===

However, "pkg_info -e" does not understand it:
===
# pkg_info -e python%2.7
Invalid spec: python%2.7
===

I use pkg_info -e to check if a requested package is installed or
not prior to attempting to install/remove it.

The reason for doing this is that it is much faster than just blindly
trying to install a package, and does not hammer mirrors needlessly.

Are there any plans to teach pkg_info -e about "%"? Is it even possible?

The full ansible upstream discussion can be found here if anyone is
interested:
https://github.com/ansible/ansible-modules-extras/issues/97

Anyway, thanks for working on this, and thanks to landry@ for mentioning
this was in the works :).

-- 
Patrik Lundin



Re: new feature in pkg_add(1)

2016-06-19 Thread Stuart Henderson
On 2016/06/18 19:54, frantisek holop wrote:
> does this deprecate -z ?

hopefully not; -z is useful for feeding old pkg_info output into pkg_add
on a new machine, and we've used it in the past for getting past a flag
day bump.



Re: new feature in pkg_add(1)

2016-06-19 Thread Nayden Markatchev
amd64 snapshots have been flowing again since yesterday. apologies for
the delay.

On Fri, Jun 17, 2016 at 8:02 AM, Marc Espie  wrote:
> I was waiting for snapshots to come up with the new stuff, but it
> looks like amd64 will be a bit late.  Someone is still hiking in
> the mountains...
>
>
> A week ago or so, I committed support for some disambiguating
> filter in pkg_add.
>
> This means that you can now simply install packages for ports which
> have several versions in the tree without having to know the exact
> version.
>
> For instance,
>
> pkg_add python%2.7
> will install a python from the lang/python/2.7 branch.
>
>
> e.g., stem%branch  takes all packages that match stem-* and filters them
> according to a word in their pkgpath, e.g., you can also use it for, say
> postfix%stable  and other things.
>
>
> This is not really a change, but I've checked where I put %m and stuff
> support, it works in pkg.conf, it also works in PKG_PATH and on the
> command-line.
>
> This means that you can, for instance, write something like
> pkg_add http://ftp.fr.openbsd.org/%m/tcl%8.5
> and this will grab tcl on the 8.5 branch from the "appropriate"
> directory of the froggie server, depending on your OpenBSD version
> and architecture.
>



Re: new feature in pkg_add(1)

2016-06-19 Thread frantisek holop
does this deprecate -z ?

-f
-- 
there's no second chance for a good first impression.



new feature in pkg_add(1)

2016-06-17 Thread Marc Espie
I was waiting for snapshots to come up with the new stuff, but it
looks like amd64 will be a bit late.  Someone is still hiking in
the mountains...


A week ago or so, I committed support for some disambiguating
filter in pkg_add.

This means that you can now simply install packages for ports which
have several versions in the tree without having to know the exact
version.

For instance,

pkg_add python%2.7
will install a python from the lang/python/2.7 branch.


e.g., stem%branch  takes all packages that match stem-* and filters them
according to a word in their pkgpath, e.g., you can also use it for, say
postfix%stable  and other things.


This is not really a change, but I've checked where I put %m and stuff
support, it works in pkg.conf, it also works in PKG_PATH and on the
command-line.

This means that you can, for instance, write something like
pkg_add http://ftp.fr.openbsd.org/%m/tcl%8.5
and this will grab tcl on the 8.5 branch from the "appropriate"
directory of the froggie server, depending on your OpenBSD version
and architecture.



Re: pkg_add.1

2016-02-08 Thread Marc Espie
On Sun, Feb 07, 2016 at 09:42:32AM -0600, joshua stein wrote:
> We don't recommend FTP mirrors anymore, installing a package via a
> pipe doesn't seem to work anymore, and packages have to be signed to
> be installed so the advice about miscreants is not very relevant.
> 
> 
installing packages thru pipes should still work.
surprised it got broken.

you can still install non-signed packages if you really try.



Re: pkg_add.1

2016-02-08 Thread Edgar Pettijohn


Sent from my iPhone

> On Feb 8, 2016, at 12:28 PM, Marc Espie  wrote:
> 
>> On Sun, Feb 07, 2016 at 09:42:32AM -0600, joshua stein wrote:
>> We don't recommend FTP mirrors anymore, installing a package via a
>> pipe doesn't seem to work anymore, and packages have to be signed to
>> be installed so the advice about miscreants is not very relevant.
> installing packages thru pipes should still work.
> surprised it got broken.
> 

I usually do install thru pipes and I haven't seen it broken. I haven't tried 
with the latest snapshot though.

> you can still install non-signed packages if you really try.
> 



Re: pkg_add.1

2016-02-08 Thread Marc Espie
On Mon, Feb 08, 2016 at 03:05:00PM -0800, patrick keshishian wrote:
> On Mon, Feb 08, 2016 at 07:28:24PM +0100, Marc Espie wrote:
> > On Sun, Feb 07, 2016 at 09:42:32AM -0600, joshua stein wrote:
> > > We don't recommend FTP mirrors anymore, installing a package via a
> > > pipe doesn't seem to work anymore, and packages have to be signed to
> > > be installed so the advice about miscreants is not very relevant.
> > > 
> > > 
> > installing packages thru pipes should still work.
> > surprised it got broken.
> > 
> > you can still install non-signed packages if you really try.
> 
> I haven't build ports in a while, but does this comment mean
> that if I'm building my own ports (moving forward), the
> resulting packages must be signed?

Nope, just be careful not mixing your packages with other stuff, and how
you move them around.   Signing with your personal key is not hard.

Specifically,
- you can use -Dunsigned to install your own unsigned packages
- beware of mixing up your unsigned packages AND official packages for
dependencies (e.g., the later should be signed). Note that even with 
-Dunsigned, packages with a signature will *still* have their signature
checked for tampering.
- be careful of taking care of your unsigned packages properly. Getting
them around insecure networks obviously allows tampering.  You can use scp://
urls to prevent that.

Automatically Signing is reasonably easy. You need to generate a couple of
public/private key using signify, have them be of the form
XXX-pkg.sec and  XXX-pkg.pub, put at least the pubkey under /etc,
then set SIGNING_PARAMETERS properly in /etc/mk.conf, e.g., 
SIGNING_PARAMETERS=-s signify -s /etc/XXX-pkg.sec

(there's no pki. the bootstrap part means getting the pub key under the
correct directory manually)


Admittedly, it's safe if you trust your ports building system, and you have
to take extra care (as usual) to not let /etc/XXX-pkg.sec out of your sight...

You can also build packages normally and sign later off-site using pkg_sign.
More cumbersome, but somewhat safer...

In my opinion, there's nothing in there that's not glaringly obvious if
you have a background in the use of public key cryptography.   We went out
of our way to make the design of the package signing system fairly
intuitive and the possible security trade-offs highly visible (as far as 
public key cryptography can be, of course).



Re: pkg_add.1

2016-02-07 Thread Michael McConville
joshua stein wrote:
> We don't recommend FTP mirrors anymore, installing a package via a
> pipe doesn't seem to work anymore, and packages have to be signed to
> be installed so the advice about miscreants is not very relevant.

Good catch with the FTP link.

I think it's still worth mentioning that you put trust in the packages
you install. Although the package tarballs themselves are now signed (by
default), the porter or software author could still try to slip
something in.

> Index: pkg_add.1
> ===
> RCS file: /var/cvsync/src/usr.sbin/pkg_add/pkg_add.1,v
> retrieving revision 1.134
> diff -u -p -u -p -r1.134 pkg_add.1
> --- pkg_add.1 4 Nov 2015 16:59:58 -0000   1.134
> +++ pkg_add.1 20 Jan 2016 21:06:53 -
> @@ -198,41 +198,6 @@ dependencies with the list of packages l
>  user's opinion in interactive mode,
>  then install default packages that satisfy the dependencies.
>  .Pp
> -Alternatively, it is possible to add packages interactively from within the
> -.Xr ftp 1
> -client,
> -in which case setting
> -.Ev PKG_PATH
> -correctly will be necessary for any dependency to be found out and retrieved
> -the same way.
> -For example, the following works:
> -.Bd -literal -offset indent
> -$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/2.7/packages/i386/
> -250 CWD command successful
> -ftp> ls m*
> -227 Entering Passive Mode (129,128,5,191,164,73)
> -150 Opening ASCII mode data connection for m*.
> -m4-1.4.tgz
> -metamail-2.7.tgz
> -mh-6.8.4.tgz
> -mm-1.0.12.tgz
> -mpeg_lib-1.2.1.tgz
> -mpeg_play-2.4.tgz
> -mpg123-0.59q.tgz
> -mutt-0.95.7i.tgz
> -226 Transfer complete.
> -ftp> get m4-1.4.tgz "|pkg_add -v -"
> -.Ed
> -.Pp
> -.Sy Warning:
> -Since the
> -.Nm
> -command may execute scripts or programs contained within a package file,
> -your system may be susceptible to
> -.Dq trojan horses
> -or other subtle attacks from miscreants who create dangerous packages.
> -Be sure the specified package(s) are from trusted sources.
> -.Pp
>  The options are as follows:
>  .Bl -tag -width keyword
>  .It Fl A Ar arch
> 



small fix for pkg_add(1)

2014-01-11 Thread Markus Lude
$ man pkg_add
[...]
 -D name[=value]
[...]
  downgradedon't filter out package versions older than
   what's currently installed.
  D FW_UPDATE  set by fw_update(1) to separate firmwares from
   normal packages.
  installedin update mode, reinstall an existing package
   with the same signature.

D  is too much there, fix below

Regards,
Markus

Index: pkg_add.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
retrieving revision 1.118
diff -u -r1.118 pkg_add.1
--- pkg_add.1   9 Jan 2014 10:51:51 -   1.118
+++ pkg_add.1   11 Jan 2014 13:24:27 -
@@ -275,7 +275,7 @@
 disables that behavior.
 .It Ar downgrade
 don't filter out package versions older than what's currently installed.
-.It D Ar FW_UPDATE
+.It Ar FW_UPDATE
 set by
 .Xr fw_update 1
 to separate firmwares from normal packages.



Re: Automatic package mirror discovery implementation for pkg_add(1) tool

2010-02-21 Thread frantisek holop
hmm, on Thu, Feb 11, 2010 at 12:35:05AM +0300, Igor Zinovik said that
 Maybe it is not polite to answer to this old thread, but I've integrated
 (somehow) AutoMirrorDiscovery functionality into pkg_add tool, just to
 prove myself that i can do that without crashing pkg_add functionality.  It is
 very clumsy right now, but it works for me (with some bugs of course).

this is a great idea i think.
maybe you would want to rename it MirrorAutoDiscovery though :]

i would also fill the cache file with all the mirrors,
(not just the n fastest) in order from fastest to slowest.

if the list of the mirrors is taken from www.openbsd.org
everytime the list is generated, the list could be
considered authoritative.

-f
-- 
go ahead, jump.  100,000 lemmings can't be wrong.



Re: Automatic package mirror discovery implementation for pkg_add(1) tool

2010-02-10 Thread Igor Zinovik
08.01.2010 15:30, Bob Beck writes:
 2010/1/8 Bob Beck b...@ualberta.ca:
 And what I mean by that Is that I would be willing to put together a similar
 trick for this on ftp.openbsd.org as I did for the installer - if
 someone was willing
 to integrate it into the pkg_add tools.

Maybe it is not polite to answer to this old thread, but I've integrated
(somehow) AutoMirrorDiscovery functionality into pkg_add tool, just to
prove myself that i can do that without crashing pkg_add functionality.  It is
very clumsy right now, but it works for me (with some bugs of course).

This is how it works (currently there is no knob to shut it up):
(/tmp)[213]% sudo pkg_add -d
Pinging anga.funkfeuer.at...OK
Pinging carroll.cac.psu.edu...OK
Pinging filedump.se.rit.edu...OK
Pinging ftp-stud.fht-esslingen.de...OK
Pinging ftp.arcane-networks.fr...OK
Pinging ftp.aso.ee...no response
Pinging ftp.belnet.be...OK
Pinging ftp.bytemine.net...OK
Pinging ftp.ca.openbsd.org...no response
Pinging ftp.cc.uoc.gr...no response
Pinging ftp.chg.ru...OK
Pinging ftp.crans.org...OK
Pinging ftp.cs.pu.edu.tw...no response
Pinging ftp.cse.buffalo.edu...no response
Pinging ftp.das.ufsc.br...OK
Pinging ftp.df.lth.se...OK
Pinging ftp.dkuug.dk...no response
Use of uninitialized value $ret in numeric eq (==) at
/usr/libdata/perl5/OpenBSD/AutoMirrorDiscovery.pm line 58.
Pinging ftp.duth.gr...no response
Pinging ftp.esat.net...OK
Pinging ftp.estpak.ee...OK
Pinging ftp.eu.openbsd.org...OK
Pinging ftp.fmed.uc.pt...no response
Pinging ftp.fr.openbsd.org...OK
Pinging ftp.freebsdchina.org...OK
Pinging ftp.freenet.de...OK
Pinging ftp.fsn.hu...OK
Pinging ftp.gamma.ru...OK
Pinging ftp.heanet.ie...OK
Pinging ftp.iinet.net.au...OK
Pinging ftp.inet.no...OK
Pinging ftp.irisa.fr...OK
Pinging ftp.is.co.za...OK
Pinging ftp.jaist.ac.jp...OK
Pinging ftp.jyu.fi...OK
Pinging ftp.kaist.ac.kr...no response
Pinging ftp.kddlabs.co.jp...no response
Pinging ftp.lambdaserver.com...OK
Pinging ftp.mirrorservice.org...OK
Pinging ftp.netbsd.se...OK
Pinging ftp.nluug.nl...OK
Pinging ftp.obsd.si...OK
Pinging ftp.openbsd.dk...OK
Pinging ftp.openbsd.or.id...OK
Pinging ftp.openbsd.org.ar...no response
Pinging ftp.openbsd.org...OK
Pinging ftp.piotrkosoft.net...no response
Pinging ftp.plig.net...OK
Pinging ftp.rediris.es...OK
Pinging ftp.spline.de...OK
Pinging ftp.task.gda.pl...OK
Pinging ftp.tcc.edu.tw...OK
Pinging ftp.tpnet.pl...OK
Pinging ftp.tw.openbsd.org...OK
Pinging ftp.udc.es...no response
Pinging ftp.ulak.net.tr...OK
Pinging ftp.uninett.no...OK
Pinging ftp.wu-wien.ac.at...OK
Pinging ftp2.fr.openbsd.org...OK
Pinging ftp3.usa.openbsd.org...OK
Pinging ftp5.usa.openbsd.org...OK
Pinging gulus.usherbrooke.ca...no response
Pinging mirror.aarnet.edu.au...OK
Pinging mirror.cdmon.com...OK
Pinging mirror.corbina.net...OK
Pinging mirror.hostfuss.com...OK
Pinging mirror.iawnet.sandia.gov...no response
Pinging mirror.internode.on.net...OK
Pinging mirror.pacific.net.au...OK
Pinging mirror.planetunix.net...OK
Pinging mirror.public-internet.co.uk...no response
Pinging mirror.rit.edu...OK
Pinging mirror.roothell.org...OK
Pinging mirror.switch.ch...OK
Pinging mirrors.24-7-solutions.net...OK
Pinging mirrors.localhost.net.ar...no response
Pinging mirrors.nic.funet.fi...OK
Pinging mirrors.ucr.ac.cr...no response
Pinging obsd.cec.mtu.edu...OK
Pinging openbsd.arcticnetwork.ca...OK
Pinging openbsd.bsdforen.de...OK
Pinging openbsd.ftp.fu-berlin.de...no response
Pinging openbsd.mirror.frontiernet.net...OK
Pinging openbsd.mirrors.pair.com...OK
Pinging openbsd.mirrors.tds.net...OK
Pinging openbsd.noc.jgm.gov.ar...no response
(/tmp)[214]% cat /var/db/ftpmirror.cache
ftp://mirrors.nic.funet.fi/pub/OpenBSD/4.6/packages/i386/
ftp://ftp.gamma.ru/pub/OpenBSD/4.6/packages/i386/
ftp://ftp.eu.openbsd.org/pub/OpenBSD/4.6/packages/i386/
(/tmp)[228]% echo $PKG_PATH

(/tmp)[229]% sudo pkg_add -i fdm
No packages available in the PKG_PATH
fdm-1.6:tdb-1.0.6p0: ok (1 to go)
fdm-1.6: ok


Here is the code:

/usr/src/usr.sbin/pkg_add/OpenBSD/AutoMirrorDiscovery.pm
# ex:ts=8 sw=4:
# $OpenBSD$
#
# Copyright (c) 2009 Igor Zinovik zino...@petrsu.ru
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

# functionality for automatic fastest ftp mirror discovery

use strict;
use warnings;

package OpenBSD::AutoMirrorDiscovery;

use OpenBSD::Paths;
use Net::Ping;
use Net::FTP;

sub 

Re: Automatic package mirror discovery implementation for pkg_add(1) tool

2010-01-08 Thread Bob Beck
2010/1/8 Bob Beck b...@ualberta.ca:
 Apart from this, this is a really tough problem, because of infrastructure
 issues. Basically, our mirrors are not that reliable, and the closest
 one often won't have the packages you need... which is a reason why it's
 mostly some user settings...

 True - although we could do a very similar stunt to what we do with ftplist
 now in the installer - including remembering your most recent choice from your
 IP address, so it just figured out where you liked to get your packages from.


And what I mean by that Is that I would be willing to put together a similar
trick for this on ftp.openbsd.org as I did for the installer - if
someone was willing
to integrate it into the pkg_add tools.



Re: Automatic package mirror discovery implementation for pkg_add(1) tool

2009-12-05 Thread Marc Espie
On Sat, Dec 05, 2009 at 10:47:25PM +0300, Igor Zinovik wrote:
 if (-e /var/db/pkg/ftpmirror.cache) {
   open my $fh, '', /var/db/pkg/ftpmirror.cache or
   die(Permission denied);
   @mirrors = $fh;
   close $fh;
   print $mirrors[0];
   exit;
 }
...
 open $fh, '', /var/db/pkg/ftpmirror.cache or
   die(Cannot create mirror cache file);
 

you can't do this. /var/db/pkg only holds packages. This will confuse
pkg_add when you try to update things.


Apart from this, this is a really tough problem, because of infrastructure
issues. Basically, our mirrors are not that reliable, and the closest
one often won't have the packages you need... which is a reason why it's
mostly some user settings...



Re: Automatic package mirror discovery implementation for pkg_add(1) tool

2009-12-05 Thread Stuart Henderson
On 2009/12/05 22:22, Marc Espie wrote:
 Apart from this, this is a really tough problem, because of infrastructure
 issues. Basically, our mirrors are not that reliable, and the closest
 one often won't have the packages you need... which is a reason why it's
 mostly some user settings...

For snapshots I totally agree, but I think this could work reasonably
well for releases.