Re: make installworld failing with locales due to broken symlinks

[Baptiste Daroussin]

On Sun, Nov 15, 2015 at 05:57:52PM -0800, NGie Cooper wrote:
> Hi,
>   I run into this error when running `make installworld` with a world 
> installed prior and during the projects/collation merge to head — reason is 
> that the target for the symlink doesn’t exist. This might be fallout from 
> recent build changes, or a side effect of the broken symlinks…
> Thanks,
> -NGie
> 
> install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or 
> directory
> *** Error code 71
> 
> Stop.
> make[5]: stopped in /usr/src/git/share/ctypedef
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /usr/src/git/share
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src/git
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/src/git
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/src/git
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/git
> $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE
> lrwxr-xr-x  1 root  wheel  27 Nov  1 16:24 
> /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
> $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE
> /usr/share/locale/la_LN.ISO8859-1
> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE`
> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory

There is a bug in install(1) basically it tries to follow symlinks when
installing a file instead of replacing the symlink with the said file.

In the current case the problem is la_LN.ISO8859-1 has been removed before, so
the previous symlink is a dead symlink meaning install(1) fails to open it and
die

here is a proposal for a fix:
https://reviews.freebsd.org/D4191

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: CFT: uintmax_t rman

[Justin Hibbits]

On Mon, Nov 16, 2015 at 6:25 PM, Benjamin Kaduk  wrote:
> On Mon, 16 Nov 2015, Warner Losh wrote:
>
>> >
>> > On Nov 15, 2015, at 9:13 PM, Justin Hibbits  wrote:
>> >
>> > (Attempted to send this yesterday, but appears it didn't go through.  
>> > Apologies if it really did go through).
>> >
>> > As part of a project getting FreeBSD on the Freescale P5020 SoC, I 
>> > increased the width of resources, from u_long(32 bits on 32-bit archs, 64 
>> > bits on 64-bit archs) to uintmax_t (currently 64 bits on all archs).  I 
>> > have it working on PowerPC, but have not tested it on any other 
>> > architecture, I have no other systems to test it with, so I need help.  
>> > This passes a tinderbox build.  I need this tested on other archs, the 
>> > more the better, especially i386, including PAE.
>> >
>> > It should be effectively a no-op on most architectures, especially 64-bit 
>> > archs, though there were some checks I found in x86 code clamping address 
>> > checks to under 4GB, commented as necessary purely for rman.  If this 
>> > isn't the case, and we can't yet handle the checks being removed, they can 
>> > go in, but that needs testing.  It should apply cleanly to recent head.
>>
>> I like the idea. There’s nothing offensive enough in the diffs to comment 
>> upon here (though I suppose I could see a few spots one could quibble over 
>> if one were so inclined).
>>
>> I wonder, though, why not make its own typedef, even if it is just
>> ‘typedef man_res_t uintmax_t;’ in the rman headers?
>
> Channeling my inner bde (maybe?), the typedef is probably helpful, but
> uintmax_t seems less so.  uintmax_t has no guaranteed ABI, so a
> fixed-width type like uint64_t seems beter, assuming that uintmax_t is
> currently uint64_t everywhere (which I think is the case but did not
> verify).
>
> -Ben

I'm not opposed to a typedef for this, bde suggested I just use
straight uintmax_t, so it's a good starting point for wider testing.
I'm fine with anything as long as it's guaranteed to be the largest
integer size (uintmax_t guarantees that, so any typedef of that is
sufficient for me).

Any name suggestions are appreciated, but what I want more than that
right now is testing.  Hammer the hell out of this on as wide a
variety of platforms as anyone can, to make sure it doesn't break in
odd cases.

If typedefs are desired, it's no more work than a simple sed plus a
single added line.  If this breaks anything, that's the bigger
problem.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1703 - Still Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1703 - Still Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1703/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1703/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1703/console

Change summaries:

No changes


The failed test cases:

1 tests failed.
FAILED:  test-report.xml.

Error Message:


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: uintmax_t rman

[Adrian Chadd]

[snip]

emulators! emulators emulators emulators emulators emulators!

You can emulate x86 (32, 64 bit) on your ppc via qemu-devel.
I know that mips, mipsel, mips64, mips64el all work via qemu-system-*.
sparc64 is .. coming.
I'm not sure about arm, but I know arm64 can run in the emulator fine.

So hm, can you automate firing things up in emulators?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: uintmax_t rman

[Warner Losh]

On Tue, Nov 17, 2015 at 9:56 AM, Justin Hibbits 
wrote:

> On Tue, Nov 17, 2015 at 10:41 AM, Adrian Chadd 
> wrote:
> > [snip]
> >
> > emulators! emulators emulators emulators emulators emulators!
> >
> > You can emulate x86 (32, 64 bit) on your ppc via qemu-devel.
> > I know that mips, mipsel, mips64, mips64el all work via qemu-system-*.
> > sparc64 is .. coming.
> > I'm not sure about arm, but I know arm64 can run in the emulator fine.
> >
> > So hm, can you automate firing things up in emulators?
> >
> >
> >
> > -adrian
>
> Can I build a full bootable image for every arch without root
> privileges?  There's no way that I'm going to build every architecture
> on my 10 year old dual core machine (where I have root), it'll take
> forever, so my only other option is to use the cluster, where I of
> course don't have root privileges.
>
> If I can type 'make universeimages' as non-root, then, sure, I'll take
> the time to boot test every target that'll boot in qemu.  Otherwise, I
> don't have the time to do it, and that's where crowdtesting is
> advantageous.
>

One can build a bootable image without root. However, it is currently
poorly scripted at best. I have some changes to nanobsd that moves
it in that direction, but I don't have config files for all the platforms,
just the ones that I have on my desk right now :)

I tend to agree that crowd-testing is a must here.

You can run make universe w/o root permissions.

But looking at the diffs, the only thing that makes this change
at all risky is its scope. The change itself looks to be good
and mostly mechanical.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic while waiting on wlan0

[Adrian Chadd]

hiya!

try updating to head as of today. Some callout issues were fixed.

Thanks!


-a


On 17 November 2015 at 01:45, Florian Limberger
 wrote:
> Hi,
>
> I am running -CURRENT on my Lenovo T410 notebook since nearly a year now and
> am now experiencing my first reliable occuring panic.  Since I am interested
> into getting more involved, I want not only to give a report on this, but
> ask for directions on how I can help to fix the issue.
>
> The crash occurs on bad wifi reception, either on startup, if “waiting 30s
> for default interface” is not interrupted, or at a later point if the
> wpa_supplicant is not able to establish a connection (mostly due to a wrong
> passphrase, which is not the case if the wifi reception is better).
> Core.txt and the dump info are attached.
>
> I am using git commit 71f160e0193fee45242bebeff7f1282846e83d2c.
>
> Best regards,
>
>
> florian
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Simon J. Gerraty]

Dan Partelly  wrote:
>   Juniper can further help FreeBSD by donating the code of their
>   system management daemon and their fine granularity permissions

At the cost of i18n etc?
The Junos UI is totally data driven, syntax is verified term by term
(since depending on your permissions some terms simply do not exist for
you).   Such a model cannot be successfully translated to other
languages where the order of verbs and nouns differ for example.

Everything I've read on the topic suggests that messages must be
translated on at least phrase if not sentence granularity for reasonable
results, and that just doesn't fit our UI.
Thus enhancement requests for i18n are politely rejected.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: uintmax_t rman

[Justin Hibbits]

On Tue, Nov 17, 2015 at 10:41 AM, Adrian Chadd  wrote:
> [snip]
>
> emulators! emulators emulators emulators emulators emulators!
>
> You can emulate x86 (32, 64 bit) on your ppc via qemu-devel.
> I know that mips, mipsel, mips64, mips64el all work via qemu-system-*.
> sparc64 is .. coming.
> I'm not sure about arm, but I know arm64 can run in the emulator fine.
>
> So hm, can you automate firing things up in emulators?
>
>
>
> -adrian

Can I build a full bootable image for every arch without root
privileges?  There's no way that I'm going to build every architecture
on my 10 year old dual core machine (where I have root), it'll take
forever, so my only other option is to use the cluster, where I of
course don't have root privileges.

If I can type 'make universeimages' as non-root, then, sure, I'll take
the time to boot test every target that'll boot in qemu.  Otherwise, I
don't have the time to do it, and that's where crowdtesting is
advantageous.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1704 - Still Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1704 - Still Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/console

Change summaries:

No changes


The failed test cases:

1 tests failed.
FAILED:  test-report.xml.

Error Message:


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Dan Partelly]

> On 17 Nov 2015, at 11:04, Julian Elischer  > wrote:
> 
> Personally I would have liked it if in '91 we had followed one very serious 
> suggestion,
> and implemented every user command as  a base 'library', and a tcl wrapper 
> script that gave the external behaviour. then every command could have been 
> made extensible to output various formats etc. by having an alternate tcl 
> script  to run in that case
>> believe it is being pushed by Juniper to make it easier to make appliances, 
>> but I'm not sure I remember correctly.
>>I remember that there was a set of slides somewhere that give the 
>>justifications and thinking behind it.


Well, I would have loved if that would have come to pass. 24 years of potential 
framework development .

I guess libxo solves some corner cases very well, such as the problem of “how 
can we with the least possible effort get information from OS
and display it in www based GUI.

  Juniper can further help FreeBSD by donating the code of their system 
management daemon  and their fine granularity permissions system. Most likely  
the BSDs  could reuse a component like this, given it was battle tested in 
Juniper products, even if it would need adaptation and re-factoring  to fit the 
management needs of a general purpose OS. 

I am grateful for—libxo, but I would be much more grateful for a something  
like a management daemon and a fine granularity permission system. 
That would be a substantial contribution. 






___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Simon J. Gerraty]

Dan Partelly  wrote:
> Management daemon with fine grained permission, extremely
> useful. Would Juniper consider donating to FreeBSD under a BSD license
> portions of this code, the MGD, which could be reused in FreeBSD ? A

Right now I suspect the answer to that might be "no".
We know we have competitors who would dearly like that ;-)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1706 - Still Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1706 - Still Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1706/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1706/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1706/console

Change summaries:

No changes


The failed test cases:

1 tests failed.
FAILED:  test-report.xml.

Error Message:


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LOR in mpr(4)

[Pete Wright]

On 11/12/15 09:44, Pete Wright wrote:
> Hi All,
> Just wanted a sanity check before filing a PR.  I am running r290688 and
> am seeing a LOR being triggered in the mpr(4) device:
> 
> $ uname -ar
> FreeBSD srd0013 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r290688: Wed Nov 11
> 21:28:26 PST 2015 root@srd0013:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> 
> lock order reversal:
>  1st 0xf8000d26bc60 CAM device lock (CAM device lock) @
> /usr/src/sys/cam/cam_xpt.c:784
>  2nd 0xfe00012811c0 MPR lock (MPR lock) @
> /usr/src/sys/cam/cam_xpt.c:2620
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe04608ee890
> witness_checkorder() at witness_checkorder+0xe79/frame 0xfe04608ee910
> __mtx_lock_flags() at __mtx_lock_flags+0xa4/frame 0xfe04608ee960
> xpt_action_default() at xpt_action_default+0xb6c/frame 0xfe04608ee9b0
> scsi_scan_bus() at scsi_scan_bus+0x1d5/frame 0xfe04608eea20
> xpt_scanner_thread() at xpt_scanner_thread+0x15c/frame 0xfe04608eea70
> fork_exit() at fork_exit+0x84/frame 0xfe04608eeab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe04608eeab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> 

FWIW I filed the following PR as I can still reproduce this on boot:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204614

cheers,
-pete

-- 
Pete Wright
p...@nomadlogic.org
twitter => @nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD_HEAD-tests - Build #1704 - Still Unstable

[Li-Wen Hsu]

On Tue, Nov 17, 2015 at 20:34:29 +0100, Baptiste Daroussin wrote:
> On Tue, Nov 17, 2015 at 05:36:45PM +, jenkins-ad...@freebsd.org wrote:
> > FreeBSD_HEAD-tests - Build #1704 - Still Unstable:
> > 
> > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/
> > Full change log: 
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/changes
> > Full build log: 
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/console
> > 
> > Change summaries:
> > 
> > No changes
> > 
> > 
> > The failed test cases:
> > 
> > 1 tests failed.
> > FAILED:  test-report.xml.
> > 
> > Error Message:
> > 
> Can someone fix that? or at least show which test is giving unicode in the
> output?

Just did a quick look into this:

https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1704/testReport/test-report/xml/_init_/

"""
org.dom4j.DocumentException: Error on line 52159 of document 
file:///builds/FreeBSD_HEAD-tests/test-report.xml : An invalid XML character 
(Unicode: 0x1) was found in the element content of the document. Nested 
exception: An invalid XML character (Unicode: 0x1) was found in the element 
content of the document.
"""

And this is the case output contains invalid XML character:

"""


Test case metadata
--

allowed_architectures is empty
allowed_platforms is empty
description = crypt(3) salt consistency checks
has_cleanup = false
required_configs is empty
required_disk_space = 0
required_files is empty
required_memory = 0
required_programs is empty
required_user is empty
timeout = 300

Original stderr
---

*** Expected check failure: Old-style/bad inputs fail on FreeBSD: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:140: Test 22 
^A^BUZoIyj/Hy/c != ^A^Bwyd0KZo65Jo

*** Expected check failure: Old-style/bad inputs fail on FreeBSD: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:140: Test 23 
a_Av8awQ0AsR6 != a_C10Dk/ExaG.

*** Expected check failure: Old-style/bad inputs fail on FreeBSD: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:140: Test 24 
~▒UZoIyj/Hy/c != ~▒.5OTsRVjwLo



"""

There is an issue and a PR for kyua for this:

https://github.com/jmmv/kyua/issues/136
https://github.com/jmmv/kyua/pull/148

Escape these characters is a way, or we might make our test cases always
produce printable characters in outputs, however that might be
impossible (who knows when test fails would happen?).  Or, don't know if
there is a method to embedded these bytes into a valid XML.



Li-Wen

-- 
Li-Wen Hsu 
http://lwhsu.org


pgpqIWs0vVLM0.pgp
Description: PGP signature

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[dan_partelly]

Software wise, your biggest competitive advantage is using a re-branded
BSD operating system.  

On a more serious note, surely I understand and support this position. The
BSD license stays 
for true freedom, unlike the GNU beer . 

But we would never be sure that your company would say no, unless someone
asks. SO I asked here
on this list.What do you say Simon, would you please relay to Juniper
decision factors 
my plea to open source your rights management system back in the BSD
source code pool? 

Then we would know for sure if the answer is yes of no. Answer which of 
course will be respected of the BSD community.


On Tue, 17 Nov 2015 10:00:30 -0800, "Simon J. Gerraty" 
wrote:
> Dan Partelly  wrote:
>> Management daemon with fine grained permission, extremely
>> useful. Would Juniper consider donating to FreeBSD under a BSD license
>> portions of this code, the MGD, which could be reused in FreeBSD ? A
> 
> Right now I suspect the answer to that might be "no".
> We know we have competitors who would dearly like that ;-)
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1705 - Still Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1705 - Still Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1705/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1705/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1705/console

Change summaries:

No changes


The failed test cases:

1 tests failed.
FAILED:  test-report.xml.

Error Message:


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1707 - Still Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1707 - Still Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1707/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1707/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1707/console

Change summaries:

No changes


The failed test cases:

1 tests failed.
FAILED:  test-report.xml.

Error Message:


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: uintmax_t rman

[Konstantin Belousov]

On Mon, Nov 16, 2015 at 07:25:54PM -0500, Benjamin Kaduk wrote:
> Channeling my inner bde (maybe?), the typedef is probably helpful, but
> uintmax_t seems less so.  uintmax_t has no guaranteed ABI, so a
> fixed-width type like uint64_t seems beter, assuming that uintmax_t is
> currently uint64_t everywhere (which I think is the case but did not
> verify).

The statement about {u}intmax_t not having a guaranteed ABI is wrong,
I believe.  You cannot change the type after it is exposed.

I am sure that ANSI C or POSIX would introduce intthistimerealmax_t after
long long long type is added (only half-joking).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Andreas Nilsson]

On Tue, Nov 17, 2015 at 10:04 AM, Julian Elischer 
wrote:

> On 11/15/15 8:54 PM, Dan Partelly wrote:
>
>> Hi all,
>>
>> I was looking at the new facility of dumping JSON,XML from many utils in
>> base and after some funny minutes, I couldn't stop ask myself “ Ok, this is
>> funny , but why ? “ And I couldn't find a real answer. Ill outline what I
>> think:
>>
>>
>> 1. Undoubtedly, it makes base code slightly harder to understand and
>> maintain.
>> 2. I have seen the idea that this makes the information dumped by
>> utilities in the base easily accessible programatically. OK, maybe it does
>> , but
>> it doesn't fit with the current paradigm of "tool | filter | tool” at
>> all. There are no tools able to accept JSON and filter it in any meaningful
>> way, and I
>> dont see too many ppl changing their code to read JSON instead of text.
>> I don't even see the base tools changing. This output may be useful in
>> corner cases only.
>> 3. The integration of libxo IMO only points at a much deeper issue IMO.
>> It is only an expression of the need of a mechanism aimed at binary code
>> reuse. But it does not solve the problem, it only adds yet another
>> possibility in a world where too much choices already result in too much
>> splits and incompatible APIs.
>> 4. This whole effort would have been IMO much better served  by porting
>> the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, much
>> like the libs for geom, zfs , etc , ready for reuse of 3rd party code.
>> Eventually writing network control daemons in time over it , much like
>> solaris does.
>>
>> 5. A port of partial OS config data to UCL …. would induce yet induce
>> another orthogonality violation. What makes UCL better than the bestiary of
>> ad hoc databases already existing in BSDs ? Programatic readability, yes.
>> but it does not add any real much needed functionality such as
>> *transactional databases* for system tools.   Why not research a proper
>> solution - easily accessible by other programs ,orthogonal , transactional,
>> and ACL protected   solution  which can be used all over the place , from
>> OS boot, to ABI management, service management, network management, user
>> management.  I hope this day will come, a day when I will not have to edit
>> a single config file manually, yet I would have access to all the config
>> and system state  easy with wrapper APIs. In the light of this point, why
>> go with UCL ? It is not orthogonal, it is not transnational, and editing
>> the config files directly would result in the same old human errors which
>> bite as all from time to time.
>>
>> 5. It is my opinion that Solaris addressed some of those issue. Solaris
>> FMRI and SMF are lightyears ahead of the very tired models we keep using on
>> BSDs. Why not build on the insight offered by those (or even on the insight
>> offered by Windows :P) , then inventing more adhoc solutions and ad-hoc
>> databases, which do not address the real issues we have , like binary code
>> reuse, service management issues,  lack of a system wide published
>> -subscriber bus ( not kdbus :P ) fault detection and reaction, fault
>> reporting, all much needed parts of a modern OS.
>>
>> And now thee questions
>>
>> 1. Why lib XO ? Why burden the OS for some corner cases where it may be
>> useful ?
>>
>> 2. Was there any real talk on how to bring FreeBSD up to speed regarding
>> those issues ?  A period of research on what exists, on what can be done ,
>> and ensure important things are not showed in background and replaced with
>> yet another ad-hoc config database which lacks modern features ?
>> >From where I am standing, this could be a project spawning multiple
>> years , but it would be well worth it, and in my opinion it would be also
>> worthy of
>> the freeSBD foundation sponsorship for several years in a row. The
>> features I touched upon became very important parts of oder OSes, and
>> rightly so.
>>
>> Note:
>>
>> this message is serious and it is not intended to start flame wars,
>> religious crusades, or offend anyone.
>>
> Amen.
>
> I have stated before that I believe this is a mistake... actually, no, not
> "mistake" actually.. let's say "suboptimal and aesthetically dipleasing".
> It has every hallmark of "the wrong answer" in my gut feeling.
> I believe it is being pushed by Juniper to make it easier to make
> appliances, but I'm not sure I remember correctly.
> I remember that there was a set of slides somewhere that give the
> justifications and thinking behind it.
> But  quick look failed to find it.. As a 'currently mostly inactive (kids
> + $JOB ) I feel iti sn't my place to argue against it too much if currently
> active deveelopers want it, but it doesn't ring quite right to me..  The
> ifconfig issue is a separate issue, but yes that could be a good library to
> have.
>
> Personally I would have liked it if in '91 we had followed one very
> serious suggestion,
> and implemented every user command as  

‘zpool get’ command help output.

[Ranjan1018 .]

Hi,

running the command

$ zpool get

missing property argument

usage:

   get [-Hp] [-o "all" | field[,...]] <"all" | property[,...]> 
...

the following properties are supported:

   PROPERTY EDIT   VALUES

   allocated  NO   

   capacity   NO   

   dedupratio NO   <1.00x or higher if deduped>

   expandsize NO   

   fragmentation  NO   

   free   NO   

   freeingNO   

   guid   NO   

   health NO   

   leaked NO   

   size   NO   

   altroot   YES   

   autoexpandYES   on | off

   autoreplace   YES   on | off

   bootfsYES   

   cachefile YES| none

   comment   YES   

   dedupdittoYES   

   delegationYES   on | off

   failmode  YES   wait | continue | panic

   listsnapshots YES   on | off

   readonly  YES   on | off

   version   YES   

   feature@...   YES   disabled | enabled | active

The feature@ properties must be appended with a feature name.

See zpool-features(7).

I notice that:

   -

   the property “capacity” is a  and not a 
   -

   the property “name” is missing.


Regards
Maurizio
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Julian Elischer]

On 11/15/15 8:54 PM, Dan Partelly wrote:

Hi all,

I was looking at the new facility of dumping JSON,XML from many utils in base 
and after some funny minutes, I couldn't stop ask myself “ Ok, this is funny , 
but why ? “ And I couldn't find a real answer. Ill outline what I think:


1. Undoubtedly, it makes base code slightly harder to understand and maintain.
2. I have seen the idea that this makes the information dumped by utilities in 
the base easily accessible programatically. OK, maybe it does , but
it doesn't fit with the current paradigm of "tool | filter | tool” at all. 
There are no tools able to accept JSON and filter it in any meaningful way, and I
dont see too many ppl changing their code to read JSON instead of text.  I 
don't even see the base tools changing. This output may be useful in corner 
cases only.
3. The integration of libxo IMO only points at a much deeper issue IMO. It is 
only an expression of the need of a mechanism aimed at binary code reuse. But 
it does not solve the problem, it only adds yet another possibility in a world 
where too much choices already result in too much splits and incompatible APIs.
4. This whole effort would have been IMO much better served  by porting the 
bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, much like the 
libs for geom, zfs , etc , ready for reuse of 3rd party code. Eventually 
writing network control daemons in time over it , much like solaris does.

5. A port of partial OS config data to UCL …. would induce yet induce another 
orthogonality violation. What makes UCL better than the bestiary of ad hoc 
databases already existing in BSDs ? Programatic readability, yes. but it does 
not add any real much needed functionality such as *transactional databases* 
for system tools.   Why not research a proper solution - easily accessible by 
other programs ,orthogonal , transactional, and ACL protected   solution  which 
can be used all over the place , from OS boot, to ABI management, service 
management, network management, user management.  I hope this day will come, a 
day when I will not have to edit a single config file manually, yet I would 
have access to all the config and system state  easy with wrapper APIs. In the 
light of this point, why go with UCL ? It is not orthogonal, it is not 
transnational, and editing the config files directly would result in the same 
old human errors which bite as all from time to time.

5. It is my opinion that Solaris addressed some of those issue. Solaris FMRI 
and SMF are lightyears ahead of the very tired models we keep using on BSDs. 
Why not build on the insight offered by those (or even on the insight offered 
by Windows :P) , then inventing more adhoc solutions and ad-hoc databases, 
which do not address the real issues we have , like binary code reuse, service 
management issues,  lack of a system wide published -subscriber bus ( not kdbus 
:P ) fault detection and reaction, fault reporting, all much needed parts of a 
modern OS.

And now thee questions

1. Why lib XO ? Why burden the OS for some corner cases where it may be useful ?

2. Was there any real talk on how to bring FreeBSD up to speed regarding those 
issues ?  A period of research on what exists, on what can be done , and ensure 
important things are not showed in background and replaced with yet another 
ad-hoc config database which lacks modern features ?
>From where I am standing, this could be a project spawning multiple years , 
but it would be well worth it, and in my opinion it would be also worthy of
the freeSBD foundation sponsorship for several years in a row. The features I 
touched upon became very important parts of oder OSes, and rightly so.

Note:

this message is serious and it is not intended to start flame wars, religious 
crusades, or offend anyone.

Amen.

I have stated before that I believe this is a mistake... actually, no, 
not "mistake" actually.. let's say "suboptimal and aesthetically 
dipleasing".

It has every hallmark of "the wrong answer" in my gut feeling.
I believe it is being pushed by Juniper to make it easier to make 
appliances, but I'm not sure I remember correctly.
I remember that there was a set of slides somewhere that give the 
justifications and thinking behind it.
But  quick look failed to find it.. As a 'currently mostly inactive 
(kids + $JOB ) I feel iti sn't my place to argue against it too much 
if currently active deveelopers want it, but it doesn't ring quite 
right to me..  The ifconfig issue is a separate issue, but yes that 
could be a good library to have.


Personally I would have liked it if in '91 we had followed one very 
serious suggestion,
and implemented every user command as  a base 'library', and a tcl 
wrapper script that gave the external behaviour. then every command 
could have been made extensible to output various formats etc. by 
having an alternate tcl script  to run in that case.




  
___

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Julian Elischer]

On 11/16/15 1:51 AM, Andrey Chernov wrote:

On 15.11.2015 20:37, Adrian Chadd wrote:

On 15 November 2015 at 09:10, Dan Partelly  wrote:

Meaning, is that simple to push things in head , if somone does the work, even 
with with no proper review of the problem at hand , and the proposed solutions ?

Nope and yup. The juniper folk had a solution to a problem multiple
people had requested work on, and their proposal was by far the
furthest along code and use wise.

It's all fine and good making technical decisions based on drawings
and handwaving and philosophizing, but at some point someone has to do
the code. Juniper's libxo was the furthest along in implementation and
production.

It seems it is the only and final argument for libXO existence. I
remember 2 or 3 discussions against libXO spontaneously happens in the
FreeBSD lists, all ended with that, approximately: "we already have the
code and you have just speculations". Alternative and more architecture
clean ideas, like making standalone template-oriented parser probably
based on liXO, are never seriously considered, because nobody will code
it, not for other reasons.
I believe that was my suggestion.. (thus automatically gaining 
negative votes from certain scandinavian countries).
I still think it is better because it would give a framework for 
adding templates for third party applications for which
libXO will NEVER be an option. LibXO could be the backend for 
outputing the data.






___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Julian Elischer]

On 11/16/15 7:36 AM, Don Lewis wrote:

On 15 Nov, Allan Jude wrote:

On 2015-11-15 13:06, Garrett Cooper wrote:

On Nov 15, 2015, at 09:51, Andrey Chernov  wrote:


On 15.11.2015 20:37, Adrian Chadd wrote:

On 15 November 2015 at 09:10, Dan Partelly  wrote:
Meaning, is that simple to push things in head , if somone does the work, even 
with with no proper review of the problem at hand , and the proposed solutions ?

Nope and yup. The juniper folk had a solution to a problem multiple
people had requested work on, and their proposal was by far the
furthest along code and use wise.

It's all fine and good making technical decisions based on drawings
and handwaving and philosophizing, but at some point someone has to do
the code. Juniper's libxo was the furthest along in implementation and
production.

It seems it is the only and final argument for libXO existence. I
remember 2 or 3 discussions against libXO spontaneously happens in the
FreeBSD lists, all ended with that, approximately: "we already have the
code and you have just speculations". Alternative and more architecture
clean ideas, like making standalone template-oriented parser probably
based on liXO, are never seriously considered, because nobody will code
it, not for other reasons.

We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't 
seems like the best idea in the world to me from a end-user sysadmin/developer 
perspective.

I could just as easily use standard tools like awk, grep, sed, and more 
advanced languages like perl or Python to parse output, and assuming output 
doesn't get a major rewrite, I'd just go with that method that's worked pretty 
well for me over the last 10 years of my career..

Cheers,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


The big difference is, a json parser isn't going to blow up if a new
field gets added in the middle, and your awk/grep/sed script probably will.

Or more likely, if some value gets large causing adjacent columns run
together.  Or even if you the utility is used to display something where
some of the data contains whitespace.

How is an awk script going to cope with this:


the suggestion I made, which was refered to earlier, was that we add 
one very smart tool to our quiver.
one that can take a template, (a grammar decription) and parse these 
things in an meaningful manner
There are already tools that do this for HANDWRITING. If we can't do 
it for regular computer text I'd be
very surprised.  Given a correct front end.. you should be able to 
take sample outputs of a program and

generate the template.
Given a few months with no job, lots of money and time, I think it 
would be a grand project.
Unfortunately I do not have these conditions so I will limit 
complaints to the fact that
"I am not sure this is the way to do this" but I will not stop the 
libXO-ification of the utilities.
(not that I could, but I mean that my objections do not raise to the 
level of "moral outrage" :-) .





# grep spacey /etc/passwd
spacey user:*:::Update Builder:/tmp/spacey:/bin/csh
# su 'spacey user'
% cd ~
% touch 'a file'
% ls -l
total 1
-rw-r--r--  1 spacey user    0 Nov 15 15:24 a file

vs a json parser:

% ls --libxo json -l
{"__version": "1", "file-information": {"directory": [{"total-blocks":1, "entry": [{"name":"a 
file","mode":"-rw-r--r--","mode_octal":644,"links":1,"user":"spacey user","group":"","type":"regular","size":0,"modify-time":1447629885}]}]}
}

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD_HEAD-tests - Build #1704 - Still Unstable

[Baptiste Daroussin]

On Tue, Nov 17, 2015 at 05:36:45PM +, jenkins-ad...@freebsd.org wrote:
> FreeBSD_HEAD-tests - Build #1704 - Still Unstable:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/changes
> Full build log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/console
> 
> Change summaries:
> 
> No changes
> 
> 
> The failed test cases:
> 
> 1 tests failed.
> FAILED:  test-report.xml.
> 
> Error Message:
> 
Can someone fix that? or at least show which test is giving unicode in the
output?

Bapt


signature.asc
Description: PGP signature

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Dan Partelly]

It’s not about the fronted. That would have to be replaced most likely 
The most useful part IMO is the permission engine itself, and maybe some 
other parts too but without insight into implementation I am not able to 
judge that.  

You could IPC key value-data into the security engine describing arbitrary 
commands,
, have the request validated, user right checked, then passed to a command 
execution 
system (and I use the command  term very loosely, I do not refers to a
utility)  


> On 17 Nov 2015, at 18:42, Simon J. Gerraty  wrote:
> 
> Dan Partelly  wrote:
>>  Juniper can further help FreeBSD by donating the code of their
>>  system management daemon and their fine granularity permissions
> 
> At the cost of i18n etc?
> The Junos UI is totally data driven, syntax is verified term by term
> (since depending on your permissions some terms simply do not exist for
> you).   Such a model cannot be successfully translated to other
> languages where the order of verbs and nouns differ for example.
> 
> Everything I've read on the topic suggests that messages must be
> translated on at least phrase if not sentence granularity for reasonable
> results, and that just doesn't fit our UI.
> Thus enhancement requests for i18n are politely rejected.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic while waiting on wlan0

[Ben Lavery]

Evening all,

I had a very similar issue when I installed SVN r290768 on my T440 on
Monday, upped the laptop to r290927 that evening and everything was cool
again - didn't have a chance to post about it at the time, and it looks
like Adrian had already caught it :)

Regards,
Ben

On 11/17/15 16:42, Adrian Chadd wrote:
> hiya!
> 
> try updating to head as of today. Some callout issues were fixed.
> 
> Thanks!
> 
> 
> -a
> 
> 
> On 17 November 2015 at 01:45, Florian Limberger
>  wrote:
>> Hi,
>>
>> I am running -CURRENT on my Lenovo T410 notebook since nearly a year now and
>> am now experiencing my first reliable occuring panic.  Since I am interested
>> into getting more involved, I want not only to give a report on this, but
>> ask for directions on how I can help to fix the issue.
>>
>> The crash occurs on bad wifi reception, either on startup, if “waiting 30s
>> for default interface” is not interrupted, or at a later point if the
>> wpa_supplicant is not able to establish a connection (mostly due to a wrong
>> passphrase, which is not the case if the wifi reception is better).
>> Core.txt and the dump info are attached.
>>
>> I am using git commit 71f160e0193fee45242bebeff7f1282846e83d2c.
>>
>> Best regards,
>>
>>
>> florian
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"