It looks like these two are defined in rpc_com.h, so they are declared and
defined in multiple compilation units. That's not actually wrong (they'll have
common linkage and be merged), but it's discouraged because it can mask other
errors. Can you see if this patch fixes it for you?
David
I
Hi all,
For a little while, I've had an issue with the machine that sits on the edge of
my network deciding to start avahi as soon as a network is available, meaning
that it then runs mDNS advertisements on the external interface and not the
wireless one, requiring a manual restart once the mac
On 25 Apr 2014, at 09:16, Matthias Gamsjager wrote:
> Isn't the latest news that Google&co and the linux foundation setup a
> construction that these vital opensource projects get the proper
> funding. Meaning more man power and hopefully less bugs
Yes, there's effort to improve OpenSSL from the
On 29 Apr 2014, at 18:39, Julian Elischer wrote:
> I just recompiled ld and gcc and it's still not working.. did we break
> sysroot support some time in 2011?
My memory may be faulty, but I was under the impression that we switched *to*
enabling sysroot support in the toolchain some time aroun
On 17 Apr 2014, at 09:30, Adrian Chadd wrote:
> Can't we add a devd hook to do that?
I tried doing this, but it turns out that wlan devices don't appear to send
devd LINK_UP / LINK_DOWN events. It would be nice to have a clean solution to
this. By default, using the stock rc scripts, my rout
On 11 May 2014, at 20:23, Adrian Chadd wrote:
> On 11 May 2014 12:01, David Chisnall wrote:
>> On 17 Apr 2014, at 09:30, Adrian Chadd wrote:
>>
>>> Can't we add a devd hook to do that?
>>
>> I tried doing this, but it turns out that wlan devi
Hi,
I thought I'd already fixed this a year or so ago. Looking at my system, I see
this in cdefs.h:
/* C++11 exposes a load of C99 stuff */
#if defined(__cplusplus) && __cplusplus >= 201103L
#define __LONG_LONG_SUPPORTED
#ifndef __STDC_LIMIT_MACROS
#define __STDC_LIMIT_MACROS
#endif
#ifndef __S
On 25 May 2014, at 21:31, Oliver Pinter wrote:
> On 5/25/14, Dag-Erling Smørgrav wrote:
>> Oliver Pinter writes:
>>> pax_log will be in future a generic pax related logging framework,
>>> with ratelimiting and other features. It will log user, IP, binary
>>> name, path, checksum, and others.
>
On 28 May 2014, at 17:10, Dirk Engling wrote:
> I wonder if there is or there are any plans to provide an official repo
> suitable for a typical non-desktop-installation, i.e. with
There aren't currently any plans, but we're now bringing online the
infrastructure for supporting multiple packag
On 29 May 2014, at 02:23, Bryan Drewery wrote:
> As for skipping unneeded ports the best I can do is '-a' or "Build it all".
> If a port is only needed for WITH_X11 then an IGNORE should be added to it
> when WITHOUT_X11 is set to prevent wasting time on it.
We can probably do a bit better by lo
On 29 May 2014, at 23:06, Andreas Nilsson wrote:
> Having a "parent" set would be nice, yes. I maintain two repos for several
> FreeBSD-versions. Being able to pull some of the deps from packages instead
> of blindingly building would be nice.
Yes, for a lot of cases you only want to build a sma
On 2 Jun 2014, at 16:12, Ollivier Robert wrote:
> According to David Chisnall on Thu, May 29, 2014 at 10:19:41AM +0100:
>> We can probably do a bit better by looking at the complete dependency graph
>> and removing any ports that have unconditional dependencies on X. For a
>
On 3 Jun 2014, at 09:00, Beeblebrox wrote:
> I know that they are related to GNUstep (although I have no idea what
> GNUstep actually does other than act as a messaging system probably like
> dbus). Anyway, I don't understand how & why they start up and that's
> exactly my question. The only insi
On 1 Jul 2014, at 15:41, d...@gmx.com wrote:
> Also, you're at least the 3rd user (I'm at least the 2nd) that runs into this
> case; ie., here's a report: http://forums.freebsd.org/showthread.php?t=14612
> (of course, this does not contain a solution).
Please note that forums.freebsd.org is not
On 5 Jul 2014, at 14:07, Dimitry Andric wrote:
> Interestingly, -Wno-uninitialized has been in bsd.sys.mk since r76861,
> and the accompanying comment ("XXX Delete -Wuninitialized by default for
> now -- the compiler doesn't always get it right") has never been
> changed. :-)
>
> It is probably
Hi Ivan,
The demangler in libcxxrt is taken from the elftoolchain project. Kai Wang
(added to cc:) was interested in improving it, but I doubt any fixes will be
merged to 9.x any time soon.
David
On 15 Jul 2014, at 14:11, Ivan A. Kosarev wrote:
> Hello everybody,
>
> It seems there are pro
Great news!
I've been running the 1.3 prereleases for a while, and aside from one hiccup in
the early alphas, it's been a very pleasant experience.
Thanks to all involved,
David
On 23 Jul 2014, at 15:42, Baptiste Daroussin wrote:
> Hi all,
>
> I'm very please to announce the release of pkg
On 12 Aug 2014, at 19:09, John Baldwin wrote:
> OTOH, I have actually seen junk profiling _improve_ performance in certain
> cases as it forces promotion of allocated pages to superpages since all pages
> are dirtied. (I have a local hack that adds a new malloc option to
> explicitly
> memse
On 14 Aug 2014, at 02:34, Russell L. Carter wrote:
> So I would be very willing to contribute to this project, if that
> makes sense.
>
> Best,
> Russell
>
> (what list should this move to? Perhaps ports?)
I'd suggest docs. Note that currently, the docs team is the smallest part of
FreeBSD,
On 2 Sep 2014, at 12:47, Michelle Sullivan wrote:
> I'm not happy that the EOL was
> not actually an EOL and it was actually a deadline.
I'm not sure what you think the difference is. The EOL says 'the FreeBSD
project no longer supports this configuration'. If you are not relying on us
for s
On 28 Apr 2013, at 19:09, Stephen Montgomery-Smith wrote:
> But let's not get into the Linux
> bashing the same way he bashed BSD.
There is already a very good Linux Haters' Blog, in the tradition of the UNIX
Haters' Handbook. Unlike the antibsd blog (which contains ill-informed rants
and non
On 5 May 2013, at 13:26, Ulrich Spörlein wrote:
> If you can
> lump everything into one run, then it's as simple as 'scan-build make'
> and you get your HTML output.
The most important thing is to remember to do a make clean. As scan-build just
interposes itself in front of the compiler, it wo
On 28 May 2013, at 05:56, Zaphod Beeblebrox wrote:
> Urm... Isn't the use of shared memory the more obvious way to transfer data
> between processes? Am I missing some nuance?
I can't speak for Luigi's use-case, but the Binder APIs in BeOS and Android
call for this kind of copy. The receiving
On 10 Jun 2013, at 15:40, Florent Peterschmitt wrote:
> Ok and isn't it a "bad" thing ? I mean, even if the video driver
> crashes, I still want to have the ability to reboot the right way,
> avoiding corrupted files and WIP lose.
>
> Another thing is a non-critical module that can crash, but be
Hi Everyone,
If English is not your first language and / or you are not confident about your
writing, please don't let this stop you from submitting something. A native
English speaker (probably me) will read through everything before publication
and fix any errors. As long as the technical d
On 9 Jul 2013, at 05:40, Tim Kientzle wrote:
> However, this does have an implicit redundant store,
> so changing it to
>
>ptr = func(ptr + 1);
>
> is still a good idea, just not for the reason Clang was claiming.
If the compiler can tell that ptr has not escaped, then it will elide the
r
Hi,
On 10 Jul 2013, at 14:58, "O. Hartmann" wrote:
>
> Whe I try to compile the sources of a port in spe (devel/pocl), which
> is now out as RC6, I receive this error shown below:
>
> [...]
> ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
> conversion from 'int' to 'boolvec_t' (aka 'bo
On 10 Jul 2013, at 17:33, "O. Hartmann" wrote:
> Hi David,
>
> thanks for the fast response.
>
> The code I was told to check with is this:
>
> #include
> #include
> #include
>
> int
> main(void)
> {
>
>std::cout << typeid(isnan(1.0)).name() << "\n";
>
> }
>
>
> If I compile it
Hi Bruce,
You're joining in this discussion starting in the middle, so you probably
missed the earlier explanation.
On 11 Jul 2013, at 05:21, Bruce Evans wrote:
> I don't see how any conforming program can access the isnan() function
> directly. It is just as protected as __isnan() would be.
On 11 Jul 2013, at 13:11, Bruce Evans wrote:
> is also not required to be conforming C code, let alone C++ code,
> so there is only a practical requirement that it works when included
> in the C++ implementation.
Working with the C++ implementation is the problem that we are trying to solve.
>
On 11 Jul 2013, at 13:11, Bruce Evans wrote:
> The error message for the __builtin_isnan() version is slightly better up
> to where it says more.
>
> The less-unportable macro can do more classification and detect problems
> at compile time using __typeof().
The attached patch fixes the related
On 12 Jul 2013, at 10:01, "Lundberg, Johannes"
wrote:
>> As the KMS code does not switch the display mode back, once X with KMS
> starts, you can't get a console back.
>
> Is there any solution for this in the works?
Yes. ray@ is currently being funded by the FreeBSD Foundation to improve
Ne
On 12 Jul 2013, at 22:47, "O. Hartmann" wrote:
> Obviously not really fixed, but even worse:
>
> if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64
> revision 253287) isnan(x) where x is a "const double", I receive now
> the following error (which doesn't appear on previous v
On 28 Jul 2013, at 22:27, Raphael Kubo da Costa wrote:
> This seems to have been committed in r253321, and broke some code that
> was working with r253320; namely, some code in x11/kde4-workspace
> includes math.h and calls isnan() with a const double.
Please provide a test case. Specifically,
On 29 Jul 2013, at 21:54, Mateusz Guzik wrote:
> Well, there was linux_kdump in ports but it apparently got obsolete as
> necessary support for included in our regular kdump.
>
> So it may make sense to teach our ldd how to deal with Linux binaries
> for consistency, but its unclear for me if th
On 1 Aug 2013, at 20:10, Baptiste Daroussin wrote:
> Thay is with the new ld behaviour, it seems like for some reason, when linking
> with libc++ it lacks an explicit link on libcxxrt, I ll let c++ people find
> out
> why.
I think dim was planning on adding a libc++ linker script that would fix
On 17 Aug 2013, at 10:48, "O. Hartmann" wrote:
> port graphics/blender doesn't compiler neither in CURRENT nor 9.2-PRE
> for the moment. On CURRENT (FreeBSD 10.0-CURRENT #4 r254430: Fri Aug 16
> 23:23:08 CEST 2013 amd64), compilation fails with the belwo shown error
> message - for roughly a mont
On 17 Aug 2013, at 15:39, "O. Hartmann" wrote:
> On Sat, 17 Aug 2013 11:24:41 +0100
> David Chisnall wrote:
>
>> On 17 Aug 2013, at 10:48, "O. Hartmann"
>> wrote:
>>
>>> port graphics/blender doesn't compiler neither in CUR
I have a patch that I intend to commit before the 10.0 code slush that removes
GCC and libstdc++ from the default build on platforms where clang is the system
compiler. We definitely don't want to be supporting our 6-year-old versions of
these for the lifetime of the 10.x branch.
David
On 2
On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote:
> I don't know if you are aware that IF you really do that we will have serious
> problems to ship packages for 10. USE_GCC=any is the fallback in the
> portstree for all ports that are unable to build with clang which was
> introduced
> when HE
On 23 Aug 2013, at 11:42, Julian Elischer wrote:
> no, I believe we have said that 10 would ship with clang by default. NO
> mention was made about gcc being absent, and I am uncomfortable with taking
> that step yet. Having gcc just present, will not hurt you.. even after it is
> gone we wil
On 23 Aug 2013, at 13:26, Andriy Gapon wrote:
> On the other hand these tools are perfect for building FreeBSD kernel and
> base.
> Extrapolating my experience with base GCC I am very confident in it as a
> FreeBSD development tool.
> Extrapolating my experience with Clang I am not yet confident
On 23 Aug 2013, at 14:52, Warner Losh wrote:
> No. That breaks non x86 architecutres. gcc must remain in base for now, or
> there's no bootstrap ability. Nobody has done the lifting to cleanly
> integrate gcc as a port into buildworld, althogh Brooks' work gets us most of
> the way there.
We'
On 23 Aug 2013, at 13:30, Bernhard Fröhlich wrote:
> lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need
> to fix it first to be able to compile it with clang 3.3 from base.
What is the issue with the gcc 4.2.1 build (aside from the fact that it has a
terrifying number o
On 24 Aug 2013, at 02:35, Julian Elischer wrote:
> I don't know.. whatever RootBSD run, but the fact that I needed gcc for
> anything suggests that we should keep it around for a while.
Please point to the FreeBSD PRs and clang bug reports that you have filed about
this. I have been running a
On 23 Aug 2013, at 23:37, Warner Losh wrote:
> I'd dispute the 'and surely it seems like it does' part of this. Non x86
> architectures will continue to use gcc because clang just isn't ready at this
> time for them. Some are very close (arm), some are close (powerpc64, mips*),
> some are no w
On 24 Aug 2013, at 11:30, "Sam Fourman Jr." wrote:
> So I vote, let's not give ourselves the burden of "lugging" dead weight in
> base
> for another 5 years. (in 2017 do we still want to be worrying about gcc in
> base?)
Perhaps more to the point, in 2017 do we want to be responsible for maintai
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote:
> Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
> don't understand inlined asm.
Clang supports inline asm. If there is some specific inline asm syntax that
clang does not recognise, then please will you point me to the
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
> And i found PR about clang and mplayer: ports/176272
> This PR contains log with build error log.
Please file clang bugs at http://llvm.org/bugs/
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 25 Aug 2013, at 00:06, Steve Kargl wrote:
> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
>>
>>> And i found PR about clang and mplayer: ports/176272
>>> This PR contains log with bu
On 29 Aug 2013, at 15:57, John Baldwin wrote:
> I have not seen any convincing
> argument as to why leaving GCC in the base for 10.x impedes anything.
> Because clang isn't sufficient for so many non-x86 platforms we can't
> really start using clang-specific features yet anyway.
Apparently I h
On 29 Aug 2013, at 18:44, John Baldwin wrote:
> How does removing GCC from base change this? I already deal with having
> 3 different GCC versions at work by building them from ports and building
> things with the right rpath, etc. so I am familiar with this, and having
> GCC in the base doesn't
On 30 Aug 2013, at 08:18, Julian Elischer wrote:
> As far as I'm concerned we can even slate it for
> "possible removal in 10.2-- if clang has proven up to the task"
I would be happy to ship gcc, as long as:
- It's explicitly marked as deprecated and due for removal at some point in the
10.x t
On 30 Aug 2013, at 08:56, Jonathan Anderson wrote:
> Wouldn't this mean that we can't build base using the shipped-in-base g++? If
> we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++,
> then people wanting to compile the base system with gcc/g++ will have to
> install
On 30 Aug 2013, at 15:41, John Baldwin wrote:
> So my take away from this is that you have no plans to support any platform
> that
> doesn't support clang as you just expect ia64 and sparc64 to die and not be
> present in 11.0. That may be the best path, but I've certainly not seen that
> goal
On 30 Aug 2013, at 15:53, Nathan Whitehorn wrote:
> So the real driver here is switching to libc++. Is there really no way
> at all to use it with gcc? If, even with hacking, we could arrange that
> to work then it seems that all of our problems would go away.
If we can make our g++ compile C++1
On 31 Aug 2013, at 08:33, John-Mark Gurney wrote:
> Why didn't this come up when John added XSAVE (a year ago) or Pedro
> Giffuni added amdfam10 support (3 months ago)?
>
> Plus, I've sent other patches earlier this year to -toolchain and made
> clear why I was adding them... Had I known that t
On 1 Sep 2013, at 02:53, Benjamin Kaduk wrote:
> I am worried about the definition of "polished". I held my tongue in Ottawa
> in 2011 when Kirk wanted to turn SU+J on by default, since I figured he knew
> what was going on much better than I did. Then, we discovered the bad
> interactions b
On 1 Sep 2013, at 19:03, Mark Linimon wrote:
> If this is the case, IMHO:
I was going to quote the whole mail, but actually this is enough. As I have
already said in this thread, there is no such plan. I repeat, for those who
missed it the first time:
On 30 Aug 2013, at 16:11, Da
On 2 Sep 2013, at 03:01, John-Mark Gurney wrote:
> b/crtn.o: warning: linking PIC files with non-PIC files
I think that this is an issue in our import of clang. I'll have to check
whether I upstreamed the code, but it's basically just not setting the e_flags
field in the ELF header correctly
On 5 Sep 2013, at 08:14, Baptiste Daroussin wrote:
> On Thu, Sep 05, 2013 at 09:05:45AM +0200, Dimitry Andric wrote:
>> On Sep 5, 2013, at 00:38, Baptiste Daroussin wrote:
>>> I'm running exp-run to build the whole ports tree with clang using libc++ by
>>> default.
>>>
>>> As a result we have
On 4 Sep 2013, at 23:38, Baptiste Daroussin wrote:
> As a result we have a lot of fallouts of ports complaining about:
> undefined reference to `powl'
>
> It seems like libc++ is relying on a function we don't have yet in libm, am I
> missing something?
I've attached a diff that I'd like to com
On 5 Sep 2013, at 22:09, Steve Kargl wrote:
> On Thu, Sep 05, 2013 at 09:52:13AM +0100, David Chisnall wrote:
>> On 4 Sep 2013, at 23:38, Baptiste Daroussin wrote:
>>
>>> As a result we have a lot of fallouts of ports complaining about:
>>> undefined reference
Hi Everyone,
As of r255321, we are no longer building gcc or libstdc++ as part of the
default install on platforms where clang is cc.
If you are using gcc, you have two options:
1) Install one of the lang/gcc* ports (Warner has been working on separating
out the patches to our GCC, so these sh
On 6 Sep 2013, at 16:59, Steve Kargl wrote:
> Well, your commit has pre-empted any discussion on whether
> there would have been a better kludge. Oh well.
I'm very happy for it to be replaced by something better (and would be ecstatic
for it to go away completely and for all of the functions t
On 30/01/2023 21:39, Yetoo wrote:
If github is going to be considered for issue tracking I just want to
say, after having extensively using it for issue tracking, it tends to
be difficult to find an issue if the exact title isn't entered and many
duplicate reports are made as a result. Code s
On 01/02/2023 06:05, Yetoo wrote:
On Tue, Jan 31, 2023, 9:47 AM David Chisnall wrote:
On 30/01/2023 21:39, Yetoo wrote:
If github is going to be considered for issue tracking I just want to
say, after having extensively using it for issue tracking, it tends to
be difficult to find an issue if
On 27 May 2023, at 03:52, Mike Karels wrote:
>
> On 26 May 2023, at 21:28, bob prohaska wrote:
>
>> It turns out all seven hosts in my cluster report
>> a null password for root in /usr/src/etc/master.passwd:
>> root::0:0::0:0:Charlie &:/root:/bin/sh
>>
>> Is that intentional?
>
> Well, it has
On 30/05/2023 20:11, Dag-Erling Smørgrav wrote:
David Chisnall writes:
There was a very nasty POLA violation a release or two ago. OpenSSH
defaults to disallowing empty passwords and so having a null password
was a convenient way of allowing people to su or locally log into that
user but
Hi,
This bit of the C spec is a bit of a mess. There was, I believe, a desire to
return volatile to its original use and make any use of volatile other than
MMIO discouraged. This broke too much legacy code and so now it’s a confusing
state.
The requirements for volatile are that the compiler
On 2 Aug 2023, at 00:33, Rick Macklem wrote:
>
> Just trying to understand what you are suggesting...
> 1 - Declare the variable _Atomic(int) OR atomic_int (is there a preference)
> and
> not volatile.
Either is fine (the latter is a typedef for the former). I am not a huge fan
of the typ
Hi,
What are the changes to the DTS files? If there are problems with DTC handling
the new files, please can you raise issues here:
https://github.com/davidchisnall/dtc/issues
If there are problems with the kernel’s handling of the dtb, please ignore me.
David
> On 10 Aug 2023, at 13:24, Geor
On 12 Sep 2023, at 17:19, Bakul Shah wrote:
>
> FreeBSD
> should add inotify.
inotify is also probably not the right thing. If someone is interested in
adding this, Apple’s fsevents API is a better inspiration. It is carefully
designed to ensure that the things monitoring for events can’t ev
On 8 Jan 2024, at 16:30, Tomoaki AOKI wrote:
>
> So it should be in ports to adapt for latest products more quickly than
> in base, I think.
We push out a new release of each of the -STABLE branches every 6 months and
can do ENs if a product ships and becomes popular in under six months. This
On 15 Jan 2024, at 16:46, Mario Marietto wrote:
>
> The ARM Chromebook is based on armv7,it is still recent.
For reference, the ARMv7 architecture was introduced in 2005. The last cores
that implemented the architecture were released in 2014. This is not a
‘recent’ architecture, it’s one tha
On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
>
> Binary startup is very slow, for example execve of a hello world
> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
> compared to a native one. As such perf-wise this looks like a step in
> the wrong direction.
Have you profil
On 21 Feb 2024, at 20:00, Brooks Davis wrote:
>
> The sanitizers reach somewhat questionably into libc internals that are
> exported to allow rtld to update them. I was unable to find an solution
> that didn't break this and I felt that fixing things like closefrom()
> using non-deprecated sysca
Hi all,
I have some code using libzfs_core that works fine on 13, but seems not to on
15-CURRENT. The lzc_snapshot function is failing with exactly the same nv list
argument. It is failing with errno 2 (ENOENT) from the ZFS ioctl (and not
returning an nvlist of errors).
My understanding is t
Hi,
Since updating to 15-CURRENT, I have been unable to get some existing code that
used libzfs_core to take snapshots. There are a lot of reasons that this could
have broken and it’s hard to track it down:
- We ship both libnv and libnvpair. These define the same data structure but
with di
On 23 Oct 2017, at 21:35, Mateusz Guzik wrote:
>
> Instead, the same can be reshuffled:
> struct crap2 {
>int i1;
>int i2;
>void *p1;
>void *p2;
> };
>
> With offsets:
>
> 0x1000 i1
> 0x1004 i2
> 0x1008 p1
> 0x1010 p2
>
> This is only 24 bytes. 2 ints can be pla
On 24 Oct 2017, at 10:29, Kurt Jaeger wrote:
>
>>
>> is libfuzzer (see https://llvm.org/docs/LibFuzzer.html) supported on FreeBSD
>> head?
>> It seems that it is not supported by /usr/bin/clang...
>>
>> Am I wrong and it is supported or is someone working on it?
>
> I searched in the Port dev
On 1 Jan 2018, at 05:09, Adrian Chadd wrote:
>
> On 30 December 2017 at 00:28, Konstantin Belousov wrote:
>> On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote:
>>> Is there some way to programmatically get the CPU cache line sizes on
>>> FreeBSD?
>>
>> There are, all of them are M
On 3 Jan 2018, at 22:12, Nathan Whitehorn wrote:
>
> On 01/03/18 13:37, Ed Schouten wrote:
>> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov :
>> On x86, the CPUID instruction leaf 0x1 returns the information in
>> %ebx register.
> Hm, weird. Why don't we extend sysctl to include this
On 5 Jan 2018, at 02:46, Jon Brawn wrote:
> This idea of Arm big.LITTLE systems having cache lines of different lengths
> really, really bothers me - how on earth is the cache coherency supposed to
> work in such a system? I doubt the usual cache coherency protocols would work
> - probably need
On 10 Jan 2018, at 18:53, Baptiste Daroussin wrote:
>
> I need to figure out a mechanism to make this simpler to handle to upgrade of
> base system while keeping this safety belt for users.
>
> Any idea is welcome
I believe the apt approach to this is to have a different verb (distupgrade vs
u
On 15 Jan 2018, at 14:49, Hans Petter Selasky wrote:
>
> The "seq" utility should use two 64-bit integers to represent the 10-base
> decimal number instead of float/double. And then you need to step this pair
> of integers.
As the saying goes:
> Sometimes, people think 'I have a problem and I
On 15 Jan 2018, at 17:00, Jan Beich wrote:
>
> It wouldn't help (see below). Clang 6 accidentally made __atomic* work
> enough to satisfy configure check but not for the port to build. I guess,
> it also confuses configure in net/librdkafka and net-mgmt/netdata.
>
Can we (by which I probably me
On 6 Apr 2018, at 01:30, Pete Wright wrote:
>
>
> On 04/05/2018 17:15, Steve Kargl wrote:
>> This assumes that a gcc(1) is available on the system.
>>
>> % man gcc
>> No manual entry for gcc
>>
>> If the system compiler is clang/clang++, then it ought to be
>> documented better than it current
On 03/05/2021 22:37, Pete Wright via freebsd-current wrote:
On 5/1/21 12:42 PM, Chargen wrote:
Dear all
please note that I hope this message will be discussed to get this on the
roadmap for FreeBSD. Perhaps there is already talk about && work done on
that.
I would like to suggest having a BSD
On 07/05/2021 11:17, Rozhuk Ivan wrote:
On Thu, 6 May 2021 10:57:16 +0100
David Chisnall wrote:
Whether Microsoft or the FreeBSD project should do the work really
comes down to who has more to gain. Windows 10 is installed on
around a 1.3 billion devices and any of these users can run
On 06/05/2021 16:17, Alan Somers wrote:
It's easy to build a UFS-based VM image just by setting WITH_VMIMAGES in
release.conf and running release.sh. But what about ZFS-based images?
What's the easiest way to build a ZFS-based VM image, using a pool layout
similar to what the interactive install
On 09/05/2021 04:55, Daniel Nebdal wrote:
On Thu, 6 May 2021 at 19:05, David Chisnall wrote:
[ Disclaimer: I work for Microsoft, but not on WSL and this is my own
opinion ]
(...)
David
Just as a counterpoint to Rozhuk's take, that all sounds sensible
enough to me - FreeBSD would pro
On 16/07/2021 16:50, Cameron Katri via freebsd-current wrote:
On Fri, Jul 16, 2021 at 09:01:49AM -0600, Alan Somers wrote:
FreeBSD has always placed /usr/local/X after /usr/X in the default PATH.
AFAICT that convention began with SVN revision 37 "Initial import of 386BSD
0.1 othersrc/etc". Why
Hi,
Does anyone know how to build ZFS disk images from any existing tooling?
I haven't used UFS for over a decade now and the official cloud images
are all UFS, so I end up doing an install from the CD ISO into Hyper-V
locally and then exporting the VHD, but that can't be the most efficient
w
would need to re-guid the
pool on first boot.
On Thu, Aug 5, 2021, 6:41 AM David Chisnall wrote:
Hi,
Does anyone know how to build ZFS disk images from any existing tooling?
I haven't used UFS for over a decade now and the official cloud images
are all UFS, so I end up doing an install from
On 05/08/2021 13:53, Alan Somers wrote:
I don't know of any way to do it using the official release scripts
either. One problem is that every ZFS pool and file system is supposed
to have a unique GUID. So any kind of ZFS release builder would need to
re-guid the pool on first boot.
Is there
Hi everyone,
A few years ago at BSDCam I started working on a tool that would parse data
structures using libclang and provide libucl wrappers for serialising and
deserialising the code. After working on it for a bit, I came to the
conclusion that the approach was the wrong way around and what
On 25/08/2021 22:19, Alan Somers wrote:
We usually try to maintain backwards compatibility forever. But is that
necessary for the ses(4) ioctls? There are several problems with them as
currently defined. They lack type safety, lack automatic copyin/copyout
handling, and one of them can overrun
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
Hi,
I think there are two conflated things here:
- Moving the handbook into the source tree.
- Creating branches in the handbook that track particular releases.
The first one is largely irrelevant to anyone other than people
contributing to the handbook, so I'll focus on the second:
This i
201 - 300 of 317 matches
Mail list logo
