Re: date(1) default format changed between 10.3 and 11.0-BETA3
On 2016-08-06 21:08, Julian Elischer wrote: On 6/08/2016 11:09 PM, Benjamin Kaduk wrote: On Sat, 6 Aug 2016, Baptiste Daroussin wrote: On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote: On Friday, 5 August 2016 at 18:56:33 +0300, Andrey A. Chernov wrote: On 05.08.2016 18:44, Mark Martinec wrote: On 2016-08-05 17:23, Andrey Chernov wrote: POSIX does say that the default format should be the same as with "+%a %b %e %H:%M:%S %Z %Y". It also says that %a and %b are locale's abbreviated names. It is true for _POSIX_ locale only, as I already say. en_US.* is not POSIX or C locale. It still violates POLA. I really do not think that it violates POLA fiven that the behaviour you are expecting is still available in the default configurtion that is still POSIX. Regardless, at a new major release is precisely when it is permissible to break POLA. switching from short form to long form is more than a POLA.. short form has a specific fixed layout and feeding a long form string into it will break things. Set LC_TIME to C and then you are back on your behaviour (and this is the default when you install FreeBSD). locales should be seen as tzdata for exemple, they are a moving target complicated to handle for every locale we do support: 78 for 11.0-RELEASE and 193 if we do count the encoding variants. locales are updated very often (for exemple cldr unicode make a new release of the data every 8 month or so) As I understand it, your change will improve the maintainability of locales in FreeBSD in the future, which justifies a POLA break at the release boundary. -Ben $ LC_ALL=en_US.UTF-8 date FreeBSD 11.0-BETA3 : Friday, August 5, 2016 at 03:20:25 PM CEST FreeBSD 10.3-RELEASE-p6 : Fri Aug 5 15:15:11 CEST 2016 OSX version 10.9.5 : Fri Aug 5 14:57:14 CEST 2016 Fedora Linux 4.6.4-301.fc24.x86_64 : Fri Aug 5 15:10:40 CEST 2016 Debian 8.0 / Linux 4.4.16-v7+ : Fri Aug 5 15:25:49 CEST 2016 It's not just long vs. short forms of a name, it is also the order of fields, their separators, and a 12/24h time form that is different from everyone else and from what we used to have in 10.3. Is it really worth being different? I wonder how many ad-hoc scripts will break. Although as Andrey Chernov correctly noted that the date(1) specs in The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition ( http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html ) says that the default format applies to POSIX locale only: STDOUT When no formatting operand is specified, the output in the POSIX locale shall be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y" imo, unless there is a very good reason not to, the above default format should be applicable to most locales, but at least to English spoken locales. The explicit locale-dependency of %a, %b, and %Z conversion specifications already takes care of most locale-specific idiosyncrasies. Mark ___ 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 11.0-BETA4 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The fourth BETA build of the 11.0-RELEASE release cycle is now available. Installation images are available for: o 11.0-BETA4 amd64 GENERIC o 11.0-BETA4 i386 GENERIC o 11.0-BETA4 powerpc GENERIC o 11.0-BETA4 powerpc64 GENERIC64 o 11.0-BETA4 sparc64 GENERIC o 11.0-BETA4 armv6 BANANAPI o 11.0-BETA4 armv6 BEAGLEBONE o 11.0-BETA4 armv6 CUBIEBOARD o 11.0-BETA4 armv6 CUBIEBOARD2 o 11.0-BETA4 armv6 CUBOX-HUMMINGBOARD o 11.0-BETA4 armv6 GUMSTIX o 11.0-BETA4 armv6 RPI-B o 11.0-BETA4 armv6 RPI2 o 11.0-BETA4 armv6 PANDABOARD o 11.0-BETA4 armv6 WANDBOARD o 11.0-BETA4 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/11" branch. A summary of changes since 11.0-BETA3 includes: o The mtx_trylock_spin(9) kernel synchronization primitive was added. o The machdep.disable_msix_migration loader tunable has been re-enabled for EC2 AMIs. o The iwm(4) and iwmfw(4) drivers have been updated. o The new system hardening options have been fixed to avoid overwriting other options selected during install time. o Several build-related fixes. o Several miscellaneous bug fixes. A list of changes since 10.0-RELEASE are available on the stable/11 release notes: https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 11.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-BETA4/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-fb65f7ec us-west-1 region: ami-befebede us-west-2 region: ami-4dab632d sa-east-1 region: ami-74dd4b18 eu-west-1 region: ami-6180e912 eu-central-1 region: ami-c940b7a6 ap-northeast-1 region: ami-99f137f8 ap-northeast-2 region: ami-b720ead9 ap-southeast-1 region: ami-9cf22cff ap-southeast-2 region: ami-675d6904 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-BETA4 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 11.0-BETA4 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility
Re: date(1) default format changed between 10.3 and 11.0-BETA3
On 6/08/2016 11:09 PM, Benjamin Kaduk wrote: On Sat, 6 Aug 2016, Baptiste Daroussin wrote: On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote: On Friday, 5 August 2016 at 18:56:33 +0300, Andrey A. Chernov wrote: On 05.08.2016 18:44, Mark Martinec wrote: On 2016-08-05 17:23, Andrey Chernov wrote: POSIX does say that the default format should be the same as with "+%a %b %e %H:%M:%S %Z %Y". It also says that %a and %b are locale's abbreviated names. It is true for _POSIX_ locale only, as I already say. en_US.* is not POSIX or C locale. It still violates POLA. I really do not think that it violates POLA fiven that the behaviour you are expecting is still available in the default configurtion that is still POSIX. Regardless, at a new major release is precisely when it is permissible to break POLA. switching from short form to long form is more than a POLA.. short form has a specific fixed layout and feeding a long form string into it will break things. Set LC_TIME to C and then you are back on your behaviour (and this is the default when you install FreeBSD). locales should be seen as tzdata for exemple, they are a moving target complicated to handle for every locale we do support: 78 for 11.0-RELEASE and 193 if we do count the encoding variants. locales are updated very often (for exemple cldr unicode make a new release of the data every 8 month or so) As I understand it, your change will improve the maintainability of locales in FreeBSD in the future, which justifies a POLA break at the release boundary. -Ben ___ 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: rc scripts new login_class, default can break old rc scripts
Hi! > So my question is this, should old rc scripts adapt to this new default, or > should the default be changed to avoid issues like I just found? There should be a PR about this, and please give it to re (release engineering). -- 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"
rc scripts new login_class, default can break old rc scripts
I recently upgraded one of my boxes to FreeBSD 11 r303750 (beta-3). After
the upgrade I noticed that one of the services would no longer start...
After digging into it, I found that the new var ${name}_login_class var's
defaults to the daemon login class and by default, the daemon class
resource limit on memory is set to 128M. This maybe an issue for old rc
scripts.
So my question is this, should old rc scripts adapt to this new default, or
should the default be changed to avoid issues like I just found? The port
this issue was found is audio/teamspeak3-server. If installed on FreeBSD
11+ it will fail to start with...
2016-08-06 17:07:27.946432|CRITICAL|ServerLibPriv | |Server()
DatabaseError out of memory
Ultima
___
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: date(1) default format changed between 10.3 and 11.0-BETA3
On Sat, 6 Aug 2016, Baptiste Daroussin wrote: > On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote: > > On Friday, 5 August 2016 at 18:56:33 +0300, Andrey A. Chernov wrote: > > > On 05.08.2016 18:44, Mark Martinec wrote: > > >> On 2016-08-05 17:23, Andrey Chernov wrote: > > >> > > >> POSIX does say that the default format should be the same > > >> as with "+%a %b %e %H:%M:%S %Z %Y". > > >> It also says that %a and %b are locale's abbreviated names. > > > > > > It is true for _POSIX_ locale only, as I already say. en_US.* is not > > > POSIX or C locale. > > > > It still violates POLA. > > > I really do not think that it violates POLA fiven that the behaviour you are > expecting is still available in the default configurtion that is still POSIX. Regardless, at a new major release is precisely when it is permissible to break POLA. > Set LC_TIME to C and then you are back on your behaviour (and this is the > default when you install FreeBSD). > > locales should be seen as tzdata for exemple, they are a moving target > complicated to handle for every locale we do support: 78 for 11.0-RELEASE and > 193 if we do count the encoding variants. locales are updated very often (for > exemple cldr unicode make a new release of the data every 8 month or so) As I understand it, your change will improve the maintainability of locales in FreeBSD in the future, which justifies a POLA break at the release boundary. -Ben ___ 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: some [big] changes to ZPL (ZFS<->VFS )
On 05/08/2016 23:31, Alan Somers wrote: > I'm not certain it's related, but on a head build at r303767 I see a > LOR and a reproducible panic that involve the snapdir code. Alan, thank you very much for the clear report and for the very easy reproduction scenario. I am not sure how I missed this simple and severe bug. Please try r303791, it should fix the problem. I believe that the LOR is not new and been there since we started using distinct tags for .zfs special vnodes. > First, the LOR: > $ zpool destroy foo > > lock order reversal: > 1st 0xf800404c8b78 zfs (zfs) @ > /usr/home/alans/freebsd/head/sys/kern/vfs_mount.c:1244 > 2nd 0xf800404c85f0 zfs_gfs (zfs_gfs) @ > /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:484 > stack backtrace: > #0 0x80aa90b0 at witness_debugger+0x70 > #1 0x80aa8fa4 at witness_checkorder+0xe54 > #2 0x80a22072 at __lockmgr_args+0x4c2 > #3 0x80af8e7c at vop_stdlock+0x3c > #4 0x81018880 at VOP_LOCK1_APV+0xe0 > #5 0x80b19f2a at _vn_lock+0x9a > #6 0x821b9c53 at gfs_file_create+0x73 > #7 0x821b9cfd at gfs_dir_create+0x1d > #8 0x8228aa07 at zfsctl_mknode_snapdir+0x47 > #9 0x821ba1a5 at gfs_dir_lookup+0x185 > #10 0x821ba68d at gfs_vop_lookup+0x1d > #11 0x82289a42 at zfsctl_root_lookup+0xf2 > #12 0x8228a8c3 at zfsctl_umount_snapshots+0x83 > #13 0x822a1d2b at zfs_umount+0x7b > #14 0x80b02a14 at dounmount+0x6f4 > #15 0x80b0228d at sys_unmount+0x35d > #16 0x80ebbb7b at amd64_syscall+0x2db > #17 0x80e9b72b at Xfast_syscall+0xfb > > > Here's the panic: > $ zpool create testpool da0 > $ touch /testpool/testfile > $ zfs snapshot testpool@testsnap > $ cd /testpool/.zfs/snapshots > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 04 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80b19f1c > stack pointer = 0x28:0xfe0b54bf7430 > frame pointer = 0x28:0xfe0b54bf74a0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 966 (bash) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0b54bf6fc0 > vpanic() at vpanic+0x182/frame 0xfe0b54bf7040 > panic() at panic+0x43/frame 0xfe0b54bf70a0 > trap_fatal() at trap_fatal+0x351/frame 0xfe0b54bf7100 > trap_pfault() at trap_pfault+0x1fd/frame 0xfe0b54bf7160 > trap() at trap+0x284/frame 0xfe0b54bf7370 > calltrap() at calltrap+0x8/frame 0xfe0b54bf7370 > --- trap 0xc, rip = 0x80b19f1c, rsp = 0xfe0b54bf7440, rbp > = 0xfe0b54bf74a0 --- > _vn_lock() at _vn_lock+0x8c/frame 0xfe0b54bf74a0 > zfs_lookup() at zfs_lookup+0x50d/frame 0xfe0b54bf7540 > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfe0b54bf7680 > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfe0b54bf76b0 > vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfe0b54bf7710 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfe0b54bf7740 > lookup() at lookup+0x5a2/frame 0xfe0b54bf77d0 > namei() at namei+0x5b2/frame 0xfe0b54bf7890 > kern_statat() at kern_statat+0xa8/frame 0xfe0b54bf7a40 > sys_stat() at sys_stat+0x2d/frame 0xfe0b54bf7ae0 > amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0b54bf7bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0b54bf7bf0 > > > I can provide core files, test scripts, whatever you need. Thanks for > tackling this difficult problem. > > -Alan > > On Fri, Aug 5, 2016 at 12:36 AM, Andriy Gapon wrote: >> On 03/08/2016 17:25, Andriy Gapon wrote: >>> Another change that was not strictly required and which is probably too >>> intrusive is killing the support for case insensitive operations. My >>> thinking was that FreeBSD VFS does not provide support for those anyway. >>> But I'll probably restore the code, at least in the bottom half of the >>> ZPL, before committing the change. >> >> It turned out that most of the removed code was dead anyway and it took >> just a few lines of code to restore support for case-insensitive >> filesystems. Filesystems with mixed case sensitivity behave exactly the >> same as case-sensitive filesystem as it has always been the case on FreeBSD. >> >> Anyway the big change has just been committed: >> https://svnweb.freebsd.org/changeset/base/303763 >> Please test away. >> >> Another note is that the filesystem name cache is now disabled for case >> insensitive filesystems and filesystems with normalization other than >> none. That may hurt the lookup performance, but should ensure >> correctness of operations. >> >> -- >> Andriy Gapon >> ___
Re: date(1) default format changed between 10.3 and 11.0-BETA3
On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote: > On Friday, 5 August 2016 at 18:56:33 +0300, Andrey A. Chernov wrote: > > On 05.08.2016 18:44, Mark Martinec wrote: > >> On 2016-08-05 17:23, Andrey Chernov wrote: > >>> On 05.08.2016 17:47, Mark Martinec wrote: > [Bug 211598] > date(1) default format in en_EN locale breaks compatibility with 10.3 > and violates POSIX > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598 > >>> > >>> It breaks compatibility but not violates POSIX. POSIX care of only its > >>> own POSIX (or C) locale. > >> > >> POSIX does say that the default format should be the same > >> as with "+%a %b %e %H:%M:%S %Z %Y". > >> It also says that %a and %b are locale's abbreviated names. > > > > It is true for _POSIX_ locale only, as I already say. en_US.* is not > > POSIX or C locale. > > It still violates POLA. > I really do not think that it violates POLA fiven that the behaviour you are expecting is still available in the default configurtion that is still POSIX. Set LC_TIME to C and then you are back on your behaviour (and this is the default when you install FreeBSD). locales should be seen as tzdata for exemple, they are a moving target complicated to handle for every locale we do support: 78 for 11.0-RELEASE and 193 if we do count the encoding variants. locales are updated very often (for exemple cldr unicode make a new release of the data every 8 month or so) No locales defines the same date format and that was already the case before the change we did Now if people have strong arguments for a specific locale I'm inclined to add some hacks in our tool that generates our locales to make sure we fix the upstream data (http://cldr.unicode.org) we already committed some and I'm planning to report upstream (cldr) all the issues we have faced to improve. Best regards, Bapt signature.asc Description: PGP signature
