Re: Crash with ZFS between r296491 and r296548

2016-03-08 Thread Ed Maste 
On 9 March 2016 at 01:39, Ed Maste  wrote:
> On 8 March 2016 at 18:52, Jean-Sébastien Pédron
>  wrote:
>> Hi!
>>
>> I use Root on ZFS and my laptop doesn't boot with a kernel from r296548
>> and world from r296491 (so older than kernel). Ed hits a similar crash.
>>
>> Here are the dmesg and backtrace of zfs(8):
>> https://gist.github.com/dumbbell/c9978ad4ac70214f0f47
>>
>> With a kernel and world from r296491, everything is ok.
>>
>> I didn't have the time to bisect the bad commit yet, so this is mostly a
>> warning for other. Maybe someone will know what's wrong :)
>
> The error's coming from namespace_reload() in libzfs_util.c,
> ioctl(hdl->libzfs_fd, ZFS_IOC_POOL_CONFIGS, )
>
> I haven't had a chance to bisect yet either. There are 9 or so commits
> between r296491 and r296548 -- I hope mav@ has some insight.

I still haven't been able to bisect, but in a local tree I've reverted
recent ZFS changes and the issue is gone.

Reverted commits: r296510, r296512, r296514, r296516, r296519,
r296521, r296523, r296528, r296530
___
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: Crash with ZFS between r296491 and r296548

2016-03-08 Thread Ed Maste 
On 8 March 2016 at 18:52, Jean-Sébastien Pédron
 wrote:
> Hi!
>
> I use Root on ZFS and my laptop doesn't boot with a kernel from r296548
> and world from r296491 (so older than kernel). Ed hits a similar crash.
>
> Here are the dmesg and backtrace of zfs(8):
> https://gist.github.com/dumbbell/c9978ad4ac70214f0f47
>
> With a kernel and world from r296491, everything is ok.
>
> I didn't have the time to bisect the bad commit yet, so this is mostly a
> warning for other. Maybe someone will know what's wrong :)

The error's coming from namespace_reload() in libzfs_util.c,
ioctl(hdl->libzfs_fd, ZFS_IOC_POOL_CONFIGS, )

I haven't had a chance to bisect yet either. There are 9 or so commits
between r296491 and r296548 -- I hope mav@ has some insight.
___
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"

Crash with ZFS between r296491 and r296548

2016-03-08 Thread Jean-Sébastien Pédron 
Hi!

I use Root on ZFS and my laptop doesn't boot with a kernel from r296548
and world from r296491 (so older than kernel). Ed hits a similar crash.

Here are the dmesg and backtrace of zfs(8):
https://gist.github.com/dumbbell/c9978ad4ac70214f0f47

With a kernel and world from r296491, everything is ok.

I didn't have the time to bisect the bad commit yet, so this is mostly a
warning for other. Maybe someone will know what's wrong :)

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: loader and load: path?

2016-03-08 Thread John 

Hi, (reply is at the bottom of quoted text)

On Mon, Mar 07, 2016 at 04:04:46PM +, Anthony Jenkins wrote:

set module_path /boot/kernel # ?

I don't think module_path is set to its default "/boot/kernel;/boot/modules" 
when booting to loader(8) prompt...


Anthony Jenkins

From: Steven Hartland 
To: freebsd-current@freebsd.org
Sent: Monday, March 7, 2016 9:18 AM
Subject: Re: loader and load: path?


So your saying "kldload zfs" fails because it can't find opensolaris or
are you giving it absolute paths?

If so try without absolute paths.

Regards
Steve


On 07/03/2016 14:09, Larry Rosenman wrote:

If I type load /boot/kernel/kernel, and then load /boot/kernel/zfs.ko,
the loader
(loader.efi in this case) says it can't find opensolaris.  Same for
dtraceall, where
it can't find it's dependent modules.  Just hitting enter does the
right thing.

What variable(s) am I missing?


I think you're going to have to load /bootpool/boot/kernel/zfs.ko

I've been bitten by this. Seems there was a recent change, and it
affects -stable as well as -current. The boot path was changed and
it's caused breakage. I dunno what way there is around it.

I downloaded the memstick image 10.3-RC1 on the 5th, booted to it, all
was well. Mouse working (I have a wireless mouse that uses ums0,
standard zfs-on-root install, nothing else added.

Today I ran svnlite and updated the sources, recompiled, ran
mergemaster and at the start of it it says something like (from
memory) that /boot kernel is a link and do I want to remove it? The
directory can be made later - so I agree to this. After the update,
the system is at 10.3-PRERELEASE #0 r296497

The system boots but now my mouse isn't detected as a mouse but as a
keyboard. The radeon drivers the screen needs weren't compiled, so I
go into /usr/src/sys/modules/drm2/ to make the modules, ran make
install but it bails saying that /boot/kernel isn't a directory... so
I checked and indeed it wasn't:

$ ls -lah /boot/kernel
-r-xr-xr-x  1 root  wheel   454K Mar  8 20:57 /boot/kernel
$

modules are now in /bootpool/boot/kernel/

it's a file so I can't fix this by symlinking to the real path.

It seems some modules know about the path and not others. kldload
doesn't know about the path. If I want a module loaded I have to
specify the full path. For example, if I want to load ums.ko manually,
I can:

$ sudo kldload /bootpool/boot/kernel/ums.ko

$ kldstat
Id Refs AddressSize Name
1   26 0x8020 f8f798   kernel
21 0x8119 2e9690   zfs.ko
32 0x8147a000 5640 opensolaris.ko
41 0x8148 1d698geom_eli.ko
53 0x8149e000 322f0crypto.ko
61 0x814d1000 f8c8 aio.ko
71 0x814e1000 3418 amdtemp.ko
81 0x814e6000 4e50 aesni.ko
91 0x814ec000 15080fuse.ko
101 0x81611000 22c8 ums.ko
	 
but if I unload it and then try to load it in the usual way, it can't

be found:

$ sudo kldload ums.ko
kldload: can't load ums.ko: No such file or directory

how can I fix this please? [without having to reinstall]

thanks,
--
John 
___

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"

geli vs openssl, geli is much slower

2016-03-08 Thread Anonymous 
Hello All,

The disk encryption on my NAS (RAIDZ1 + ZFS + GELI (aes-128-xts)) is
running much slower than expected (80MB/S). It seems that GELI is much
slower than openssl for aes-128-xts, the results might be similar for
other cipher, but I only verified aes-128-xts and aes-128-cbc.

My NAS is running 9.3, but I was able to replicate on FreeBSD 10.2
(recent VM image) on a different machine.

OpenSSL w/o AES-NI:

OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-xts

type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-128-xts  49702.86k   140889.72k   358413.11k   444357.17k   482859.72k

OpenSSL w/ AES-NI (not relevant, for demonstration purpose):

openssl speed -elapsed -evp aes-128-xts

type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-128-xts 417564.07k  1253833.96k  2302266.40k  2993555.43k  3411513.42k

w/ gzero:

dd if=/dev/zero of=/dev/gzero.eli bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 13.107259 secs (7640 bytes/sec)

geli is only seing 76MB/s (4k sector) while openssl (even at 1k) is
doing 433 MB/s.

Am I comparing apples and oranges? Is this to be expected?

NOTE: It should not be related to AES-NI since my processor (an X3450)
doesn't support AES-NI, and I was seeing similar results.

NOTE2:

# uname -a
FreeBSD  10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28: Wed Aug 12
15:26:37 UTC 2015
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

# openssl version
OpenSSL 1.0.1p-freebsd 9 Jul 2015
___
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] packaging the base system with pkg(8)

2016-03-08 Thread Roger Marquis 

In FreeBSD, we *do* have a compelling case for installing a small subset of
the base system: service jails (or ?containerised applications? as the kids
are calling them). We want to be able to install, for example, owncloud and
nginx or ejabberd in a jail with only the bare minimum required for them to
start and run. We want updates to these jails to be fast and we want disk
usage (and install time) to be low. In such a jail, I want a shell, the
parts of sbin needed to do network setup, the libraries that these ports
depend on, *and nothing else*. We?re still a way away from doing that.


Would be great to be able to do this via something like 'make
installworld -DMINJAIL DESTDIR=...' and end-up with a bare-bones, secure
jail.  We've done something like that in the past by:

Roger


chroot $jail && rm -rf \
 /media /mnt /modules /proc /rescue /boot /cdrom /usr/src /usr/obj /bin/chio 
/bin/rcp
 /bin/rmail /etc/amd.map /etc/apmd.conf /etc/bluetooth /etc/bluetooth/
 /etc/defaults/bluetooth.device.conf /etc/defaults/devfs.rules
 /etc/defaults/pccard.conf /etc/devd.conf /etc/devfs.conf /etc/dhclient.conf
 /etc/disktab /etc/hosts.lpd /etc/isdn/ /etc/namedb /etc/nsmb.conf /etc/ntp
 /etc/pccard_ether /etc/pf.conf /etc/pf.os /etc/phones /etc/ppp /etc/ppp/
 /etc/printcap /etc/rc.firewall /etc/rc.firewall6 /etc/rc.initdiskless 
/etc/rc.resume
 /etc/rc.suspend /etc/remote /etc/rmt /etc/security /etc/usbd.conf 
/kernel.GENERIC
 /lib/geom/ /lib/libatm.so.2 /lib/libcam.so.2 /lib/libgeom.so.2 
/lib/libpcap.so.4
 /sbin/adjkerntz /sbin/atacontrol /sbin/atm /sbin/atmconfig /sbin/badsect
 /sbin/bsdlabel /sbin/camcontrol /sbin/ccdconfig /sbin/clri /sbin/comcontrol
 /sbin/conscontrol /sbin/devd /sbin/devfs /sbin/dhclient /sbin/dhclient-script
 /sbin/disklabel /sbin/dmesg /sbin/dump /sbin/dumpfs /sbin/dumpon /sbin/fastboot
 /sbin/fasthalt /sbin/fdisk /sbin/ffsinfo /sbin/fore_dnld /sbin/fsck
 /sbin/fsck_4.2bsd /sbin/fsck_ffs /sbin/fsck_msdosfs /sbin/fsck_ufs /sbin/fsdb
 /sbin/fsirand /sbin/g* /sbin/gbde /sbin/gcache /sbin/gconcat /sbin/geli 
/sbin/geom
 /sbin/ggatec /sbin/ggated /sbin/ggatel /sbin/gjournal /sbin/glabel 
/sbin/gmirror
 /sbin/gmultipath /sbin/gnop /sbin/gpart /sbin/graid /sbin/graid3 /sbin/growfs
 /sbin/gsched /sbin/gshsec /sbin/gstripe /sbin/gvinum /sbin/gvirstor /sbin/halt
 /sbin/ilmid /sbin/init /sbin/ip6fw /sbin/ipf /sbin/ipfs /sbin/ipfstat 
/sbin/ipftest
 /sbin/ipfw /sbin/ipmon /sbin/ipnat /sbin/ippool /sbin/ipresend /sbin/kldconfig
 /sbin/kldload /sbin/kldstat /sbin/kldunload /sbin/mdconfig /sbin/mdmfs 
/sbin/mknod
 /sbin/mksnap_ffs /sbin/mount /sbin/mount_cd9660 /sbin/mount_devfs 
/sbin/mount_ext2fs
 /sbin/mount_fdescfs /sbin/mount_linprocfs /sbin/mount_linsysfs /sbin/mount_mfs
 /sbin/mount_msdosfs /sbin/mount_nfs /sbin/mount_nfs4 /sbin/mount_ntfs
 /sbin/mount_nullfs /sbin/mount_procfs /sbin/mount_reiserfs /sbin/mount_std
 /sbin/mount_udf /sbin/mount_umapfs /sbin/mount_unionfs /sbin/natd /sbin/newfs
 /sbin/newfs_msdos /sbin/nextboot /sbin/nfsiod /sbin/nos-tun /sbin/pfctl 
/sbin/pflogd
 /sbin/ping /sbin/ping6 /sbin/poweroff /sbin/quotacheck /sbin/raidctl 
/sbin/rdump
 /sbin/reboot /sbin/restore /sbin/route /sbin/routed /sbin/rrestore 
/sbin/rtquery
 /sbin/rtsol /sbin/savecore /sbin/sconfig /sbin/setkey /sbin/shutdown 
/sbin/slattach
 /sbin/spppcontrol /sbin/startslip /sbin/sunlabel /sbin/swapctl /sbin/swapoff
 /sbin/swapon /sbin/tunefs /sbin/umount /usr/bin/bthost /usr/bin/btsockstat
 /usr/bin/ftp /usr/bin/lastcomm /usr/bin/lp /usr/bin/lpq /usr/bin/lpr 
/usr/bin/lprm
 /usr/bin/lsvfs /usr/bin/mt /usr/bin/ncplist /usr/bin/ncplogin 
/usr/bin/ncplogout
 /usr/bin/nfsstat /usr/bin/pawd /usr/bin/pr /usr/bin/quota /usr/bin/rfcomm_spdd
 /usr/bin/scp /usr/bin/sftp /usr/bin/showmount /usr/bin/sscop /usr/bin/stdbuf
 /usr/bin/tcopy /usr/bin/tip /usr/bin/truss /usr/bin/usbhidaction 
/usr/bin/usbhidctl
 /usr/bin/vmstat /usr/bin/wall /usr/bin/write /usr/bin/yp* /usr/bin/ypchfn
 /usr/bin/ypchpass /usr/bin/ypchsh /usr/bin/yppasswd /usr/games/ 
/usr/include/altq/
 /usr/include/bluetooth.h /usr/include/bsm/ /usr/include/cam/ 
/usr/include/camlib.h
 /usr/include/dev/ /usr/include/fs/ /usr/include/geom/ /usr/include/isofs/
 /usr/include/libatm.h /usr/include/libgeom.h /usr/include/libufs.h
 /usr/include/net80211/ /usr/include/netatalk/ /usr/include/netatm/
 /usr/include/netnatm/ /usr/include/netncp/ /usr/include/pcap-int.h
 /usr/include/pcap-namedb.h /usr/include/pcap.h /usr/include/pccard/
 /usr/include/ufs/ /usr/lib/libatm.a /usr/lib/libatm.so /usr/lib/libatm_p.so
 /usr/lib/libbluetooth.a /usr/lib/libbluetooth.so /usr/lib/libbluetooth.so.2
 /usr/lib/libbluetooth_p.a /usr/lib/libbluetooth_p.so /usr/lib/libcam.a
 /usr/lib/libcam.so /usr/lib/libcam_p.a /usr/lib/libgeom.a /usr/lib/libgeom.so
 /usr/lib/libgeom_p.a /usr/lib/libncp.a /usr/lib/libncp.so /usr/lib/libncp.so.2
 /usr/lib/libncp_p.a /usr/lib/libngatm.a /usr/lib/libngatm.so 
/usr/lib/libngatm.so.2
 /usr/lib/libngatm_p.a /usr/lib/libpcap.a /usr/lib/libpcap.so

Re: mount_smbfs(8): support for SMBv3.02?

2016-03-08 Thread Gary Palmer 
On Tue, Mar 08, 2016 at 06:59:54PM +0100, Kurt Jaeger wrote:
> Hi!
> 
> > Indeed.  Both Solaris and OS X have SMB2 implementations.  If
> > anyone is interested in working on this, then the Apple implementation
> > may provide some inspiration:
> > 
> > http://www.opensource.apple.com/source/smb/
> 
> Is there any way to download this as tgz or something ?
> 
> It looks painful to get it from that site.

http://www.opensource.apple.com/tarballs/smb/

Note that if you poke around you'll find that the SMB code is
no longer used in the latest OSX (10.11).  Not entirely sure what
it is replaced with currently

Gary
___
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: mount_smbfs(8): support for SMBv3.02?

2016-03-08 Thread David Chisnall 
On 8 Mar 2016, at 17:59, Kurt Jaeger  wrote:
> 
>> Indeed.  Both Solaris and OS X have SMB2 implementations.  If
>> anyone is interested in working on this, then the Apple implementation
>> may provide some inspiration:
>> 
>> http://www.opensource.apple.com/source/smb/
> 
> Is there any way to download this as tgz or something ?
> 
> It looks painful to get it from that site.

Tarballs are here:

http://www.opensource.apple.com/tarballs/smb/

Latest one is here:

http://www.opensource.apple.com/tarballs/smb/smb-759.40.1.tar.gz

David

___
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] packaging the base system with pkg(8)

2016-03-08 Thread Slawa Olhovchenkov 
On Tue, Mar 08, 2016 at 05:35:59PM +, David Chisnall wrote:

> On 8 Mar 2016, at 15:14, Slawa Olhovchenkov  wrote:
> > 
> > Yes, I undertund this. But what profit of this? Addtional size is
> > small, many small packages is bad. We already have expirense with
> > spliting Xorg to many small packages -- no profit of this.
> 
> The X.org case is similar, but not quite the same.  The X.org split
> was to ease development, but came at a cost of packaging because you
> almost always want all of X (or, at least, most of it - there are a
> few things such as Xephyr that many users may want to skip).

IMHO, for FreeBSD is same. Except embeded systems. But for embeded
systems, after custom kernel and cut off clang next cut off is pkg:
10MB install size and 50MB database size:

% pkg query -a "%n %sb" | grep pkg
pkg 3058

% ls -lh /var/db/pkg/
total 29707
-rw-r--r--  1 root  wheel   246B Mar  4 22:25 FreeBSD-base.meta
-rw-r--r--  1 root  wheel   246B Mar  4 22:26 FreeBSD.meta
-rw-r--r--  1 root  wheel   5.0M Mar  4 22:28 local.sqlite
-rw-r--r--  1 root  wheel   811K Mar  4 22:25 repo-FreeBSD-base.sqlite
-rw-r--r--  1 root  wheel43M Mar  4 22:26 repo-FreeBSD.sqlite
-r--r--r--  1 root  wheel   4.0M Mar  7 03:46 vuln.xml

> In FreeBSD, we *do* have a compelling case for installing a small
> subset of the base system: service jails (or ‘containerised
> applications’ as the kids are calling them).  We want to be able to
> install, for example, owncloud and nginx or ejabberd in a jail with
> only the bare minimum required for them to start and run.  We want
> updates to these jails to be fast and we want disk usage (and
> install time) to be low.  In such a jail, I want a shell, the parts
> of sbin needed to do network setup, the libraries that these ports
> depend on, *and nothing else*.  We’re still a way away from doing
> that.

From one side, you don't need network setup in jail at all: all
network setup can be done by external tools. You also can absent shell
and manage jail as subdir. 

From other side, detaching jail to other admin and managing it inside
you need many tools for processing logs, network startup script used
cut, sed, dd and any random (at current point) stuff. I am don't see
correct depends for startup scripts now and this is to complex work. 

From thrid side, using ZFS and cloning can eliminate overhead of
duplicating.

> Comparing the installed sets can be simplified with some
> improvements to the pkg UI, for example allowing a set of packages
> to be aggregated into a single entry.  This is not quite the same as
> the metapackage concept.  If you install everything, then a
> FreeBSD-base-all metapackage might show up as a single thing unless
> you ask for a verbose output.  We can also present these in a
> hierarchical manner, so that you can drill down and see more detail
> if you want to.

Next problem is:

1. install some packages.
2. adding missed packages to FreeBSD-base-all
3. Don't see FreeBSD-base-all, but see 750 separated packages

Or:

1. install FreeBSD-base-all
2. remove some packages
3. What I see?

> In terms of comparing packages, if you’re doing that visually then
> you are likely to have problems anyway, unless your eyes and brain
> work far better than most humans.  We can make that much easier by
> providing libxo output in pkg and allowing you to have a simple jq
> script that tells you what the differences are.

In case of 500-1000 packages -- yes, you right.
In case of 5-10 base packages -- eyes is enought.
I am don't need to have utility to comparing and sepeartely installed
reference system for discovering problematic system.
Less separeted packages, more unification in all installed system --
easy to support for me and on any forum for newbies.
___
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: mount_smbfs(8): support for SMBv3.02?

2016-03-08 Thread Kurt Jaeger 
Hi!

> Indeed.  Both Solaris and OS X have SMB2 implementations.  If
> anyone is interested in working on this, then the Apple implementation
> may provide some inspiration:
> 
> http://www.opensource.apple.com/source/smb/

Is there any way to download this as tgz or something ?

It looks painful to get it from that site.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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] packaging the base system with pkg(8)

2016-03-08 Thread David Chisnall 
On 8 Mar 2016, at 15:14, Slawa Olhovchenkov  wrote:
> 
> Yes, I undertund this. But what profit of this? Addtional size is
> small, many small packages is bad. We already have expirense with
> spliting Xorg to many small packages -- no profit of this.

The X.org case is similar, but not quite the same.  The X.org split was to ease 
development, but came at a cost of packaging because you almost always want all 
of X (or, at least, most of it - there are a few things such as Xephyr that 
many users may want to skip).

In FreeBSD, we *do* have a compelling case for installing a small subset of the 
base system: service jails (or ‘containerised applications’ as the kids are 
calling them).  We want to be able to install, for example, owncloud and nginx 
or ejabberd in a jail with only the bare minimum required for them to start and 
run.  We want updates to these jails to be fast and we want disk usage (and 
install time) to be low.  In such a jail, I want a shell, the parts of sbin 
needed to do network setup, the libraries that these ports depend on, *and 
nothing else*.  We’re still a way away from doing that.

Comparing the installed sets can be simplified with some improvements to the 
pkg UI, for example allowing a set of packages to be aggregated into a single 
entry.  This is not quite the same as the metapackage concept.  If you install 
everything, then a FreeBSD-base-all metapackage might show up as a single thing 
unless you ask for a verbose output.  We can also present these in a 
hierarchical manner, so that you can drill down and see more detail if you want 
to.

In terms of comparing packages, if you’re doing that visually then you are 
likely to have problems anyway, unless your eyes and brain work far better than 
most humans.  We can make that much easier by providing libxo output in pkg and 
allowing you to have a simple jq script that tells you what the differences are.

David

___
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: lldb input issue

2016-03-08 Thread Roman Bogorodskiy 
  Pedro Giffuni wrote:

> On 03/06/16 15:20, Pedro Giffuni wrote:
> >
> >
> > El 06/03/2016 a las 15:05, Baptiste Daroussin escribió:
> >> On Sun, Mar 06, 2016 at 10:55:27PM +0300, Roman Bogorodskiy wrote:
> >>>Baptiste Daroussin wrote:
> >>>
>  On Sun, Mar 06, 2016 at 07:44:34PM +0300, Roman Bogorodskiy wrote:
> > Hi,
> >
> > I'm seeing an issue with lldb: when I start it (without arguments) and
> > try to type commands, it looks like this:
> >
> > $  lldb
> > (lldb) \U+7F68\U+7F65\U+7F6C\U+7F70\U+7F0A
> >
> > So, basically, I cannot execute any command and cannot even exit from
> > its shell, only by ctrl-z and killing it.
> >
> > This happens to me on today's -CURRENT / amd64.
> >
> > I was wondering if that's an issue with my user's locale, but the
> > behavior is same for root.
> >
> > Also, I can see exactly the same behavior with lldb on FreeBSD.
> >>> ^^^
> >>> Oops, that's supposed to be 'freefall'.
> >>>
> > Is that some known issue or maybe configuration problem?
> >
> > Thanks,
> >
> > Roman Bogorodskiy
> 
> 
>  Sounds like an issue with libedit, probably due to the latest import
>  of libedit
>  (just a guess)
> >>> It could be. BTW, I've installed lldb38 using pkg and it works fine.
> >>>
> >> Which is linked to libedit from ports (older that in base) so it seems
> >> to prove
> >> that libedit update might be the issue there.
> >
> > Hmm ... most of the changes were cosmetical. I will take a look though.
> >
> 
> Actually we have had two updates lately with sufficient changes that it
> is not easy to find which may be the culprit. I will revert the last
> change in the hope that it is enough.
> 
> Sorry about this.

Thanks, appears it fixed the issue.

Roman Bogorodskiy


signature.asc
Description: PGP signature

Re: [CFT] packaging the base system with pkg(8)

2016-03-08 Thread Slawa Olhovchenkov 
On Tue, Mar 08, 2016 at 02:39:24PM +0100, Miroslav Lachman wrote:

> Glen Barber wrote on 03/08/2016 14:18:
> > On Tue, Mar 08, 2016 at 03:40:16PM +0300, Slawa Olhovchenkov wrote:
> 
> [...]
> 
> >> Packaging of individual utilites is useless (total 19MB vs
> >> 30.7+2.8+20.7+2.9) and incorrect (for example, WITHOUT_ACCT not only
> >> don't build accton/lastcomm/sa but also cut off accaunting code from
> >> kernel for space saving and perforamce).
> >>
> >
> > Packaging individual utilities is not useless, depending on who you ask.
> > One of the first replies I received when starting separating userland
> > utilities into separate packages was further splitting rwho(1) and
> > rwhod(8) into different packages, the use case being not necessarily
> > needing (or wanting) the rwho(1) utility on systems where rwhod(8) runs.
> 
> I didn't tried pkg base yet but I read posts on mailinglist. I 
> understand the need of separating and splitting on the one side and I 
> understand the fear of too long list of packages when one need to do 
> some maintenance (update or upgrade). So one idea come to my mind - what 
> about some meta-packages like "utilities, kernel, libs32, debug" hiding 
> all details about real packages if there are some env variable or 
> command line switch turned on?
> Meta-packages is used in current ports for things like PHP extensions. 
> These ports meta-packages are not hiding real packages so this can be 
> improved for base packages.

Complexly not only in long list of packages:
- comparing two list from different setups
- checking for missing of install some packages
- checking for installed additional packages
- depends calculating (not all host run on power hardware, I am use
VIA C3, for example)

All of this don't resolving by meta-packages.

> It is just a quick idea how to satisfy both sides ;)
> 
> Miroslav Lachman
> 
___
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] packaging the base system with pkg(8)

2016-03-08 Thread Slawa Olhovchenkov 
On Tue, Mar 08, 2016 at 01:18:47PM +, Glen Barber wrote:

> On Tue, Mar 08, 2016 at 03:40:16PM +0300, Slawa Olhovchenkov wrote:
> > On Wed, Mar 02, 2016 at 11:54:29PM +, Glen Barber wrote:
> > 
> > > To obtain the sources for testing, please use the projects/release-pkg
> > > branch:
> > > 
> > >  # svn co svn://svn.freebsd.org/base/projects/release-pkg /usr/src
> > > 
> > > The projects/release-pkg branch is (at this time) in sync with head
> > > revision r296327.
> > > 
> > > After checking out the project branch, build the userland and kernel as
> > > normal with the 'buildworld' and 'buildkernel' targets.  Afterward,
> > > packages can be created with the 'packages' target.
> > > 
> > >  # cd /usr/src
> > >  # make [make flags] buildworld
> > >  # make [make flags] buildkernel
> > >  # make packages
> > > 
> > > At present, the base system consists of 755 packages with the default
> > > build (empty src.conf(5) and make.conf(5)) for amd64.  The number of
> > > packages depends on several factors, but for most cases a runtime binary
> > > is split into several components.  In particular, most shared libraries
> > > are individually packaged, in addition to debugging symbols, profiling
> > > libraries, and 32-bit packaged separately.
> > > 
> > > The package repository will be created within /usr/obj/usr/src/repo by
> > > default.
> > 
> > I am get snapshot .iso for install test setup in VirtualBox and using
> > projects/release-pkg for sources. After make buildworld buildkernel
> > packages and pkg install '*' I am have some words.
> > 
> > I am not developer, I am like maintenance services. I am do maintaing
> > systems more ten 20 years, some systems maintainig more ten 10 year
> > continuous, some systems got for maintenance after years unmaintening.
> > All of this give some requirement and vision different from
> > developers. Please, do not reject this!
> > 
> > First, you do collocal work, thanks!
> > 
> > I am don't check all, but already found some stranges:
> > 
> > Package FreeBSD-clibs-development contain /usr/lib/libthr.so,
> > /usr/lib/libedit.so and etc (and same in other packages).
> > 
> 
> Correct.  The libraries in the 'clibs' package must be installed before
> the rest of the system can be safely upgraded, to ensure consistency
> with the core runtime libraries.

You are miss may point: FreeBSD-clibs-development named as optional
package, need for writing some programs (like in linuxes (and I am hate
this spliting)) but contain /usr/lib/libthr.so and /usr/lib/libedit.so
that must be part of runtime/clibs.

> > I am reseach spliting to package and try some aggregation:
> > 
> > NumPkgs  tarSize(MB)  flatSize(MB)  Aggregation
> > 1  30.7102  FreeBSD-kernel-generic-release
> > 1  57.1331  FreeBSD-kernel-generic-debug
> > 1   2.8  5.4FreeBSD-clibs
> > 1   3.5 24  FreeBSD-clibs-development
> > 1   2.4 11  FreeBSD-clibs-debug
> > 1   1.3  9.8FreeBSD-clibs-profile
> > 1  20.7103  FreeBSD-runtime
> > 1   5.9 38.1FreeBSD-development
> > 1   2.9  2.8FreeBSD-runtime-manuals
> > 1  14.9 65  FreeBSD-debug
> > 1   2.2 12.5FreeBSD-profile
> > 1  24.3 93  FreeBSD-clang
> > 1   8.7 66  FreeBSD-clang-debug
> > 11619.0 80  FreeBSD-*
> > 89  3.2 14  FreeBSD-*-development
> > 11012.5 61  FreeBSD-*-debug
> > 85  2.8 13  FreeBSD-*-profile
> > 85  6.0 18  FreeBSD-*-lib32-*
> > 88  7.4 30  FreeBSD-*-lib32-development
> > 84 11.6 43  FreeBSD-*-lib32-debug
> > 85  5.8 24  FreeBSD-*-lib32-profile
> > 
> > I.e -development is substantially less of main package and don't need
> > separatly (and many .so incorrectly packaging into -development).
> > Same as -profile vs -debug (and -profile useless w/o -debug).
> > 
> 
> Regarding the .so files, I am not clear on the original intent behind
> separating the actual shared library from the installed symbolic link to
> the real shared library, but in my investigation into this, only the
> symlinks are provided by the '-development' package.

OK, this is may fault about incorrect size estimation, but why we miss
this links w/o installing '-development' packages?

> Regarding '-profile' and '-debug' package separation, it is possible to
> install the debugging files without requiring the profiling libraries
> now, so I think keeping them as separate packages is the best way to
> achieve this.  (Note, profiling libraries will not be installed with
> WITHOUT_PROFILE=1 in src.conf(5)).

Yes, I undertund this. But what profit of this? Addtional size is
small, many small packages is bad. We already have expirense with
spliting

Re: mount_smbfs(8): support for SMBv3.02?

2016-03-08 Thread David Chisnall 
On 8 Mar 2016, at 13:19, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> It would be really nice if somebody can bring better support for FreeBSD's 
> SMB/CIFS mount. Maybe through FreeBSD Foundation projects.

Indeed.  Both Solaris and OS X have SMB2 implementations.  If anyone is 
interested in working on this, then the Apple implementation may provide some 
inspiration:

http://www.opensource.apple.com/source/smb/

David

___
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_amd64_gcc4.9 - Build #1119 - Still Failing

2016-03-08 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc4.9 - Build #1119 - Still Failing:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1119/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1119/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1119/console

Change summaries:

296494 by np:
cxgbe(4): Many new functions in the shared code, unused at this time.

Obtained from:  Chelsio Communications

296493 by np:
cxgbe(4): Use t4_link_down_rc_str in shared code to decode the reason
the link is down, instead of doing it in OS specific code.

296492 by sgalabov:
Add MIPS_INTRNG to sys/conf/options.mips

This was somehow missed in the commit of
https://reviews.freebsd.org/D5182
although it was in the original diff submitted for review.

Approved by:adrian (mentor)
Differential Revision:  https://reviews.freebsd.org/D5568

296491 by np:
cxgbe(4): Updates to shared routines that get/set various parameters via
the firmware.

Obtained from:  Chelsio Communications

296490 by np:
cxgbe(4): Remove __devinit and SPEED_ as part of catch up with
internal shared code.

Obtained from:  Chelsio Communications

296489 by np:
cxgbe(4): Updates to the shared routines that deal with the serial EEPROM,
flash, and VPD.

Obtained from:  Chelsio Communications

296488 by np:
cxgbe(4): Updates to mailbox routines in the shared code.

Obtained from:  Chelsio Communications

296485 by np:
cxgbe(4): Update the interrupt handlers for hardware errors.

Obtained from:  Chelsio Communications

296481 by np:
cxgbe(4): Overhaul the shared code that deals with the chip's TP block,
which is responsible for filtering and RSS.

Add the ability to use filters that match on PF/VF (aka "VNIC id") while
here.  This is mutually exclusive with filtering on outer VLAN tag with
Q-in-Q.

Sponsored by:   Chelsio Communications

296480 by markj:
Fix a couple of silly mistakes in r291962.

- Handle the case where no DOF helper is provided. This occurs with the
  currently-unused DTRACEHIOC_ADD ioctl.
- Fix some checks that prevented the loading DOF in the (non-default)
  lazyload mode.

296479 by markj:
Fix fasttrap tracepoint locking.

Upstream, tracepoints are protected by per-CPU mutexes. An unlinked
tracepoint may be freed once all the tracepoint mutexes have been acquired
and released - this is done in fasttrap_mod_barrier(). This mechanism was
not properly ported: in some places, the proc lock is used in place of a
tracepoint lock, and in others the locking is omitted entirely. This change
implements tracepoint locking with an rmlock, where the read lock is used
in fasttrap probe context. As a side effect, this fixes a recursion on the
proc lock when the raise action is used from a userland probe.

MFC after:  1 month

296478 by np:
cxgbe(4): Add a struct sge_params to store per-adapter SGE parameters.
Move the code that reads all the parameters to t4_init_sge_params in the
shared code.  Use these per-adapter values instead of globals.

Sponsored by:   Chelsio Communications

296477 by markj:
Remove the fasttrap implementation for sparc.

Other machine-dependent code required for DTrace on sparc is not present in
the tree, so there's no point to keeping the fasttrap code.

296476 by rrs:
Fix a sneaky bug where we were missing an extern
to get the rxt threshold.. and thus created our own defaulted to 0 :-(

Sponsored by:   Netflix Inc

296475 by markj:
MFV r296306: 6604 harden DIF bounds checking

Reviewed by: Alex Wilson 
Reviewed by: Patrick Mooney 
Reviewed by: Dan McDonald 
Approved by: Robert Mustacchi 
Author: Bryan Cantrill 

illumos/illumos-gate@1c0cef67dba05c477dba779bc99224693e809a14

MFC after:  2 weeks

296474 by emaste:
libc/{i386,amd64}: Do not export .cerror when building WITHOUT_SYMVER

Further to r240152 (i386) and r240178 (amd64), hide the .cerror symbol
so that it is not exported if symbol versioning is not in use.  Without
this change WITHOUT_SYMVER libc contains .text relocations for .cerror,
as described in LLVM PR 26813 (http://llvm.org/pr26813).

This is a no-op for the regular build as the symbol version script
already controls .cerror visibility.

PR: 207712
Submitted by:   Rafael Espíndola
Reviewed by:jilles, kib
Differential Revision:  https://reviews.freebsd.org/D5571

296473 by bdrewery:
Add missing break for r296472.

This was lost in git rebasing, though it has no functional change.

X-MFC-With: r296472
MFC after:  1 week

296472 by bdrewery:
Require kldunload -f to unload.

Code may still be executing from the wrappers at unload time and thus is
not generally safe to unload.  Converting the wrappers to use
EVENTHANDLER(9) will allow this to safely drain on active threads in
hooks.  More work on EVENTHANDLER(9) is needed first.

MFC after:  1 week
Sponsored by:   EMC / Isilon Storage Division

296471 by np:

Re: [CFT] packaging the base system with pkg(8)

2016-03-08 Thread Miroslav Lachman 

Glen Barber wrote on 03/08/2016 14:18:

On Tue, Mar 08, 2016 at 03:40:16PM +0300, Slawa Olhovchenkov wrote:


[...]


Packaging of individual utilites is useless (total 19MB vs
30.7+2.8+20.7+2.9) and incorrect (for example, WITHOUT_ACCT not only
don't build accton/lastcomm/sa but also cut off accaunting code from
kernel for space saving and perforamce).



Packaging individual utilities is not useless, depending on who you ask.
One of the first replies I received when starting separating userland
utilities into separate packages was further splitting rwho(1) and
rwhod(8) into different packages, the use case being not necessarily
needing (or wanting) the rwho(1) utility on systems where rwhod(8) runs.


I didn't tried pkg base yet but I read posts on mailinglist. I 
understand the need of separating and splitting on the one side and I 
understand the fear of too long list of packages when one need to do 
some maintenance (update or upgrade). So one idea come to my mind - what 
about some meta-packages like "utilities, kernel, libs32, debug" hiding 
all details about real packages if there are some env variable or 
command line switch turned on?
Meta-packages is used in current ports for things like PHP extensions. 
These ports meta-packages are not hiding real packages so this can be 
improved for base packages.


It is just a quick idea how to satisfy both sides ;)

Miroslav Lachman

___
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: mount_smbfs(8): support for SMBv3.02?

2016-03-08 Thread Miroslav Lachman 

O. Hartmann wrote on 03/08/2016 13:53:

On Tue, 8 Mar 2016 10:55:25 +0100
Edward Tomasz Napierała  wrote:


On 0303T1047, O. Hartmann wrote:

Does FreeBSD's mount_smbfs(8) support for Microsoft's SMBv3 protocol
introduced with Windows 8 and Windows Server 2012/R2?


No, it only supports the obsolete SMB1 (aka CIFS) protocol.  Since SMB2
is a completely different protocol, supporting it properly pretty much
requires implementing it from scratch.  SMB3 is one of the SMB2 revisions
and thus is backward compatible with SMB2.


[...]

Thank you very much for this clearification. This explains much strange
behaviour I faced.

Do you see any chance that this gets fixed in a forseable time? Linux seems to
support SMBv3 by now. Or is a support considered obsolete and handled
via /net/samba43?


I am not a FreeBSD expert but I am using mount_smbfs - with some 
troubles for a long time. The code base is really old and not well 
maintained. There are/were many problems with charset conversions etc.
And there is no mount_smbfs in net/sambaXY packages AFAIK (smbclient is 
not an option in our environment were we need to access SMB mounted 
files from 3rd party PHP web applications)


It would be really nice if somebody can bring better support for 
FreeBSD's SMB/CIFS mount. Maybe through FreeBSD Foundation projects.



For a security appliance, I try to avoid as much packages as possible, so
therefore my concerns regarding mount_smbfs.


I can use packages but there is none with mount ability of SMB/CIFS or I 
don't know about it.


Miroslav Lachman
___
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] packaging the base system with pkg(8)

2016-03-08 Thread Glen Barber 
On Tue, Mar 08, 2016 at 03:40:16PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Mar 02, 2016 at 11:54:29PM +, Glen Barber wrote:
> 
> > To obtain the sources for testing, please use the projects/release-pkg
> > branch:
> > 
> >  # svn co svn://svn.freebsd.org/base/projects/release-pkg /usr/src
> > 
> > The projects/release-pkg branch is (at this time) in sync with head
> > revision r296327.
> > 
> > After checking out the project branch, build the userland and kernel as
> > normal with the 'buildworld' and 'buildkernel' targets.  Afterward,
> > packages can be created with the 'packages' target.
> > 
> >  # cd /usr/src
> >  # make [make flags] buildworld
> >  # make [make flags] buildkernel
> >  # make packages
> > 
> > At present, the base system consists of 755 packages with the default
> > build (empty src.conf(5) and make.conf(5)) for amd64.  The number of
> > packages depends on several factors, but for most cases a runtime binary
> > is split into several components.  In particular, most shared libraries
> > are individually packaged, in addition to debugging symbols, profiling
> > libraries, and 32-bit packaged separately.
> > 
> > The package repository will be created within /usr/obj/usr/src/repo by
> > default.
> 
> I am get snapshot .iso for install test setup in VirtualBox and using
> projects/release-pkg for sources. After make buildworld buildkernel
> packages and pkg install '*' I am have some words.
> 
> I am not developer, I am like maintenance services. I am do maintaing
> systems more ten 20 years, some systems maintainig more ten 10 year
> continuous, some systems got for maintenance after years unmaintening.
> All of this give some requirement and vision different from
> developers. Please, do not reject this!
> 
> First, you do collocal work, thanks!
> 
> I am don't check all, but already found some stranges:
> 
> Package FreeBSD-clibs-development contain /usr/lib/libthr.so,
> /usr/lib/libedit.so and etc (and same in other packages).
> 

Correct.  The libraries in the 'clibs' package must be installed before
the rest of the system can be safely upgraded, to ensure consistency
with the core runtime libraries.

> Misspeling FreeBSD-debug, FreeBSD-development and FreeBSD-profile as
> FreeBSD-runtime-debug, FreeBSD-runtime-development and 
> FreeBSD-runtime-profile?
> 

I am not sure why this was originally named as they are, but this can be
fixed.

> I am reseach spliting to package and try some aggregation:
> 
> NumPkgs  tarSize(MB)  flatSize(MB)  Aggregation
> 1  30.7102  FreeBSD-kernel-generic-release
> 1  57.1331  FreeBSD-kernel-generic-debug
> 1   2.8  5.4FreeBSD-clibs
> 1 3.5 24  FreeBSD-clibs-development
> 1   2.4   11  FreeBSD-clibs-debug
> 1 1.3  9.8FreeBSD-clibs-profile
> 1  20.7  103  FreeBSD-runtime
> 1 5.9 38.1FreeBSD-development
> 1 2.9  2.8FreeBSD-runtime-manuals
> 114.9 65  FreeBSD-debug
> 1 2.2 12.5FreeBSD-profile
> 124.3 93  FreeBSD-clang
> 1 8.7 66  FreeBSD-clang-debug
> 116  19.0 80  FreeBSD-*
> 893.2 14  FreeBSD-*-development
> 110  12.5 61  FreeBSD-*-debug
> 852.8 13  FreeBSD-*-profile
> 856.0 18  FreeBSD-*-lib32-*
> 887.4 30  FreeBSD-*-lib32-development
> 84   11.6 43  FreeBSD-*-lib32-debug
> 855.8 24  FreeBSD-*-lib32-profile
> 
> I.e -development is substantially less of main package and don't need
> separatly (and many .so incorrectly packaging into -development).
> Same as -profile vs -debug (and -profile useless w/o -debug).
> 

Regarding the .so files, I am not clear on the original intent behind
separating the actual shared library from the installed symbolic link to
the real shared library, but in my investigation into this, only the
symlinks are provided by the '-development' package.

For example:

 root@pkgbase:/ # file /usr/lib/libjail.so
 /usr/lib/libjail.so: symbolic link to ../../lib/libjail.so.1
 root@pkgbase:/ # pkg shlib libjail.so
 No packages provide libjail.so.
 No packages require libjail.so.
 root@pkgbase:/ # pkg shlib libjail.so.1
 libjail.so.1 is provided by the following packages:
 FreeBSD-jail-11.0.s20160303044402
 FreeBSD-jail-lib32-11.0.s20160303044402
 libjail.so.1 is linked to by the following packages:
 FreeBSD-runtime-11.0.s20160303044402

Moving them to the package that installs the shared library itself
should be fairly easy to do.

Regarding '-profile' and '-debug' package separation, it is possible to
install the debugging files without requiring the profiling libraries
now, so I think keeping them as separate packages is the best way

Re: mount_smbfs(8): support for SMBv3.02?

2016-03-08 Thread O. Hartmann 
On Tue, 8 Mar 2016 10:55:25 +0100
Edward Tomasz Napierała  wrote:

> On 0303T1047, O. Hartmann wrote:
> > Does FreeBSD's mount_smbfs(8) support for Microsoft's SMBv3 protocol
> > introduced with Windows 8 and Windows Server 2012/R2?  
> 
> No, it only supports the obsolete SMB1 (aka CIFS) protocol.  Since SMB2
> is a completely different protocol, supporting it properly pretty much
> requires implementing it from scratch.  SMB3 is one of the SMB2 revisions
> and thus is backward compatible with SMB2.
> 
[...]

Thank you very much for this clearification. This explains much strange
behaviour I faced.

Do you see any chance that this gets fixed in a forseable time? Linux seems to
support SMBv3 by now. Or is a support considered obsolete and handled
via /net/samba43?

For a security appliance, I try to avoid as much packages as possible, so
therefore my concerns regarding mount_smbfs.

Thanks you very much,

O. Hartmann

___
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] packaging the base system with pkg(8)

2016-03-08 Thread Slawa Olhovchenkov 
On Wed, Mar 02, 2016 at 11:54:29PM +, Glen Barber wrote:

> To obtain the sources for testing, please use the projects/release-pkg
> branch:
> 
>  # svn co svn://svn.freebsd.org/base/projects/release-pkg /usr/src
> 
> The projects/release-pkg branch is (at this time) in sync with head
> revision r296327.
> 
> After checking out the project branch, build the userland and kernel as
> normal with the 'buildworld' and 'buildkernel' targets.  Afterward,
> packages can be created with the 'packages' target.
> 
>  # cd /usr/src
>  # make [make flags] buildworld
>  # make [make flags] buildkernel
>  # make packages
> 
> At present, the base system consists of 755 packages with the default
> build (empty src.conf(5) and make.conf(5)) for amd64.  The number of
> packages depends on several factors, but for most cases a runtime binary
> is split into several components.  In particular, most shared libraries
> are individually packaged, in addition to debugging symbols, profiling
> libraries, and 32-bit packaged separately.
> 
> The package repository will be created within /usr/obj/usr/src/repo by
> default.

I am get snapshot .iso for install test setup in VirtualBox and using
projects/release-pkg for sources. After make buildworld buildkernel
packages and pkg install '*' I am have some words.

I am not developer, I am like maintenance services. I am do maintaing
systems more ten 20 years, some systems maintainig more ten 10 year
continuous, some systems got for maintenance after years unmaintening.
All of this give some requirement and vision different from
developers. Please, do not reject this!

First, you do collocal work, thanks!

I am don't check all, but already found some stranges:

Package FreeBSD-clibs-development contain /usr/lib/libthr.so,
/usr/lib/libedit.so and etc (and same in other packages).

Misspeling FreeBSD-debug, FreeBSD-development and FreeBSD-profile as
FreeBSD-runtime-debug, FreeBSD-runtime-development and FreeBSD-runtime-profile?

I am reseach spliting to package and try some aggregation:

NumPkgs  tarSize(MB)  flatSize(MB)  Aggregation
1  30.7102  FreeBSD-kernel-generic-release
1  57.1331  FreeBSD-kernel-generic-debug
1   2.8  5.4FreeBSD-clibs
1   3.5 24  FreeBSD-clibs-development
1   2.4 11  FreeBSD-clibs-debug
1   1.3  9.8FreeBSD-clibs-profile
1  20.7103  FreeBSD-runtime
1   5.9 38.1FreeBSD-development
1   2.9  2.8FreeBSD-runtime-manuals
1  14.9 65  FreeBSD-debug
1   2.2 12.5FreeBSD-profile
1  24.3 93  FreeBSD-clang
1   8.7 66  FreeBSD-clang-debug
11619.0 80  FreeBSD-*
89  3.2 14  FreeBSD-*-development
11012.5 61  FreeBSD-*-debug
85  2.8 13  FreeBSD-*-profile
85  6.0 18  FreeBSD-*-lib32-*
88  7.4 30  FreeBSD-*-lib32-development
84 11.6 43  FreeBSD-*-lib32-debug
85  5.8 24  FreeBSD-*-lib32-profile

I.e -development is substantially less of main package and don't need
separatly (and many .so incorrectly packaging into -development).
Same as -profile vs -debug (and -profile useless w/o -debug).

Manual must be installed always, IMHO (size is small and version of
manual must matcj version of utility).

Packaging of individual utilites is useless (total 19MB vs
30.7+2.8+20.7+2.9) and incorrect (for example, WITHOUT_ACCT not only
don't build accton/lastcomm/sa but also cut off accaunting code from
kernel for space saving and perforamce).

I am propose don't distinct profile and debug, development and main
package.

I am propose divide only to FreeBSD-kernel, FreeBSD-clibs (clibs,
runtime and manuals), FreeBSD-clang, FreeBSD-lib32.

Dividing to many packages is anoyning on install and maintancing (what
exact keys of this utilites this version?! stupid admin don't install
manuals!)

About use cases. I am try to imagine different use cases and don't
found answer how do this:

1. package building as `make packages` witch version as timestamp of
start buildworld. I.e. on every buildworld every package will be
rebuild, take new version and will be reinstaled. Where is profit of
package spliting?

2. After src.conf change some package don't build. Where analog of
`make delete-old delete-old-libs`?

3. After src.conf chanege some (WITHOUT_ACCT for example) some
packages can't be installed. How handle this?

4. How install debug symbols after installing separately set of
packages? Not all *-debug*- and don't selecting all 200 packages
individualy?

5. Take system installed by unknow person (ex: ISP support 5 years
ago). Try to write program. Don't find nothing for this. Version is
11.0-BETA3. How to

Re: mount_smbfs(8): support for SMBv3.02?

2016-03-08 Thread Edward Tomasz Napierała 
On 0303T1047, O. Hartmann wrote:
> Does FreeBSD's mount_smbfs(8) support for Microsoft's SMBv3 protocol 
> introduced
> with Windows 8 and Windows Server 2012/R2?

No, it only supports the obsolete SMB1 (aka CIFS) protocol.  Since SMB2
is a completely different protocol, supporting it properly pretty much
requires implementing it from scratch.  SMB3 is one of the SMB2 revisions
and thus is backward compatible with SMB2.

___
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"