Re: pkg_add -u
> Hello > > i did an upgrade from 7.1 to 7.2, everything went well, but, i did an > upgrade from 7.2 to 7.3 and then i got this message: > > ListUtil.c: loadable library and perl binaries are mismatched (got first > handshake key 0xec0, needed 0xeb8) > > The procedure for both upgrades was: > > # sysupgrade > # syspatch > # pkg_add -u > > What is wrong, and how to repair it please? > > Thanks. > > Ops i found the answer at misc archives: https://marc.info/?l=openbsd-misc&m=163762126127301&w=2 The point is that the server had a previous Administration, and then i did not know that there are some extraneous packages installed. I appreciate any other opinion. Thanks.
Re: `pkg_add -u` and caching
On Sun, Jul 9, 2023 at 11:11 Morgan Aldridge wrote: > Hi misc@ and Marc, > > I have a script for applying all updates/upgrades for upgrading my OpenBSD > workstation, dev machines, and servers. I'm currently in the process of > improving it to better support downloading pending updates in advance of > actual review and installation (see < > https://github.com/morgant/swupdate-openbsd/issues/14>. I've been > studying the pkg_add(1) manual, testing, and also reviewing the pkg_add > Perl source in src/usr.sbin/pkg_add/OpenBSD/, but while really well > structured and easy to read, the latter does take me longer to grok than > the former. > > I'm hoping you have a quick answer (even if it's 'no') to the following > question: Does `pkg_add -u` utilize PKG_CACHE other than with the `-n` > option? > > In my testing (on amd64/7.3-stable), the following will check for updates > and copy packages to `PKG_CACHE`, as described in pkg_add(1): > > PKG_CACHE=/home/_swupdate/7.3/packages/amd64 pkg_add -nu > > If I delete a cached package from the PKG_CACHE directory, re-executing > the above command will redownload the package. That's what I was hoping > for. I'm not quite sure whether some of the packages are being > re-downloaded by just looking at file modification dates (unfortunately, > `-v` doesn't note downloads, nor cache mis/hit.) > > The following seems to try to update packages from PKG_CACHE, if passed in > as PKG_PATH, but -- understandably -- does result in errors that some > packages (those that didn't need updates or have dependencies that did) > could not be found: > > PKG_PATH=/home/_swupdate/7.3/packages/amd64 pkg_add -u > > Naturally, if I append ':installpath' to the above PKG_PATH, it will not > give such errors: > > PKG_PATH=/home/_swupdate/7.3/packages/amd64:installpath pkg_add -u > > However, since '-v' also doesn't note which package repository (esp. > local or not) a package was processed from, I don't know whether it's > actually preferring the local repository. > > Additionally, if I set both PKG_CACHE and PKG_PATH to `pkg_add -u`, it > doesn't appear that packages are downloaded to PKG_CACHE: > > PKG_CACHE=/home/_swupdate/7.3/packages/amd64 > /home/_swupdate/7.3/packages/amd64 > pkg_add -u > Typo. The above command should have been: PKG_CACHE=/home/_swupdate/7.3/packages/amd64 \ PKG_PATH=/home/_swupdate/7.3/packages/amd64 \ pkg_add -u This is confirmed by deleting a package from PKG_CACHE and re-executing the > above, after which the deleted package is still missing from PKG_CACHE. Of > course, this absolutely feels sketchy to be caching to a package > repository, but was worth a try. > Thanks in advance and please CC me if replying to the list as I'm not subscribed to misc@. Morgan > -- Morgan --- http://makkintosshu.com/ https://centresteer.com/ https://tobuji.tech/ http://unna.org/
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
> Please reconsider my suggestion made on 2022-01-14: Everybody wants to be a dev.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Mon, Jan 24, 2022 at 10:21:33AM +0100, Harald Dunkel wrote: > I highly appreciate the carefulness, but the error message doesn't > indicate a user "_pkgfetch", nor is it mentioned on pkg_add(1). > Please reconsider my suggestion made on 2022-01-14: > Note that smtpd(8) doesn't mention all the users and processes it used for privilege separation either. Those are implementation details and will work out-of-the-box unless you fiddle with parts you're not supposed to touch. and if you touch those parts... you're supposed to know where to look and how things work in the background.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
I highly appreciate the carefulness, but the error message doesn't indicate a user "_pkgfetch", nor is it mentioned on pkg_add(1). Please reconsider my suggestion made on 2022-01-14: > In general, if there is a permission problem due to file system > access bits, then it would be wise to include euid and egid in > the error message. Thank you very much Harri
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. Because we use this nifty technique called privilege separation to alleviate issues with bugs. Most specifically, pkg_add runs as root, which has wy too many rights, so it doesn't connect to the network directly, it starts ftp(1), which runs as _pkgfetch, which passes its result to signify which can check that the archive is properly signed before decompressing it with the zlib and finally putting the result on your disk. It's not rocket science, privilege separation has been around for over 20 years at this point ;)
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. > > If there was another user account involved, then show me. The user is called _pkgfetch -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-17 18:02:25, Marc Espie wrote: Lol. cert.pem only contains public certificates. Insisting on only root being able to read it means you are going to run code as root which doesn't require it. That seems way more unreasonable than your original assumption. I am not arguing about the access permissions (which I screwed up), but I wonder why pkg_add run by root failed with EPERM? Actually root was the only one *permitted* to access this file. Thats not an error. If there was another user account involved, then show me.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14, Harald Dunkel wrote: > On 2022-01-14 10:42:56, Harald Dunkel wrote: >> >> Hi folks, >> >> trying to upgrade the installed packages I get >> >> # pkg_add -u >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > chmod a+rx /etc/ssl > > did the trick, but this doesn't look reasonable. Lol. cert.pem only contains public certificates. Insisting on only root being able to read it means you are going to run code as root which doesn't require it. That seems way more unreasonable than your original assumption.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
OpenBSD default is for /etc/ssl/ to be root:wheel u+w,a+rx Harold, you broke your own machine. Stuart Henderson wrote: > On 2022-01-14, Harald Dunkel wrote: > > On 2022-01-14 10:42:56, Harald Dunkel wrote: > >> > >> Hi folks, > >> > >> trying to upgrade the installed packages I get > >> > >> # pkg_add -u > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS > >> connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission > >> denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect > >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty > >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > > > chmod a+rx /etc/ssl > > > > did the trick, but this doesn't look reasonable. > > Why would that not be reasonable? It's setting it back to the default > permissions after whatever change you've made to it. > > There are various system daemons and utilities (including sysupgrade, > syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will > want to make TLS connections as a non-root user, at least in some > configurations. Some of these may open cert.pem while they still have > privileges but not always. > > > In general, if there is a permission problem due to file system > > access bits, then it would be wise to include euid and egid in > > the error message. > > Not sure if that helps really. If you'd seen that, maybe you would have > fixed it for _pkgfetch and not noticed some other software that would > like to use it.. > >
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14, Harald Dunkel wrote: > On 2022-01-14 10:42:56, Harald Dunkel wrote: >> >> Hi folks, >> >> trying to upgrade the installed packages I get >> >> # pkg_add -u >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > chmod a+rx /etc/ssl > > did the trick, but this doesn't look reasonable. Why would that not be reasonable? It's setting it back to the default permissions after whatever change you've made to it. There are various system daemons and utilities (including sysupgrade, syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will want to make TLS connections as a non-root user, at least in some configurations. Some of these may open cert.pem while they still have privileges but not always. > In general, if there is a permission problem due to file system > access bits, then it would be wise to include euid and egid in > the error message. Not sure if that helps really. If you'd seen that, maybe you would have fixed it for _pkgfetch and not noticed some other software that would like to use it..
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
| This happens on 2 OpenBSD hosts. On 5 others there is no such problem. Do you have an explanation why the 2 host out of 7 are behaving different? I don't find it "reasonable" that 2 host out of 7 manifest some different behavior on their own.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14 10:42:56, Harald Dunkel wrote: Hi folks, trying to upgrade the installed packages I get # pkg_add -u https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... chmod a+rx /etc/ssl did the trick, but this doesn't look reasonable. In general, if there is a permission problem due to file system access bits, then it would be wise to include euid and egid in the error message. Harri
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
On 2021-10-15, cho...@jtan.com wrote: > Bingo. I was even told about it in the email I ignored (there's > nothing wrong with *69): :) Been there done that. (If I am anywhere near tight on space in /usr I usually try to upgrade with the "untar on running system" method with a root shell open so I have some hope of fixing it..) And I have a number of systems where I have a gap in partition letters after growfs'ing /usr into what was previously the partition after it on disk. > Time to reinstall on a bigger disc. Thanks for the pointer, that > saves me some perplexed digging around. Good files to kill if you need to quickly make some breathing space (but of course will come back after reinstalling all sets): /usr/lib/lib[a-bd-z]*.a /usr/share/man Unless you are doing installs directly under /usr (usually self built software), removing everything reported by "sysclean | grep ^/usr" should be safe. It takes care of libraries needed for installed packages so you can try cleaning, making sure you have xbase and base sets fully unpacked, update packages, then run sysclean again and it will probably allow you to free up some more shared libraries. > btw Some of the space used on /usr will be old libraries (it's at > least as old as 6.8, clearly), but for the record it looks like the > minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), > 240MB for /usr/X11R6 and <75MB for everything else if the box isn't > doing a great deal. FWIW I usually try to give /usr at least 5GB. Maybe slight overkill but it's such a pain to shuffle partitions I'd rather waste a bit of space than have to do that again. The other place I often run out is / on systems where I run current as I often have a few different kernels lying around from trying to bisect when a problem was introduced. -- Please keep replies on the mailing list.
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Oh and it's also worth noting that despite that massive cock-up, the box is still (now) running just fine on this frankenhybrid and serving its git repositories and running its crons, all entirely hands-off and automated: # uname -a && uptime OpenBSD smoke.datum 7.0 GENERIC#224 amd64 4:29AM up 10:49, 2 users, load averages: 0.05, 0.02, 0.01 That's how engineering works. Take that, devops. Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Stuart Henderson writes: > On 2021-10-14, cho...@jtan.com wrote: > > Turns out, one of my less important boxes was still on 6.8. Whoops. > > > > After two sysupgrades, this is the result of pkg_add -u: > > > > quirks-4.53 signed on 2021-10-12T20:12:39Z > > Can't install cairo-1.16.0 because of libraries > >|library pixman-1.40.0 not found > > That file is in xserv70.tgz so you shouldn't be having that problem unless the > untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok > for > disk space in /usr/X11R6? Bingo. I was even told about it in the email I ignored (there's nothing wrong with *69): Installing base70.tgz91% |*** | 275 MB00:01 ETAtar: Failed write to file ./usr/share/relink/kernel.tgz: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libc.so.96.1.a: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libcrypto.so.47.0.a: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-CARP-MIB.txt: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-PF-MIB.txt: No space left on device Installing base70.tgz99% |* | 301 MB00:00 ETAtar: Failed write to file ./usr/share/zoneinfo/CST6CDT: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Paris: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Zaporozhye: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Pacific/Fiji: No space left on device Installing base70.tgz 100% |**| 302 MB00:14 Installation of base70.tgz failed. Continue anyway? [no] no Time to reinstall on a bigger disc. Thanks for the pointer, that saves me some perplexed digging around. Matthew btw Some of the space used on /usr will be old libraries (it's at least as old as 6.8, clearly), but for the record it looks like the minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), 240MB for /usr/X11R6 and <75MB for everything else if the box isn't doing a great deal.
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
On 2021-10-14, cho...@jtan.com wrote: > Turns out, one of my less important boxes was still on 6.8. Whoops. > > After two sysupgrades, this is the result of pkg_add -u: > > quirks-4.53 signed on 2021-10-12T20:12:39Z > Can't install cairo-1.16.0 because of libraries >|library pixman-1.40.0 not found That file is in xserv70.tgz so you shouldn't be having that problem unless the untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok for disk space in /usr/X11R6? > This will not be difficult to fix; remove and reinstall will probably > do it. If this is the result of me skipping pkg_add -u on the 6.9 > hop then there's nothing to see here but I've done the same thing > a few times before without incident (I expect problems if I skip > base releases, not so much with ports) so if this problem's unexpected, > well, here it is. I've done a few from 6.8 direct to 7.0 (skipping base and package updates) and probably some from earlier, it's rare (read: I don't remember it happening) that I have any problems attributed to skipping versions. Not recommended unless you know how to fix things if they do arise, but still..
Re: pkg_add -u: no such dir
Jan Betlach @ 2020-05-05 17:05 IST: > Is 6.7 being released already? No, they're probably using a snapshot. signature.asc Description: PGP signature
Re: pkg_add -u: no such dir
Thanks. My bad, I’ve realized that as soon as I’ve hit the send button. On 5 May 2020, at 17:19, Andinus wrote: > Jan Betlach @ 2020-05-05 17:05 IST: > >> Is 6.7 being released already? > > No, they're probably using a snapshot.
Re: pkg_add -u: no such dir
Is 6.7 being released already? Jan On 5 May 2020, at 13:28, Groot wrote: > I tried updating all applications, only to be greeted with > the following message. > > doas pkg_add -u > https://ftp.OpenBSD.org/pub/OpenBSD/6.7/packages/amd64/: no such dir > list of applications > > I'm sure someone must have noticed by now. > Only the directories within https://ftp.OpenBSD.org/pub/OpenBSD/6.7/ > give 404 Not found error in a browser.
Re: pkg_add -u: no such dir
Hi, Groot wrote on Tue, May 05, 2020 at 04:58:34PM +0530: > I tried updating all applications, only to be greeted with > the following message. You don't say so explicitly, but let's assume you upgraded to the latest snapshot. While that is not the final 6.7 release yet, the operating system release string as returned by "uname -r" was already switched to "6.7" (without -beta) in preparation for release, so your upgraded system already tries to use 6.7 release packages, which do not exist yet. > doas pkg_add -u > https://ftp.OpenBSD.org/pub/OpenBSD/6.7/packages/amd64/: no such dir > list of applications > > I'm sure someone must have noticed by now. > Only the directories within https://ftp.OpenBSD.org/pub/OpenBSD/6.7/ > give 404 Not found error in a browser. That's expected. For now, use "pkg_add -u -D snap" as documented here: https://man.openbsd.org/pkg_add.1#snap Yours, Ingo
Re: pkg_add -u fails on nonexistant package
On Thu, Aug 22, 2019 at 07:40:28AM -0500, Jordon wrote: > Thanks - that fixed it. I figured there was some cleanup or maintenance that > needed to be done - i just didn't know how to do it. In running pkg_check, i > did get a lot of these: Packages normally don't need maintenance. What you're seeing looks like a very unclean unmount at some point or a failing disk. pkg_check will recover the best it can from these. It was originally written for other developers, who tend to crash their testing kernels a lot... shouldn't happen THAT much for non kernel developers/crash-test bunnies.
Re: pkg_add -u fails on nonexistant package
Yeah, back before Skylake was supported. I did get a pre-Skylake system (broadwell, i think) that is the openbsd system i am using now. I did get it performing ok, but it was lacking some features. I think it was audio/video sources but i could be wrong. That was a couple years ago! :) Anyway, i tried that command and i think it got rid of some of the errors. There are still a few but im pretty sure it is fewer than it was. Thanks! > On Aug 22, 2019, at 11:50, Stuart Henderson wrote: > > On 2019-08-21, Jordon wrote: >> A few years ago I attempted to make a port of obs-studio for openbsd. >> With help from this mailing list, I got something that ran but >> wasn\xe2\x80\x99t >> particularly useful, as audio and video sources were not there. > > erm, audio and video sources did work, via ffmpeg. > it didn't work well on your machine though. > > https://marc.info/?l=openbsd-ports&m=148404688530732&w=2 > >> On 2019-08-22, Jordon wrote: >> Thanks - that fixed it. I figured there was some cleanup or maintenance >> that needed to be done - i just didn't know how to do it. In running >> pkg_check, i did get a lot of these: >> >> --- .libs9-partial-gcc-libs-8.3.0p1.1 --- >> lib should exist >> lib is not a directory >> lib/libatomic.so.3.0 should exist >> lib/libatomic.so.3.0 is not a file >> can't read lib/libatomic.so.3.0 >> lib/libestdc++.so.19.0 should exist >> lib/libestdc++.so.19.0 is not a file >> can't read lib/libestdc++.so.19.0 >> >> Are those problematic? How do I fix them or should I just ignore them? > > you probably either had some crash or failure during a pkg_add or pkg_delete > operation, or some filesystem corruption. > > does pkg_delete .libs9-partial-gcc-libs get rid of it? > >
Re: pkg_add -u fails on nonexistant package
I do the package upgrades as root (‘su -‘) and I’m pretty sure I was doing the pkg_check commands in the same terminal this morning. > On Aug 22, 2019, at 11:00, Isak Holmstroem wrote: > > How did you run the command? As your user or with doas/or as root? > > I have seen problems with permissions with pkg_check as my user can not read > all the directories that pkg_check are trying to read. > > /Isak > >> >> From: Jordon >> Sent: Thu Aug 22 14:40:28 CEST 2019 >> To: Isak Holmström >> Cc: >> Subject: Re: pkg_add -u fails on nonexistant package >> >> >> Thanks - that fixed it. I figured there was some cleanup or maintenance >> that needed to be done - i just didn't know how to do it. In running >> pkg_check, i did get a lot of these: >> >> --- .libs9-partial-gcc-libs-8.3.0p1.1 --- >> lib should exist >> lib is not a directory >> lib/libatomic.so.3.0 should exist >> lib/libatomic.so.3.0 is not a file >> can't read lib/libatomic.so.3.0 >> lib/libestdc++.so.19.0 should exist >> lib/libestdc++.so.19.0 is not a file >> can't read lib/libestdc++.so.19.0 >> >> Are those problematic? How do I fix them or should I just ignore them? >> >> Thanks again! >> >> >> >> >>>>> On Aug 22, 2019, at 00:27, Isak Holmström wrote: >>> Have you tried pkg_check to see failing messages for missing files? >>> >>>> On August 21, 2019 11:03:06 PM UTC, Jordon wrote: >>>> A few years ago I attempted to make a port of obs-studio for openbsd. >>>> With help from this mailing list, I got something that ran but wasn’t >>>> particularly useful, as audio and video sources were not there. I gave >>>> up on that project and since then have been using that machine for >>>> local development on a cgi-based website. >>>> This system runs current and gets updated about once a week or so. I >>>> also try to do a ‘pkg_add -u’ regularly too. Every time I do that, it >>>> ends with this: >>>> Fatal error: can't parse OpenBSD::Requiring: writing >>>> /var/db/pkg/obs-studio-17.0.0/+REQUIRING: No such file or directory at >>>> /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 30. >>>> >>>> That is the package I was making and it is no longer installed. How >>>> does pkg_add even know about it, as it isn't part of the base packages? >>>> What can I do to get rid of that message? It has been doing that for a >>>> while and I am finally annoyed enough to try to fix it! >>>> >>>> Jordon >>> >>> -- >>> Isak - OBSD.xyz >>
Re: pkg_add -u fails on nonexistant package
On 2019-08-21, Jordon wrote: > A few years ago I attempted to make a port of obs-studio for openbsd. > With help from this mailing list, I got something that ran but > wasn\xe2\x80\x99t > particularly useful, as audio and video sources were not there. erm, audio and video sources did work, via ffmpeg. it didn't work well on your machine though. https://marc.info/?l=openbsd-ports&m=148404688530732&w=2 On 2019-08-22, Jordon wrote: > Thanks - that fixed it. I figured there was some cleanup or maintenance that > needed to be done - i just didn't know how to do it. In running pkg_check, i > did get a lot of these: > > --- .libs9-partial-gcc-libs-8.3.0p1.1 --- > lib should exist > lib is not a directory > lib/libatomic.so.3.0 should exist > lib/libatomic.so.3.0 is not a file > can't read lib/libatomic.so.3.0 > lib/libestdc++.so.19.0 should exist > lib/libestdc++.so.19.0 is not a file > can't read lib/libestdc++.so.19.0 > > Are those problematic? How do I fix them or should I just ignore them? you probably either had some crash or failure during a pkg_add or pkg_delete operation, or some filesystem corruption. does pkg_delete .libs9-partial-gcc-libs get rid of it?
Re: pkg_add -u fails on nonexistant package
How did you run the command? As your user or with doas/or as root? I have seen problems with permissions with pkg_check as my user can not read all the directories that pkg_check are trying to read. /Isak > > From: Jordon > Sent: Thu Aug 22 14:40:28 CEST 2019 > To: Isak Holmström > Cc: > Subject: Re: pkg_add -u fails on nonexistant package > > > Thanks - that fixed it. I figured there was some cleanup or maintenance that > needed to be done - i just didn't know how to do it. In running pkg_check, i > did get a lot of these: > > --- .libs9-partial-gcc-libs-8.3.0p1.1 --- > lib should exist > lib is not a directory > lib/libatomic.so.3.0 should exist > lib/libatomic.so.3.0 is not a file > can't read lib/libatomic.so.3.0 > lib/libestdc++.so.19.0 should exist > lib/libestdc++.so.19.0 is not a file > can't read lib/libestdc++.so.19.0 > > Are those problematic? How do I fix them or should I just ignore them? > > Thanks again! > > > > > >> On Aug 22, 2019, at 00:27, Isak Holmström wrote: > > Have you tried pkg_check to see failing messages for missing files? > > > >> On August 21, 2019 11:03:06 PM UTC, Jordon wrote: > >> A few years ago I attempted to make a port of obs-studio for openbsd. > >> With help from this mailing list, I got something that ran but wasn’t > >> particularly useful, as audio and video sources were not there. I gave > >> up on that project and since then have been using that machine for > >> local development on a cgi-based website. > >> This system runs current and gets updated about once a week or so. I > >> also try to do a ‘pkg_add -u’ regularly too. Every time I do that, it > >> ends with this: > >> Fatal error: can't parse OpenBSD::Requiring: writing > >> /var/db/pkg/obs-studio-17.0.0/+REQUIRING: No such file or directory at > >> /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 30. > >> > >> That is the package I was making and it is no longer installed. How > >> does pkg_add even know about it, as it isn't part of the base packages? > >> What can I do to get rid of that message? It has been doing that for a > >> while and I am finally annoyed enough to try to fix it! > >> > >> Jordon > > > > -- > > Isak - OBSD.xyz >
Re: pkg_add -u fails on nonexistant package
Thanks - that fixed it. I figured there was some cleanup or maintenance that needed to be done - i just didn't know how to do it. In running pkg_check, i did get a lot of these: --- .libs9-partial-gcc-libs-8.3.0p1.1 --- lib should exist lib is not a directory lib/libatomic.so.3.0 should exist lib/libatomic.so.3.0 is not a file can't read lib/libatomic.so.3.0 lib/libestdc++.so.19.0 should exist lib/libestdc++.so.19.0 is not a file can't read lib/libestdc++.so.19.0 Are those problematic? How do I fix them or should I just ignore them? Thanks again! >> On Aug 22, 2019, at 00:27, Isak Holmström wrote: > Have you tried pkg_check to see failing messages for missing files? > >> On August 21, 2019 11:03:06 PM UTC, Jordon wrote: >> A few years ago I attempted to make a port of obs-studio for openbsd. >> With help from this mailing list, I got something that ran but wasn’t >> particularly useful, as audio and video sources were not there. I gave >> up on that project and since then have been using that machine for >> local development on a cgi-based website. >> This system runs current and gets updated about once a week or so. I >> also try to do a ‘pkg_add -u’ regularly too. Every time I do that, it >> ends with this: >> Fatal error: can't parse OpenBSD::Requiring: writing >> /var/db/pkg/obs-studio-17.0.0/+REQUIRING: No such file or directory at >> /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 30. >> >> That is the package I was making and it is no longer installed. How >> does pkg_add even know about it, as it isn't part of the base packages? >> What can I do to get rid of that message? It has been doing that for a >> while and I am finally annoyed enough to try to fix it! >> >> Jordon > > -- > Isak - OBSD.xyz
Re: pkg_add -u fails on nonexistant package
Thanks - that fixed it. I figured there was some cleanup or maintenance that needed to be done - i just didn't know how to do it. In running pkg_check, i did get a lot of these: --- .libs9-partial-gcc-libs-8.3.0p1.1 --- lib should exist lib is not a directory lib/libatomic.so.3.0 should exist lib/libatomic.so.3.0 is not a file can't read lib/libatomic.so.3.0 lib/libestdc++.so.19.0 should exist lib/libestdc++.so.19.0 is not a file can't read lib/libestdc++.so.19.0 Are those problematic? How do I fix them or should I just ignore them? Thanks again! Jordon > On Aug 22, 2019, at 00:27, Isak Holmström wrote: > > Have you tried pkg_check to see failing messages for missing files? > >> On August 21, 2019 11:03:06 PM UTC, Jordon wrote: >> A few years ago I attempted to make a port of obs-studio for openbsd. >> With help from this mailing list, I got something that ran but wasn’t >> particularly useful, as audio and video sources were not there. I gave >> up on that project and since then have been using that machine for >> local development on a cgi-based website. >> This system runs current and gets updated about once a week or so. I >> also try to do a ‘pkg_add -u’ regularly too. Every time I do that, it >> ends with this: >> Fatal error: can't parse OpenBSD::Requiring: writing >> /var/db/pkg/obs-studio-17.0.0/+REQUIRING: No such file or directory at >> /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 30. >> >> That is the package I was making and it is no longer installed. How >> does pkg_add even know about it, as it isn't part of the base packages? >> What can I do to get rid of that message? It has been doing that for a >> while and I am finally annoyed enough to try to fix it! >> >> Jordon > > -- > Isak - OBSD.xyz >
Re: pkg_add -u fails on nonexistant package
Have you tried pkg_check to see failing messages for missing files? On August 21, 2019 11:03:06 PM UTC, Jordon wrote: >A few years ago I attempted to make a port of obs-studio for openbsd. >With help from this mailing list, I got something that ran but wasn’t >particularly useful, as audio and video sources were not there. I gave >up on that project and since then have been using that machine for >local development on a cgi-based website. >This system runs current and gets updated about once a week or so. I >also try to do a ‘pkg_add -u’ regularly too. Every time I do that, it >ends with this: >Fatal error: can't parse OpenBSD::Requiring: writing >/var/db/pkg/obs-studio-17.0.0/+REQUIRING: No such file or directory at >/usr/libdata/perl5/OpenBSD/RequiredBy.pm line 30. > >That is the package I was making and it is no longer installed. How >does pkg_add even know about it, as it isn't part of the base packages? >What can I do to get rid of that message? It has been doing that for a >while and I am finally annoyed enough to try to fix it! > >Jordon -- Isak - OBSD.xyz
Re: pkg_add -u skipping mutt and python
On 2017-10-26, Alex Holst wrote: > mutt is linked against two libc. To make matters worse, I am running > mutt 1.6.2 from 6.0, not 1.9.x from OpenBSD 6.2. Mutt isn't linked against two libc. Some of the libraries it use have been updated (pulling in new libc) but mutt itself hasn't been updated. > Skipping mutt-1.9.1v3-gpgme-sasl (update candidate for > mutt-1.6.2v0-compressed-sasl-sidebar-slang) > mutt-1.6.2v0-compressed-sasl-sidebar-slang pkgpaths: > mail/mutt,sasl,sidebar,slang,compressed > mail/mutt/,slang,compressed,sidebar,sasl > mail/mutt/snapshot,sasl,sidebar,compressed,slang > mail/mutt/stable,sasl,slang,compressed,sidebar > mutt-1.9.1v3-gpgme-sasl pkgpaths: mail/mutt/stable,sasl,gpgme > mail/mutt/snapshot,sasl,gpgme mail/mutt,sasl,gpgme mail/mutt/,sasl,gpgme I just removed a stray / in the PLIST in the port in -current, which *may* be related, but honestly I would just pkg_delete and pkg_add the version you want. The maze of flavours makes it hard to get updates absolutely correct with all combinations. > [..] > Skipping python-3.6.2 (update candidate for python-3.4.5p2) > python-3.4.5p2 pkgpaths: lang/python/3.4,-main lang/python3/3.4,-main > python-3.6.2 pkgpaths: lang/python3/3.6,-main lang/python/3.6,-main This is working as currently designed (though I agree it's not totally useful). python/3.4 and python/3.6 are separate branches in ports and don't auto update between the branches, even though python 3.4 (and 3.5) have now been removed. Problem is, the module directories are different, so if you had some locally installed thing using 3.4 it probably wouldn't work directly with 3.6. Leaving them installed in parallel there's still some chance old programs will still run (up to a point).
Re: pkg_add -u skipping mutt and python
This is because pkgpaths differ from previous versions for both of them. >From pkg_add(1): "To update packages in -u mode, pkg_add performs the following steps. [...] 4. Candidates are then matched according to their pkgpaths in order to weed out similar packages with distinct options." In addition to pkg_add(1), you can read OpenBSD::Intro(3p), the PACKAGE UPDATES section. I suppose something was done wrong during the port update. Also, do you have two libc versions installed or they are simply linked to them? -- caóc
Re: pkg_add -u error
On 09/19/16 16:32, Edgar Pettijohn wrote: > I recently upgraded to the latest snapshot and when upgrading packages > I saw this: > > system(/bin/sh, -c, /usr/local/bin/mktexlsr > /dev/null 2>&1) failed: > exit(127) > > Which makes sense because there is no /usr/local/bin/mktexlsr on my system. > I searched for it with pkg_info -Q mktexlsr as well as other variations with > no luck. Not sure where to go from here. Ignore post to ports@? > > Any suggestions? You can use pkg_locate to find files in packages. # pkg_add pkglocatedb $ pkg_locate :/usr/local/bin/mktexlsr texlive_base-2015:print/texlive/base:/usr/local/bin/mktexlsr Best, > Thanks, signature.asc Description: OpenPGP digital signature
Re: pkg_add -u freezes after last snapshot
On 07/11/15 17:15, Joseph Oficre wrote: > Hello, misc. > My dmesg: > OpenBSD 5.8-beta (GENERIC.MP) #1141: Fri Jul 10 11:31:23 MDT 2015 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > RTC BIOS diagnostic error 80 > real mem = 8451125248 (8059MB) > avail mem = 8191127552 (7811MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (67 entries) > bios0: vendor LENOVO version "8BET62WW (1.42 )" date 07/26/2013 > bios0: LENOVO 428445G > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA > SSDT SSDT UEFI UEFI UEFI > acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) > EHC2(S3) HDEF(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.87 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > E > S,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > E > S,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > E > S,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > E > S,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 1, core 1, package 0 > cpu4 at mainbus0: apid 4 (application processor) > cpu4: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz > cpu4: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > E > S,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu4: 256KB 64b/line 8-way L2 cache > cpu4: smt 0, core 2, package 0 > cpu5 at mainbus0: apid 5 (application processor) > cpu5: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz > cpu5: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu5: 256KB 64b/line 8-way L2 cache > cpu5: smt 1, core 2, package 0 > cpu6 at mainbus0: apid 6 (application processor) > cpu6: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz > cpu6: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu6: 256KB 64b/line 8-way L2 cache > cpu6: smt 0, core 3, package 0 > cpu7 at mainbus0: apid 7 (application processor) > cpu7: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz > cpu7: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX > ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A > ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT > cpu7: 256KB 64b/line 8-way L2 cache > cpu7: smt 1, core 3, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0
Re: pkg_add -u and unneeded updates
Hi Marc, On Fri 24/10 14:58, Marc Espie wrote: [...] > > Look, either you use it as as simple user, and then you trust the tool. > Or you want to really understand what's going on and you have to dig deeper. > What pkg_add shows you *by default* is the simple story. > > Try pkg_add -v for more details. You'll figure it out. You're definitely right; I'll try to dig a bit deeper next time. Sorry for the noise. All the best -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: pkg_add -u and unneeded updates
On Fri 24/10 11:29, Ingo Schwarze wrote: Hi Ingo, > Almost certainly not unneeded; Marc Espie@ has spent a lot of effort > on getting that right. At least, you don't show any evidence for > that claim, or for any bug in this area. > My bad; I should have said "maybe unneeded?"... [...] > packages(7): > > The full version (package name and dependency names) is known as the > `update signature', and can be queried with pkg_info -S, for packages, > or make print-update-signature for ports. > [...] > > So, packages are automatically updated when new versions are available > compiled again newer libraries or newer dependencies, even if the > Makefile of the package itself (and hence its own version number) > did not change. That prevents .libs-* packages from needlessly > accumulating on your system. Got it; the "concept" of package signature was in fact obscure to me. Thanks a lot for your precious clarifications. All the best -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: pkg_add -u and unneeded updates
On Fri, Oct 24, 2014 at 08:25:59AM +0200, Alessandro DE LAURENZIS wrote: > Folks, > > I noticed that, when I update my packages using "pkg_add -u", some > unneeded re-installation are performed; in particular (examples below > are with the latest snapshot, Oct 23): > > - when a dependency needs update, all the dependencies and the package > itself are updated: > cups-1.7.5p2:openjpeg-1.5.1->1.5.1: ok > cups-1.7.5p2:poppler-0.26.5->0.26.5: ok > cups-1.7.5p2:poppler-utils-0.26.5->0.26.5: ok > cups-1.7.5p2:foomatic-db-engine-4.0.11p0->4.0.11p0: ok > cups-1.7.5p2:cups-filters-1.0.60->1.0.61: ok > cups-1.7.5p2->1.7.5p2: ok > > - some packages are updated even if version is unchanged: > xloadimage-4.1.22v0->4.1.22v0: ok > xpdf-3.04->3.04: ok > xzgv-0.9p4->0.9p4: ok > > According to pkg_add's man page > > "the update signature of the candidate > is compared to the signature of the already installed package: identical > signatures mean no update needed" > > so I think that signatures of those packages have changed w.r.t. the > previous snapshot, but what's the rationale here? Look, either you use it as as simple user, and then you trust the tool. Or you want to really understand what's going on and you have to dig deeper. What pkg_add shows you *by default* is the simple story. Try pkg_add -v for more details. You'll figure it out.
Re: pkg_add -u and unneeded updates
Hi Alessandro, Alessandro DE LAURENZIS wrote on Fri, Oct 24, 2014 at 08:25:59AM +0200: > I noticed that, when I update my packages using "pkg_add -u", some > unneeded re-installation are performed; Almost certainly not unneeded; Marc Espie@ has spent a lot of effort on getting that right. At least, you don't show any evidence for that claim, or for any bug in this area. [...] > - some packages are updated even if version is unchanged: > xloadimage-4.1.22v0->4.1.22v0: ok > xpdf-3.04->3.04: ok > xzgv-0.9p4->0.9p4: ok > > According to pkg_add's man page > > "the update signature of the candidate is compared to the signature > of the already installed package: identical signatures mean no update > needed" > > so I think that signatures of those packages have changed w.r.t. the > previous snapshot, but what's the rationale here? packages(7): The full version (package name and dependency names) is known as the `update signature', and can be queried with pkg_info -S, for packages, or make print-update-signature for ports. Try it: $ pkg_info -S xpdf Information for inst:xpdf-3.04 Signature: xpdf-3.04, @ghostscript-fonts-8.11p2,@openmotif-2.3.4p0,@png-1.6.13, ICE.10.0,SM.9.0,X11.16.0,Xext.13.0,Xm.6.0,Xpm.9.0,Xt.11.0,c.77.2, freetype.22.0,m.9.0,png.17.2,pthread.18.1,stdc++.57.0,z.5.0 So, packages are automatically updated when new versions are available compiled again newer libraries or newer dependencies, even if the Makefile of the package itself (and hence its own version number) did not change. That prevents .libs-* packages from needlessly accumulating on your system. Yours, Ingo
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
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 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
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 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 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 2012-01-14, Jason McIntyre 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
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
> 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.
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
> On Sat, Jan 14, 2012 at 10:13:07PM +, Stuart Henderson wrote: > > On 2012-01-14, Jason McIntyre 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
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 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
On 2012-01-14, Jason McIntyre 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, 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 > > >But no, that's not the root cause of the issue. > >Yours, > Ingo > -- Dave Anderson
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 > > > 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
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
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 But no, that's not the root cause of the issue. Yours, Ingo
Re: pkg_add -u updating same package
hmm, on Fri, Mar 06, 2009 at 07:54:53PM +, Stefan Sperling said that > On Fri, Mar 06, 2009 at 07:26:21PM +0100, Thomas Pfaff wrote: > > $ sudo pkg_add -ui > > ... > > libglade2-2.6.2p2 (extracting): complete > > libglade2-2.6.2p2 (deleting): complete > > libglade2-2.6.2p2 (installing): complete > > > > Maybe I'm just slow or haven't read the relevant FAQ, > > but what does this mean? (4.5-current using snapshot > > packages). > > I think this means that some library in base or in ports that > libglade depends on was updated. libglade itself was not updated, ^^^ > but recompiled against fresh dependencies. ^^ isn't that an update then? -f -- life is that brief interlude between nothingness and eternity.
Re: pkg_add -u updating same package
On Fri, Mar 06, 2009 at 07:26:21PM +0100, Thomas Pfaff wrote: > $ sudo pkg_add -ui > ... > libglade2-2.6.2p2 (extracting): complete > libglade2-2.6.2p2 (deleting): complete > libglade2-2.6.2p2 (installing): complete > > Maybe I'm just slow or haven't read the relevant FAQ, > but what does this mean? (4.5-current using snapshot > packages). I think this means that some library in base or in ports that libglade depends on was updated. libglade itself was not updated, but recompiled against fresh dependencies. Stefan
Re: pkg_add -u updating same package
On Fri, Mar 06, 2009 at 07:26:21PM +0100, Thomas Pfaff wrote: > $ sudo pkg_add -ui > ... > libglade2-2.6.2p2 (extracting): complete > libglade2-2.6.2p2 (deleting): complete > libglade2-2.6.2p2 (installing): complete > > Maybe I'm just slow or haven't read the relevant FAQ, > but what does this mean? (4.5-current using snapshot > packages). The package libglade2 was updated to one with other (newer?) dependancies. Regards, Markus
Re: pkg_add -u
Hi Fulvio, fulvio ciriaco wrote on Fri, Feb 29, 2008 at 10:59:29PM +0100: > I have some ports updated by me, > e.g. emacs-22.1, sawfish-1.3.3 ... > When trying > pkg_add -ui > Candidates for updating sawfish-1.3.3p0 -> sawfish-1.3p9 > Candidates for updating auctex-11.14p1 -> auctex-11.14p1 > ... > auctex installed by me, dependent on emacs-22.1 wants to be > replaced by auctex same version dependent on emacs-21.4, > Does pkg_add -u not check version number? No, currently, it only compares patch level numbers (not version numbers) and even that only within the same package repository. Perhaps setting your PKG_PATH might get part of your job done. The program pkg_add only considers the packages form the first repository in the PKG_PATH where it finds at least one matching one. With the current scheme, considering installed packages as an additional pseudo-repository is not possible and would not make any sense: If that pseudo-repository were put at the beginning, no package would ever get updated, were it put at the end, it would have no effect whatsoever. Consider export PKG_PATH=/usr/ports/packages/386/all/:ftp://openbsd.ftp.fu-berlin.de/snapshots/packages/i386/ or whatever architecture, flavor and mirror you are using. But if use such settings, do not forget regularly cleaning obsolete packages out of the directory /usr/ports/packages/386/all/. With the PKG_PATH shown above, they will always override the public mirror, even when they become outdated and the mirror has newer ones. Hope that helps, Ingo
Re: pkg_add -u
On Fri, Feb 29, 2008 at 10:59:29PM +0100, fulvio ciriaco wrote: > Hallo, > I have some ports updated by me, > e.g. emacs-22.1, sawfish-1.3.3 ... > When trying > pkg_add -ui > Candidates for updating sawfish-1.3.3p0 -> sawfish-1.3p9 > Candidates for updating auctex-11.14p1 -> auctex-11.14p1 > ... > auctex installed by me, dependent on emacs-22.1 wants to be > replaced by auctex same version dependent on emacs-21.4, > Does pkg_add -u not check version number? No.
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
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
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 says "Not updating .libs-$pkg, remember to clean it"
On Tue, Apr 24, 2007 at 02:16:38PM +0200, Peter N. M. Hansteen wrote: > while doing a 'pkg_add -ui -F update -F updatedepends' on a machine > with the most recent snapshot I could get my hands on, I get the > message > > Not updating .libs-ImageMagick-6.2.6.1, remember to clean it > > for a number of packages, apparently corresponding to directories > under /var/db/pkg. This being OpenBSD, I know it's most likely > harmless and informational, but I wonder - does this mean I should > 'clean out' these .libs-* directories by deleting them manually? > > That is, if they're still there after the pkg_add command completes. Yep. It needs some explaining. The .libs-* packages are stub-packages that still contain some shared libraries necessary for other packages, after an update. Say, you update foo-1.0 -> foo-2.0, you may end up with a libfoo.so.1.0 in .libs-foo-1.0, and the regular libfoo.so.2.0 in foo-2.0. This allows you to proceed with the update. The .libs-* packages do not get cleaned up automatically, because it is assumed you may have compiled other stuff outside of the packages' responsibility that still needs it.
Re: pkg_add -u says "Not updating .libs-$pkg, remember to clean it"
On 14:16 Tue 24 Apr , Peter N. M. Hansteen wrote: > for a number of packages, apparently corresponding to directories > under /var/db/pkg. This being OpenBSD, I know it's most likely > harmless and informational, but I wonder - does this mean I should > 'clean out' these .libs-* directories by deleting them manually? run pkg_delete /var/db/pkg/.libs* bye Julian
Re: pkg_add -u not working
On 6/21/06, Benjamin Collins <[EMAIL PROTECTED]> wrote: What I expect the tool to do if I invoke it like $ sudo pkg_add -u is to do this (from pkg_add(1)): If no pkgname is given, pkg_add will update all installed packages. What actually happens after the above invocation is what Sebastian pointed out - updatable package names are printed, but nothing is actually updated. This is exactly what happens in my 3.9-stable on i386 as well. But if I do: pkg_add -ui it updates the + dependencies just fine.
Re: pkg_add -u not working
On Tue, Jun 20, 2006 at 09:56:17AM -0500, Will Maier wrote: > On Tue, Jun 20, 2006 at 09:29:08AM -0500, Benjamin Collins wrote: > > What actually happens after the above invocation is what Sebastian > > pointed out - updatable package names are printed, but nothing is > > actually updated. > > And you're running 3.9 or -current? I've got one machine running -current, and two others running 3.9-stable. The behavior is the same on all three. [demime 1.01d removed an attachment of type application/pgp-signature]
Re: pkg_add -u not working
On Tue, Jun 20, 2006 at 06:41:09PM +0200, [EMAIL PROTECTED] wrote: | > On Tue, Jun 20, 2006 at 09:29:08AM -0500, Benjamin Collins wrote: | >> What actually happens after the above invocation is what Sebastian | >> pointed out - updatable package names are printed, but nothing is | >> actually updated. | > | > And you're running 3.9 or -current? | | 3.9-amd64 (stable). | But it was mentioned that there are no updated packages avaiable for amd64... | Yes I can update using Ports... but it`s realy not so good (compared to | pkg_add -ui). | | *my oppinion* | There are not so many updates in the STABLE-Branch so I realy don`t | understand why nobody can spend 3hrs of Compiling (a day, in the night, | even developers have to speel :)) ) STABLE Packages (just the updated | software! Not ALL Packages..). | It`s realy something I can`t understand if it deals with the great idea of | pkg_add -ui. | */my oppinion* Consider this for a bit. What do you need to do those 3 hours of compiling (even though I think it's more work to get updated packages) ? You'll need a machine to build them on. You need the this machine to run the STABLE version you want to build the package for. OpenBSD developers support two releases, so you'd need two machines (or boot between two versions in some way or another, adding to the time it take to release updated packages). How many pkg-archs does OpenBSD support ? see ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/ : alpha, amd64, arm, hppa, i386, m68k, m88k, mips64, powerpc, sparc, sparc64, vax. That's 12 * 2 = 24 package build machines. That's also 24 * 3 = 72 hours of work (granted, some stuff can be done in parallel but I still believe it to be more than three hours of work, especially since some archs are quite a bit slower than your run of the mill quad 3GHz AMD64 box). Please remember that OpenBSD is a multi-platform OS. All these resources could be used to further -current and the -current ports tree. I find it amazing developers find time to update packages for older releases for one arch. Anyway, as can be seen in a recent post from Nikolay Sturm, they are looking at supporting another arch. If you really want that support to be there, please consider donating. See http://www.undeadly.org/cgi?action=article&sid=20060619214229 for more info on this request. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: pkg_add -u not working
[EMAIL PROTECTED] [2006-06-20, 18:41:09]: > *my oppinion* > There are not so many updates in the STABLE-Branch so I realy don`t > understand why nobody can spend 3hrs of Compiling (a day, in the night, > even developers have to speel :)) ) STABLE Packages (just the updated > software! Not ALL Packages..). > It`s realy something I can`t understand if it deals with the great idea of > pkg_add -ui. > */my oppinion* we need a machine for this. see the recent story on undeadly: http://undeadly.org/cgi?action=article&sid=20060619214229 -- steven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: pkg_add -u not working
On Tue, Jun 20, 2006 at 06:41:09PM +0200, [EMAIL PROTECTED] wrote: > 3.9-amd64 (stable). > But it was mentioned that there are no updated packages avaiable for amd64... > Yes I can update using Ports... but it`s realy not so good (compared to > pkg_add -ui). Right; pkg_add is nice. > *my oppinion* > There are not so many updates in the STABLE-Branch so I realy > don`t understand why nobody can spend 3hrs of Compiling (a day, in > the night, even developers have to speel :)) ) STABLE Packages > (just the updated software! Not ALL Packages..). It`s realy > something I can`t understand if it deals with the great idea of > pkg_add -ui. > */my oppinion* It's not that developers don't have time; it's that they don't have resources. We all agree -- it would be great to see updates built for more/all of the arches. And that can happen, I imagine. The only problem is money and resources. So if you care as much about having packages built for your arch as you seem to, donate money or hardware. Nikolay has already asked[0] for an amd64 to make -stable packages happen; can you help? [0]http://undeadly.org/cgi?action=article&sid=20060619214229 -- o--{ Will Maier }--o | jabber:[EMAIL PROTECTED] | [EMAIL PROTECTED] | | freenode:..lt_kije | freenode:..#openbsd,#madlug | *--[ BSD Unix: Live Free or Die ]--*
Re: pkg_add -u not working
> On Tue, Jun 20, 2006 at 09:29:08AM -0500, Benjamin Collins wrote: >> What actually happens after the above invocation is what Sebastian >> pointed out - updatable package names are printed, but nothing is >> actually updated. > > And you're running 3.9 or -current? 3.9-amd64 (stable). But it was mentioned that there are no updated packages avaiable for amd64... Yes I can update using Ports... but it`s realy not so good (compared to pkg_add -ui). *my oppinion* There are not so many updates in the STABLE-Branch so I realy don`t understand why nobody can spend 3hrs of Compiling (a day, in the night, even developers have to speel :)) ) STABLE Packages (just the updated software! Not ALL Packages..). It`s realy something I can`t understand if it deals with the great idea of pkg_add -ui. */my oppinion* Kidn regards, Sebastian
Re: pkg_add -u not working
On Tue, Jun 20, 2006 at 09:29:08AM -0500, Benjamin Collins wrote: > What actually happens after the above invocation is what Sebastian > pointed out - updatable package names are printed, but nothing is > actually updated. And you're running 3.9 or -current? -- o--{ Will Maier }--o | jabber:[EMAIL PROTECTED] | [EMAIL PROTECTED] | | freenode:..lt_kije | freenode:..#openbsd,#madlug | *--[ BSD Unix: Live Free or Die ]--*
Re: pkg_add -u not working
On Sun, Jun 18, 2006 at 01:43:44PM +0200, Marc Espie wrote: > You'd better really start explaining what you are doing, and what you > expect the tools to do... > > so far, you are not making any kind of point. > > pkg_add -ui does exactly what it is supposed to at this point in time. > If it doesn't work for you, it's probably because there's something you > have completely not understood... Let me see chime in here, because I've been wondering about this as well. What I expect the tool to do if I invoke it like $ sudo pkg_add -u is to do this (from pkg_add(1)): If no pkgname is given, pkg_add will update all installed packages. What actually happens after the above invocation is what Sebastian pointed out - updatable package names are printed, but nothing is actually updated. > # pkg_add -uv > > Candidates for updating atk-1.10.1 -> atk-1.10.3p1 > Candidates for updating glib2-2.6.4 -> glib2-2.8.4 > Looking for updates: complete bc [demime 1.01d removed an attachment of type application/pgp-signature]
Re: pkg_add -u not working
On Sun, Jun 18, 2006 at 12:03:34AM +0200, [EMAIL PROTECTED] wrote: > In my oppinion the tool does NOT WORK like descriped... > Why? If you update from 3.8 to 3.9 it MAY work. > But if a depency was updated or so it totaly fails... > > godfather $ sudo pkg_add -ui > Looking for updates: complete Are you pointing it at a valid package repository ? doesn't look like it. > Btw: The other problem of that tool is that the Packages at the FTP must > be up2date too... Of course they must ! that's a prerequisite. And guess what ? they often are. > I would prefere a Ports-Solution for pkg_add -ui but there`s none. > *my oppinion but I think this examples proofs me right* You'd better really start explaining what you are doing, and what you expect the tools to do... so far, you are not making any kind of point. pkg_add -ui does exactly what it is supposed to at this point in time. If it doesn't work for you, it's probably because there's something you have completely not understood...
Re: pkg_add -u not working
Hi Tobias, The last one just solved your problem (in case you didn't notice). Next time use 'pkg_add -ui' The last one solved the problem because I gave the package name (atk in this case). If I didn't give the package name it would just have compared and exited like before.
Re: pkg_add -u not working
On Sun, Jun 18, 2006 at 09:43:53AM +1000, atstake atstake wrote: > >I'm sure it doesn't output 3 dots. So if you want serious help, provide > >the full output of pkg_add. Afaik, the -F flags are not needed because > >-i already asks you in tricky situations. > > Here are 3 diffrerent types of output - > > # pkg_add -uv > > Candidates for updating atk-1.10.1 -> atk-1.10.3p1 > Candidates for updating glib2-2.6.4 -> glib2-2.8.4 > Looking for updates: complete > > # pkg_add -ui -F update -F updatedepends > > Candidates for updating atk-1.10.1 -> atk-1.10.3p1 > Candidates for updating glib2-2.6.4 -> glib2-2.8.4 > Looking for updates: complete > > # pkg_add -u atk > > Candidates for updating glib2-2.6.4 -> glib2-2.8.4 > Candidates for updating atk-1.10.1 -> atk-1.10.3p1 > Looking for updates: complete > Running the equivalent of pkg_add -r glib2-2.8.4 atk-1.10.3p1 > glib2-2.8.4 (extracting): complete > glib2-2.6.4 (deleting): complete > glib2-2.8.4 (installing): complete > atk-1.10.3p1 (extracting): complete > atk-1.10.1 (deleting): complete > atk-1.10.3p1 (installing): complete > Clean shared items: complete > > Thanks! > > The last one just solved your problem (in case you didn't notice). Next time use 'pkg_add -ui' Tobias
Re: pkg_add -u not working
I'm sure it doesn't output 3 dots. So if you want serious help, provide the full output of pkg_add. Afaik, the -F flags are not needed because -i already asks you in tricky situations. Here are 3 diffrerent types of output - # pkg_add -uv Candidates for updating atk-1.10.1 -> atk-1.10.3p1 Candidates for updating glib2-2.6.4 -> glib2-2.8.4 Looking for updates: complete # pkg_add -ui -F update -F updatedepends Candidates for updating atk-1.10.1 -> atk-1.10.3p1 Candidates for updating glib2-2.6.4 -> glib2-2.8.4 Looking for updates: complete # pkg_add -u atk Candidates for updating glib2-2.6.4 -> glib2-2.8.4 Candidates for updating atk-1.10.1 -> atk-1.10.3p1 Looking for updates: complete Running the equivalent of pkg_add -r glib2-2.8.4 atk-1.10.3p1 glib2-2.8.4 (extracting): complete glib2-2.6.4 (deleting): complete glib2-2.8.4 (installing): complete atk-1.10.3p1 (extracting): complete atk-1.10.1 (deleting): complete atk-1.10.3p1 (installing): complete Clean shared items: complete Thanks!
Re: pkg_add -u not working
There is always Debian and apt-get ;)
Re: pkg_add -u not working
In my oppinion the tool does NOT WORK like descriped... Why? If you update from 3.8 to 3.9 it MAY work. But if a depency was updated or so it totaly fails... godfather $ sudo pkg_add -ui Looking for updates: complete Cannot find updates for BitTorrent-4.2.2 ImageMagick-6.2.6.1 ORBit-0.5.13p1 OpenEXR-1.2.2p2 aalib-1.2p0 arc-5.21n arts-1.5.1p0 aspell-0.50.5p4 atk-1.10.3p1 autoconf-2.13p0 autoconf-2.52p0 autoconf-2.54 autoconf-2.57 autoconf-2.59 bash-3.1.1p0 bison-2.1p0 bzip2-1.0.3 cairo-1.0.2p0 cdparanoia-3.a9.8p0 cdrtools-2.01 clamav-0.88.2 cups-1.1.23p8 curl-7.15.3 cvsync-0.24.19 cyrus-sasl-2.1.21p2 db-4.2.52p8 dbh-1.0.24p0 docbook-4.2p2 docbook-dsssl-1.72 docbook-to-man-0.0p0 dvd+rw-tools-5.21.4.10.8 esound-0.2.34p0 expat-1.95.6p1 flac-1.1.2p1 fltk-1.1.4p0 gdbm-1.8.3p0 gdk-pixbuf-0.22.0p4 gettext-0.14.5p1 ghostscript-7.05p7 ghostscript-fonts-6.0p0 gimp-2.2.10 glib-1.2.10p1 glib2-2.8.4 glitz-0.4.4 gmake-3.80p1 gmp-4.1.4p0 gnome-libs-1.4.2p2 gnupg-1.4.2.2 gnutls-1.0.25p0 gpgme-1.1.0p0 gtk+-1.2.10p4 gtk+2-2.6.10p1 gtk-xfce-engine-2.2.8p3 help2man-1.29 hicolor-icon-theme-0.5p0 hydra-4.6p1 imlib-1.9.14p4 irssi-0.8.9 iso8879-1986 jasper-1.701.0p1 jbigkit-1.6 john-1.6.40 jpeg-6bp3 kde-i18n-de-3.5.1 kdeadmin-3.5.1 kdebase-3.5.1p4 kdeedu-3.5.1 kdelibs-3.5.1p0 kdenetwork-3.5.1 koffice-1.4.2p2 koffice-i18n-de-1.4.2 koffice-i18n-fr-1.4.2 lame-3.96.1p1 lcms-1.12p1 lha-1.14i.ac20050924 libIDL-0.8.5p0 libao-0.8.5p2 libart-2.3.17 libaudiofile-0.2.6p0 libdnet-1.10p1 libexif-0.5.9p3 libgcrypt-1.2.0p0 libgpg-error-1.1 libgsf-1.11.1p2 libiconv-1.9.2p3 libltdl-1.5.22p1 libmad-0.15.1bp1 libmikmod-3.1.10p4 libmng-1.0.9p1 libnasl-2.2.5p5 libogg-1.1.3 libpqxx-2.5.3p0 libtheora-1.0alpha4p0 libtool-1.5.22 libungif-4.1.4 libusb-0.1.10ap1 libvorbis-1.1.2 libwmf-0.2.8.3p1 libxfce4mcs-4.2.3p0 libxfce4util-4.2.3.2 libxfcegui4-4.2.3p2 libxml-2.6.16p8 libxslt-1.1.12p3 lsof-4.75p0 lua-5.0.2p6 lzma-4.27.1 lzo-1.08p1 m4-1.4.4 metaauto-0.5 mozilla-firefox-1.5.0.3 mplayer-1.0pre7p15 mysql-client-5.0.18p0 nessus-core-2.2.5p3 nessus-libraries-2.2.5p1 nessus-plugins-2.2.5p2 netpbm-9.24p3 nikto-1.35 nmap-4.03 opencdk-0.5.5p0 openjade-1.3p1 openldap-client-2.3.11p4 openmotif-2.1.30.5p1 openvpn-2.0.6 p5-Gtk-0.7008-gnome p5-Locale-gettext-1.03p0 p5-Net-SSLeay-1.25p0 p5-XML-Parser-2.34 p5-XML-Writer-0.600 pango-1.10.2p0 pcre-6.4p1 pkgconfig-0.19p0 png-1.2.8 popt-1.7p0 postgresql-client-8.1.3 postgresql-server-8.1.3 privoxy-3.0.3p0 python-2.3.5p3 qemu-0.8.0p3 qt3-mt-3.5p4 samba-3.0.21bp2 screen-4.0.2 sdl-1.2.9p1-sun silc-client-1.0.2p1 sp-1.3.4p1 speex-1.0.5p0 startup-notification-0.8 sylpheed-2.0.4p0-gpgme t1lib-5.1.0p0 tcl-8.4.7p1 tcsh-6.14.00p0 texi2html-1.64 tiff-3.7.3p1 tinyca-0.6.8 tk-8.4.7 tor-0.1.1.20 transfig-3.2.4p0 unarj-2.43 unrar-3.54p0 unzip-5.52 vim-6.4.6p1-gtk2 vorbis-tools-1.1.1 wget-1.10.2p0 wv2-0.2.1p2 xcdroast-0.98a15p3 xfcalendar-4.2.3p1 xfce-mcs-manager-4.2.3p1 xfce-mcs-plugins-4.2.3p1 xfce-utils-4.2.3p1 xfce4-appfinder-4.2.3p1 xfce4-clipman-0.4.1p3 xfce4-datetime-0.3.1p3 xfce4-diskperf-1.5p3 xfce4-fsguard-0.2.1p1 xfce4-icon-theme-4.2.3 xfce4-iconbox-4.2.3p1 xfce4-lua-graph-0.1 xfce4-minicmd-0.3.0p3 xfce4-netload-0.3.3p1 xfce4-notes-0.11.1p1 xfce4-panel-4.2.3p1 xfce4-session-4.2.3p1 xfce4-showdesktop-0.4.0p4 xfce4-systemload-0.3.6p3 xfce4-systray-4.2.3p1 xfce4-taskbar-0.2.2p4 xfce4-toys-4.2.3p1 xfce4-trigger-launcher-4.2.3p1 xfce4-wavelan-0.4.1p3 xfce4-weather-0.4.9p4 xfce4-xkb-0.3.2p2 xfdesktop-4.2.3p2 xffm-4.2.3p3 xfwm4-4.2.3.2p0 xfwm4-themes-4.2.3 xmms-1.2.10p6 xmms-esd-1.2.10p5 xmms-flac-1.1.2 xmms-mikmod-1.2.10p5 xmms-mp3-1.2.10p6 xmms-vorbis-1.2.10p5 xpdf-3.01p1 zip-2.3p0 zoo-2.10.1p0 Proceed? [y/N] y godfather $ perl /usr/ports/infrastructure/build/out-of-date Collecting installed packages Collecting port versions: complete Collecting port signatures: complete Outdated ports: databases/libpqxx # postgresql-client-8.1.3 -> postgresql-client-8.1.4 databases/mysql# 5.0.18p0 -> 5.0.22 databases/postgresql # 8.1.3 -> 8.1.4 databases/postgresql,-server # 8.1.3 -> 8.1.4 devel/gettext # expat.4.0 -> expat.5.0 graphics/ImageMagick # tiff-3.7.3p0 -> tiff-3.7.3p1 graphics/gdk-pixbuf# tiff-3.7.3p0 -> tiff-3.7.3p1 graphics/lcms # tiff-3.7.3p0 -> tiff-3.7.3p1 graphics/netpbm# tiff-3.7.3p0 -> tiff-3.7.3p1 print/cups # tiff-3.7.3p0 -> tiff-3.7.3p1 security/nessus/plugins# -> nmap-3.95p0 textproc/p5-XML-Parser # expat.4.0 -> expat.5.0 x11/gtk+2 # tiff-3.7.3p0 -> tiff-3.7.3p1 x11/kde/libs3 # tiff-3.7.3p0 -> tiff-3.7.3p1 x11/kde/office3# mysql-client-5.0.18p0,postgresql-client-8.1.3 -> mysql-client-5.0.22,postgresql-client-8.1.4 Ports that can't be found in the official ports tree: /tmp/ports/net/nmap godfather $ nmap can`t be found. I use 4.01 because the Version in the Ports HAS issues and an update wich prevents it from crashing wa s
Re: pkg_add -u not working
On Sat, Jun 17, 2006 at 06:38:21PM +1000, atstake atstake wrote: > I have just upgraded from OpenBSD 3.8 -> 3.9. I set my PKG_PATH to > ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/ > > and did a "pkg_add -ui -F update -F updatedepends" but it doesn't > update all the packages instead just compare them. Here's the output - > > # pkg_add -ui -F update -F updatedepends > > Error from ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/: > Unknown command. > Candidates for updating atk-1.10.1 -> atk-1.10.3p1 > Candidates for updating bzip2-1.0.3 -> bzip2-1.0.3 > ... I'm sure it doesn't output 3 dots. So if you want serious help, provide the full output of pkg_add. Afaik, the -F flags are not needed because -i already asks you in tricky situations. Oh and ignore the unknow command thing, it has to do with the ftp.openbsd.org server not supporting EPSV or something Tobias > > Here's my pkg_path > > # echo $PKG_PATH > > ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/