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 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 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...
OpenBSD NFC support
I've been thinking about getting a laptop with a Near Field Communication module, but I'm worried if it'll work on OpenBSD. A search through the mailing list archives, man pages and packages revealed only the the qtconnectivity package, whose description holds the following paragraph: Qt NFC enables connectivity between NFC enabled devices. Be warned that Qt NFC on OpenBSD may need some additional components. Which seems to suggest that it's possible, but doesn't mention what those "additional components" might be. Does anyone have any firm knowledge?
Re: OpenBSD NFC support
Thanks Stefan, Paul. NFC is at the moment a mostly idle fancy for me, so I'm unfortunately not prepared to commit to developing it yet.
Re: New default setup for touchpads in X
Ulf Brosziewski kirjoitti 12/06/17 klo 00:59:
> please consider giving ws a try, and help
> us by reporting problems if it doesn't work for you.
ws(4) seems to have much higher limiting friction for me when two-finger
scrolling. In synaptics(4), it was enough to just tilt my fingers to
get the page moving, whereas ws(4) requires me to perceptibly move them.
When tilting just a single finger on the touchpad, the limiting
friction feels the same - but ws(4) moves the pointer much fewer pixels.
From your reply to Christoph ("I hope you can observer a higher
precision when navigating at low speeds"), I gather this is intentional?
I guess I've just gotten too used to the synaptics scaling, the ws
behavior feels too sluggish to me.
My machine is a Thinkpad E530. Here's how the touchpad appears in dmesg:
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
wsmouse1 at pms0 mux 0
pms0: Synaptics clickpad, firmware 8.1, 0x1e2b1 0x940300
Re: Kindly support this initiative for a public git repository of OpenBSD source code located at Germany!
On 01/02/18 14:03, Stuart Henderson wrote: > Hosting a large git repository is not trivial, it uses far more server > resources (memory and cpu time) than an anoncvs/cvsync/rsync mirror, and > OpenBSD src/ (or even just ports/) is *huge* for a git repo. It works > better on Linux where things are more separated. Even *just the kernel* > is split across multiple repos. The Linux kernel repo is multiple times the size of OpenBSD-src [1], so I don't see how things being more separated helps them re: hosting. Perhaps kernel.org just has more hardware to throw at the problem? And in case anyone else was confused, the Linux kernel itself isn't split across multiple repos: you can build a fully functional one from a single checkout. It is the kernel *development* that is split across multiple repos, with occasional merges to mainline. [1]: Naive estimate based on comparing object counts when cloning from GitHub: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ - 5,779,337 objects, https://github.com/openbsd/src - 1,741,047 objects. > Anyway, has anyone fetched your openbsd-src0-test repo from github while > crossing crypto export boundaries? That has the exact same issue, > except that now as it's your repo, it may well be considered that it's > *you* that is responsible for exporting it. Surely the responsibility for exporting lies with the one doing the checkout? Otherwise I don't see how operators of OpenBSD CVS mirrors in the US aren't in the same position. Or is there some technical distinction between "mirroring" and "checking out" a repository? (I ask because the warning against fetching sources from USA when located outside North America only appears on https://www.openbsd.org/cvsync.html, not https://www.openbsd.org/anoncvs.html or https://www.openbsd.org/ftp.html.)
Re: Kindly support this initiative for a public git repository of OpenBSD source code located at Germany!
On 01/06/18 18:23, Lari Rasku wrote: > The Linux kernel repo is multiple times the size of OpenBSD-src [1], > [1]: Naive estimate based on comparing object counts when cloning from > GitHub: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ - > 5,779,337 objects, > https://github.com/openbsd/src - 1,741,047 objects. I need to correct myself here. The naive estimate is misleading: I took some time today to clone both repositories in full and found that a full checkout of openbsd/src weights in at 953 MiB, and linux.git at 1.1 GiB (obtained by running du -sh on the .git directory). So the difference isn't as overwhelming as just counting objects would suggest. (Surprising to see that the average OpenBSD Git object is almost thrice the size of a Linux one, though.)
Re: Git(Hub) and CVS
I'm guessing the cvs2git version changed in the upgrade and the new version generates different commit hashes from the old one. You can verify this by comparing how a known commit shows up on the GitHub UI vs. a git log of a recent cvs2git conversion: if the "commit XXX" strings differ, that's our culprit. If you don't care about preserving the hashes of the old commits on GitHub, then what you probably want is `git push --mirror origin`. It does exactly what it sounds like, mirroring the current state of the entire repo to the remote. (Doing this means that people won't be able to git pull without --rebase on checkouts of your repository made prior to the cvs2git upgrade, and if there are any antediluvian forks of it on GitHub the UI may get confused trying to figure out their relation.) If you DO care about preserving the commits with the old hashes on GitHub then I don't know how to do better than Anton's suggestion, though I think you'll still encounter problems with tags... you'd have to take the --tags off your push command and come up with some system for pushing new tags individually.
Re: identifying software and licenses used in base install
On 01/19/18 01:12, Theo de Raadt wrote: >> FWIW, the permission I seek is from my Legal department. > > That maybe your job but it isn't the project's job. > Enough is enough. That sentence above makes it clear who is getting > paid for satisfying those requirements: You. Huh, where did he imply otherwise? I don't think I saw Kent make a single claim about what the project _ought_ to do, or have done.
