Re: GOST in OPENSSL_BASE
On Sun, Jul 10, 2016 at 06:28:04PM +0300, Andrey Chernov wrote: > On 10.07.2016 18:13, Andrey Chernov wrote: > > On 10.07.2016 18:12, Andrey Chernov wrote: > >> On 10.07.2016 18:01, Slawa Olhovchenkov wrote: > >>> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote: > >>> > On 10.07.2016 16:30, Slawa Olhovchenkov wrote: > > I am surprised lack of support GOST in openssl-base. > > Can be this enabled before 11.0 released? > > AFAIK openssl maintainers says something like they can't support this > code and it will become rotten shortly with new changes, so they drop it. > > >>> > >>> Upstream or FreeBSD maintainers? > >>> > >> > >> Openssl maintainers. > >> > > I.e. upstream. > > > They mean built-in one, dropped from openssl 1.1.0 and above. It is > still available as 3rd party at: > https://github.com/gost-engine/engine I.e. GOST will be available in openssl. Under BSD-like license. Can be this engine import in base system and enabled at time 1.1.0? And can be GOST enabled now? ___ 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"
stable/11 question: kboot vs. powerpc: only powerpc64?
Is the following something that should be updated something like is indicated
below for 11.0-BETA1? Is kboot powerpc64 specific?
# svnlite diff /usr/src/sys/boot/powerpc/Makefile
Index: /usr/src/sys/boot/powerpc/Makefile
===
--- /usr/src/sys/boot/powerpc/Makefile (revision 302457)
+++ /usr/src/sys/boot/powerpc/Makefile (working copy)
@@ -1,5 +1,9 @@
# $FreeBSD$
-SUBDIR=boot1.chrp kboot ofw ps3 uboot
+SUBDIR=boot1.chrp
+.if ${MACHINE_ARCH} == "powerpc64"
+SUBDIR+= kboot
+.endif
+SUBDIR+= ofw ps3 uboot
.include
I ask because I'd submitted 206303 back on 2016-jan-16 reporting that
TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride and a
-mcpu=powerpc64 (one of the base/head/sys/boot/powerpc/kboot/Makefile SRCS
being ppc64_elf_freebsd.c).
===
Mark Millard
markmi at dsl-only.net
___
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: stable/11 question: kboot vs. powerpc: only powerpc64?
It is not 64-bit only; like the normal loader, it can load both 32-bit
and 64-bit kernels. Those two flags are probably obsolete at this point
and were for compatibility with pre-2.17.5 versions of binutils. Can you
do a test build with the -CFLAGS+= -Wa,-mppc64bridge line removed?
-Nathan
On 07/11/16 03:55, Mark Millard wrote:
Is the following something that should be updated something like is indicated
below for 11.0-BETA1? Is kboot powerpc64 specific?
# svnlite diff /usr/src/sys/boot/powerpc/Makefile
Index: /usr/src/sys/boot/powerpc/Makefile
===
--- /usr/src/sys/boot/powerpc/Makefile (revision 302457)
+++ /usr/src/sys/boot/powerpc/Makefile (working copy)
@@ -1,5 +1,9 @@
# $FreeBSD$
-SUBDIR= boot1.chrp kboot ofw ps3 uboot
+SUBDIR=boot1.chrp
+.if ${MACHINE_ARCH} == "powerpc64"
+SUBDIR+= kboot
+.endif
+SUBDIR+= ofw ps3 uboot
.include
I ask because I'd submitted 206303 back on 2016-jan-16 reporting that
TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride and a
-mcpu=powerpc64 (one of the base/head/sys/boot/powerpc/kboot/Makefile SRCS
being ppc64_elf_freebsd.c).
===
Mark Millard
markmi at dsl-only.net
___
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_i386 - Build #3556 - Failure
FreeBSD_HEAD_i386 - Build #3556 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3556/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3556/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3556/console Change summaries: 302564 by rwatson: Add AUE_WAIT6 handling to the BSM conversion switch statement, reusing the BSM encoding used for AUE_WAIT4. MFC after: 3 days Sponsored by: DARPA, AFRL 302561 by ae: Flush buffer after output. This fixes adding new data to already printed flows. PR: 210882 MFC after: 3 days The end of the build log: [...truncated 112799 lines...] --- all_subdir_sys --- --- part.o --- --- all_subdir_lib --- --- thr_clean.po --- --- all_subdir_sys --- cc -O2 -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/usr/src/sys/boot/i386/zfsloader/../../ficl -I/usr/src/sys/boot/i386/zfsloader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/i386/zfsloader/../../.. -D_STAND -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -I/usr/src/sys/boot/i386/zfsloader/../../common -I. -Wall -I/usr/src/sys/boot/i386/zfsloader/.. -I/usr/src/sys/boot/i386/zfsloader/../btx/lib -march=i386 -ffreestanding -mno-mmx -mno-sse -mno-avx -msoft-float -MD -MF.depend.part.o -MTpart.o -std=gnu99-Qunused-arguments -c /usr/src/sys/boot/i386/zfsloader/../../common/part.c -o part.o --- all_subdir_lib --- cc -pg -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -MD -MF.depend.thr_clean.po -MTthr_clean.po -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_clean.c -o thr_clean.po --- thr_concurrency.po --- cc -pg -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -MD -MF.depend.thr_concurrency.po -MTthr_concurrency.po -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_concurrency.c -o thr_concurrency.po --- thr_cond.po --- cc -pg -O2 -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHREADS_INVARIANTS -mno-mmx -mno-sse -mno-avx -MD -MF.depend.thr_cond.po -MTthr_cond.po -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/libthr/thread/thr_cond.c -o thr_cond.po --- all_subdir_sys --- --- crc32.o --- cc -O2 -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/usr/src/sys/boot/i386/zfsloader/../../ficl -I/usr/src/sys/boot/i386/zfsloader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GELI_SUPPORT -I/usr/src/sys/boot/i386/zfsloader/../../.. -D_STAND -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -I/usr/src/sys/boot/i386/zfsloader/../../common -I. -Wall -I/usr/src/sys/boot/i386/zfsloader/.. -I/usr/src/sys/boot/i386/zfsloader/../btx/lib -march=i386 -ffreestanding -mno-mmx -mno-sse -mno-avx -msoft-f
Re: GOST in OPENSSL_BASE
On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote: > > > On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote: > > > > I.e. GOST will be available in openssl. > > Under BSD-like license. > > Can be this engine import in base system and enabled at time 1.1.0? > > And can be GOST enabled now? > > > > I think the wrong question is being asked here. Instead we need to focus > on decoupling openssl from base so this can all be handled by ports. This is wrong direction with current policy. ports: unsupported by FreeBSD core and securite team, no guaranted to comaptible between options and applications. base: supported by FreeBSD core and securite team, covered by CI, checked for forward and backward API and ABI compatibility. ___ 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_i386 - Build #3557 - Fixed
FreeBSD_HEAD_i386 - Build #3557 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3557/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3557/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3557/console Change summaries: 302567 by kib: In vgonel(), postpone setting BO_DEAD until VOP_RECLAIM() is called, if vnode is VMIO. For VMIO vnodes, set BO_DEAD in vm_object_terminate(). The vnode_destroy_object(), when calling into vm_object_terminate(), must be able to flush buffers. BO_DEAD purpose is to quickly destroy buffers on write when the underlying vnode is not operable any more (one example is the devfs node after geom is gone). Setting BO_DEAD for reclaiming vnode before object is terminated is premature, and results in unability to flush buffers with live SU dependencies from vinvalbuf() in vm_object_terminate(). Reported by:David Cross Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks 302566 by gjb: Fix the naming of -CURRENT Sponsored by: The FreeBSD Foundation 302565 by cy: r302561 broke buildworld. This patch fixes that. MFC after: 3 days X-MFC with: r302561 ___ 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: GOST in OPENSSL_BASE
On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote: > > I.e. GOST will be available in openssl. > Under BSD-like license. > Can be this engine import in base system and enabled at time 1.1.0? > And can be GOST enabled now? > I think the wrong question is being asked here. Instead we need to focus on decoupling openssl from base so this can all be handled by ports. -- Mark Felder f...@feld.me ___ 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: GOST in OPENSSL_BASE
Hi! > > I.e. GOST will be available in openssl. > > Under BSD-like license. > > Can be this engine import in base system and enabled at time 1.1.0? > > And can be GOST enabled now? > I think the wrong question is being asked here. Instead we need to focus > on decoupling openssl from base so this can all be handled by ports. As far as I know, GOST is a standardized crypto algo in .ru, it's suggested (required?) by the government in .ru. So, if FreeBSD does not want to alienate the .ru userbase, GOST probably should be in base. I'm not sure how difficult that would be. -- 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: GOST in OPENSSL_BASE
On 11.07.2016 19:29, Slawa Olhovchenkov wrote: > On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote: > >> >> >> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote: >>> >>> I.e. GOST will be available in openssl. >>> Under BSD-like license. >>> Can be this engine import in base system and enabled at time 1.1.0? >>> And can be GOST enabled now? >>> >> >> I think the wrong question is being asked here. Instead we need to focus >> on decoupling openssl from base so this can all be handled by ports. > > This is wrong direction with current policy. > ports: unsupported by FreeBSD core and securite team, no guaranted to > comaptible > between options and applications. > > base: supported by FreeBSD core and securite team, covered by CI, > checked for forward and backward API and ABI compatibility. > Ports are supported by secteam, and recently I notice "headsup" mail with intention to make base openssl private and switch all ports to security/openssl port. Adding of GOST as 3rd party plugin is technically possible in both (base, ports) cases, the rest of decision is up to FreeBSD openssl maintainers and possible contributors efforts. I need to specially point to "patches" section of the 3rd party GOST plugin, from just viewing I don't understand, are those additional openssl patches should be applied to openssl for GOST, or they are just reflect existent changes in the openssl. ___ 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: GOST in OPENSSL_BASE
On 07/10/16 09:30 AM, Slawa Olhovchenkov wrote: > I am surprised lack of support GOST in openssl-base. > Can be this enabled before 11.0 released? It works for me, I think. The following change was all I need to enable the engine: --- /etc/ssl/openssl.cnf.orig +++ /etc/ssl/openssl.cnf @@ -13,6 +13,21 @@ #oid_file = $ENV::HOME/.oid oid_section= new_oids +# GOST +openssl_conf = openssl_def + +[openssl_def] +engines= engine_section + +[engine_section] +gost = gost_section + +[gost_section] +engine_id = gost +dynamic_path = /usr/lib/engines/libgost.so +default_algorithms = ALL +CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet + # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: Please see the README file for more info: https://svnweb.freebsd.org/base/head/crypto/openssl/engines/ccgost/README.gost?revision=238405&view=co Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: stable/11 question: kboot vs. powerpc: only powerpc64?
On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn wrote:
>
> It is not 64-bit only; like the normal loader, it can load both 32-bit and
> 64-bit kernels. Those two flags are probably obsolete at this point and were
> for compatibility with pre-2.17.5 versions of binutils. Can you do a test
> build with the -CFLAGS+= -Wa,-mppc64bridge line removed?
> -Nathan
>
> On 07/11/16 03:55, Mark Millard wrote:
>> Is the following something that should be updated something like is
>> indicated below for 11.0-BETA1? Is kboot powerpc64 specific?
>>
>> # svnlite diff /usr/src/sys/boot/powerpc/Makefile
>> Index: /usr/src/sys/boot/powerpc/Makefile
>> ===
>> --- /usr/src/sys/boot/powerpc/Makefile (revision 302457)
>> +++ /usr/src/sys/boot/powerpc/Makefile (working copy)
>> @@ -1,5 +1,9 @@
>> # $FreeBSD$
>> -SUBDIR=boot1.chrp kboot ofw ps3 uboot
>> +SUBDIR= boot1.chrp
>> +.if ${MACHINE_ARCH} == "powerpc64"
>> +SUBDIR+=kboot
>> +.endif
>> +SUBDIR+=ofw ps3 uboot
>>.include
>>
>>
>>
>> I ask because I'd submitted 206303 back on 2016-jan-16 reporting that
>> TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride and
>> a -mcpu=powerpc64 (one of the base/head/sys/boot/powerpc/kboot/Makefile SRCS
>> being ppc64_elf_freebsd.c).
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
I do not have access to powerpc's currently so I'm just going to be doing
cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from
amd64) based on the below updates.
You initially mention "two flags" but then only explicitly request removal of
one (the -CFLAGS+= -Wa,-mppc64bridge line).
I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc (non-64)
is to be covered. See my intended test below. Let me know if it is not what you
want.
> # svnlite diff sys/boot/powerpc/kboot/Makefile
> Index: sys/boot/powerpc/kboot/Makefile
> ===
> --- sys/boot/powerpc/kboot/Makefile (revision 302457)
> +++ sys/boot/powerpc/kboot/Makefile (working copy)
> @@ -71,7 +71,7 @@
> # Avoid the open-close-dance for every file access as some firmwares perform
> # an auto-negotiation on every open of the network interface and thus causes
> # netbooting to take horribly long.
> -CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
> +CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE
>
> # Always add MI sources
> .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
> @@ -88,9 +88,6 @@
>
> LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
>
> -# 64-bit bridge extensions
> -CFLAGS+= -Wa,-mppc64bridge
> -
> # Pull in common loader code
> #.PATH: ${.CURDIR}/../../ofw/common
> #.include"${.CURDIR}/../../ofw/common/Makefile.inc"
> # svnlite diff sys/boot/powerpc/Makefile
> #
(I.e., I reverted sys/boot/powerpc/Makefile.)
===
Mark Millard
markmi at dsl-only.net
___
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: GOST in OPENSSL_BASE
On 07/10/16 10:10 AM, Andrey Chernov wrote: > On 10.07.2016 16:30, Slawa Olhovchenkov wrote: >> I am surprised lack of support GOST in openssl-base. >> Can be this enabled before 11.0 released? > > AFAIK openssl maintainers says something like they can't support this > code and it will become rotten shortly with new changes, so they drop it. [OpenSSL-maintainer-for-the-base hat on] GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on these branches unless secteam explicitly ask us to do so. However, we *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch. [OpenSSL-maintainer-for-the-base hat off] Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: stable/11 question: kboot vs. powerpc: only powerpc64?
On 2016-Jul-11, at 11:04 AM, Mark Millard wrote:
> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn wrote:
>>
>> It is not 64-bit only; like the normal loader, it can load both 32-bit and
>> 64-bit kernels. Those two flags are probably obsolete at this point and were
>> for compatibility with pre-2.17.5 versions of binutils. Can you do a test
>> build with the -CFLAGS+= -Wa,-mppc64bridge line removed?
>> -Nathan
>>
>> On 07/11/16 03:55, Mark Millard wrote:
>>> Is the following something that should be updated something like is
>>> indicated below for 11.0-BETA1? Is kboot powerpc64 specific?
>>>
>>> # svnlite diff /usr/src/sys/boot/powerpc/Makefile
>>> Index: /usr/src/sys/boot/powerpc/Makefile
>>> ===
>>> --- /usr/src/sys/boot/powerpc/Makefile (revision 302457)
>>> +++ /usr/src/sys/boot/powerpc/Makefile (working copy)
>>> @@ -1,5 +1,9 @@
>>> # $FreeBSD$
>>> -SUBDIR=boot1.chrp kboot ofw ps3 uboot
>>> +SUBDIR=boot1.chrp
>>> +.if ${MACHINE_ARCH} == "powerpc64"
>>> +SUBDIR+= kboot
>>> +.endif
>>> +SUBDIR+= ofw ps3 uboot
>>> .include
>>>
>>>
>>>
>>> I ask because I'd submitted 206303 back on 2016-jan-16 reporting that
>>> TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride
>>> and a -mcpu=powerpc64 (one of the base/head/sys/boot/powerpc/kboot/Makefile
>>> SRCS being ppc64_elf_freebsd.c).
>>>
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>
> I do not have access to powerpc's currently so I'm just going to be doing
> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from
> amd64) based on the below updates.
>
> You initially mention "two flags" but then only explicitly request removal of
> one (the -CFLAGS+= -Wa,-mppc64bridge line).
>
> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc
> (non-64) is to be covered. See my intended test below. Let me know if it is
> not what you want.
>
>> # svnlite diff sys/boot/powerpc/kboot/Makefile
>> Index: sys/boot/powerpc/kboot/Makefile
>> ===
>> --- sys/boot/powerpc/kboot/Makefile (revision 302457)
>> +++ sys/boot/powerpc/kboot/Makefile (working copy)
>> @@ -71,7 +71,7 @@
>> # Avoid the open-close-dance for every file access as some firmwares perform
>> # an auto-negotiation on every open of the network interface and thus causes
>> # netbooting to take horribly long.
>> -CFLAGS+=-DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
>> +CFLAGS+=-DNETIF_OPEN_CLOSE_ONCE
>>
>> # Always add MI sources
>> .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
>> @@ -88,9 +88,6 @@
>>
>> LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
>>
>> -# 64-bit bridge extensions
>> -CFLAGS+= -Wa,-mppc64bridge
>> -
>> # Pull in common loader code
>> #.PATH: ${.CURDIR}/../../ofw/common
>> #.include"${.CURDIR}/../../ofw/common/Makefile.inc"
>
>> # svnlite diff sys/boot/powerpc/Makefile
>> #
>
> (I.e., I reverted sys/boot/powerpc/Makefile.)
>
> ===
> Mark Millard
> markmi at dsl-only.net
The TARGET_ARCH=powerpc build completed with the following messages (from
grep'ing for kboot in the typescript file):
> ===> sys/boot/powerpc/kboot (all)
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
> Building
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is
> uninitialized when used here [-Wuninitialized]
> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the variable
> 'sp' to silence this warning
> Building
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.o
> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: implicit
> declaration of function 'md_load64' is invalid in C99
> [-Wimplicit-function-declaration]
> Building
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall.o
> Building
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o
> Building
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o
> Building
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.o
> Building
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o
> --- kbootfdt.o ---
> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing 'const
> char *' to parameter of type 'char *' discards qualifiers
> [-Wincompatible-pointer-types-discards-qualifiers]
> /usr/src/sys/boot/powerpc/kboot/host_syscall.h:36:21: note: passing argument
> to parameter 'path'
Re: GOST in OPENSSL_BASE
On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
> On 07/10/16 10:10 AM, Andrey Chernov wrote:
> > On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> >> I am surprised lack of support GOST in openssl-base.
> >> Can be this enabled before 11.0 released?
> >
> > AFAIK openssl maintainers says something like they can't support this
> > code and it will become rotten shortly with new changes, so they drop it.
>
> [OpenSSL-maintainer-for-the-base hat on]
>
> GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on
> these branches unless secteam explicitly ask us to do so. However, we
> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
>
> [OpenSSL-maintainer-for-the-base hat off]
>
> Jung-uk Kim
>
Thanks!
May be need file PR for dns/bind910?
# grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
.include
.if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && ${SSL_DEFAULT}
== base
BROKEN= OpenSSL from the base system does not support GOST, add \
DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild
everything \
that needs SSL.
.endif
___
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: stable/11 question: kboot vs. powerpc: only powerpc64?
On 2016-Jul-11, at 11:30 AM, Mark Millard wrote:
> On 2016-Jul-11, at 11:04 AM, Mark Millard wrote:
>
>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn wrote:
>>>
>>> It is not 64-bit only; like the normal loader, it can load both 32-bit and
>>> 64-bit kernels. Those two flags are probably obsolete at this point and
>>> were for compatibility with pre-2.17.5 versions of binutils. Can you do a
>>> test build with the -CFLAGS+= -Wa,-mppc64bridge line removed?
>>> -Nathan
>>>
>>> On 07/11/16 03:55, Mark Millard wrote:
Is the following something that should be updated something like is
indicated below for 11.0-BETA1? Is kboot powerpc64 specific?
# svnlite diff /usr/src/sys/boot/powerpc/Makefile
Index: /usr/src/sys/boot/powerpc/Makefile
===
--- /usr/src/sys/boot/powerpc/Makefile (revision 302457)
+++ /usr/src/sys/boot/powerpc/Makefile (working copy)
@@ -1,5 +1,9 @@
# $FreeBSD$
-SUBDIR= boot1.chrp kboot ofw ps3 uboot
+SUBDIR= boot1.chrp
+.if ${MACHINE_ARCH} == "powerpc64"
+SUBDIR+= kboot
+.endif
+SUBDIR+= ofw ps3 uboot
.include
I ask because I'd submitted 206303 back on 2016-jan-16 reporting that
TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride
and a -mcpu=powerpc64 (one of the
base/head/sys/boot/powerpc/kboot/Makefile SRCS being ppc64_elf_freebsd.c).
===
Mark Millard
markmi at dsl-only.net
>>
>> I do not have access to powerpc's currently so I'm just going to be doing
>> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from
>> amd64) based on the below updates.
>>
>> You initially mention "two flags" but then only explicitly request removal
>> of one (the -CFLAGS+= -Wa,-mppc64bridge line).
>>
>> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc
>> (non-64) is to be covered. See my intended test below. Let me know if it is
>> not what you want.
>>
>>> # svnlite diff sys/boot/powerpc/kboot/Makefile
>>> Index: sys/boot/powerpc/kboot/Makefile
>>> ===
>>> --- sys/boot/powerpc/kboot/Makefile (revision 302457)
>>> +++ sys/boot/powerpc/kboot/Makefile (working copy)
>>> @@ -71,7 +71,7 @@
>>> # Avoid the open-close-dance for every file access as some firmwares perform
>>> # an auto-negotiation on every open of the network interface and thus causes
>>> # netbooting to take horribly long.
>>> -CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
>>> +CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE
>>>
>>> # Always add MI sources
>>> .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
>>> @@ -88,9 +88,6 @@
>>>
>>> LDFLAGS=-nostdlib -static -T ${.CURDIR}/ldscript.powerpc
>>>
>>> -# 64-bit bridge extensions
>>> -CFLAGS+= -Wa,-mppc64bridge
>>> -
>>> # Pull in common loader code
>>> #.PATH: ${.CURDIR}/../../ofw/common
>>> #.include "${.CURDIR}/../../ofw/common/Makefile.inc"
>>
>>> # svnlite diff sys/boot/powerpc/Makefile
>>> #
>>
>> (I.e., I reverted sys/boot/powerpc/Makefile.)
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>
> The TARGET_ARCH=powerpc build completed with the following messages (from
> grep'ing for kboot in the typescript file):
>
>> ===> sys/boot/powerpc/kboot (all)
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
>> Building
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is
>> uninitialized when used here [-Wuninitialized]
>> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the variable
>> 'sp' to silence this warning
>> Building
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.o
>> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: implicit
>> declaration of function 'md_load64' is invalid in C99
>> [-Wimplicit-function-declaration]
>> Building
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall.o
>> Building
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o
>> Building
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o
>> Building
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.o
>> Building
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o
>> --- kbootfdt.o ---
>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing 'const
>> char *' to parameter of type 'char *' discards qualifi
Re: GOST in OPENSSL_BASE
On 07/11/16 02:41 PM, Slawa Olhovchenkov wrote:
> On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
>
>> On 07/10/16 10:10 AM, Andrey Chernov wrote:
>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
I am surprised lack of support GOST in openssl-base.
Can be this enabled before 11.0 released?
>>>
>>> AFAIK openssl maintainers says something like they can't support this
>>> code and it will become rotten shortly with new changes, so they drop it.
>>
>> [OpenSSL-maintainer-for-the-base hat on]
>>
>> GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on
>> these branches unless secteam explicitly ask us to do so. However, we
>> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
>>
>> [OpenSSL-maintainer-for-the-base hat off]
>>
>> Jung-uk Kim
>>
>
> Thanks!
>
> May be need file PR for dns/bind910?
>
> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> .include
>
> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && ${SSL_DEFAULT}
> == base
> BROKEN= OpenSSL from the base system does not support GOST, add \
> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild
> everything \
> that needs SSL.
> .endif
FreeBSD 9.3 is still supported but GOST is not available there. It
seems the ports maintainer didn't want to break it on 9.3 (CC added).
Version check may be needed there.
Jung-uk Kim
signature.asc
Description: OpenPGP digital signature
Re: GOST in OPENSSL_BASE
On Mon, Jul 11, 2016 at 03:00:39PM -0400, Jung-uk Kim wrote:
> On 07/11/16 02:41 PM, Slawa Olhovchenkov wrote:
> > On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
> >
> >> On 07/10/16 10:10 AM, Andrey Chernov wrote:
> >>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> I am surprised lack of support GOST in openssl-base.
> Can be this enabled before 11.0 released?
> >>>
> >>> AFAIK openssl maintainers says something like they can't support this
> >>> code and it will become rotten shortly with new changes, so they drop it.
> >>
> >> [OpenSSL-maintainer-for-the-base hat on]
> >>
> >> GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on
> >> these branches unless secteam explicitly ask us to do so. However, we
> >> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
> >>
> >> [OpenSSL-maintainer-for-the-base hat off]
> >>
> >> Jung-uk Kim
> >>
> >
> > Thanks!
> >
> > May be need file PR for dns/bind910?
> >
> > # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> > .include
> >
> > .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
> > ${SSL_DEFAULT} == base
> > BROKEN= OpenSSL from the base system does not support GOST, add \
> > DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild
> > everything \
> > that needs SSL.
> > .endif
>
> FreeBSD 9.3 is still supported but GOST is not available there. It
Thanks for clarifications.
> seems the ports maintainer didn't want to break it on 9.3 (CC added).
> Version check may be needed there.
Thanks!
> Jung-uk Kim
>
___
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: GOST in OPENSSL_BASE
On Mon, Jul 11, 2016 at 07:48:44PM +0300, Andrey Chernov wrote: > On 11.07.2016 19:29, Slawa Olhovchenkov wrote: > > On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote: > > > >> > >> > >> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote: > >>> > >>> I.e. GOST will be available in openssl. > >>> Under BSD-like license. > >>> Can be this engine import in base system and enabled at time 1.1.0? > >>> And can be GOST enabled now? > >>> > >> > >> I think the wrong question is being asked here. Instead we need to focus > >> on decoupling openssl from base so this can all be handled by ports. > > > > This is wrong direction with current policy. > > ports: unsupported by FreeBSD core and securite team, no guaranted to > > comaptible > > between options and applications. > > > > base: supported by FreeBSD core and securite team, covered by CI, > > checked for forward and backward API and ABI compatibility. > > > > Ports are supported by secteam, and recently I notice "headsup" mail > with intention to make base openssl private and switch all ports to > security/openssl port. I mean `support` is commit reviewing, auditing and etc. Secteam do it for ports? > Adding of GOST as 3rd party plugin is technically possible in both > (base, ports) cases, the rest of decision is up to FreeBSD openssl > maintainers and possible contributors efforts. > > I need to specially point to "patches" section of the 3rd party GOST > plugin, from just viewing I don't understand, are those additional > openssl patches should be applied to openssl for GOST, or they are just > reflect existent changes in the openssl. > > ___ > freebsd-secur...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-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: stable/11 question: kboot vs. powerpc: only powerpc64?
Quick top-post just to indicate that I just did gcc 4.2.1 based cross-builds
for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 and they completed. They had
analogous warnings to what clang (powerpc) and powerpc64-gcc (powerpc64)
produced.
I do not have a context to test powerpc64 or powerpc kboot in.
I'll enter a report showing the sys/boot/powerpc/kboot/Makefile change that I
tried.
===
Mark Millard
markmi at dsl-only.net
On 2016-Jul-11, at 11:43 AM, Mark Millard wrote:
> On 2016-Jul-11, at 11:30 AM, Mark Millard wrote:
>
>> On 2016-Jul-11, at 11:04 AM, Mark Millard wrote:
>>
>>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn wrote:
It is not 64-bit only; like the normal loader, it can load both 32-bit and
64-bit kernels. Those two flags are probably obsolete at this point and
were for compatibility with pre-2.17.5 versions of binutils. Can you do a
test build with the -CFLAGS+= -Wa,-mppc64bridge line removed?
-Nathan
On 07/11/16 03:55, Mark Millard wrote:
> Is the following something that should be updated something like is
> indicated below for 11.0-BETA1? Is kboot powerpc64 specific?
>
> # svnlite diff /usr/src/sys/boot/powerpc/Makefile
> Index: /usr/src/sys/boot/powerpc/Makefile
> ===
> --- /usr/src/sys/boot/powerpc/Makefile(revision 302457)
> +++ /usr/src/sys/boot/powerpc/Makefile(working copy)
> @@ -1,5 +1,9 @@
> # $FreeBSD$
> -SUBDIR= boot1.chrp kboot ofw ps3 uboot
> +SUBDIR= boot1.chrp
> +.if ${MACHINE_ARCH} == "powerpc64"
> +SUBDIR+= kboot
> +.endif
> +SUBDIR+= ofw ps3 uboot
> .include
>
>
>
> I ask because I'd submitted 206303 back on 2016-jan-16 reporting that
> TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride
> and a -mcpu=powerpc64 (one of the
> base/head/sys/boot/powerpc/kboot/Makefile SRCS being ppc64_elf_freebsd.c).
>
> ===
> Mark Millard
> markmi at dsl-only.net
>>>
>>> I do not have access to powerpc's currently so I'm just going to be doing
>>> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from
>>> amd64) based on the below updates.
>>>
>>> You initially mention "two flags" but then only explicitly request removal
>>> of one (the -CFLAGS+= -Wa,-mppc64bridge line).
>>>
>>> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc
>>> (non-64) is to be covered. See my intended test below. Let me know if it is
>>> not what you want.
>>>
# svnlite diff sys/boot/powerpc/kboot/Makefile
Index: sys/boot/powerpc/kboot/Makefile
===
--- sys/boot/powerpc/kboot/Makefile(revision 302457)
+++ sys/boot/powerpc/kboot/Makefile(working copy)
@@ -71,7 +71,7 @@
# Avoid the open-close-dance for every file access as some firmwares
perform
# an auto-negotiation on every open of the network interface and thus
causes
# netbooting to take horribly long.
-CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
+CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE
# Always add MI sources
.PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
@@ -88,9 +88,6 @@
LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
-# 64-bit bridge extensions
-CFLAGS+= -Wa,-mppc64bridge
-
# Pull in common loader code
#.PATH:${.CURDIR}/../../ofw/common
#.include "${.CURDIR}/../../ofw/common/Makefile.inc"
>>>
# svnlite diff sys/boot/powerpc/Makefile
#
>>>
>>> (I.e., I reverted sys/boot/powerpc/Makefile.)
>>>
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>>
>> The TARGET_ARCH=powerpc build completed with the following messages (from
>> grep'ing for kboot in the typescript file):
>>
>>> ===> sys/boot/powerpc/kboot (all)
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
>>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is
>>> uninitialized when used here [-Wuninitialized]
>>> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the
>>> variable 'sp' to silence this warning
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.o
>>> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning:
>>> implicit declaration of function 'md_load64' is invalid in C99
>>> [-Wimplicit-func
FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
Hi, Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on Windows 10. It complained that the ISO is too big for my 700 MB CD-r. The bootonly iso (281MB) burns and runs ok. Regards, Ronald. ___ 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: stable/11 question: kboot vs. powerpc: only powerpc64?
On 2016-Jul-11, at 1:51 PM, Mark Millard wrote:
> Quick top-post just to indicate that I just did gcc 4.2.1 based cross-builds
> for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 and they completed. They
> had analogous warnings to what clang (powerpc) and powerpc64-gcc (powerpc64)
> produced.
>
> I do not have a context to test powerpc64 or powerpc kboot in.
>
> I'll enter a report showing the sys/boot/powerpc/kboot/Makefile change that I
> tried.
>
> ===
> Mark Millard
> markmi at dsl-only.net
I've updated 206303 ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206303
) with Comment 2 and 206303's Version is now set to 11.0-BETA1 since the odd
powerpc64 options are present in 11.0-BETA1 (-r302457 is where I'm currently
synchronized to).
===
Mark Millard
markmi at dsl-only.net
On 2016-Jul-11, at 11:43 AM, Mark Millard wrote:
> On 2016-Jul-11, at 11:30 AM, Mark Millard wrote:
>
>> On 2016-Jul-11, at 11:04 AM, Mark Millard wrote:
>>
>>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn wrote:
It is not 64-bit only; like the normal loader, it can load both 32-bit and
64-bit kernels. Those two flags are probably obsolete at this point and
were for compatibility with pre-2.17.5 versions of binutils. Can you do a
test build with the -CFLAGS+= -Wa,-mppc64bridge line removed?
-Nathan
On 07/11/16 03:55, Mark Millard wrote:
> Is the following something that should be updated something like is
> indicated below for 11.0-BETA1? Is kboot powerpc64 specific?
>
> # svnlite diff /usr/src/sys/boot/powerpc/Makefile
> Index: /usr/src/sys/boot/powerpc/Makefile
> ===
> --- /usr/src/sys/boot/powerpc/Makefile(revision 302457)
> +++ /usr/src/sys/boot/powerpc/Makefile(working copy)
> @@ -1,5 +1,9 @@
> # $FreeBSD$
> -SUBDIR= boot1.chrp kboot ofw ps3 uboot
> +SUBDIR= boot1.chrp
> +.if ${MACHINE_ARCH} == "powerpc64"
> +SUBDIR+= kboot
> +.endif
> +SUBDIR+= ofw ps3 uboot
> .include
>
>
>
> I ask because I'd submitted 206303 back on 2016-jan-16 reporting that
> TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride
> and a -mcpu=powerpc64 (one of the
> base/head/sys/boot/powerpc/kboot/Makefile SRCS being ppc64_elf_freebsd.c).
>
> ===
> Mark Millard
> markmi at dsl-only.net
>>>
>>> I do not have access to powerpc's currently so I'm just going to be doing
>>> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from
>>> amd64) based on the below updates.
>>>
>>> You initially mention "two flags" but then only explicitly request removal
>>> of one (the -CFLAGS+= -Wa,-mppc64bridge line).
>>>
>>> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc
>>> (non-64) is to be covered. See my intended test below. Let me know if it is
>>> not what you want.
>>>
# svnlite diff sys/boot/powerpc/kboot/Makefile
Index: sys/boot/powerpc/kboot/Makefile
===
--- sys/boot/powerpc/kboot/Makefile(revision 302457)
+++ sys/boot/powerpc/kboot/Makefile(working copy)
@@ -71,7 +71,7 @@
# Avoid the open-close-dance for every file access as some firmwares
perform
# an auto-negotiation on every open of the network interface and thus
causes
# netbooting to take horribly long.
-CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
+CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE
# Always add MI sources
.PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
@@ -88,9 +88,6 @@
LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
-# 64-bit bridge extensions
-CFLAGS+= -Wa,-mppc64bridge
-
# Pull in common loader code
#.PATH:${.CURDIR}/../../ofw/common
#.include "${.CURDIR}/../../ofw/common/Makefile.inc"
>>>
# svnlite diff sys/boot/powerpc/Makefile
#
>>>
>>> (I.e., I reverted sys/boot/powerpc/Makefile.)
>>>
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>>
>> The TARGET_ARCH=powerpc build completed with the following messages (from
>> grep'ing for kboot in the typescript file):
>>
>>> ===> sys/boot/powerpc/kboot (all)
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
>>> Building
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
>>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is
>>> uninitialized when used here [-Wuninitialized]
>>>
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
DVD-R dates to 1997; cheap USB flash devices are now pervasive. Maybe it's time to move on from CD. Best, Conrad On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: > Hi, > > Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on > Windows 10. It complained that the ISO is too big for my 700 MB CD-r. > > The bootonly iso (281MB) burns and runs ok. > > Regards, > Ronald. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
> On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: >> Hi, >> >> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on >> Windows 10. It complained that the ISO is too big for my 700 MB CD-r. >> >> The bootonly iso (281MB) burns and runs ok. >> >> Regards, >> Ronald. Please open a PR. Those images should be able to fit on a CD. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: > > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: > >> Hi, > >> > >> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on > >> Windows 10. It complained that the ISO is too big for my 700 MB CD-r. > >> > >> The bootonly iso (281MB) burns and runs ok. > >> > >> Regards, > >> Ronald. > > Please open a PR. Those images should be able to fit on a CD. This was actually a known "going to be problem" thing for 11.0. I'm looking into how to fix this for 11.0-RELEASE, but right now, there is not much more we can exclude from it. :( Glen signature.asc Description: PGP signature
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote: > On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: > > > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: > > >> Hi, > > >> > > >> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on > > >> Windows 10. It complained that the ISO is too big for my 700 MB CD-r. > > >> > > >> The bootonly iso (281MB) burns and runs ok. > > >> > > >> Regards, > > >> Ronald. > > > > Please open a PR. Those images should be able to fit on a CD. > > This was actually a known "going to be problem" thing for 11.0. I'm > looking into how to fix this for 11.0-RELEASE, but right now, there is > not much more we can exclude from it. :( Reduce GENERIC to MINIMAL? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
Glen Barber wrote: On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: Hi, Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on Windows 10. It complained that the ISO is too big for my 700 MB CD-r. The bootonly iso (281MB) burns and runs ok. Regards, Ronald. Please open a PR. Those images should be able to fit on a CD. This was actually a known "going to be problem" thing for 11.0. I'm looking into how to fix this for 11.0-RELEASE, but right now, there is not much more we can exclude from it. :( Glen I burned 11.0-ALPHA6 to a 700 MB CD-r using "cdrecord -sao -overburn -disc1.iso" ___ 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: GOST in OPENSSL_BASE
On 11.07.2016 23:13, Slawa Olhovchenkov wrote: > On Mon, Jul 11, 2016 at 07:48:44PM +0300, Andrey Chernov wrote: > >> On 11.07.2016 19:29, Slawa Olhovchenkov wrote: >>> On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote: >>> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote: > > I.e. GOST will be available in openssl. > Under BSD-like license. > Can be this engine import in base system and enabled at time 1.1.0? > And can be GOST enabled now? > I think the wrong question is being asked here. Instead we need to focus on decoupling openssl from base so this can all be handled by ports. >>> >>> This is wrong direction with current policy. >>> ports: unsupported by FreeBSD core and securite team, no guaranted to >>> comaptible >>> between options and applications. >>> >>> base: supported by FreeBSD core and securite team, covered by CI, >>> checked for forward and backward API and ABI compatibility. >>> >> >> Ports are supported by secteam, and recently I notice "headsup" mail >> with intention to make base openssl private and switch all ports to >> security/openssl port. > > I mean `support` is commit reviewing, auditing and etc. > Secteam do it for ports? At least CVEs are tracked. You better ask about whole list of ports secteam duties secteam themselves. > >> Adding of GOST as 3rd party plugin is technically possible in both >> (base, ports) cases, the rest of decision is up to FreeBSD openssl >> maintainers and possible contributors efforts. >> >> I need to specially point to "patches" section of the 3rd party GOST >> plugin, from just viewing I don't understand, are those additional >> openssl patches should be applied to openssl for GOST, or they are just >> reflect existent changes in the openssl. >> >> ___ >> freebsd-secur...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov wrote > On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote: > > > On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: > > > > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop > > > wrote: >> Hi, > > > >> > > > >> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on > > > >> Windows 10. It complained that the ISO is too big for my 700 MB CD-r. > > > >> > > > >> The bootonly iso (281MB) burns and runs ok. > > > >> > > > >> Regards, > > > >> Ronald. > > > > > > Please open a PR. Those images should be able to fit on a CD. > > > > This was actually a known "going to be problem" thing for 11.0. I'm > > looking into how to fix this for 11.0-RELEASE, but right now, there is > > not much more we can exclude from it. :( Can't it use the compressed iso format, or is it already using that format. Sorry haven't checked. > > Reduce GENERIC to MINIMAL? --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On 2016-07-11 18:33, Chris H wrote: On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov wrote On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote: On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: >> Hi, Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on Windows 10. It complained that the ISO is too big for my 700 MB CD-r. The bootonly iso (281MB) burns and runs ok. Regards, Ronald. Please open a PR. Those images should be able to fit on a CD. This was actually a known "going to be problem" thing for 11.0. I'm looking into how to fix this for 11.0-RELEASE, but right now, there is not much more we can exclude from it. :( Can't it use the compressed iso format, or is it already using that format. Sorry haven't checked. Reduce GENERIC to MINIMAL? --Chris ___ 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" 380MB of the data on disc1 is the distsets, which are already .txz (max compression). That doesn't leave much room for the live OS on the disk. -- Allan Jude ___ 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: GOST in OPENSSL_BASE
On 11.07.2016 21:41, Slawa Olhovchenkov wrote:
> On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
>
>> On 07/10/16 10:10 AM, Andrey Chernov wrote:
>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
I am surprised lack of support GOST in openssl-base.
Can be this enabled before 11.0 released?
>>>
>>> AFAIK openssl maintainers says something like they can't support this
>>> code and it will become rotten shortly with new changes, so they drop it.
>>
>> [OpenSSL-maintainer-for-the-base hat on]
>>
>> GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on
>> these branches unless secteam explicitly ask us to do so. However, we
>> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
>>
>> [OpenSSL-maintainer-for-the-base hat off]
>>
>> Jung-uk Kim
>>
>
> Thanks!
>
> May be need file PR for dns/bind910?
>
> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> .include
>
> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && ${SSL_DEFAULT}
> == base
> BROKEN= OpenSSL from the base system does not support GOST, add \
> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild
> everything \
> that needs SSL.
> .endif
>
I dislike idea to use GOST in the bind, it is unneeded there, DNSSEC
don't use GOST, so I vote for removing GOST option from there.
___
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: GOST in OPENSSL_BASE
On 12.07.2016 1:44, Andrey Chernov wrote:
> On 11.07.2016 21:41, Slawa Olhovchenkov wrote:
>> On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
>>
>>> On 07/10/16 10:10 AM, Andrey Chernov wrote:
On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> I am surprised lack of support GOST in openssl-base.
> Can be this enabled before 11.0 released?
AFAIK openssl maintainers says something like they can't support this
code and it will become rotten shortly with new changes, so they drop it.
>>>
>>> [OpenSSL-maintainer-for-the-base hat on]
>>>
>>> GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on
>>> these branches unless secteam explicitly ask us to do so. However, we
>>> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
>>>
>>> [OpenSSL-maintainer-for-the-base hat off]
>>>
>>> Jung-uk Kim
>>>
>>
>> Thanks!
>>
>> May be need file PR for dns/bind910?
>>
>> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
>> .include
>>
>> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
>> ${SSL_DEFAULT} == base
>> BROKEN= OpenSSL from the base system does not support GOST, add \
>> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild
>> everything \
>> that needs SSL.
>> .endif
>>
>
> I dislike idea to use GOST in the bind, it is unneeded there, DNSSEC
> don't use GOST, so I vote for removing GOST option from there.
>
I need to note that RFC exists, proposing GOST (old version) for DNSSEC:
https://tools.ietf.org/html/rfc5933
but nobody really use it.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On 11/07/2016 23:39, Allan Jude wrote: On 2016-07-11 18:33, Chris H wrote: On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov wrote On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote: On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: >> Hi, Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on Windows 10. It complained that the ISO is too big for my 700 MB CD-r. The bootonly iso (281MB) burns and runs ok. Regards, Ronald. Please open a PR. Those images should be able to fit on a CD. This was actually a known "going to be problem" thing for 11.0. I'm looking into how to fix this for 11.0-RELEASE, but right now, there is not much more we can exclude from it. :( Can't it use the compressed iso format, or is it already using that format. Sorry haven't checked. Reduce GENERIC to MINIMAL? --Chris ___ 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" 380MB of the data on disc1 is the distsets, which are already .txz (max compression). That doesn't leave much room for the live OS on the disk. Silly question but what about only supporting DVD? I can't remember the last server I installed that had CDROM drive vs a DVD drive. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
You don't need that much for OS really if you compress the underlying FS (be that ISO9660 or UFS) with the mkuzip. Just as an extreme example of that, we have liveCD-type image that deals with provisioning a new systems and troubleshooting issues on around 40MB ISO. That includes nearly all of the stock base system tools (modulo compilers and other dev related bits, fully linked ones, not crunch), full amd64 kernel (compressed separately) and complete python 2.7 environment along with necessary dependencies. So if your live OS takes 300MB+, it will be compressed down to under 100MB by just using GEOM_UZIP. Whatever people say here about moving to USB, ISOs are quite useful for setting up VMs as well as for remove booting off IP KVMs. JFYI. -Maxim P.S. It would be cool to have a loader that can read off CLOOP partition, but it's just in my wet dreams now. On Mon, Jul 11, 2016 at 3:39 PM, Allan Jude wrote: > On 2016-07-11 18:33, Chris H wrote: > >> On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov >> wrote >> >> On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote: >>> >>> On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop >> > wrote: >> Hi, > >> >>> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on >>> Windows 10. It complained that the ISO is too big for my 700 MB CD-r. >>> >>> The bootonly iso (281MB) burns and runs ok. >>> >>> Regards, >>> Ronald. >>> >> > Please open a PR. Those images should be able to fit on a CD. > This was actually a known "going to be problem" thing for 11.0. I'm looking into how to fix this for 11.0-RELEASE, but right now, there is not much more we can exclude from it. :( >>> Can't it use the compressed iso format, or is it already using that >> format. Sorry haven't checked. >> >>> >>> Reduce GENERIC to MINIMAL? >>> >> >> --Chris >> >> >> ___ >> 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 >> " >> >> > 380MB of the data on disc1 is the distsets, which are already .txz (max > compression). That doesn't leave much room for the live OS on the disk. > > -- > Allan Jude > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On Mon, 11 Jul 2016 18:39:51 -0400 Allan Jude wrote > On 2016-07-11 18:33, Chris H wrote: > > On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov > > wrote > > >> On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote: > >> > >>> On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: > > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop > wrote: >> Hi, > >> > >> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on > >> Windows 10. It complained that the ISO is too big for my 700 MB CD-r. > >> > >> The bootonly iso (281MB) burns and runs ok. > >> > >> Regards, > >> Ronald. > > Please open a PR. Those images should be able to fit on a CD. > >>> > >>> This was actually a known "going to be problem" thing for 11.0. I'm > >>> looking into how to fix this for 11.0-RELEASE, but right now, there is > >>> not much more we can exclude from it. :( > > Can't it use the compressed iso format, or is it already using that > > format. Sorry haven't checked. > >> > >> Reduce GENERIC to MINIMAL? > > > > --Chris > > > > > > ___ > > 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" > > > > 380MB of the data on disc1 is the distsets, which are already .txz (max > compression). That doesn't leave much room for the live OS on the disk. I'm not sure I was clear enough when I responded. So, just for the record; I meant the ISO data itself, not the image per se; that is, not disc-1.iso.txz. But rather mounting a compressed file system. Be it bz2, or xz(1). I seem to remember tar(1) providing examples about creating/mounting compressed archives as iso images, and then writing them as an iso image, that can be later burned to CD/DVD. Another option that I employ, when creating CD/DVD images, is to take a dump(8) of the data I intend to create the image of. This method removes the "slack" from the data/files/dirs, before writing the image -- all the nodes are contiguous, end-for-end. So there is no wasted space. > > -- > Allan Jude --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
P.S. Just in case if somebody wants to integrate this method into FreeBSD
liveCD build, we do a bit of trick there by making normal ISO9660 file
system with compressed kernel and relevant boot pieces and then also
sticking in BSD label on the same disk image. It turns out ISO9660 and BSD
disklabel structures do not overlap, so it works nicely since 2005 or
so. Then we append UFS image compressed with mkuzip at the end of it.
Resulting image can be used just as any ISO would. We also cook up UFS with
unique label and then use GEOM_LABEL to easily find relevant file system on
boot regardless of the physical device name.
mkuzip -dL -S -s 65536 -o ${UZPFILE} ${UFSFILE}
mkisofs -b boot/${CDBOOT} -no-emul-boot -r -o ${ISOFILE} ${CDIR}
eval $(stat -s ${UZPFILE})
UZPSIZE=$((st_size + 2048 - (st_size % 2048)))
truncate -s ${UZPSIZE} ${UZPFILE}
eval $(stat -s ${ISOFILE})
ISOSIZE=${st_size}
echo "bytes/sector: 2048">
${TDIR}/label.txt
echo "sectors/unit: $(((UZPSIZE + ISOSIZE) / 2048))">>
${TDIR}/label.txt
echo "a: $((UZPSIZE / 2048)) $((ISOSIZE / 2048)) unused" >>
${TDIR}/label.txt
echo "c: $(((UZPSIZE + ISOSIZE) / 2048)) 0 unused" >>
${TDIR}/label.txt
truncate -s $((ISOSIZE + UZPSIZE)) ${ISOFILE}
disklabel -A -R -f ${ISOFILE} ${TDIR}/label.txt
truncate -s ${ISOSIZE} ${ISOFILE}
cat ${UZPFILE} >> ${ISOFILE}
-Max
On Mon, Jul 11, 2016 at 4:28 PM, Chris H wrote:
> On Mon, 11 Jul 2016 18:39:51 -0400 Allan Jude
> wrote
>
> > On 2016-07-11 18:33, Chris H wrote:
> > > On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov
> > > wrote >
> > >> On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote:
> > >>
> > >>> On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote:
> > > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop >
> > wrote: >> Hi,
> > >>
> > >> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a
> CD on
> > >> Windows 10. It complained that the ISO is too big for my 700 MB
> CD-r.
> > >>
> > >> The bootonly iso (281MB) burns and runs ok.
> > >>
> > >> Regards,
> > >> Ronald.
> >
> > Please open a PR. Those images should be able to fit on a CD.
> > >>>
> > >>> This was actually a known "going to be problem" thing for 11.0. I'm
> > >>> looking into how to fix this for 11.0-RELEASE, but right now, there
> is
> > >>> not much more we can exclude from it. :(
> > > Can't it use the compressed iso format, or is it already using that
> > > format. Sorry haven't checked.
> > >>
> > >> Reduce GENERIC to MINIMAL?
> > >
> > > --Chris
> > >
> > >
> > > ___
> > > 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"
> > >
> >
> > 380MB of the data on disc1 is the distsets, which are already .txz (max
> > compression). That doesn't leave much room for the live OS on the disk.
> I'm not sure I was clear enough when I responded. So, just for the record;
> I meant the ISO data itself, not the image per se;
> that is, not disc-1.iso.txz. But rather mounting a compressed file system.
> Be it bz2, or xz(1). I seem to remember tar(1) providing examples about
> creating/mounting compressed archives as iso images, and then writing
> them as an iso image, that can be later burned to CD/DVD. Another option
> that I employ, when creating CD/DVD images, is to take a dump(8) of
> the data I intend to create the image of. This method removes the "slack"
> from the data/files/dirs, before writing the image -- all the nodes
> are contiguous, end-for-end. So there is no wasted space.
>
> >
> > --
> > Allan Jude
>
> --Chris
>
>
> ___
> 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"
ptrace attach in multi-threaded processes
Hi, It seems to be possible for ptrace(PT_ATTACH) to race with the delivery of a signal to the same process. ptrace(PT_ATTACH) sets P_TRACED and sends SIGSTOP to a thread in the target process. Consider the case where a signal is delivered to a second thread, and both threads are executing ast() concurrently. The two threads will both call issignal() and from there call ptracestop() because P_TRACED is set, though they will be serialized by the proc lock. If the thread receiving SIGSTOP wins the race, it will suspend first and set p->p_xthread. The second thread will also suspend in ptracestop(), overwriting the p_xthread field set by the first thread. Later, ptrace(PT_DETACH) will unsuspend the threads, but it will set td->td_xsig only in the second thread. This means that the first thread will return SIGSTOP from ptracestop() and subsequently suspend the process, which seems rather incorrect. The above is just a theory to explain an unexpectedly-stopped multi-threaded process that I've observed. Is there some mechanism I'm missing that prevents multiple threads from suspending in ptracestop() at the same time? If not, then I think that's the root of the problem, since p_xthread is pretty clearly not meant to be overwritten this way. Moreover, in my scenario I see a thread with TDB_XSIG set even after ptrace(PT_DETACH) was called (P_TRACED is cleared). Thanks, -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"
Re: svn commit: r302601 - in head/sys: arm/include arm64/include [__WCHAR_MAX definition mostly]
https://lists.freebsd.org/pipermail/svn-src-head/2016-July/088998.html shows: > Modified: head/sys/arm/include/_types.h > == > --- head/sys/arm/include/_types.h Mon Jul 11 23:15:54 2016 > (r302600) > +++ head/sys/arm/include/_types.h Tue Jul 12 00:37:48 2016 > (r302601) > @@ -107,7 +107,7 @@ typedef __uint32_t __vm_size_t; > > typedef unsigned int___wchar_t; > #define __WCHAR_MIN 0 /* min value for a wchar_t */ > -#define __WCHAR_MAX __UINT_MAX /* max value for a wchar_t */ > +#define __WCHAR_MAX __INT_MAX /* max for a wchar_t <= > WINT_MAX */ > > /* > * Unusual type definitions. > > Modified: head/sys/arm64/include/_types.h > == > --- head/sys/arm64/include/_types.h Mon Jul 11 23:15:54 2016 > (r302600) > +++ head/sys/arm64/include/_types.h Tue Jul 12 00:37:48 2016 > (r302601) > @@ -95,7 +95,7 @@ typedef __uint64_t __vm_size_t; > typedef unsigned int___wchar_t; > > #define __WCHAR_MIN 0 /* min value for a wchar_t */ > -#define __WCHAR_MAX __UINT_MAX /* max value for a wchar_t */ > +#define __WCHAR_MAX __INT_MAX /* max for a wchar_t <= > WINT_MAX */ > > /* > * Unusual type definitions. My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of ___wchar_t (if that is distinct). B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not necessarily a valid char value C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not necessarily a valid char value (A) and (C) seem to be violated here for __WHAR_MAX if I'm right about (A)-(C). [I'm not sure sure that (A)'s violation for __WCHAR_MIN here matters much if I got that combination right.] As far as I know arm FreeBSD uses unsigned character types (of whatever width). There is also at least one past example of Bruce Evans not objecting to __UINT_MAX for __WCHAR_MAX for arm: https://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012721.html has his only comment being. . . > % +#ifdef __ARM_EABI__ > % +#define__WCHAR_MIN (0) > > Bogus parentheses. > > % +#define__WCHAR_MAX __UINT_MAX (The definitions were in a different file back then, leading to the ifdef use.) You may want to check with Bruce Evans. He has good coverage of the various standards to be covered (that may not all agree and how/what FreeBSD then picks). === Mark Millard markmi at dsl-only.net ___ 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: svn commit: r302601 - in head/sys: arm/include arm64/include [__WCHAR_MAX definition mostly]
On 12.07.2016 5:44, Mark Millard wrote: > My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: > > A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of > ___wchar_t (if that is distinct). > B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not > necessarily a valid char value > C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not > necessarily a valid char value It seems you are right about "not a valid char value", I'll back this change out. > As far as I know arm FreeBSD uses unsigned character types (of whatever > width). Probably it should be unsigned for other architectures too, clang does not generate negative values with L'' literals and locale use only positive values too. ___ 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"
