Re: Need help debugging yacc test failure in CURRENT
On Thu, Oct 2, 2014 at 5:23 AM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, I have managed to eliminate all the test failures from /usr/tests in CURRENT except for one failure. See: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport/ I can reproduce the failure by doing the following: mkdir /tmp/x cd /tmp/x /usr/tests/usr.bin/yacc/yacc_tests usr.bin.yacc.yacc_tests.main I then get a core file: /tmp/x/test/yacc.core Can someone help debug and fix this? What you'd do until someone fixes the yacc bug is file a PR for this crash and then mark the test as expected failure (or TODO in TAP terms). ___ 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: make installworld for i386 fails on Kyuafile
On Mon, Sep 22, 2014 at 11:15 AM, Thomas Mueller mueller6...@bellsouth.net wrote: I was successful on make buildworld and kernel, but make installworld failed on a missing file somewhere: /usr/share/man/man3/pmclog_read.3.gz - /usr/share/man/man3/pmclog.3.gz === lib/libproc (install) install -C -o root -g wheel -m 444 libproc.a /usr/lib install -C -o root -g wheel -m 444 libproc_p.a /usr/lib install -s -o root -g wheel -m 444 libproc.so.2 /usr/lib install -l s libproc.so.2 /usr/lib/libproc.so install -C -o root -g wheel -m 444 /BETA1/usr/src/lib/libproc/libproc.h /usr/include === lib/libproc/tests (install) install -o root -g wheel -m 444 Kyuafile.auto /usr/tests/lib/libproc/Kyuafile install: /usr/tests/lib/libproc/Kyuafile: No such file or directory Fixed in r271950. Problem introduced in r271937 which seems to have missed part of the change sent out for review in D710. ___ 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: make -DNO_ROOT to create chroot, problem installing into chroot with pkg
On Mon, Sep 8, 2014 at 2:36 PM, Brooks Davis bro...@freebsd.org wrote: I believe the majority of packages don't suffer from post-install scripts hence the suggestion that extracting in the right place without root would solve 80-90% of the problem (and probably take no more than 10% of the work). I could live with the pain of not having scripts run during install. The correct long term fix as proposed by bapt is the do anyway with most scripts in favor of common actions and if any significant scripts remain add the ability to run them on first boot. Cool; glad to hear. This sounds like a good plan. ___ 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: make -DNO_ROOT to create chroot, problem installing into chroot with pkg
On Mon, Sep 8, 2014 at 11:48 AM, Brooks Davis bro...@freebsd.org wrote: If you don't mind the ownership being wrong and there being a few extra +FOO files tar works. It would be great for someone to teach package to install without root and to update a METALOG file. That's not 100% of the solution, but it's a solid 80-90% solution. (This is just my completely uninformed opinion as I don't know the internals of pkg.) There are other issues to be addressed. Teaching pkg to install without root means changing pkg to not use chroot: i.e. to make pkg be able to deal with the concept of a destdir for package installations. That is probably easy: just prefixing a bunch of destdir to the locations being touched. However, the tricky part here is dealing with any package-specific post-install scripts to ensure they understand destdir, which in turn means that any tools executed by the scripts must also be capable of dealing with a destdir. Also, the scripts (being potentially-untrusted code) cannot be guaranteed to behave correctly on the outside-of-the-chroot system. ___ 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: Turning TESTS on by default
On Tue, Jun 10, 2014 at 4:54 PM, Glen Barber g...@freebsd.org wrote: After reviewing Julio's proposed changes, I realize that there is a way to avoid populating /usr/tests when building the on-disc filesystem. I think this will also apply to the WITH_DEBUG_FILES=1 case mentioned. It seems I cannot apply an update to another differential review (or I am just doing it wrong), so have created a new differential here: https://phabric.freebsd.org/D202 Thanks for testing and for the feedback. All raised issues should now be resolved: - installworld now works again with read-only src and object trees. - The test suite is shipped as a separate tests.txz file that users can choose to not install. - Release media do not include the test suite in them. ___ 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: Turning TESTS on by default
On Fri, Jun 6, 2014 at 11:33 PM, Konstantin Belousov kostik...@gmail.com wrote: It is the same as the debugging kernel. The INVARIANTS, WITNESS, DEBUG and DIAGNOSTIC options are not enabled for the user consumption. No; this is not the same at all. All the options you mention introduce a performance penalty on the system at *run* time and the _only_ way to get rid of such penalty completely is to disable the options at *build* time (sysctl doesn't make the cut because the system would still need to check a boolean value). Because these toggles affect run-time performance, and because they are intended for developers only, they are not the default on release builds. Building the test suite has no impact whatsoever on the system at run-time. The test suite is just a bunch of files in a self-contained location. We ought to ship such files as tests.tgz to give users a very easy way of not installing them though. ___ 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: Turning TESTS on by default
On Sat, Jun 7, 2014 at 3:53 PM, Konstantin Belousov kostik...@gmail.com wrote: Could somebody point out a popular software system that spills the tests or other developer-only[*] stuff into the production install ? I immediately remember the perl and its modules which have very extensive test suite, but the test suite is not installed. [*] As is, developers of the system, not developers utilizing the product as the base. That's the key you are missing: the FreeBSD test suite, just as the NetBSD test suite, have been designed from the very beginning as a tool for *both* developers and end users. Most test suites out there, if not all, do not have such a goal and thus it is uninteresting, and likely harmful, to install them (if only because it is non-trivial to execute them in a controlled manner). The FreeBSD test suite is intended to let users (especially sysadmins) routinely assess the functionality of their system, especially right after deployment and during system upgrades. This approach is partly intended to cover the fact that the FreeBSD project cannot possibly have[*] a large-enough testing farm to validate most hardware/software combinations run by our users. It is also partly intended to inspire confidence in the system by our users by being very transparent about what works and what may possibly not work. NetBSD encourages you to do test runs (even from cron) in its afterboot(8) manual page. * Mind you: companies such as Microsoft have extremely large test environments and, yet, they continuously fail to catch specific failures in some weird system combination. It is just a fact of the complexity of OSes. The difference between them and us is that they cannot afford to ship their test suite because it's a very important asset of theirs and because of the potential PR implications of users uncovering failures here and there (my guesses though). I recommend reading The Old New Thing blog for insightful details on all the testing that Windows goes thorough, for example. ___ 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: Turning TESTS on by default
On Sun, Jun 8, 2014 at 1:50 PM, Warren Block wbl...@wonkity.com wrote: How much of an impact does the test suite have in terms of disk space (probably not much) It clocks at 11MB now on amd64. and buildworld time (possibly not much, either)? Haven't measured. Note, though, that the majority of the existing tests are shell-scripts so they do not take any build time. ___ 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
Turning TESTS on by default
Hello all, TL;DR - I plan to turn the TESTS src.conf knob ON by default on Tuesday once I have been able to perform enough sanity-checks of the build and all of them pass. The impact of this is that the FreeBSD Test Suite (see tests(7)) will be built and installed by default under /usr/tests/ along with the private atf libraries and binaries. There should be no other changes and this should be transparent to everyone. If this happens to break the world in any way, we can trivially roll the change back to fix the fallout. Some details TESTS was never intended to be disabled by default. However, the original patches that were committed months ago related to this feature broke the build and the easiest way out (instead of reverting the commits) was to set the knob to disabled. Unfortunately, it stayed that way even after the discovered problems were fixed. I am confident enough now that we have ironed out all major issues that this might introduce, so it is about time to enable TESTS by default again in HEAD. The benefits of this are that 1) we allow end users (especially consumers of binary releases!) to run the tests out of the box, as it has always been intended; and 2) we will be able to run the official release builds through testing via Jenkins, instead of having to issue custom builds. Actual change: https://phabric.freebsd.org/D188 I will update this thread when the change is committed and/or with any updates. Please let me know if I'm missing anything. Cheers ___ 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: Turning TESTS on by default
On Fri, Jun 6, 2014 at 3:50 PM, Jilles Tjoelker jil...@stack.nl wrote: This is certainly useful, but please fix installworld from a read-only (e.g. NFS) /usr/obj first. I reported this a while ago in http://lists.freebsd.org/pipermail/freebsd-testing/2014-May/000384.html build Kyuafile.auto during buildworld, not installworld. This message includes patches, although they are a bit ugly. OK; that's a blocker and had forgotten about it. Will fix. ___ 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: Import of DragonFly Mail Agent
On Mon, Feb 24, 2014 at 6:47 AM, Thomas Mueller mueller6...@bellsouth.netwrote: To Julio Merino: How long did NetBSD include both sendmail and postfix in base? What NetBSD releases? What was the first release that included both sendmail and postfix, and the first release where sendmail was dropped? As far as I can tell, postfix was added in NetBSD 1.5 (Dec 6, 2000), made the default in NetBSD 2.0 (Dec 9, 2004) and sendmail was removed in NetBSD 4.0 (Dec 19, 2007). That's a 7-year long transitional period. I haven't been able to find the discussion for the removal of sendmail unfortunately. ___ 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: Import of DragonFly Mail Agent
On Sun, Feb 23, 2014 at 4:11 PM, Baptiste Daroussin b...@freebsd.orgwrote: Hi, As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. DragonFly Mail Agent is a minimalistic mailer that is able to relay mails to some smtp servers (with TLS, authentication and so on) It supports MASQUERADE and NULLCLIENT, and is able to deliver mails locally (respecting aliases). I imported it because dma is lightweight, BSD license and easy to use. The code base is rather small and easy to capsicumize (which I plan to do) My initial goal is not to replace sendmail. But is it an eventual goal? *I* don't see why not, but if it is: what's the plan? How is the decision to drop sendmail going to be made when the time comes? (I.e. who _can_ and will make the call?) All I want is a small mailer simple to configure, and not listening to port 25, suitable for small environment (embedded and/or resource bounded) as well as for server deployment. Playing devil's advocate: what specific problems is this trying to solve? I'd argue, for example, that postfix can be also easily configured and can be made to not listen on port 25 for local mail delivery, while at the same time it is a fully-functional MTA that could replace sendmail altogether. (Which, by the way, is the configuration with which postfix ships within the NetBSD base system.) The reason I'm asking these questions is because I have seen NetBSD maintain two MTAs (sendmail + postfix) in the base system for _years_ and it was not a pretty situation. The eventual removal of sendmail was appreciated, but of course it came with the associated bikeshedding. ___ 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: RFC: less chatty system builds
On Mon, Dec 16, 2013 at 1:46 PM, Luigi Rizzo ri...@iet.unipi.it wrote: The following is a proof-of-concept patch to make system builds less chatty. It also has the nice side effect of showing more clearly which rules are used during the build and possibly help debugging the share/mk files and the individual Makefiles. I like the feature having used it in NetBSD routinely. Have you checked how NetBSD does this? It seems you are going for a yes/no approach while NetBSD supports various levels of verbosity. Trying to copy what's done there may be a good idea, if only at the interface level. Search for MAKEVERBOSE as a starting point here: http://cvsweb.netbsd.org/bsdweb.cgi/src/share/mk/bsd.own.mk?rev=1.759content-type=text/x-cvsweb-markuponly_with_tag=MAIN -- Julio Merino / @jmmv ___ 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
