Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 01 Nov 2014 01:33:09 +0100 Dag-Erling Sm〓rgrav d...@des.no wrote: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. VirtualBox VM [head, r273922, amd64] on stable/10 host [r273847, amd64]. In my case, /var is NOT a mount point (root only partition, mounted rw), but empty mfsvar is forcibly used without Manfred's workaround in multi user mode. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Writing entropy file:random: unblocking device. takes a little longer I changed to entropy_save_sz=4096 in /etc/rc.conf, maybe thats why. That shouldn't make any difference. Our /dev/random never blocks once it's seeded, and reading 4096 bytes won't take noticeably longer than reading 2048 bytes. But it should already be unblocked by then - this is on shutdown, right? For me, it takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. DES -- Dag-Erling Sm〓rgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- 青木 知明 [Tomoaki AOKI] junch...@dec.sakura.ne.jp mxe02...@nifty.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: RE: reducing the size of the ports tree
Not initially welcoming this new effort... explanation and other PKG problems taking precedence... I've a few scripts which use the smaller files, and have used them extensively in pipes. Syntax within the Makefile would make those counterintuitive.I would wonder also if it would break port infrastructure like the Mk and Tools and make search and portsearch (etc -- ports )... essentially breaking more things than would be solved. Indeed, I've many ideas for MORE small files for people crafting shell scripts that would be of more use down the road, and incorporated someday into additional port tools, portmasters, portupgrades, etc... So as far as this particular suggestion, maybe if someone wants it bad enough one should build a prototype and test locally several years with many ports and upgrades to determine what it breaks... and how to write new tools. But I conjecture that effort would be better spent with PR backlogs, fixing pkg2ng (which fails here on one machine ) etc... and making pkg more robust... (complete recovery if the database is hosed, with a something local_sqlite_hosed_reuild_sh.sh etc etc And the documentation. Many many more examples of everyday usage over the course of a year and UPDATING scenarious would be appreciated... and also streamlining pkg so it works better on low power machines with many ports installed. Including less segfaults... As an aside, I am now on a machine which never had the problem before, after a failed pkg2ng conversion, A... pkg install -f nettle wants to install csound! what file is telling it that? The database ??? ... and seven others I had just deinstalled B... make install ( proceeds with Child process terminated abnomally... segmentation fault) before the install. Not known if anything was running beforehand. Not problems with the install. But it keeps occuring... What process? Something in the background wanting that nettle csound dependency? Pkg working before the make command? Part of the make command infrastructure now more buggy? Thankfully that machine is not the primary one here, and all the programs installed still work on it as far as I know. But its registration data is not exact and pkg-devel as installed on it could be debugged more... as well as pkg2ng retested to work on v9 more precisely... It failed three times to convert that machine. (not installed unless desinstalling direct from the port, so could not upgrade.. or pkg info the port) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg 1.4 freeze please test test test!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 29/10/2014 02:19, Baptiste Daroussin wrote: We are starting the release process of pkg 1.4, we want to have a better release process than with every single previous version of pkg. For that we will need you help! pkg-devel has been updated to the latest version of pkg as of alpha2. I have 1.4.0.p.a16 installed and have two problems now: (1) Latest 11:amd64 package repository doesn't have newest package (2) this package thinks, that 1.4.0.p.a16 is newer than 1.4.0.a4: lev@labrat:~% pkg version -vIL= ... pkg-devel-1.4.0.p.a16 succeeds index (index has 1.4.0.a4) ... lev@labrat:~% sudo pkg -4 upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (216 candidates): 37% pkg-devel~ports-mgmt/pkg-devel has no direct installation candidates, change it to pkg-devel~ports-mgmt/pkg-devel? [Y/n]: y Checking for upgrades (216 candidates): 100% Processing candidates (216 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. lev@labrat:~% - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJUVOQAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP1EUQALM9Hs2X1F3Zoa94RwpHK4XI 0H8/VWB/NA9J//UGqW1btikXpbSDRSA2DsjL3wzfk0Z0SNQrExrUlwthkv3n/llh OPTthShVOijOGTuvE+voBuc0aGNDOfAodNaJKHncF/qai/6P3WqqGnxsuEGegZm4 JD0bM0OQfnoQz/xECWFOwJA6EFPgneAzCthpNkCFUbe0d7/hk9uDD3I6rmJPzT4T pMRizelSZxNyMc0kVJZjfa/Zlj6h818R6puzbb3ErX0SyijyzyOKI1pAZ5mmSgl4 vPbMWELHQWVRRQS1KcvGfNJMgpYB0UG93flZ+E9M3h/ScBqdZc+2OqYUEd+ZiE/T kPJ0oQw9t283banasA0k8Ej59478ZN1CxnmO766x96lqCTlbqbl3KFwgpNORCvas /WBjV0T8ZgSf1gCh5WnFQDF0rmpfql4Ol0ynY4A8ToKtJsAUpQ+vwR8WieHRKWf9 28fqmq/+ZewX5mS/7/eZ/DZdlqgKSmWv7JbETVYR3IAkF1a3s38DrU1ZZ5TnUrPM xWqvFC8hfW7aiMtzQ8OWW8WIFMC02/0oyxEqnFsVh/+IIsvXtTQOmPFd+tNlU3Xq FjkqFJRmVBqLS2eXtNvF5WzOJrEJmAOkkYVzGAlpYQVAVie+UZHKu3D1A8B8+EPO 3PfdV96CUGhS56H9Z8R3 =v9Qt -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Dag-Erling Smørgrav d...@des.no writes: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. [...] If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. It helped that particular issue, more or less by accident. It was not in any way a correct fix or even a correct workaround. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Exactly right; the check for a writeable /var occurred before / was mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. For me, [unblocking /dev/random] takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 2014-11-01 at 15:21 +0100, Dag-Erling Smørgrav wrote: Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Dag-Erling Smørgrav d...@des.no writes: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. [...] If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. It helped that particular issue, more or less by accident. It was not in any way a correct fix or even a correct workaround. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Exactly right; the check for a writeable /var occurred before / was mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. For me, [unblocking /dev/random] takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). DES And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. VMs have the additional problem of divergence between clones: if you clone a VM, all clones will start out with the exact same state and won't diverge until they've all reseeded after gathering entropy independently of eachother. I don't really know how to solve this. One possibility, assuming you have guest additions installed and that they can tell you that you've been suspended, is to block on resume. It won't help VMs that were cloned while shut down, but they should diverge to some extent during boot. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 2014-11-01 at 15:59 +0100, Dag-Erling Smørgrav wrote: Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. And what about devices that are not connected to a network? We've been over this, I stressed again and again that we have an absolute requirement to start up reliably when there is NO ENTROPY. Saved entropy is great, if you've got some saved. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. -- Ian VMs have the additional problem of divergence between clones: if you clone a VM, all clones will start out with the exact same state and won't diverge until they've all reseeded after gathering entropy independently of eachother. I don't really know how to solve this. One possibility, assuming you have guest additions installed and that they can tell you that you've been suspended, is to block on resume. It won't help VMs that were cloned while shut down, but they should diverge to some extent during boot. DES ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. And what about devices that are not connected to a network? They still get entropy from interrupts and disk I/O. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. How about you take a ing chill pill and read what I wrote earlier: this is a regression which we will try to fix. But the bottom line is that the entropy has to come from *somewhere* and if whatever dinky device you're playing with doesn't provide any, that's not our fault. Buy http://www.amazon.com/dp/0833030477 and type it in, or something. We're engineers, not magicians. (or maybe you can do something constructive, like write code to harvest entropy from background noise in ADCs, unused WiFi / 4G / BT radios or whatever else is available and submit a patch) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 1 Nov 2014 18:03+0100, Dag-Erling Smørgrav wrote: Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. And what about devices that are not connected to a network? They still get entropy from interrupts and disk I/O. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. How about you take a ing chill pill and read what I wrote earlier: this is a regression which we will try to fix. But the bottom line is that the entropy has to come from *somewhere* and if whatever dinky device you're playing with doesn't provide any, that's not our fault. Buy http://www.amazon.com/dp/0833030477 and type it in, or something. We're engineers, not magicians. Sirs, please control your temper, at least while on a public mailing list. What good does the file /entropy do if boot up is delayed everytime during Writing entropy file:? (or maybe you can do something constructive, like write code to harvest entropy from background noise in ADCs, unused WiFi / 4G / BT radios or whatever else is available and submit a patch) -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg 1.4 freeze please test test test!
I upgraded one of my machines to have pkg-devel on it
(1.4.0.alpha4), and attempted to recreate my test repo with it.
Version : 1.4.0.alpha4
PKG_DBDIR = /tmp/pkg.tmp.67648;
PKG_CACHEDIR = /var/cache/pkg;
PORTSDIR = /usr/ports;
INDEXDIR = ;
INDEXFILE = INDEX-9;
HANDLE_RC_SCRIPTS = false;
ASSUME_ALWAYS_YES = true;
REPOS_DIR [
/usr/local/etc/pkg/repos,
]
PLIST_KEYWORDS_DIR = ;
SYSLOG = true;
ABI = FreeBSD:9:amd64;
ALTABI = freebsd:9:x86:64;
DEVELOPER_MODE = false;
VULNXML_SITE = http://vuxml.freebsd.org/freebsd/vuln.xml.bz2;;
FETCH_RETRY = 3;
PKG_PLUGINS_DIR = /usr/local/lib/pkg/;
PKG_ENABLE_PLUGINS = true;
PLUGINS [
]
DEBUG_SCRIPTS = false;
PLUGINS_CONF_DIR = /usr/local/etc/pkg/;
PERMISSIVE = false;
REPO_AUTOUPDATE = false;
NAMESERVER = ;
EVENT_PIPE = ;
FETCH_TIMEOUT = 30;
UNSET_TIMESTAMP = false;
SSH_RESTRICT_DIR = ;
PKG_ENV {
}
PKG_SSH_ARGS = ;
DEBUG_LEVEL = 0;
ALIAS {
}
CUDF_SOLVER = ;
SAT_SOLVER = ;
RUN_SCRIPTS = true;
CASE_SENSITIVE_MATCH = false;
LOCK_WAIT = 1;
LOCK_RETRIES = 5;
SQLITE_PROFILE = false;
WORKERS_COUNT = 0;
READ_LOCK = false;
PLIST_ACCEPT_DIRECTORIES = false;
IP_VERSION = 0;
AUTOMERGE = true;
Repositories:
X: {
url : pkg+http://X/FreeBSD:9:amd64/latest;,
enabled : yes,
mirror_type : SRV
}
Updating X repository catalogue...
Fetching meta.txz... done
Fetching packagesite.txz... done
Processing entries... done
X repository update completed. 506 packages processed
pkg: sqlite error while executing INSERT INTO pkg_search SELECT id, name
|| '-' || version, origin FROM packages;CREATE INDEX packages_origin ON
packages(origin COLLATE NOCASE);CREATE INDEX packages_name ON
packages(name COLLATE NOCASE);CREATE INDEX packages_uid_nocase ON
packages(name COLLATE NOCASE, origin COLLATE NOCASE);CREATE INDEX
packages_version_nocase ON packages(name COLLATE NOCASE, version);CREATE
INDEX packages_uid ON packages(name, origin);CREATE INDEX
packages_version ON packages(name, version);CREATE UNIQUE INDEX
packages_digest ON packages(manifestdigest); in file pkgdb.c:2246:
UNIQUE constraint failed: packages.manifestdigest
Creating repository in
/usr/obj/usr/src/release/packages/FreeBSD:9:amd64... done
Packing files for repository... done
Creating repository in
/usr/obj/usr/src/release/packages/FreeBSD:9:amd64... done
Packing files for repository... done
-Kurt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
version number error with ports
There seems to be a problem with certain ports detecting the OS version.
* This happens with emulators/i386-wine-devel; it's unable to detect the
version and exits.
* Poudriere shows below message:
make: /usr/ports/Mk/bsd.port.mk line 1216: warning: /usr/bin/awk
'/^#define[[:blank:]]__FreeBSD_version/ {print $3}'
/usr/include/sys/param.h exited on a
signal
make: /usr/ports/Mk/bsd.port.mk line 1228: UNAME_r (11.0-CURRENT) and
OSVERSION () do not agree on major version number.
uname FreeBSD 11.0-CURRENT #0 r272601M: Mon Oct 6 ... amd64
Will upgrade as soon as recent buildworld / clang error is fixed.
-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/version-number-error-with-ports-tp5961642.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On 01.11.2014 21:26, Trond Endrestøl wrote: What good does the file /entropy do if boot up is delayed everytime during Writing entropy file:? Probably some entropy is needed before saved file is loaded. As raw guessing of alternative solution it is possible to make some part of previously saved entropy as kld module always loaded with the kernel. -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg 1.4 freeze please test test test!
On Sat, Nov 01, 2014 at 04:13:32PM +0100, Marc UBM wrote: On Wed, 29 Oct 2014 00:19:33 +0100 Baptiste Daroussin b...@freebsd.org wrote: Hi all, We are starting the release process of pkg 1.4, we want to have a better release process than with every single previous version of pkg. For that we will need you help! pkg-devel has been updated to the latest version of pkg as of alpha2. Changes you can expect in pkg 1.4 are the following: - Loads of bug fixes - Stricter checking of the path passed via the plist - Removal of the bundled libyaml - new --raw-format to chose the output format for info -R and search -R - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64) the old ABI is available as a fallback in ALTABI - pkg check now support a quiet mode - new 3 way merge code (stolen from the fossil-scm) to allow automerging configuration files - new @config keyword to mark a file as a config file (during upgrade/reinstallation it will try to merge the configuration with the one the user may have modified) an option AUTOMERGE is available to prevent automerging if automerge fails a .pkgnew file will be created along with the untouched user version of the configuration - The update procedure has been improved and speed up a lot (in particular for machine with low resources) - The unique identifier has been modified to be pkgname meaning now ports can be moved in new categories without having to be considered a different package - Only libraries starting by lib* are added to the provided libraries - General speed up of all operations We need help in testing, but we also need help in writing regression tests ! The more we have tests the more stable the releases will be. The release will also allow to be able to package base! regards, Bapt The update is failing for me with: .../usr/ports/ports-mgmt/pkg-devel# make all install clean === Installing for pkg-1.4.0.a3 === Checking if pkg already installed pkg-static: sqlite error while executing DROP INDEX packages_unique;CREATE UNIQUE INDEX packages_unique ON packages(name); in file pkgdb.c:2246: UNIQUE constraint failed: packages.name *** Error code 74 Stop. make[1]: stopped in /usr/ports/ports-mgmt/pkg-devel *** Error code 1 Stop. make: stopped in /usr/ports/ports-mgmt/pkg-devel portmaster fails with: root@ubm:/usr/ports/ports-mgmt/pkg-devel# portmaster -d pkg === No ORIGIN in /var/db/pkg/pkgconf-0.9.7/+CONTENTS === Cannot continue === Aborting update === Killing background jobs Terminated === Exiting make.conf related options: #enable pkgng (might be superfluous) WITH_PKGNG=yes #enable PKGNG devel WITH_PKGNG=devel Am I doing something wrong? You are doing nothing wrong but that probably means you have ancient packages that never got upgraded (in the old time it was allowed to have 2 packages installed with the same name) we have fixed that over the time and that is why we had unicity set to origin as a hack for a while, we are now moving to unique name so you have to make sure that all your installed packages are up to date before moving to new pkg. At least make sure you do not have 2 packages with the same name. Concerning portmaster I have no idea why it now thinks you are not using pkg :( regards, Bapt pgpZl_FQZwuMj.pgp Description: PGP signature
