Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built pkg_summary)
At Sat, 20 Apr 2019 13:20:03 +0100, Chavdar Ivanov wrote: Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built pkg_summary) > > I have always used > > cd /usr/pkgsrc/packages/All ; ( for i in *.tgz; pkg_info -X $i ) | > bzip2 > pkg_summary.bz2 Ah, that is interesting. I don't see how or why "pkg_info -X" should produce different results when looking at the .tgz vs. what is in /var/db/pkg. (without looking at the code, that is) I would call that a bug -- especially since it isn't documented as a feature! OK, I'll give that a try # pkgin upgrade calculating dependencies...done. 6 packages to refresh: perl-5.28.0nb2 yajl-2.1.0nb1 python27-2.7.15nb1 glib2-2.56.2nb3 m4-1.4.18nb1 autoconf-2.69nb8 4 packages to upgrade: py27-curses-2.7.15nb5 osabi-NetBSD-8.99.32 libarchive-3.3.3 automake-1.15.1nb1 6 to refresh, 4 to upgrade, 0 to install 0B to download, 85M to install proceed ? [Y/n] refreshing perl-5.28.0nb2... refreshing yajl-2.1.0nb1... refreshing python27-2.7.15nb1... refreshing glib2-2.56.2nb3... No schema files found: doing nothing. refreshing m4-1.4.18nb1... refreshing autoconf-2.69nb8... pkg_install warnings: 0, errors: 2 pkg_install error log can be found in /var/db/pkgin/pkg_install-err.log upgrading py27-curses-2.7.15nb5... upgrading osabi-NetBSD-8.99.32... upgrading libarchive-3.3.3... upgrading automake-1.15.1nb1... pkg_install warnings: 0, errors: 0 reading local summary... processing local summary... Well I'll be... It worked! Thanks! OK, that's definitely a bug in 'pkg_info -X', IMNSHO. Now I'll have to sort the chunks in each differently produced pkg_summary file to try doing a diff between them > This gives me the older versions of packages as well, should I need > them (and I do - e.g. qemu-3.1.0nb4.tgz was produced from > wip/qemu-nvmm, whereas qemu-3.1.0nb5.tgz from emulators/qemu, a rather > different one, ten times the size). However that is an important distinction to be sure! I don't expect I would need the older packages quite so often, given I static-link as many packages as possible (and I've tweaked pkgsrc where necessary to not record the library-only, i.e. now build-only, dependencies as runtime dependencies), though I've been unable to eliminate quite as much interdependency as I would have hoped. On the other hand part of the remaining problem is in how dependencies are specified for packages providing shared libraries and other less explicit A"B"Is. (The "B" in quotes because I'm referring more to the more dynamic interfaces outside of binary executables, such as file formats, command-line options, etc.) -- Greg A. Woods +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgp3CppfPVrSo.pgp Description: OpenPGP Digital Signature
Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built pkg_summary)
On Sat, 20 Apr 2019 at 07:16, Greg A. Woods wrote: > > [[ I tried sending this to gnats-admin, but it hasn't appeared yet, and > in any case folks here might have answers or suggestions too. ]] > > At Wed, 17 Apr 2019 23:32:40 +0100, Jonathan Perkin > wrote: > Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built > pkg_summary) > > > > While pkgin shouldn't crash and should be able to handle bad input, it > > should be pointed out that this use-case is not expected to work at all, > > and any fix will simply enforce that. Your pkg_summary files should be > > generated from binary package files, not installed packages. > > Hmmm... OK, so how should I generate the pkg_summary file for my limited > archive of locally built binary packages? > > I couldn't find much info anywhere about handling the server-side of > things for pkgin, so I RTFM'ed and just did what it says in > pkg_summary(5): > > The pkg_summary file can be generated using the pkg_info(1) －X option. > For example, the following will list this data for all installed pack‐ > ages: > >pkg_info ‐X ‐a I have always used cd /usr/pkgsrc/packages/All ; ( for i in *.tgz; pkg_info -X $i ) | bzip2 > pkg_summary.bz2 This gives me the older versions of packages as well, should I need them (and I do - e.g. qemu-3.1.0nb4.tgz was produced from wip/qemu-nvmm, whereas qemu-3.1.0nb5.tgz from emulators/qemu, a rather different one, ten times the size). I still get errors using this repo on occasion, usually some dependencies not caught for upgrade, so I have to examine the log file and first go through their update - again with pkgin - repeating the initial installation at the end. It is not ideal, but usable. I normally setup the repo to be accessed via anonymous ftp, but also via nfs. > > And I hoped that a file of the same name was of the kind that pkgin > would be happy to use. > > Pkgin did seem to happily suck up the file, and "pkgin avail" gives me a > nice list corresponding to all the binary packages I should have > available. It's just the attempt to install one of them that failed. > > I.e. there are binaries for all the installed packages in PKG_PATH -- > that's the point, after all, as I am trying to use pkgin to install > those binaries on other local systems. (Indeed I now rely on the way > pkgsrc uses DESTDIR to create a binary package that's then installed as > the last step, even on the build machine.) > > (and yes, PKG_PATH is set when I run "pkg_info -X -a", if that matters) > > One caveat I have locally is that these binary packages may not all for > the same OS version and/or they may not all be in the same PKG_PATH > location, since it is -current, and I've built different packages at > different times while upgrading the OS from time to time (and though I > often use pgk_rolling-replace with its '-B' option on the build machine, > that doesn't seem to find absolutely everything that's not for the same > OS version and rebuild it). > > So, I'm not sure if I should be simply linking together all the > compatible OS version binary package directories, or not. With pkg_add > I can't put multiple repositories in PKG_PATH, and presumably not for > "pkg_info -X" either, though it is hinted that repositories.conf can > contain a list of locations, though it's not clear if there can only be > one per $arch and/or $osrelease, nor is it clear what happens if > different installed packages were built for different (but nominally > compatible) $osrelease values. (The issue for me is that I'll likely > never manage to build everything I want all together at once with the > exact same OS release -- and I don't want to care about this as long as > the installed binaries run, and after all that's part of the point of > using NetBSD is that the ABI is stable for the most part, and even if > I've built packages on an old release that needs a COMPAT option, I > might want to include them in the stable of binary packages that I make > available for pkgin. I only really want to use pkgin for its ease of > managing upgrades, since for the initial installs it is not much > different for me to just use pkg_add directly, provided I really can > start with an empty /var/db/pkgin database and have it rebuilt to > account for such manually installed packages.) > > -- > Greg A. Woods > > +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms --
Re: Alternative DVCS to git: hg?
On Fri, 19 Apr 2019 22:10:12 +, Sad Clouds wrote: ... > > - not really doing branches properly or usefully > What is your definition of a "useful" branch? A branch that the VCS actually knows as a separate concept, not this branches-are-paths 'potentially interesting idea', that turned out to be weird enough that nobody ever reiterated it. And that also turned merge tracking into a nightmare that literally took years to get, well, at least almost right. My guess it that exactly this model will cause subversion to *never* get merging fixed, the model is just too complicated to fully understand. And preferrably branches in a history(including branches)-of-trees way, not tree-of-histories. > > - not doing or tracking merges properly > OK some problems exist Which is a nice way of saying "it's broken for years, and we're not even trying to fix some cases". ... > > - not being distributed and usable offline > No big deal if you don't need distributed VCS Obviously you don't 'need' distribution. But it makes live easier, faster, and open to new ideas. E.g. we do a backup of our git worktrees by doing the equivalent of a git stash (putting all locally modified and untracked files into a commit) and pushing that into a backup repo (plus all the local branches). Thus having backups of what the developer reasonably needs, but not all the build artefacts, plus deduplication in the backup repo. > > - not having secure guarantees of commit contents > Meaning? Can you give some examples? This has been discussed in this thread at length. > > - being slow and a big resource pig (with a larger attack surface) > OK Git is somewhat more efficient, but I wouldn't describe Subversion > as extremely slow. svn update needs eight roundtrips (last time I checked). With half a second ping and a few externals that quickly takes half a minute. And I've seen cases where svn takes five minutes for a merge that git made in a few seconds. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built pkg_summary)
[[ I tried sending this to gnats-admin, but it hasn't appeared yet, and in any case folks here might have answers or suggestions too. ]] At Wed, 17 Apr 2019 23:32:40 +0100, Jonathan Perkin wrote: Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built pkg_summary) > > While pkgin shouldn't crash and should be able to handle bad input, it > should be pointed out that this use-case is not expected to work at all, > and any fix will simply enforce that. Your pkg_summary files should be > generated from binary package files, not installed packages. Hmmm... OK, so how should I generate the pkg_summary file for my limited archive of locally built binary packages? I couldn't find much info anywhere about handling the server-side of things for pkgin, so I RTFM'ed and just did what it says in pkg_summary(5): The pkg_summary file can be generated using the pkg_info(1) −X option. For example, the following will list this data for all installed pack‐ ages: pkg_info ‐X ‐a And I hoped that a file of the same name was of the kind that pkgin would be happy to use. Pkgin did seem to happily suck up the file, and "pkgin avail" gives me a nice list corresponding to all the binary packages I should have available. It's just the attempt to install one of them that failed. I.e. there are binaries for all the installed packages in PKG_PATH -- that's the point, after all, as I am trying to use pkgin to install those binaries on other local systems. (Indeed I now rely on the way pkgsrc uses DESTDIR to create a binary package that's then installed as the last step, even on the build machine.) (and yes, PKG_PATH is set when I run "pkg_info -X -a", if that matters) One caveat I have locally is that these binary packages may not all for the same OS version and/or they may not all be in the same PKG_PATH location, since it is -current, and I've built different packages at different times while upgrading the OS from time to time (and though I often use pgk_rolling-replace with its '-B' option on the build machine, that doesn't seem to find absolutely everything that's not for the same OS version and rebuild it). So, I'm not sure if I should be simply linking together all the compatible OS version binary package directories, or not. With pkg_add I can't put multiple repositories in PKG_PATH, and presumably not for "pkg_info -X" either, though it is hinted that repositories.conf can contain a list of locations, though it's not clear if there can only be one per $arch and/or $osrelease, nor is it clear what happens if different installed packages were built for different (but nominally compatible) $osrelease values. (The issue for me is that I'll likely never manage to build everything I want all together at once with the exact same OS release -- and I don't want to care about this as long as the installed binaries run, and after all that's part of the point of using NetBSD is that the ABI is stable for the most part, and even if I've built packages on an old release that needs a COMPAT option, I might want to include them in the stable of binary packages that I make available for pkgin. I only really want to use pkgin for its ease of managing upgrades, since for the initial installs it is not much different for me to just use pkg_add directly, provided I really can start with an empty /var/db/pkgin database and have it rebuilt to account for such manually installed packages.) -- Greg A. Woods +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpcc7ip_vR0U.pgp Description: OpenPGP Digital Signature
Re: Alternative DVCS to git: hg?
On Thu, 18 Apr 2019 19:38:06 -0700 "Greg A. Woods" wrote: > The whole range of other more direct problems with SVN is of course > the real issue with it: > > - not really doing branches properly or usefully What is your definition of a "useful" branch? > - not doing or tracking merges properly OK some problems exist > - not really tracking changes per project (but rather per dir) > - not being ACID in commit semantics > - not being distributed and usable offline No big deal if you don't need distributed VCS > - not having secure guarantees of commit contents Meaning? Can you give some examples? > - being slow and a big resource pig (with a larger attack surface) OK Git is somewhat more efficient, but I wouldn't describe Subversion as extremely slow.
