Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 01 Nov 2014 15:21:48 +0100 Dag-Erling Sm〓rgrav wrote: > Tomoaki AOKI writes: > > Dag-Erling Sm〓rgrav writes: > > > Manfred Antar 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. Looks fixed now, but what confused me is that r273919 modifies etc/rc.d/geli. I've not configured GELI neither in head VM nor stable/10 host. And what MORE confused me are that... *In first reboot (after installworld and mergemaster) at r273922, mfsvar problem appeared. (/var/db/ports looked empty.) At the moment, r273619:OK -> r273876:NG -> r273902:NG -> r273922:NG. *Manfred's workaround helped in following reboot [no other change]. (And sent my previous mail.) *Noticed that r273919 should fix above by your reply, backed out Manfred's workaround [no other change] and rebooted, can't reproduce the mfsvar problem anymore! (With some rebooting test, and updating to r273958.) > > 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). Confirmed r273957 and r273958 fixes this. Thanks! > > 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 AOKIjunch...@dec.sakura.ne.jp ___ 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 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
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"
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: 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"
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 writes: > > Dag-Erling Smørgrav 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: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Ian Lepore writes: > Dag-Erling Smørgrav 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, 2014-11-01 at 15:59 +0100, Dag-Erling Smørgrav wrote: > Ian Lepore writes: > > Dag-Erling Smørgrav 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 writes: > Dag-Erling Smørgrav 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:21 +0100, Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > Dag-Erling Smørgrav writes: > > > Manfred Antar 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!
Tomoaki AOKI writes: > Dag-Erling Smørgrav writes: > > Manfred Antar 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: 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: 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"