El día jueves, septiembre 21, 2023 a las 05:03:15p. m. +0300, Gleb Popov
escribió:
> On Thu, Sep 21, 2023 at 4:47 PM Matthias Apitz wrote:
> >
> > Should I file a new PR?
>
> You should check git log:
> https://cgit.freebsd.org/ports/commit/?id=190bd2d090115c5c38661198d16fd55288aeb9c1
> This co
On Thu, Sep 21, 2023 at 4:47 PM Matthias Apitz wrote:
>
> Should I file a new PR?
You should check git log:
https://cgit.freebsd.org/ports/commit/?id=190bd2d090115c5c38661198d16fd55288aeb9c1
This commit is just several commits later than the one you're building.
On a recent CURRENT (August 5) and ports from git September 13, the
above port fails in poudriere reproducible at the same place during compilation:
www/qt5-webengine for pkg qt5-webengine-5.15.8_6 failed after 02:46:52
with
lines 120952 ff from poudriere log file qt5-webengine-5.15.8_6.log
On 09/09/2021 00:04, Tomoaki AOKI wrote:
devel/ninja/Makefile has USES= python in it, so it maybe require python
to run or at least build.
You could probably remove that line without anyone noticing. Ninja uses
Python for precisely one thing (or, at least, did last time I looked):
There is
On Wed, Sep 8, 2021, 5:06 PM Tomoaki AOKI wrote:
> On Wed, 8 Sep 2021 14:32:16 -0600
> Warner Losh wrote:
>
> > On Wed, Sep 8, 2021, 6:33 AM David Chisnall
> wrote:
> >
> > > On 08/09/2021 11:52, Gary Jennejohn wrote:
> > > > Seems to me that there was an earlier mail about getting CMAKE to
> w
On Wed, 8 Sep 2021 14:32:16 -0600
Warner Losh wrote:
> On Wed, Sep 8, 2021, 6:33 AM David Chisnall wrote:
>
> > On 08/09/2021 11:52, Gary Jennejohn wrote:
> > > Seems to me that there was an earlier mail about getting CMAKE to work
> > > with FreeBSD builds. Could be worthwhile to look into ge
On Wed, Sep 8, 2021, 6:33 AM David Chisnall wrote:
> On 08/09/2021 11:52, Gary Jennejohn wrote:
> > Seems to me that there was an earlier mail about getting CMAKE to work
> > with FreeBSD builds. Could be worthwhile to look into getting ninja
> > to work also. But I could understand that there
ich is not too bad
> if you consider that the link phase needs to wait for all object files.
>
> I really do not see that there is much to gain, here ...
>
> > In particular, building FreeBSD on a 10-24 core machine has very long
> periods
> > where a number of the cores are
stem need to be rebuild.
(BTW: This is a system with SATA drives in a RAIDZ1 configuration,
which limits the I/O rate way below what an SSD based system might
get.)
> Ninja also has a few other nice features that improve performance relative to
> bmake:
>
> - It lets you put jobs in diff
>
> In particular, building FreeBSD on a 10-24 core machine has very long
> periods where a number of the cores are completely idle.
>
> Ninja also has a few other nice features that improve performance
> relative to bmake:
>
> - It lets you put jobs in different pools. In
On 08/09/2021 11:52, Gary Jennejohn wrote:
Seems to me that there was an earlier mail about getting CMAKE to work
with FreeBSD builds. Could be worthwhile to look into getting ninja
to work also. But I could understand that there might be push-back,
since the project prefers to use utilities fr
nless I've changed a header that everything
>
> In particular, building FreeBSD on a 10-24 core machine has very
> long periods where a number of the cores are completely idle.
>
> Ninja also has a few other nice features that improve performance
> relative to bmake:
>
&
g with LLD
uses multiple threads and a lot more memory than compilation, so a
10-core machine may want to do 12 compile jobs in parallel but only 2
link jobs. This makes it much easier to completely saturate the machine.
- Ninja provides each parallel build task with a separate pipe for
stdo
> From: David Chisnall
> Date: Tue, 7 Sep 2021 14:51:21 +0100
> On 06/09/2021 20:34, Wolfram Schneider wrote:
> > With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5
> > times faster (real or user+sys), down from 48 min to 19.5 min real
> > time.
>
> Note that building LLVM with th
Am 07.09.21 um 15:51 schrieb David Chisnall:
> On 06/09/2021 20:34, Wolfram Schneider wrote:
>> With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5
>> times faster (real or user+sys), down from 48 min to 19.5 min real
>> time.
>
> Note that building LLVM with the upstream CMake + Nin
On Tue, 7 Sep 2021, at 13:51, David Chisnall wrote:
> One of the things I'd love to prototype if I had time is a CMake-based
> build system for FreeBSD so that we could get all of the tooling
> integration from the compile_commands.json, reuse LLVM's (and any other
> contrib things that use CMak
On 06/09/2021 20:34, Wolfram Schneider wrote:
With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5
times faster (real or user+sys), down from 48 min to 19.5 min real
time.
Note that building LLVM with the upstream CMake + Ninja build system is
*significantly* faster on a decent mu
Van: David Chisnall
Datum: maandag, 6 september 2021 11:43
Aan: freebsd-current@freebsd.org
Onderwerp: Re: -CURRENT compilation time
On 06/09/2021 09:08, Jeremie Le Hen wrote:
> Compiling C++ seems
> extremely CPU heavy and this is made worse by the fact LLVM is built
> twice (once
On Mon, 6 Sept 2021 at 11:44, David Chisnall wrote:
>
> On 06/09/2021 09:08, Jeremie Le Hen wrote:
> > Compiling C++ seems
> > extremely CPU heavy and this is made worse by the fact LLVM is built
> > twice (once for build/cross tools, once for the actual world).
>
> Note that you need to build LLV
On Mon, 6 Sept 2021 at 10:10, Jeremie Le Hen wrote:
>
> Hey,
>
> I want to build -CURRENT again from sources. It's been a long time
> since I hadn't done that. I'm shocked by the compilation time.
>
> I started the whole thing on Friday night and Monday morning
On Mon, 6 Sep 2021 10:43:06 +0100, David Chisnall wrote:
> On 06/09/2021 09:08, Jeremie Le Hen wrote:
> > Compiling C++ seems
> > extremely CPU heavy and this is made worse by the fact LLVM is built
> > twice (once for build/cross tools, once for the actual world).
>
> Note that you need to b
On 06/09/2021 09:08, Jeremie Le Hen wrote:
Compiling C++ seems
extremely CPU heavy and this is made worse by the fact LLVM is built
twice (once for build/cross tools, once for the actual world).
Note that you need to build LLVM twice only if you are actively
debugging LLVM reproduceable deploy
On 06/09/21 10:08, Jeremie Le Hen wrote:
Hey,
I want to build -CURRENT again from sources. It's been a long time
since I hadn't done that. I'm shocked by the compilation time.
I started the whole thing on Friday night and Monday morning it's
still in stage 4.2 (building
Jeremie,
a few observations (from the POV of someone who builds current ~ once a
month)
On Mon, Sep 6, 2021 at 10:09 AM Jeremie Le Hen wrote:
> Hey,
>
> I want to build -CURRENT again from sources. It's been a long time
> since I hadn't done that. I'm shocked by
Hey,
I want to build -CURRENT again from sources. It's been a long time
since I hadn't done that. I'm shocked by the compilation time.
I started the whole thing on Friday night and Monday morning it's
still in stage 4.2 (building libraries). Through occasional glancing
at
Good morning!
I found a problem rather quickly: the compilation complains about a missing
libcasper.h file. (/usr/include/capsicum_helpers.h references libcasper.h, and
not from the sources but from the installed system.
The problem is that casper is a feature which can be switched off (and on
INSTALL_NODEBUG=YES
WITH_FAST_DEPEND=YES
Compilation takes a few hours usually, I will tell you the result.
best regards
Andras Krasznai
-Eredeti üzenet-
Feladó: Pete Wright [mailto:p...@nomadlogic.org]
Küldve: 2019. július 18. 19:10
Címzett: M&S - Krasznai András; freebsd-cur
27;'
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose
curdirOk=
yes'
I deleted and resynchronized the source tree and emptied the /usr/obj
directory, but it did not help.
How could I get kernel compilation work again? I would like to say that the
make.conf
;
.MAKE.LEVEL='2'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose
curdirOk=
yes'
I deleted and resynchronized the source tree and emptied the /usr/obj
directory, but it did not help.
How could I get kernel compilation work again
Hello Lev,
Saturday, December 8, 2018, 7:58:37 PM, you wrote:
>> Can you please narrow the problem down to a specific kernel revision?
> I'm still not sure it is software or hardware problem.
Looks like Samsung 850 EVO doesn't like TRIMs sent by ZFS (and I've thought
it is good SSD, consumer-gr
Hello Mateusz,
Saturday, December 8, 2018, 5:27:42 PM, you wrote:
>> Looks like each next compiler invocation is slower and more stressful than
>> previous one.
> Is this a fresh install?
Almost fresh. It was installed from some rather fresh 13 snapshot and then
upgraded to r341157 and custom
On 12/8/18, Lev Serebryakov wrote:
> Hello Lev,
>
> Saturday, December 8, 2018, 2:13:03 PM, you wrote:
>
>
>> Even when build is single-job, system becomes unresponsive. With
>> 4-job build running it could takes up to minute to switch screen's
>> windows!
> And even with 1-job kernel build upsm
08.12.2018 18:13, Lev Serebryakov wrote:
> I'm completely lost. Is it problem of software? Hardware? If it is
> hardware problem what should I blame?
Try using different kern.timecounter.hardware and/or kern.eventtimer.timer
but first try kern.eventtimer.periodic=1 instead of default 0.
If some
Hello Eugene,
Saturday, December 8, 2018, 4:27:13 PM, you wrote:
>> I'm completely lost. Is it problem of software? Hardware? If it is
>> hardware problem what should I blame?
> Try using different kern.timecounter.hardware and/or kern.eventtimer.timer
> but first try kern.eventtimer.periodic=1
Hello Lev,
Saturday, December 8, 2018, 2:13:03 PM, you wrote:
> Even when build is single-job, system becomes unresponsive. With
> 4-job build running it could takes up to minute to switch screen's windows!
And even with 1-job kernel build upsmon's connection to remote upsd
flickers! Unbelieva
Hello Lev,
Saturday, December 8, 2018, 2:13:03 PM, you wrote:
> Another strange thing I noticed: when system is in such state, "top -SH"
> shows that sometimes very low-profile processes, like clock software
> interrupt (!) could consume large amount of CPU for short periods time. When
> system
‐‐‐ Original Message ‐‐‐
On Saturday, December 8, 2018 8:18 AM, Lev Serebryakov wrote:
> Hello Lev,
>
> Saturday, December 8, 2018, 2:13:03 PM, you wrote:
>
> > Another strange thing I noticed: when system is in such state, "top -SH"
> > shows that sometimes very low-profile processes, l
Hello Lev,
Saturday, December 8, 2018, 2:13:03 PM, you wrote:
> I've checked all "standard" places — CPU is not throttling, SSD looks
> perfectly Ok according to SMART and there is no complains from AHCI driver
> about timeouts and such, system doesn't start to use swap.
ZFS ARC was checked too
Hello Freebsd-hackers,
I'm experiencing very strange situation on my lab system which is
E3-1220v2, 8GiB of RAM and 850 EVO SATA SSD (with single ZFS pool).
It runs CURRENT r341157. Kernel is built *without* INVARIANTS and other
heavy debug aids.
Everything works great — but compil
Thanks for the help, all.
Last night I set my computer to compile from the 12-CURRENT head and went to
sleep.
This morning, I installed the graphics/drm-next-kmod port and after a little
troubleshooting (I had to set the compat.linuxkpi.enable_hangcheck=0 bootflag)
I got it up and running. The
On 2/27/2018 5:03 AM, Pete Wright wrote:
On 02/26/2018 17:17, Mylan Connolly wrote:
Hello all,
I'm not sure if this is the best place to send this, but it looks
like the issue tracker in Github is a bit dead.
there may not be much traffic on it recently, but people are def still
actively
On 02/26/2018 17:17, Mylan Connolly wrote:
Hello all,
I'm not sure if this is the best place to send this, but it looks like the
issue tracker in Github is a bit dead.
there may not be much traffic on it recently, but people are def still
actively working on the repository and will see whe
Hello all,
I'm not sure if this is the best place to send this, but it looks like the
issue tracker in Github is a bit dead.
I have been trying to compile it for the past few weeks after downloading the
latest code about once a week and it looks like this issue hasn't resolved
itself.
When I
On i386, this revision breaks compilation as follows:
Building /usr/obj/usr/src/sys/SARAH/mca.o
--- mca.o ---
/usr/src/sys/x86/x86/mca.c:985:54: error: format specifies type
'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long
On Mon, Oct 24, 2016 at 02:58:43PM -0400, Michael Butler wrote:
> It seems that compilation of -current fails in the case that KDB is not
> defined.
>
> I'm assuming that the following diff achieves what was intended:
>
> imb@vm01:/usr/src/sys/x86/x86> svn d
It seems that compilation of -current fails in the case that KDB is not
defined.
I'm assuming that the following diff achieves what was intended:
imb@vm01:/usr/src/sys/x86/x86> svn diff
Index: cpu_machdep.c
===
--- cpu_m
On 08/02/16 05:06, Mateusz Guzik wrote:
> On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote:
>> In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent
>> reference to mtx_delay causes compilation of kern_mutex.c to fail
>> because KDTRACE_HOOKS m
/usr/src/sys/modules/vmm/../../amd64/vmm/vmm_dev.c: In function
'alloc_memseg':
/usr/src/sys/modules/vmm/../../amd64/vmm/vmm_dev.c:261:3: error: null
argument where non-null required (argument 1) [-Werror=nonnull]
error = copystr(VM_MEMSEG_NAME(mseg), name, SPECNAMELEN + 1, 0);
This is with amd
On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote:
> In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent
> reference to mtx_delay causes compilation of kern_mutex.c to fail
> because KDTRACE_HOOKS may be,
>
Indeed, fixed in r303655.
Thanks f
In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent
reference to mtx_delay causes compilation of kern_mutex.c to fail
because KDTRACE_HOOKS may be,
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org
NGie Cooper wrote:
> And here’s the real issue — .PATH is completely broken when
> TARGET/TARGET_ARCH are specified as explicit values:
It would help if you could indicate what you think the right value
should be.
> $ env MAKEOBJDIRPREFIX=/scratch/tmp/ngie/obj/ make buildenv TARGET=powerpc
>
> On Oct 31, 2015, at 14:37, NGie Cooper wrote:
>
>
>> On Oct 30, 2015, at 23:51, NGie Cooper wrote:
>>
>>
>>> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote:
>>>
>>> NGie Cooper wrote:
I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
and I ran into th
> On Oct 30, 2015, at 23:51, NGie Cooper wrote:
>
>
>> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote:
>>
>> NGie Cooper wrote:
>>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
>>> and I ran into this linker issue below. I have no idea (yet) why it’s
>>> tryi
> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote:
>
> NGie Cooper wrote:
>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
>> and I ran into this linker issue below. I have no idea (yet) why it’s trying
>> to compile an x64 object when I specify powerpc/powerpc —
NGie Cooper wrote:
> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
> and I ran into this linker issue below. I have no idea (yet) why it’s trying
> to compile an x64 object when I specify powerpc/powerpc — and more
> importantly, why is the object not being put in o
On Fri, Oct 30, 2015 at 4:09 PM, Bryan Drewery wrote:
...
> The example output must be a mistake as they are correct on ref11:
>
> ref11-amd64% find
> /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
> -name tst.usdt.o -exec file {} +
> /scratch/tmp/ngie/obj/arm.
On 10/30/2015 4:08 PM, Mark Johnston wrote:
> On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote:
>> On 10/30/2015 3:03 PM, NGie Cooper wrote:
>>> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote:
On 10/30/2015 2:21 PM, Bryan Drewery wrote:
> On 10/30/2015 1:57 PM, NGie Coo
On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote:
> On 10/30/2015 3:03 PM, NGie Cooper wrote:
> > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote:
> >> On 10/30/2015 2:21 PM, Bryan Drewery wrote:
> >>> On 10/30/2015 1:57 PM, NGie Cooper wrote:
> Hi Bryan/Simon!
> I
On 10/30/2015 3:03 PM, NGie Cooper wrote:
> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote:
>> On 10/30/2015 2:21 PM, Bryan Drewery wrote:
>>> On 10/30/2015 1:57 PM, NGie Cooper wrote:
Hi Bryan/Simon!
I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
a
On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote:
> On 10/30/2015 2:21 PM, Bryan Drewery wrote:
>> On 10/30/2015 1:57 PM, NGie Cooper wrote:
>>> Hi Bryan/Simon!
>>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
>>> and I ran into this linker issue below. I have no
On 10/30/2015 2:21 PM, Bryan Drewery wrote:
> On 10/30/2015 1:57 PM, NGie Cooper wrote:
>> Hi Bryan/Simon!
>> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
>> and I ran into this linker issue below. I have no idea (yet) why it’s trying
>> to compile an x64 object when
On 10/30/2015 1:57 PM, NGie Cooper wrote:
> Hi Bryan/Simon!
> I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
> and I ran into this linker issue below. I have no idea (yet) why it’s trying
> to compile an x64 object when I specify powerpc/powerpc — and more
> important
Hi Bryan/Simon!
I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS
and I ran into this linker issue below. I have no idea (yet) why it’s trying to
compile an x64 object when I specify powerpc/powerpc — and more importantly,
why is the object not being put in obj.powerpc
On 25 Sep, Matt Smith wrote:
> On Sep 25 01:00, Don Lewis wrote:
>>On 25 Sep, Matt Smith wrote:
>>> On Sep 24 21:52, Kurt Jaeger wrote:
Hi!
> > > Try dropping the attached patch in net/mediatomb/files. I
> > > submitted it in March, in PR198436:
> > >
> > > https://bugs.fr
On Sep 25 01:00, Don Lewis wrote:
On 25 Sep, Matt Smith wrote:
On Sep 24 21:52, Kurt Jaeger wrote:
Hi!
> > Try dropping the attached patch in net/mediatomb/files. I submitted it
> > in March, in PR198436:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
>
> Eh, now with an ac
On 25 Sep, Matt Smith wrote:
> On Sep 24 21:52, Kurt Jaeger wrote:
>>Hi!
>>
>>> > > Try dropping the attached patch in net/mediatomb/files. I submitted it
>>> > > in March, in PR198436:
>>> > >
>>> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
>>> >
>>> > Eh, now with an actual patc
On Sep 25 09:18, Kurt Jaeger wrote:
Hi!
>> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
This seems to create a run time dependency on GCC. Should it not just be
a build time dependency which allows you to uninstall GCC afterwards?
Maybe, I have not looked into that. Can you
Hi!
> >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
> This seems to create a run time dependency on GCC. Should it not just be
> a build time dependency which allows you to uninstall GCC afterwards?
Maybe, I have not looked into that. Can you suggest a patch ?
--
p...@opsec.
On Sep 24 21:52, Kurt Jaeger wrote:
Hi!
> > Try dropping the attached patch in net/mediatomb/files. I submitted it
> > in March, in PR198436:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
>
> Eh, now with an actual patch. :)
Thanks, helps to build it. Still fails on 9.3a, b
Hi!
> > > Try dropping the attached patch in net/mediatomb/files. I submitted it
> > > in March, in PR198436:
> > >
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
> >
> > Eh, now with an actual patch. :)
>
> Thanks, helps to build it. Still fails on 9.3a, but I *have* to go
> t
On Wed, Sep 23, 2015 at 1:39 PM, Kurt Jaeger wrote:
> Hi!
>
> > > Try dropping the attached patch in net/mediatomb/files. I submitted it
> > > in March, in PR198436:
> > >
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
> >
> > Eh, now with an actual patch. :)
>
> Thanks, helps to
Hi!
> > Try dropping the attached patch in net/mediatomb/files. I submitted it
> > in March, in PR198436:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
>
> Eh, now with an actual patch. :)
Thanks, helps to build it. Still fails on 9.3a, but I *have* to go
to bed now.
--
p.
On 23 Sep 2015, at 17:38, Kevin Oberman wrote:
>
> met/mediatomb fails to compile with clang++36. Works fine with gcc++ and
> older versions of clang++.
Try dropping the attached patch in net/mediatomb/files. I submitted it
in March, in PR198436:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?
On 23 Sep 2015, at 21:57, Dimitry Andric wrote:
> On 23 Sep 2015, at 17:38, Kevin Oberman wrote:
>>
>> met/mediatomb fails to compile with clang++36. Works fine with gcc++ and
>> older versions of clang++.
>
> Try dropping the attached patch in net/mediatomb/files. I submitted it
> in March, i
met/mediatomb fails to compile with clang++36. Works fine with gcc++ and
older versions of clang++.
/usr/local/bin/clang++36 -DHAVE_CONFIG_H -I. -I.. -I../tombupnp/upnp/inc
-I/usr/local/include -DLIBICONV_PLUG -I../src -I../tombupnp/ixml/inc
-I../tombupnp/threadutil/inc -I../tombupnp/upnp/inc -
On May 30, 2015, at 19:15, Craig Rodrigues wrote:
> On Thu, May 28, 2015 at 9:49 AM, Konstantin Belousov
> wrote:
>
>> On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote:
>>
>> I take some time to do a pass over mine code or code I am somewhat
>> knowledgable, to correct some 'ass
On Thu, May 28, 2015 at 9:49 AM, Konstantin Belousov
wrote:
> On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote:
>
> I take some time to do a pass over mine code or code I am somewhat
> knowledgable, to correct some 'assigned but not used variable' warnings.
> There might be even on
On Thu, May 28, 2015 at 5:45 AM, Muhammad Moinur Rahman
wrote:
> Hi,
>
> Can anyone give me any ideas about how can I contribute some of my idle
> times? Do I need commit bit to submit patches in Jenkins? Or should I
> submit through CODE Review?
>
Please read this: https://wiki.freebsd.org/Cod
On 28 May 2015, at 21:09, Craig Rodrigues wrote:
>
> On Thu, May 28, 2015 at 5:38 AM, Johannes Jost Meixner
...
>> The warnings are almost all in contrib/ areas. Hence, any fix might
>> want to probably be submitted to upstream first.
>>
> Sure, if we can push fixes upstream that would be great
On Thu, May 28, 2015 at 12:18 PM, Baptiste Daroussin wrote:
...
> If not upstreamed, there is a good chance it get lost during the next update.
> So
> in the special case of warning fixes, I would strongly advice to upstream
> first!!
+200
Plus upstream sources generally get slammed by multiple
On Thu, May 28, 2015 at 12:09:35PM -0700, Craig Rodrigues wrote:
> On Thu, May 28, 2015 at 5:38 AM, Johannes Jost Meixner
> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hi Craig,
> >
> > I'll gladly help (good excuse to learn C), but looking at those errors
> > in gene
On Thu, May 28, 2015 at 5:38 AM, Johannes Jost Meixner
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Craig,
>
> I'll gladly help (good excuse to learn C), but looking at those errors
> in general, one thing pops out:
>
> The warnings are almost all in contrib/ areas. Hence, an
On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote:
> Hi,
>
> I've configured Jenkins to highlight compiler warnings and
> generate a table. Jenkins also keeps track of new compiler warnings
> over time. See:
>
> https://jenkins.freebsd.org/job/FreeBSD_HEAD/warnings7
>
> Can anyon
Hi,
You don't need src bit to submit any patch and you can do it via review
without any problem. Just try to drive the patch to the right person.
Best,
2015-05-28 20:45 GMT+08:00 Muhammad Moinur Rahman :
> Hi,
>
> Can anyone give me any ideas about how can I contribute some of my idle
> times?
Hi,
Can anyone give me any ideas about how can I contribute some of my idle
times? Do I need commit bit to submit patches in Jenkins? Or should I
submit through CODE Review?
BR,
@bofh
On Thu, May 28, 2015 at 6:38 PM, Johannes Jost Meixner
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Craig,
I'll gladly help (good excuse to learn C), but looking at those errors
in general, one thing pops out:
The warnings are almost all in contrib/ areas. Hence, any fix might
want to probably be submitted to upstream first.
Correct me if I'm
Hi Craig,
I can give a hand with it.
Best,
2015-05-28 14:30 GMT+08:00 Craig Rodrigues :
> Hi,
>
> I've configured Jenkins to highlight compiler warnings and
> generate a table. Jenkins also keeps track of new compiler warnings
> over time. See:
>
> https://jenkins.freebsd.org/job/FreeBSD_HEA
Hi,
I've configured Jenkins to highlight compiler warnings and
generate a table. Jenkins also keeps track of new compiler warnings
over time. See:
https://jenkins.freebsd.org/job/FreeBSD_HEAD/warnings7
Can anyone help improve the code by periodically looking
at this table and submitting patche
On Sun, Apr 19, 2015 at 2:10 AM, Eitan Adler wrote:
>
> Perhaps it would be useful to do a second run of this, but with a
> modified share/mk to silence the most useless of these warnings?
>
>
Sure, that's fine. Can you provide a modified share/mk which you think
does the right thing? We can tr
On Sun, 19 Apr 2015, Adrian Chadd wrote:
> I just got a booting mips32 kernel using gcc-4.9.2, and boy are there
> a lot of warnings. I'm going to start fixing the ones I find - cleaner
> code is better code. Mostly.
>
> (I'd be happy with -Wall -Werror.)
I thought that -Wall was a fixed set of w
gt;make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=
>>
>>
>> It was necessary to skip boot2 from building because of errors
>> reported here:
>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html
>>
>> The boot2 co
skip boot2 from building because of errors
> reported here:
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html
>
> The boot2 compilation errors still need to be worked on.
>
> However, most other things compile with warnings. If folks are
> intereste
1658.html
The boot2 compilation errors still need to be worked on.
However, most other things compile with warnings. If folks are
interested in looking at the warnings, you can see them here:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/warnings17
Please look at these warnings, and
Hi!
> The updates to dd cause this on an i386 ..
Yes, I'm sorry. Change reverted.
--
p...@opsec.eu+49 171 3101372 6 years to go !
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
The updates to dd cause this on an i386 ..
===> bin/dd (all)
cc -O2 -pipe -march=pentium4 -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswit
rejecting compilation of port emulators/virtualbox-ose, although I
already updated the ports tree and did successfully a portmaster -R
-fd /emulators/virtualbox-ose.
Since I use some non-standard optimization flags in /etc/src.conf
and /etc/make.conf (-O3 and CPUTYPE=native instead of plain -O an
On 29 Aug 2014, at 13:33 , David Wolfskill wrote:
> On Fri, Aug 29, 2014 at 12:55:40PM +, Bjoern A. Zeeb wrote:
>>
>> On 29 Aug 2014, at 12:02 , Steven Hartland wrote:
>>
>>> Looks like this was already fixed by:
>>> http://svnweb.freebsd.org/changeset/base/270799
>>
>> Yes, just before
On Fri, Aug 29, 2014 at 12:55:40PM +, Bjoern A. Zeeb wrote:
>
> On 29 Aug 2014, at 12:02 , Steven Hartland wrote:
>
> > Looks like this was already fixed by:
> > http://svnweb.freebsd.org/changeset/base/270799
>
> Yes, just before I closed the bugreport.
>
> There?s a few more follow-up co
On 29 Aug 2014, at 12:02 , Steven Hartland wrote:
> Looks like this was already fixed by:
> http://svnweb.freebsd.org/changeset/base/270799
Yes, just before I closed the bugreport.
There’s a few more follow-up commits that (if I didn’t screw up) should make
things at least compile now. To wh
Looks like this was already fixed by:
http://svnweb.freebsd.org/changeset/base/270799
Regards
Steve
- Original Message -
From: "David Shao"
To:
Sent: Friday, August 29, 2014 6:38 AM
Subject: i386 compilation errors in head/sys/dev/ixl/if_ixl.c
Compilation error
1 - 100 of 260 matches
Mail list logo