From owner-freebsd-hackers@freebsd.org Mon Mar 8 20:13:48 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F7B855606A; Mon, 8 Mar 2021 20:13:48 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvV0W1gjBz3PyR; Mon, 8 Mar 2021 20:13:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f45.google.com with SMTP id k2so11375705ioh.5; Mon, 08 Mar 2021 12:13:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NoIvf0hya5FBzhXr4KBKDN5VKuUnizqtWcuTC+FVVvs=; b=FhgsDtwlJHRRxM6Iq65L+HSnYXwEhGIYfxmYOoBRbO+0tFu9QOifJ9yWTlRVKYgpZS OeJTy4/4+Eucpi4TA30gb0t9nTur/OMUDg7m/uVxTlSm01zfOQG++U3s3XyFzaPqT+Pm di3JZzIfZtJpZ+mGw/BwcuWos1QuCN+MCqkKB/AoNw7zoQYyXEu+CTUg9PH87Qzm0mE/ jcflZk/BFRw8KjYpDa9zpJ9Ht57ybKM2KC2A1znb9vdhwj0fh7fWDV8IPlsz1dCxRIt2 bBBO11l0fw/TjHsnWUnUV+KaJpFg1ta1dBCOSZVpumxHzrHXKYJLm3+RZUUgrMyQoseP UXYw== X-Gm-Message-State: AOAM531ghX/2e/92CC89akv3JDVUClWTBUvZFLknmZaaTYuQ28s00qxr GQfIbYp8kHMEmGb0uNZ75mZdW21xMpddeUzoR6Xix2BZ6W3swg== X-Google-Smtp-Source: ABdhPJxBKEhCu4WYS6hz9jX7xhxIyXmY25tqv3QLuK9UbCMaCg5VVkknFJXYM/O1XVY6SD6DEUOQc0dlnuiNUNc3jOc= X-Received: by 2002:a6b:fc16:: with SMTP id r22mr19135510ioh.102.1615234424871; Mon, 08 Mar 2021 12:13:44 -0800 (PST) MIME-Version: 1.0 From: Ed Maste Date: Mon, 8 Mar 2021 15:13:19 -0500 Message-ID: Subject: Rationalizing sed -i/-I (in-place editing) argument handling To: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvV0W1gjBz3PyR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.45:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[209.85.166.45:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.45:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.45:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:13:48 -0000 A relatively minor but longstanding incompatibility between FreeBSD and many other systems is the way sed handles backup files for in-place editing -- sed's -I and -i options. GNU sed and other BSDs accept an optional argument: -I.bak will save a backup file with a .bak extension, and -I with no argument will not create a backup file. FreeBSD currently accepts either -I.bak or -I .bak to save a backup with the given extension, and -I "" (an empty argument) to specify no backup. I've been tripped up by this in the past and I know many others have. Most recently tobik@ filed PR 254091 for this. Now, I think a single change to make -i/-I to be compatible with other sed implementations in one step is too much of a POLA violation, but I think it can reasonably be done in stages: 1. Update the man page to indicate that -i/-I should not have a space between the flag and the extension. This is compatible with current FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. No backup is still a special case and remains as -I "". I've opened https://reviews.freebsd.org/D29128 with proposed man page changes. 2. Continue accepting -I .bak, but emit a warning suggesting the use of -I.bak instead. 3. Change -I/-i to getopt optional arguments, but keep a special case for -I/-i "". At this point -I .bak becomes invalid as with other seds, and specifying no backup can be done with either -I "" or -I with no argument. This relies on an empty argument having no other sensible interpretation. 4. Continue accepting -I "" to specify no backup, but emit a warning suggesting the use of -I with no argument. 5. Retire the special case for -I "". These steps could be done over an extended period of time (such as one major release to another) - this is most important between steps 2 and 3. Please let me know what you think, and if there's something I've missed. From owner-freebsd-hackers@freebsd.org Mon Mar 8 20:25:41 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C4665556B92; Mon, 8 Mar 2021 20:25:41 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvVGF2hvsz3h0P; Mon, 8 Mar 2021 20:25:40 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 128KQ5MT095162; Mon, 8 Mar 2021 12:26:11 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Mon, 08 Mar 2021 12:26:05 -0800 From: Chris To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <0aa81e9d7124b144443da405d9ba5d43@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvVGF2hvsz3h0P X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:25:41 -0000 On 2021-03-08 12:13, Ed Maste wrote: > A relatively minor but longstanding incompatibility between FreeBSD > and many other systems is the way sed handles backup files for > in-place editing -- sed's -I and -i options. GNU sed and other BSDs > accept an optional argument: -I.bak will save a backup file with a > .bak extension, and -I with no argument will not create a backup file. > FreeBSD currently accepts either -I.bak or -I .bak to save a backup > with the given extension, and -I "" (an empty argument) to specify no > backup. > > I've been tripped up by this in the past and I know many others have. > Most recently tobik@ filed PR 254091 for this. Now, I think a single > change to make -i/-I to be compatible with other sed implementations > in one step is too much of a POLA violation, but I think it can > reasonably be done in stages: > > 1. Update the man page to indicate that -i/-I should not have a space > between the flag and the extension. This is compatible with current > FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. > No backup is still a special case and remains as -I "". > > I've opened https://reviews.freebsd.org/D29128 with proposed man page > changes. > > 2. Continue accepting -I .bak, but emit a warning suggesting the use > of -I.bak instead. > > 3. Change -I/-i to getopt optional arguments, but keep a special case > for -I/-i "". At this point -I .bak becomes invalid as with other > seds, and specifying no backup can be done with either -I "" or -I > with no argument. This relies on an empty argument having no other > sensible interpretation. > > 4. Continue accepting -I "" to specify no backup, but emit a warning > suggesting the use of -I with no argument. > > 5. Retire the special case for -I "". > > These steps could be done over an extended period of time (such as one > major release to another) - this is most important between steps 2 and > 3. > > Please let me know what you think, and if there's something I've missed. +1 This seems more than a reasonable course of action. :-) Thanks! From owner-freebsd-hackers@freebsd.org Mon Mar 8 20:55:55 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A5FD2557AF8 for ; Mon, 8 Mar 2021 20:55:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2j.ore.mailhop.org (outbound2j.ore.mailhop.org [54.148.113.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvVx71Sxrz3kn6 for ; Mon, 8 Mar 2021 20:55:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1615236954; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=IqrMg/xbpz81NJnMzDab/tQPUE5UC6wUfFGLFtvycp5jz/F9Lj5tHMBoVzhGM/wSYUnndO55i+c9D jh1mtvZ8IhOZkF+mN9T6asrAA+twodOocdz86sACdemZzXzqb5Gj0feZHb6y9cZKij8kdcWbooTnPj +pqsj/YMmiAKd4R72awU+DfnEfVsW4/awRvbbGXcr28DTdXooJOllQqa6gzYqLMN8tyGAZ78ELUvaZ EXo6su4b7bCOYeNueDXQVMiXnakCDwdlAtW7QqYX6NS1Zny+j8LDQjlHnVTkC0Ca9R4J4Wh200wavx 5Vh6DgIEjPJ0ylTpMad/iqw5LpKfZOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=WTmv4J9ExjuHPSlCZmsyq7KQjd854vtRJhfxWGo4l6s=; b=psCZdVRm7hlhjss5DHgqG49Kf6yXWkGHMhHCJ0eMPr3HoOM6mcfRztcCfrsvlZkvSwha8QMs9aKen KSRp0z0CgRd7paSyyCftEkQyHrw8uXboTmhCm3IutLa1CXU/2Mkbgy9PTKVMKzsARx4riRHbqJz28A alYdQYlg11hcdY8mPNOwsqune+ucKCR7DWfq9iK0szFz2LT5V/J4ufwRfIqAAF5Mc0CMTWZQ0eSoT6 OAR00KKQ1+ePA9KqF7DuGBSbFPBR4+n1/r62a51lVahTgp+wkVE2gIt9Ah9iEREACqjZRZ9Siy5MtD lo4fda77ARQ0ErQW139Iq5zp8914k6A== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-low; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=WTmv4J9ExjuHPSlCZmsyq7KQjd854vtRJhfxWGo4l6s=; b=QZ2ITA4xFu/SnsJ5RuUqT9wimAQ6+pf1oMQHT63WpXeKilZt7jG5575MpqhGQUDHiTKKoaGoDpAc6 k2p8C5EEreWtpVEGOT0g8DunMvk0EfxxK/2Y1zHPSxxJODE8/6kHMJCSF1vttHFhZWEvOTliWkdYVI tsGUD4l3ET6dFq0F6Tmm3dT3W4LCvv0U5N4w6dAkUaTeZp0QHQ8k/VO5qHK1zWnUlWkTAFTjF1yvw0 1wi/GOj8kACt9giVc9r4M3skBPvXRW0BJ942qfYRz52SzmtDKzgOd/I1/1sfYqwl4AVkUnRjQT6+hO tf+8uh9toIodUsi2tCjH8tK4jnhfdvg== X-Originating-IP: 67.177.211.60 X-MHO-RoutePath: aGlwcGll X-MHO-User: ab31223f-8050-11eb-ad62-59765e228ffb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id ab31223f-8050-11eb-ad62-59765e228ffb; Mon, 08 Mar 2021 20:55:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 128KtqFB076198; Mon, 8 Mar 2021 13:55:52 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling From: Ian Lepore To: Ed Maste , FreeBSD Hackers , FreeBSD Current Date: Mon, 08 Mar 2021 13:55:52 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvVx71Sxrz3kn6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:55:55 -0000 On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote: > A relatively minor but longstanding incompatibility between FreeBSD > and many other systems is the way sed handles backup files for > in-place editing -- sed's -I and -i options. GNU sed and other BSDs > accept an optional argument: -I.bak will save a backup file with a > .bak extension, and -I with no argument will not create a backup > file. > FreeBSD currently accepts either -I.bak or -I .bak to save a backup > with the given extension, and -I "" (an empty argument) to specify no > backup. > > I've been tripped up by this in the past and I know many others have. > Most recently tobik@ filed PR 254091 for this. Now, I think a single > change to make -i/-I to be compatible with other sed implementations > in one step is too much of a POLA violation, but I think it can > reasonably be done in stages: > > 1. Update the man page to indicate that -i/-I should not have a space > between the flag and the extension. This is compatible with current > FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. > No backup is still a special case and remains as -I "". > > I've opened https://reviews.freebsd.org/D29128 with proposed man page > changes. > > 2. Continue accepting -I .bak, but emit a warning suggesting the use > of -I.bak instead. > > 3. Change -I/-i to getopt optional arguments, but keep a special case > for -I/-i "". At this point -I .bak becomes invalid as with other > seds, and specifying no backup can be done with either -I "" or -I > with no argument. This relies on an empty argument having no other > sensible interpretation. > > 4. Continue accepting -I "" to specify no backup, but emit a warning > suggesting the use of -I with no argument. > > 5. Retire the special case for -I "". > > These steps could be done over an extended period of time (such as > one > major release to another) - this is most important between steps 2 > and > 3. > > Please let me know what you think, and if there's something I've > missed. > As someone who has to take care of common software that runs on everything from freebsd 8 through -current, I HATE the very idea of this. If we keep whittling away at the backwards compatibility freebsd is so famous for, I'll have abosolutely zero arguments left for why $work shouldn't just switch to the much more popular and better- supported linux. I also hate the idea of requiring no space between -I and its related value. That seems like a huge POLA violation compared to how virtually every other command's options and arguments work. -- Ian From owner-freebsd-hackers@freebsd.org Mon Mar 8 21:19:56 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E84A1558863; Mon, 8 Mar 2021 21:19:56 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvWSq6yyRz3m1w; Mon, 8 Mar 2021 21:19:55 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.1]) by sdaoden.eu (Postfix) with ESMTP id 9C02E16056; Mon, 8 Mar 2021 22:19:47 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 68DDDFD24; Mon, 8 Mar 2021 22:19:46 +0100 (CET) Date: Mon, 08 Mar 2021 22:19:46 +0100 From: Steffen Nurpmeso To: Ian Lepore Cc: Ed Maste , FreeBSD Hackers , FreeBSD Current Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling Message-ID: <20210308211946.6CWxa%steffen@sdaoden.eu> In-Reply-To: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> References: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> Mail-Followup-To: Ian Lepore , Ed Maste , FreeBSD Hackers , FreeBSD Current User-Agent: s-nail v14.9.22-99-g733424fe OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4DvWSq6yyRz3m1w X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.144.132.164:from]; SPAMHAUS_ZRD(0.00)[217.144.132.164:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 21:19:57 -0000 Ian Lepore wrote in <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org>: |On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote: |> A relatively minor but longstanding incompatibility between FreeBSD |> and many other systems is the way sed handles backup files for |> in-place editing -- sed's -I and -i options. GNU sed and other BSDs |> accept an optional argument: -I.bak will save a backup file with a |> .bak extension, and -I with no argument will not create a backup |> file. |> FreeBSD currently accepts either -I.bak or -I .bak to save a backup |> with the given extension, and -I "" (an empty argument) to specify no |> backup. |> |> I've been tripped up by this in the past and I know many others have. |> Most recently tobik@ filed PR 254091 for this. Now, I think a single ... |> change to make -i/-I to be compatible with other sed implementations |> in one step is too much of a POLA violation, but I think it can |> reasonably be done in stages: |> |> 1. Update the man page to indicate that -i/-I should not have a space |> between the flag and the extension. This is compatible with current |> FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. |> No backup is still a special case and remains as -I "". ... |As someone who has to take care of common software that runs on |everything from freebsd 8 through -current, I HATE the very idea of |this. If we keep whittling away at the backwards compatibility freebsd |is so famous for, I'll have abosolutely zero arguments left for why |$work shouldn't just switch to the much more popular and better- |supported linux. | |I also hate the idea of requiring no space between -I and its related |value. That seems like a huge POLA violation compared to how virtually |every other command's options and arguments work. I hate it too. But just wanted to note that sccs used this (and still does, even standardized) decades ago already (and i always did it wrong). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Mon Mar 8 21:41:59 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BD687559A11; Mon, 8 Mar 2021 21:41:59 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvWyG6wntz3p92; Mon, 8 Mar 2021 21:41:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f178.google.com with SMTP id e7so10241169ile.7; Mon, 08 Mar 2021 13:41:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KkiHKxAfzL9AbUTn3iuTxrRObYaHODZqZC7w4/9hMvM=; b=dxFSxnKel+t+xaOu/6+e5+Go2emMKs99EKg10oPXR7V1j2nJHQtq0WtKS+1EBnzTvI QKM0IUO2cBUGOUAgrxfqH7yV5R5ZRRC9ynz6p41bCiis4cmHhwdwpKf3lMULodShQ3DW bEniycljWrPfRDEtlPDNsBdHTxN7qJn5EFOTbWyhPD0sLU921TjqfekYZm4Q9ia46zB6 q8p7Mme7yOR4CMkHp7VarEktCRqU9iL+DNMkCkhC8zF+N3BBmGfr75h81/qpMz02JRM5 sX8ocxJic/HzTRfJfAlL8NlmYhzcxxZka2/xdni9sgf99V99beIICSjP7VqVDaj8pPxY j9Mw== X-Gm-Message-State: AOAM532Lsdeyh8+Nlhx03iwphaiwCkm3xAH2ojR6Dt04EKqFZdvpQhYP AAviOyo+gMiugPVtc1QGGUInzIaI/ppstj/rIkMYs3fNPqU= X-Google-Smtp-Source: ABdhPJzMIh7fm/k03IKSg3Lrrgwak9Vm8RTfb6cAQYHpwsPDoEml1PSH80NzPL2VcovkFa8lHIXUMXiSHCK5+UVgCcc= X-Received: by 2002:a92:ce02:: with SMTP id b2mr23420953ilo.182.1615239717265; Mon, 08 Mar 2021 13:41:57 -0800 (PST) MIME-Version: 1.0 References: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> In-Reply-To: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> From: Ed Maste Date: Mon, 8 Mar 2021 16:41:29 -0500 Message-ID: Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling To: Ian Lepore Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvWyG6wntz3p92 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.178:from]; SPAMHAUS_ZRD(0.00)[209.85.166.178:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.178:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.178:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 21:41:59 -0000 On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote: > > I also hate the idea of requiring no space between -I and its related > value. That seems like a huge POLA violation compared to how virtually > every other command's options and arguments work. On the other hand, -i.ext with no space is compatible with FreeBSD today and is portable to OpenBSD, NetBSD, macOS, and GNU. -i .ext works only with FreeBSD and macOS. From owner-freebsd-hackers@freebsd.org Mon Mar 8 22:00:35 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 75F5D55A2E7; Mon, 8 Mar 2021 22:00:35 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvXMk3kzhz3psJ; Mon, 8 Mar 2021 22:00:33 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 128M0Qvw032513 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Mar 2021 14:00:26 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 128M0Q4F032512; Mon, 8 Mar 2021 14:00:26 -0800 (PST) (envelope-from jmg) Date: Mon, 8 Mar 2021 14:00:26 -0800 From: John-Mark Gurney To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling Message-ID: <20210308220026.GK5246@funkthat.com> Mail-Followup-To: Ed Maste , FreeBSD Hackers , FreeBSD Current References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 08 Mar 2021 14:00:26 -0800 (PST) X-Rspamd-Queue-Id: 4DvXMk3kzhz3psJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.51 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.29)[0.285]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:00:35 -0000 Ed Maste wrote this message on Mon, Mar 08, 2021 at 15:13 -0500: > A relatively minor but longstanding incompatibility between FreeBSD > and many other systems is the way sed handles backup files for > in-place editing -- sed's -I and -i options. GNU sed and other BSDs > accept an optional argument: -I.bak will save a backup file with a > .bak extension, and -I with no argument will not create a backup file. > FreeBSD currently accepts either -I.bak or -I .bak to save a backup > with the given extension, and -I "" (an empty argument) to specify no > backup. > > I've been tripped up by this in the past and I know many others have. > Most recently tobik@ filed PR 254091 for this. Now, I think a single > change to make -i/-I to be compatible with other sed implementations > in one step is too much of a POLA violation, but I think it can > reasonably be done in stages: > > 1. Update the man page to indicate that -i/-I should not have a space > between the flag and the extension. This is compatible with current > FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. > No backup is still a special case and remains as -I "". > > I've opened https://reviews.freebsd.org/D29128 with proposed man page changes. > > 2. Continue accepting -I .bak, but emit a warning suggesting the use > of -I.bak instead. > > 3. Change -I/-i to getopt optional arguments, but keep a special case > for -I/-i "". At this point -I .bak becomes invalid as with other > seds, and specifying no backup can be done with either -I "" or -I > with no argument. This relies on an empty argument having no other > sensible interpretation. I will say that IMO, I really dislike a command line argument having an optional argument. It can cause parsing confusion and possibly security issues... Copying this behavior, IMO, is not good... So my vote is against this misfeature.. How is the program suppose to tell when the extension is "-e", or -e is a different option and not the argument to -I? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@freebsd.org Mon Mar 8 22:08:56 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CA06A55A6DF; Mon, 8 Mar 2021 22:08:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvXYM45w0z3qQv; Mon, 8 Mar 2021 22:08:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f169.google.com with SMTP id c10so10302516ilo.8; Mon, 08 Mar 2021 14:08:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yPZ3T06czy5q8iTqR3SCuCl70XWXixDr+mfJXSItxSo=; b=ebEn3l5VkyAOYxCrQa7jYJxQI77XOUu5VI+XQtsJ4UL5JRL/WxyFTUwrDYFeCknAUN Yc8MNlxOrRxh5r0DOg2w8XzBP/DGnHSl2eO7W2YopEXmqBzqdnouTDj10xjS6sc6gNUJ 7wQ5UHlpS75QLkJhcVZJUoAMXj/ZI4oNOWr0QAHuzShk4wzlWXMua0xHL/P93PMJ1JmZ YI32w2K2cxufBIBTJonhAWUyGUiEbfdimGfk5nqLhHgb1iaby8YYgDs80H8fefjp/wg6 Huu4MnrdcN+7BMzJ6ViTfOo9GUE8/jwY70Exb2Q9CtHmM6aX4erSUO0YeUvNXidkJ0gq zWxw== X-Gm-Message-State: AOAM532Vue6+g6mFe7Gwb4AbxCAzM1BWkGWrrXIhMFCF6n6uA/F8GUlO /I2RsAo1Y1dLrP7fxaLOBCR2npnkmFDmaBw2qPsE1yiv3F8= X-Google-Smtp-Source: ABdhPJzUYT8YBC6JjQzfvWipPZNsrE3KvjJGqoFMshdHhIyFidtkkRGXEsCrrclWvaMnvFxKgnf0lGX/yTW5EITeK3Y= X-Received: by 2002:a05:6e02:1845:: with SMTP id b5mr22463661ilv.11.1615241334003; Mon, 08 Mar 2021 14:08:54 -0800 (PST) MIME-Version: 1.0 References: <20210308220026.GK5246@funkthat.com> In-Reply-To: <20210308220026.GK5246@funkthat.com> From: Ed Maste Date: Mon, 8 Mar 2021 17:08:27 -0500 Message-ID: Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling To: Ed Maste , FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvXYM45w0z3qQv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[209.85.166.169:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.169:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.169:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.169:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:08:56 -0000 On Mon, 8 Mar 2021 at 17:00, John-Mark Gurney wrote: > > How is the program suppose to tell when the extension is "-e", or -e > is a different option and not the argument to -I? -i-e is an in-place edit with extension "-e" -i -e is an in-place edit with no extension From owner-freebsd-hackers@freebsd.org Wed Mar 10 23:00:24 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5F44F57A395 for ; Wed, 10 Mar 2021 23:00:24 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dwnbr2NJSz4pTV for ; Wed, 10 Mar 2021 23:00:24 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id E066F5ACB for ; Wed, 10 Mar 2021 23:00:23 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Wed, 10 Mar 2021 15:00:21 -0800 (PST) From: Don Lewis Subject: problems building a release To: freebsd-hackers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 23:00:24 -0000 I'm trying to build a customized 13.0 i386 release on a amd64 host running FreeBSD 14.0-CURRENT #89 n245058-1ca8842f3ad9. The source tree is branch releng/13.0 from last night. The release build gets most of the way through, but fails with: ===> usr.bin/svn/lib/libsvn_wc (installconfig) --- installconfig_subdir_usr.sbin --- --- installconfig_subdir_usr.sbin/pkg --- --- installdirs-CONFSDIR --- --- _CONFSINS_FreeBSD.conf.quarterly --- --- installdirs-CONFSDIR --- installing DIRS CONFSDIR install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratch/etc/pkg --- _CONFSINS_FreeBSD.conf.quarterly --- install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf Shared object "libedit.so.8" not found, required by "sh" /scratch/bin/sh seems to work, though it is using the host library: # ldd /scratch/bin/sh /scratch/bin/sh: libedit.so.8 => /usr/lib32/libedit.so.8 (0x20463000) libc.so.7 => /usr/lib32/libc.so.7 (0x20495000) libncursesw.so.9 => /usr/lib32/libncursesw.so.9 (0x20683000) # /scratch/bin/sh # The library is present in /scratch/lib: # file /scratch/lib/libedit.so.8 /scratch/lib/libedit.so.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 (1300139), stripped Unfortunately the build isn't verbose enough to give me any hints about where the problem might be. I've been able to build FreeBSD 11.x and 12.x releases this way, but no luck so far with 13. Update: I am able to build an amd64 release, so the problem has something to do with crossbuilds. There are some other problems that crop up, though. ===> usr.bin/svn/lib/libsvn_wc (installconfig) --- installconfig_subdir_usr.sbin --- --- installconfig_subdir_usr.sbin/pkg --- --- installdirs-CONFSDIR --- --- _CONFSINS_FreeBSD.conf.quarterly --- --- installdirs-CONFSDIR --- installing DIRS CONFSDIR install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratch/etc/pkg --- _CONFSINS_FreeBSD.conf.quarterly --- install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/perl5/5.20/mach/CORE 32-bit compatibility ldconfig path: /usr/lib32 pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 916 B 0.9kB/s 00:01 pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 repository FreeBSD has no meta file, using default settings Fetching packagesite.txz: 100% 6 MiB 1.6MB/s 00:04 pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 Unable to open created repository FreeBSD Unable to update repository FreeBSD All repositories are up-to-date. pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 pkg: Repository FreeBSD cannot be opened. 'pkg update' required Updating database digests format: 100% pkg: No packages available to install matching 'devel/git' have been found in the repositories From owner-freebsd-hackers@freebsd.org Thu Mar 11 02:57:46 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3354C5AC52C for ; Thu, 11 Mar 2021 02:57:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dwtsj6y2Kz3Qc8 for ; Thu, 11 Mar 2021 02:57:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615431464; bh=r62KydRkUy2Xhj6fG/sgSyyFj2CqZAL8n5jIcFIdUK6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=U4omhUDEV6/qrcSnuKENSakuSkTJ76pV/Q8YJms+ZwVv6htclOEcnq8UTnX5zUBUPm999xhQe3PC3adG0LyomLQd87j00pC9/J75RNV3/wSbNvEwuhLPY+Fpr89XQ0a28MwpL5+y6sVaGi0csc+WoO4vk0Gt/Qu/pU96OINjMH97yaSSMEHLCcl1q1XN72piMEWPwaUEvnUYyJtXtbJo6oVZOsaB4iWh/rT7KmyMaM9/PjoZQfThW9K0qPfVjwUEbySQgRqLelu2wusqi1KEAiIk4VUERYHskLx0CdC8Rx4FvjU2t0tz28MhaPOqLYXsCf8jZe6bPLi5hfMvY52oQQ== X-YMail-OSG: eHX8a6cVM1kxLcScJF2EdkEP_HbDHpUXmSPt3uYFu3Lz2xT.CRceelEmnToZCk0 KWq7fE1MRXQCKbNjdvGofqxl1zAIIOOc6e2x8QOhQBuus42S3pE8FINYUbVQ1M3h_wAeDoTM0cZD qxCiKPfVlMAOMmJOflgaR8x8PmdOd607MEMl5uHXmQj0Tuwg_3HFijWaaetZA0DHV6UDn7gHdleV znarTPFAbxyuhZDSA9Tx1RIvsWsCyneuiZmQaXtiku1LmcAdg2XI79TibiuOMcZmM88eWf.lqGIR FbP4_H5S8WNqJwkMZI_ysZmOvEMbeGu7VxXi9mevby.Wf2Dkp5O_OF6BVBs3fmNtY57jSGAaP37K s4B18wETxo26UZ4TkH8OaNMitWlObhjtWteyMLaZr81UNuzSd_rUXp8AhYEMVYakpDkA__Zb8BXz 4auRTPAH6ejqdyta0_Bg0yt8qdgcaV6B98p0Zr529O_Bt8C9b8Z5JSSsr2MPf5bSm7UMsnRoVmZX 1Gh3omyWpHvbMaPh_dIaLtKe3fy9oCtxC.wNKRdIDzNrqHesbWnNUgLs..WNI83zncLzlBzbQmH4 7JVxLIPX.o3bnv48QQrqcqYKjbvcydAFQqgXxZnZoUnDXbIBD0FBLGI8bm2JulNyG1LkE55wOsbi AX3wUq7IMRZYa3c_NALdt4J4Jk8BZXMLrXG1_.8Te3yYJvw6nGfKuqIFjwuYEpwrBRa6g27aZUwX 0ozNdwU.hplswUNEA.7sxVZgduAM.yYwo.5v3Pk_vb_2gIG.kjouQ.6hpYupJLWcGMw98G5ZvKHs 10jeBHqK88gRm5W2JxK_kG4Vs.5ClAMdElsgIVvgHV_cOjaEtJuQIIW19K_VLofp3ChX6Ag03R5Q ZV4zMcWiZR9G3kXXd1g1HdIA9F7a1vR8ZieSXpKnfU__QFEh3I5IlzMxo7MXWJuoyIg2rcCEp16t bR1XVsO3LsxsxFTuhl04Fq37lezUlNIMJZYycrY7UYGySRSUzVMdmVXLmME4FZP9ULVrj90jhIiV Glifbz_2jD7MREGLG88M.g6VYfSDrzP3i1Y4SMWCOPmb_pdkA4P_kxd4UrVOs.JJ1QmwtTHV85kF yD4SWqDCWgAKxYFnhRrNrJ.bzmdlXof4qQRxA8NO7J14DO3e5FmI1Uq71aH066jBjtqWIhWR56R0 e.icU67RS9fbYt5N1R4NvJuYuZFUmDcJ5LqvpaAaxwFUEnMfBczeL5AuLtGPy_YAUmXBh59FcYa5 Ym_O8oAyXYfzjrDIkB8PyDLKZZ_1M3uFhGDrIg2j_X_89rA1kR.zApi0MsAOtoKE7dVDmfVuZDqp hkYW_oC8hakMMoiJiuuAfyaFGJAlBdY7KAgCrHCBTd4dNMIlW4D82Mjva1NDVC.SseoA7vlCZdjF BAd74GuFOr6lN6bnNv8r1fLxAO7J9dEYa3mLcHduTU_XSCnAKVnoIr3_yeKdbgHJ3XY8HaPEteSw t8KpmcQ7SBD33WZT7AcHt8Y671YSLcqO6XNR0CE_.qvactpLGL7DvQrvF4_GMnJELAgeeZRQ..Ui 5xoTxTUZ97P64CYkimw_bUs4JF8BH6H0qfNzHTxGZ38L_Beu9dHnIcXKdVS9IiULY_eJFMo90D8b yo.LqpEgB00FvVBhNaIWMkn5Yk8hk3OwTl7W2kQk7nGaGgegYVxx8iPMGZ3mFZykHNxgiuy21xxZ ljC1x7T8c9QeSnrFzQnyG6ZH0pSEz09q.inbxtOme3tzgzgE4LtolZPJFr0HlF1w75WpdGUk1sHe yz4xiEIOh4qS4dBpayouQOfUuGV44gdjE3DhMvvGxNRdKDmGRlDuLa6Msvpaq_ZbxW_sGVY3DtV3 9WtZEUpwXaxl_mbGf.M8ryWWR.XIicMs.AaLmktEQBdhViO7mRV19Iv1UqNMXzXl1REOyjBVzJOe fhZ.3URNzEYQBqGA6KupN6AegKvzEuYkFEfmR0JSIszF41oJUvPnzIte6uRGFOvOZYjYpmitMX.H dTfUHCr0mGp25OWg93JS83R1p6p8QCHfVstfUt2xFn_Ax_s0eyOmdmbELNsSGrcsvjjhNMTP.SVx VcBG12oZmw4b.KglbuuOuWIqEsaQPupWWBUgZJ5wvm0hYHOUV95YylAZw4aslE6tjPPB8THYbUWL rdKu9OHnar5Pw77Fg2GNzpDe55sJXZwgZrDsLKgbqoTSWXodR0l6HbsfS4KrObXaZzm5ANw_BKIp TkG8QueVHnNKePeeoH3QesitZQ.luOeOsUXlD0VnuQ_2ZSpc3XYyUJ3Jc8DS8Wd5qvBpuZFcGKCZ .ABBE4oq9UXPDm3byeAIMTgHEsxiclQcqjHq0ZHPI0TBaz1BCxDu4SU9lv.Uqe2OPj7QqbAiUyMC O1v6hl7zOMHO.YjtgZ1UqqzE_NjKXNSIt19zcG_aVmuU.S3.wPkdXLcr4I_J5dlLAQ4cSE.dG7hE YxzIw7qo8TQdRUXGP4kd9HJy7sUNQgbvKLZ6ZiJdicodvXyNYjKZ_tbNJLajOl4ym4eBSZp.k4PV iZ70QZHdUd0IXqyoz0zwfjbdatkH00KuzGDVAUYRIuuuDe8LtSFQ_VUKT3c5yVWIm2NCL_riyX_2 A0ozoZA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 11 Mar 2021 02:57:44 +0000 Received: by kubenode539.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a20af21c7ab362b79b147fcc6263a060; Thu, 11 Mar 2021 02:57:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: problems building a release From: Mark Millard In-Reply-To: Date: Wed, 10 Mar 2021 18:57:37 -0800 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Don Lewis X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4Dwtsj6y2Kz3Qc8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 02:57:46 -0000 On 2021-Mar-10, at 15:00, Don Lewis wrote: > I'm trying to build a customized 13.0 i386 release on a amd64 host > running FreeBSD 14.0-CURRENT #89 n245058-1ca8842f3ad9. The source = tree > is branch releng/13.0 from last night. The release build gets most of > the way through, but fails with: >=20 > =3D=3D=3D> usr.bin/svn/lib/libsvn_wc (installconfig) > --- installconfig_subdir_usr.sbin --- > --- installconfig_subdir_usr.sbin/pkg --- > --- installdirs-CONFSDIR --- > --- _CONFSINS_FreeBSD.conf.quarterly --- > --- installdirs-CONFSDIR --- > installing DIRS CONFSDIR > install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel = /scratch/etc/pkg > --- _CONFSINS_FreeBSD.conf.quarterly --- > install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 = /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly = /scratch/etc/pkg/FreeBSD.conf > Shared object "libedit.so.8" not found, required by "sh" >=20 > /scratch/bin/sh seems to work, though it is using the host library: > # ldd /scratch/bin/sh > /scratch/bin/sh: > libedit.so.8 =3D> /usr/lib32/libedit.so.8 (0x20463000) > libc.so.7 =3D> /usr/lib32/libc.so.7 (0x20495000) > libncursesw.so.9 =3D> /usr/lib32/libncursesw.so.9 (0x20683000) > # /scratch/bin/sh > #=20 >=20 > The library is present in /scratch/lib: > # file /scratch/lib/libedit.so.8 > /scratch/lib/libedit.so.8: ELF 32-bit LSB shared object, Intel 80386, = version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 (1300139), = stripped >=20 > Unfortunately the build isn't verbose enough to give me any hints = about > where the problem might be. I've been able to build FreeBSD 11.x and > 12.x releases this way, but no luck so far with 13. >=20 > Update: I am able to build an amd64 release, so the problem has > something to do with crossbuilds. There are some other problems that > crop up, though. >=20 >=20 > =3D=3D=3D> usr.bin/svn/lib/libsvn_wc (installconfig) > --- installconfig_subdir_usr.sbin --- > --- installconfig_subdir_usr.sbin/pkg --- > --- installdirs-CONFSDIR --- > --- _CONFSINS_FreeBSD.conf.quarterly --- > --- installdirs-CONFSDIR --- > installing DIRS CONFSDIR > install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel = /scratch/etc/pkg > --- _CONFSINS_FreeBSD.conf.quarterly --- > install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 = /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly = /scratch/etc/pkg/FreeBSD.conf > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/perl5/5.20/mach/CORE > 32-bit compatibility ldconfig path: /usr/lib32 > pkg: Warning: Major OS version upgrade detected. Running "pkg-static = install -f pkg" recommended > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100% 916 B 0.9kB/s 00:01 =20 > pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 > repository FreeBSD has no meta file, using default settings > Fetching packagesite.txz: 100% 6 MiB 1.6MB/s 00:04 =20 > pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 > Unable to open created repository FreeBSD > Unable to update repository FreeBSD > All repositories are up-to-date. > pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 > pkg: Repository FreeBSD cannot be opened. 'pkg update' required > Updating database digests format: 100% > pkg: No packages available to install matching 'devel/git' have been = found in the repositories To my knowledge FreeBSD does not support 14 directly building 13 or before: self hosted and sufficiently recent older building newer only, as far as direct builds go. My understanding is that on 14 you can chroot into a 13 (or, say, 12.2) and build 13 in that environment if the chroot area is set up for doing so, so a more indirect way of building on what is ultimately a native-14 configuration. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Mar 11 22:24:38 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 654D15AE055 for ; Thu, 11 Mar 2021 22:24:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxNm55MZCz4T8r for ; Thu, 11 Mar 2021 22:24:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f181.google.com with SMTP id d5so813154iln.6 for ; Thu, 11 Mar 2021 14:24:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=cjdqkVu9gJYb1fFpXZ2kaWg3Y4SH534Wcv+nivTe0Mw=; b=CfXY5pYolRWSaLG6WDfMGxgOZs8Xm61IGxP1Zs2i3mX6LhcrvH1idEMH+K54k017yg Yo1bCohgOI5DTxmnxoW8I4Man3fbAIGPgNbzlE3y3+vce38e0/4IJmnlunQaQHUb5PFf u8skXkKiJ1t+PmEjzzqrXk8FSty5snPO9kMs1im0x5VNcSYKNzcwsu/LfbPdTyWoeIlB Yl179gz79wK5x1iVC11lbHvWaqBArddjVUclUWoUVpV1t3e4dNU16q7S5aS7BeTv3m84 WRZEVp5egIxdb5+38hxDTMw6MquOq0TjEtifuOGmWfxkTGeDd0eXj1KT+YsTzN6g26jh l6Hg== X-Gm-Message-State: AOAM533nPiW90bdFGeh74P/wz1iZ7Q0q/3gcWbmWhywIjj6/rhgM/3Tr SIhvceeMbmaxzHLYwrz0M2fREezFTCiM7pujuUz61en7tQQ= X-Received: by 2002:a92:c690:: with SMTP id o16mt535563ilg.256.1615501476402; Thu, 11 Mar 2021 14:24:36 -0800 (PST) MIME-Version: 1.0 References: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> In-Reply-To: From: Ed Maste Date: Thu, 11 Mar 2021 17:23:55 -0500 Message-ID: Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DxNm55MZCz4T8r X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.181:from]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.166.181:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.181:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.181:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 22:24:38 -0000 On Mon, 8 Mar 2021 at 16:41, Ed Maste wrote: > > On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote: > > > > I also hate the idea of requiring no space between -I and its related > > value. That seems like a huge POLA violation compared to how virtually > > every other command's options and arguments work. > > On the other hand, -i.ext with no space is compatible with FreeBSD > today and is portable to OpenBSD, NetBSD, macOS, and GNU. -i .ext > works only with FreeBSD and macOS. I'd like to go ahead with a man page update shortly. Even if we do not modify sed, it is valuable to document and describe the compatibility issues with our -i/-I, including the odd way we specify no backup file. On the topic of POLA our -i/-I support was based on perl's in-place editing, except perl uses the optional argument style (-i / -i.bak). I'd also argue that our -i "" is a POLA violation compared to how most other commands work, and has caused significant confusion for folks interested in cross-OS compatibility. If anyone has suggestions or improvements to the proposed man page text I'd appreciate a follow-up here or a comment in the review, https://reviews.freebsd.org/D29128. From owner-freebsd-hackers@freebsd.org Fri Mar 12 18:24:28 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 759D65A8E2F; Fri, 12 Mar 2021 18:24:28 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (mail.xzibition.com [52.11.127.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxvNW4G0rz4gW9; Fri, 12 Mar 2021 18:24:27 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 10F1219F70; Fri, 12 Mar 2021 18:24:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id jDwy_3VBYXAG; Fri, 12 Mar 2021 18:24:13 +0000 (UTC) Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com D9DA719F66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shatow.net; s=mxc204805312015; t=1615573453; bh=B4zjcqIrHAN23n0XH7HAE9S15ooWmwJW2m1jRGacKRA=; h=Subject:To:References:From:Date:In-Reply-To; b=WdgVuKlO+WoxXgshcOBBDzeTAUfuQzfVfKp2lf3qXsRtCUCBO1P2Wu2lXd84PtzB3 0SYWsYrD/a4ZCS0MFPI07/QqAX/8CFegrh0mwvXQU29tJ1wknJxSIeENaMMW/hrrkZ 5bnWCxOo94/yXhSGWmyqXBzQaeWCTm9rC0DPOtEGriDQ4gYlgFU7gZgB8ckyQ7hN6o o/qK5AYvzHxLcVz4M8nB1fgViKv0Nhfrx0bWBWoaUHQ+JvVdGES9USySJ4sLCBu0t2 Fy7kYBa01MKYQw2yDpMxfm66B2ylZfADZaHq50mlhWrkFTNYzXXleHCc8ba02ZTUMr yDyn2p6tNtJhg== To: Ed Maste , FreeBSD Hackers , FreeBSD Current References: From: Bryan Drewery Message-ID: Date: Fri, 12 Mar 2021 10:24:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DxvNW4G0rz4gW9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=shatow.net header.s=mxc204805312015 header.b=WdgVuKlO; dmarc=pass (policy=none) header.from=shatow.net; spf=pass (mx1.freebsd.org: domain of bryan-lists@shatow.net designates 52.11.127.251 as permitted sender) smtp.mailfrom=bryan-lists@shatow.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[52.11.127.251:from]; R_DKIM_ALLOW(-0.20)[shatow.net:s=mxc204805312015]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[52.11.127.251:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[shatow.net:+]; DMARC_POLICY_ALLOW(-0.50)[shatow.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16509, ipnet:52.10.0.0/15, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 18:24:28 -0000 On 3/8/2021 12:13 PM, Ed Maste wrote: > 5. Retire the special case for -I "". Just to be clear, we are not suggesting removing compat for -i '' right? -- Regards, Bryan Drewery From owner-freebsd-hackers@freebsd.org Sat Mar 13 08:11:58 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C68DA56D96E for ; Sat, 13 Mar 2021 08:11:58 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyFlL5Lsfz4Xb1; Sat, 13 Mar 2021 08:11:58 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 435F4132D; Sat, 13 Mar 2021 08:11:58 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Sat, 13 Mar 2021 00:11:56 -0800 (PST) From: Don Lewis Subject: Re: problems building a release To: Mark Millard cc: freebsd-hackers In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 08:11:58 -0000 On 10 Mar, Mark Millard wrote: > On 2021-Mar-10, at 15:00, Don Lewis wrote: > >> I'm trying to build a customized 13.0 i386 release on a amd64 host >> running FreeBSD 14.0-CURRENT #89 n245058-1ca8842f3ad9. The source tree >> is branch releng/13.0 from last night. The release build gets most of >> the way through, but fails with: >> >> ===> usr.bin/svn/lib/libsvn_wc (installconfig) >> --- installconfig_subdir_usr.sbin --- >> --- installconfig_subdir_usr.sbin/pkg --- >> --- installdirs-CONFSDIR --- >> --- _CONFSINS_FreeBSD.conf.quarterly --- >> --- installdirs-CONFSDIR --- >> installing DIRS CONFSDIR >> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratch/etc/pkg >> --- _CONFSINS_FreeBSD.conf.quarterly --- >> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf >> Shared object "libedit.so.8" not found, required by "sh" >> >> /scratch/bin/sh seems to work, though it is using the host library: >> # ldd /scratch/bin/sh >> /scratch/bin/sh: >> libedit.so.8 => /usr/lib32/libedit.so.8 (0x20463000) >> libc.so.7 => /usr/lib32/libc.so.7 (0x20495000) >> libncursesw.so.9 => /usr/lib32/libncursesw.so.9 (0x20683000) >> # /scratch/bin/sh >> # >> >> The library is present in /scratch/lib: >> # file /scratch/lib/libedit.so.8 >> /scratch/lib/libedit.so.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 (1300139), stripped >> >> Unfortunately the build isn't verbose enough to give me any hints about >> where the problem might be. I've been able to build FreeBSD 11.x and >> 12.x releases this way, but no luck so far with 13. >> >> Update: I am able to build an amd64 release, so the problem has >> something to do with crossbuilds. There are some other problems that >> crop up, though. >> >> >> ===> usr.bin/svn/lib/libsvn_wc (installconfig) >> --- installconfig_subdir_usr.sbin --- >> --- installconfig_subdir_usr.sbin/pkg --- >> --- installdirs-CONFSDIR --- >> --- _CONFSINS_FreeBSD.conf.quarterly --- >> --- installdirs-CONFSDIR --- >> installing DIRS CONFSDIR >> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratch/etc/pkg >> --- _CONFSINS_FreeBSD.conf.quarterly --- >> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/perl5/5.20/mach/CORE >> 32-bit compatibility ldconfig path: /usr/lib32 >> pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended >> Updating FreeBSD repository catalogue... >> Fetching meta.txz: 100% 916 B 0.9kB/s 00:01 >> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >> repository FreeBSD has no meta file, using default settings >> Fetching packagesite.txz: 100% 6 MiB 1.6MB/s 00:04 >> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >> Unable to open created repository FreeBSD >> Unable to update repository FreeBSD >> All repositories are up-to-date. >> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >> pkg: Repository FreeBSD cannot be opened. 'pkg update' required >> Updating database digests format: 100% >> pkg: No packages available to install matching 'devel/git' have been found in the repositories > > > To my knowledge FreeBSD does not support 14 directly > building 13 or before: self hosted and sufficiently > recent older building newer only, as far as direct > builds go. That doesn't seem to be the problem that I'm running into. I run into a similar problem when trying to build a 14-CURRENT release. The cause of the problem seems to be that I'm specifying TARGET=i386 and TARGET_ARCH=i386 in both release.conf, and the make.conf that release.conf points to. With 14-CURRENT the failure mode is that something can't find ld-elf.so and aborts. That happens a number of times during the release build, but this time the release build appears to run to completion. If I remove the make.conf settings, then the error goes away. The reason that I did this in the first place was so I could set TARGET_CPUTYPE. This setting appears to be ignored in release.conf. If I set it in make.conf without setting TARGET=i386 and TARGET_ARCH=i386, then I get a compiler error because the CPUTYPE is not valid on amd64. Basically, the difference is that with the settings in both places, I get an i386 chroot under /scratch and with the settings different, the chroot is amd64. I thing the failure is being caused when something tries to run an amd64 executable in under the i386 chroot. Verbosity is too low to see what it is. Another complication is that I want to maintain the target system with freebsd-update, so I need to package up my customized make.conf and src.conf into the release so they get used by the update builder. It should be easy to tweak the release script to do this, but it gets complicated if the the make.conf files have different TARGET settings. From owner-freebsd-hackers@freebsd.org Sat Mar 13 09:40:24 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AAB1D5706D7 for ; Sat, 13 Mar 2021 09:40:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyHjN2z98z4d62 for ; Sat, 13 Mar 2021 09:40:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615628422; bh=5fxU0yDpjTWIRtxrRH3m7UtwAZsmTOs1+A101Oj6j0r=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=capUrXd6DoM6bajvUNehFw15KeJZsVJ8NSu0+vfVpwAyPIN52m3W1PllubXUH+Z6a9JVYXUCq4IGpjcyKCmUH25AEwpK/43jQ+PoCjA05N10komJbU6x+EIjtpliZEFUlYMzB3NvHaeSFIyeEl5hpLBh6Rch8RG5N8n/C0ishrsiCMfPs4/FJDOZliewJiGuOShSxz/tipvvW1QMIKabAhtoEZo2n6w0UvvpETI1Xm7pHvrw7wC7Xhjw9lC9vKplCgVYfoeVJCGem+agDUfoxJKbB5G9KGeZKzor6sM5c/5cfML/1GHSorkBhGzuu5BO26MAJNKeDZdyIzTrXHpsTw== X-YMail-OSG: wXaONEgVM1lMmeDODrll8Mm9dpNJYKP1PKstKF3zEZqOx5CRLlOkJRvuUmo57kR 7Wul_tCmGuz09fnl.aKVuFRdR0AycUpW0tY9xcnsMYLUuECHKenp8p7CjxFKYsmOgxmBluPvGWRu nNd4Pu4HyRvA_IY2myPIJx1P.14K6_Pay6N1sPiDz1aRt3v1wHgHH_EUKSwPB6O_Teg0R10Nqvnu fXxE.p8yEMEjKxqVybdDK8S3qw4JUIXPym6Z.eLXNa4Nfo8fZBO.Lplj8GM1_zSU_uLx8pTvnVmE eBxPWOwzPtm0OqxI_9U1w_xfiG6nplTmZa.A56JZ2Ww76J7LPSI2mDGFCVW6Wo9i7zf9s20PyAFP lWPjiNIqizAsSxrzBgkKuYv5S.X75VKiNs_AJuFliBP3ESqoSozQCPQUUUJhYK2egWmdhUau124. sRMIqeGvtUeGbOC.7.ocl3xNKPs7XSIc7DzMhzjJ_mR1R.slgDl921rJrHlKFAdQMq5WY747j_ea PhEPIZsD38rnmaeT80dDg7RozVn5MP1BfJKYbhyzld5KjFve1OITTOj33H6rTYMHe_XlhAei7GQ_ 55Svb444IfnsrpC7XEqWzyDf6MnbuuRaKgudSWIdEQJ5ywMooL7RTLJlOSNV5BYoLO_3WxfUE2xl QotXDr4SdYAmcXp9uJO0ZvzGmerX98hsLa959g153OShP3aKkl7uO6kWDFq.fNpPjl3FHGbFACtT 1z28jhoiCKBAF8aJGxDrXZg5SgWkwhj8j_RAuLeA2bHUd.HI6MyLhMBS32Tu3oj9v2rc285tMqX7 jNcsmo1XnFlFpTdYdxgE0wJuil7npIFqSfAJVx_E5Oar_dman28.k6a3xQws4fev.44Mj5NwI2dj zt3dAB3Zv113aIlHqCzK.ubj7NuRtLlLXtn_LRJlxuM8rhOsMNd7r4POvcglVoZuEjdjhHlBcNsN X_JdvrzPw5m5.80tNb0.9cBG.NBHAWkp3j9QZ8gU3OxTEH3EpeUFYGBFjPvfxh_j66tWlCeQmPpm x5X04FPEQFtzJ5ShZucGNLLYZqLxptM0_MrlkM.fil2RiHr211_L4OyWiKm_tVJOMmYJxDaDSRlC 5nbbrbjwPTr2np0LqIeNGQrf9pstjAXQgYVv4Mf6q5knvaNHKIgRxSI8pK3zfDCFwUzII9d_rRWb 1q7M8f3ZQwYu2lcwzHhjV6uDT4z5bGEepdXBZIr7XvHNV05vs_lcZq_yYJU.v9eZKpKvEj7zrsu8 bwNzWWh8NcuMvcI3b4hymdMtNPBxsAWDHb2TtjrGKwfAMUnkERsx2YYRuSTFDiwqiRN4eqHuZwam QRQXTH2jmOAOwETjqU9ek8eWaFSZaEyriTUJOpVhle9IOXAaBqMOld1xYjFgfEHdfbq1BHBEsP9s OVsnft5dniJaG0YN7NBaqil8gX268Bz2c..jkbvK_VsOpf5PjVxwzg6pNIZRnBFs_YSIofBrJ23p 6fOkcQPeTCR9TuvTSaiBSaWrpzYygUR_GHdnckkHN2U5noxxz8I_s4WVvfTHfXu.xByBKspntMwF VIN9jZGmJVbEtjnGPBCJE9Qak5wZtKV1JYkw2RqeHO9c_BsFVdRktZT0ffK_fJ.j8EPynWWLowTS 0QObkbHq2sVcDiHvbR8rZ8zuM6RKCAFaCEI3nUMZ_BL_xZGwo_DlolCLUBnFVPyuAR.SbCX9vjk3 lRkMAxZwQZnGIe3rPIjUP56z5M4_RfmUatY6UfUDUneH.1Gagjj_4XMi9FUYhPo1P6HyV49fGLU5 enujw.Xdq7gI0hVGVGCPU0BAT.6db0AKx5PUMK3KoYopMxTWGX9mDm.6_ohbSHM_JZ0bwVPMy1F0 itilVn3KR9BbBYD3tY269_g6kboMB3BXxzJASqZE3AB9xFJA7yRHwnwU.dSxN4ciEbpe4HP55wFD L_uxRpWuAesHj295.eO_OKI822fmtP6voB8hII6Famyz7ULPdzkO5HJtVt60aIf7EusZwBeNRJwr SvPhnMHFdGWNG1oz7AQWWnK7xcM7spZd.ObyZ3kQSN_vDHXvz87NxPwX0beNwzPcbBlo5bSNaixR qb3BO67K2cN32TXQBqVPYl5DWHpLTg51oUReHfYH8bgiNTLvbrgONKHjOcCIzbf7jsIHnZXnzNsB gGCu2_2Fgu4KZ_0sdGDySDxzG2FJIpoqYYd8qw7L8fassO4KbIMDFRfDSbV.lYmUmrhPrlTGHYWG DPiavH4.bO1eK.lw4tTUc0XgoxGGbKRwGQ0plKey4jzyD1fiDwSsW1mInu6PJrdL4_th8U2qhxwA e2U7k3baNtWNzeOTuJ.RH6oqMkvsEiPYlecHQ9LI.taA4o3KRmuOpz37gsoCf0XvIX0.Qa.kZLnQ R87Q5m1cgP2lJvE2h19yi4JmC6GX_jiw4LRSmB4oF5R1Zbnd7JGUO4D1iLy5B4t0Zq7HkgcthfrU cvGdkt0j7hAQoZceE.KOGTKJ.xfqG2B_gBKiIoorwvFXLSPQpnF9BzxUTiTLcT7yLT_ZwlZ7Gbi_ TMEFvIqvKLijFmg8TCbDLIW8v2I0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Mar 2021 09:40:22 +0000 Received: by kubenode575.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 99dacff56c30ca1f51462aed16d9519b; Sat, 13 Mar 2021 09:40:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: problems building a release From: Mark Millard In-Reply-To: Date: Sat, 13 Mar 2021 01:40:17 -0800 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <8CE18E0A-8931-4C41-83B4-D30EEC049E6D@yahoo.com> References: To: Don Lewis X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DyHjN2z98z4d62 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 09:40:24 -0000 On 2021-Mar-13, at 00:11, Don Lewis wrote: > On 10 Mar, Mark Millard wrote: >> On 2021-Mar-10, at 15:00, Don Lewis wrote: >>=20 >>> I'm trying to build a customized 13.0 i386 release on a amd64 host >>> running FreeBSD 14.0-CURRENT #89 n245058-1ca8842f3ad9. The source = tree >>> is branch releng/13.0 from last night. The release build gets most = of >>> the way through, but fails with: >>>=20 >>> =3D=3D=3D> usr.bin/svn/lib/libsvn_wc (installconfig) >>> --- installconfig_subdir_usr.sbin --- >>> --- installconfig_subdir_usr.sbin/pkg --- >>> --- installdirs-CONFSDIR --- >>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>> --- installdirs-CONFSDIR --- >>> installing DIRS CONFSDIR >>> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel = /scratch/etc/pkg >>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 = /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly = /scratch/etc/pkg/FreeBSD.conf >>> Shared object "libedit.so.8" not found, required by "sh" >>>=20 >>> /scratch/bin/sh seems to work, though it is using the host library: >>> # ldd /scratch/bin/sh >>> /scratch/bin/sh: >>> libedit.so.8 =3D> /usr/lib32/libedit.so.8 (0x20463000) >>> libc.so.7 =3D> /usr/lib32/libc.so.7 (0x20495000) >>> libncursesw.so.9 =3D> /usr/lib32/libncursesw.so.9 (0x20683000) >>> # /scratch/bin/sh >>> #=20 >>>=20 >>> The library is present in /scratch/lib: >>> # file /scratch/lib/libedit.so.8 >>> /scratch/lib/libedit.so.8: ELF 32-bit LSB shared object, Intel = 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 = (1300139), stripped >>>=20 >>> Unfortunately the build isn't verbose enough to give me any hints = about >>> where the problem might be. I've been able to build FreeBSD 11.x = and >>> 12.x releases this way, but no luck so far with 13. >>>=20 >>> Update: I am able to build an amd64 release, so the problem has >>> something to do with crossbuilds. There are some other problems = that >>> crop up, though. >>>=20 >>>=20 >>> =3D=3D=3D> usr.bin/svn/lib/libsvn_wc (installconfig) >>> --- installconfig_subdir_usr.sbin --- >>> --- installconfig_subdir_usr.sbin/pkg --- >>> --- installdirs-CONFSDIR --- >>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>> --- installdirs-CONFSDIR --- >>> installing DIRS CONFSDIR >>> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel = /scratch/etc/pkg >>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 = /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly = /scratch/etc/pkg/FreeBSD.conf >>> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/perl5/5.20/mach/CORE >>> 32-bit compatibility ldconfig path: /usr/lib32 >>> pkg: Warning: Major OS version upgrade detected. Running = "pkg-static install -f pkg" recommended >>> Updating FreeBSD repository catalogue... >>> Fetching meta.txz: 100% 916 B 0.9kB/s 00:01 =20 >>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >>> repository FreeBSD has no meta file, using default settings >>> Fetching packagesite.txz: 100% 6 MiB 1.6MB/s 00:04 =20 >>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >>> Unable to open created repository FreeBSD >>> Unable to update repository FreeBSD >>> All repositories are up-to-date. >>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >>> pkg: Repository FreeBSD cannot be opened. 'pkg update' required >>> Updating database digests format: 100% >>> pkg: No packages available to install matching 'devel/git' have been = found in the repositories >>=20 >>=20 >> To my knowledge FreeBSD does not support 14 directly >> building 13 or before: self hosted and sufficiently >> recent older building newer only, as far as direct >> builds go. >=20 > That doesn't seem to be the problem that I'm running into. I run into = a > similar problem when trying to build a 14-CURRENT release. The cause = of > the problem seems to be that I'm specifying TARGET=3Di386 and = TARGET_ARCH=3Di386 > in both release.conf, and the make.conf that release.conf points to. > With 14-CURRENT the failure mode is that something can't find = ld-elf.so > and aborts. That happens a number of times during the release build, > but this time the release build appears to run to completion. If I > remove the make.conf settings, then the error goes away. The reason > that I did this in the first place was so I could set TARGET_CPUTYPE. > This setting appears to be ignored in release.conf. If I set it in > make.conf without setting TARGET=3Di386 and TARGET_ARCH=3Di386, then I = get a > compiler error because the CPUTYPE is not valid on amd64. Basically, > the difference is that with the settings in both places, I get an i386 > chroot under /scratch and with the settings different, the chroot is > amd64. I thing the failure is being caused when something tries to = run > an amd64 executable in under the i386 chroot. Verbosity is too low to > see what it is. >=20 > Another complication is that I want to maintain the target system with > freebsd-update, so I need to package up my customized make.conf and > src.conf into the release so they get used by the update builder. It > should be easy to tweak the release script to do this, but it gets > complicated if the the make.conf files have different TARGET settings. >=20 You are definitely working outside my direct experience. But I'll note that release/release.conf.sample and the man page have all of the following, not that I understand the various implications of use: ## Set to override the default target architecture. #TARGET=3D"amd64" #TARGET_ARCH=3D"amd64" #KERNEL=3D"GENERIC" ## Multiple kernels may be set. #KERNEL=3D"GENERIC XENHVM" . . . ## Set to pass additional flags to make(1) for the build chroot setup, = such ## as TARGET/TARGET_ARCH. #CHROOT_MAKEENV=3D Also described via: CHROOT_MAKEENV Additional make(1) arguments to pass through, which directly affect the tuning of the build chroot. TARGET and TARGET_ARCH are also listed as controllable via the ENVIRONMENT : TARGET The target hardware platform. This is analogous = to the =E2=80=9Cuname -m=E2=80=9D output. This is = necessary to cross-build some target architectures. For example, = cross-building for ARM64 machines requires TARGET_ARCH=3Daarch64 = and TARGET=3Darm64. If not set, TARGET defaults to = the current hardware platform. TARGET_ARCH The target machine processor architecture. This = is analogous to the =E2=80=9Cuname -p=E2=80=9D = output. Set this to cross- build for a different architecture. If not set, TARGET_ARCH defaults to the current machine architecture, unless TARGET is also set, in which = case it defaults to the appropriate value for that = platform. Typically, one only needs to set TARGET. A possibility would seem to be use of: ## Set to the hardware platform of the target userland. This value ## is passed to make(1) to set the TARGET (value of uname -m) to cross ## build. #EMBEDDED_TARGET=3D ## Set to the machine processor architecture of the target userland. ## This value is passed to make(1) to set the TARGET_ARCH (value of = uname -p) ## to cross build. #EMBEDDED_TARGET_ARCH=3D May be EMBEDDEDBUILD=3D with an empty or nonexistent EMBEDDEDPORTS might happen to do somethings useful for your context? (Implication of WITH_DVD being unset when EMBEDDEDBUILD=3D is in use. Implicit EMBEDDEDPORTS such as devel/subversion ?) A different direction is to have release use a pre-existing build (separately built beforehand). As I vaguely remember, this involved: ## Set to skip the chroot environment = buildworld/installworld/distribution ## step if it is expected the build environment will exist via alternate ## means. #CHROOTBUILD_SKIP=3D Also described via: CHROOTBUILD_SKIP If defined, the buildworld, installworld, and distribution stages of the chroot(8) build = environment setup are skipped. This is intended solely for = cases where the chroot(8) userland are provided by = alternate means. There are also: ## Redefine environment variables here to override prototypes ## defined in release.sh. #load_chroot_env() { } #load_target_env() { } #buildenv_setup() { } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sat Mar 13 16:35:35 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D79357BF26 for ; Sat, 13 Mar 2021 16:35:35 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane-mx.org) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DySwQ0tGbz544B for ; Sat, 13 Mar 2021 16:35:33 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane-mx.org) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lL7Eb-0009ae-UW for freebsd-hackers@freebsd.org; Sat, 13 Mar 2021 17:35:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Johannes Totz Subject: Kernel dump during boot Date: Sat, 13 Mar 2021 16:35:20 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 X-Mozilla-News-Host: news://news.gmame.org:119 Content-Language: en-GB X-Rspamd-Queue-Id: 4DySwQ0tGbz544B X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=jo-t.de (policy=none); spf=pass (mx1.freebsd.org: domain of freebsd-hackers@m.gmane-mx.org designates 116.202.254.214 as permitted sender) smtp.mailfrom=freebsd-hackers@m.gmane-mx.org X-Spamd-Result: default: False [0.36 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[116.202.254.214:from]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[116.202.254.214:from:127.0.2.255]; DMARC_POLICY_SOFTFAIL(0.10)[jo-t.de : SPF not aligned (relaxed), No valid DKIM,none]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-0.74)[-0.738]; FORGED_SENDER(0.30)[johannes@jo-t.de,freebsd-hackers@m.gmane-mx.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; FROM_NEQ_ENVFROM(0.00)[johannes@jo-t.de,freebsd-hackers@m.gmane-mx.org]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 16:35:35 -0000 Hey everyone, is there a way to dump the kernel from DDB? I've got a panic during boot, before init is started but after geom and friends are up. So dumpdev hasnt been set yet. Can I hardcode it somewhere? Setting kern.shutdown.dumpdevname in loader.conf doesn't seem to work. Searching around I found some old messages that say it's not possible. Is that still the case? Thanks, Johannes From owner-freebsd-hackers@freebsd.org Sat Mar 13 20:43:16 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3F5605AAF9B for ; Sat, 13 Mar 2021 20:43:16 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyZQD1Fpdz3P2W; Sat, 13 Mar 2021 20:43:16 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 929FA6EF9; Sat, 13 Mar 2021 20:43:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Sat, 13 Mar 2021 12:43:13 -0800 (PST) From: Don Lewis Subject: Re: problems building a release To: Mark Millard cc: freebsd-hackers In-Reply-To: <8CE18E0A-8931-4C41-83B4-D30EEC049E6D@yahoo.com> Message-ID: References: <8CE18E0A-8931-4C41-83B4-D30EEC049E6D@yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-13 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 20:43:16 -0000 On 13 Mar, Mark Millard wrote: > On 2021-Mar-13, at 00:11, Don Lewis wrote: >=20 >> On 10 Mar, Mark Millard wrote: >>> On 2021-Mar-10, at 15:00, Don Lewis wrote: >>>=20 >>>> I'm trying to build a customized 13.0 i386 release on a amd64 host >>>> running FreeBSD 14.0-CURRENT #89 n245058-1ca8842f3ad9. The source tre= e >>>> is branch releng/13.0 from last night. The release build gets most of >>>> the way through, but fails with: >>>>=20 >>>> =3D=3D=3D> usr.bin/svn/lib/libsvn_wc (installconfig) >>>> --- installconfig_subdir_usr.sbin --- >>>> --- installconfig_subdir_usr.sbin/pkg --- >>>> --- installdirs-CONFSDIR --- >>>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>>> --- installdirs-CONFSDIR --- >>>> installing DIRS CONFSDIR >>>> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratc= h/etc/pkg >>>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>>> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch= /usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf >>>> Shared object "libedit.so.8" not found, required by "sh" >>>>=20 >>>> /scratch/bin/sh seems to work, though it is using the host library: >>>> # ldd /scratch/bin/sh >>>> /scratch/bin/sh: >>>> =09libedit.so.8 =3D> /usr/lib32/libedit.so.8 (0x20463000) >>>> =09libc.so.7 =3D> /usr/lib32/libc.so.7 (0x20495000) >>>> =09libncursesw.so.9 =3D> /usr/lib32/libncursesw.so.9 (0x20683000) >>>> # /scratch/bin/sh >>>> #=20 >>>>=20 >>>> The library is present in /scratch/lib: >>>> # file /scratch/lib/libedit.so.8 >>>> /scratch/lib/libedit.so.8: ELF 32-bit LSB shared object, Intel 80386, = version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 (1300139), stripp= ed >>>>=20 >>>> Unfortunately the build isn't verbose enough to give me any hints abou= t >>>> where the problem might be. I've been able to build FreeBSD 11.x and >>>> 12.x releases this way, but no luck so far with 13. >>>>=20 >>>> Update: I am able to build an amd64 release, so the problem has >>>> something to do with crossbuilds. There are some other problems that >>>> crop up, though. >>>>=20 >>>>=20 >>>> =3D=3D=3D> usr.bin/svn/lib/libsvn_wc (installconfig) >>>> --- installconfig_subdir_usr.sbin --- >>>> --- installconfig_subdir_usr.sbin/pkg --- >>>> --- installdirs-CONFSDIR --- >>>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>>> --- installdirs-CONFSDIR --- >>>> installing DIRS CONFSDIR >>>> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratc= h/etc/pkg >>>> --- _CONFSINS_FreeBSD.conf.quarterly --- >>>> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch= /usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf >>>> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/l= ocal/lib/perl5/5.20/mach/CORE >>>> 32-bit compatibility ldconfig path: /usr/lib32 >>>> pkg: Warning: Major OS version upgrade detected. Running "pkg-static = install -f pkg" recommended >>>> Updating FreeBSD repository catalogue... >>>> Fetching meta.txz: 100% 916 B 0.9kB/s 00:01 =20 >>>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >>>> repository FreeBSD has no meta file, using default settings >>>> Fetching packagesite.txz: 100% 6 MiB 1.6MB/s 00:04 =20 >>>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >>>> Unable to open created repository FreeBSD >>>> Unable to update repository FreeBSD >>>> All repositories are up-to-date. >>>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2 >>>> pkg: Repository FreeBSD cannot be opened. 'pkg update' required >>>> Updating database digests format: 100% >>>> pkg: No packages available to install matching 'devel/git' have been f= ound in the repositories >>>=20 >>>=20 >>> To my knowledge FreeBSD does not support 14 directly >>> building 13 or before: self hosted and sufficiently >>> recent older building newer only, as far as direct >>> builds go. >>=20 >> That doesn't seem to be the problem that I'm running into. I run into a >> similar problem when trying to build a 14-CURRENT release. The cause of >> the problem seems to be that I'm specifying TARGET=3Di386 and TARGET_ARC= H=3Di386 >> in both release.conf, and the make.conf that release.conf points to. >> With 14-CURRENT the failure mode is that something can't find ld-elf.so >> and aborts. That happens a number of times during the release build, >> but this time the release build appears to run to completion. If I >> remove the make.conf settings, then the error goes away. The reason >> that I did this in the first place was so I could set TARGET_CPUTYPE. >> This setting appears to be ignored in release.conf. If I set it in >> make.conf without setting TARGET=3Di386 and TARGET_ARCH=3Di386, then I g= et a >> compiler error because the CPUTYPE is not valid on amd64. Basically, >> the difference is that with the settings in both places, I get an i386 >> chroot under /scratch and with the settings different, the chroot is >> amd64. I thing the failure is being caused when something tries to run >> an amd64 executable in under the i386 chroot. Verbosity is too low to >> see what it is. >>=20 >> Another complication is that I want to maintain the target system with >> freebsd-update, so I need to package up my customized make.conf and >> src.conf into the release so they get used by the update builder. It >> should be easy to tweak the release script to do this, but it gets >> complicated if the the make.conf files have different TARGET settings. >>=20 >=20 > You are definitely working outside my direct > experience. But I'll note that > release/release.conf.sample and the man page > have all of the following, not that I > understand the various implications of use: >=20 > ## Set to override the default target architecture. > #TARGET=3D"amd64" > #TARGET_ARCH=3D"amd64" > #KERNEL=3D"GENERIC" > ## Multiple kernels may be set. > #KERNEL=3D"GENERIC XENHVM" > . . . > ## Set to pass additional flags to make(1) for the build chroot setup, su= ch > ## as TARGET/TARGET_ARCH. > #CHROOT_MAKEENV=3D >=20 > Also described via: >=20 > CHROOT_MAKEENV Additional make(1) arguments to pass through, which > directly affect the tuning of the build chroot. >=20 > TARGET and TARGET_ARCH are also listed as controllable > via the ENVIRONMENT : >=20 > TARGET The target hardware platform. This is analogous to= the > =B4uname -m=A1 output. This is necessary to cross-= build > some target architectures. For example, cross-buil= ding > for ARM64 machines requires TARGET_ARCH=3Daarch64 a= nd > TARGET=3Darm64. If not set, TARGET defaults to the > current hardware platform. >=20 > TARGET_ARCH The target machine processor architecture. This is > analogous to the =B4uname -p=A1 output. Set this t= o cross- > build for a different architecture. If not set, > TARGET_ARCH defaults to the current machine > architecture, unless TARGET is also set, in which c= ase > it defaults to the appropriate value for that platf= orm. > Typically, one only needs to set TARGET. >=20 >=20 > A possibility would seem to be use of: >=20 > ## Set to the hardware platform of the target userland. This value > ## is passed to make(1) to set the TARGET (value of uname -m) to cross > ## build. > #EMBEDDED_TARGET=3D >=20 > ## Set to the machine processor architecture of the target userland. > ## This value is passed to make(1) to set the TARGET_ARCH (value of uname= -p) > ## to cross build. > #EMBEDDED_TARGET_ARCH=3D >=20 > May be EMBEDDEDBUILD=3D with an empty or nonexistent EMBEDDEDPORTS > might happen to do somethings useful for your context? (Implication > of WITH_DVD being unset when EMBEDDEDBUILD=3D is in use. Implicit > EMBEDDEDPORTS such as devel/subversion ?) >=20 >=20 > A different direction is to have release use a pre-existing build > (separately built beforehand). As I vaguely remember, this involved: >=20 > ## Set to skip the chroot environment buildworld/installworld/distributio= n > ## step if it is expected the build environment will exist via alternate > ## means. > #CHROOTBUILD_SKIP=3D >=20 > Also described via: >=20 > CHROOTBUILD_SKIP > If defined, the buildworld, installworld, and > distribution stages of the chroot(8) build environm= ent > setup are skipped. This is intended solely for cas= es > where the chroot(8) userland are provided by altern= ate > means. >=20 >=20 > There are also: >=20 > ## Redefine environment variables here to override prototypes > ## defined in release.sh. > #load_chroot_env() { } > #load_target_env() { } > #buildenv_setup() { } Thanks. All of this stuff is pretty confusing. If I specify MAKE_CONF in release.conf, it does affect the target build. In particular MODULES_OVERRIDE does the right thing. It seems like there should be a way to specify a make.conf and src.conf so that they get included in the release so that if the release is installed and then world and kernel are built it reproduces itself. I did manage to unmute release.sh and make so that the build is verbose, but the error I get when I specify TARGET and TARGET_ARCH in the make.conf is still a mystery. There doesn't seem to be a line buffering problem hiding things, this was captured from the terminal window with no redirections involved. =3D=3D=3D> etc (installconfig) mkdir -p bootonly/usr/freebsd-dist cp MANIFEST bootonly/usr/freebsd-dist ln -fs /tmp/bsdinstall_etc/resolv.conf bootonly/etc/resolv.conf echo sendmail_enable=3D\"NONE\" > bootonly/etc/rc.conf echo hostid_enable=3D\"NO\" >> bootonly/etc/rc.conf echo debug.witness.trace=3D0 >> bootonly/etc/sysctl.conf echo vfs.mountroot.timeout=3D\"10\" >> bootonly/boot/loader.conf echo kernels_autodetect=3D\"NO\" >> bootonly/boot/loader.conf cp /usr/src/release/rc.local bootonly/etc sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_BO bootonly.is= o bootonly=20 sh /usr/src/release/i386/make-memstick.sh disc1 memstick.img Calculated size of `memstick.img.part': 624754688 bytes, 13074 inodes Extent size set to 32768 memstick.img.part: 595.8MB (1220224 sectors) block size 32768, fragment siz= e 4096 =09using 1 cylinder groups of 595.81MB, 19066 blks, 13952 inodes. super-block backups (for fsck -b #) at: 192, Populating `memstick.img.part' Image `memstick.img.part' complete sh /usr/src/release/i386/make-memstick.sh bootonly mini-memstick.img Calculated size of `mini-memstick.img.part': 237436928 bytes, 13069 inodes Extent size set to 32768 mini-memstick.img.part: 226.4MB (463744 sectors) block size 32768, fragment= size 4096 =09using 1 cylinder groups of 226.44MB, 7246 blks, 14592 inodes. super-block backups (for fsck -b #) at: 192, Populating `mini-memstick.img.part' Image `mini-memstick.img.part' complete make -C /usr/src/release release-done ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap touch release true + eval chroot /scratch make -C /usr/src/release 'TARGET=3Di386' 'TARGET_ARC= H=3Di386' 'KERNCONF=3D"GW"' '__MAKE_CONF=3D/home/dl/gw-release/make.conf' '= SRCCONF=3D/home/dl/gw-release/src.conf' 'NOPORTS=3Dyes' 'WITH_DVD=3D' 'WITH= _VMIMAGES=3D' 'WITH_CLOUDWARE=3D' 'XZ_THREADS=3D0' install 'DESTDIR=3D/R' '= WITH_COMPRESSED_IMAGES=3D' 'WITH_COMPRESSED_VMIMAGES=3D' + chroot /scratch make -C /usr/src/release 'TARGET=3Di386' 'TARGET_ARCH=3Di= 386' 'KERNCONF=3DGW' '__MAKE_CONF=3D/home/dl/gw-release/make.conf' 'SRCCONF= =3D/home/dl/gw-release/src.conf' 'NOPORTS=3Dyes' 'WITH_DVD=3D' 'WITH_VMIMAG= ES=3D' 'WITH_CLOUDWARE=3D' 'XZ_THREADS=3D0' install 'DESTDIR=3D/R' 'WITH_CO= MPRESSED_IMAGES=3D' 'WITH_COMPRESSED_VMIMAGES=3D' ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap mkdir -p /R cp -a ftp /R/ cp -p disc1.iso /R/FreeBSD-14.0-CURRENT-i386-disc1.iso cp -p bootonly.iso /R/FreeBSD-14.0-CURRENT-i386-bootonly.iso cp -p memstick.img /R/FreeBSD-14.0-CURRENT-i386-memstick.img cp -p mini-memstick.img /R/FreeBSD-14.0-CURRENT-i386-mini-memstick.img cd /R && sha512 FreeBSD-14.0-CURRENT-i386* > /R/CHECKSUM.SHA512 cd /R && sha256 FreeBSD-14.0-CURRENT-i386* > /R/CHECKSUM.SHA256 + return 0 + return 0 + umount /scratch/dev From owner-freebsd-hackers@freebsd.org Sat Mar 13 21:41:30 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C7D125ACA19 for ; Sat, 13 Mar 2021 21:41:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DybjQ3qSBz3hqh for ; Sat, 13 Mar 2021 21:41:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615671688; bh=w7WeGhDwAVe2KKJpOFR+kQOc6hTLC8XJOsO8oYdJ+TO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SjCvp7w4fd+NP4VYhOz/AeJIgLzBa8vm9IupN9sJHh5DE0wmMFQ537h82KYg8QoW3qH54XZmcgLjOmj7y4WB6XF62SRK8m0eNDxKf+XIQzDVcH+EWUqXWs4itgIiBHR6ju3NzciFe7WLq1kPdpp9DIFsmwODnIp1CKPdmIV/ZQWYQ2BLjIXbU7GJDESIamXoG2SHVJ+6O/M+sg4a0LQjEssnO1qaRm0gVURW0iEIBwHGYo/udwnEV+vCmGlWGalrSQBK5s8GBlFtk0m7d76/lzGgvYEXdTZLIT9xnYMt+E7Z1qN1vHZpuTUzMO3NydGCIKnM9WGQlW/nLlOyypnfvA== X-YMail-OSG: N7QZhYMVM1kXLURVPk2uHNjfBWHL1o6.rke15jtNmECzLdMDgeTVVgGXKctxbcg OWTNWBI2P9QXW6w.OsSFrPzhdE7GcBhPrBPSufVugRXimT_M0hGWia7d8pYS6saHWeDkdNi7MvHK n.7CaPxwnUzMm4xrXEkWYzucQ3K_X_u5Dkcj1yzxZTgHti8FR_EO_lMnBEJssdWmSlmSyS3dNv1o aB0KrCt4aHnnypj23nd7yBZv8RYupeNqpprSPrQfb8ZF8N7qn1l92yPMm5_a2q7A9YdCuwTg0ybb SKBcZAsqKXp1teMOnfnyAx.G97Hbwlq6G35cd96WjOGYfRSyeX3zybpk4Yo1WEAepbP2de_Evc0z 6QAZpyzmIuvg97r4kF8cuJiEPmN8_mLDiPlAyHftGPAvCBMFHqLuXDhCbLtSqiL8KLDZwuCHTLDt HRjcsIDRzDdPSVMTD6fQgBYfZUoO1WS.SIgPYaM1EjeMayxPsbwto3tqCYaevL_JMDaHq5YGLCma rTwNrFXfieLVXNoZru0W8t_CGmBa6Sxys_9zmQ37hJBmmmaX3ps5R07uK5PsNcK8pqEsvDsYD2GY ajrTMmQIq4D8dTt.8X33NR3feDQ06m1.GLg54jBlbrm2bg.n.kr1QPFpQnVBbDlRYP0MOBaHQGGC _NXkSMiAKJ0GAgyZCWMlyG9YAJBhbzUO4hc6wZIQtWZeapTzYi2kI.Q6_S4zmj_xMT1vi8zvk5Pq 0A.HYsc3PeGcGjuR.OPBp9utxboemDIIPJ4r1HypaNQjZOeMqwitNKnmC523EhFtVWleUJbG.6T4 UJOXHkV84WKhfjE57Ae54xLih1rxpTnbwYLPKkQD7_3fYBoyqFnxj4IfamJcQw52pfgZOHaygKz3 zlaRSX2wyu3czbGQoQuefSs9Pe95pcydKTSxGVBrfDMwM30H4ErIV9CJZsDPRJFhicMgM06g32bF QZp7j0RJ3cosPhBa04Gsf4iZpmNmbTC5LT3kW5Y5Cr7sBAjatL4kgRp4Ae8MCBPi6VHLaTaV3M8a qYqL2n4I_H2g__lLTjDHck61.Sb_XLCCYJX4coG3er44ysSPOM60VgQxbykg5zDCQ2ds_93b9Aw6 GDgdsivXEHbN2mYjImjba4GHNtHCp.1eVOuB4VExhg0_YlJKKmKzgP9AoS1vBpQUYTopxDSYp66b nQUzFBvAwUwcQRJpYeJFjEfVZjwl9jVQtdZ6delTCny2ZA6VePZ8.gyaJQInMQNLl68vMH8rYhJp YPWblcfP52VS0.vfXntr08FSKFS_24eXSSRwgMwDCwmNIJJZJfUlr28C62vUOXTUMmKRb_EqRiG4 .EJ_Pm7RtEQitmcfAzLrYHYFvCYpOwdBPD747YJp5FssQRKyiGa7RNV9Sgba6ytnTuJ9KzvIZZxo gQYYcn12RCu47yzER_1gl_ruYmGEGsawny4Qc3NsD59YCB98RGthYmkG62Qd4WWaoh7kddm9BfDZ NM7NCBR24rfezhICObwCrxi5jXruNFnNeNH8KVYBLJMxTJ9TbLb31ZwjcCicfWYgL8dUZFuFywso jyXtt5GY3m1mPHtYLDQKHmjpPckPe0lpGcLgQyN5yaEV5uQkQG.sDTfbbjguR6qvkh0IMXlBESTE _wrrAdU425UvUh.oJrBcCi1KZy4DITVGSCWUA1ffv490IbT7br2QQFlSpZ5dg0vWk2Cc8rl4Gaql DIS81y_E5w.k_LcdRlHNREjYvTb_6TvoxnVYkw3nsyM1mPNnfCBzQc7hEDw2n32P6DG4S4CBnjEI EU5xquyarRXFa48QA7TIDWqZMcHCPzuZeFgS22kQCbk4iGjTbi.LlkP31uJpVOrsTBZ4rBWHaWCi uNqjmusVzerqe..0c0c2zc.LpjW6EkK.44gNPc83HAzRKtrAOF6r6KbkcIf1_It1PXAsdUQl31bf Q6dCR30ebWCsYQiaayx.N6dlADj.sU4H_b_JGsEEe5c8hKFlWovpgMnV2HH7dzTndIZZsuEkEFtN 33iDEkgvg3J8eEk95GWNIhmWl8rNTT92wHL_lRlPC7k5kFIhmQGzRxt6nOLVJdBYhSwMq761_sl5 bahshIGSN4zn5ZGrz_8PltqQMUpqOqk.IMx7A5L4zuNVHqNTWIocbpx4hdPRQgUjE1GBg1Fbb1Uj PDufwXwiNyckGjO_qiyzWQDLkRnOadcKd6vx3xgP5S0lKBxbZ6lRvR_CdPVDaUMYj3t__a7bEW1s eMCj6i11gaJ9aLioApdeRstVnD5S5mmEaCBhPG_K4RUrL82CSg5cMKo4vwTj.oAt92TpH_GyfibG i_s3SZMoEh4xabkRQH.dvWtNUng9DN8VORxtqeWFgIEZP5mFEmsKgS7TlqmJbwnUFmksZnJluwNe Ln2IUwHZkjd6F3XT4OFhko.4ruF7titx1lV0Jm.xv6A8Xavmb7HwatNaR0KhrQ0zFvbJPp_uRJpD XFKue9I4dmBscLK4NGFB.BQkxOBbDE0SvFDxGaTZwZbEKGsPpPhtnLTWhS_bxm5V5InuqxhEJgj. K8vuPSOc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Mar 2021 21:41:28 +0000 Received: by smtp406.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 20591359d219f1dd39140c8f763dc8bb; Sat, 13 Mar 2021 21:41:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: problems building a release From: Mark Millard In-Reply-To: Date: Sat, 13 Mar 2021 13:41:23 -0800 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CE18E0A-8931-4C41-83B4-D30EEC049E6D@yahoo.com> To: Don Lewis X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DybjQ3qSBz3hqh X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 21:41:30 -0000 > On 2021-Mar-13, at 12:43, Don Lewis wrote: >=20 > On 13 Mar, Mark Millard wrote: >> . . . >=20 > Thanks. All of this stuff is pretty confusing. >=20 > If I specify MAKE_CONF in release.conf, it does affect the target = build. > In particular MODULES_OVERRIDE does the right thing. >=20 > It seems like there should be a way to specify a make.conf and = src.conf > so that they get included in the release so that if the release is > installed and then world and kernel are built it reproduces itself. >=20 > I did manage to unmute release.sh and make so that the build is = verbose, > but the error I get when I specify TARGET and TARGET_ARCH in the > make.conf is still a mystery. There doesn't seem to be a line = buffering > problem hiding things, this was captured from the terminal window with > no redirections involved. >=20 > =3D=3D=3D> etc (installconfig) > mkdir -p bootonly/usr/freebsd-dist > cp MANIFEST bootonly/usr/freebsd-dist > ln -fs /tmp/bsdinstall_etc/resolv.conf bootonly/etc/resolv.conf > echo sendmail_enable=3D\"NONE\" > bootonly/etc/rc.conf > echo hostid_enable=3D\"NO\" >> bootonly/etc/rc.conf > echo debug.witness.trace=3D0 >> bootonly/etc/sysctl.conf > echo vfs.mountroot.timeout=3D\"10\" >> bootonly/boot/loader.conf > echo kernels_autodetect=3D\"NO\" >> bootonly/boot/loader.conf > cp /usr/src/release/rc.local bootonly/etc > sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_BO = bootonly.iso bootonly=20 > sh /usr/src/release/i386/make-memstick.sh disc1 memstick.img > Calculated size of `memstick.img.part': 624754688 bytes, 13074 inodes > Extent size set to 32768 > memstick.img.part: 595.8MB (1220224 sectors) block size 32768, = fragment size 4096 > using 1 cylinder groups of 595.81MB, 19066 blks, 13952 inodes. > super-block backups (for fsck -b #) at: > 192, > Populating `memstick.img.part' > Image `memstick.img.part' complete > sh /usr/src/release/i386/make-memstick.sh bootonly mini-memstick.img > Calculated size of `mini-memstick.img.part': 237436928 bytes, 13069 = inodes > Extent size set to 32768 > mini-memstick.img.part: 226.4MB (463744 sectors) block size 32768, = fragment size 4096 > using 1 cylinder groups of 226.44MB, 7246 blks, 14592 inodes. > super-block backups (for fsck -b #) at: > 192, > Populating `mini-memstick.img.part' > Image `mini-memstick.img.part' complete The below notes are about what starts here: > make -C /usr/src/release release-done > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > touch release > true That is interesting as this turns out to be a fairly simple context by the time that "make . . . release-done" is echoed: QUOTE release: real-release vm-release cloudware-release ${MAKE} -C ${.CURDIR} ${.MAKEFLAGS} release-done true release-done: touch release END QUOTE but by then "real-release vm-release cloudware-release" completed and we see the touch and true after the messages. So it looks like the 6 "not found" messages are from make's internal activities. It would be interesting to get a truss -f log (or some such) of that "${MAKE} . . . release-done" out into to a file. There should not be much other activity in the file generated. That might expose the activity producing the "not found" messages. Also interesting might be adding a "file /libexec/ld-elf.so.1" command line to release: or adding other such context reporting there, such as "uname -apKU" . > + eval chroot /scratch make -C /usr/src/release 'TARGET=3Di386' = 'TARGET_ARCH=3Di386' 'KERNCONF=3D"GW"' = '__MAKE_CONF=3D/home/dl/gw-release/make.conf' = 'SRCCONF=3D/home/dl/gw-release/src.conf' 'NOPORTS=3Dyes' 'WITH_DVD=3D' = 'WITH_VMIMAGES=3D' 'WITH_CLOUDWARE=3D' 'XZ_THREADS=3D0' install = 'DESTDIR=3D/R' 'WITH_COMPRESSED_IMAGES=3D' 'WITH_COMPRESSED_VMIMAGES=3D' > + chroot /scratch make -C /usr/src/release 'TARGET=3Di386' = 'TARGET_ARCH=3Di386' 'KERNCONF=3DGW' = '__MAKE_CONF=3D/home/dl/gw-release/make.conf' = 'SRCCONF=3D/home/dl/gw-release/src.conf' 'NOPORTS=3Dyes' 'WITH_DVD=3D' = 'WITH_VMIMAGES=3D' 'WITH_CLOUDWARE=3D' 'XZ_THREADS=3D0' install = 'DESTDIR=3D/R' 'WITH_COMPRESSED_IMAGES=3D' 'WITH_COMPRESSED_VMIMAGES=3D' > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap > ELF interpreter /libexec/ld-elf.so.1 not found, error 8 > Abort trap QUOTE install: release-install vm-install END QUOTE where the release-install: commands are listed later below (so after the "not found" messages). Again: seems to be make-internal activities that generate the 6 messages. > mkdir -p /R > cp -a ftp /R/ > cp -p disc1.iso /R/FreeBSD-14.0-CURRENT-i386-disc1.iso > cp -p bootonly.iso /R/FreeBSD-14.0-CURRENT-i386-bootonly.iso > cp -p memstick.img /R/FreeBSD-14.0-CURRENT-i386-memstick.img > cp -p mini-memstick.img /R/FreeBSD-14.0-CURRENT-i386-mini-memstick.img > cd /R && sha512 FreeBSD-14.0-CURRENT-i386* > /R/CHECKSUM.SHA512 > cd /R && sha256 FreeBSD-14.0-CURRENT-i386* > /R/CHECKSUM.SHA256 > + return 0 > + return 0 > + umount /scratch/dev From owner-freebsd-hackers@freebsd.org Sat Mar 13 21:57:20 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 119E45AC970 for ; Sat, 13 Mar 2021 21:57:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dyc3g10XWz3k7h for ; Sat, 13 Mar 2021 21:57:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615672637; bh=RjpzQ/qZZj2hiKG8kR3vWk7yCseq0PZlTdVjP+XywxZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QZv0HaN68HuVuCyFvdGxQxBtWKN7n95J2FREuuxghA+HOc4YWujxlufsif45AeuWRmuPk/NLNbbXLAxeO/X7RgKLggkAsgPT9uD4KVBSCoUsl7qb4y3umiHkz/+VgJMKkx2peh6kLhNx75uvqqISCrw6xosbhjJTfTJv0gVQWCZKsa5nZCuF3TeA79MN0IIkJw3SjZBpR3G5FslDRiUDg5bRV/JWd9LvRneQ7dxqnl5JqdfCLq9Ihckqe1OlxrXGakrLHzDPcdNKHFgz0LtWehxmvOhOmQ5q4/DMgE5PLzvhUFEao72zFatpMi0vIF6CuNdyMDyiKzk9YYZcBVTEuw== X-YMail-OSG: xOypgtcVM1mGPslREW4OMFeI2s6Cyvv0htOAKcDyMiCKFWGZ260r36XC_QZqrNJ hERXFasX1XfTnSfBicXqH44uKXpkI5NVWBCcrTrmDV0qw_twzIbUiA4sJoIi3D8a7aLv8a9L4Sf1 FMhKZqa74lRMxl4Z3P9Qtp9Eq9AgFW3KDjusBB__5_MrWcw67JrmXkX3ro_i4EcZdHEgv7l42FJP odt1IRqhnT7PE2kttqBl0RSkib8WRDGAMKHB.2WxxGqfvYr1IsTXvc5I0nbLkj.AhgaeKquXzo1C XJ_aQYr2VvTvDIGJi.pdmIct6totu1gZezZz3pszIZYX_529uDuPyu.LMpYO.Bbz7Q2DIQqWd4Fw 8gf4WJd9vlPMJgs7bfASM3i0Uch9JTmAzBlrdB46uV66sZbMiUSMV4brtvEI1Szb_qbIMiG1kDjx z2jndAVMZWnzUklfhsSWzqGqXYQS.teXxZ8PD946wPxSEzjeO6WRNBvAQXVfA7oE6GLBQKIFvM8k ASyW9V7gYbfpmOvnxOD7gTf4u.gQLTi4gTvgrdGX633baPBXKOGnGpHqSLLcke4PUBLrRwpOFKRF eLQfpB42BGOiz3eEiVFOwo5mv4Qkq7e2OSNP_ij1_mcqCqYmDpZXpbqDT0cxLorUsAVJ8xKbBSPO I9EYN07bM1WHMILYe3NtgSPfxjJ.jRE_o.A0IjPth8k6uE5r3MfHqzMODVGte7c98bBUR1HFIaYu etAp8YFaBQVmKgLnNT.laRIbtP9JsZYEI3V3F_1qPoCH.bjRSAZ.kOD_Equy.FQQNDXRBQ_3kUsq 0p8quTIJpLvS0o6C7vKa._fTWdG0P2BnfkgASLfIeLWmQGBGBso7NAjOvQde.YjziBRIZaXtREhF THZU7KwUdsgS7i6_g.K9oGTtDlGp4fOa1RCZLEno7iIestBC6rWhtC9e0Vpxo6yxBx4pR4vewY92 meGPCkkbGyu3fKiz8sPDpttni0KP1KMeJ1dtEnDQV0WArrEDY.WTY1xF0ECWcaxCkX65VlQa3ohv ZUf2AJSnI.KlZDppyDa1plB4i9MD6RCYr2Sw_AfONgaYvt_Ko4obaVpGcVpshJDwuReops7R7Xul X07fvCbUHGv_XpASGIj8XhY3wkbLl0gYnUDkU4v0SED2QSDHyJNnp6Za9wRyRztD5yISFyGl7rzv gYPgGADrczHn4nLsapY9SW0z6x69LPMcjKXwqLXBbjeckX5YWFAqoMvDlhOX.BcrY.1ZaxhrFlbf Ne.YDD57piiBG9iGbFnMQu4_jc4.x9BNfIDx0w3C5WTCfBaQ8VzZ1coByasqDqUAjqcRYKsINE5O 849xSpTjYe20YYr_b0.xfI.hhmqoVVNJns5IdVqHiZ.i64GazlHRK_Vp5PNuP5q.Oe6cUjTRgvAq AYAxnyLI7r3Q_.DiVJE_bPV9.T_xlZ2qa47LUFiinB6AiOJ67EPHJtRBv_9dGGNLG7HtQ4_zrnUC RMQQBgoE2R1RuljZ0AUnjhcxpF1GVWrE2NXjiTAd7spQ.y705rINk8o7SknPWLlH9U1VwnaP4OU2 l.oo4Gi_YULR81GSgVPznjVW6oYsZY3SwN85awJmjp3gqPPDnqxNa88YtrOj62QecNij.dGvNhqi KRqJ61aVuRdHb2Mj9NfYXQ8WfJjA3fy02lUS9UUiKfmxodWmGo0UQlE__5IrTf8ayKE6.gnTfz63 OoOWrmbeAuLJ2GLugYbjKyAdFMXLEFwQB.5ebQWkxPXr2Pl0d2Fuw4cNU1Mf.nnCz05eUJ2cE8K_ nQJ78_NdBqWzaTIa9uoAGqdVchSfZtzFsKk585053LstVsFyI1JiXfaZ69SlWyx9BUao1W13cO7R DQ20tJF0i7NC5.owcWoTzHqR6Llbl7P6iSPmozgnHrgI8BhXdDcLv1ns5cVXzQJFCIibSq0K2wwz zro8Ita2wXT34GN0g0hKaxg87vbw3wAtBOspXqw428tRSUgMSeHwxUjXRZGPi8fj9QJrz4ekRYk4 0JurtnYE6bRKvebeLYjOMcYy0czSVTLi5z9BJFxy7mg18hxpBvTAx2iD.qXdt0uFEBlfrVcRbmOS 2bsORrubisq5R2UY3AhOAliu57kJWckgIA1uAe2XDUjKXUGKdPhhx_gQ2RXrk6zx8clVaEA2yE._ fLbHu_H7tFJ06IKEBqZ34XypSjdKpTIHjK8Z4OOO30w9u_DzQSH481AiAq1ttez5IaOexXn5aboy DUb5GXFqsDOKbLWt1uXdG72jwa46hvvgErBlmRPyOIdp0UKyVzWyvPxYPy39Nk3IXlgTU2x_36V5 dcBGEuZjqueRz.LAt1QkyzeFu4o326vpIHUKAwe6QcI6rRAILkHBXtDvrT1hpg22J0CUVTu_N_Kl IT_CapWphahTVmncADFxWXw1iY81unwJ4uYD2RBzRCtYmygMbILODdINS__Mw0_6fR7Xtn54fHqU UGEbz8wufAaygZI3JY4cIm4vmkPOS92cnwftO_AbIbWbr5E3xsFddD_M2T9WB3iWeZ3HWTNh15ry spuxJEBLXHDSitnLKp_x3VKKWuNUmjaGkz.9j2A6roJFe3ry8dAQnPVxjmuH8Jde8w1Vayq9YLAl IXpScOSodiQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Mar 2021 21:57:17 +0000 Received: by kubenode569.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8e9e470f24ea4b2fc5ba370a69328cfa; Sat, 13 Mar 2021 21:57:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: problems building a release From: Mark Millard In-Reply-To: Date: Sat, 13 Mar 2021 13:57:12 -0800 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <45D8156C-8DEF-48DD-A091-09D54E84F6B4@yahoo.com> References: <8CE18E0A-8931-4C41-83B4-D30EEC049E6D@yahoo.com> To: Don Lewis X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4Dyc3g10XWz3k7h X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.66.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 21:57:20 -0000 On 2021-Mar-13, at 13:41, Mark Millard wrote: >> On 2021-Mar-13, at 12:43, Don Lewis wrote: >>=20 >> On 13 Mar, Mark Millard wrote: >>> . . . >>=20 >> Thanks. All of this stuff is pretty confusing. >>=20 >> If I specify MAKE_CONF in release.conf, it does affect the target = build. >> In particular MODULES_OVERRIDE does the right thing. >>=20 >> It seems like there should be a way to specify a make.conf and = src.conf >> so that they get included in the release so that if the release is >> installed and then world and kernel are built it reproduces itself. >>=20 >> I did manage to unmute release.sh and make so that the build is = verbose, >> but the error I get when I specify TARGET and TARGET_ARCH in the >> make.conf is still a mystery. There doesn't seem to be a line = buffering >> problem hiding things, this was captured from the terminal window = with >> no redirections involved. >>=20 >> =3D=3D=3D> etc (installconfig) >> mkdir -p bootonly/usr/freebsd-dist >> cp MANIFEST bootonly/usr/freebsd-dist >> ln -fs /tmp/bsdinstall_etc/resolv.conf bootonly/etc/resolv.conf >> echo sendmail_enable=3D\"NONE\" > bootonly/etc/rc.conf >> echo hostid_enable=3D\"NO\" >> bootonly/etc/rc.conf >> echo debug.witness.trace=3D0 >> bootonly/etc/sysctl.conf >> echo vfs.mountroot.timeout=3D\"10\" >> bootonly/boot/loader.conf >> echo kernels_autodetect=3D\"NO\" >> bootonly/boot/loader.conf >> cp /usr/src/release/rc.local bootonly/etc >> sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_BO = bootonly.iso bootonly=20 >> sh /usr/src/release/i386/make-memstick.sh disc1 memstick.img >> Calculated size of `memstick.img.part': 624754688 bytes, 13074 inodes >> Extent size set to 32768 >> memstick.img.part: 595.8MB (1220224 sectors) block size 32768, = fragment size 4096 >> using 1 cylinder groups of 595.81MB, 19066 blks, 13952 inodes. >> super-block backups (for fsck -b #) at: >> 192, >> Populating `memstick.img.part' >> Image `memstick.img.part' complete >> sh /usr/src/release/i386/make-memstick.sh bootonly mini-memstick.img >> Calculated size of `mini-memstick.img.part': 237436928 bytes, 13069 = inodes >> Extent size set to 32768 >> mini-memstick.img.part: 226.4MB (463744 sectors) block size 32768, = fragment size 4096 >> using 1 cylinder groups of 226.44MB, 7246 blks, 14592 inodes. >> super-block backups (for fsck -b #) at: >> 192, >> Populating `mini-memstick.img.part' >> Image `mini-memstick.img.part' complete >=20 > The below notes are about what starts here: >=20 >> make -C /usr/src/release release-done >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> touch release >> true >=20 > That is interesting as this turns out to be a fairly > simple context by the time that "make . . . release-done" > is echoed: >=20 > QUOTE > release: real-release vm-release cloudware-release > ${MAKE} -C ${.CURDIR} ${.MAKEFLAGS} release-done > true >=20 > release-done: > touch release > END QUOTE >=20 > but by then "real-release vm-release cloudware-release" > completed and we see the touch and true after the messages. >=20 > So it looks like the 6 "not found" messages are from > make's internal activities. >=20 > It would be interesting to get a truss -f log (or some such) > of that "${MAKE} . . . release-done" out into to a file. > There should not be much other activity in the file generated. > That might expose the activity producing the "not found" > messages. >=20 > Also interesting might be adding a "file /libexec/ld-elf.so.1" > command line to release: or adding other such context reporting > there, such as "uname -apKU" . >=20 >> + eval chroot /scratch make -C /usr/src/release 'TARGET=3Di386' = 'TARGET_ARCH=3Di386' 'KERNCONF=3D"GW"' = '__MAKE_CONF=3D/home/dl/gw-release/make.conf' = 'SRCCONF=3D/home/dl/gw-release/src.conf' 'NOPORTS=3Dyes' 'WITH_DVD=3D' = 'WITH_VMIMAGES=3D' 'WITH_CLOUDWARE=3D' 'XZ_THREADS=3D0' install = 'DESTDIR=3D/R' 'WITH_COMPRESSED_IMAGES=3D' 'WITH_COMPRESSED_VMIMAGES=3D' >> + chroot /scratch make -C /usr/src/release 'TARGET=3Di386' = 'TARGET_ARCH=3Di386' 'KERNCONF=3DGW' = '__MAKE_CONF=3D/home/dl/gw-release/make.conf' = 'SRCCONF=3D/home/dl/gw-release/src.conf' 'NOPORTS=3Dyes' 'WITH_DVD=3D' = 'WITH_VMIMAGES=3D' 'WITH_CLOUDWARE=3D' 'XZ_THREADS=3D0' install = 'DESTDIR=3D/R' 'WITH_COMPRESSED_IMAGES=3D' 'WITH_COMPRESSED_VMIMAGES=3D' >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >> ELF interpreter /libexec/ld-elf.so.1 not found, error 8 >> Abort trap >=20 > QUOTE > install: release-install vm-install > END QUOTE >=20 > where the release-install: commands are listed > later below (so after the "not found" messages). >=20 > Again: seems to be make-internal activities that > generate the 6 messages. >=20 >> mkdir -p /R >> cp -a ftp /R/ >> cp -p disc1.iso /R/FreeBSD-14.0-CURRENT-i386-disc1.iso >> cp -p bootonly.iso /R/FreeBSD-14.0-CURRENT-i386-bootonly.iso >> cp -p memstick.img /R/FreeBSD-14.0-CURRENT-i386-memstick.img >> cp -p mini-memstick.img = /R/FreeBSD-14.0-CURRENT-i386-mini-memstick.img >> cd /R && sha512 FreeBSD-14.0-CURRENT-i386* > /R/CHECKSUM.SHA512 >> cd /R && sha256 FreeBSD-14.0-CURRENT-i386* > /R/CHECKSUM.SHA256 >> + return 0 >> + return 0 >> + umount /scratch/dev >=20 >=20 If I gather correctly, one can force the: ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap messages to show up on a previously working amd64 system that has lib32 support by removing /libexec/ld-elf32.so.1 and then trying to run i386 code. (The message generation does not track the indirection to /libexec/ld-elf32.so.1 and so references a misleading path.) This might suggest that /libexec/ld-elf32.so.1 is missing or corrupt in the context those 2 makes are executing in. (Hopefully no WITHOUT_LIB32=3D usage is explicitly involved.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)