Re: Why does `pkg_info -m` show quirks?
On Sat, Aug 19, 2023 at 07:21:58PM +0200, Ingo Schwarze wrote: > Hi, > > Stuart Henderson wrote on Fri, Aug 18, 2023 at 05:52:07PM -: > > On 2023-08-18, l...@ena.re wrote: > > >> Also, what is the reason the quirks package does not have a man page? > > Usually, there is no manual page documenting a package as a whole. > > >> I believe it should have one, just like any other program. > > The quirks package certainly isn't a program. > Right now, i fail to see any evidence that it even *contains* any program. > > >> Is this something that is desired? > > The following is certainly not a good syllogism: > "There is no manual page documenting this package" > => "We need a manual page documenting this package" > > Even the folliwing, weaker syllogism may occasionally be false: > "This package contains no manual page" > => "We should write a manual page to include in the package" > > Is information about the quirks package missing from the manual pages? > Maybe, it doesn't seem unlikely to me, but i'm far from sure. > > >> If so, I would gladly model one after the package description. > > What a terrible idea. Most of that information is already contained > in the manual page sthen@ mentioned: > > > packages(7) - overview of the binary package system > > I think what packages(7) says is also easier to understand than > what the quirks package description says. > > > not sure what such a manpage would be named. > > Given that manual pages are named after programs, functions, devices, > or file formats, > >$ pkg_info -L quirks > > tells me that a manual page to be included in the quirks package > could be named: > > OpenBSD::Quirks(3p) > >- that one would document the Perl API of the OpenBSD::Quirks > Perl package, similar to e.g. OpenBSD::PackingElement(3p) > or OpenBSD::State(3p) > > or > > update.db(5) > >- that one would document the file format of the file > /usr/local/share/update.db and explain how that file > is used, similar to mandoc.db(5) or locate(1) -- > by the way, it does look like we are missing a > locate.database(5) manual page > > > it is already described here though: > > $ man -k any=quirks > > packages(7) - overview of the binary package system > > Right, any information about the quirks package that doesn't > belong into OpenBSD::Quirks(3p) or update.db(5) probably > belongs into packages(7) or pkg_add(1). > > Yours, > Ingo > from my phone so bear with me for the poor formatting. the whole point of quirks is to deal with unforeseen upgrade issues. So there's no point in documenting an api that's meant to evolve and be abused as needs arise.
Re: Why does `pkg_info -m` show quirks?
Hi, Stuart Henderson wrote on Fri, Aug 18, 2023 at 05:52:07PM -: > On 2023-08-18, l...@ena.re wrote: >> Also, what is the reason the quirks package does not have a man page? Usually, there is no manual page documenting a package as a whole. >> I believe it should have one, just like any other program. The quirks package certainly isn't a program. Right now, i fail to see any evidence that it even *contains* any program. >> Is this something that is desired? The following is certainly not a good syllogism: "There is no manual page documenting this package" => "We need a manual page documenting this package" Even the folliwing, weaker syllogism may occasionally be false: "This package contains no manual page" => "We should write a manual page to include in the package" Is information about the quirks package missing from the manual pages? Maybe, it doesn't seem unlikely to me, but i'm far from sure. >> If so, I would gladly model one after the package description. What a terrible idea. Most of that information is already contained in the manual page sthen@ mentioned: > packages(7) - overview of the binary package system I think what packages(7) says is also easier to understand than what the quirks package description says. > not sure what such a manpage would be named. Given that manual pages are named after programs, functions, devices, or file formats, $ pkg_info -L quirks tells me that a manual page to be included in the quirks package could be named: OpenBSD::Quirks(3p) - that one would document the Perl API of the OpenBSD::Quirks Perl package, similar to e.g. OpenBSD::PackingElement(3p) or OpenBSD::State(3p) or update.db(5) - that one would document the file format of the file /usr/local/share/update.db and explain how that file is used, similar to mandoc.db(5) or locate(1) -- by the way, it does look like we are missing a locate.database(5) manual page > it is already described here though: > $ man -k any=quirks > packages(7) - overview of the binary package system Right, any information about the quirks package that doesn't belong into OpenBSD::Quirks(3p) or update.db(5) probably belongs into packages(7) or pkg_add(1). Yours, Ingo
Re: Why does `pkg_info -m` show quirks?
On 2023-08-18, l...@ena.re wrote: > Hey, > > according to pkg_info(1) the -m options "shows the names and one-line > comments for all packages tagged as manually installed". However, > executing `pkg_info -m` shows the quirks package, which is clearly not > "manually installed". According to it's package description: "pkg_add(1) > always installs and updates it automatically". > > Can a package be tagged either as manually installed or as a dependency > and as quirks is not a dependency, it is tagged as manually installed? > If this is so, it seems to make sense that is tagged as manually > installed. quirks isn't installed as a dependency of another port, so by that definition it's not "auto installed". I think it's undesirable for "pkg_delete -a" to remove the quirks package which is probably why it is currently recorded as manual-install. > However, what do you think about not showing quirks when executing > `pkg_info -mz`, as this is intended to "be reused with pkg_add(1) -l to > recreate a package installation"? Similarly to how firmware is not shown. > This would resemble the behaviour I expect from `pkg_info -mz`. might be an idea, though it doesn't really hurt to list it. suggest asking on ports@ and cc espie rather than on misc, though IIRC he's away at the moment. > Also, what is the reason the quirks package does not have a man page? I > believe it should have one, just like any other program. Is this > something that is desired? If so, I would gladly model one after the > package description. not sure what such a manpage would be named. it is already described here though: $ man -k any=quirks packages(7) - overview of the binary package system
Why does `pkg_info -m` show quirks?
Hey, according to pkg_info(1) the -m options "shows the names and one-line comments for all packages tagged as manually installed". However, executing `pkg_info -m` shows the quirks package, which is clearly not "manually installed". According to it's package description: "pkg_add(1) always installs and updates it automatically". Can a package be tagged either as manually installed or as a dependency and as quirks is not a dependency, it is tagged as manually installed? If this is so, it seems to make sense that is tagged as manually installed. However, what do you think about not showing quirks when executing `pkg_info -mz`, as this is intended to "be reused with pkg_add(1) -l to recreate a package installation"? Similarly to how firmware is not shown. This would resemble the behaviour I expect from `pkg_info -mz`. Also, what is the reason the quirks package does not have a man page? I believe it should have one, just like any other program. Is this something that is desired? If so, I would gladly model one after the package description. Kind regards, Leo
Re: pkg_info -Q confusion
> Am 15.04.2023 um 23:44 schrieb Antun Matanović : > >> I'm generally interested in what is available for the exact machine I am >> running on. > > You could use `pkg_info -a -Q` which searches all the repositories. >> From the pkg_info man page: > -Q substring > Show the names of all packages in the first repository of the > package search path containing the substring in the stems of > their package names. A stem is a package name with all version > and flavor suffixes removed; see pkg_add(1) for more details on > stems. If -a is also specified, show the names of all matching > packages in all repositories instead. So simple and so perfect! Thanks for that hint. I’ll still keep pkglocate around for more complicated partial name searches but for most of my use cases pkg_info -aQ name is exactly what I need. Mike
Re: pkg_info -Q confusion
> I'm generally interested in what is available for the exact machine I am > running on. You could use `pkg_info -a -Q` which searches all the repositories. >From the pkg_info man page: -Q substring Show the names of all packages in the first repository of the package search path containing the substring in the stems of their package names. A stem is a package name with all version and flavor suffixes removed; see pkg_add(1) for more details on stems. If -a is also specified, show the names of all matching packages in all repositories instead.
Re: pkg_info -Q confusion
> Am 14.04.2023 um 18:24 schrieb Allan Streib :
>
> On Fri, Apr 14, 2023, at 05:50, Stuart Henderson wrote:
>> I never found pkg_info -Q to be a useful tool.
>>
>> Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
>> searching on an index that is built from : - as a
>> result it lets you do a substring match on package names, not just
>> on filenames.
>
> Also, as mentioned in packages(7) man page, there is a site at
> https://openports.pl/ that can be used, though obviously that requires
> internet access so may not be appropriate for all cases. I tend to
> use it a lot, personally.
It does not seem to differentiate between different OpenBSD versions or
architectures though?
I’m generally interested in what is available for the exact machine I am
running on. But I guess at least knowing that there is a port for some version
on some platform might be helpful — at least the inverse means I can stop
looking now ;-)
But still thanks for reminding me of this site. I had forgotten about that.
Mike
Re: pkg_info -Q confusion
On Fri, Apr 14, 2023, at 05:50, Stuart Henderson wrote:
> I never found pkg_info -Q to be a useful tool.
>
> Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
> searching on an index that is built from : - as a
> result it lets you do a substring match on package names, not just
> on filenames.
Also, as mentioned in packages(7) man page, there is a site at
https://openports.pl/ that can be used, though obviously that requires
internet access so may not be appropriate for all cases. I tend to
use it a lot, personally.
Re: pkg_info -Q confusion
Inline…
> Am 14.04.2023 um 12:50 schrieb Stuart Henderson :
>
> On 2023-04-14, Mike Fischer wrote:
>> Usually when looking for a port to install I use `pkg_info -Q name` to
>> search for the the port.
>>
>> Strangely this does not completely work for PHP on OpenBSD 7.3:
>>
>> `pkg_info -Q php` does not list PHP 7.4.33 and related ports which are
>> clearly available.
>>
>> It seems that -Q only finds ports in packages-stable/, not packages/?
>>
>> pkg_info(1) does not seem to mention this limitation (or I have missed it).
>
> That's what is meant by "in the first repository of the package search
> path" but it's not very obvious.
Ah, I see. Indeed I didn’t realise that was meant by the statement.
> If PKG_PATH is not set and you're on a release version, the
> pkg_add-based tools (including pkg_info) construct one starting with
> the packages-stable directory, in order that -stable updates are
> preferred over release packages. This is (mostly) described in
> pkg_add(1).
>
> You can search just the release packages with
>
> PKG_PATH=http://cdn.openbsd.org/pub/OpenBSD/%v/packages/%a/ pkg_info -Q php
Ok, thanks. Not very comfortable but at least a possibility.
>
>> Is this working as intended?
>
> Yes though it's a little unfriendly.
Yep!
>
>> Is there a better way to look for available packages?
>
> I never found pkg_info -Q to be a useful tool.
Up to now I never had an issue. But I never noticed this limitation before. (I
did notice the lack of being able to search for partial package names but I
have gotten used to that.)
> Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
> searching on an index that is built from : - as a
> result it lets you do a substring match on package names, not just
> on filenames.
>
> For a package which includes many files you'll get a lot of output
> lines, so something like "pkglocate moo | cut -d: -f1 | uniq" maybe
> useful, or "pkglocate moo | grep ^moo".
>
> And if you're looking for the package containing a particular
> binary, "pkglocate bin/moo" cuts out a lot of the useless stuff.
Very helpful!
Thanks Stuart!
Mike
Re: pkg_info -Q confusion
On 2023-04-14, Mike Fischer wrote:
> Usually when looking for a port to install I use `pkg_info -Q name` to
> search for the the port.
>
> Strangely this does not completely work for PHP on OpenBSD 7.3:
>
> `pkg_info -Q php` does not list PHP 7.4.33 and related ports which are
> clearly available.
>
> It seems that -Q only finds ports in packages-stable/, not packages/?
>
> pkg_info(1) does not seem to mention this limitation (or I have missed it).
That's what is meant by "in the first repository of the package search
path" but it's not very obvious.
If PKG_PATH is not set and you're on a release version, the
pkg_add-based tools (including pkg_info) construct one starting with
the packages-stable directory, in order that -stable updates are
preferred over release packages. This is (mostly) described in
pkg_add(1).
You can search just the release packages with
PKG_PATH=http://cdn.openbsd.org/pub/OpenBSD/%v/packages/%a/ pkg_info -Q php
> Is this working as intended?
Yes though it's a little unfriendly.
> Is there a better way to look for available packages?
I never found pkg_info -Q to be a useful tool.
Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
searching on an index that is built from : - as a
result it lets you do a substring match on package names, not just
on filenames.
For a package which includes many files you'll get a lot of output
lines, so something like "pkglocate moo | cut -d: -f1 | uniq" maybe
useful, or "pkglocate moo | grep ^moo".
And if you're looking for the package containing a particular
binary, "pkglocate bin/moo" cuts out a lot of the useless stuff.
pkg_info -Q confusion
Usually when looking for a port to install I use `pkg_info -Q name` to search for the the port. Strangely this does not completely work for PHP on OpenBSD 7.3: `pkg_info -Q php` does not list PHP 7.4.33 and related ports which are clearly available. It seems that -Q only finds ports in packages-stable/, not packages/? pkg_info(1) does not seem to mention this limitation (or I have missed it). Is this working as intended? Is there a better way to look for available packages? Thanks! Mike
Re: pkg_info -Q not finding all entries?
On Mon, 2023-01-30 at 11:26 +, Stuart Henderson wrote: > On 2023-01-30, David Demelier wrote: > > While searching for sqlite3 I've realized that pkg_info -Q sqlite3 > > finds some php packages but not everything available in the remote > > repository: > > This is a consequence of the "first repository of the package search > path" limitation of -Q and how -stable packages are handled. > It only displays packages for which a -stable update is available. > > Workaround: > > PKG_PATH=http://cdn.openbsd.org/pub/OpenBSD/%v/packages/%a/ pkg_info > -Q sqlite > Hi, Thank you for your both answers, I'll keep that around :) -- David
Re: pkg_info -Q not finding all entries?
On 2023-01-30, David Demelier wrote: > While searching for sqlite3 I've realized that pkg_info -Q sqlite3 > finds some php packages but not everything available in the remote > repository: This is a consequence of the "first repository of the package search path" limitation of -Q and how -stable packages are handled. It only displays packages for which a -stable update is available. Workaround: PKG_PATH=http://cdn.openbsd.org/pub/OpenBSD/%v/packages/%a/ pkg_info -Q sqlite though this won't show updates from the packages-stable directory. (Or run -current :-) Another sort-of alternative is to use pkglocate (install the pkglocatedb package, and for some things postprocessing with | cut -d: -f1 | sort -u helps).
Re: pkg_info -Q not finding all entries?
Hi, * David Demelier wrote: > Hello, > > While searching for sqlite3 I've realized that pkg_info -Q sqlite3 > finds some php packages but not everything available in the remote > repository: > > # cat /etc/installurl > https://ftp.fr.openbsd.org/pub/OpenBSD/ > # pkg_info -Q sqlite3 > debug-php-sqlite3-7.4.32p0 > debug-php-sqlite3-7.4.33 > debug-php-sqlite3-8.0.24p0 > debug-php-sqlite3-8.0.25 > debug-php-sqlite3-8.0.26 > debug-php-sqlite3-8.0.27 > debug-php-sqlite3-8.1.11p0 > debug-php-sqlite3-8.1.12 > debug-php-sqlite3-8.1.13 > debug-php-sqlite3-8.1.14 > php-sqlite3-7.4.32p0 > php-sqlite3-7.4.33 > php-sqlite3-8.0.24p0 > php-sqlite3-8.0.25 > php-sqlite3-8.0.26 > php-sqlite3-8.0.27 > php-sqlite3-8.1.11p0 > php-sqlite3-8.1.12 > php-sqlite3-8.1.13 > php-sqlite3-8.1.14 What you see above are the sqlite3 packages from the 7.2 packages-stable/ directory. When you do the same on a -current you get much more results and presumably what you expected. $ pkg_info -Q sqlite3 | wc -l 20 I assume pkg_info looks only in the stable directory and not in both to builds a set between updated and not updates packages... Cheers Matthias
pkg_info -Q not finding all entries?
Hello, While searching for sqlite3 I've realized that pkg_info -Q sqlite3 finds some php packages but not everything available in the remote repository: # cat /etc/installurl https://ftp.fr.openbsd.org/pub/OpenBSD/ # pkg_info -Q sqlite3 debug-php-sqlite3-7.4.32p0 debug-php-sqlite3-7.4.33 debug-php-sqlite3-8.0.24p0 debug-php-sqlite3-8.0.25 debug-php-sqlite3-8.0.26 debug-php-sqlite3-8.0.27 debug-php-sqlite3-8.1.11p0 debug-php-sqlite3-8.1.12 debug-php-sqlite3-8.1.13 debug-php-sqlite3-8.1.14 php-sqlite3-7.4.32p0 php-sqlite3-7.4.33 php-sqlite3-8.0.24p0 php-sqlite3-8.0.25 php-sqlite3-8.0.26 php-sqlite3-8.0.27 php-sqlite3-8.1.11p0 php-sqlite3-8.1.12 php-sqlite3-8.1.13 php-sqlite3-8.1.14 # It also does not list the installed package of the exact name 'sqlite3' (which is installed). # pkg_info sqlite3 Information for inst:sqlite3-3.39.3 Comment: embedded SQL implementation Required by: python-3.9.16 Description: SQLite is a C library that implements an embeddable SQL database engine. Programs that link with the SQLite library can have SQL database access without running a separate RDBMS process. The distribution comes with a standalone command-line access program (sqlite3) that can be used to administer an SQLite database and which serves as an example of how to use the SQLite library. Maintainer: The OpenBSD ports mailing-list WWW: https://www.sqlite.org/ Do I miss something (or misunderstood the -Q option)? This is 7.2 on amd64. Regards, -- David
Re: pkg_info -m: libraries and dependencies marked as manually installed
On 9/19/21 3:21 PM, Stuart Henderson wrote: > On 2021-09-19, Jordan Geoghegan wrote: >> Hello, >> >> I recently decided to clean up my desktop machine of unused packages etc. >> I've been running release/stable on this machine since around the OpenBSD >> 6.2 era. The machine has been upgraded over the years all the way to 6.9. >> I'm not sure that it's relevant, but I've regularly run sysclean in an >> effort to keep my install clean and fresh. >> >> When running "pkg_info -m", within the output list I am shown a number of >> random dependencies which I did not manually install. Is there a way to >> remove the "manually installed" tag from these library/dependency packages >> to allow them to potentially be cleaned up by "pkg_delete -a"? > Yes, with pkg_add(1): > > "-aa Force already installed packages to be tagged as > installed automatically." > > Thanks Stuart, you're a saint - that certainly did the trick! Regards, Jordan
Re: pkg_info -m: libraries and dependencies marked as manually installed
On 2021-09-19, Jordan Geoghegan wrote: > Hello, > > I recently decided to clean up my desktop machine of unused packages etc. > I've been running release/stable on this machine since around the OpenBSD 6.2 > era. The machine has been upgraded over the years all the way to 6.9. I'm not > sure that it's relevant, but I've regularly run sysclean in an effort to keep > my install clean and fresh. > > When running "pkg_info -m", within the output list I am shown a number of > random dependencies which I did not manually install. Is there a way to > remove the "manually installed" tag from these library/dependency packages to > allow them to potentially be cleaned up by "pkg_delete -a"? Yes, with pkg_add(1): "-aa Force already installed packages to be tagged as installed automatically."
pkg_info -m: libraries and dependencies marked as manually installed
Hello, I recently decided to clean up my desktop machine of unused packages etc. I've been running release/stable on this machine since around the OpenBSD 6.2 era. The machine has been upgraded over the years all the way to 6.9. I'm not sure that it's relevant, but I've regularly run sysclean in an effort to keep my install clean and fresh. When running "pkg_info -m", within the output list I am shown a number of random dependencies which I did not manually install. Is there a way to remove the "manually installed" tag from these library/dependency packages to allow them to potentially be cleaned up by "pkg_delete -a"? $ pkg_info -m ImageMagick-6.9.12.2 image processing tools adwaita-icon-theme-3.38.0 base icon theme for GNOME aggregate-1.6p1 optimise a list of route prefixes aggregate6-1.0.12p1 optimise a list of IPv4/IPv6 prefixes amdgpu-firmware-20201218 firmware binary images for amdgpu(4) driver aria2-1.35.0p0 lightweight multi-protocol & multi-source download utility at-spi2-atk-2.38.0 atk-bridge for at-spi2 at-spi2-core-2.38.0 service interface for assistive technologies atk-2.36.0 accessibility toolkit used by gtk+ avahi-0.8p0 framework for Multicast DNS Service Discovery cairo-1.16.0 vector graphics library cloc-1.86 count lines of code coreutils-8.32p0 file, shell and text manipulation utilities cowsay-3.04 speaking ascii cow cups-libs-2.3.3.2 CUPS libraries and headers dbus-glib-0.112v0 glib bindings for dbus message system dconf-0.40.0 configuration backend system desktop-file-utils-0.26 utilities for dot.desktop entries dolphin-5.0.0.20190621p1 Nintendo GameCube and Wii emulator with GUI dvd+rw-tools-7.1p1 mastering tools for DVD+RW/+R/-R/-RW e2fsprogs-1.42.12p5 utilities to manipulate ext2 filesystems evince-3.38.2-light GNOME document viewer fdupes-2.1.2 identify or delete duplicate files firefox-esr-78.14.0 Firefox web browser, Extended Support Release freerdp-2.3.2 client for Microsoft RDP (remote desktop protocol) gcr-3.38.1 library for bits of crypto UI and parsing gdbm-1.19 GNU dbm gdk-pixbuf-2.42.4 image data transformation library gegl04-0.4.30p0 graph based image processing framework (API version 0.4) geoclue-0.12.99p9 modular geoinformation service on top of D-Bus gettext-runtime-0.21p1 GNU gettext runtime libraries and programs ggrep-3.6 GNU versions of grep pattern matching utilities gimp-2.10.24 GNU Image Manipulation Program git-2.31.1 distributed version control system glib2-2.66.8 general-purpose utility library glib2-networking-2.66.0 network-related gio modules for GLib gnome-icon-theme-3.12.0p5 base icon theme for GNOME gnome-icon-theme-symbolic-3.12.0p3 base icon theme extension for special UI contexts gnupg-2.2.23p2 GNU privacy guard - a free PGP replacement gnutls-3.6.16 GNU Transport Layer Security library go-1.16.2 Go programming language gsettings-desktop-schemas-3.38.0 collection of shared GSettings schemas gtk+2-2.24.33p0 multi-platform graphical toolkit gtk+3-3.24.28p1 multi-platform graphical toolkit gtk-update-icon-cache-3.24.28 gtk+ icon theme caching utility gvfs-1.46.2 GNOME Virtual File System gxemul-0.6.3.1 ARM/M88k/MIPS/PowerPC/SuperH machines emulator harfbuzz-2.8.0 text shaping library harfbuzz-icu-2.8.0 ICU support for libharfbuzz httrack-3.48.21p2 offline browser iwm-firmware-20191022p1 firmware binary images for iwm(4) driver keepassxc-2.6.4 management tool for password and sensitive data ksh93-20120801p1 AT Korn Shell libassuan-2.5.5 IPC library used by GnuPG and gpgme libcroco-0.6.13p0 generic CSS parsing library for GNOME project libexif-0.6.22 extract digital camera info tags from JPEG images libgcrypt-1.9.4 crypto library based on code used in GnuPG libgpg-error-1.42 error codes for GnuPG related software libidn-1.36 internationalized string handling libksba-1.4.0 X.509 library libmypaint-1.6.1 library for making brushstrokes libnotify-0.7.9 send desktop notifications to a notification daemon libproxy-0.4.17 library handling all the details of proxy configuration libpsl-0.21.1 public suffix list library libreoffice-7.0.5.2v0 multi-platform productivity suite librsvg-2.50.3 SAX-based render library for SVG files libsecret-0.20.4 library for storing and retrieving passwords and secrets libsoup-2.72.0 HTTP client/server library for GNOME mawk-1.3.4.20200120p0 fast POSIX-compliant awk mupdf-1.18.0 graphic library, pdf parser, viewer and utilities mupen64plus-2.5.9 n64 emulator (default plugins) nmap-7.80p0 scan ports and fingerprint stack of network hosts opus-tools-0.2 encode, inspect, and decode Opus files p11-kit-0.23.22p0 library for loading and enumerating PKCS#11 modules p7zip-16.02p6 file archiver with h
Re: pkg_info(1) manpage issue
On Sun, Jan 24, 2021 at 09:35:46PM +0100, Andrew Easton wrote: > Hello everyone, > > it appears that there may be a way to misinterpret > the man page for pkg_info(1) in the state of > commit 0b249e2164be2385bc6a5e82814435649b2b06e0 > Date: Sun Jan 24 10:21:43 2021 + > on the github openbsd src mirror. > > The problem description is under the headline > "Issue". > > There is a realistic chance that I am > misunderstanding something. If this is the case, what > further measures can I take to narrow down the problem? > > === Issue === > > The uninstalled packages are supposed to be listed > together with their one-line summary. The manual > page accessible with $ man 1 pkg_info; reads: > > [quote] > When browsing through uninstalled packages, running > pkg_info -I *.tgz will report a summary line for each > package, so that it is possible to run > pkg_info pkgname.tgz to obtain a longer package > description, and pkg_add -n pkgname.tgz to check that > the installation would proceed cleanly, including > dependencies. > [\quote] > > Copy-pasting the command "pkg_info -I *.tgz" from the > manual page into the terminal yields the following > error: > > computer$ pkg_info -I *.tgz > Invalid spec: *.tgz > Invalid spec: *.tgz > computer$ > Are there any packages in the directory? Try: $ cd /usr/ports/packages/`uname -m`/all $ pkg_info -I *.tgz Obviously you're results will vary, but I get: file:./autoconf-2.67p1.tgz: unsigned package autoconf-2.67p1.tgz automatically configure source code on many Un*x platforms file:./autoconf-2.69p3.tgz: unsigned package autoconf-2.69p3.tgz automatically configure source code on many Un*x platforms file:./automake-1.16.2.tgz: unsigned package automake-1.16.2.tgz GNU Standards-compliant Makefile generator file:./bison-3.3.2p1.tgz: unsigned package bison-3.3.2p1.tgz GNU parser generator file:./blas-3.8.0p0.tgz: unsigned package followed by many more... Or an absolute path like: pkg_info -I https://cnd.openbsd.org/pub/OpenBSD/6.8/packages-stable/`uname -m`/curl-7.72.0p0.tgz curl-7.72.0p0.tgz transfer files with FTP, HTTP, HTTPS, etc. However, pkg_add -n https://cnd.openbsd.org/pub/OpenBSD/6.8/packages-stable/`uname -m`/curl-7.72.0p0.tgz Does give weird output: quirks-3.440 signed on 2021-01-22T19:53:09Z Can't find transfer Can't find files Can't find with Can't find FTP, Can't find HTTP, Can't find HTTPS, Can't find etc. Edgar > > Even calling pkg_info(1) with doas(1) yields the same > behaviour: > > computer$ doas pkg_info -I *.tgz > Invalid spec: *.tgz > Invalid spec: *.tgz > computer$ > > > Note that there is a relatively long pause between > the two "Invalid spec" messages both with and without > doas(1). > > > In which way am I misunderstanding the manual page > for pkg_info(1) for the specific operation of > browsing uninstalled packages and showing a summary > line? > > > === Affected Man-Page File === > /usr.sbin/pkg_add/pkg_info.1 > in > commit 0b249e2164be2385bc6a5e82814435649b2b06e0 > Date: Sun Jan 24 10:21:43 2021 + > > > > Kind regards, > Andrew Easton >
pkg_info(1) manpage issue
Hello everyone, it appears that there may be a way to misinterpret the man page for pkg_info(1) in the state of commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + on the github openbsd src mirror. The problem description is under the headline "Issue". There is a realistic chance that I am misunderstanding something. If this is the case, what further measures can I take to narrow down the problem? === Issue === The uninstalled packages are supposed to be listed together with their one-line summary. The manual page accessible with $ man 1 pkg_info; reads: [quote] When browsing through uninstalled packages, running pkg_info -I *.tgz will report a summary line for each package, so that it is possible to run pkg_info pkgname.tgz to obtain a longer package description, and pkg_add -n pkgname.tgz to check that the installation would proceed cleanly, including dependencies. [\quote] Copy-pasting the command "pkg_info -I *.tgz" from the manual page into the terminal yields the following error: computer$ pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Even calling pkg_info(1) with doas(1) yields the same behaviour: computer$ doas pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Note that there is a relatively long pause between the two "Invalid spec" messages both with and without doas(1). In which way am I misunderstanding the manual page for pkg_info(1) for the specific operation of browsing uninstalled packages and showing a summary line? === Affected Man-Page File === /usr.sbin/pkg_add/pkg_info.1 in commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + Kind regards, Andrew Easton
Re: pkg_info(1) man page possible error
On 01-25 01:49, Ingo Schwarze wrote: > Andrew Easton wrote on Fri, Jan 24, 2020 at 11:17:20PM +0100: > > I was looking for a list of ports packages > Depending what you really need, try > $ doas pkg_add portslist > $ less /usr/local/share/ports-INDEX > $ doas pkg_add sqlports > $ sqlite3 /usr/local/share/sqlports > https://cvsweb.openbsd.org/ports/ > > and read the man page pkg_info(1). For what it may be worth, another way to get a list of ports is (as root, or maybe should be rewritten with "doas", as Ingo did, but): # cd /usr/ports/ && make print-index > ~root/openbsdports-list-$(uname -r)-$(machine) -Luke -- Please pray for our country(ies) and leaders, at this important time. More on this and other topics (a simple site w/o sales): http://lukecall.net (updated 2020-01-23)
Re: pkg_info(1) man page possible error
Hi Andrew, Andrew Easton wrote on Fri, Jan 24, 2020 at 11:17:20PM +0100: > I am running OpenBSD in a virtualbox because I am taking a deeper look > into it. > > I was looking for a list of ports packages Depending what you really need, try $ doas pkg_add portslist $ less /usr/local/share/ports-INDEX $ doas pkg_add sqlports $ sqlite3 /usr/local/share/sqlports https://cvsweb.openbsd.org/ports/ > and read the man page pkg_info(1). > > That man page it states, > "When browsing through uninstalled packages, running pkg_info -I *.tgz > will report a summary line for each package [...]" > > Note the capital eye 'I'. > > It says so in the VMs man page as well as at > https://man.openbsd.org/pkg_info > (All Sections ; All Architectures ; OpenBSD-current) > (Timestamp: approx. Fri 24 Jan 2020 10:05:00 PM UTC) > > > When I run the command > > # pkg_info -I *.tgz > > I get the result > > Invalid spec: *.tgz > Invalid spec: *.tgz > # > Well, that's less a question about pkg_info(1) but more about the sh(1). In the https://man.openbsd.org/sh.1#Expansion section, look for the paragraph beginning with After field splitting, the shell matches filename patterns. So the above command only makes sense in a directory where you do actually have some packages with file names that match the glob(7) pattern "*.tgz", for example: schwarze@isnote $ cd /usr/ports/packages/amd64/all/ schwarze@isnote $ ls groff* groff-1.22.3p9.tgz groff-1.22.4p2.tgz groff-git-1.22.4p3.tgz groff-1.22.4.tgzgroff-1.22.4p3.tgz schwarze@isnote $ pkg_info -D unsigned -I *.tgz | grep groff gpresent-2.3p0.tgz make presentations with groff and PDF gpresent-2.5.tgzmake presentations with groff and PDF groff-1.22.3p9.tgz GNU troff typesetter groff-1.22.4.tgzGNU troff typesetter groff-1.22.4p2.tgz GNU troff typesetter groff-1.22.4p3.tgz GNU troff typesetter groff-git-1.22.4p3.tgz GNU troff typesetter ja-groff-1.10_0.99p2.tgz japanese groff > If I run > # pkg_info -l *.tgz # NOTE the little ell instead of capital eye Using -l in this way doesn't really make sense. Look at $ man -O tag=l pkg_info # or https://man.openbsd.org/pkg_info.1#l for what -l does. You don't want to give "*.tgz" as an option argument to -l. > If I run > # pkg_info -I > > I get the result > pkg_info: Missing package name(s) > Usage: <...> Yes. It pays off to read manual pages and error messages closely, at least on OpenBSD. pkg_info(1) says: -I Show the index entry for each package. So with -I, you need to say for which package(s) you want to see index entries. > Searching for "openbsd pkg_info -I" with duckduckgo Don't search the web for OpenBSD documentation that way. Yes, for Linux, it's sometimes hard to get any help without searching the web indiscriminately. But for OpenBSD, everything is supposed to be explained in the manual page of the program you are trying to use, so look there. Random stuff from the web is likely to just confuse you even more. > What other information can I provide to clarify where the problem lies? > (It may be the man page, pkg_info, "layer 8" or a combination of these > three factors.) The information you provided was pretty good, i hope i could help. Yours, Ingo
pkg_info(1) man page possible error
Hello, I am running OpenBSD in a virtualbox because I am taking a deeper look into it. I was looking for a list of ports packages and read the man page pkg_info(1). That man page it states, "When browsing through uninstalled packages, running pkg_info -I *.tgz will report a summary line for each package [...]" Note the capital eye 'I'. It says so in the VMs man page as well as at https://man.openbsd.org/pkg_info (All Sections ; All Architectures ; OpenBSD-current) (Timestamp: approx. Fri 24 Jan 2020 10:05:00 PM UTC) When I run the command # pkg_info -I *.tgz I get the result Invalid spec: *.tgz Invalid spec: *.tgz # If I run # pkg_info -l *.tgz # NOTE the little ell instead of capital eye I get something that looks like the list the man page describes. Two columns, first being package name and second being a short one line description. If I run # pkg_info -I I get the result pkg_info: Missing package name(s) Usage: <...> Searching for "openbsd pkg_info -I" with duckduckgo just presented the OpenBSD FAQ and Manual Pages and something about a pkg_info -Q bug. I read the man page's descriptions for options -I and -l and it seems to me that -I (capital eye) *should* work the way the man page exemplifies its use or maybe even without an argument. Maybe I am misinterpreting the descriptions. I do not quite understand why requesting the list of packages including a short description works with -l (small ell), which takes a string as an argument. What other information can I provide to clarify where the problem lies? (It may be the man page, pkg_info, "layer 8" or a combination of these three factors.) # uname -a OpenBSD 6.6 GENERIC#4 amd64 Thank you for your time, Andrew Easton
Re: pkg_info -Q bug?
Thanks Stuart,
I tried that package and it indeed does what i needed :)
But I decided to scratch my itch anyway and dug a bit into the
pkg_info code to figure out
what was going on and I found the culprit: is the match_locations function
in the PackageRepositoryList class that all the matches from the first
repository that has some.
I changed that behaviour but that had some side effects so I modified
the PkgInfo class, the patch
follows. Hope this might help for future work on pkg_info.
Cheers,
Antonio
##
Index: usr.sbin/pkg_add/OpenBSD/PkgInfo.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
retrieving revision 1.49
diff -u -p -u -p -r1.49 PkgInfo.pm
--- usr.sbin/pkg_add/OpenBSD/PkgInfo.pm7 Oct 2017 13:23:05 -1.49
+++ usr.sbin/pkg_add/OpenBSD/PkgInfo.pm23 Nov 2019 17:45:52 -
@@ -597,15 +597,18 @@ sub parse_and_run
$state->say("PKG_PATH=#1", $ENV{PKG_PATH} // "")
if $state->verbose;
my $partial = OpenBSD::Search::PartialStem->new($state->opt('Q'));
-my $r = $state->repo->match_locations($partial);
-for my $pkg (sort {$a->name cmp $b->name} @$r) {
-my $p = $pkg->name;
-if ($state->hasanyopt('cdfMqs')) {
-$self->print_info($state, $p, $pkg);
-} else {
-$state->say(
-is_installed($p) ? "#1 (installed)" : "#1", $p);
+for my $repo (@{$state->locator->default_path($state)->{l}}) {
+$state->say("Repo: #1:#2", $repo->urlscheme, $repo->baseurl);
+my $r = $repo->match_locations($partial);
+for my $pkg (sort {$a->name cmp $b->name} @$r) {
+my $p = $pkg->name;
+if ($state->hasanyopt('cdfMqs')) {
+$self->print_info($state, $p, $pkg);
+} else {
+$state->say(
+is_installed($p) ? "#1 (installed)" : "#1", $p);
+}
}
}
##
On Tue, Nov 19, 2019 at 22:53 Stuart Henderson wrote:
>
> On 2019-11-19, Marc Espie wrote:
> > On Tue, Nov 19, 2019 at 12:13:37PM +0200, Dumitru Moldovan wrote:
> >> On Mon, Nov 18, 2019 at 11:15:05AM +0100, Antonio Bibiano wrote:
> >> > Hello,
> >> > I just wanted to add to this thread that I incurred in the same
> >> > issue on a fresh 6.6 installation.
> >> > I also tried with a different mirror in /etc/installurl and receive
> >> > the same partial response from pkg_info -Q.
> >> > What makes it even more odd is that pkg_add finds the correct package.
> >>
> >> Thanks Antonio for double-checking this! I have also tested it on a
> >> fresh installation at the time and got the same results.
> >>
> >> Maybe the behaviour is undefined if PKG_PATH is not set, which is fine
> >> by me. But still, it's quite puzzling and against the principle of
> >> least surprise.
> >
> > It's one of those little things that is well known, but that won't change
> > until I have time to look at it, and it's definitely not a high priority
> > problem right now.
> >
> >
>
> As a workaround (but also something that would be more likely to give
> the results wanted than a properly-working pkg_info -Q which doesn't match
> filenames inside the packages), you might like to "pkg_add pkglocatedb"
> and use the "pkglocate" tool that this provides.
>
Re: pkg_info -Q bug?
On 2019-11-19, Marc Espie wrote: > On Tue, Nov 19, 2019 at 12:13:37PM +0200, Dumitru Moldovan wrote: >> On Mon, Nov 18, 2019 at 11:15:05AM +0100, Antonio Bibiano wrote: >> > Hello, >> > I just wanted to add to this thread that I incurred in the same >> > issue on a fresh 6.6 installation. >> > I also tried with a different mirror in /etc/installurl and receive >> > the same partial response from pkg_info -Q. >> > What makes it even more odd is that pkg_add finds the correct package. >> >> Thanks Antonio for double-checking this! I have also tested it on a >> fresh installation at the time and got the same results. >> >> Maybe the behaviour is undefined if PKG_PATH is not set, which is fine >> by me. But still, it's quite puzzling and against the principle of >> least surprise. > > It's one of those little things that is well known, but that won't change > until I have time to look at it, and it's definitely not a high priority > problem right now. > > As a workaround (but also something that would be more likely to give the results wanted than a properly-working pkg_info -Q which doesn't match filenames inside the packages), you might like to "pkg_add pkglocatedb" and use the "pkglocate" tool that this provides.
Re: pkg_info -Q bug?
On Tue, Nov 19, 2019 at 12:13:37PM +0200, Dumitru Moldovan wrote: > On Mon, Nov 18, 2019 at 11:15:05AM +0100, Antonio Bibiano wrote: > > Hello, > > I just wanted to add to this thread that I incurred in the same > > issue on a fresh 6.6 installation. > > I also tried with a different mirror in /etc/installurl and receive > > the same partial response from pkg_info -Q. > > What makes it even more odd is that pkg_add finds the correct package. > > Thanks Antonio for double-checking this! I have also tested it on a > fresh installation at the time and got the same results. > > Maybe the behaviour is undefined if PKG_PATH is not set, which is fine > by me. But still, it's quite puzzling and against the principle of > least surprise. It's one of those little things that is well known, but that won't change until I have time to look at it, and it's definitely not a high priority problem right now.
Re: pkg_info -Q bug?
On Mon, Nov 18, 2019 at 11:15:05AM +0100, Antonio Bibiano wrote: Hello, I just wanted to add to this thread that I incurred in the same issue on a fresh 6.6 installation. I also tried with a different mirror in /etc/installurl and receive the same partial response from pkg_info -Q. What makes it even more odd is that pkg_add finds the correct package. Thanks Antonio for double-checking this! I have also tested it on a fresh installation at the time and got the same results. Maybe the behaviour is undefined if PKG_PATH is not set, which is fine by me. But still, it's quite puzzling and against the principle of least surprise.
Re: pkg_info -Q bug?
Hello, I just wanted to add to this thread that I incurred in the same issue on a fresh 6.6 installation. I also tried with a different mirror in /etc/installurl and receive the same partial response from pkg_info -Q. What makes it even more odd is that pkg_add finds the correct package. Cheers, Antonio Bibiano On Fri, Nov 08, 2019 at 09:34:06PM GMT, Dumitru Moldovan wrote: >On Fri, Nov 08, 2019 at 08:04:45PM +, Raf Czlonka wrote: >>On Fri, Nov 08, 2019 at 05:45:23PM GMT, Dumitru Moldovan wrote: >>> >>> Hi misc, >>> >>> I see pkg_info's man page says: >>> >>>-Q query >>>Show all packages in $PKG_PATH which match the given query. >>> >>> Trying in 6.6 to find the Python module "mysqlclient", I get the >>> following puzzling results: >>> >>> $ pkg_info -Q mysql >>> php-mysqli-7.2.24 >>> php-mysqli-7.3.11 >>> php-pdo_mysql-7.2.24 >>> php-pdo_mysql-7.3.11 >>> >>> $ pkg_info -Q py-mysql >>> py-mysql-1.2.5p6 >>> py-mysqlclient-1.4.2p0 >>> >>> Am I doing something wrong? Why is "py-mysqlclient" not matched for >>> the first query? >>> >> >>Hi Dumitru, >> >>Not only isn't "py-mysqlclient" matched, but also over 40 other >>packages with "mysql" string. >> >>How does your $PKG_PATH look like? > >Thanks for looking into it! > >$PKG_PATH is empty here, should have checked it first. I get the >expected results with: > >PKG_PATH=`cat /etc/installurl`/`uname -r`/packages/`uname -m`/ pkg_info -Q >mysql > >But now I don't understand why I got any results at all with an empty >$PKG_PATH... Maybe I would have read that one line in the man page >more carefully if there was no result at all to begin with. :-] >
Re: pkg_info -Q bug?
On Fri, Nov 08, 2019 at 08:04:45PM +, Raf Czlonka wrote: On Fri, Nov 08, 2019 at 05:45:23PM GMT, Dumitru Moldovan wrote: Hi misc, I see pkg_info's man page says: -Q query Show all packages in $PKG_PATH which match the given query. Trying in 6.6 to find the Python module "mysqlclient", I get the following puzzling results: $ pkg_info -Q mysql php-mysqli-7.2.24 php-mysqli-7.3.11 php-pdo_mysql-7.2.24 php-pdo_mysql-7.3.11 $ pkg_info -Q py-mysql py-mysql-1.2.5p6 py-mysqlclient-1.4.2p0 Am I doing something wrong? Why is "py-mysqlclient" not matched for the first query? Hi Dumitru, Not only isn't "py-mysqlclient" matched, but also over 40 other packages with "mysql" string. How does your $PKG_PATH look like? Thanks for looking into it! $PKG_PATH is empty here, should have checked it first. I get the expected results with: PKG_PATH=`cat /etc/installurl`/`uname -r`/packages/`uname -m`/ pkg_info -Q mysql But now I don't understand why I got any results at all with an empty $PKG_PATH... Maybe I would have read that one line in the man page more carefully if there was no result at all to begin with. :-]
Re: pkg_info -Q bug?
On Fri, Nov 08, 2019 at 05:45:23PM GMT, Dumitru Moldovan wrote: > > Hi misc, > > I see pkg_info's man page says: > >-Q query >Show all packages in $PKG_PATH which match the given query. > > Trying in 6.6 to find the Python module "mysqlclient", I get the > following puzzling results: > > $ pkg_info -Q mysql > php-mysqli-7.2.24 > php-mysqli-7.3.11 > php-pdo_mysql-7.2.24 > php-pdo_mysql-7.3.11 > > $ pkg_info -Q py-mysql > py-mysql-1.2.5p6 > py-mysqlclient-1.4.2p0 > > Am I doing something wrong? Why is "py-mysqlclient" not matched for > the first query? > Hi Dumitru, Not only isn't "py-mysqlclient" matched, but also over 40 other packages with "mysql" string. How does your $PKG_PATH look like? Regards, Raf
pkg_info -Q bug?
Hi misc, I see pkg_info's man page says: -Q query Show all packages in $PKG_PATH which match the given query. Trying in 6.6 to find the Python module "mysqlclient", I get the following puzzling results: $ pkg_info -Q mysql php-mysqli-7.2.24 php-mysqli-7.3.11 php-pdo_mysql-7.2.24 php-pdo_mysql-7.3.11 $ pkg_info -Q py-mysql py-mysql-1.2.5p6 py-mysqlclient-1.4.2p0 Am I doing something wrong? Why is "py-mysqlclient" not matched for the first query? Thanks!
pkg_info -Q multiple queries?
Hello, Is there a way to do multiple queries at once using pkg_info? Something like: pkg_info -Q query1 query2 ... The best I've found so far is to do something like: for q in query1 query2 ...; do pkg_info -Q $q; done which is slow when the list of queries is long (my network bandwidth is not what I would like it to be...) Background: I'm running 6.5-release and would like to upgrade to 6.6-release by doing an offline upgrade, downloading the base system and packages in advance at work to do the upgrade offline later at home (where my network bandwidth is even worse than at work). So for packages I would like to do something like this, in a script (with the hope that package dependencies have not changed too much between 6.5 and 6.6): export PKG_PATH=.../6.6/packages/... pkg_info -z | xargs pkg_info -q -Q | while read p; do wget $PKG_PATH/$p.tgz; done (or even better: pkg_info -z | pkg_info -q -Q | while ...) Note: I also tried to combine pkg_info with pkg_add: export PKG_PATH=.../6.6/packages/... export PKG_CACHE=... pkg_info -mz > pkglist pkg_add -n -l pkglist but: 1) pkg_add only downloads into $PKG_CACHE the packages listed in the pkglist file, not the dependencies; 2) pkg_add deletes each package it downloads after the download is finished. Is there some magic combination of options that I can use with pkg_add to make it download and keep all the packages listed in the pkglist file, plus all the required dependencies? (being able to do: pkg_info -mz | pkg_add -n -l would be nice too!) Thanks, Philippe
Re: pkg_info - dependencies of package
Hi Evan, Evan Silberman wrote on Wed, May 01, 2019 at 04:24:51PM -0700: > pkg_info -R PACKAGE lists the packages that depend on PACKAGE. Is there a > particular reason there's not an analogous option that lists a package's own > dependencies? (i.e., listing the contents of +REQUIRING from the package > db, rather than +REQUIRED_BY) > > (Granted, in asking this question, I have taught myself where to find this > information for installed packages without adding it to pkg_info, but it still > seems like a thing pkg_info could reasonbly be expected to do.) As usual with pkg_add(1), there is already more than one way how it does roughly what you want: $ pkg_info -f mutt | grep ^@depend $ pkg_info -S mutt Sure, those handle indirect dependencies in a sligtly different way than +REQUIRED_BY. But there is value in keeping option proliferation at bay. Yours, Ingo
pkg_info - dependencies of package
pkg_info -R PACKAGE lists the packages that depend on PACKAGE. Is there a particular reason there's not an analogous option that lists a package's own dependencies? (i.e., listing the contents of +REQUIRING from the package db, rather than +REQUIRED_BY) (Granted, in asking this question, I have taught myself where to find this information for installed packages without adding it to pkg_info, but it still seems like a thing pkg_info could reasonbly be expected to do.) -- Evan Silberman
Re: pkg_info -Q fails [OpenBSD 6.3 amd64/virtualbox]
On 04/15/18 14:37, Jeffrey Joshua Rollin wrote: On 15 April 2018 at 12:03, Juan Francisco Cantero Hurtado <i...@juanfra.info <mailto:i...@juanfra.info>> wrote: On Sun, Apr 15, 2018 at 11:19:50AM +0100, Jeffrey Joshua Rollin wrote: > No, it works fine with pkg_add, as I have repeatedly said, and a few months ago I did have a problem where a trailing slash caused problems with syspatch, which, without any pressure from me, I was informed would be fixed. The issue may simply be one of consistency, but looks more likely to be an error in the pkg_info script. > > So, to sum up: > > Pkg_add works; > Syspatch works; > Cloudflare was up last time I tried it; > Despite the above, pkg_info -Q does *not* work. Try this: $ su -l root # echo 'https://fastly.cdn.openbsd.org/pub/OpenBSD/ <https://fastly.cdn.openbsd.org/pub/OpenBSD/>' > /etc/installurl # unset PKG_PATH # pkg_info -Q mate If fastly works, try with cloudflare again. BTW, we don't have a metapackage for mate. Whoops, I forgot about this bit. Yes, fastly works, but trying just https://cdn.openbsd.org/pub/OpenBSD/ does not; I tried that because it was listed on the OpenBSD website FAQ, having forgotten fthat I'd used cloudflare before; the same error came up with the address listed on the website, as I mentioned previously. You are missing the `cloudflare' part. Yesterday you had /org instead of .org. edgar:9$ PKG_PATH=https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.3/packages/amd64 pkg_info -Q mate checkmate-0.21 libmatekbd-1.20.0 libmatemixer-1.20.0 libmateweather-1.20.0 mate-calc-1.20.0 mate-control-center-1.20.0 mate-desktop-1.20.0 mate-icon-theme-1.20.0 mate-media-1.20.0 mate-menus-1.20.0 mate-notification-daemon-1.20.0 mate-panel-1.20.0 mate-power-manager-1.20.0 mate-screensaver-1.20.0 mate-session-manager-1.20.0 mate-settings-daemon-1.20.0 mate-terminal-1.20.0 mate-themes-3.22.15 mate-utils-1.20.0 sslmate-1.5.1p1 tmate-2.2.1p0 For now, I'll just stick to fastly. Thanks. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: pkg_info -Q fails [OpenBSD 6.3 amd64/virtualbox]
On 15 April 2018 at 12:03, Juan Francisco Cantero Hurtado <i...@juanfra.info> wrote: > On Sun, Apr 15, 2018 at 11:19:50AM +0100, Jeffrey Joshua Rollin wrote: > > No, it works fine with pkg_add, as I have repeatedly said, and a few > months ago I did have a problem where a trailing slash caused problems with > syspatch, which, without any pressure from me, I was informed would be > fixed. The issue may simply be one of consistency, but looks more likely to > be an error in the pkg_info script. > > > > So, to sum up: > > > > Pkg_add works; > > Syspatch works; > > Cloudflare was up last time I tried it; > > Despite the above, pkg_info -Q does *not* work. > > Try this: > > $ su -l root > # echo 'https://fastly.cdn.openbsd.org/pub/OpenBSD/' > /etc/installurl > # unset PKG_PATH > # pkg_info -Q mate > > If fastly works, try with cloudflare again. BTW, we don't have a > metapackage for mate. > Whoops, I forgot about this bit. Yes, fastly works, but trying just https://cdn.openbsd.org/pub/OpenBSD/ does not; I tried that because it was listed on the OpenBSD website FAQ, having forgotten fthat I'd used cloudflare before; the same error came up with the address listed on the website, as I mentioned previously. For now, I'll just stick to fastly. Thanks. > -- > Juan Francisco Cantero Hurtado http://juanfra.info >
Re: pkg_info -Q fails [OpenBSD 6.3 amd64/virtualbox]
Yes, I'd already remembered that myself. Sent from Blue On 15 Apr 2018, 12:03, at 12:03, Juan Francisco Cantero Hurtado <i...@juanfra.info> wrote: >On Sun, Apr 15, 2018 at 11:19:50AM +0100, Jeffrey Joshua Rollin wrote: >> No, it works fine with pkg_add, as I have repeatedly said, and a few >months ago I did have a problem where a trailing slash caused problems >with syspatch, which, without any pressure from me, I was informed >would be fixed. The issue may simply be one of consistency, but looks >more likely to be an error in the pkg_info script. >> >> So, to sum up: >> >> Pkg_add works; >> Syspatch works; >> Cloudflare was up last time I tried it; >> Despite the above, pkg_info -Q does *not* work. > >Try this: > >$ su -l root ># echo 'https://fastly.cdn.openbsd.org/pub/OpenBSD/' > /etc/installurl ># unset PKG_PATH ># pkg_info -Q mate > >If fastly works, try with cloudflare again. BTW, we don't have a >metapackage for mate. > >> >> Jeff >> >> Sent from Blue >> >> On 15 Apr 2018, 03:26, at 03:26, Edgar Pettijohn ><ed...@pettijohn-web.com> wrote: >> > >> > >> >On 04/14/18 19:34, Jeffrey Joshua Rollin wrote: >> >> >> >> >> >> Sent from Blue <http://www.bluemail.me/r?b=12687> >> >> On 15 Apr 2018, at 00:31, Edgar Pettijohn <ed...@pettijohn-web.com >> >> <mailto:ed...@pettijohn-web.com>> wrote: >> >> >> >> >> >> On 04/14/18 15:08, Jeffrey Joshua Rollin wrote: >> >> >> >> Hi, I've installed OpenBSD 6.3-release for amd64 on >> >> virtualbox, and updated it with syspatch as of 20:40 UTC. >> >> pkg_info -Q seems to be failing. Specifically, I tried $ >> >> pkg_info -Q mate ...and also as root, to remind myself >what >> >> the metapackage is [I have a feeling it's just "mate" >anyway] >> >> [EDIT: Metapackages? maybe I'm thinking of FreeBSD]; but: >> >> pkg_info -Q firefox also fails, despite the fact I just >> >> successfully installed Firefox. The relevant error is as >> >> follows: Redirected to >> >> >> >>https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 >> >> >> >> >> >^^ >> >Your PKG_PATH appears to have a couple of errors. >> > >> >https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.3/packages/amd64 >> > >> >and I can't remember but it may need to end with a `/' >> >> >> >> Can't locate object method "syslog" via package >> >> "OpenBSD::PkgInfo::State" at >> >> /usr/libdata/perl5/OpenBSD/PackageRepository.pm >> >> <http://PackageRepository.pm> line 302, <$fh> line 3. >Thanks, >> >> Jeff. >> >> >> >> edgar:7$ pkg_info -Q mate >> >> checkmate-0.21 >> >> libmatekbd-1.20.0 >> >> libmatemixer-1.20.0 >> >> libmateweather-1.20.0 >> >> mate-calc-1.20.0 >> >> mate-control-center-1.20.0 >> >> mate-desktop-1.20.0 >> >> mate-icon-theme-1.20.0 >> >> mate-media-1.20.0 >> >> mate-menus-1.20.0 >> >> mate-notification-daemon-1.20.0 >> >> mate-panel-1.20.0 >> >> mate-power-manager-1.20.0 >> >> mate-screensaver-1.20.0 >> >> mate-session-manager-1.20.0 >> >> mate-settings-daemon-1.20.0 >> >> mate-terminal-1.20.0 >> >> mate-themes-3.22.15 >> >> mate-utils-1.20.0 >> >> sslmate-1.5.1p1 >> >> tmate-2.2.1p0 >> >> >> >> I suspect its because >> >> >> >> >> >>https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 >> >> >> >> doesn't exist or is down. >> >> >> >> It exists, and is unlikely to be a transient error, >> >> >> >> because I tried it several times, and as I said, was able >> >> >> >> to download software even though I couldn't query it. >> >> >> >> (I subsequently found a YouTube tutorial which listed >> >> >> >> most of the packages in your message.) >> >> >> >> I will try again, and/or with a different mirror in >> >> >> >> the morning. >> >> >> >> Jeff >> >> > >-- >Juan Francisco Cantero Hurtado http://juanfra.info
Re: pkg_info -Q fails [OpenBSD 6.3 amd64/virtualbox]
On Sun, Apr 15, 2018 at 11:19:50AM +0100, Jeffrey Joshua Rollin wrote: > No, it works fine with pkg_add, as I have repeatedly said, and a few months > ago I did have a problem where a trailing slash caused problems with > syspatch, which, without any pressure from me, I was informed would be fixed. > The issue may simply be one of consistency, but looks more likely to be an > error in the pkg_info script. > > So, to sum up: > > Pkg_add works; > Syspatch works; > Cloudflare was up last time I tried it; > Despite the above, pkg_info -Q does *not* work. Try this: $ su -l root # echo 'https://fastly.cdn.openbsd.org/pub/OpenBSD/' > /etc/installurl # unset PKG_PATH # pkg_info -Q mate If fastly works, try with cloudflare again. BTW, we don't have a metapackage for mate. > > Jeff > > Sent from Blue > > On 15 Apr 2018, 03:26, at 03:26, Edgar Pettijohn <ed...@pettijohn-web.com> > wrote: > > > > > >On 04/14/18 19:34, Jeffrey Joshua Rollin wrote: > >> > >> > >> Sent from Blue <http://www.bluemail.me/r?b=12687> > >> On 15 Apr 2018, at 00:31, Edgar Pettijohn <ed...@pettijohn-web.com > >> <mailto:ed...@pettijohn-web.com>> wrote: > >> > >> > >> On 04/14/18 15:08, Jeffrey Joshua Rollin wrote: > >> > >> Hi, I've installed OpenBSD 6.3-release for amd64 on > >> virtualbox, and updated it with syspatch as of 20:40 UTC. > >> pkg_info -Q seems to be failing. Specifically, I tried $ > >> pkg_info -Q mate ...and also as root, to remind myself what > >> the metapackage is [I have a feeling it's just "mate" anyway] > >> [EDIT: Metapackages? maybe I'm thinking of FreeBSD]; but: > >> pkg_info -Q firefox also fails, despite the fact I just > >> successfully installed Firefox. The relevant error is as > >> follows: Redirected to > >> > >https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 > >> > >> > >^^ > >Your PKG_PATH appears to have a couple of errors. > > > >https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.3/packages/amd64 > > > >and I can't remember but it may need to end with a `/' > >> > >> Can't locate object method "syslog" via package > >> "OpenBSD::PkgInfo::State" at > >> /usr/libdata/perl5/OpenBSD/PackageRepository.pm > >> <http://PackageRepository.pm> line 302, <$fh> line 3. Thanks, > >> Jeff. > >> > >> edgar:7$ pkg_info -Q mate > >> checkmate-0.21 > >> libmatekbd-1.20.0 > >> libmatemixer-1.20.0 > >> libmateweather-1.20.0 > >> mate-calc-1.20.0 > >> mate-control-center-1.20.0 > >> mate-desktop-1.20.0 > >> mate-icon-theme-1.20.0 > >> mate-media-1.20.0 > >> mate-menus-1.20.0 > >> mate-notification-daemon-1.20.0 > >> mate-panel-1.20.0 > >> mate-power-manager-1.20.0 > >> mate-screensaver-1.20.0 > >> mate-session-manager-1.20.0 > >> mate-settings-daemon-1.20.0 > >> mate-terminal-1.20.0 > >> mate-themes-3.22.15 > >> mate-utils-1.20.0 > >> sslmate-1.5.1p1 > >> tmate-2.2.1p0 > >> > >> I suspect its because > >> > >> > >https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 > >> > >> doesn't exist or is down. > >> > >> It exists, and is unlikely to be a transient error, > >> > >> because I tried it several times, and as I said, was able > >> > >> to download software even though I couldn't query it. > >> > >> (I subsequently found a YouTube tutorial which listed > >> > >> most of the packages in your message.) > >> > >> I will try again, and/or with a different mirror in > >> > >> the morning. > >> > >> Jeff > >> -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: pkg_info -Q fails [OpenBSD 6.3 amd64/virtualbox]
No, it works fine with pkg_add, as I have repeatedly said, and a few months ago I did have a problem where a trailing slash caused problems with syspatch, which, without any pressure from me, I was informed would be fixed. The issue may simply be one of consistency, but looks more likely to be an error in the pkg_info script. So, to sum up: Pkg_add works; Syspatch works; Cloudflare was up last time I tried it; Despite the above, pkg_info -Q does *not* work. Jeff Sent from Blue On 15 Apr 2018, 03:26, at 03:26, Edgar Pettijohn <ed...@pettijohn-web.com> wrote: > > >On 04/14/18 19:34, Jeffrey Joshua Rollin wrote: >> >> >> Sent from Blue <http://www.bluemail.me/r?b=12687> >> On 15 Apr 2018, at 00:31, Edgar Pettijohn <ed...@pettijohn-web.com >> <mailto:ed...@pettijohn-web.com>> wrote: >> >> >> On 04/14/18 15:08, Jeffrey Joshua Rollin wrote: >> >> Hi, I've installed OpenBSD 6.3-release for amd64 on >> virtualbox, and updated it with syspatch as of 20:40 UTC. >> pkg_info -Q seems to be failing. Specifically, I tried $ >> pkg_info -Q mate ...and also as root, to remind myself what >> the metapackage is [I have a feeling it's just "mate" anyway] >> [EDIT: Metapackages? maybe I'm thinking of FreeBSD]; but: >> pkg_info -Q firefox also fails, despite the fact I just >> successfully installed Firefox. The relevant error is as >> follows: Redirected to >> >https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 >> >> >^^ >Your PKG_PATH appears to have a couple of errors. > >https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.3/packages/amd64 > >and I can't remember but it may need to end with a `/' >> >> Can't locate object method "syslog" via package >> "OpenBSD::PkgInfo::State" at >> /usr/libdata/perl5/OpenBSD/PackageRepository.pm >> <http://PackageRepository.pm> line 302, <$fh> line 3. Thanks, >> Jeff. >> >> edgar:7$ pkg_info -Q mate >> checkmate-0.21 >> libmatekbd-1.20.0 >> libmatemixer-1.20.0 >> libmateweather-1.20.0 >> mate-calc-1.20.0 >> mate-control-center-1.20.0 >> mate-desktop-1.20.0 >> mate-icon-theme-1.20.0 >> mate-media-1.20.0 >> mate-menus-1.20.0 >> mate-notification-daemon-1.20.0 >> mate-panel-1.20.0 >> mate-power-manager-1.20.0 >> mate-screensaver-1.20.0 >> mate-session-manager-1.20.0 >> mate-settings-daemon-1.20.0 >> mate-terminal-1.20.0 >> mate-themes-3.22.15 >> mate-utils-1.20.0 >> sslmate-1.5.1p1 >> tmate-2.2.1p0 >> >> I suspect its because >> >> >https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 >> >> doesn't exist or is down. >> >> It exists, and is unlikely to be a transient error, >> >> because I tried it several times, and as I said, was able >> >> to download software even though I couldn't query it. >> >> (I subsequently found a YouTube tutorial which listed >> >> most of the packages in your message.) >> >> I will try again, and/or with a different mirror in >> >> the morning. >> >> Jeff >>
Re: pkg_info -Q fails [OpenBSD 6.3 amd64/virtualbox]
On 04/14/18 19:34, Jeffrey Joshua Rollin wrote: Sent from Blue <http://www.bluemail.me/r?b=12687> On 15 Apr 2018, at 00:31, Edgar Pettijohn <ed...@pettijohn-web.com <mailto:ed...@pettijohn-web.com>> wrote: On 04/14/18 15:08, Jeffrey Joshua Rollin wrote: Hi, I've installed OpenBSD 6.3-release for amd64 on virtualbox, and updated it with syspatch as of 20:40 UTC. pkg_info -Q seems to be failing. Specifically, I tried $ pkg_info -Q mate ...and also as root, to remind myself what the metapackage is [I have a feeling it's just "mate" anyway] [EDIT: Metapackages? maybe I'm thinking of FreeBSD]; but: pkg_info -Q firefox also fails, despite the fact I just successfully installed Firefox. The relevant error is as follows: Redirected to https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 ^^ Your PKG_PATH appears to have a couple of errors. https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.3/packages/amd64 and I can't remember but it may need to end with a `/' Can't locate object method "syslog" via package "OpenBSD::PkgInfo::State" at /usr/libdata/perl5/OpenBSD/PackageRepository.pm <http://PackageRepository.pm> line 302, <$fh> line 3. Thanks, Jeff. edgar:7$ pkg_info -Q mate checkmate-0.21 libmatekbd-1.20.0 libmatemixer-1.20.0 libmateweather-1.20.0 mate-calc-1.20.0 mate-control-center-1.20.0 mate-desktop-1.20.0 mate-icon-theme-1.20.0 mate-media-1.20.0 mate-menus-1.20.0 mate-notification-daemon-1.20.0 mate-panel-1.20.0 mate-power-manager-1.20.0 mate-screensaver-1.20.0 mate-session-manager-1.20.0 mate-settings-daemon-1.20.0 mate-terminal-1.20.0 mate-themes-3.22.15 mate-utils-1.20.0 sslmate-1.5.1p1 tmate-2.2.1p0 I suspect its because https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 doesn't exist or is down. It exists, and is unlikely to be a transient error, because I tried it several times, and as I said, was able to download software even though I couldn't query it. (I subsequently found a YouTube tutorial which listed most of the packages in your message.) I will try again, and/or with a different mirror in the morning. Jeff
pkg_info -Q fails [OpenBSD 6.3 amd64/virtualbox]
Hi, I've installed OpenBSD 6.3-release for amd64 on virtualbox, and updated it with syspatch as of 20:40 UTC. pkg_info -Q seems to be failing. Specifically, I tried $ pkg_info -Q mate ...and also as root, to remind myself what the metapackage is [I have a feeling it's just "mate" anyway] [EDIT: Metapackages? maybe I'm thinking of FreeBSD]; but: pkg_info -Q firefox also fails, despite the fact I just successfully installed Firefox. The relevant error is as follows: Redirected to https://cloudflare.cdn.openbsd/org/pub/OpenBSD/6.3/packages-stable/amd64 Can't locate object method "syslog" via package "OpenBSD::PkgInfo::State" at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 302, <$fh> line 3. Thanks, Jeff.
Re: pkg_info fails for non-installed packages when PKG_CACHE is set to a directory the current user can't write to
Hi Lari/Marc/all, On Thu, 2 Nov 2017 00:21:08 +0200 Lari Rasku wrote: > Oh, it's a ports tree mechanism? I only use packages, so I've been > using it for a fast reinstall/lookup cache in case I come to second > thoughts about some package: Likewise, I have: $ printenv | fgrep PKG_ PKG_CACHE=/var/cache/pkg PKG_PATH=$PKG_CACHE:http://mirror. /var/cache/pkg/ is group writable by wheel, so unpriv sysadmins can do pkg_add -n to download & cache items, for root to install later. I thought the cache was to reduce remote package server/network load. Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: pkg_info fails for non-installed packages when PKG_CACHE is set to a directory the current user can't write to
Marc Espie kirjoitti 11/01/17 klo 20:11: On Wed, Nov 01, 2017 at 11:51:52AM +0100, Marc Espie wrote: >> Somewhat low priority. > > Fairly easy to fix actually, so it's going to be in current, thx Sweet. Well, people usually don't define PKG_CACHE manually, but rely on the ports tree to do it when needed. Oh, it's a ports tree mechanism? I only use packages, so I've been using it for a fast reinstall/lookup cache in case I come to second thoughts about some package: $ cat /etc/profile export PKG_CACHE=/var/cache/pkg export PKG_PATH=$PKG_CACHE:installpath Though this came back to bite me when I tried upgrading packages yesterday, as pkg_add -u naturally quit its search at the cache. This one probably isn't a supported use case...
Re: pkg_info fails for non-installed packages when PKG_CACHE is set to a directory the current user can't write to
On Wed, Nov 01, 2017 at 11:51:52AM +0100, Marc Espie wrote: > On Mon, Oct 30, 2017 at 09:05:53PM +0200, Lari Rasku wrote: > > Oct 27 snapshot, amd64. > > > > When PKG_CACHE is set: > > > > $ cat /etc/profile > > export PKG_CACHE=/var/cache/pkg > > > > To a directory the current user lacks write access to: > > > > $ touch /var/cache/pkg/somefile > > touch: /var/cache/pkg/somefile: Permission denied > > > > Trying to call pkg_info on an uninstalled package fails: > > > > $ pkg_info -e lumina-1.3.0pl1p2; echo $? > > 1 > > $ pkg_info lumina-1.3.0pl1p2 > > Fatal error: bad PKG_CACHE directory /var/cache/pkg > > at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 669. > > > > This is surprising, because I didn't expect pkg_info to write anything but > > temporary files; PKG_CACHE is not documented on pkg_info(1). The program > > doesn't apparently even intend to cache anything, as when I temporarily set > > PKG_CACHE to something writable: > > Fun one. Well, people usually don't define PKG_CACHE manually, but rely > on the ports tree to do it when needed. > > Tweaking the full chain to only handle it with pkg_add would be feasible. > > Somewhat low priority. Fairly easy to fix actually, so it's going to be in current, thx
Re: pkg_info fails for non-installed packages when PKG_CACHE is set to a directory the current user can't write to
On Mon, Oct 30, 2017 at 09:05:53PM +0200, Lari Rasku wrote: > Oct 27 snapshot, amd64. > > When PKG_CACHE is set: > > $ cat /etc/profile > export PKG_CACHE=/var/cache/pkg > > To a directory the current user lacks write access to: > > $ touch /var/cache/pkg/somefile > touch: /var/cache/pkg/somefile: Permission denied > > Trying to call pkg_info on an uninstalled package fails: > > $ pkg_info -e lumina-1.3.0pl1p2; echo $? > 1 > $ pkg_info lumina-1.3.0pl1p2 > Fatal error: bad PKG_CACHE directory /var/cache/pkg >at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 669. > > This is surprising, because I didn't expect pkg_info to write anything but > temporary files; PKG_CACHE is not documented on pkg_info(1). The program > doesn't apparently even intend to cache anything, as when I temporarily set > PKG_CACHE to something writable: Fun one. Well, people usually don't define PKG_CACHE manually, but rely on the ports tree to do it when needed. Tweaking the full chain to only handle it with pkg_add would be feasible. Somewhat low priority.
pkg_info fails for non-installed packages when PKG_CACHE is set to a directory the current user can't write to
Oct 27 snapshot, amd64. When PKG_CACHE is set: $ cat /etc/profile export PKG_CACHE=/var/cache/pkg To a directory the current user lacks write access to: $ touch /var/cache/pkg/somefile touch: /var/cache/pkg/somefile: Permission denied Trying to call pkg_info on an uninstalled package fails: $ pkg_info -e lumina-1.3.0pl1p2; echo $? 1 $ pkg_info lumina-1.3.0pl1p2 Fatal error: bad PKG_CACHE directory /var/cache/pkg at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 669. This is surprising, because I didn't expect pkg_info to write anything but temporary files; PKG_CACHE is not documented on pkg_info(1). The program doesn't apparently even intend to cache anything, as when I temporarily set PKG_CACHE to something writable: $ cd $HOME $ PKG_CACHE=. pkg_info lumina-1.3.0pl1p2 Information for https://ftp.eu.openbsd.org/pub/OpenBSD/snapshots /packages/amd64/lumina-1.3.0pl1p2.tgz Comment: Lumina Desktop Environment Description: Lumina-DE is a lightweight, BSD licensed desktop environment. Maintainer: Bryan C. Everly <br...@bceassociates.com> WWW: http://lumina-desktop.org/ It works, but nothing is actually cached: $ ls lumina-1.3.0pl1p2.tgz ls: lumina-1.3.0pl1p2.tgz: No such file or directory Is this a bug, or just an unsupported use case?
Re: pkg_info
On Tue, Jun 28, 2016 at 08:29:23PM -0500, Edgar Pettijohn wrote:
> On 16-06-29 03:16:02, Theo Buehler wrote:
> > On Tue, Jun 28, 2016 at 08:09:02PM -0500, Edgar Pettijohn wrote:
> > > This doesn't seem possible, but maybe I'm missing something.
> > >
> > > I would like pkg_info to tell me where to find a package in
> > > the ports tree. For example:
> > >
> > > If I go to /usr/ports and do make search key=wget I can find
> > > the following.
> > >
> > > Port: wget-1.16.3p0
> > > Path: net/wget
> > > Info: retrieve files from the web via HTTP, HTTPS and FTP
> > > Maint: The OpenBSD ports mailing-list <po...@openbsd.org>
> > > Index: net lang/python
> > > L-deps: STEM->=0.10.38:devel/gettext converters/libiconv devel/libidn
> > > devel/pcre net/libpsl
> > > B-deps: STEM->=0.10.38:devel/gettext archivers/xz devel/gettext-tools
> > > R-deps: STEM->=0.10.38:devel/gettext
> > > Archs: any
> > >
> > > Which tells me to go to /usr/ports/net/wget. Is there currently
> > > a way to achieve this with any of the pkg_ tools?
> >
> > Use the -P option:
> >
> > $ pkg_info -P wget
> > Information for inst:wget-1.18
> >
> > Pkgpath:
> > net/wget
> >
> I can't believe I missed that. Beats the hell out of my alternative.
>
> pkg_info -f wget | grep pkgpath | awk '{print $2}' | cut -f 2 -d =
In that case, you'll want to add the -q option:
$ pkg_add -Pq wget
net/wget
Re: pkg_info
On 16-06-29 03:16:02, Theo Buehler wrote:
> On Tue, Jun 28, 2016 at 08:09:02PM -0500, Edgar Pettijohn wrote:
> > This doesn't seem possible, but maybe I'm missing something.
> >
> > I would like pkg_info to tell me where to find a package in
> > the ports tree. For example:
> >
> > If I go to /usr/ports and do make search key=wget I can find
> > the following.
> >
> > Port: wget-1.16.3p0
> > Path: net/wget
> > Info: retrieve files from the web via HTTP, HTTPS and FTP
> > Maint: The OpenBSD ports mailing-list <po...@openbsd.org>
> > Index: net lang/python
> > L-deps: STEM->=0.10.38:devel/gettext converters/libiconv devel/libidn
> > devel/pcre net/libpsl
> > B-deps: STEM->=0.10.38:devel/gettext archivers/xz devel/gettext-tools
> > R-deps: STEM->=0.10.38:devel/gettext
> > Archs: any
> >
> > Which tells me to go to /usr/ports/net/wget. Is there currently
> > a way to achieve this with any of the pkg_ tools?
>
> Use the -P option:
>
> $ pkg_info -P wget
> Information for inst:wget-1.18
>
> Pkgpath:
> net/wget
>
I can't believe I missed that. Beats the hell out of my alternative.
pkg_info -f wget | grep pkgpath | awk '{print $2}' | cut -f 2 -d =
--
Edgar Pettijohn
Re: pkg_info
On Tue, Jun 28, 2016 at 08:09:02PM -0500, Edgar Pettijohn wrote: > This doesn't seem possible, but maybe I'm missing something. > > I would like pkg_info to tell me where to find a package in > the ports tree. For example: > > If I go to /usr/ports and do make search key=wget I can find > the following. > > Port: wget-1.16.3p0 > Path: net/wget > Info: retrieve files from the web via HTTP, HTTPS and FTP > Maint: The OpenBSD ports mailing-list <po...@openbsd.org> > Index: net lang/python > L-deps: STEM->=0.10.38:devel/gettext converters/libiconv devel/libidn > devel/pcre net/libpsl > B-deps: STEM->=0.10.38:devel/gettext archivers/xz devel/gettext-tools > R-deps: STEM->=0.10.38:devel/gettext > Archs: any > > Which tells me to go to /usr/ports/net/wget. Is there currently > a way to achieve this with any of the pkg_ tools? Use the -P option: $ pkg_info -P wget Information for inst:wget-1.18 Pkgpath: net/wget
Re: pkg_info
Edgar Pettijohn wrote: > I would like pkg_info to tell me where to find a package in > the ports tree. For example: > > If I go to /usr/ports and do make search key=wget I can find > the following. > > Port: wget-1.16.3p0 > Path: net/wget > Info: retrieve files from the web via HTTP, HTTPS and FTP > Maint: The OpenBSD ports mailing-list <po...@openbsd.org> > Index: net lang/python > L-deps: STEM->=0.10.38:devel/gettext converters/libiconv devel/libidn > devel/pcre net/libpsl > B-deps: STEM->=0.10.38:devel/gettext archivers/xz devel/gettext-tools > R-deps: STEM->=0.10.38:devel/gettext > Archs: any > > Which tells me to go to /usr/ports/net/wget. Is there currently > a way to achieve this with any of the pkg_ tools? I don't know about pkg_info, but "cd ports/*/wget" usually gets the job done.
pkg_info
This doesn't seem possible, but maybe I'm missing something. I would like pkg_info to tell me where to find a package in the ports tree. For example: If I go to /usr/ports and do make search key=wget I can find the following. Port: wget-1.16.3p0 Path: net/wget Info: retrieve files from the web via HTTP, HTTPS and FTP Maint: The OpenBSD ports mailing-list <po...@openbsd.org> Index: net lang/python L-deps: STEM->=0.10.38:devel/gettext converters/libiconv devel/libidn devel/pcre net/libpsl B-deps: STEM->=0.10.38:devel/gettext archivers/xz devel/gettext-tools R-deps: STEM->=0.10.38:devel/gettext Archs: any Which tells me to go to /usr/ports/net/wget. Is there currently a way to achieve this with any of the pkg_ tools? Thanks, -- Edgar Pettijohn
Does pkg_info -E need full path?
This is OpenBSD 4.8-current (GENERIC.MP) #0: Wed Nov 24 15:23:13 CET 2010 r...@stary.fjfi.cvut.cz:/usr/src/sys/arch/i386/compile/GENERIC.MP When looking for a package that contains a given file, I am using the -E feature of pkg_info: $ pkg_info -E /usr/local/lib/libschroedinger-1.0.so.2.0 /usr/local/lib/libschroedinger-1.0.so.2.0: schroedinger-1.0.10 schroedinger-1.0.10 high-speed Dirac codec When used with just the basename (or, more generally, anything less than the full path), pkg_info does not find it: $ pkg_info -E libschroedinger-1.0.so.2.0 $ pkg_info -E lib/libschroedinger-1.0.so.2.0 Is this the intended behaviour? Jan
Re: Does pkg_info -E need full path?
On Mon, Feb 14, 2011 at 01:13:34PM +0100, Jan Stary wrote: Is this the intended behaviour? Yeah. it's meant to find where a file you know lives. You want pkglocatedb.
Re: Package related questions: pkg_info, pkg_add, etc.
On Fri, Jan 22, 2010 at 06:42:45AM +0100, Song Li wrote: Thank you Bret. I can see that now after Aaron's comments and yours. cheers, This is actually documented. You can tell by telling me where you looked, and where I should put the info to be sure newbies see it. From packages(7), third paragraph: Even though the names are similar, note that the basic OpenBSD distribu- tion (baseXX.tgz, compXX.tgz ...) is not composed of such packages, but of plain tarballs.
Package related questions: pkg_info, pkg_add, etc.
Hi: I am really a newbie on OpenBSD. So my question might look stupid to you. I am using the current release 4.6 installed from the file install46.iso on ftp://openbsd.ftp.fu-berlin.de/pub/OpenBSD/4.6/i386/ Have anyone encountered any problem using pkg_info, pkg_add, etc.? They do not seem working to me. Take a simplest example, when I checked pkg_info, the man page says: ... -A Show information for all currently installed packages, including internal packages ... but when I typed pkg_info -A, it does not return anything. Just silently back to the commond line prompt. Similarly, -a does not work either. I also tryed pkg_info man46.tgz, pkg_info -L man46.tgz and none of them gave me any response. (with man46.tgz in the current directory) For pkg_add, I tried the following command: pkg_add man46.tgz (again, man46.tgz is in the current directory) and it responded: Can't resolve man46.tgz and pkg_add man46(with export PKG_PATH=/mnt/cdrom/4.6/i386) and it responded: Can't find CONTENTS from file:/mnt/cdrom/4.6/i386/man46.tgz /usr/sbin/pkg_add: man46: Fatal error and another try: pkg_add ./man46 gives similar response: Can't find CONTENTS from file:./man46.tgz /usr/sbin/pkg_add: man46: Fatal error It seems like man46.tgz has a wrong format (with missing CONTENTS?) but all the other .tgz files on the CD (from install46.iso) have the same problem. In addition, it seems that pkg_add ./man46 is more like the correct command than pkg_add man46.tgz. However, man packages says: ... Adding a new package is as simple as pkg_add foo-1.0-vanilla.tgz So I am quite confused (regarding the suffix .tgz, keep it or not?). How should we really use the command pkg_info and pkg_add? Are the manuals up-to-date? These problems are not critical problems since we can probably just go through the scripts of these commands and see what's inside and maybe there is just a easy way to fix it. My question is, however, 1) Did I get the corrent release file? The sha sum of my iso matches the key listed on their web (d53855c34bfa2d7b46f643ca4de8cc55debd8524) but I have not checked other sites yet. 2) The usage of pkg_add and pkg_info seems to be different from the FreeBSD version. And OpenBSD seems also using its own set of basic commands like cp instead of GNU set. So I wonder maybe I missed something basic for OpenBSD users? 3) are such problems common to OpenBSD users and how people usually solve such problems? Built-in manual (seems not very reliable to me) or search the web? It seems a little annoying to get stucked with such basic things. Any comments on the specific package problems or the above general questions on OpenBSD are much appreciated. Thanks. Best, Song ps. even though I do not think it's relevant to dmesg output, I think it does not hurt so I still paste it here: = dmesg OpenBSD 4.6 (GENERIC.MP) #89: Thu Jul 9 21:32:39 MDT 2009 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR real mem = 3756036096 (3582MB) avail mem = 3647295488 (3478MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/19/08, BIOS32 rev. 0 @ 0xffa10, SMBIOS rev. 2.4 @ 0xf71e0 (45 entries) bios0: vendor Dell Inc. version A12 date 11/19/2008 bios0: Dell Inc. XPS M1530 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP HPET APIC MCFG SLIC OSFR BOOT SSDT acpi0: wakeup devices PCI0(S5) PCIE(S4) USB1(S0) USB2(S0) USB3(S0) USB4(S0) USB5(S0) EHC2(S0) EHCI(S0) AZAL(S3) RP01(S5) RP02(S3) RP03(S3) RP04(S3) RP05(S3) RP06(S3) LID_(S3) PBTN(S4) MBTN(S5) 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: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiprt0 at acpi0: bus 3 (PCIE) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 9 (RP01) acpiprt3 at acpi0: bus 11 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus 12 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature 126 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpiac0 at acpi0: AC unit online
Re: Package related questions: pkg_info, pkg_add, etc.
On Fri, Jan 22, 2010 at 05:27:39AM +0100, Song Li wrote: Hi: I am really a newbie on OpenBSD. So my question might look stupid to you. I am using the current release 4.6 installed from the file install46.iso on ftp://openbsd.ftp.fu-berlin.de/pub/OpenBSD/4.6/i386/ Have anyone encountered any problem using pkg_info, pkg_add, etc.? They do not seem working to me. Take a simplest example, when I checked pkg_info, the man page says: ... -A Show information for all currently installed packages, including internal packages ... but when I typed pkg_info -A, it does not return anything. Just silently back to the commond line prompt. Similarly, -a does not work either. I also tryed pkg_info man46.tgz, pkg_info -L man46.tgz and none of them gave me any response. (with man46.tgz in the current directory) Base tarballs are not managed with the pkg_* tools. I can see why you made that assumption, but your assumption is incorrect; pkg_* only deals with precompiled 3rd-party software.
Re: Package related questions: pkg_info, pkg_add, etc.
Thank you Bret. I can see that now after Aaron's comments and yours. cheers, Song On Fri, Jan 22, 2010 at 6:34 AM, Bret S. Lambert bret.lamb...@gmail.com wrote: On Fri, Jan 22, 2010 at 05:27:39AM +0100, Song Li wrote: Hi: I am really a newbie on OpenBSD. So my question might look stupid to you. I am using the current release 4.6 installed from the file install46.iso on ftp://openbsd.ftp.fu-berlin.de/pub/OpenBSD/4.6/i386/ Have anyone encountered any problem using pkg_info, pkg_add, etc.? They do not seem working to me. Take a simplest example, when I checked pkg_info, the man page says: ... -A Show information for all currently installed packages, including internal packages ... but when I typed pkg_info -A, it does not return anything. Just silently back to the commond line prompt. Similarly, -a does not work either. I also tryed pkg_info man46.tgz, pkg_info -L man46.tgz and none of them gave me any response. (with man46.tgz in the current directory) Base tarballs are not managed with the pkg_* tools. I can see why you made that assumption, but your assumption is incorrect; pkg_* only deals with precompiled 3rd-party software.
Re: Weird pkg_info behavior?
On 2008/10/5, Philip Guenther [EMAIL PROTECTED] wrote: [In the context of pkg_info only downloading the first part of a package to get the info] On Sat, Oct 4, 2008 at 5:09 AM, Slim Joe [EMAIL PROTECTED] wrote: Also I think it would be nice if the packages are dumped not into the present directory but in the $PKG_CACHE that I have set. pkg_add does that (assuming you actually export PKG_CACHE), but I don't see why pkg_info would, given that it expects to only download the start of the package file and not the entire thing. Leaving partial package files in your cache would be confusing, IMO. (Or did I misunderstand your suggestion?) Does the pkg install mechanism allow for resumable downloads? Up to now I've managed to finish all my installs in one run. But I assume resuming is possible, since pkg_add uses plain ftp to download the package tgz. It would then save bandwidth if pkg_add resumes from the partial download already made by pkg_info.
Re: Weird pkg_info behavior?
On 2008/10/4, Marc Espie [EMAIL PROTECTED] wrote: pkg_info will only download the beginning of the package, since it only needs the packing information, and we're very careful to store it at the beginning. Now, a lot of FTP servers tend to not like abort in the middle of transfer, especially when coupled with idiot firewalls. http transfers should be slightly better. I'm not sure but the partial transfer appears to work with single (versioned) files. I think I'm using (I'm not at the machine atm) PKG_PATH=ftp://ftp.eu.openbsd.org/pub/OpenBSD/. Also I think it would be nice if the packages are dumped not into the present directory but in the $PKG_CACHE that I have set. This makes it convenient to export PKG_PATH=$PKG_CACHE:etc Strangely enough, pkg transfers over scp is the fastest, due to using a specialized protocol that avoids this set-up/tear-down altogether. So what you see is very much set-up/tear-down of connections, pkg_info actually uses very little bandwidth, but it has a high latency. I'm not familiar with scp (never used it). Where's the list of scp mirrors?
Re: Weird pkg_info behavior?
[In the context of pkg_info only downloading the first part of a package to get the info] On Sat, Oct 4, 2008 at 5:09 AM, Slim Joe [EMAIL PROTECTED] wrote: ... Also I think it would be nice if the packages are dumped not into the present directory but in the $PKG_CACHE that I have set. pkg_add does that (assuming you actually export PKG_CACHE), but I don't see why pkg_info would, given that it expects to only download the start of the package file and not the entire thing. Leaving partial package files in your cache would be confusing, IMO. (Or did I misunderstand your suggestion?) Philip Guenther
Re: Weird pkg_info behavior?
On Tue, Sep 30, 2008 at 10:47:56PM -0400, Nick Guenther wrote: On Tue, Sep 30, 2008 at 8:14 PM, James Hartley [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:16 AM, Slim Joe [EMAIL PROTECTED] wrote: Is there a way to get package info for a file not already downloaded or installed without such heavy bandwidth (just the package info). Look at the -Q option on the pkg_info(1) manpage. I think he's asking for how to read package descriptions without downloading everything. But pkg_info has to download the entirety of each package first because a package is a compressed archive file. Nope, that's incorrect. pkg_info will only download the beginning of the package, since it only needs the packing information, and we're very careful to store it at the beginning. Now, a lot of FTP servers tend to not like abort in the middle of transfer, especially when coupled with idiot firewalls. http transfers should be slightly better. Strangely enough, pkg transfers over scp is the fastest, due to using a specialized protocol that avoids this set-up/tear-down altogether. So what you see is very much set-up/tear-down of connections, pkg_info actually uses very little bandwidth, but it has a high latency.
Re: Weird pkg_info behavior?
On Thu, Oct 2, 2008 at 3:20 AM, Slim Joe [EMAIL PROTECTED] wrote: On 2008/10/1, Stuart Henderson [EMAIL PROTECTED] wrote: On 2008-10-01, Nick Guenther [EMAIL PROTECTED] wrote: If you are looking for package descriptions, install the ports tree and read the Makefiles. A lynx dump of http://www.openbsd.org/4.3_packages/i386.html seems more handy. For 4.4/-current, landry@ has written a curses-based package browser, pkg_mgr. It's in the ports tree and of course a package is available, pkg_add pkg_mgr. That's something to wait for then. From what I read it references openports.se. It has nothing to do with openports.se, it uses databases/sqlports as its backend. Landry
Re: Weird pkg_info behavior?
On 2008-10-01, Nick Guenther [EMAIL PROTECTED] wrote: If you are looking for package descriptions, install the ports tree and read the Makefiles. For 4.4/-current, landry@ has written a curses-based package browser, pkg_mgr. It's in the ports tree and of course a package is available, pkg_add pkg_mgr.
Re: Weird pkg_info behavior?
On 2008/10/1, Stuart Henderson [EMAIL PROTECTED] wrote: On 2008-10-01, Nick Guenther [EMAIL PROTECTED] wrote: If you are looking for package descriptions, install the ports tree and read the Makefiles. A lynx dump of http://www.openbsd.org/4.3_packages/i386.html seems more handy. For 4.4/-current, landry@ has written a curses-based package browser, pkg_mgr. It's in the ports tree and of course a package is available, pkg_add pkg_mgr. That's something to wait for then. From what I read it references openports.se.
Weird pkg_info behavior?
When I invoke something like pkg_info vim*, pkg_info insists on downloading all the packages named vim*. That is, I see a bunch of vim* packages on . (present directory). Is there a way to get package info for a file not already downloaded or installed without such heavy bandwidth (just the package info). Note that my $PKG_PATH is set to ftp://[mirror site].
Re: Weird pkg_info behavior?
On Tue, Sep 30, 2008 at 11:16 AM, Slim Joe [EMAIL PROTECTED] wrote: When I invoke something like pkg_info vim*, pkg_info insists on downloading all the packages named vim*. That is, I see a bunch of vim* packages on . (present directory). Is there a way to get package info for a file not already downloaded or installed without such heavy bandwidth (just the package info). Note that my $PKG_PATH is set to ftp://[mirror site]. There's probably a better way but since nobody has responded maybe try ftp $PKG_PATH ftp ls vim* -r--r--r--1 00 6253054 Mar 14 2008 vim-7.1.244p0-gtk2.tgz -r--r--r--1 00 6168107 Mar 11 2008 vim-7.1.244p0-no_x11.tgz -r--r--r--1 00 1216459 Mar 14 2008 vim-lang-7.1.244-gtk2.tgz ftp get vim-7.1.244p0-no_x11.tgz | pkg_info - -B
Re: Weird pkg_info behavior?
On Tue, Sep 30, 2008 at 11:16 AM, Slim Joe [EMAIL PROTECTED] wrote: Is there a way to get package info for a file not already downloaded or installed without such heavy bandwidth (just the package info). Look at the -Q option on the pkg_info(1) manpage.
Re: Weird pkg_info behavior?
On Tue, Sep 30, 2008 at 8:14 PM, James Hartley [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:16 AM, Slim Joe [EMAIL PROTECTED] wrote: Is there a way to get package info for a file not already downloaded or installed without such heavy bandwidth (just the package info). Look at the -Q option on the pkg_info(1) manpage. I think he's asking for how to read package descriptions without downloading everything. But pkg_info has to download the entirety of each package first because a package is a compressed archive file. If you are looking for package descriptions, install the ports tree and read the Makefiles. Also, if you are lazy/not on an OpenBSD box, most of the descriptions are available at http://www.openbsd.org/4.3_packages/. -Nick
Re: Weird pkg_info behavior?
On Tue, Sep 30, 2008 at 10:47:56PM -0400, Nick Guenther wrote: If you are looking for package descriptions, install the ports tree and read the Makefiles. Also, if you are lazy/not on an OpenBSD box, most of the descriptions are available at http://www.openbsd.org/4.3_packages/. or even http://openports.se/search.php?so=vim l8rZ, -- andrew - ICQ# 253198 - Jabber: [EMAIL PROTECTED] BOFH excuse of the day: internet is needed to catch the etherbunny
