> Cheerleading does not solve engineering problems, it's just noise.
>
> I'll post this again to keep the focus on the issue at hand.
>
> If The Graphics team has already done these tests, show us.
> If The Graphics team has not, then maybe they should take some time to do
> the work required get
> Den 19. apr. 2016 kl. 03.24 skrev Lyndon Nerenberg :
>
> There aren't enough seconds in the universe to test all the viable
> combinations for one single release.
We don't even do that with the WITH_FOO/WITHOUT_FOO options now, so why should
that be a criteria? You can use any combination of
> Den 20/11/2014 kl. 18.07 skrev Chris H :
>
> Greetings,
> While I recognize that send-pr has pretty much
> become useless, with the advent of bugzilla, being made
> the new "official" FreeBSD bug reporting system. I really
> miss send-pr, and was hoping I could revive it, eg;
> integrate it with
Den 10/11/2013 kl. 09.45 skrev Julian Elischer :
>
> it would be interesting to know what you did. and what conclusions you came
> to..
I created a system with a build server, a set of slaves, and a website to
collect and publish the benchmark data in graphs and raw data and highlight
signific
Hi Julian,
Den 08/11/2013 kl. 03.02 skrev Julian Elischer :
> Some time ago someone showed some freebsd performance graphs graphed against
> time.
> He had them up on a website that was updated each day or so.
>
> I think they were network perf tests but I'm not sure.
> He indicated that he was
Hi Julian,
Den 08/11/2013 kl. 03.02 skrev Julian Elischer :
> Some time ago someone showed some freebsd performance graphs graphed against
> time.
> He had them up on a website that was updated each day or so.
>
> I think they were network perf tests but I'm not sure.
> He indicated that he was
Den 07/11/2013 kl. 13.11 skrev Kimmo Paasiala :
> Snippets installed by ports should be disabled by default and
> enabled only selectively by variables in rc.conf(5) or some other
> configuration file to mirror what periodic(8) is doing now. This is
> an absolute must because having them enabled
Hi Colin,
Den 27/10/2013 kl. 22.03 skrev Colin Percival :
> Hi all,
>
> Doing freebsd-update builds, I've now had two instances where /usr/bin/svnlite
> has built inexplicably differently -- changes scattered all over the binary.
Which kind of changes? Are you aware of the -D flag to ar(1) (wip
Den 25/08/2013 kl. 16.21 skrev Ian Lepore :
>> Please file clang bugs at http://llvm.org/bugs/
>
> And THIS is a major reason why FreeBSD needs a compiler in base instead
> of all tools being ports. The last thing we need is to start responding
> to every problem with "this is not my problem, g
Den 22/08/2013 kl. 18.23 skrev John-Mark Gurney :
>> I don't think we should support building different parts of the tree
>> with incompatible settings. E.g. compiling part of the tree using
>> WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to
>> work properly.
>
> Do we have
Den 11/02/2013 kl. 13.07 skrev Erich Dollansky :
> ok, I agree that developers could react faster some times. But, isn't
> it more important that the errors are caught at all?
Yes. As long as there is no alternative, the best motivation to fix a bug is
when you just spent 20 minutes recovering y
Erich,
Den 11/02/2013 kl. 00.38 skrev Erich Dollansky :
> On Sun, 10 Feb 2013 15:57:01 +0100
> Erik Cederstrand wrote:
>
>> And as long as there is no automatic can taster doing quality
>> assurance of the produced cans, then foul cans will go unnoticed
>> until a do
Den 10/02/2013 kl. 02.30 skrev Erich Dollansky :
> I am on dog food since last May/June. How should I phrase it? Every can
> tastes different. Most cans have a perfect taste but some cans are
> really off.
And as long as there is no automatic can taster doing quality assurance of the
produced ca
Den 06/01/2013 kl. 18.25 skrev "O. Hartmann" :
>> In contrast, LLVM changes the ABI (and API!) significantly between point
>> releases. We therefore don't want to encourage anything outside of the base
>> system to link against these libraries, because doing so would prevent us
>> from importi
Den 06/01/2013 kl. 13.55 skrev O. Hartmann :
> While FreeBSD's
> base system already has LLVM/CLANG, it is missing some important LLVM
> pieces, like llvm-config and others.
llvm-config is a build dependency that spits out some lib paths that you can
just hard-code for FreeBSD. So what in "other
Den 16/11/2012 kl. 11.18 skrev Andriy Gapon :
> This is starting to turn into a bikeshed, but anyway...
>
> on 16/11/2012 12:00 Daniel Braniss said the following:
>> the question as to what compiler was used to compile the kernel is a bit of
>> an
>> oxymoron, since the kernel is made up of many
Den 16/11/2012 kl. 08.34 skrev Andriy Gapon :
> on 16/11/2012 01:09 Dimitry Andric said the following:
>> And as I remarked in another reply, now that I have thought about it a
>> bit, I would much rather see this information moved to a sysctl or dmesg
>> line, than in uname. With the happy side
Den 02/11/2012 kl. 04.29 skrev Brooks Davis :
> On Monday, November 5th I plan to commit the following patch to make
> clang the default compiler on i386 and amd64. Many people have worked
> long and hard to make this a reality and we're finally close enough to
> throw the switch.
Congratulation
Den 12/09/2012 kl. 11.29 skrev Doug Barton :
> On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
>> So can we do a sweep on the ports tree and mark the 2232 ports with
>> USE_GCC=4.2 until they can actually build with clang?
>
> Unfortunately it isn't that simple. We al
Roman,
Den 11/09/2012 kl. 14.38 skrev Roman Divacky :
>
> Upstream developers almost never use gcc4.2.1 as we do. So right now the
> ports maintainer must check whats wrong in the case the (upgraded) port
> doesnt compile with our in-tree gcc.
>
>
> It can be trivial USE_GCC=4.something but the
Den 10/05/2012 kl. 12.03 skrev Dimitry Andric:
> On 2012-05-10 11:02, Kohji Okuno wrote:
>> I think that libc/locale/toupper.c is mistaken.
>> Could you check it?
>>
>> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
>> {
>>size_t lim;
>>FIX_LOCALE(l);
>> - _RuneRange *rr = &XLOCALE_CT
Den 10/05/2012 kl. 11.54 skrev Erik Cederstrand:
> Den 10/05/2012 kl. 11.02 skrev Kohji Okuno:
>
>> Hi,
>>
>> I think that libc/locale/toupper.c is mistaken.
>> Could you check it?
>>
>> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
>&
Den 10/05/2012 kl. 11.02 skrev Kohji Okuno:
> Hi,
>
> I think that libc/locale/toupper.c is mistaken.
> Could you check it?
>
> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
> {
>size_t lim;
>FIX_LOCALE(l);
> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
> + _Ru
Den 02/05/2012 kl. 13.56 skrev John Baldwin:
>>
>> Static version:
>> * 0.09 ms spent execve'ing /usr/bin/make
>> * The rest is mostly sysctl calls
>>
>> Dynamic version:
>> * 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1
>> * 0.18 ms spent loading libc.so.7 (incl. reading /etc/
Den 01/05/2012 kl. 15.55 skrev Gary Palmer:
>
> If you want a high-level view of what goes on run
>
> ldd `which ls`
>
> check that it has libraries to load and doesn't say "not a dynamic ELF
> executable", and then run:
>
> ktrace ls
> kdump | more
>
> All the system calls related to resolvi
Den 01/05/2012 kl. 07.52 skrev Tim Kientzle:
>
> On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote:
>>
>> Can anyone explain to me why the dynamically linked version is significantly
>> slower? What are the extra steps involved compared to a statically linked
>&g
Den 26/04/2012 kl. 22.30 skrev Chris Rees:
> On 26 April 2012 20:15, Matthew Seaman
> wrote:
>> On 26/04/2012 20:01, Chris Rees wrote:
>>> hydra# cd /usr/ports && time make MAKE=~crees/bin/make-static index
>>>
>>> Generating INDEX-9 - please wait.. Done.
>>> 729.770u 120.841s 7:45.10 182.8%
Den 26/04/2012 kl. 11.35 skrev Konstantin Belousov:
> I think it is time to stop building the toolchain static. I was told that
> original reasoning for static linking was the fear of loosing the ability
> to recompile if some problem appears with rtld and any required dynamic
> library. Apparentl
Hi,
I've created a patch that cleans up FreeBSD Makefiles that unconditionally set
the -g flag for GCC. The motivation for this is that it should be possible to
add or remove this flag globally via e.g. CFLAGS (it's part of my quest to
produce deterministic builds).
I'm not very familiar with
Den 15/12/2011 kl. 22.21 skrev Andrew Boyer:
> These two changes allow you to set PXE as the default MBR boot selection,
> which enables you to write a 'reboot to the network' script. We've found it
> to be very useful. What do people think?
I think this is very useful for e.g. re-installing
Hi Ruslan,
Den 09/12/2011 kl. 14.37 skrev Ruslan Ermilov:
> On Fri, Dec 09, 2011 at 12:16:39PM +0100, Erik Cederstrand wrote:
>> I've been working on a project to make it possible to produce deterministic
>> builds with FreeBSD. By this I mean building a FreeBSD distributi
Hi all,
I've been working on a project to make it possible to produce deterministic
builds with FreeBSD. By this I mean building a FreeBSD distribution twice from
the same code base and having all files in the two distributions match by md5
sum. Currently, this is not the case.
My main goal fo
Hello Pav,
Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik:
> Package cluster is quite clever, akshully, and since this is OT here,
> just terse comments
Sorry, replied to a bad message... redirecting to current@
>>> 1. adding SSD disks
>
> irrelevant because of bullet 2.
>
>>> 2. source and des
Den 06/01/2011 kl. 20.56 skrev Tijl Coosemans:
> On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote:
>> Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker:
>>> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote:
>>>> - get IPA to work with
Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker:
> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote:
>> On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote:
>>> These are all marked as __dead2, so the compiler should "know" that these do
>>> not return.
>
>> And clang did the
Den 05/01/2011 kl. 17.55 skrev Ulrich Spörlein:
> And clang did the right thing here in the past. Beware that it does no
> inter-procedural analysis yet, so it will usually miss that usage()
> calls exit unconditionally.
>
> *But*, it should grok that for err(3) and exit(3). Now there are some
>
Den 05/01/2011 kl. 14.14 skrev Ulrich Spörlein:
> Hello folks,
>
> Now that I'm fairly confident that the stability issues with your.org's
> VMs have been resolved, I'd like to point you to the new and improved,
> semi-weekly analyzer runs at
>
>http://scan.freebsd.your.org/freebsd-head/
Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand:
> Ignoring contrib code for the moment, I decided to look at usr.sbin.pw from
> 2011-01-05. There's one report
> (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath)
> which turns
Den 07/12/2010 kl. 10.20 skrev Garrett Cooper:
> On Dec 7, 2010, at 12:26 AM, Mehmet Erol Sanliturk
> wrote:
>
>> A Dmesg.TXT is attached having a lock order reversal .
>
>The mount LOR is well known.
I see that this is the standard response to lot's of LOR reports. It seems to
be one o
Den 23/10/2010 kl. 22.40 skrev Sean Bruno:
> Anyone have a src.conf + make.conf that I can steal to build a small
> installation of BSD? I've been trying to shrink the installation so I
> can cram an ISO of BSD across the network into a remote installation
> thing in an HP box.
Apart from the m
Den 10/06/2010 kl. 22.31 skrev Mike Jakubik:
> On 6/10/2010 2:47 PM, Andriy Gapon wrote:
>> on 10/06/2010 21:29 Eitan Adler said the following:
>>
>>> -1 unless mergemaster is replaced.
>> Have you tried etcupdate?
>> etcupdate and mergemaster have a similar function but do things in quite a
>
Den 03/06/2010 kl. 16.14 skrev Maxim Konovalov:
> On Thu, 3 Jun 2010, 15:15+0200, Erik Cederstrand wrote:
>
>> I just wrote a shell script to recurse into the subdirectories and
>> run make on the Makefiles found. Unfortunately, some of the
>> Makefiles start running
Den 04/06/2010 kl. 01.10 skrev David Rhodus:
> Doing a ./test.sh make crashes my -current machine pretty quickly.
> It stops inBuilding in /usr/src/tools/regression/bin/mv
Well there you go. The regression tests are already useful :-)
The Makefile in tools/regression/bin/mv just runs 'sh re
Den 03/06/2010 kl. 21.54 skrev Giorgos Keramidas:
> On Thu, 03 Jun 2010 14:50:13 +0200, Alexander Leidinger
> wrote:
>> Quoting Erik Cederstrand (from Thu, 3 Jun 2010
>> 12:02:51 +0200):
>>
>>> Hi,
>>>
>>> I'd like to run the regress
Den 03/06/2010 kl. 14.53 skrev Mehmet Erol Sanliturk:
>
> I do not know how to perform regression tests , but
> is it not possible to write a shell script to perform the above manual steps ?
I just wrote a shell script to recurse into the subdirectories and run make on
the Makefiles found. Unfo
Hi,
I'd like to run the regression tests in src/tools/regression on a regular
basis. What's the official way to do this? Is there some way I can run them all
in one go?
It seems it's necessary to enter every single subdirectory and execute any
Makefiles located there before running 'prove -r'.
Den 31/05/2010 kl. 21.50 skrev Erik Cederstrand:
> I do have a problem with buildworld on an unmodified ClangBSD src/ tree
> within a ClangBSD VM. Clang barfs on the mmintrin.h headers when building
> it's own Lexer because it picks up the gcc version of the headers instead o
Den 01/06/2010 kl. 12.19 skrev b. f.:
>
> Also, others have announced that they are running regression tests on
> systems built with clang. Would it be possible to set up some
> regularly scheduled tests to uncover possible problems, if this hasn't
> been done already?
As far as I know, regressi
Den 29/05/2010 kl. 15.02 skrev Roman Divacky:
> ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to
> import
> into HEAD in roughly a week. We would like the initial import to be as
> painless
> as possible and therefore we ask you to test ClangBSD to assure that the
> r
Den 12/05/2010 kl. 22.44 skrev Jeff Roberson:
>
> I think Peter Holm also saw this once while we were testing SUJ and
> reproduced ~30 second hangs with stock sources. At this point we need to
> brainstorm ideas for adding debugging instrumentation and come up with the
> quickest possible rep
Den 19/04/2010 kl. 17.03 skrev Attilio Rao:
> 2010/4/19 Erik Cederstrand :
>> Hi
>>
>> I'm testing ClangBSD in a VirtualBox client and ran into a panic on the
>> client, but I don't think it's clang-related. I haven't tried kernel
>> debug
Hi
I'm testing ClangBSD in a VirtualBox client and ran into a panic on the client,
but I don't think it's clang-related. I haven't tried kernel debugging before.
I tried getting a backtrace as described in
http://old.nabble.com/Re%3A-ia64--%3E-panic%3A-deadlkres%3A-possible-deadlock-detected-fo
Hi Roman
Den 16/04/2010 kl. 18.08 skrev Roman Divacky:
> We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel
> and
> use it as you would normally use FreeBSD. Please report back
I installed ClangBSD kernel and world in a VirtualBox virtual machine (amd64)
and rebooted
53 matches
Mail list logo
