svn commit: r321783 - head/usr.bin/calendar/calendars
Author: lifanov (ports committer) Date: Mon Jul 31 13:08:47 2017 New Revision: 321783 URL: https://svnweb.freebsd.org/changeset/base/321783 Log: add myself to calendar.freebsd Modified: head/usr.bin/calendar/calendars/calendar.freebsd Modified: head/usr.bin/calendar/calendars/calendar.freebsd == --- head/usr.bin/calendar/calendars/calendar.freebsdMon Jul 31 12:09:24 2017(r321782) +++ head/usr.bin/calendar/calendars/calendar.freebsdMon Jul 31 13:08:47 2017(r321783) @@ -94,6 +94,7 @@ 03/07 Michael P. Pritchard born in Los Angeles, California, United States, 1964 03/07 Giorgos Keramidas born in Athens, Greece, 1976 03/10 Andreas Klemm born in Duesseldorf, Nordrhein-Westfalen, Germany, 1963 +03/10 Nikolai Lifanov born in Moscow, Russian Federation, 1989 03/11 Soeren Straarup born in Andst, Denmark, 1978 03/12 Greg Lewis born in Adelaide, South Australia, Australia, 1969 03/13 Alexander Leidinger born in Neunkirchen, Saarland, Germany, 1976 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318313 - head/libexec/rtld-elf
On 05/15/2017 15:52, Konstantin Belousov wrote: > On Mon, May 15, 2017 at 07:42:23PM +, Alexey Dokuchaev wrote: >> On Mon, May 15, 2017 at 10:40:49PM +0300, Konstantin Belousov wrote: >>> On Mon, May 15, 2017 at 03:37:42PM -0400, Nikolai Lifanov wrote: >>>> On 05/15/2017 15:36, Alexey Dokuchaev wrote: >>>>> ... >>>>> Would this now allow executing binaries (with or without +x bit) from >>>>> filesystems mounted with -o noexec? >>>> >>>> No: >>>> >>>> # zfs create -o mountpoint=/mnt -o exec=off tank/TEST >>>> # cp /bin/sh /mnt/ >>>> # /mnt/sh >>>> /mnt/sh: Permission denied. >>>> # /libexec/ld-elf.so.1 /mnt/sh >>>> /mnt/sh: mmap of data failed: Permission denied >>> >>> This is due to >>> r313967 | kib | 2017-02-19 22:51:04 +0200 (Sun, 19 Feb 2017) | 24 lines >>> Apply noexec mount option for mmap(PROT_EXEC). >> >> Nice, good to know that. > > [Replying to random mail in thread] > > I tried this on an up to date latest Fedora installation: > [kostik@sandy ~]$ cp /bin/ls /tmp > [kostik@sandy ~]$ chmod a-x /tmp/ls > [kostik@sandy ~]$ /lib64/ld-linux-x86-64.so.2 /tmp/ls > Dropbox intel tmp work > > I am not sure about one detail, the /tmp/ls file has some security context > on it, but I do not believe that it may affect the outcome of the experiment. > Please correct me if I am wrong. > This is because /tmp is exec. On Linux it does the same thing: # mount -t tmpfs none -o noexec,mode=1777 /mnt # cp /bin/bash /mnt/ # /lib64/ld-linux-x86-64.so.2 /mnt/bash /mnt/bash: error while loading shared libraries: /mnt/bash: failed to map segment from shared object: Operation not permitted - Nikolai Lifanov signature.asc Description: OpenPGP digital signature
Re: svn commit: r318313 - head/libexec/rtld-elf
On 05/15/2017 15:36, Alexey Dokuchaev wrote:
> On Mon, May 15, 2017 at 10:25:29PM +0300, Konstantin Belousov wrote:
>> On Mon, May 15, 2017 at 01:08:55PM -0600, Ian Lepore wrote:
>>> Well, for example, it seems like it would allow anyone to execute a
>>> binary even if the sysadmin had set it to -x specifically to prevent
>>> people from running it.
>>
>> The direct mode does not (and cannot) honor set{u,g}id modes of the
>> executable, so any binary run this way would only exercise the existing
>> power of the user which did it.
>>
>> The most advanced explanation that I was given in private was among
>> the lines: "if you have an environment where users can upload content
>> to a shared server, but have no access to chmod(2), no compilers, no
>> scripting languages, etc." The person then admitted that (s)he does not
>> consider it as an actual concern.
>
> Would this now allow executing binaries (with or without +x bit) from
> filesystems mounted with -o noexec?
>
> ./danfe
No:
# zfs create -o mountpoint=/mnt -o exec=off tank/TEST
# cp /bin/sh /mnt/
# /mnt/sh
/mnt/sh: Permission denied.
# /libexec/ld-elf.so.1 /mnt/sh
/mnt/sh: mmap of data failed: Permission denied
- Nikolai Lifanov
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r318313 - head/libexec/rtld-elf
On 05/15/2017 15:32, Bryan Drewery wrote: > On 5/15/2017 12:29 PM, Konstantin Belousov wrote: >> On Mon, May 15, 2017 at 12:25:20PM -0700, Bryan Drewery wrote: >>> On 5/15/2017 12:00 PM, Konstantin Belousov wrote: >>>> On Mon, May 15, 2017 at 06:52:36PM +, Alexey Dokuchaev wrote: >>>>> On Mon, May 15, 2017 at 06:48:58PM +, Konstantin Belousov wrote: >>>>>> New Revision: 318313 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/318313 >>>>>> >>>>>> Log: >>>>>> Make ld-elf.so.1 directly executable. >>>>> >>>>> Does it mean that old Linux' trick of /lib/ld-linux.so.2 /bin/chmod +x >>>>> /bin/chmod would now be possible on FreeBSD as well? >>>> Yes. >>>> >>>>> Does this have any security implications? >>>> What do you mean ? >>>> >>> >>> I think for 3rd-party distributions it may be a problem. At the very >>> least it needs to be communicated clearly in release notes or UPDATING. >>> >>> Consider a downstream vendor who has support for signed binary >>> executions. If rtld allows a backdoor around exec(2) to run an unsigned >>> binary, that could be a problem for them. It is on them to add support >>> to exec(2) to validate the special case of execing rtld with an >>> argument, or to just disable the feature in rtld from this commit. >> >> Note the undocumented O_VERIFY flag in open(2) from the patch. >> This is very vendor-ish addition to request veriexec (?). >> > > Ah nice. > Note, this already does the right thing with noexec filesystems: # zfs create -o mountpoint=/mnt -o exec=off tank/TEST # cp /bin/sh /mnt/ # /mnt/sh /mnt/sh: Permission denied. # /libexec/ld-elf.so.1 /mnt/sh /mnt/sh: mmap of data failed: Permission denied - Nikolai Lifanov signature.asc Description: OpenPGP digital signature
Re: svn commit: r318313 - head/libexec/rtld-elf
On 05/15/2017 15:18, Jonathan Anderson wrote: > On 15 May 2017, at 16:44, Jonathan Anderson wrote: > >> You can already execute "non-executable" binaries using the `exec` >> shell built-in: >> >> ``` >> $ cp /bin/sh . >> $ chmod -x sh >> $ exec sh >> ``` > > Er, oops: I ought to have said, you can execute non-executable binaries > by copying and marking them `+x`: > > ``` > $ cp /bin/sh . > $ chmod +x sh > $ ./sh > ``` > > (please ignore the bit about `exec`, that's from another mental thread) > > > Jon And the default install doesn't mount /tmp noexec ... - Nikolai Lifanov signature.asc Description: OpenPGP digital signature
Re: svn commit: r318313 - head/libexec/rtld-elf
On 05/15/2017 14:52, Alexey Dokuchaev wrote: > On Mon, May 15, 2017 at 06:48:58PM +, Konstantin Belousov wrote: >> New Revision: 318313 >> URL: https://svnweb.freebsd.org/changeset/base/318313 >> >> Log: >> Make ld-elf.so.1 directly executable. > > Does it mean that old Linux' trick of /lib/ld-linux.so.2 /bin/chmod +x > /bin/chmod would now be possible on FreeBSD as well? Does this have > any security implications? > > ./danfe This is a use case for fixing accidentally hosed /bin/chmod binary and not some sort of an escalation thing. You will need to be root to do this. Likewise, with working chmod binary, you should be able to mark binaries with write access executable. - Nikolai Lifanov signature.asc Description: OpenPGP digital signature
Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk
On 05/13/2017 13:21, Ngie Cooper (yaneurabeya) wrote: > Even ansible/chef/puppet would have to bake the configuration removal logic > into its template files, which seems like a pain for folks (and the same > logic would need to be implemented multiple times instead of once). Having to template one .conf file couples not necessarily related config modules together and it's *a lot* more performant to conditionally install and remove config snippets in .d/ than to expand a template. The separation matters when separate people write separate configuration modules and the performance matters when deciding on frequency of config runs. - Nikolai signature.asc Description: OpenPGP digital signature
svn commit: r312352 - stable/10/sys/dev/kbd
Author: lifanov (ports committer) Date: Tue Jan 17 22:02:22 2017 New Revision: 312352 URL: https://svnweb.freebsd.org/changeset/base/312352 Log: MFC r311650 Restore priority value for OGIO_KEYMAP PR: 206678 Submitted by: ect...@gmail.com Reviewed by: cem Approved by: cem, matthew (mentor) MFC after:1 week Differential Revision:https://reviews.freebsd.org/D5095 Modified: stable/10/sys/dev/kbd/kbd.c Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/dev/kbd/kbd.c == --- stable/10/sys/dev/kbd/kbd.c Tue Jan 17 22:01:33 2017(r312351) +++ stable/10/sys/dev/kbd/kbd.c Tue Jan 17 22:02:22 2017(r312352) @@ -884,7 +884,7 @@ genkbd_commonioctl(keyboard_t *kbd, u_lo omapp->key[i].spcl = mapp->key[i].spcl; omapp->key[i].flgs = mapp->key[i].flgs; } - return (0); + break; case PIO_KEYMAP:/* set keyboard translation table */ case OPIO_KEYMAP: /* set keyboard translation table (compat) */ #ifndef KBD_DISABLE_KEYMAP_LOAD ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r312351 - stable/11/sys/dev/kbd
Author: lifanov (ports committer) Date: Tue Jan 17 22:01:33 2017 New Revision: 312351 URL: https://svnweb.freebsd.org/changeset/base/312351 Log: MFC r311650 Restore priority value for OGIO_KEYMAP PR: 206678 Submitted by: ect...@gmail.com Reviewed by: cem Approved by: cem, matthew (mentor) MFC after:1 week Differential Revision:https://reviews.freebsd.org/D5095 Modified: stable/11/sys/dev/kbd/kbd.c Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/dev/kbd/kbd.c == --- stable/11/sys/dev/kbd/kbd.c Tue Jan 17 21:12:21 2017(r312350) +++ stable/11/sys/dev/kbd/kbd.c Tue Jan 17 22:01:33 2017(r312351) @@ -884,7 +884,7 @@ genkbd_commonioctl(keyboard_t *kbd, u_lo omapp->key[i].spcl = mapp->key[i].spcl; omapp->key[i].flgs = mapp->key[i].flgs; } - return (0); + break; case PIO_KEYMAP:/* set keyboard translation table */ case OPIO_KEYMAP: /* set keyboard translation table (compat) */ #ifndef KBD_DISABLE_KEYMAP_LOAD ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r311650 - head/sys/dev/kbd
Author: lifanov (ports committer) Date: Sat Jan 7 15:58:57 2017 New Revision: 311650 URL: https://svnweb.freebsd.org/changeset/base/311650 Log: Restore priority value for OGIO_KEYMAP PR: 206678 Submitted by: ect...@gmail.com Reviewed by: cem Approved by: cem, matthew (mentor) MFC after:1 week Differential Revision:https://reviews.freebsd.org/D5095 Modified: head/sys/dev/kbd/kbd.c Modified: head/sys/dev/kbd/kbd.c == --- head/sys/dev/kbd/kbd.c Sat Jan 7 15:57:12 2017(r311649) +++ head/sys/dev/kbd/kbd.c Sat Jan 7 15:58:57 2017(r311650) @@ -884,7 +884,7 @@ genkbd_commonioctl(keyboard_t *kbd, u_lo omapp->key[i].spcl = mapp->key[i].spcl; omapp->key[i].flgs = mapp->key[i].flgs; } - return (0); + break; case PIO_KEYMAP:/* set keyboard translation table */ case OPIO_KEYMAP: /* set keyboard translation table (compat) */ #ifndef KBD_DISABLE_KEYMAP_LOAD ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r310288 - stable/10
Author: lifanov (ports committer) Date: Mon Dec 19 19:39:02 2016 New Revision: 310288 URL: https://svnweb.freebsd.org/changeset/base/310288 Log: MFC r310160 retain cc.4.gz man page for Chelsio T6 NICs This man page was removed in r225583 when cc.4 was renamed to mod_cc.4 With reintroduction of cc.4 "make installworld; make delete-old" was no longer convergent. Reviewed by: matthew Approved by: jhb (implicit), matthew (mentor) Differential Revision:https://reviews.freebsd.org/D8829 Modified: stable/10/ObsoleteFiles.inc Directory Properties: stable/10/ (props changed) Modified: stable/10/ObsoleteFiles.inc == --- stable/10/ObsoleteFiles.inc Mon Dec 19 19:37:55 2016(r310287) +++ stable/10/ObsoleteFiles.inc Mon Dec 19 19:39:02 2016(r310288) @@ -937,7 +937,6 @@ OLD_FILES+=usr/lib32/libftpio_p.a OLD_FILES+=usr/include/ftpio.h OLD_FILES+=usr/share/man/man3/ftpio.3.gz # 20110915: rename congestion control manpages -OLD_FILES+=usr/share/man/man4/cc.4.gz OLD_FILES+=usr/share/man/man9/cc.9.gz # 20110831: atomic page flags operations OLD_FILES+=usr/share/man/man9/vm_page_flag.9.gz ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r310287 - stable/11
Author: lifanov (ports committer) Date: Mon Dec 19 19:37:55 2016 New Revision: 310287 URL: https://svnweb.freebsd.org/changeset/base/310287 Log: MFC r310160 retain cc.4.gz man page for Chelsio T6 NICs This man page was removed in r225583 when cc.4 was renamed to mod_cc.4 With reintroduction of cc.4 "make installworld; make delete-old" was no longer convergent. Reviewed by: matthew Approved by: jhb (implicit), matthew (mentor) Differential Revision:https://reviews.freebsd.org/D8828 Modified: stable/11/ObsoleteFiles.inc Directory Properties: stable/11/ (props changed) Modified: stable/11/ObsoleteFiles.inc == --- stable/11/ObsoleteFiles.inc Mon Dec 19 19:21:28 2016(r310286) +++ stable/11/ObsoleteFiles.inc Mon Dec 19 19:37:55 2016(r310287) @@ -2777,7 +2777,6 @@ OLD_FILES+=usr/lib32/libftpio_p.a OLD_FILES+=usr/include/ftpio.h OLD_FILES+=usr/share/man/man3/ftpio.3.gz # 20110915: rename congestion control manpages -OLD_FILES+=usr/share/man/man4/cc.4.gz OLD_FILES+=usr/share/man/man9/cc.9.gz # 20110831: atomic page flags operations OLD_FILES+=usr/share/man/man9/vm_page_flag.9.gz ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r310160 - head
On 12/16/2016 15:12, John Baldwin wrote: > On Friday, December 16, 2016 05:44:57 PM Nikolai Lifanov wrote: >> Author: lifanov (ports committer) >> Date: Fri Dec 16 17:44:56 2016 >> New Revision: 310160 >> URL: https://svnweb.freebsd.org/changeset/base/310160 >> >> Log: >> retain cc.4.gz man page for Chelsio T6 NICs >> >> This man page was removed in r225583 when cc.4 was renamed to mod_cc.4 >> With reintroduction of cc.4 "make installworld; make delete-old" was >> no longer convergent. > > Please MFC to 10 and 11 since cc(4) is now present there as well. > Makes sense, will do! - Nikolai Lifanov signature.asc Description: OpenPGP digital signature
svn commit: r310160 - head
Author: lifanov (ports committer) Date: Fri Dec 16 17:44:56 2016 New Revision: 310160 URL: https://svnweb.freebsd.org/changeset/base/310160 Log: retain cc.4.gz man page for Chelsio T6 NICs This man page was removed in r225583 when cc.4 was renamed to mod_cc.4 With reintroduction of cc.4 "make installworld; make delete-old" was no longer convergent. Reported by: Trond Endrestøl Reviewed by: np, matthew Approved by: np, matthew (mentor) Differential Revision:https://reviews.freebsd.org/D8816 Modified: head/ObsoleteFiles.inc Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Fri Dec 16 17:41:20 2016(r310159) +++ head/ObsoleteFiles.inc Fri Dec 16 17:44:56 2016(r310160) @@ -2939,7 +2939,6 @@ OLD_FILES+=usr/lib32/libftpio_p.a OLD_FILES+=usr/include/ftpio.h OLD_FILES+=usr/share/man/man3/ftpio.3.gz # 20110915: rename congestion control manpages -OLD_FILES+=usr/share/man/man4/cc.4.gz OLD_FILES+=usr/share/man/man9/cc.9.gz # 20110831: atomic page flags operations OLD_FILES+=usr/share/man/man9/vm_page_flag.9.gz ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r310024 - head/share/misc
Author: lifanov (ports committer) Date: Tue Dec 13 16:53:58 2016 New Revision: 310024 URL: https://svnweb.freebsd.org/changeset/base/310024 Log: add myself as a ports committer and update mentor/mentee relationship Reviewed by: matthew Approved by: matthew (mentor) Differential Revision:https://reviews.freebsd.org/D8774 Modified: head/share/misc/committers-ports.dot Modified: head/share/misc/committers-ports.dot == --- head/share/misc/committers-ports.dotTue Dec 13 16:20:10 2016 (r310023) +++ head/share/misc/committers-ports.dotTue Dec 13 16:53:58 2016 (r310024) @@ -145,6 +145,7 @@ lawrance [label="Sam Lawrance\nlawrance@ lbr [label="Lars Balker Rasmussen\n...@freebsd.org\n2006/04/30"] leeym [label="Yen-Ming Lee\nle...@freebsd.org\n2002/08/14"] lev [label="Lev Serebryakov\n...@freebsd.org\n2003/06/17"] +lifanov [label="Nikolai Lifanov\nlifa...@freebsd.org\n2016/12/11"] linimon [label="Mark Linimon\nlini...@freebsd.org\n2003/10/23"] lioux [label="Mario Sergio Fujikawa Ferriera\nli...@freebsd.org\n2000/10/14"] lippe [label="Felippe de Meirelles Motta\nli...@freebsd.org\n2008/03/08"] @@ -475,6 +476,8 @@ mat -> tcberner mat -> thierry mat -> woodsb02 +matthew -> lifanov + mezz -> tmclaugh miwi -> amdmi3 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r301010 - in head/sys: cddl/contrib/opensolaris/common/zfs cddl/contrib/opensolaris/uts/common cddl/contrib/opensolaris/uts/common/fs/zfs cddl/contrib/opensolaris/uts/common/fs/zfs/sys
On 05/31/2016 03:28, Jan Beich wrote: > Allan Jude writes: > >> Author: allanjude >> Date: Tue May 31 04:12:14 2016 >> New Revision: 301010 >> URL: https://svnweb.freebsd.org/changeset/base/301010 >> >> Log: >> Connect the SHA-512t256 and Skein hashing algorithms to ZFS >> >> Support for the new hashing algorithms in ZFS was introduced in r289422 >> However it was disconnected because FreeBSD lacked implementations of >> SHA-512 (truncated to 256 bits), and Skein. >> >> These implementations were introduced in r300921 and r300966 respectively >> >> This commit connects them to ZFS and enabled these new checksum algorithms >> >> This new algorithms are not supported by the boot blocks, so do not use >> them >> on your root dataset if you boot from ZFS. > > Can you document the feature and booting caveat in zpool-features(7) manpage? > And Illumos seems to limit booting support to pools vs. datasets. > +1. Also, zfs(8) needs to be updated. > Booting off of pools using skein is NOT supported -- any attempt to > enable skein on a root pool will fail with an error. > > https://illumos.org/man/5/zpool-features > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On March 6, 2016 4:13:34 PM EST, Dimitry Andric wrote: >On 06 Mar 2016, at 20:57, Nikolai Lifanov >wrote: >> >> On 2016-03-06 11:17, Dimitry Andric wrote: >>> On 06 Mar 2016, at 17:00, Oliver Pinter > wrote: >>>> On 3/6/16, Dimitry Andric wrote: >>>>> Author: dim >>>>> Date: Sun Mar 6 15:57:43 2016 >>>>> New Revision: 296428 >>>>> URL: https://svnweb.freebsd.org/changeset/base/296428 >>>>> Log: >>>>> Since kernel modules can now contain sections of type >SHT_AMD64_UNWIND, >>>>> the boot loader should not skip over these anymore while loading >images. >>>>> Otherwise the kernel can still panic when it doesn't find the >.eh_frame >>>>> section belonging to the .rela.eh_frame section. >>>>> Unfortunately this will require installing boot loaders from >sys/boot >>>>> before attempting to boot with a new kernel. >>>> Could you please add a note about this to UPDATING file? >>> I am a bit torn on this, because normally we always tell people to >>> install the kernel first, reboot, then run make installworld (which >also >>> installs the boot loaders). >>> However, in this case, people might depend on their boot loader >loading >>> modules which are required to make the system boot at all. So if >they >>> happened to forget updating their boot loader first, a panic might >be >>> the result. >>> I wonder what a failsafe and acceptable upgrade scenario is, in this >>> case. Normally the procedure is something like: >>> make buildworld >>> make buildkernel (with KERNCONF=whatever, if needed) >>> make installkernel (again with KERNCONF, if needed) >>> reboot (to single user, but cheating is possible usually) >>> mergemaster -p >>> make installworld >>> This could maybe be modified to: >>> make buildworld >>> make buildkernel (with KERNCONF=whatever, if needed) >>> make installkernel (again with KERNCONF, if needed) >>> make -C sys/boot install >>> reboot (to single user, but cheating is possible usually) >>> mergemaster -p >>> make installworld >>> E.g. insert the step which installs the boot loaders just after (or >>> before) the step which installs the kernel. >>> Is something like this acceptable as a one-time workaround, or maybe >it >>> is better in general, in case we ever add other new features to the >boot >>> loaders? >>> -Dimitry >> >> In my opinion, boot *blocks* (boot1) should be updated seldomly and >not on every install. >> All (?) instances of not updating these resulting in a failed boot >have an UPDATING >> entry or a similar warning (like the one during "zpool upgrade"). > >Well, each time you run make installworld, almost all the files in >/boot >(except for configuration) get reinstalled. For e.g. mbr, boot1 and >such, this has no consequences at all, until you install them into some >partition using gpart, but changes to loader, loader.efi or zfsloader >*will* affect the next startup. > >Per a suggestion from Kostik, maybe it would be nice to have a separate >"make installboot" target, which installs just the components in /boot. >This could then be used before or after "make installkernel". > >-Dimitry The bootcode gets installed to boot, but deployed with gpart, cp, sliced in half and dd, etc. And that's to one or more partitions. I don't think that a separate install target that just stages boot1 to /boot is valuable. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r296428 - head/sys/boot/common
On 2016-03-06 11:17, Dimitry Andric wrote: On 06 Mar 2016, at 17:00, Oliver Pinter wrote: On 3/6/16, Dimitry Andric wrote: Author: dim Date: Sun Mar 6 15:57:43 2016 New Revision: 296428 URL: https://svnweb.freebsd.org/changeset/base/296428 Log: Since kernel modules can now contain sections of type SHT_AMD64_UNWIND, the boot loader should not skip over these anymore while loading images. Otherwise the kernel can still panic when it doesn't find the .eh_frame section belonging to the .rela.eh_frame section. Unfortunately this will require installing boot loaders from sys/boot before attempting to boot with a new kernel. Could you please add a note about this to UPDATING file? I am a bit torn on this, because normally we always tell people to install the kernel first, reboot, then run make installworld (which also installs the boot loaders). However, in this case, people might depend on their boot loader loading modules which are required to make the system boot at all. So if they happened to forget updating their boot loader first, a panic might be the result. I wonder what a failsafe and acceptable upgrade scenario is, in this case. Normally the procedure is something like: make buildworld make buildkernel (with KERNCONF=whatever, if needed) make installkernel (again with KERNCONF, if needed) reboot (to single user, but cheating is possible usually) mergemaster -p make installworld This could maybe be modified to: make buildworld make buildkernel (with KERNCONF=whatever, if needed) make installkernel (again with KERNCONF, if needed) make -C sys/boot install reboot (to single user, but cheating is possible usually) mergemaster -p make installworld E.g. insert the step which installs the boot loaders just after (or before) the step which installs the kernel. Is something like this acceptable as a one-time workaround, or maybe it is better in general, in case we ever add other new features to the boot loaders? -Dimitry In my opinion, boot *blocks* (boot1) should be updated seldomly and not on every install. All (?) instances of not updating these resulting in a failed boot have an UPDATING entry or a similar warning (like the one during "zpool upgrade"). - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys
On 01/19/16 16:02, Nikolai Lifanov wrote:
> On 01/19/16 15:52, Kurt Lidl wrote:
>> On 1/19/16 1:55 PM, Alan Somers wrote:
>>> On Tue, Jan 19, 2016 at 10:00 AM, Alan Somers
>>> wrote:
>>>> Author: asomers
>>>> Date: Tue Jan 19 17:00:25 2016
>>>> New Revision: 294329
>>>> URL: https://svnweb.freebsd.org/changeset/base/294329
>>>>
>>>> Log:
>>>>Disallow zvol-backed ZFS pools
>>>>
>>>>Using zvols as backing devices for ZFS pools is fraught with
>>>> panics and
>>>>deadlocks. For example, attempting to online a missing device in the
>>>>presence of a zvol can cause a panic when vdev_geom tastes the
>>>> zvol. Better
>>>>to completely disable vdev_geom from ever opening a zvol. The
>>>> solution
>>>>relies on setting a thread-local variable during vdev_geom_open, and
>>>>returning EOPNOTSUPP during zvol_open if that thread-local
>>>> variable is set.
>>>>
>>>>Remove the check for MUTEX_HELD(&zfsdev_state_lock) in zvol_open.
>>>> Its intent
>>>>was to prevent a recursive mutex acquisition panic. However, the
>>>> new check
>>>>for the thread-local variable also fixes that problem.
>>>>
>>>>Also, fix a panic in vdev_geom_taste_orphan. For an unknown
>>>> reason, this
>>>>function was set to panic. But it can occur that a device
>>>> disappears during
>>>>tasting, and it causes no problems to ignore this departure.
>>>>
>>>>Reviewed by: delphij
>>>>MFC after:1 week
>>>>Relnotes: yes
>>>>Sponsored by: Spectra Logic Corp
>>>>Differential Revision:https://reviews.freebsd.org/D4986
>>>>
>>>> Modified:
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
>>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
>>>>
>>>> Modified:
>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>>
>>> Due to popular demand, I will conditionalize this behavior on a
>>> sysctl, and I won't MFC it. The sysctl must default to off (ZFS on
>>> zvols not allowed) because having the ability to put pools on zvols
>>> can cause panics even for users who aren't using it.
>>
>> Thank you!
>>
>>> And let me clear up some confusion:
>>>
>>> 1) Having the ability to put a zpool on a zvol can cause panics and
>>> deadlocks, even if that ability is unused.
>>> 2) Putting a zpool atop a zvol causes unnecessary performance problems
>>> because there are two layers of COW involved, with all their software
>>> complexities. This also applies to putting a zpool atop files on a
>>> ZFS filesystem.
>>> 3) A VM guest putting a zpool on its virtual disk, where the VM host
>>> backs that virtual disk with a zvol, will work fine. That's the ideal
>>> use case for zvols.
>>> 3b) Using ZFS on both host and guest isn't ideal for performance, as
>>> described in item 2. That's why I prefer to use UFS for VM guests.
>>
>> The patch as is does very much break the way some people do operations
>> on zvols. My script that does virtual machine cloning via snapshots
>> of zvols containing zpools is currently broken due to this. (I upgraded
>> one of my dev hosts right after your commit, to verify the broken
>> behavior.)
>>
>> In my script, I boot an auto-install .iso into bhyve:
>>
>> bhyve -c 2 -m ${vmmem} -H -A -I -g 0 \
>> -s 0:0,hostbridge \
>> -s 1,lpc -l com1,stdio \
>> -s 2:0,virtio-net,${template_tap} \
>> -s 3:0,ahci-hd,"${zvol}" \
>> -s 4:0,ahci-cd,"${isofile}" \
>> ${vmname} || \
>> echo "trapped error exit from bhyve: $?"
>>
>> So, yes, the zpool gets created by the client VM. Then on
>> the hypervisor host, the script imports that zpool and renames it,
>> so that I can have different pool names for all the client VMs.
>> This step now fails:
>>
>> + zpool import -R /virt/base -d /dev/zvol/zdata sys base
>>
Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys
On 01/19/16 15:52, Kurt Lidl wrote:
> On 1/19/16 1:55 PM, Alan Somers wrote:
>> On Tue, Jan 19, 2016 at 10:00 AM, Alan Somers
>> wrote:
>>> Author: asomers
>>> Date: Tue Jan 19 17:00:25 2016
>>> New Revision: 294329
>>> URL: https://svnweb.freebsd.org/changeset/base/294329
>>>
>>> Log:
>>>Disallow zvol-backed ZFS pools
>>>
>>>Using zvols as backing devices for ZFS pools is fraught with
>>> panics and
>>>deadlocks. For example, attempting to online a missing device in the
>>>presence of a zvol can cause a panic when vdev_geom tastes the
>>> zvol. Better
>>>to completely disable vdev_geom from ever opening a zvol. The
>>> solution
>>>relies on setting a thread-local variable during vdev_geom_open, and
>>>returning EOPNOTSUPP during zvol_open if that thread-local
>>> variable is set.
>>>
>>>Remove the check for MUTEX_HELD(&zfsdev_state_lock) in zvol_open.
>>> Its intent
>>>was to prevent a recursive mutex acquisition panic. However, the
>>> new check
>>>for the thread-local variable also fixes that problem.
>>>
>>>Also, fix a panic in vdev_geom_taste_orphan. For an unknown
>>> reason, this
>>>function was set to panic. But it can occur that a device
>>> disappears during
>>>tasting, and it causes no problems to ignore this departure.
>>>
>>>Reviewed by: delphij
>>>MFC after:1 week
>>>Relnotes: yes
>>>Sponsored by: Spectra Logic Corp
>>>Differential Revision:https://reviews.freebsd.org/D4986
>>>
>>> Modified:
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
>>>head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
>>>
>>> Modified:
>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h
>>
>> Due to popular demand, I will conditionalize this behavior on a
>> sysctl, and I won't MFC it. The sysctl must default to off (ZFS on
>> zvols not allowed) because having the ability to put pools on zvols
>> can cause panics even for users who aren't using it.
>
> Thank you!
>
>> And let me clear up some confusion:
>>
>> 1) Having the ability to put a zpool on a zvol can cause panics and
>> deadlocks, even if that ability is unused.
>> 2) Putting a zpool atop a zvol causes unnecessary performance problems
>> because there are two layers of COW involved, with all their software
>> complexities. This also applies to putting a zpool atop files on a
>> ZFS filesystem.
>> 3) A VM guest putting a zpool on its virtual disk, where the VM host
>> backs that virtual disk with a zvol, will work fine. That's the ideal
>> use case for zvols.
>> 3b) Using ZFS on both host and guest isn't ideal for performance, as
>> described in item 2. That's why I prefer to use UFS for VM guests.
>
> The patch as is does very much break the way some people do operations
> on zvols. My script that does virtual machine cloning via snapshots
> of zvols containing zpools is currently broken due to this. (I upgraded
> one of my dev hosts right after your commit, to verify the broken
> behavior.)
>
> In my script, I boot an auto-install .iso into bhyve:
>
> bhyve -c 2 -m ${vmmem} -H -A -I -g 0 \
> -s 0:0,hostbridge \
> -s 1,lpc -l com1,stdio \
> -s 2:0,virtio-net,${template_tap} \
> -s 3:0,ahci-hd,"${zvol}" \
> -s 4:0,ahci-cd,"${isofile}" \
> ${vmname} || \
> echo "trapped error exit from bhyve: $?"
>
> So, yes, the zpool gets created by the client VM. Then on
> the hypervisor host, the script imports that zpool and renames it,
> so that I can have different pool names for all the client VMs.
> This step now fails:
>
> + zpool import -R /virt/base -d /dev/zvol/zdata sys base
> cannot import 'sys' as 'base': no such pool or dataset
> Destroy and re-create the pool from
> a backup source.
>
> I import the clients' zpools after the zpools on them has
> been renamed, so the hypervisor host can manipulate the
> files directly. It only disturbs a small amount of the
> disk blocks on each of the snapshots of the zvol to rename
> the zpools.
>
> In this way, I can instantiate ~30 virtual machines from
> a custom install.iso image in less than 3 minutes. And
> the bulk of that time is doing the installation from the
> custom install.iso into the first virtual machine. The
> cloning of the zvols, and manipulation of the resulting
> filesystems is very fast.
>
Can't you just set volmode=dev and use zfs clone?
> -Kurt
>
>
>
> ___
> svn-src-h...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
___
svn-src-all@freebsd.org mailing list
https://lists.f
Re: svn commit: r287227 - in head: lib/libstand share/mk sys/boot/efi sys/boot/ficl sys/boot/i386 sys/boot/libstand32 sys/boot/pc98 sys/boot/userboot/ficl sys/boot/userboot/libstand sys/boot/zfs
On 08/27/15 19:46, Warner Losh wrote: > Author: imp > Date: Thu Aug 27 23:46:42 2015 > New Revision: 287227 > URL: https://svnweb.freebsd.org/changeset/base/287227 > > Log: > Use CFLAGS_NO_SIMD in preference to varying lists of -mno- flags. > Go ahead and defined -D_STANDALONE for all targets (only strictly > needed for some architecture, but harmless on those it isn't required > for). Also add -msoft-float to all architectures uniformly rather > that higgley piggley like it is today. > > Differential Revision: https://reviews.freebsd.org/D3496 > > Added: > head/share/mk/bsd.stand.mk (contents, props changed) > Modified: > head/lib/libstand/Makefile > head/sys/boot/efi/Makefile.inc > head/sys/boot/ficl/Makefile > head/sys/boot/i386/Makefile.inc > head/sys/boot/libstand32/Makefile > head/sys/boot/pc98/Makefile.inc > head/sys/boot/userboot/ficl/Makefile > head/sys/boot/userboot/libstand/Makefile > head/sys/boot/zfs/Makefile > Hi! I get this on amd64 after this commit: --- sys.all__D --- ld: i386:x86-64 architecture of input file `/usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a(qdivrem.o)' is incompatible with i386 output *** [gptboot.out] Error code 1 - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278450 - head/release
On 2015-02-09 05:46, Glen Barber wrote: Author: gjb Date: Mon Feb 9 10:46:39 2015 New Revision: 278450 URL: https://svnweb.freebsd.org/changeset/base/278450 Log: Revert r278445. I was going to use __FreeBSD_version to determine if xz(1) should be multi-threaded by default, but doing this will cause problems if/when the changes are merged from head. Sponsored by: The FreeBSD Foundation Modified: head/release/Makefile Modified: head/release/Makefile Can you just X-MFC this with xz 5.2.0 import? You can then refer to xz in OBJDIR to get this to work on older releases. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 2014-09-03 21:18, Steven Hartland wrote:
- Original Message - From: "Andriy Gapon"
on 03/09/2014 23:22 Nikolai Lifanov said the following:
On 09/03/14 15:22, John Baldwin wrote:
On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
On 09/03/14 04:09, Steven Hartland wrote:
I'm looking to MFC this change so wanted to check if
anyone had an final feedback / objections?
I know we currently have Alan's feedback on changing
the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
which sounds sensible but waiting Peter to comment on.
Regards
Steve
I have no technical input, but this change improves ARC usefulness
for
me quite a bit. I would like to see the improvement in 10-STABLE.
Can you verify that the current 10-STABLE (as of today) with all the
various pagedaemon fixes still has ARC issues for your workload?
It doesn't have any issues, but I noticed the improvement on CURRENT.
I
observed that just after this change, my package builder is much more
likely to retain MFU and not evict useful things from there (the port
tree) after large builds.
However, I run a lot more 10.0-RELEASE than CURRENT and I would like
to
see this improvement release-bound.
I would be happy to test this on 10-STABLE if you think that this is
relevant.
As noted before, unfortunately, this commit (plus its fixups) contains
at least
two related but distinct changes. So, to separate the wheat from the
chaff,
could you please try to comment out the following block in
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, function
arc_reclaim_needed:
if (kmem_free_count() < zfs_arc_free_target) {
DTRACE_PROBE2(arc__reclaim_freetarget, uint64_t,
kmem_free_count(), uint64_t, zfs_arc_free_target);
return (1);
}
Alternatively, I think that the same effect can be achieved by setting
sysctl
vfs.zfs.arc_free_target to the same value as vm.stats.vm.v_free_min.
Thats correct that would achieve the same thing.
It's interesting to me whether you would still see the better
performance or if
that improvement would be undone.
Indeed that would be interesting, but we might find that its quite
memory size
dependent given the scaling so confirming HW details would be nice too.
I'd also be interested to know who wins the free race between the VM
and ARC
when using that value.
For those following this thread but not the review, I've added some
additional
information there which you might be interested in:
https://reviews.freebsd.org/D702
Regards
Steve
I had time to re-test both the "stock" condition after the improvements
and the condition in which
vfs.zfs.arc_free_target=vm.stats.vm.v_free_min. It seems that MFU is
more likely to be reduced in the second case.
- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 09/03/14 21:18, Steven Hartland wrote:
>
> - Original Message - From: "Andriy Gapon"
>
>
>> on 03/09/2014 23:22 Nikolai Lifanov said the following:
>>> On 09/03/14 15:22, John Baldwin wrote:
>>>> On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
>>>>> On 09/03/14 04:09, Steven Hartland wrote:
>>>>>> I'm looking to MFC this change so wanted to check if
>>>>>> anyone had an final feedback / objections?
>>>>>>
>>>>>> I know we currently have Alan's feedback on changing
>>>>>> the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
>>>>>> which sounds sensible but waiting Peter to comment on.
>>>>>>
>>>>>>Regards
>>>>>>Steve
>>>>>
>>>>> I have no technical input, but this change improves ARC usefulness for
>>>>> me quite a bit. I would like to see the improvement in 10-STABLE.
>>>>
>>>> Can you verify that the current 10-STABLE (as of today) with all the
>>>> various pagedaemon fixes still has ARC issues for your workload?
>>>>
>>>
>>> It doesn't have any issues, but I noticed the improvement on CURRENT. I
>>> observed that just after this change, my package builder is much more
>>> likely to retain MFU and not evict useful things from there (the port
>>> tree) after large builds.
>>> However, I run a lot more 10.0-RELEASE than CURRENT and I would like to
>>> see this improvement release-bound.
>>>
>>> I would be happy to test this on 10-STABLE if you think that this is
>>> relevant.
>>
>>
>> As noted before, unfortunately, this commit (plus its fixups) contains
>> at least
>> two related but distinct changes. So, to separate the wheat from the
>> chaff,
>> could you please try to comment out the following block in
>> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, function
>> arc_reclaim_needed:
>>
>>if (kmem_free_count() < zfs_arc_free_target) {
>>DTRACE_PROBE2(arc__reclaim_freetarget, uint64_t,
>>kmem_free_count(), uint64_t, zfs_arc_free_target);
>>return (1);
>>}
>>
>> Alternatively, I think that the same effect can be achieved by setting
>> sysctl
>> vfs.zfs.arc_free_target to the same value as vm.stats.vm.v_free_min.
>
> Thats correct that would achieve the same thing.
>
>> It's interesting to me whether you would still see the better
>> performance or if
>> that improvement would be undone.
>
> Indeed that would be interesting, but we might find that its quite
> memory size
> dependent given the scaling so confirming HW details would be nice too.
>
> I'd also be interested to know who wins the free race between the VM and
> ARC
> when using that value.
>
> For those following this thread but not the review, I've added some
> additional
> information there which you might be interested in:
> https://reviews.freebsd.org/D702
>
>Regards
>Steve
Just an update: I'm in the middle of testing this. I have to finish a
large bulk build to observe the behavior one way or another.
I have 32G of physical memory and 2x16G dedicated swap SSDs (L2ARC
wasn't very useful, but I should probably retest this) on this machine.
My ARC is usually at 14G with ~5G of MFU full of things I benefit from
keeping there (port trees, base jails). Builds themselves happen in
tmpfs and I usually have around 1.5G - 4G "Free" memory (unless building
something like pypy).
- Nikolai Lifanov
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 09/03/14 15:22, John Baldwin wrote: > On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote: >> On 09/03/14 04:09, Steven Hartland wrote: >>> I'm looking to MFC this change so wanted to check if >>> anyone had an final feedback / objections? >>> >>> I know we currently have Alan's feedback on changing >>> the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC >>> which sounds sensible but waiting Peter to comment on. >>> >>>Regards >>>Steve >> >> I have no technical input, but this change improves ARC usefulness for >> me quite a bit. I would like to see the improvement in 10-STABLE. > > Can you verify that the current 10-STABLE (as of today) with all the various > pagedaemon fixes still has ARC issues for your workload? > It doesn't have any issues, but I noticed the improvement on CURRENT. I observed that just after this change, my package builder is much more likely to retain MFU and not evict useful things from there (the port tree) after large builds. However, I run a lot more 10.0-RELEASE than CURRENT and I would like to see this improvement release-bound. I would be happy to test this on 10-STABLE if you think that this is relevant. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 09/03/14 04:09, Steven Hartland wrote: > I'm looking to MFC this change so wanted to check if > anyone had an final feedback / objections? > > I know we currently have Alan's feedback on changing > the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC > which sounds sensible but waiting Peter to comment on. > >Regards >Steve I have no technical input, but this change improves ARC usefulness for me quite a bit. I would like to see the improvement in 10-STABLE. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r266553 - head/release/scripts
at kernel will be running in there and how it will be configured? You don't. IA64 can -- sometimes -- run i386 binaries, for example. amd64 may or may not be able to run i386, depending on kernel options. You're assuming that you would only use a chroot to RUN things. This is also useful for building images. Install a world into a chroot, run pkg -c install whatever and it picks the right ABI. Just an example. In any case, I wouldn't really characterize this situation as "common" in any sense -- and I don't even see why it applies to this discussion. Whatever logic calculates your own private version of architecture strings can calculate the correct ones. Allowing it to ignore the architecture optionally, just like you how you already have to add flags to install in a chroot, would also work. Lots of things like that. This issue is basically wholly unrelated to whether you use normal architecture strings or not. I'm perfectly happy to write 100% of the code to enable pkg to use the same architecture strings that the rest of the operating system uses. Having private ones is just a recipe for confusion. From this discussion, there don't seem to be any actually existing reasons why MACHINE_ARCH doesn't work for this. pkg is *not* FreeBSD-specific. Is MACHINE_ARCH portable? I don't think it matters whether MACHINE_ARCH is portable. FreeBSD amd64 binaries are not going to run on Linux x86_64, for example. Setting pkg ABI to something like freebsd:arm:armv6hf or freebsd:amd64:amd64 is specific enough, and could allow installation if the last triplet is in kern.supported_archs. Then you can have linux:fruit:banana packages that will correctly not install on freebsd:amd64:amd64. The current mapping is not intuitive. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264027 - in head: release share/man/man7
On 04/02/14 12:33, Glen Barber wrote: > On Wed, Apr 02, 2014 at 12:23:46PM -0400, Nikolai Lifanov wrote: >> On 04/02/14 12:06, Glen Barber wrote: >>> On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: >>>> On 04/02/14 11:51, Glen Barber wrote: >>>>> On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: >>>>>> On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: >>>>>>> Author: gjb >>>>>>> Date: Tue Apr 1 22:41:26 2014 >>>>>>> New Revision: 264027 >>>>>>> URL: http://svnweb.freebsd.org/changeset/base/264027 >>>>>>> >>>>>>> Log: >>>>>>> Add a new release build variable, WITH_COMPRESSED_IMAGES. >>>>>>> >>>>>>> When set to a non-empty value, the installation medium is >>>>>>> compressed with gzip(1) as part of the 'install' target in >>>>>>> the release/ directory. >>>>>>> >>>>>>> With gzip(1) compression, downloadable image are reduced in >>>>>>> size quite significantly. Build test against head@263927 >>>>>>> shows the following: >>>>>>> >>>>>>>bootonly.iso:64% smaller >>>>>>>disc1.iso: 44% smaller >>>>>>>memstick.img:47% smaller >>>>>>>mini-memstick.img: 65% smaller >>>>>>>dvd1.iso:untested >>>>>>> >>>>>>> This option is off by default, I would eventually like to >>>>>>> turn it on by default, and remove the '-k' flag to gzip(1) >>>>>>> so only compressed images are published on FTP. >>>>>> >>>>>> I'd recommend testing xz compression as well. With UFS images of a full >>>>>> world the savings vs gzip are significant (more than 30% IIRC, but it's >>>>>> need more than a year since I checked so I'm a bit unsure of the exact >>>>>> numbers). >>>>>> >>>>> >>>>> delphij also brought this up. >>>>> >>>>> I have concerns with xz(1), since there was mention in IRC that Windows >>>>> users may have problems decompressing xz-compressed images. So, gzip(1) >>>>> is used because it seems to be the more commonly-supported archive >>>>> mechanisms. >>>>> >>>>> The benefit of xz(1) over gzip(1) was only 50M-ish. >>>>> >>>>> -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso >>>>> -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 >>>>> -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz >>>>> -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz >>>>> >>>>> Glen >>>>> >>>> >>>> How about 7zip (Windows program, not file format)? What would a Windows >>>> user use that can decompress gzip and not xz? It was a problem around >>>> ~2007, but xz support is no longer rare or exotic. >>>> >>> >>> I don't know, to be honest. I have no Windows machines to test, so >>> I can only go by what I am told. >>> >>> Glen >>> >> >> I just verified it with 7zip for Windows version 9.22. It extracts >> .tar.xz archives and decompresses .xz images. >> > > Great, thank you for confirming. > > So, the question I have now is, considering the time it takes to > compress the image with xz(1) compared to gzip(1), is that worth saving > the 50MB space? > > I do not object to using xz(1), but the compression time difference was > quite significant. (I do not have numbers off-hand, but can run the > compression again.) > > Glen > Compression is much more expensive. There are different levels too, so xz -9e my16Gfile.img on a 4 core i7 can take up to 8 hours. Other levels are cheaper. De-compression (for the end user) is as cheap or cheaper than gzip. Depending on the chosen compression level, the minimum amount of RAM required for decompression can also grow. The xz(1) explains these properties. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264027 - in head: release share/man/man7
On 04/02/14 12:06, Glen Barber wrote: > On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: >> On 04/02/14 11:51, Glen Barber wrote: >>> On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: >>>> On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: >>>>> Author: gjb >>>>> Date: Tue Apr 1 22:41:26 2014 >>>>> New Revision: 264027 >>>>> URL: http://svnweb.freebsd.org/changeset/base/264027 >>>>> >>>>> Log: >>>>> Add a new release build variable, WITH_COMPRESSED_IMAGES. >>>>> >>>>> When set to a non-empty value, the installation medium is >>>>> compressed with gzip(1) as part of the 'install' target in >>>>> the release/ directory. >>>>> >>>>> With gzip(1) compression, downloadable image are reduced in >>>>> size quite significantly. Build test against head@263927 >>>>> shows the following: >>>>> >>>>>bootonly.iso: 64% smaller >>>>>disc1.iso: 44% smaller >>>>>memstick.img: 47% smaller >>>>>mini-memstick.img: 65% smaller >>>>>dvd1.iso: untested >>>>> >>>>> This option is off by default, I would eventually like to >>>>> turn it on by default, and remove the '-k' flag to gzip(1) >>>>> so only compressed images are published on FTP. >>>> >>>> I'd recommend testing xz compression as well. With UFS images of a full >>>> world the savings vs gzip are significant (more than 30% IIRC, but it's >>>> need more than a year since I checked so I'm a bit unsure of the exact >>>> numbers). >>>> >>> >>> delphij also brought this up. >>> >>> I have concerns with xz(1), since there was mention in IRC that Windows >>> users may have problems decompressing xz-compressed images. So, gzip(1) >>> is used because it seems to be the more commonly-supported archive >>> mechanisms. >>> >>> The benefit of xz(1) over gzip(1) was only 50M-ish. >>> >>> -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso >>> -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 >>> -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz >>> -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz >>> >>> Glen >>> >> >> How about 7zip (Windows program, not file format)? What would a Windows >> user use that can decompress gzip and not xz? It was a problem around >> ~2007, but xz support is no longer rare or exotic. >> > > I don't know, to be honest. I have no Windows machines to test, so > I can only go by what I am told. > > Glen > I just verified it with 7zip for Windows version 9.22. It extracts .tar.xz archives and decompresses .xz images. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264027 - in head: release share/man/man7
On 04/02/14 11:51, Glen Barber wrote: > On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: >> On Tue, Apr 01, 2014 at 10:41:27PM +, Glen Barber wrote: >>> Author: gjb >>> Date: Tue Apr 1 22:41:26 2014 >>> New Revision: 264027 >>> URL: http://svnweb.freebsd.org/changeset/base/264027 >>> >>> Log: >>> Add a new release build variable, WITH_COMPRESSED_IMAGES. >>> >>> When set to a non-empty value, the installation medium is >>> compressed with gzip(1) as part of the 'install' target in >>> the release/ directory. >>> >>> With gzip(1) compression, downloadable image are reduced in >>> size quite significantly. Build test against head@263927 >>> shows the following: >>> >>>bootonly.iso:64% smaller >>>disc1.iso: 44% smaller >>>memstick.img:47% smaller >>>mini-memstick.img: 65% smaller >>>dvd1.iso:untested >>> >>> This option is off by default, I would eventually like to >>> turn it on by default, and remove the '-k' flag to gzip(1) >>> so only compressed images are published on FTP. >> >> I'd recommend testing xz compression as well. With UFS images of a full >> world the savings vs gzip are significant (more than 30% IIRC, but it's >> need more than a year since I checked so I'm a bit unsure of the exact >> numbers). >> > > delphij also brought this up. > > I have concerns with xz(1), since there was mention in IRC that Windows > users may have problems decompressing xz-compressed images. So, gzip(1) > is used because it seems to be the more commonly-supported archive > mechanisms. > > The benefit of xz(1) over gzip(1) was only 50M-ish. > > -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso > -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 > -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz > -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz > > Glen > How about 7zip (Windows program, not file format)? What would a Windows user use that can decompress gzip and not xz? It was a problem around ~2007, but xz support is no longer rare or exotic. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r258672 - in head: . share/mk
On 11/26/13 23:54, Peter Wemm wrote: > Author: peter > Date: Wed Nov 27 04:54:23 2013 > New Revision: 258672 > URL: http://svnweb.freebsd.org/changeset/base/258672 > > Log: > At great personal risk, change the default for LIB32 from yes to no. As > mentioned in UPDATING, you can even do it as an as-needed operation after > doing a buildworld/installworld. You can set WITH_LIB32=yes in make.conf > or src.conf. > > Modified: > head/UPDATING > head/share/mk/bsd.own.mk > If you decide to keep this change, can you add LIB32 stuff to optional obsoletes? Otherwise people will be left with rotting outdated lib32 directories. Thanks! - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r254025 - in head/sys: amd64/amd64 arm/arm arm/at91 arm/mv/armadaxp arm/s3c2xx0 arm/xscale/i80321 arm/xscale/i8134x arm/xscale/ixp425 cddl/compat/opensolaris/kern cddl/compat/opensolar
On 08/07/13 02:21, Jeff Roberson wrote: Author: jeff Date: Wed Aug 7 06:21:20 2013 New Revision: 254025 URL: http://svnweb.freebsd.org/changeset/base/254025 Log: Replace kernel virtual address space allocation with vmem. This provides transparent layering and better fragmentation. - Normalize functions that allocate memory to use kmem_* - Those that allocate address space are named kva_* - Those that operate on maps are named kmap_* - Implement recursive allocation handling for kmem_arena in vmem. Reviewed by: alc Tested by: pho Sponsored by:EMC / Isilon Storage Division Modified: head/sys/amd64/amd64/mp_machdep.c head/sys/amd64/amd64/pmap.c head/sys/amd64/amd64/sys_machdep.c head/sys/amd64/amd64/vm_machdep.c head/sys/arm/arm/bus_space_generic.c head/sys/arm/arm/busdma_machdep-v6.c head/sys/arm/arm/busdma_machdep.c head/sys/arm/arm/mp_machdep.c head/sys/arm/arm/pmap-v6.c head/sys/arm/arm/pmap.c head/sys/arm/arm/vm_machdep.c head/sys/arm/at91/at91.c head/sys/arm/mv/armadaxp/armadaxp_mp.c head/sys/arm/s3c2xx0/s3c2xx0_space.c head/sys/arm/xscale/i80321/i80321_space.c head/sys/arm/xscale/i8134x/i81342_space.c head/sys/arm/xscale/ixp425/ixp425_pci_space.c head/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c head/sys/cddl/compat/opensolaris/sys/kmem.h head/sys/compat/linux/linux_misc.c head/sys/compat/ndis/subr_ntoskrnl.c head/sys/dev/bktr/bktr_core.c head/sys/dev/drm/drm_scatter.c head/sys/dev/drm2/drm_scatter.c head/sys/dev/drm2/i915/intel_ringbuffer.c head/sys/dev/drm2/ttm/ttm_bo_util.c head/sys/dev/xen/blkback/blkback.c head/sys/dev/xen/netback/netback.c head/sys/dev/xen/xenpci/xenpci.c head/sys/i386/i386/machdep.c head/sys/i386/i386/mp_machdep.c head/sys/i386/i386/pmap.c head/sys/i386/i386/sys_machdep.c head/sys/i386/i386/vm_machdep.c head/sys/i386/ibcs2/imgact_coff.c head/sys/i386/pci/pci_cfgreg.c head/sys/i386/xen/mp_machdep.c head/sys/i386/xen/pmap.c head/sys/ia64/ia64/mp_machdep.c head/sys/kern/imgact_gzip.c head/sys/kern/init_main.c head/sys/kern/kern_exec.c head/sys/kern/kern_malloc.c head/sys/kern/kern_mbuf.c head/sys/kern/kern_sharedpage.c head/sys/kern/subr_busdma_bufalloc.c head/sys/kern/subr_vmem.c head/sys/kern/vfs_bio.c head/sys/mips/mips/mp_machdep.c head/sys/mips/mips/pmap.c head/sys/mips/mips/vm_machdep.c head/sys/mips/sibyte/sb_zbpci.c head/sys/ofed/include/linux/dma-mapping.h head/sys/ofed/include/linux/gfp.h head/sys/ofed/include/linux/linux_compat.c head/sys/pc98/pc98/machdep.c head/sys/powerpc/aim/mmu_oea.c head/sys/powerpc/aim/mmu_oea64.c head/sys/powerpc/aim/vm_machdep.c head/sys/powerpc/booke/pmap.c head/sys/powerpc/booke/vm_machdep.c head/sys/powerpc/powerpc/busdma_machdep.c head/sys/powerpc/powerpc/mp_machdep.c head/sys/sparc64/sparc64/bus_machdep.c head/sys/sparc64/sparc64/mem.c head/sys/sparc64/sparc64/mp_machdep.c head/sys/sparc64/sparc64/pmap.c head/sys/sparc64/sparc64/vm_machdep.c head/sys/vm/memguard.c head/sys/vm/memguard.h head/sys/vm/pmap.h head/sys/vm/uma_core.c head/sys/vm/vm_extern.h head/sys/vm/vm_glue.c head/sys/vm/vm_init.c head/sys/vm/vm_kern.c head/sys/vm/vm_kern.h head/sys/vm/vm_map.c head/sys/vm/vm_map.h head/sys/vm/vm_object.c head/sys/x86/x86/busdma_machdep.c head/sys/xen/gnttab.c Modified: head/sys/amd64/amd64/mp_machdep.c == --- head/sys/amd64/amd64/mp_machdep.c Wed Aug 7 06:05:57 2013 (r254024) +++ head/sys/amd64/amd64/mp_machdep.c Wed Aug 7 06:21:20 2013 (r254025) @@ -938,10 +938,14 @@ start_all_aps(void) apic_id = cpu_apic_ids[cpu]; /* allocate and set up an idle stack data page */ - bootstacks[cpu] = (void *)kmem_alloc(kernel_map, KSTACK_PAGES * PAGE_SIZE); - doublefault_stack = (char *)kmem_alloc(kernel_map, PAGE_SIZE); - nmi_stack = (char *)kmem_alloc(kernel_map, PAGE_SIZE); - dpcpu = (void *)kmem_alloc(kernel_map, DPCPU_SIZE); + bootstacks[cpu] = (void *)kmem_malloc(kernel_arena, + KSTACK_PAGES * PAGE_SIZE, M_WAITOK | M_ZERO); + doublefault_stack = (char *)kmem_malloc(kernel_arena, + PAGE_SIZE, M_WAITOK | M_ZERO); + nmi_stack = (char *)kmem_malloc(kernel_arena, PAGE_SIZE, + M_WAITOK | M_ZERO); + dpcpu = (void *)kmem_malloc(kernel_arena, DPCPU_SIZE, + M_WAITOK | M_ZERO); bootSTK = (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE - 8; bootAP = cpu; Modified: head/sys/amd64/amd64/pmap.c == --- head/sys/amd64/amd64/pmap.c Wed Aug 7 06:05:57
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 06/18/13 12:48, Andre Oppermann wrote: On 18.06.2013 18:40, Tijl Coosemans wrote: On 2013-06-18 04:53, Peter Wemm wrote: Author: peter Date: Tue Jun 18 02:53:45 2013 New Revision: 251886 URL: http://svnweb.freebsd.org/changeset/base/251886 Log: Introduce svnlite so that we can check out our source code again. This is actually a fully functional build except: * All internal shared libraries are static linked to make sure there is no interference with ports (and to reduce build time). * It does not have the python/perl/etc plugin or API support. * By default, it installs as "svnlite" rather than "svn". * If WITH_SVN added in make.conf, you get "svn". * If WITHOUT_SVNLITE is in make.conf, this is completely disabled. To be absolutely clear, this is not intended for any use other than checking out freebsd source and committing, like we once did with cvs. It should be usable for small scale local repositories that don't need the python/perl plugin architecture. This ties the repo to the oldest supported release, meaning that years from now we won't be able to use some new subversion feature because an old FreeBSD release doesn't support it. AFAIK there is a checkout-only SVN client available, as in cvsup, but I don't remember the name. I don't find it unreasonable to ask developers to install the port. And for users it seems all they need is something like portsnap for base. Portsnap already distributes ports svn so it shouldn't be too hard to adapt it for base. And the extra layer it adds is very convenient. Apart from a bigger than usual update maybe, portsnap users never even noticed it was switched from cvs to svn at some point. Installing SVN from ports is very painful because of the huge dependency chain it carries, with the largest being Python and Perl IIRC. It's net/svnup and is a great replacement for cvs, in my opinion. CVS wasn't used for development for a long while anyway, so there is nothing subversion is replacing that net/svnup wouldn't. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r246362 - head/games/fortune/datfiles
-Rush Limbaugh's 35 Undeniable Truths of Life: > - -(26) The only difference between Mikhail Gorbachev and previous > Soviet - leaders is that he is alive. - - -- "The Limbaugh > Letter," Copyright 1992, EFM Publishing, Inc. -% -Rush Limbaugh's > 35 Undeniable Truths of Life: - -(27) Soviet leaders were actually > left-wing dictators. - - -- "The Limbaugh Letter," Copyright 1992, > EFM Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of > Life: - -(28) Abraham Lincoln saved this nation. - - -- "The > Limbaugh Letter," Copyright 1992, EFM Publishing, Inc. -% -Rush > Limbaugh's 35 Undeniable Truths of Life: - -(29) The Los Angeles > Raiders will never be the team they were when they - called > Oakland home. - - -- "The Limbaugh Letter," Copyright 1992, EFM > Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: > - -(3) Peace does not mean the elimination of nuclear weapons. - - > -- "The Limbaugh Letter," Copyright 1992, EFM Publishing, Inc. -% > -Rush Limbaugh's 35 Undeniable Truths of Life: - -(30) The United > States will again go to war. - - -- "The Limbaugh Letter," > Copyright 1992, EFM Publishing, Inc. -% -Rush Limbaugh's 35 > Undeniable Truths of Life: - -(31) To more and more American > intellectuals, a victorious United States - is a sinful United > States. - - -- "The Limbaugh Letter," Copyright 1992, EFM > Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: > - -(32) The fact that American intellectuals rue a victorious > United States - is frightening and ominous. - - -- "The > Limbaugh Letter," Copyright 1992, EFM Publishing, Inc. -% -Rush > Limbaugh's 35 Undeniable Truths of Life: - -(33) There will always > be poor people. - - -- "The Limbaugh Letter," Copyright 1992, EFM > Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: > - -(34) The fact that there will always be poor people is not the > fault of - the rich. - - -- "The Limbaugh Letter," Copyright > 1992, EFM Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths > of Life: - -(35) Rather than feel guilty as some do, you should > thank God for making - you an American. - - -- "The Limbaugh > Letter," Copyright 1992, EFM Publishing, Inc. -% -Rush Limbaugh's > 35 Undeniable Truths of Life: - -(4) Peace does not mean the > absence of war. - - -- "The Limbaugh Letter," Copyright 1992, EFM > Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: > - -(5) War is not obsolete. - - -- "The Limbaugh Letter," Copyright > 1992, EFM Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths > of Life: - -(6) Ours is a world governed by the aggressive use of > force. - --- "The Limbaugh Letter," Copyright 1992, EFM > Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: > - -(7) There is only one way to eliminate nuclear weapons. Use > them. - - -- "The Limbaugh Letter," Copyright 1992, EFM Publishing, > Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: - -(8) Peace > cannot be achieved merely by developing an "understanding" - > among peoples. - --- "The Limbaugh Letter," Copyright 1992, EFM > Publishing, Inc. -% -Rush Limbaugh's 35 Undeniable Truths of Life: > - -(9) Americans opposing America is not always sacred nor > courageous ... -it is sometimes dangerous. - --- "The Limbaugh > Letter," Copyright 1992, EFM Publishing, Inc. -% Said a dainty > young whore named Ms. Meggs, "The men like to spread my two legs, > Then slip in between, > ___ > svn-src-h...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-head To > unsubscribe, send any mail to > "svn-src-head-unsubscr...@freebsd.org" > Remove political propaganda -- Why? This is the "offensive" file. It's supposed to have potentially offensive political, sexist, religious, racist, and miscellaneously off content. The man page is clear about this and comes with a warning. - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
