Re: Massive libxo-zation that breaks everything
How about we allow JSON input on those utils too... Then we get into full-blown hell faster. Hmm... I would like to talk with system using JSON. JSON would be in utils that are or at least function similarly to rm, mv, ls, find, mount, zpool, zfs, geom, mdconfig, tar, df, netstat, ifconfig... (or maybe even talk JSON directly to the kernel?!). How to have all that goodness, while at same time not having extra library dependency? Without that library the system wouldn't work at all (and there is no fallback mode for "manual operation"). Fragile library that requires you to have worse-than-bad-Perl-looking (funnily I write lot of Perl myself) parts everywhere in your code. And requires huge set of tests to verify correct operation. Hope that you never see things like this: > df Shared object "libxo.so.0" not found, required by "df" Or this: > netstat -nhbdWi Name Mtu Network Address Ipkts Ierrs Idrop IbytesOpkts Oerrs Obytes Coll Drop smc0 %6s 1.5K 52:54:00:12:34:56 %8s 4.4M %5s 0 %5s 0 %10s 290M %8s 3.3M %5s 0 %10s 756M %5s 0 %5s 11 smc0- fe80::5054:ff fe80::5054:ff:fe1 %8s 8.7K - - %10s 592K %8s 17K - %10s 1.0M - - smc0- 2001:ad0:91f: 2001:ad0:91f:0:50 %8s 4.4M - - %10s 225M %8s 3.3M - %10s 709M - - smc0- 10.0.0.0/24 10.0.0.48 %8s 4.0K - - %10s 504K %8s 3.2K - %10s 233K - - lo0%6s16K %8s 272 %5s 0 %5s 0 %10s24K %8s 272 %5s 0 %10s24K %5s 0 %5s 0 lo0 - ::1/128 ::1 %8s 136 - - %10s16K %8s 136 - %10s16K - - lo0 - fe80::1%lo0/6 fe80::1%lo0 %8s0 - - %10s 0 %8s7 - %10s963 - - lo0 - 127.0.0.0/8 127.0.0.1 %8s 136 - - %10s 8.6K %8s 136 - %10s 8.6K - - Or, at least you only see it (occasionally) in CURRENT. ( And, all current libxo issues seem to be fixed, for now... ) ___ 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"
Massive libxo-zation that breaks everything
Hello. First, I would be happy to have JSON and XML output about filesystems, users, routes... but I don't like how it makes code of df, w, netstat hard to read/maintain and often broken. I don't think it would be good to continue with this. Maybe the effort should be put to creating new layer/library and then something on top of it that actually outputs JSON and XML. Or, if that's too difficult... maybe just regular df/w/netstat could be copied to somewhere else and made code libxo-output-only. And original df/w/netstat changes reverted and left alone. Then, maybe later, df/w/netstat/... could be updated to this new layer/library. Or maybe this should be just left as it is. That would mean having two netstat's in system, which could be both good (separation) and bad (maintaining). Just some ideas... I don't know how to solve this issue fully. I'm also not likely the one who would write code for all this. Hell, those aren't even all my ideas here. I just worry that system drop-in xo-zation is bad for overall health of base. Oh and, it makes rescue larger and more complex, too? On that, there was suggestion to maybe create separate "first aid kit" and "emergency room" types of system rescue utils/methods. Thanks. ___ 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: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0
Maybe I should add (if no-one noticed it yet) that this is cross-build for ARM. I wouldn't attempt to upgrade host itself over two major versions. I think it's totally insane how you can't build other major versions & arches. 9.x can't make 11.x (well, you can, if using gcc bootstrap), and I heard that 10.x can't make 9.x... I mean, build should start "clean", building all things that are needed to bootstrap. If needed, building some tools two times to get into right environment (host -> bootstrap -> bootstrap -> build). Of course, i realize how much work that would be... But this would make it possible to build things across all supported major versions and across arches where it's not too hard to support (for example, MIPS -> amd64 likely doesn't make sense, but i386/amd64 -> ARM/MIPS/... likely has uses). ___ 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: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0
Hello. I have this issue where it's impossible to get 9.x (9.3) into state where I can build clang 3.5.0 bootstrap of CURRENT. gcc works fine. I've already discussed this with some people in EFNet :: #bsdmips Currently I have this jail, built using: WITH_CLANG_IS_CC WITH_LIBCPLUSPLUS I get strange errors like: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:14: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:20: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/MathExtras.h:21:10: fatal error: 'type_traits' file not found #include ^ 1 error generated. Or: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FileOutputBuffer.cpp:14: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Errc.h:33:10: fatal error: 'system_error' file not found #include ^ 1 error generated. There are files: /usr/include/c++/4.2/tr1/type_traits /usr/include/c++/v1/type_traits /usr/include/c++/v1/system_error Where files in v1/ directory seem to be indeed correct ones and part of clang. But include paths seem wrong? Or is it something else? Full log: http://ketas.si.pri.ee/bbb.build.1420677522.log I don't know... if 9.x can't be used to build 11.x / CURRENT anymore, maybe this should be put to UPDATING (that 9.x is not supported) and I just upgrade to 10.x... which would solve everything (hopefully). Thanks. ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
On 2014-11-17 08:58, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Steve Kargl writes: >>> I'll try that tomorrow. But, I now know that this is related to using >>> hal from ports. If I comment out both enable_dbus and enable_hal in >>> /etc/rc.conf, the system works as I would expect (ie., usb now works >>> for unplugging devices!). I further suspect that the problems lies in >>> hal_probe_storage, but haven't got too much further. >> HAL: the gift that keeps on giving. It also has this wonderful feature >> where it prevents you from unmounting anything you've ever mounted, >> because it watches for new mountpoints in the system, opens them, and >> keeps the file descriptors open indefinitely. >> >> I know this isn't really germane, but I just couldn't pass up a chance >> to complain about HAL. > > Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick > and is holding on to it. If this also happens with mice and keyboards > etc., you're probably looking at two different issues. > > DES > I cursed at HAL a lot because it made uC inside r0ket to crap itself partially... this thing can be USB device but apparently didn't like black magic that HAL did. Maybe it tried to read from the beginning or something. It took lot of time to figure out why it doesn't work. Now I have set of ignore files to prevent grabbing for every single device in 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: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 07:32, Warner Losh wrote:
>
> On May 8, 2014, at 10:12 PM, Sulev-Madis Silber (ketas)
> wrote:
>
>> On 2014-05-09 02:54, Warner Losh wrote:
>>>
>>> On May 8, 2014, at 3:26 PM, Guy Yur wrote:
>>>
>>>> Hi,
>>>>
>>>> After the bsd.opts.mk / src.opts.mk split
>>>> WITHOUT_NIS in src.conf doesn't work.
>>>
>>> It should still work… At least that’s the intention...
>>>
>>>> src.conf is included in src.opts.mk after bsd.own.mk
>>>> which includes bsd.opts.mk.
>>>
>>> Yea, that’s a problem… It should be included after.
>>>
>>>> Should bsd.opts.mk options overrides now be set in
>>>> make.conf instead of src.conf?
>>>
>>> That’s a good workaround until I get that fix tested and committed. Or you
>>> could include src.conf in make.conf at the end. Either will have the same
>>> effect.
>>>
>>> Here’s the fix I’m testing, if you’d like to test that instead...
>>>
>>> diff -r d69444b828c1 share/mk/src.opts.mk
>>> --- a/share/mk/src.opts.mk
>>> +++ b/share/mk/src.opts.mk
>>> @@ -30,17 +30,15 @@
>>> .if !target()
>>> :
>>>
>>> -# Compat -- needed still?
>>> -.include
>>> -
>>> -# Allow user to configure things, but in the future this will move
>>> -# elsehwere...
>>> -
>>> +# Allow user to configure things that only effect src tree builds.
>>> SRCCONF?= /etc/src.conf
>>> .if exists(${SRCCONF}) || ${SRCCONF} != "/etc/src.conf"
>>> .include "${SRCCONF}"
>>> .endif
>>>
>>> +# Must be included after src.conf
>>> +.include
>>> +
>>> #
>>> # Define MK_* variables (which are either "yes" or "no") for users
>>> # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
>>>
>>>
>>>> Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
>>>
>>> Yea, sorry about missing this subtle issue in the split. There was another
>>> report of something similar that I hadn’t tracked down, but your report
>>> pointed me to where I needed to go.
>>>
>>> Warner
>>>
>>
>>
>> Sorry, that didn't exactly help. I don't fully get what went so wrong there?
>>
>> Now I got this during install:
>>
>> ---
>> ===> gnu/lib/libregex/doc (install)
>> install-info: not found
>> *** Error code 127
>> ---
>>
>> It was total WTF error but just in case I tried putting ".include
>> <../src.conf>" back, and it worked!
>> I use __MAKE_CONF, and inside that file I have SRCCONF.
>
> To be clear, you define SRCCONF in /etc/make.conf (or the file defined by
> __MAKE_CONF). The file defined by SRCCONF has WITHOUT_NIS=t defined, but
> that’s not effective, even with my change. However, if you add an include to
> the file defined by __MAKE_CONF, then it is effective… Is that what you are
> telling me?
>
>> 9.2, BTW... unsure if it matters here?
>
> I’m doing my testing on 10-stable… I’ll have to try on my 9.x system… But it
> is a lot slower than my 10.x system...
>
> Warner
>
Yes, that's exactly what I mean. It seems to partially work now. I
actually have lot of WITHOUT_*'s. That install error is really weird,
never seen it before. All I know is that before all those changes,
everything worked well. And if I .include file, old behavior (everything
works as expected) is back.
___
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: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 02:54, Warner Losh wrote:
>
> On May 8, 2014, at 3:26 PM, Guy Yur wrote:
>
>> Hi,
>>
>> After the bsd.opts.mk / src.opts.mk split
>> WITHOUT_NIS in src.conf doesn't work.
>
> It should still work… At least that’s the intention...
>
>> src.conf is included in src.opts.mk after bsd.own.mk
>> which includes bsd.opts.mk.
>
> Yea, that’s a problem… It should be included after.
>
>> Should bsd.opts.mk options overrides now be set in
>> make.conf instead of src.conf?
>
> That’s a good workaround until I get that fix tested and committed. Or you
> could include src.conf in make.conf at the end. Either will have the same
> effect.
>
> Here’s the fix I’m testing, if you’d like to test that instead...
>
> diff -r d69444b828c1 share/mk/src.opts.mk
> --- a/share/mk/src.opts.mk
> +++ b/share/mk/src.opts.mk
> @@ -30,17 +30,15 @@
> .if !target()
> :
>
> -# Compat -- needed still?
> -.include
> -
> -# Allow user to configure things, but in the future this will move
> -# elsehwere...
> -
> +# Allow user to configure things that only effect src tree builds.
> SRCCONF?=/etc/src.conf
> .if exists(${SRCCONF}) || ${SRCCONF} != "/etc/src.conf"
> .include "${SRCCONF}"
> .endif
>
> +# Must be included after src.conf
> +.include
> +
> #
> # Define MK_* variables (which are either "yes" or "no") for users
> # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
>
>
>> Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
>
> Yea, sorry about missing this subtle issue in the split. There was another
> report of something similar that I hadn’t tracked down, but your report
> pointed me to where I needed to go.
>
> Warner
>
Sorry, that didn't exactly help. I don't fully get what went so wrong there?
Now I got this during install:
---
===> gnu/lib/libregex/doc (install)
install-info: not found
*** Error code 127
---
It was total WTF error but just in case I tried putting ".include
<../src.conf>" back, and it worked!
I use __MAKE_CONF, and inside that file I have SRCCONF.
9.2, BTW... unsure if it matters here?
___
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: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 02:54, Warner Losh wrote:
>
> On May 8, 2014, at 3:26 PM, Guy Yur wrote:
>
>> Hi,
>>
>> After the bsd.opts.mk / src.opts.mk split
>> WITHOUT_NIS in src.conf doesn't work.
>
> It should still work… At least that’s the intention...
>
>> src.conf is included in src.opts.mk after bsd.own.mk
>> which includes bsd.opts.mk.
>
> Yea, that’s a problem… It should be included after.
>
>> Should bsd.opts.mk options overrides now be set in
>> make.conf instead of src.conf?
>
> That’s a good workaround until I get that fix tested and committed. Or you
> could include src.conf in make.conf at the end. Either will have the same
> effect.
>
> Here’s the fix I’m testing, if you’d like to test that instead...
>
> diff -r d69444b828c1 share/mk/src.opts.mk
> --- a/share/mk/src.opts.mk
> +++ b/share/mk/src.opts.mk
> @@ -30,17 +30,15 @@
> .if !target()
> :
>
> -# Compat -- needed still?
> -.include
> -
> -# Allow user to configure things, but in the future this will move
> -# elsehwere...
> -
> +# Allow user to configure things that only effect src tree builds.
> SRCCONF?=/etc/src.conf
> .if exists(${SRCCONF}) || ${SRCCONF} != "/etc/src.conf"
> .include "${SRCCONF}"
> .endif
>
> +# Must be included after src.conf
> +.include
> +
> #
> # Define MK_* variables (which are either "yes" or "no") for users
> # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
>
>
>> Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
>
> Yea, sorry about missing this subtle issue in the split. There was another
> report of something similar that I hadn’t tracked down, but your report
> pointed me to where I needed to go.
>
> Warner
>
Finally! Trying it now...
I was about to take deep look into it because that bothered me so much.
___
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"
