Re: pkg_add -u

[latincom]

> 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=163762126127301=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

[Morgan Aldridge]

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"

[Mihai Popescu]

> 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"

[Marc Espie]

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"

[Harald Dunkel]

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"

[Marc Espie]

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"

[Andreas Kusalananda Kähäri]

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"

[Harald Dunkel]

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"

[Marc Espie]

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"

[Theo de Raadt]

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"

[Stuart Henderson]

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"

[Mihai Popescu]

| 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"

[Harald Dunkel]

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

[Stuart Henderson]

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

[chohag]

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

[chohag]

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

[Stuart Henderson]

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

[Andinus]

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

[Jan Betlach]

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

[Jan Betlach]

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

[Ingo Schwarze]

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

[Marc Espie]

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

[Jordon]

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=148404688530732=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

[Jordon]

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

[Stuart Henderson]

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=148404688530732=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

[Isak Holmstroem]

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

[Jordon]

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

[Jordon]

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

[Isak Holmström]

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

[Stuart Henderson]

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

[Cág]

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

[Grégoire Jadi]

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

[nigel]

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 80clock_battery
 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, version 20, 24 pins
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpiec0 at acpi0
 

Re: pkg_add -u and unneeded updates

[Alessandro DE LAURENZIS]

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

[Alessandro DE LAURENZIS]

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

[Ingo Schwarze]

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 and unneeded updates

[Marc Espie]

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' question

[Jason McIntyre]

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

[Stuart Henderson]

On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote:
 i ask because we need to watch how we word this. we could reasonably
 assume that people would also run it from time to time just to see if
 there's an update available, right?

Newer firmware versions often require changes to the driver,
so this isn't something I would normally want to update unless
I've just updated the kernel.

Re: 'pkg_add -u' question

[Ingo Schwarze]

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

[Jason McIntyre]

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

[Ingo Schwarze]

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

[Marc Espie]

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

[Jason McIntyre]

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

[Jason McIntyre]

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

[Ingo Schwarze]

Hi Dave,

Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500:

 and then ran 'pkg_add -ui' it was unable to update those files:
 Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0.

The firmwares live in a different package repository,
that's why pkg_add(1) doesn't find them by default.

If you do want to check for new firmwares, take the above
message as a reminder to run

 $ sudo fw_update

manually.  But note that's not necessarily related to doing an
operating system upgrade.

 I'd expect that making 'pkg_add -u' able to find these files would be
 fairly simple (either by giving it access to the same data used by the
 installer or by recording where it was found with any package added from
 a source not in PKG_PATH),

I'm not sure i would want pkg_add(1) to look outside the PKG_PATH.

 and it would certainly make life a bit more convenient when upgrading.
 Am I missing something important, is this on someone's TODO list,

The only (potential, minor) problem i see is that people might run
pkg_add(1), see the couldn't find, and not know about fw_update(1).
That's probably what happened to you.

I'm not sure how to improve that.  Messages printed by programs
should be terse, so i don't think pkg_add(1) should print a
suggestion to run fw_update(1) when it sees *-firmware-* packages
it can't update.  Most people will know that anyway, and there is
no strong reason to check for firmware updates at that particular
time.

Maybe it could be mentioned in the pkg_add(1) manual.
Then again, that manual doesn't document the Couldn't find updates
diagnostic at all, so far.

 do the installer and pkg_add developers not talk to each other,

Actually, i have met all of krw@, halex@ and espie@ at least twice
during hackathons, but never together; so you may have a point...  :-D

/irony
But no, that's not the root cause of the issue.

Yours,
  Ingo

Re: 'pkg_add -u' question

[Remco]

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

[Jason McIntyre]

On Sat, Jan 14, 2012 at 06:51:05PM +0100, Ingo Schwarze wrote:
 Hi Dave,
 
 Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500:
 
  and then ran 'pkg_add -ui' it was unable to update those files:
  Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0.
 
 The firmwares live in a different package repository,
 that's why pkg_add(1) doesn't find them by default.
 
 If you do want to check for new firmwares, take the above
 message as a reminder to run
 
  $ sudo fw_update
 
 manually.  But note that's not necessarily related to doing an
 operating system upgrade.
 
  I'd expect that making 'pkg_add -u' able to find these files would be
  fairly simple (either by giving it access to the same data used by the
  installer or by recording where it was found with any package added from
  a source not in PKG_PATH),
 
 I'm not sure i would want pkg_add(1) to look outside the PKG_PATH.
 
  and it would certainly make life a bit more convenient when upgrading.
  Am I missing something important, is this on someone's TODO list,
 
 The only (potential, minor) problem i see is that people might run
 pkg_add(1), see the couldn't find, and not know about fw_update(1).
 That's probably what happened to you.
 
 I'm not sure how to improve that.  Messages printed by programs
 should be terse, so i don't think pkg_add(1) should print a
 suggestion to run fw_update(1) when it sees *-firmware-* packages
 it can't update.  Most people will know that anyway, and there is
 no strong reason to check for firmware updates at that particular
 time.
 
 Maybe it could be mentioned in the pkg_add(1) manual.
 Then again, that manual doesn't document the Couldn't find updates
 diagnostic at all, so far.
 
  do the installer and pkg_add developers not talk to each other,
 
 Actually, i have met all of krw@, halex@ and espie@ at least twice
 during hackathons, but never together; so you may have a point...  :-D
 
 /irony
 But no, that's not the root cause of the issue.
 
 Yours,
   Ingo
 

i guess we haven;t done a great job of advertising fw_update. for
example, no other man page references the tool.

it certainly isn;t helpful that pkg_add informs you that it hasn;t been
able to find updates. i'm not sure how easy it would be to fix, but it
might be better if it said nothing at all (though then you would
probably forget they were installed at all).

i think at a minimum pkg_add probably should document that fw_update
handles non-free firmware, and we should probably update the packages
section of afterboot(8) too.

however i'm not sure when the author intended fw_update to be used. i.e.
in the course of upgrading or whenever you please.

jmc

Re: 'pkg_add -u' question

[Dave Anderson]

On Sat, 14 Jan 2012, Ingo Schwarze wrote:

Hi Dave,

Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500:

 and then ran 'pkg_add -ui' it was unable to update those files:
 Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0.

The firmwares live in a different package repository,
that's why pkg_add(1) doesn't find them by default.

If you do want to check for new firmwares, take the above
message as a reminder to run

 $ sudo fw_update

manually.  But note that's not necessarily related to doing an
operating system upgrade.

Thanks for the pointer; fw_update looks like it's exactly what I need.

 I'd expect that making 'pkg_add -u' able to find these files would be
 fairly simple (either by giving it access to the same data used by the
 installer or by recording where it was found with any package added from
 a source not in PKG_PATH),

I'm not sure i would want pkg_add(1) to look outside the PKG_PATH.

 and it would certainly make life a bit more convenient when upgrading.
 Am I missing something important, is this on someone's TODO list,

The only (potential, minor) problem i see is that people might run
pkg_add(1), see the couldn't find, and not know about fw_update(1).
That's probably what happened to you.

Yes.

I'm not sure how to improve that.  Messages printed by programs
should be terse, so i don't think pkg_add(1) should print a
suggestion to run fw_update(1) when it sees *-firmware-* packages
it can't update.  Most people will know that anyway, and there is
no strong reason to check for firmware updates at that particular
time.

Maybe it could be mentioned in the pkg_add(1) manual.
Then again, that manual doesn't document the Couldn't find updates
diagnostic at all, so far.

Perhaps when the 'Install non-free firmware files on first boot' option
is selected the installer should mention fw_update?  And/or 'pkg_add -u'
should mention it as a possible solution if it issues the couldn't
find message?  I probably should have tried 'apropos firmware', but was
fixated on pkg_add and didn't think to look for a different tool.

_Some_ sort of more prominent mention of fw_update appears to be
desirable.

Dave

 do the installer and pkg_add developers not talk to each other,

Actually, i have met all of krw@, halex@ and espie@ at least twice
during hackathons, but never together; so you may have a point...  :-D

/irony
But no, that's not the root cause of the issue.

Yours,
  Ingo


-- 
Dave Anderson
d...@daveanderson.com

Re: 'pkg_add -u' question

[Stuart Henderson]

On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote:
 however i'm not sure when the author intended fw_update to be used. i.e.
 in the course of upgrading or whenever you please.

fw_update is run automatically on the first boot after you upgrade via the
usual installer (bsd.rd / install51.iso / cd51.iso etc).

Re: 'pkg_add -u' question

[Jason McIntyre]

On Sat, Jan 14, 2012 at 10:13:07PM +, Stuart Henderson wrote:
 On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote:
  however i'm not sure when the author intended fw_update to be used. i.e.
  in the course of upgrading or whenever you please.
 
 fw_update is run automatically on the first boot after you upgrade via the
 usual installer (bsd.rd / install51.iso / cd51.iso etc).
 

right. but is there any reason to discourage people from running it when
they please, or do we just expect it to be done automatically after
upgrade?

i ask because we need to watch how we word this. we could reasonably
assume that people would also run it from time to time just to see if
there's an update available, right?

jmc

Re: 'pkg_add -u' question

[Chris Cappuccio]

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

[Theo de Raadt]

 On Sat, Jan 14, 2012 at 10:13:07PM +, Stuart Henderson wrote:
  On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote:
   however i'm not sure when the author intended fw_update to be used. i.e.
   in the course of upgrading or whenever you please.
  
  fw_update is run automatically on the first boot after you upgrade via the
  usual installer (bsd.rd / install51.iso / cd51.iso etc).
  
 
 right. but is there any reason to discourage people from running it when
 they please, or do we just expect it to be done automatically after
 upgrade?
 
 i ask because we need to watch how we word this. we could reasonably
 assume that people would also run it from time to time just to see if
 there's an update available, right?

people can run fw_update any time they want to, and yes if there are
newer firmwares it will pick them up.

Re: 'pkg_add -u' question

[Theo de Raadt]

 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

[Theo de Raadt]

 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 updating same package

[frantisek holop]

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

[Markus Lude]

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 updating same package

[Stefan Sperling]

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

[Marc Espie]

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

[Ingo Schwarze]

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 question

[Cabillot Julien]

pkg_add -ui

On 5/6/07, Clint M. Sand [EMAIL PROTECTED] wrote:

 man pkg_add states:

 -u Update the given pkgname(s), and anything it depends upon.
 If no pkgname is given, pkg_add will update all installed packages.
 This relies on PKG_PATH to figure out the new package names.

 However if I run -u with no package name, it tells me a list of possible
 candidates, but doesn't actually update anything. I have to manually do
 each one. Am I doing something wrong or is this expected for some
 reason?

 (on i386)
 # dmesg | head -1
 OpenBSD 4.1-stable (GENERIC) #0: Sat May 5 21:34:13 EDT 2007
 # echo $PKG_PATH ftp://ftp.nyc.openbsd.org/pub/OpenBSD/4.1/packages/i386/
 # pkg_add -u
 Candidates for updating autossh-1.2g - autossh-1.3
 Candidates for updating bzip2-1.0.3 - bzip2-1.0.4
 Candidates for updating cdrtools-2.01 - cdrtools-2.01p0
 Looking for updates: complete
 #


 Any ideas?




-- 
Julien Cabillot

Re: pkg_add -u question

[Clint M. Sand]

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

[James Turner]

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 says Not updating .libs-$pkg, remember to clean it

[Julian Leyh]

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 says Not updating .libs-$pkg, remember to clean it

[Marc Espie]

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 not working

[atstake atstake]

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 pkg_name it updates the pkg_name + dependencies
just fine.

Re: pkg_add -u not working

[Benjamin Collins]

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

[Will Maier]

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

[sebastian . rother]

 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

[Will Maier]

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=articlesid=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

[steven mestdagh]

[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=articlesid=20060619214229

-- 
steven

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: pkg_add -u not working

[Paul de Weerd]

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=articlesid=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

[Benjamin Collins]

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

[Marc Espie]

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

[Tobias Ulmer]

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/

Re: pkg_add -u not working

[Craig Skinner]

There is always Debian and apt-get


;)

Re: pkg_add -u not working

[atstake atstake]

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

[Tobias Ulmer]

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

[atstake atstake]

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.