Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 06:29:26PM -0700, Theo de Raadt wrote: How often is firmware updated without a maching driver update? fw_update is really just to provide an automated fuction during install or upgrade, the same time when you are getting a new kernel/drier, it would be rare that a new firmware is available for an existing system, although potentially useful given how buggy some of these things are. it has already happened plenty of times before fw_update was created -- as a result, why fw_update was created by halex at my request. in that timeframe since, no new firmwares have shown up in the place where fw_update looks. unfortunately that is not proof that this will not happen in the future. so the answer to your question is: At least once in the future. ok, so perhaps the diff below will avoid future confusion. jmc Index: usr.sbin/pkg_add/pkg_add.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v retrieving revision 1.111 diff -u -r1.111 pkg_add.1 --- usr.sbin/pkg_add/pkg_add.1 23 Aug 2011 10:32:26 - 1.111 +++ usr.sbin/pkg_add/pkg_add.1 15 Jan 2012 08:26:37 - @@ -68,6 +68,9 @@ option .Fl u .Pc . +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. .Pp Details of packing-list internals are documented in .Xr pkg_create 1 . @@ -765,6 +768,7 @@ .El .Sh SEE ALSO .Xr ftp 1 , +.Xr fw_update 1 , .Xr pkg_create 1 , .Xr pkg_delete 1 , .Xr pkg_info 1 , Index: share/man/man8/afterboot.8 === RCS file: /cvs/src/share/man/man8/afterboot.8,v retrieving revision 1.135 diff -u -r1.135 afterboot.8 --- share/man/man8/afterboot.8 11 Jun 2011 17:52:00 - 1.135 +++ share/man/man8/afterboot.8 15 Jan 2012 08:26:37 - @@ -614,11 +614,16 @@ impossible. Sometimes checking the mailing lists for past problems that people have encountered will result in a fix posted. +.Pp +Non-free firmware packages have their own tool for installing/updating, +.Xr fw_update 1 . +It is run automatically as part of the system upgrade. .Ss Compiling a kernel Information on building and modifying kernels is contained within .Xr config 8 . .Sh SEE ALSO +.Xr fw_update 1 , .Xr ksh 1 , .Xr man 1 , .Xr pkg_add 1 ,
Re: 'pkg_add -u' question
On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? Newer firmware versions often require changes to the driver, so this isn't something I would normally want to update unless I've just updated the kernel.
Re: 'pkg_add -u' question
Hi Jason, Jason McIntyre wrote on Sun, Jan 15, 2012 at 08:28:29AM +: ok, so perhaps the diff below will avoid future confusion. I agree with adding that information and don't strongly object to your wording, but given that fw_update(1) is just a wrapper around pkg_add(1), some might consider it slightly misleading: there is nothing wrong with using pkg_add(1) itself for updating firmwares, as long as you specify the right PKG_PATH and options. See inline for an alternative wording you might consider. Regarding afterboot(8), i think your wording is fine. Yours, Ingo Index: usr.sbin/pkg_add/pkg_add.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v retrieving revision 1.111 diff -u -r1.111 pkg_add.1 --- usr.sbin/pkg_add/pkg_add.123 Aug 2011 10:32:26 - 1.111 +++ usr.sbin/pkg_add/pkg_add.115 Jan 2012 08:26:37 - @@ -68,6 +68,9 @@ option .Fl u .Pc . +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. Since non-free firmware packages are distributed via separate package repositories, the convenience wrapper .Xr fw_update 1 is normally used to update them. .Pp Details of packing-list internals are documented in .Xr pkg_create 1 . @@ -765,6 +768,7 @@ .El .Sh SEE ALSO .Xr ftp 1 , +.Xr fw_update 1 , .Xr pkg_create 1 , .Xr pkg_delete 1 , .Xr pkg_info 1 , Index: share/man/man8/afterboot.8 === RCS file: /cvs/src/share/man/man8/afterboot.8,v retrieving revision 1.135 diff -u -r1.135 afterboot.8 --- share/man/man8/afterboot.811 Jun 2011 17:52:00 - 1.135 +++ share/man/man8/afterboot.815 Jan 2012 08:26:37 - @@ -614,11 +614,16 @@ impossible. Sometimes checking the mailing lists for past problems that people have encountered will result in a fix posted. +.Pp +Non-free firmware packages have their own tool for installing/updating, +.Xr fw_update 1 . +It is run automatically as part of the system upgrade. .Ss Compiling a kernel Information on building and modifying kernels is contained within .Xr config 8 . .Sh SEE ALSO +.Xr fw_update 1 , .Xr ksh 1 , .Xr man 1 , .Xr pkg_add 1 ,
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 11:57:34AM +0100, Ingo Schwarze wrote: Hi Jason, Jason McIntyre wrote on Sun, Jan 15, 2012 at 08:28:29AM +: ok, so perhaps the diff below will avoid future confusion. I agree with adding that information and don't strongly object to your wording, but given that fw_update(1) is just a wrapper around pkg_add(1), some might consider it slightly misleading: there is nothing wrong with using pkg_add(1) itself for updating firmwares, as long as you specify the right PKG_PATH and options. See inline for an alternative wording you might consider. Regarding afterboot(8), i think your wording is fine. Yours, Ingo Index: usr.sbin/pkg_add/pkg_add.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v retrieving revision 1.111 diff -u -r1.111 pkg_add.1 --- usr.sbin/pkg_add/pkg_add.1 23 Aug 2011 10:32:26 - 1.111 +++ usr.sbin/pkg_add/pkg_add.1 15 Jan 2012 08:26:37 - @@ -68,6 +68,9 @@ option .Fl u .Pc . +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. Since non-free firmware packages are distributed via separate package repositories, the convenience wrapper .Xr fw_update 1 is normally used to update them. hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). jmc
Re: 'pkg_add -u' question
Hi Jason, Jason McIntyre wrote on Sun, Jan 15, 2012 at 01:01:50PM +0001: On Sun, Jan 15, 2012 at 11:57:34AM +0100, Ingo Schwarze wrote: Jason McIntyre wrote on Sun, Jan 15, 2012 at 08:28:29AM +: ok, so perhaps the diff below will avoid future confusion. I agree with adding that information and don't strongly object to your wording, but given that fw_update(1) is just a wrapper around pkg_add(1), some might consider it slightly misleading: there is nothing wrong with using pkg_add(1) itself for updating firmwares, as long as you specify the right PKG_PATH and options. +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. Since non-free firmware packages are distributed via separate package repositories, the convenience wrapper .Xr fw_update 1 is normally used to update them. hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). The pkg_add(1) manual does talk about PKG_PATH later on, so mentioning that a specific class of packages has their own repository doesn't seem off-topic when specifically talking about those packages. Besides, when documenting one tool and pointing to another one, mentioning that the latter is just just a wrapper around the former wouldn't qualifiy as excessive detail in my book. But feel free to decide, lest the bikes get all soaked! Yours, Ingo
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 01:01:50PM +0001, Jason McIntyre wrote: hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). I agree. I'm not too fond of fw_update(1), though synching to the kernel makes it a necessity. And pkg_add(1) documentation is already very long. I'm fine with a SEE ALSO .Xr fw_update 1 entry in pkg_add(1), though.
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 02:26:19PM +0100, Ingo Schwarze wrote: hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). The pkg_add(1) manual does talk about PKG_PATH later on, so mentioning that a specific class of packages has their own repository doesn't seem off-topic when specifically talking about those packages. Besides, when documenting one tool and pointing to another one, mentioning that the latter is just just a wrapper around the former wouldn't qualifiy as excessive detail in my book. it is excessive in a comparative sense. since fw_update(8) does not document at any level the fact that it is a wrapper for pkg_add, having pkg_add document what fw_update is is odd. jmc
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 02:32:56PM +0100, Marc Espie wrote: On Sun, Jan 15, 2012 at 01:01:50PM +0001, Jason McIntyre wrote: hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). I agree. I'm not too fond of fw_update(1), though synching to the kernel makes it a necessity. And pkg_add(1) documentation is already very long. I'm fine with a SEE ALSO .Xr fw_update 1 entry in pkg_add(1), though. the Xr, fine. what about the brief note i suggested? my worry is that reading the beginning of pkg_add, you'll have no idea that there even is such a thing. having an Xr will not help that case. it's doesn;t have to go in pkg_add(1), but i cannot think of a better place. jmc
'pkg_add -u' question
I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? Thanks in advance for any information. Dave PS: Before someone jumps all over me, I am _not_ demanding that anyone drop everything and implement this immediately; I'd just like to understand why this doesn't work and whether it's likely to start working anytime soon. And I recognize we've got more urgent/important things to do as a good reason for leaving this alone. I haven't looked into the pkg_add source myself because it's large, complicated and (especially) under active development. -- Dave Anderson d...@daveanderson.com
Re: 'pkg_add -u' question
Hi Dave, Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500: and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. The firmwares live in a different package repository, that's why pkg_add(1) doesn't find them by default. If you do want to check for new firmwares, take the above message as a reminder to run $ sudo fw_update manually. But note that's not necessarily related to doing an operating system upgrade. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), I'm not sure i would want pkg_add(1) to look outside the PKG_PATH. and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, The only (potential, minor) problem i see is that people might run pkg_add(1), see the couldn't find, and not know about fw_update(1). That's probably what happened to you. I'm not sure how to improve that. Messages printed by programs should be terse, so i don't think pkg_add(1) should print a suggestion to run fw_update(1) when it sees *-firmware-* packages it can't update. Most people will know that anyway, and there is no strong reason to check for firmware updates at that particular time. Maybe it could be mentioned in the pkg_add(1) manual. Then again, that manual doesn't document the Couldn't find updates diagnostic at all, so far. do the installer and pkg_add developers not talk to each other, Actually, i have met all of krw@, halex@ and espie@ at least twice during hackathons, but never together; so you may have a point... :-D /irony But no, that's not the root cause of the issue. Yours, Ingo
Re: 'pkg_add -u' question
Dave Anderson wrote: I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. I don't think the firmware files live in the same place as ordinary packages. I expect that the place these files reside is not in your PKG_PATH. If I remember correctly you should have a similar check for firmware files option during upgrades as during install. Did you check your (or root's) mail ? I think there might be a message telling whether it was necessary to update any firmware files. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? AFAICT the tool used is fw_update(1). $ file /usr/sbin/fw_update /usr/sbin/fw_update: Bourne shell script text executable You could check this script to see if it has any clues to help you fulfill your expectations.
Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 06:51:05PM +0100, Ingo Schwarze wrote: Hi Dave, Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500: and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. The firmwares live in a different package repository, that's why pkg_add(1) doesn't find them by default. If you do want to check for new firmwares, take the above message as a reminder to run $ sudo fw_update manually. But note that's not necessarily related to doing an operating system upgrade. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), I'm not sure i would want pkg_add(1) to look outside the PKG_PATH. and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, The only (potential, minor) problem i see is that people might run pkg_add(1), see the couldn't find, and not know about fw_update(1). That's probably what happened to you. I'm not sure how to improve that. Messages printed by programs should be terse, so i don't think pkg_add(1) should print a suggestion to run fw_update(1) when it sees *-firmware-* packages it can't update. Most people will know that anyway, and there is no strong reason to check for firmware updates at that particular time. Maybe it could be mentioned in the pkg_add(1) manual. Then again, that manual doesn't document the Couldn't find updates diagnostic at all, so far. do the installer and pkg_add developers not talk to each other, Actually, i have met all of krw@, halex@ and espie@ at least twice during hackathons, but never together; so you may have a point... :-D /irony But no, that's not the root cause of the issue. Yours, Ingo i guess we haven;t done a great job of advertising fw_update. for example, no other man page references the tool. it certainly isn;t helpful that pkg_add informs you that it hasn;t been able to find updates. i'm not sure how easy it would be to fix, but it might be better if it said nothing at all (though then you would probably forget they were installed at all). i think at a minimum pkg_add probably should document that fw_update handles non-free firmware, and we should probably update the packages section of afterboot(8) too. however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. jmc
Re: 'pkg_add -u' question
On Sat, 14 Jan 2012, Ingo Schwarze wrote: Hi Dave, Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500: and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. The firmwares live in a different package repository, that's why pkg_add(1) doesn't find them by default. If you do want to check for new firmwares, take the above message as a reminder to run $ sudo fw_update manually. But note that's not necessarily related to doing an operating system upgrade. Thanks for the pointer; fw_update looks like it's exactly what I need. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), I'm not sure i would want pkg_add(1) to look outside the PKG_PATH. and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, The only (potential, minor) problem i see is that people might run pkg_add(1), see the couldn't find, and not know about fw_update(1). That's probably what happened to you. Yes. I'm not sure how to improve that. Messages printed by programs should be terse, so i don't think pkg_add(1) should print a suggestion to run fw_update(1) when it sees *-firmware-* packages it can't update. Most people will know that anyway, and there is no strong reason to check for firmware updates at that particular time. Maybe it could be mentioned in the pkg_add(1) manual. Then again, that manual doesn't document the Couldn't find updates diagnostic at all, so far. Perhaps when the 'Install non-free firmware files on first boot' option is selected the installer should mention fw_update? And/or 'pkg_add -u' should mention it as a possible solution if it issues the couldn't find message? I probably should have tried 'apropos firmware', but was fixated on pkg_add and didn't think to look for a different tool. _Some_ sort of more prominent mention of fw_update appears to be desirable. Dave do the installer and pkg_add developers not talk to each other, Actually, i have met all of krw@, halex@ and espie@ at least twice during hackathons, but never together; so you may have a point... :-D /irony But no, that's not the root cause of the issue. Yours, Ingo -- Dave Anderson d...@daveanderson.com
Re: 'pkg_add -u' question
On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. fw_update is run automatically on the first boot after you upgrade via the usual installer (bsd.rd / install51.iso / cd51.iso etc).
Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 10:13:07PM +, Stuart Henderson wrote: On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. fw_update is run automatically on the first boot after you upgrade via the usual installer (bsd.rd / install51.iso / cd51.iso etc). right. but is there any reason to discourage people from running it when they please, or do we just expect it to be done automatically after upgrade? i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? jmc
Re: 'pkg_add -u' question
Jason McIntyre [j...@cava.myzen.co.uk] wrote: right. but is there any reason to discourage people from running it when they please, or do we just expect it to be done automatically after upgrade? i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? How often is firmware updated without a maching driver update? fw_update is really just to provide an automated fuction during install or upgrade, the same time when you are getting a new kernel/drier, it would be rare that a new firmware is available for an existing system, although potentially useful given how buggy some of these things are. -- There are only three sports: bullfighting, motor racing, and mountaineering; all the rest are merely games. - E. Hemingway
Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 10:13:07PM +, Stuart Henderson wrote: On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: however i'm not sure when the author intended fw_update to be used. i.e. in the course of upgrading or whenever you please. fw_update is run automatically on the first boot after you upgrade via the usual installer (bsd.rd / install51.iso / cd51.iso etc). right. but is there any reason to discourage people from running it when they please, or do we just expect it to be done automatically after upgrade? i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? people can run fw_update any time they want to, and yes if there are newer firmwares it will pick them up.
Re: 'pkg_add -u' question
How often is firmware updated without a maching driver update? fw_update is really just to provide an automated fuction during install or upgrade, the same time when you are getting a new kernel/drier, it would be rare that a new firmware is available for an existing system, although potentially useful given how buggy some of these things are. it has already happened plenty of times before fw_update was created -- as a result, why fw_update was created by halex at my request. in that timeframe since, no new firmwares have shown up in the place where fw_update looks. unfortunately that is not proof that this will not happen in the future. so the answer to your question is: At least once in the future.
Re: 'pkg_add -u' question
I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? It is not simple. While pkg_add has a PATH that it will look at, last time I tried this it only uses the first component of the path that is successful. It does not want to mix contents. Anyways, the result is that this does not work. Until it does, use fw_update.
pkg_add -u question
man pkg_add states: -u Update the given pkgname(s), and anything it depends upon. If no pkgname is given, pkg_add will update all installed packages. This relies on PKG_PATH to figure out the new package names. However if I run -u with no package name, it tells me a list of possible candidates, but doesn't actually update anything. I have to manually do each one. Am I doing something wrong or is this expected for some reason? (on i386) # dmesg | head -1 OpenBSD 4.1-stable (GENERIC) #0: Sat May 5 21:34:13 EDT 2007 # echo $PKG_PATH ftp://ftp.nyc.openbsd.org/pub/OpenBSD/4.1/packages/i386/ # pkg_add -u Candidates for updating autossh-1.2g - autossh-1.3 Candidates for updating bzip2-1.0.3 - bzip2-1.0.4 Candidates for updating cdrtools-2.01 - cdrtools-2.01p0 Looking for updates: complete # Any ideas?
Re: pkg_add -u question
pkg_add -ui On 5/6/07, Clint M. Sand [EMAIL PROTECTED] wrote: man pkg_add states: -u Update the given pkgname(s), and anything it depends upon. If no pkgname is given, pkg_add will update all installed packages. This relies on PKG_PATH to figure out the new package names. However if I run -u with no package name, it tells me a list of possible candidates, but doesn't actually update anything. I have to manually do each one. Am I doing something wrong or is this expected for some reason? (on i386) # dmesg | head -1 OpenBSD 4.1-stable (GENERIC) #0: Sat May 5 21:34:13 EDT 2007 # echo $PKG_PATH ftp://ftp.nyc.openbsd.org/pub/OpenBSD/4.1/packages/i386/ # pkg_add -u Candidates for updating autossh-1.2g - autossh-1.3 Candidates for updating bzip2-1.0.3 - bzip2-1.0.4 Candidates for updating cdrtools-2.01 - cdrtools-2.01p0 Looking for updates: complete # Any ideas? -- Julien Cabillot
Re: pkg_add -u question
On Sun, May 06, 2007 at 04:28:45PM +0200, Cabillot Julien wrote: pkg_add -ui Ah. Thanks. Seems the man page should be changed to be more clear. If no pkgname is given and -u is combined with -i, pkg_add will... On 5/6/07, Clint M. Sand [EMAIL PROTECTED] wrote: man pkg_add states: -u Update the given pkgname(s), and anything it depends upon. If no pkgname is given, pkg_add will update all installed packages. This relies on PKG_PATH to figure out the new package names. However if I run -u with no package name, it tells me a list of possible candidates, but doesn't actually update anything. I have to manually do each one. Am I doing something wrong or is this expected for some reason? (on i386) # dmesg | head -1 OpenBSD 4.1-stable (GENERIC) #0: Sat May 5 21:34:13 EDT 2007 # echo $PKG_PATH ftp://ftp.nyc.openbsd.org/pub/OpenBSD/4.1/packages/i386/ # pkg_add -u Candidates for updating autossh-1.2g - autossh-1.3 Candidates for updating bzip2-1.0.3 - bzip2-1.0.4 Candidates for updating cdrtools-2.01 - cdrtools-2.01p0 Looking for updates: complete # Any ideas? -- Julien Cabillot
Re: pkg_add -u question
On Sun, May 06, 2007 at 10:16:11AM -0400, Clint M. Sand wrote: man pkg_add states: -u Update the given pkgname(s), and anything it depends upon. If no pkgname is given, pkg_add will update all installed packages. This relies on PKG_PATH to figure out the new package names. However if I run -u with no package name, it tells me a list of possible candidates, but doesn't actually update anything. I have to manually do each one. Am I doing something wrong or is this expected for some reason? (on i386) # dmesg | head -1 OpenBSD 4.1-stable (GENERIC) #0: Sat May 5 21:34:13 EDT 2007 # echo $PKG_PATH ftp://ftp.nyc.openbsd.org/pub/OpenBSD/4.1/packages/i386/ # pkg_add -u Candidates for updating autossh-1.2g - autossh-1.3 Candidates for updating bzip2-1.0.3 - bzip2-1.0.4 Candidates for updating cdrtools-2.01 - cdrtools-2.01p0 Looking for updates: complete # Any ideas? Try pkg_add -iu -F update -F updatedepends instead. You will have better results. -- James Turner http://calminferno.net
