From owner-freebsd-current@freebsd.org Sun Nov 15 02:36:35 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79D6CA28D06; Sun, 15 Nov 2015 02:36:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6B279132A; Sun, 15 Nov 2015 02:36:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id BF3851B67; Sun, 15 Nov 2015 02:36:34 +0000 (UTC) Date: Sun, 15 Nov 2015 02:36:27 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: rodrigc@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1106037100.33.1447554993789.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1403448137.29.1447543009744.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1403448137.29.1447543009744.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1664 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 02:36:35 -0000 FreeBSD_HEAD_i386 - Build #1664 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1664/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1664/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1664/console Change summaries: 290838 by rodrigc: Fix bootstrapping of libopenbsd on build hosts where KERN_PROC_NFDS it not defined. From owner-freebsd-current@freebsd.org Sun Nov 15 03:05:13 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D403A2E055; Sun, 15 Nov 2015 03:05:13 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFDE72878; Sun, 15 Nov 2015 03:05:09 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykfs79 with SMTP id s79so196823566ykf.1; Sat, 14 Nov 2015 19:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=yMgLSfSRDWjnm9iIGgQeYumTgO8YLQ+H+RUfAcRx3L8=; b=txYOb884LOklYKh7qkBq+hE2aV+W7WXUCl+o+TVQd47nMsMjmF78EB20CE6d8oMBFx TkDt36amlybeP36/336TTNEItSBO/UTFeHmYVh4R+YrfVrXTUYBQInhygUARuu1w6pJB 4m6rUHIi0tWJFTd7HgzvjpMTGpPklkEK8qbvtCOBiogiHGHjewHYPczrFDytPkxpyMMh JaxPU+r6vJ6hj/uNZkdT5rCI9Er3jJjH3bYR7NNogj3VrSaSqQBxu5DSqLD0Yod5KKrY KpUu/9Q9fmGzxx/ymfS2Q5unSWnFWg6fIv8/0jH/VKnrzh3wzn5sultCRUiIuQQkix5u btSA== MIME-Version: 1.0 X-Received: by 10.129.0.8 with SMTP id 8mr29315803ywa.81.1447556708827; Sat, 14 Nov 2015 19:05:08 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Sat, 14 Nov 2015 19:05:08 -0800 (PST) Date: Sat, 14 Nov 2015 19:05:08 -0800 X-Google-Sender-Auth: KusWGoTF4LuwERpnfgrpG7QrIs4 Message-ID: Subject: Need help fixing failing locale tests From: Craig Rodrigues To: Baptiste Daroussin , John Marino Cc: freebsd-current Current , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 03:05:13 -0000 Hi, After the recent locale commits, some of the tests are failing: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1675/testReport/ I can reproduce two failures quite easily by doing with a newly built world: /bin/sh /usr/tests/bin/sh/builtins/case7.0 /bin/sh /usr/tests/bin/sh/builtins/locale1.0 Can someone look into this and help fix this? I don't know much about locales, so don't know what to do. -- Craig From owner-freebsd-current@freebsd.org Sun Nov 15 03:16:32 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33794A2E3B1; Sun, 15 Nov 2015 03:16:32 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 046EB2FBF; Sun, 15 Nov 2015 03:16:32 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pabfh17 with SMTP id fh17so139946044pab.0; Sat, 14 Nov 2015 19:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vQDNmKqeGtsu2KC9N8Teeh+Msb1vhMWDZGlu3pzIeow=; b=ao4k+U/3qFo4vqN61typEAMRjcDOxyFhHUH88jAQaH9mUsNAZO3L97y18htc4DK0jk Yvt4i5xDlsHJQ97uSBbhZJQhlWJZ5ej4OPSfD1NusANUvlF8T6sq2zYQoJoN1VDePHQ/ 2D3LrjeqBX/DWmQSi7em+IlrDoWF75ZwaJxlnRMUjR/ngUw8eUUmbzVY9mGZAWa/ryxZ Mm45HVlEHqxE8pZ351Gepmq8ZKMiMvM2k3LGF3y6dn3iGzj6COxu2JJCbWXh4DhAYX2I etC49I6uMD/fKJByk9HLka+Xn+tneV1WpRSBUVh3phNtp543VvKUAzOgZrOXXYdHJzt6 jJpg== X-Received: by 10.66.219.39 with SMTP id pl7mr44183417pac.88.1447557391572; Sat, 14 Nov 2015 19:16:31 -0800 (PST) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id cs9sm5152108pac.27.2015.11.14.19.16.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Nov 2015 19:16:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Need help fixing failing locale tests From: NGie Cooper In-Reply-To: Date: Sat, 14 Nov 2015 19:16:29 -0800 Cc: Baptiste Daroussin , John Marino , freebsd-current Current , "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3B98F898-206C-443D-BB5C-336F566A6BA5@gmail.com> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 03:16:32 -0000 > On Nov 14, 2015, at 19:05, Craig Rodrigues = wrote: >=20 > Hi, >=20 > After the recent locale commits, some of the tests are failing: >=20 > https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1675/testReport/ >=20 > I can reproduce two failures quite easily by doing with a newly built = world: >=20 > /bin/sh /usr/tests/bin/sh/builtins/case7.0 > /bin/sh /usr/tests/bin/sh/builtins/locale1.0 >=20 > Can someone look into this and help fix this? bapt=E2=80=99s locale work looks like it broke the following locales = with /bin/sh: de_DE.ISO8859-1 [LC_CTYPE,LC_COLLATE] nl_NL.ISO8859-1 > I don't know much about locales, so don't know what to do. I=E2=80=99ll look at the other failing tests. -NGie= From owner-freebsd-current@freebsd.org Sun Nov 15 03:18:31 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A3E1A2E462; Sun, 15 Nov 2015 03:18:31 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48FE7115B; Sun, 15 Nov 2015 03:18:31 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykfs79 with SMTP id s79so196970839ykf.1; Sat, 14 Nov 2015 19:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TAJ0I/Zl/4wjXyYS5SYfaSFGg/NnfFIlXMVl0D9vhgw=; b=ix4fYSeukeMUq3pzBcKw7gJpfhWotBEe+d5OEV0LVaaf19d+hp1Ebxd0YYfntPh03y ozS4w6vvN2FJajMTDhRO6S5eFlWRq6LHeOg/z4e4Q52CqUwDBHWzSbbmqBGqr4EdHx8j OZj0pHwnRI3RX59biKk5l/kYcLabRbnoS4+xQY4Iox9OSltY/4HcqRh/aX0gHYFqH68v FuZ1eHx4p+7t90/B+gXYgTaydsHbOQ8CQfcBhCd0Ia6tIMTAUbXyUf/0tb6xmg5x91tZ xyS+dCDan8Ot0gzyHtElGb7Eo3ASi9EvMYf7BkbkSt3DRyWrYzLDxccVPpFJropwb+bs iV5w== MIME-Version: 1.0 X-Received: by 10.13.250.69 with SMTP id k66mr28978324ywf.107.1447557510558; Sat, 14 Nov 2015 19:18:30 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Sat, 14 Nov 2015 19:18:30 -0800 (PST) In-Reply-To: References: Date: Sat, 14 Nov 2015 19:18:30 -0800 X-Google-Sender-Auth: XKc7k8CydAKvNWnDE8yUDOF1bHg Message-ID: Subject: Re: Need help fixing failing locale tests From: Craig Rodrigues To: Baptiste Daroussin , John Marino Cc: freebsd-current Current , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 03:18:31 -0000 On Sat, Nov 14, 2015 at 7:05 PM, Craig Rodrigues wrote: > Hi, > > After the recent locale commits, some of the tests are failing: > > https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1675/testReport/ > > I can reproduce two failures quite easily by doing with a newly built > world: > > /bin/sh /usr/tests/bin/sh/builtins/case7.0 > /bin/sh /usr/tests/bin/sh/builtins/locale1.0 > > Can someone look into this and help fix this? > > I don't know much about locales, so don't know what to do. > I ran the two tests using bash, and got different error messages: /usr/local/bin/bash /usr/tests/bin/sh/builtins/case7.0 /usr/tests/bin/sh/builtins/case7.0: line 7: warning: setlocale: LC_CTYPE: cannot change locale (de_DE.ISO8859-1): Invalid argument /usr/tests/bin/sh/builtins/case7.0: line 9: warning: setlocale: LC_COLLATE: cannot change locale (de_DE.ISO8859-1): Invalid argument wrong at 18 wrong at 23 /usr/local/bin/bash /usr/tests/bin/sh/builtins/locale1.0 /usr/tests/bin/sh/builtins/locale1.0: line 45: warning: setlocale: LC_CTYPE: cannot change locale (nl_NL.ISO8859-1): Invalid argument Failed: $ok -eq 1 at 56 /usr/tests/bin/sh/builtins/locale1.0: line 64: warning: setlocale: LC_ALL: cannot change locale (nl_NL.ISO8859-1): No such file or directory Failed: $ok -eq 1 at 68 Failed: $ok -eq 1 at 74 /usr/tests/bin/sh/builtins/locale1.0: regel 82: waarschuwing: setlocale(): LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file or directory Failed: $ok -eq 1 at 86 Failed: $ok -eq 1 at 99 /usr/tests/bin/sh/builtins/locale1.0: regel 107: waarschuwing: setlocale(): LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file or directory Failed: $ok -eq 1 at 111 /usr/tests/bin/sh/builtins/locale1.0: regel 114: waarschuwing: setlocale(): LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file or directory Failed: $ok -eq 1 at 118 /usr/tests/bin/sh/builtins/locale1.0: regel 122: waarschuwing: setlocale(): LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file or directory /usr/tests/bin/sh/builtins/locale1.0: regel 128: waarschuwing: setlocale(): LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file or directory Failed: $ok -eq 1 at 132 On my system, I did: ls -l /usr/share/locale/de_DE.ISO8859-1/* -r--r--r-- 1 root wheel 4642 Nov 6 12:53 /usr/share/locale/de_DE.ISO8859-1/LC_COLLATE lrwxr-xr-x 1 root wheel 27 Nov 6 12:53 /usr/share/locale/de_DE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE -r--r--r-- 1 root wheel 18 Nov 6 12:53 /usr/share/locale/de_DE.ISO8859-1/LC_MESSAGES -r--r--r-- 1 root wheel 35 Nov 6 12:53 /usr/share/locale/de_DE.ISO8859-1/LC_MONETARY -r--r--r-- 1 root wheel 6 Nov 6 12:53 /usr/share/locale/de_DE.ISO8859-1/LC_NUMERIC -r--r--r-- 1 root wheel 367 Nov 6 12:53 /usr/share/locale/de_DE.ISO8859-1/LC_TIME ls -l /usr/share/locale/nl_NL.ISO8859-1/* lrwxr-xr-x 1 root wheel 29 Nov 6 12:53 /usr/share/locale/nl_NL.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE lrwxr-xr-x 1 root wheel 27 Nov 6 12:53 /usr/share/locale/nl_NL.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE -r--r--r-- 1 root wheel 18 Nov 6 12:53 /usr/share/locale/nl_NL.ISO8859-1/LC_MESSAGES -r--r--r-- 1 root wheel 35 Nov 6 12:53 /usr/share/locale/nl_NL.ISO8859-1/LC_MONETARY -r--r--r-- 1 root wheel 6 Nov 6 12:53 /usr/share/locale/nl_NL.ISO8859-1/LC_NUMERIC -r--r--r-- 1 root wheel 376 Nov 6 12:53 /usr/share/locale/nl_NL.ISO8859-1/LC_TIME I saw that la_LN.ISO8859-1 does not exist, so the LC_CTYPE symlink is pointing to nothing. -- Craig From owner-freebsd-current@freebsd.org Sun Nov 15 03:28:27 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7C1DA2E74A; Sun, 15 Nov 2015 03:28:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D84A1924; Sun, 15 Nov 2015 03:28:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacdm15 with SMTP id dm15so138820507pac.3; Sat, 14 Nov 2015 19:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8UqeDDblaqNey5H3L6WPtcotAJXVLo5UzTQQ4xBHo2A=; b=JHUjuFyjd24wiMfRi3AaJ3wHSCbR5gg1Bs3iZs9EXxsmQWerHMtiVwunFwz4p6KxXe LOFXeLn1cuzoTkX8er+bwiIn+ztzjEEPqwxUrMCgiaT/DwpoFWAs86XWSnKrZAMpd8Y4 eArKQ0wKd8SZSrS8iG4UHMEFbMNeICRvYMUELpcVSfiCZLiTHHl7OEKNqxiWfewu1oOV N/BlpaCSRioKr0oR9l5CD2Db1CkogehVsF4xYhPYVdns4HwyrGxNZikPjam/Vnei29M5 l7eIkfAedhYQxtseMWZOSHYL3TLOFqCqppQiMoZiJ3LCoNkWRE7ajvQUT2JnguvOF7Ju m52A== X-Received: by 10.66.229.2 with SMTP id sm2mr44079496pac.28.1447558107167; Sat, 14 Nov 2015 19:28:27 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:1591:4178:5777:4e52? ([2601:601:800:126d:1591:4178:5777:4e52]) by smtp.gmail.com with ESMTPSA id n6sm14333355pap.24.2015.11.14.19.28.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Nov 2015 19:28:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Need help fixing failing locale tests From: NGie Cooper In-Reply-To: Date: Sat, 14 Nov 2015 19:28:23 -0800 Cc: Baptiste Daroussin , John Marino , freebsd-current Current , "freebsd-testing@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 03:28:27 -0000 > On Nov 14, 2015, at 19:18, Craig Rodrigues wrote: > > On Sat, Nov 14, 2015 at 7:05 PM, Craig Rodrigues > wrote: > >> Hi, >> >> After the recent locale commits, some of the tests are failing: >> >> https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1675/testReport/ >> >> I can reproduce two failures quite easily by doing with a newly built >> world: >> >> /bin/sh /usr/tests/bin/sh/builtins/case7.0 >> /bin/sh /usr/tests/bin/sh/builtins/locale1.0 >> >> Can someone look into this and help fix this? >> >> I don't know much about locales, so don't know what to do. >> > > > I ran the two tests using bash, and got different error messages: > > /usr/local/bin/bash /usr/tests/bin/sh/builtins/case7.0 > /usr/tests/bin/sh/builtins/case7.0: line 7: warning: setlocale: LC_CTYPE: > cannot change locale (de_DE.ISO8859-1): Invalid argument > /usr/tests/bin/sh/builtins/case7.0: line 9: warning: setlocale: LC_COLLATE: > cannot change locale (de_DE.ISO8859-1): Invalid argument > wrong at 18 > wrong at 23 > > /usr/local/bin/bash /usr/tests/bin/sh/builtins/locale1.0 > /usr/tests/bin/sh/builtins/locale1.0: line 45: warning: setlocale: > LC_CTYPE: cannot change locale (nl_NL.ISO8859-1): Invalid argument > Failed: $ok -eq 1 at 56 > /usr/tests/bin/sh/builtins/locale1.0: line 64: warning: setlocale: LC_ALL: > cannot change locale (nl_NL.ISO8859-1): No such file or directory > Failed: $ok -eq 1 at 68 > Failed: $ok -eq 1 at 74 > /usr/tests/bin/sh/builtins/locale1.0: regel 82: waarschuwing: setlocale(): > LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file > or directory > Failed: $ok -eq 1 at 86 > Failed: $ok -eq 1 at 99 > /usr/tests/bin/sh/builtins/locale1.0: regel 107: waarschuwing: setlocale(): > LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file > or directory > Failed: $ok -eq 1 at 111 > /usr/tests/bin/sh/builtins/locale1.0: regel 114: waarschuwing: setlocale(): > LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file > or directory > Failed: $ok -eq 1 at 118 > /usr/tests/bin/sh/builtins/locale1.0: regel 122: waarschuwing: setlocale(): > LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file > or directory > /usr/tests/bin/sh/builtins/locale1.0: regel 128: waarschuwing: setlocale(): > LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file > or directory > Failed: $ok -eq 1 at 132 > > > On my system, I did: > ls -l /usr/share/locale/de_DE.ISO8859-1/* > -r--r--r-- 1 root wheel 4642 Nov 6 12:53 > /usr/share/locale/de_DE.ISO8859-1/LC_COLLATE > lrwxr-xr-x 1 root wheel 27 Nov 6 12:53 > /usr/share/locale/de_DE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE > -r--r--r-- 1 root wheel 18 Nov 6 12:53 > /usr/share/locale/de_DE.ISO8859-1/LC_MESSAGES > -r--r--r-- 1 root wheel 35 Nov 6 12:53 > /usr/share/locale/de_DE.ISO8859-1/LC_MONETARY > -r--r--r-- 1 root wheel 6 Nov 6 12:53 > /usr/share/locale/de_DE.ISO8859-1/LC_NUMERIC > -r--r--r-- 1 root wheel 367 Nov 6 12:53 > /usr/share/locale/de_DE.ISO8859-1/LC_TIME > > ls -l /usr/share/locale/nl_NL.ISO8859-1/* > lrwxr-xr-x 1 root wheel 29 Nov 6 12:53 > /usr/share/locale/nl_NL.ISO8859-1/LC_COLLATE -> > ../la_LN.ISO8859-1/LC_COLLATE > lrwxr-xr-x 1 root wheel 27 Nov 6 12:53 > /usr/share/locale/nl_NL.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE > -r--r--r-- 1 root wheel 18 Nov 6 12:53 > /usr/share/locale/nl_NL.ISO8859-1/LC_MESSAGES > -r--r--r-- 1 root wheel 35 Nov 6 12:53 > /usr/share/locale/nl_NL.ISO8859-1/LC_MONETARY > -r--r--r-- 1 root wheel 6 Nov 6 12:53 > /usr/share/locale/nl_NL.ISO8859-1/LC_NUMERIC > -r--r--r-- 1 root wheel 376 Nov 6 12:53 > /usr/share/locale/nl_NL.ISO8859-1/LC_TIME > > I saw that la_LN.ISO8859-1 does not exist, so the LC_CTYPE symlink is > pointing to nothing. Why were these locales removed? 58 OLD_FILES+=usr/share/locale/la_LN.ISO8859-1/LC_COLLATE 59 OLD_FILES+=usr/share/locale/la_LN.ISO8859-1/LC_CTYPE 60 OLD_FILES+=usr/share/locale/la_LN.ISO8859-1/LC_TIME 61 OLD_DIRS+=usr/share/locale/la_LN.ISO8859-1 62 OLD_FILES+=usr/share/locale/la_LN.ISO8859-13/LC_COLLATE 63 OLD_FILES+=usr/share/locale/la_LN.ISO8859-13/LC_CTYPE 64 OLD_DIRS+=usr/share/locale/la_LN.ISO8859-13 From owner-freebsd-current@freebsd.org Sun Nov 15 03:46:24 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E3BAA2ED2C; Sun, 15 Nov 2015 03:46:24 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 159D21205; Sun, 15 Nov 2015 03:46:24 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by igbxm8 with SMTP id xm8so37369924igb.1; Sat, 14 Nov 2015 19:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mM/NdNvK3jwWpMNh7goeaAcQTYZS2qXrgmZOLxb82wo=; b=RmJ6YhRn5azL5Do1umVlrqIBFG7L3KwOXrmEJVMf9vUUMr3rPaa+RQ3owlOQudq02P neHFQjbslWpHTE/cfVAbWX3UE8CPZEGhIRMG0XDZPZpj/awRsPgUZkQAW3VJiK+B51Zi wvXUNwIpggjlGm6djz4Tzdc1yK/SoBTsX3wFC8yKvjwq7tV8wbtJUtRGCiP1aICkoPl9 RFv2W3jGufK/Npr/VT9HHXEkVjYseafXtreTisBU77627XWhCAEpM1f9HJ8gNH5YRvow z3bDEMLrdgX5hjXLGS9TB9pMp8p+kAd3rpzAZgImU7XLHaoeghjouKpW0R8TvC7Dhv3/ u8tA== X-Received: by 10.50.142.65 with SMTP id ru1mr10541222igb.88.1447559183482; Sat, 14 Nov 2015 19:46:23 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:1591:4178:5777:4e52? ([2601:601:800:126d:1591:4178:5777:4e52]) by smtp.gmail.com with ESMTPSA id x13sm125402igg.17.2015.11.14.19.46.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Nov 2015 19:46:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Need help fixing failing locale tests From: NGie Cooper In-Reply-To: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> Date: Sat, 14 Nov 2015 19:46:20 -0800 Cc: Baptiste Daroussin , John Marino , freebsd-current Current , "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 03:46:24 -0000 > On Nov 14, 2015, at 19:28, NGie Cooper wrote: =E2=80=A6 > Why were these locales removed? >=20 > 58 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_COLLATE > 59 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_CTYPE > 60 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_TIME > 61 OLD_DIRS+=3Dusr/share/locale/la_LN.ISO8859-1 > 62 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-13/LC_COLLATE > 63 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-13/LC_CTYPE > 64 OLD_DIRS+=3Dusr/share/locale/la_LN.ISO8859-13 la_LN.ISO8859-1 is the old Latin locale, which is no longer installed. = Copying over locale files from a stable/10 host works, but I=E2=80=99m = confused as to why a bunch of locales weren=E2=80=99t ported over in = their non-UTF-8 forms. Thanks,= From owner-freebsd-current@freebsd.org Sun Nov 15 04:17:57 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80189A2F4A7; Sun, 15 Nov 2015 04:17:57 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4161C1040; Sun, 15 Nov 2015 04:17:57 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by igvi2 with SMTP id i2so58275195igv.0; Sat, 14 Nov 2015 20:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZetXQbJhZx8f92sRhaMxTVNcvj0wFIEQrJlgJWwWscs=; b=qAT25VhVp3vYd+YThl8PWmj12E28SOQkt43KT2/7Mm/QvvHrIz+nyivQA+hczvzahe 7/F7CcfekW+8eu7kwdrr1z3sJEnsgxlzLq6u6y77cjFDSFek6NNrLmA9XEq+694A8w+B LSYExpkZQpVr0IEhZ2trUfttixP/+ID6uMN9UHUIcIk29e0IAp45a966aH7K8Gk7W4pO fv0NwNxyz7KHd9pHsrGl3cqi7Xpg8Ar3lY6fSBV9yXgLNpmcYp8oW+ZLzm6XhwBbbVfs pxxMaoN61k0u1kDxG8bAdj/9tWXQLpXzg3HQBijfyTM7ZMjeGS9sezoqQQzoWY0VPjlG 64Dg== X-Received: by 10.50.122.68 with SMTP id lq4mr10974102igb.87.1447561076603; Sat, 14 Nov 2015 20:17:56 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:fd52:9a90:172f:f1ee? ([2601:601:800:126d:fd52:9a90:172f:f1ee]) by smtp.gmail.com with ESMTPSA id qf8sm4154392igb.19.2015.11.14.20.17.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Nov 2015 20:17:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Need help fixing failing locale tests From: NGie Cooper In-Reply-To: <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> Date: Sat, 14 Nov 2015 20:17:52 -0800 Cc: Baptiste Daroussin , John Marino , freebsd-current Current , "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 04:17:57 -0000 > On Nov 14, 2015, at 19:46, NGie Cooper wrote: >=20 >=20 >> On Nov 14, 2015, at 19:28, NGie Cooper wrote: >=20 > =E2=80=A6 >=20 >> Why were these locales removed? >>=20 >> 58 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_COLLATE >> 59 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_CTYPE >> 60 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_TIME >> 61 OLD_DIRS+=3Dusr/share/locale/la_LN.ISO8859-1 >> 62 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-13/LC_COLLATE >> 63 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-13/LC_CTYPE >> 64 OLD_DIRS+=3Dusr/share/locale/la_LN.ISO8859-13 >=20 > la_LN.ISO8859-1 is the old Latin locale, which is no longer installed. = Copying over locale files from a stable/10 host works, but I=E2=80=99m = confused as to why a bunch of locales weren=E2=80=99t ported over in = their non-UTF-8 forms. > Thanks, /usr/share/locale/en_US.ISO8859-15/LC_CTYPE is also broken; I opened up = the file and it was empty. Thanks, -NGie= From owner-freebsd-current@freebsd.org Sun Nov 15 07:24:40 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9C80A2F6D4; Sun, 15 Nov 2015 07:24:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF4B91CCB; Sun, 15 Nov 2015 07:24:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by igbxm8 with SMTP id xm8so38743774igb.1; Sat, 14 Nov 2015 23:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ktKLy6yCjYYHISuMCxnCEysrSDGYx2BUZaO6kKywFtY=; b=X0wxWYW88DbrGNCi0ac8E+oGqjwpJKE/4yvH+p/R79obW+RrYCQDMs9yp91y85uy7U If0Bm4a6bgaW6ItR0xaPUB69AIiGOMdWQYMkdRgFyh0EX+AhRMv2/3qHp9Yi44oIR1W5 SIa58EwCcabCVnLQ7DKR/tbXxQRVXyOm+LvcszdA2ao2EKtue31BhBRaes8wpDnrGWDT nEgKL0X5bNNebFS3bLGs3R867RPKKnWQDba/LPGMPcUVpfKtv5P+Ex2ktbUbBUS9TtWh 90NJYCaXocpX67wI9MICiojcampcR8gut+yBCAFAexi0K51GT+oEhqQAqvFDxPd8jDeP m5Zw== X-Received: by 10.50.43.197 with SMTP id y5mr10545064igl.45.1447572280099; Sat, 14 Nov 2015 23:24:40 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:fd52:9a90:172f:f1ee? ([2601:601:800:126d:fd52:9a90:172f:f1ee]) by smtp.gmail.com with ESMTPSA id ie20sm4351327igb.10.2015.11.14.23.24.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Nov 2015 23:24:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Need help fixing failing locale tests From: NGie Cooper In-Reply-To: <56482FA9.2010803@marino.st> Date: Sat, 14 Nov 2015 23:24:36 -0800 Cc: Craig Rodrigues , Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <02FA2ED1-42BF-4BF2-879D-5463A119C000@gmail.com> References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> To: John Marino X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 07:24:41 -0000 > On Nov 14, 2015, at 23:09, John Marino wrote: >=20 > On 11/15/2015 4:46 AM, NGie Cooper wrote: >>=20 >>> On Nov 14, 2015, at 19:28, NGie Cooper = wrote: >>=20 >> =E2=80=A6 >>=20 >>> Why were these locales removed? >>>=20 >>> 58 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_COLLATE >>> 59 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_CTYPE >>> 60 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-1/LC_TIME >>> 61 OLD_DIRS+=3Dusr/share/locale/la_LN.ISO8859-1 >>> 62 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-13/LC_COLLATE >>> 63 OLD_FILES+=3Dusr/share/locale/la_LN.ISO8859-13/LC_CTYPE >>> 64 OLD_DIRS+=3Dusr/share/locale/la_LN.ISO8859-13 >>=20 >> la_LN.ISO8859-1 is the old Latin locale, which is no longer = installed. Copying over locale files from a stable/10 host works, but = I=E2=80=99m confused as to why a bunch of locales weren=E2=80=99t ported = over in their non-UTF-8 forms. >> Thanks, >>=20 >=20 > We (DragonFly) didn't just update locales. We took the opportunity to > do spring cleaning. We didn't want to be as drastic as OpenBSD which > removed all encodings except for C/POSIX and UTF, but we did remove > several locales intentionally. >=20 > In the case of ISO8859-1: > All ISO8859-* is basically obsolete. > In western Europe, if somebody wants ISO-8859, they want ISO8859-15, = not > ISO8859-1. They are similar, but the former is tailored for western > europe with "Euro" currency and 9 other symbols. It comes at the > expense of removing 10 characters from ISO8859-1. There's also a = common > problem that users view -15 documents with -1 accidently. So there = was > a conscience decision to have either ISO8859-1 or ISO8859-15 but not > both. For western Europe this means the ISO8859-1 versions were = dropped. >=20 > ISO8859-15: > In the case of USA and other non-European countries, they keep -1 and > dropped -15. >=20 > currency based: > In the case of countries where the currency symbols is not part of > ISO8859, it was dropped. E.g. Costa Rica uses the Colon which is only > in UTF-8, so there's no ISO8859-* encoding at all for CR. >=20 > Latin: > Who speaks Latin today? > This was mainly an alias for 7-bit ascii. We originally dropped that, > but later moved it to US-ASCII (which was just a symlink to Latin = before) >=20 > Bapt liked DF approach well enough that he adopted it. Even Edwin was > first in desiring to clean up locales. The major update was a perfect = time. >=20 > Bottom line: > The testsuite needs to be updated. > e.g. use de_DE.ISO8859-15 intead of de_DE.ISO8859-1 > For latin, replace with US-ASCII equivalent. I wish this had been clearly communicated here: = https://svnweb.freebsd.org/changeset/base/290494 =E2=80=A6 instead, = there are some POLA violations: 1. No RelNotes. 2. No summary of locales that have been removed. 3. No UPDATING entry for people to migrate from a locale to = another. 4. Deprecated locales (as you described it above) are still = present on my system after running `make delete-old` (assuming I have my = acronyms right, for example, ca_ES, it_CH, etc should be -1, not -15 = based on your claim above). I will update the testcases to use locales if possible, but more = work needs to be done finishing off this project and documenting for = end-users what has changed. Thanks, -NGie= From owner-freebsd-current@freebsd.org Sun Nov 15 11:23:55 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84433A2F56E; Sun, 15 Nov 2015 11:23:55 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3ECE713D8; Sun, 15 Nov 2015 11:23:55 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykdv3 with SMTP id v3so201538795ykd.0; Sun, 15 Nov 2015 03:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fnx2N1sWziloJcoeUjeVj8j2kMldYRPA0w+3mWS9MY0=; b=vagxkhcp5FZkIXBX2GRZxg8CzddzH/8CVIrXAwP6TmF5ENSgsmDGl38lnsIxsFcKAP J1YTvwv3EwaJSWOkB3ylxWf0vQknz8EHGPuYOvWtk9yRI8wCMisrz2psGsyDWrfuTDCN jFLAnER+vyqKrql1U3Q8WgV7guH1YqFOhBVuHeUDMtTOPDvt/43c2j5OBDMalzWz19Wo S8SqRwUQRYWM0sr5ODuKH+9ujY9pS3ZQmJoJBzEeFeJHImX/yevX9U+9HeFMAZoMfBnr 2ph2xQXDNu6FM+obYc5HFVN4kNknD9ikfGrgiEHYMbZ1JFRvOLjq4oXpxo5eXiNwqv8D iPQg== MIME-Version: 1.0 X-Received: by 10.13.224.3 with SMTP id j3mr30939487ywe.246.1447586634449; Sun, 15 Nov 2015 03:23:54 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Sun, 15 Nov 2015 03:23:54 -0800 (PST) In-Reply-To: <564838AD.2000402@marino.st> References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <02FA2ED1-42BF-4BF2-879D-5463A119C000@gmail.com> <564838AD.2000402@marino.st> Date: Sun, 15 Nov 2015 03:23:54 -0800 X-Google-Sender-Auth: ePQXO1lRQM23cXSBEB8FTOSsv-E Message-ID: Subject: Re: Need help fixing failing locale tests From: Craig Rodrigues To: marino@freebsd.org, Baptiste Daroussin Cc: freebsd-current Current , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 11:23:55 -0000 On Sat, Nov 14, 2015 at 11:47 PM, John Marino wrote: > > With 4.) they have been removed from FreeBSD when "Make upgrade" is run > after rebuilding. Does FreeBSD have a cleanup like that, and did you > run it? If not, then maybe that needs to be updated. > > I did not run "make upgrade". I did this: cd /usr/src svn up I then ran the 11 steps listed in /usr/src/Makefile: https://github.com/freebsd/freebsd/blob/master/Makefile#L73 It looks like after running those steps, my system is in an inconsistent state. I see that the following symlinks point to nonexistent files. /usr/share/locale/nl_BE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/nl_BE.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/en_CA.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE /usr/share/locale/en_CA.ISO8859-15/LC_COLLATE -> ../la_LN.ISO8859-15/LC_COLLATE /usr/share/locale/en_US.ISO8859-15/LC_COLLATE -> ../la_LN.ISO8859-15/LC_COLLATE /usr/share/locale/en_US.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE /usr/share/locale/ca_FR.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/nb_NO.ISO8859-1/LC_MONETARY -> ../no_NO.ISO8859-1/LC_MONETARY /usr/share/locale/nb_NO.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/nb_NO.ISO8859-1/LC_COLLATE -> ../no_NO.ISO8859-1/LC_COLLATE /usr/share/locale/nb_NO.ISO8859-1/LC_MESSAGES -> ../no_NO.ISO8859-1/LC_MESSAGES /usr/share/locale/nb_NO.ISO8859-1/LC_NUMERIC -> ../no_NO.ISO8859-1/LC_NUMERIC /usr/share/locale/sr_YU.ISO8859-2/LC_COLLATE -> ../la_LN.ISO8859-2/LC_COLLATE /usr/share/locale/sr_YU.ISO8859-2/LC_CTYPE -> ../la_LN.ISO8859-2/LC_CTYPE /usr/share/locale/is_IS.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/zh_TW.Big5/zh_Hant_TW.Big5 -> zh_Hant_TW.Big5 /usr/share/locale/af_ZA.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE /usr/share/locale/af_ZA.ISO8859-15/LC_COLLATE -> ../la_LN.ISO8859-15/LC_COLLATE /usr/share/locale/en_AU.ISO8859-15/LC_COLLATE -> ../la_LN.ISO8859-15/LC_COLLATE /usr/share/locale/en_AU.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE /usr/share/locale/fr_CH.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/fr_CH.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/zh_CN.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/zh_CN.UTF-8/zh_Hans_CN.UTF-8 -> zh_Hans_CN.UTF-8 /usr/share/locale/zh_CN.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE /usr/share/locale/sv_SE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/it_IT.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/it_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/it_CH.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/it_CH.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/nn_NO.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/nn_NO.ISO8859-1/LC_COLLATE -> ../no_NO.ISO8859-1/LC_COLLATE /usr/share/locale/nn_NO.ISO8859-1/LC_MONETARY -> ../no_NO.ISO8859-1/LC_MONETARY /usr/share/locale/nn_NO.ISO8859-1/LC_NUMERIC -> ../no_NO.ISO8859-1/LC_NUMERIC /usr/share/locale/nn_NO.ISO8859-1/LC_MESSAGES -> ../no_NO.ISO8859-1/LC_MESSAGES /usr/share/locale/nl_NL.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/nl_NL.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/zh_TW.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/zh_TW.UTF-8/zh_Hant_TW.UTF-8 -> zh_Hant_TW.UTF-8 /usr/share/locale/zh_TW.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE /usr/share/locale/de_AT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/en_GB.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/en_GB.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/ca_ES.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/zh_CN.GBK/zh_Hans_CN.GBK -> zh_Hans_CN.GBK /usr/share/locale/zh_CN.GBK/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/de_DE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/fi_FI.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/fi_FI.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/zh_CN.eucCN/zh_Hans_CN.eucCN -> zh_Hans_CN.eucCN /usr/share/locale/zh_CN.eucCN/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/zh_HK.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/zh_HK.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE /usr/share/locale/sr_YU.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/sr_YU.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE /usr/share/locale/zh_CN.GB18030/zh_Hans_CN.GB18030 -> zh_Hans_CN.GB18030 /usr/share/locale/zh_CN.GB18030/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/fr_CA.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE /usr/share/locale/fr_CA.ISO8859-15/LC_COLLATE -> ../la_LN.ISO8859-15/LC_COLLATE /usr/share/locale/ca_AD.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/fr_BE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/fr_BE.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/de_CH.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/en_NZ.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE /usr/share/locale/en_NZ.ISO8859-15/LC_COLLATE -> ../la_LN.ISO8859-15/LC_COLLATE /usr/share/locale/es_ES.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/zh_HK.Big5HKSCS/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/da_DK.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/da_DK.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/zh_CN.GB2312/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE /usr/share/locale/zh_CN.GB2312/zh_Hans_CN.GB2312 -> zh_Hans_CN.GB2312 /usr/share/locale/fr_FR.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/fr_FR.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/pt_PT.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/pt_PT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE /usr/share/locale/lt_LT.ISO8859-4/LC_CTYPE -> ../la_LN.ISO8859-4/LC_CTYPE /usr/share/locale/eu_ES.ISO8859-1/LC_COLLATE -> ../la_LN.ISO8859-1/LC_COLLATE /usr/share/locale/eu_ES.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE What is the fix for this? It looks like there is some Makefile logic which is wrong. -- Craig From owner-freebsd-current@freebsd.org Sun Nov 15 11:38:32 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AE82A2F8D7; Sun, 15 Nov 2015 11:38:32 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1838E1C12; Sun, 15 Nov 2015 11:38:32 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacdm15 with SMTP id dm15so145129958pac.3; Sun, 15 Nov 2015 03:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iYI5+C4PpDHgItfdmvOuc5DTcTJUigkxOwqwcI1fkHg=; b=Ed+azcyjUjVW8yx2I8qhGfYPDCutEPEgYQNg+VLXse1h0wlNwQ1VhyGHK4oKtCslyT VEhUCwXgO44urzCEPgnqqSyL8sLZueg2uWaUFQrIz/9L6YMOTXf5vWPQ0KVRo7OgWP87 RPYRYN71ejcgVMRRQmS/hD+okbZskQLzEwV4xtmPuAgaKU8pWAgukEH7FDpgo5m2Dxbl psixAu+sHDRzguHjm9W6IuWBZqWm/S59vGiJwRWGNjiPFpwAqJfj0qApfZExSNDIYn50 rqV9OrY5AjLRABKe1uJdWq4nj8mrRuCH9b12KcY5mdJuvS111tiN5PPyCei17svwXEvM Jc7A== X-Received: by 10.67.5.164 with SMTP id cn4mr45894748pad.141.1447587511664; Sun, 15 Nov 2015 03:38:31 -0800 (PST) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id qd2sm30231670pbb.68.2015.11.15.03.38.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 03:38:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Need help fixing failing locale tests From: NGie Cooper In-Reply-To: <56486CBF.3010200@marino.st> Date: Sun, 15 Nov 2015 03:38:28 -0800 Cc: Craig Rodrigues , Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <02FA2ED1-42BF-4BF2-879D-5463A119C000@gmail.com> <564838AD.2000402@marino.st> <56486CBF.3010200@marino.st> To: marino@freebsd.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 11:38:32 -0000 > On Nov 15, 2015, at 03:30, John Marino = wrote: =E2=80=A6 > by they way, this was meant to be "removed from DragonFly". I don't > know if "make upgrade" is set right for FreeBSD. (it appears not) make upgrade doesn=E2=80=99t exist on FreeBSD: $ (cd /usr/src/svn/; make upgrade) make: don't know how to make upgrade. Stop make: stopped in /usr/src/svn $ > It looks like the deleted locales were not removed. > They should be. Hence my previous reply=E2=80=A6 > I think somebody needs to add these locales to be reaped by make = upgrade. ObsoleteFiles.inc is missing old locale files/directories. Cheers, -NGie= From owner-freebsd-current@freebsd.org Sun Nov 15 07:09:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E8F3A2F3AE; Sun, 15 Nov 2015 07:09:38 +0000 (UTC) (envelope-from dragonflybsd@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 149D613C6; Sun, 15 Nov 2015 07:09:37 +0000 (UTC) (envelope-from dragonflybsd@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 00EC543BA2; Sun, 15 Nov 2015 01:09:33 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: NGie Cooper , Craig Rodrigues References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> Cc: Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" From: John Marino X-Enigmail-Draft-Status: N1110 Message-ID: <56482FA9.2010803@marino.st> Date: Sun, 15 Nov 2015 08:09:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 15 Nov 2015 12:17:35 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 07:09:38 -0000 On 11/15/2015 4:46 AM, NGie Cooper wrote: > >> On Nov 14, 2015, at 19:28, NGie Cooper wrote: > > … > >> Why were these locales removed? >> >> 58 OLD_FILES+=usr/share/locale/la_LN.ISO8859-1/LC_COLLATE >> 59 OLD_FILES+=usr/share/locale/la_LN.ISO8859-1/LC_CTYPE >> 60 OLD_FILES+=usr/share/locale/la_LN.ISO8859-1/LC_TIME >> 61 OLD_DIRS+=usr/share/locale/la_LN.ISO8859-1 >> 62 OLD_FILES+=usr/share/locale/la_LN.ISO8859-13/LC_COLLATE >> 63 OLD_FILES+=usr/share/locale/la_LN.ISO8859-13/LC_CTYPE >> 64 OLD_DIRS+=usr/share/locale/la_LN.ISO8859-13 > > la_LN.ISO8859-1 is the old Latin locale, which is no longer installed. Copying over locale files from a stable/10 host works, but I’m confused as to why a bunch of locales weren’t ported over in their non-UTF-8 forms. > Thanks, > We (DragonFly) didn't just update locales. We took the opportunity to do spring cleaning. We didn't want to be as drastic as OpenBSD which removed all encodings except for C/POSIX and UTF, but we did remove several locales intentionally. In the case of ISO8859-1: All ISO8859-* is basically obsolete. In western Europe, if somebody wants ISO-8859, they want ISO8859-15, not ISO8859-1. They are similar, but the former is tailored for western europe with "Euro" currency and 9 other symbols. It comes at the expense of removing 10 characters from ISO8859-1. There's also a common problem that users view -15 documents with -1 accidently. So there was a conscience decision to have either ISO8859-1 or ISO8859-15 but not both. For western Europe this means the ISO8859-1 versions were dropped. ISO8859-15: In the case of USA and other non-European countries, they keep -1 and dropped -15. currency based: In the case of countries where the currency symbols is not part of ISO8859, it was dropped. E.g. Costa Rica uses the Colon which is only in UTF-8, so there's no ISO8859-* encoding at all for CR. Latin: Who speaks Latin today? This was mainly an alias for 7-bit ascii. We originally dropped that, but later moved it to US-ASCII (which was just a symlink to Latin before) Bapt liked DF approach well enough that he adopted it. Even Edwin was first in desiring to clean up locales. The major update was a perfect time. Bottom line: The testsuite needs to be updated. e.g. use de_DE.ISO8859-15 intead of de_DE.ISO8859-1 For latin, replace with US-ASCII equivalent. John From owner-freebsd-current@freebsd.org Sun Nov 15 07:48:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEB98A2FAC8; Sun, 15 Nov 2015 07:48:01 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6482413C6; Sun, 15 Nov 2015 07:48:01 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 42E0243BA5; Sun, 15 Nov 2015 01:47:59 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: NGie Cooper References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <02FA2ED1-42BF-4BF2-879D-5463A119C000@gmail.com> Cc: Craig Rodrigues , Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino X-Enigmail-Draft-Status: N1110 Message-ID: <564838AD.2000402@marino.st> Date: Sun, 15 Nov 2015 08:47:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <02FA2ED1-42BF-4BF2-879D-5463A119C000@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 15 Nov 2015 12:17:47 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 07:48:02 -0000 On 11/15/2015 8:24 AM, NGie Cooper wrote: >> On Nov 14, 2015, at 23:09, John Marino wrote: >> Bapt liked DF approach well enough that he adopted it. Even Edwin was >> first in desiring to clean up locales. The major update was a perfect time. >> >> Bottom line: >> The testsuite needs to be updated. >> e.g. use de_DE.ISO8859-15 intead of de_DE.ISO8859-1 >> For latin, replace with US-ASCII equivalent. > > I wish this had been clearly communicated here: https://svnweb.freebsd.org/changeset/base/290494 … instead, there are some POLA violations: > 1. No RelNotes. > 2. No summary of locales that have been removed. > 3. No UPDATING entry for people to migrate from a locale to another. > 4. Deprecated locales (as you described it above) are still present on my system after running `make delete-old` (assuming I have my acronyms right, for example, ca_ES, it_CH, etc should be -1, not -15 based on your claim above). > I will update the testcases to use locales if possible, but more work needs to be done finishing off this project and documenting for end-users what has changed. With 4.) they have been removed from FreeBSD when "Make upgrade" is run after rebuilding. Does FreeBSD have a cleanup like that, and did you run it? If not, then maybe that needs to be updated. with 3.) That's a bit like saying changing the color of shoe laces needs instructions for people to learn how to adjust. Run "locale -a" to see what's available on the system. This has always been true. Attempting to switch to a locale that doesn't exist results in staying in "C" locale, which is quite obvious. with 2.) Could be combined with 1.) but in any case, there really shouldn't be POLA on anything that has no standard. Should you announce every time you add a locale too, in release notes? Really "locale -a" should tell the whole story. 1.) A paragraph on removed locales is fine. Those removed have been removed because they are a) likely unused and b) if used, they are used by mistake. in this case you hit c) where the testsuite probably chose the "wrong" locale in the first place. Note that GCC did this too with their libstdc++ testsuite and that was fixed this weekend (a huge patch to GCC 6 upstream). John From owner-freebsd-current@freebsd.org Sun Nov 15 11:30:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10C0AA2F6E0; Sun, 15 Nov 2015 11:30:15 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0717A1804; Sun, 15 Nov 2015 11:30:14 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 3C19143BA1; Sun, 15 Nov 2015 05:30:10 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Craig Rodrigues , Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <02FA2ED1-42BF-4BF2-879D-5463A119C000@gmail.com> <564838AD.2000402@marino.st> Cc: freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino Message-ID: <56486CBF.3010200@marino.st> Date: Sun, 15 Nov 2015 12:30:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2015 12:18:33 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 11:30:15 -0000 On 11/15/2015 12:23 PM, Craig Rodrigues wrote: > > > On Sat, Nov 14, 2015 at 11:47 PM, John Marino > wrote: > > > With 4.) they have been removed from FreeBSD when "Make upgrade" is run > after rebuilding. Does FreeBSD have a cleanup like that, and did you > run it? If not, then maybe that needs to be updated. by they way, this was meant to be "removed from DragonFly". I don't know if "make upgrade" is set right for FreeBSD. (it appears not) > > I did not run "make upgrade". > I did this: > cd /usr/src > svn up > > I then ran the 11 steps listed in /usr/src/Makefile: > > https://github.com/freebsd/freebsd/blob/master/Makefile#L73 > > It looks like after running those steps, my system is in an inconsistent > state. I see that the following symlinks point to nonexistent files. [snip] It looks like the deleted locales were not removed. They should be. > What is the fix for this? I think somebody needs to add these locales to be reaped by make upgrade. > It looks like there is some Makefile logic which is wrong. John From owner-freebsd-current@freebsd.org Sun Nov 15 12:24:29 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB020A2EF27 for ; Sun, 15 Nov 2015 12:24:29 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 352F5123B for ; Sun, 15 Nov 2015 12:24:28 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lfdo63 with SMTP id o63so73288812lfd.2 for ; Sun, 15 Nov 2015 04:24:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xsCxaehna8ebJ4kIWE4d5Fd0BqboG5TN9n1FfrK3Xzw=; b=gjxIXN8GvxerFjd7TZZtUUmmvcVZpQxGgpR5sqCGDWRsbYzrd5p9P7ZMZvJaY5l1TP BcJuDbtLIFgc7P34JQY97pYj9GVVjoE6QMeTt2hZ/YyokS75UQBJ5ELdXlrSVe0xntAQ CtbI3LPm8HQB+Vvp/hzIyGPFC03wJxUaGU06JwZK0rdiWAZWbBUeWfImmVhIVHLCpsFC SUcjzul0K3RboCGJtw6p5ifAzdAubKUt4x6m1n4p9CWdy4WdztzUtnOADOu6ueGipFZp z3XFxXBzB3D3cG7lELiqdpB487VbR/u1WrfkSWH119yZ1qE2AePqfnj04OHGO8wWnacz KyhA== X-Gm-Message-State: ALoCoQlDzsOFxK92DH3hXcwld6HXGdc575e68+WtOiTT7eyf3hvs7g9FUCdC16n21pJEd4iv8JoI X-Received: by 10.25.17.66 with SMTP id g63mr14438635lfi.110.1447590261474; Sun, 15 Nov 2015 04:24:21 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id j136sm4726194lfe.38.2015.11.15.04.24.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 04:24:20 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: John Marino , NGie Cooper , Craig Rodrigues References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> Cc: Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <56487973.5070803@freebsd.org> Date: Sun, 15 Nov 2015 15:24:19 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56482FA9.2010803@marino.st> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 12:24:29 -0000 On 15.11.2015 10:09, John Marino wrote: > We (DragonFly) didn't just update locales. We took the opportunity to > do spring cleaning. We didn't want to be as drastic as OpenBSD which > removed all encodings except for C/POSIX and UTF, but we did remove > several locales intentionally. > > In the case of ISO8859-1: > All ISO8859-* is basically obsolete. > In western Europe, if somebody wants ISO-8859, they want ISO8859-15, not > ISO8859-1. They are similar, but the former is tailored for western > europe with "Euro" currency and 9 other symbols. It comes at the > expense of removing 10 characters from ISO8859-1. There's also a common > problem that users view -15 documents with -1 accidently. So there was > a conscience decision to have either ISO8859-1 or ISO8859-15 but not > both. For western Europe this means the ISO8859-1 versions were dropped. ISO8859-1 locales are legacy even if obsoleted in modern world (I agree with that). Lots of ports (even at configure stage!) have checks for them. Since we generate locales from CLDR now, it will be no cost to bring all 8859-1 back to not violate POLA and not fix every failing port. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 12:37:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C292A271FA for ; Sun, 15 Nov 2015 12:37:52 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0F881958 for ; Sun, 15 Nov 2015 12:37:51 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbcs9 with SMTP id cs9so74909393lbb.1 for ; Sun, 15 Nov 2015 04:37:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=k7MxCFeKNeKvUrFJ3vNheOwpRnLLg0K+ZH6EMew9E5c=; b=eLDz8MHxySKjGKJv/fuyZfD+Zuqw/ris3Dofx8Bje4jvuJ39ft2GTasRxUOiGyW1X7 f255QySmHZJWPulk0vSqlpA1tZMeWi56h+JKo5MSGPw1k1uQkspXQkQySgmsE4785oVB Dn5njaJ6B0XQafjbYmk1Pic+pGXuylDP0fAMiKBPs3cvpGE1vgzdVN2ZgIXxkcq/BEd9 CLSnQrM5tP2rJ95jSI7Mcbzr4pMeox6DGnyFBjbXW0uhygcCORASQxVtcfrfQANabHaS pspRVOwxTeHaJp15qOE/hS1V+wW9U0XOL37QC4/Oxk+3baqGfDf/8Z+cGfBkBv4JAW7U /pFg== X-Gm-Message-State: ALoCoQm6OBAlzZZwz22PTZ2+ItWa/YtQ3KMRCq94KdGojY9oVelXaTkDTQZmWLl5+cFMb5dPR6MA X-Received: by 10.112.149.97 with SMTP id tz1mr14501960lbb.57.1447591064055; Sun, 15 Nov 2015 04:37:44 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id d2sm3369413lbc.11.2015.11.15.04.37.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 04:37:42 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: John Marino , NGie Cooper , Craig Rodrigues References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> Cc: Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <56487C96.40403@freebsd.org> Date: Sun, 15 Nov 2015 15:37:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56487973.5070803@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 12:37:52 -0000 On 15.11.2015 15:24, Andrey Chernov wrote: > On 15.11.2015 10:09, John Marino wrote: >> We (DragonFly) didn't just update locales. We took the opportunity to >> do spring cleaning. We didn't want to be as drastic as OpenBSD which >> removed all encodings except for C/POSIX and UTF, but we did remove >> several locales intentionally. >> >> In the case of ISO8859-1: >> All ISO8859-* is basically obsolete. >> In western Europe, if somebody wants ISO-8859, they want ISO8859-15, not >> ISO8859-1. They are similar, but the former is tailored for western >> europe with "Euro" currency and 9 other symbols. It comes at the >> expense of removing 10 characters from ISO8859-1. Forget to reply on that part: >> There's also a common >> problem that users view -15 documents with -1 accidently. So there was >> a conscience decision to have either ISO8859-1 or ISO8859-15 but not >> both. For western Europe this means the ISO8859-1 versions were dropped. It is pure user problem choosing its own locale (self footshooting), it not leads to program build failures (like configure checks) or tests failures etc. BTW, linux keeps 8859-1 locales. > ISO8859-1 locales are legacy even if obsoleted in modern world (I agree > with that). Lots of ports (even at configure stage!) have checks for > them. Since we generate locales from CLDR now, it will be no cost to > bring all 8859-1 back to not violate POLA and not fix every failing port. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 12:47:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CF53A274D3; Sun, 15 Nov 2015 12:47:01 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FFB91F1D; Sun, 15 Nov 2015 12:47:01 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmec201 with SMTP id c201so18259076wme.3; Sun, 15 Nov 2015 04:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kQk1zTZWWt25BdXQ/eHM9o5f3fllBxPZBcbeTMOKQnI=; b=TzwPTBUJ3qtZTjDxkglpjwV6XHh+r80N6wsohZ8JEujWG483a660uPzyUN0yRKxCY5 6FjWAoveAet6mnABASzr62MixYZngwj68z0HLGYE6ugYVLIENKNmIw6nkySmhTB9/lhY EL2EHCm3QFpdGbiBIB7sQBzbfGKVPpDWdMADQgXXiBQs90gZ14/5SUcnjKM1BKDhj3TZ aVUx0aaek48a2vsY5cQohC+OZk0payrvdmTQ4OgQrhbilSUS0nokOQsZQSXOcWrQ69ev iPGmulxuEiAaMMPZsC3PMBtFST+I7kUN3x9vHfHfhtq7mzyn+/KtMAY+wOzUomDNpPa3 Q7KA== X-Received: by 10.194.90.50 with SMTP id bt18mr3910499wjb.118.1447591619701; Sun, 15 Nov 2015 04:46:59 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id q77sm12124617wmd.22.2015.11.15.04.46.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 04:46:58 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 15 Nov 2015 13:46:57 +0100 From: Baptiste Daroussin To: Andrey Chernov Cc: John Marino , NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Subject: Re: Need help fixing failing locale tests Message-ID: <20151115124656.GB93991@ivaldir.etoilebsd.net> References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <56487973.5070803@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 12:47:01 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: > On 15.11.2015 10:09, John Marino wrote: > > We (DragonFly) didn't just update locales. We took the opportunity to > > do spring cleaning. We didn't want to be as drastic as OpenBSD which > > removed all encodings except for C/POSIX and UTF, but we did remove > > several locales intentionally. > >=20 > > In the case of ISO8859-1: > > All ISO8859-* is basically obsolete. > > In western Europe, if somebody wants ISO-8859, they want ISO8859-15, not > > ISO8859-1. They are similar, but the former is tailored for western > > europe with "Euro" currency and 9 other symbols. It comes at the > > expense of removing 10 characters from ISO8859-1. There's also a common > > problem that users view -15 documents with -1 accidently. So there was > > a conscience decision to have either ISO8859-1 or ISO8859-15 but not > > both. For western Europe this means the ISO8859-1 versions were droppe= d. >=20 > ISO8859-1 locales are legacy even if obsoleted in modern world (I agree > with that). Lots of ports (even at configure stage!) have checks for > them. Since we generate locales from CLDR now, it will be no cost to > bring all 8859-1 back to not violate POLA and not fix every failing port. >=20 Exp-run have been made and no ports were failing with the removed locales. Best regards, Bapt --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZIfsAACgkQ8kTtMUmk6EwtCQCfbQAJaHoJm7B/sdIw0/Yq8ynh KH8AoLEZQSuaZdgiRLrMWSIPrGEOHusY =ZjvY -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-current@freebsd.org Sun Nov 15 12:49:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5197DA275E5 for ; Sun, 15 Nov 2015 12:49:15 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 947641202 for ; Sun, 15 Nov 2015 12:49:14 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 73758 invoked from network); 15 Nov 2015 12:42:31 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Nov 2015 12:42:31 -0000 Date: Sun, 15 Nov 2015 13:42:31 +0100 (CET) Message-Id: <20151115.134231.74704981.sthaug@nethelp.no> To: ache@freebsd.org Cc: dragonflybsd@marino.st, yaneurabeya@gmail.com, rodrigc@FreeBSD.org, bapt@freebsd.org, freebsd-current@freebsd.org, testing@freebsd.org Subject: Re: Need help fixing failing locale tests From: sthaug@nethelp.no In-Reply-To: <56487C96.40403@freebsd.org> References: <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <56487C96.40403@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 12:49:15 -0000 > >> There's also a common > >> problem that users view -15 documents with -1 accidently. So there was > >> a conscience decision to have either ISO8859-1 or ISO8859-15 but not > >> both. For western Europe this means the ISO8859-1 versions were dropped. > > It is pure user problem choosing its own locale (self footshooting), it > not leads to program build failures (like configure checks) or tests > failures etc. BTW, linux keeps 8859-1 locales. I see no good reason whatsoever to drop ISO8859-1. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@freebsd.org Sun Nov 15 12:56:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F33BA27865 for ; Sun, 15 Nov 2015 12:56:36 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB2DA19EC for ; Sun, 15 Nov 2015 12:56:35 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lfs39 with SMTP id 39so73637618lfs.3 for ; Sun, 15 Nov 2015 04:56:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=WcDM8cnHhsj4D2nDI5Q1zrR5ObABf10qCJ8sxn0625o=; b=UYQCI0Qy4jtPxzKMWJus0ofZeaobO1335AH6ayG10VEdQEL4ziIExzBWXOuo/m6aDb JuVEuLuci3/IWXzU82GzLmFFNX5pfcRjU+Qj+eoQFAdQ0l5/phAaJuX9RPmjs2fjrk0F isCrLWFGINcQ9rIyCeCX5vLqk6UzfkuGA+ZmYPprNs3CEGW5l9Ucc2mw/mnhpD0DwrB/ liGvS8DysYlB1pX6NoWjhl/pV1Tdw3qhaivwo5jDswKqXJ5YlYKrPwl6x1+DWo5mgySi 2cVWg8ypDewKoG1QCBZP6P+Y3c5M/RYrFYpVGLW0c/RWExaMRroeC/mGebV7q8hNYFDP WZng== X-Gm-Message-State: ALoCoQnUPg0T9wDBkYEHvVJv/TP7HaGM+ar77ztZpCnanHUALQDjgCyzb0pBZceN4O/Nz1BdyAL0 X-Received: by 10.25.15.213 with SMTP id 82mr14185407lfp.98.1447592187982; Sun, 15 Nov 2015 04:56:27 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id qp7sm4667056lbc.24.2015.11.15.04.56.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 04:56:26 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> Cc: John Marino , NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <564880FA.5000009@freebsd.org> Date: Sun, 15 Nov 2015 15:56:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151115124656.GB93991@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CV3f7EI3iERDj0vSvSFiO0l5rNL3jVXkf" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 12:56:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CV3f7EI3iERDj0vSvSFiO0l5rNL3jVXkf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15.11.2015 15:46, Baptiste Daroussin wrote: > On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: >> On 15.11.2015 10:09, John Marino wrote: >> ISO8859-1 locales are legacy even if obsoleted in modern world (I agre= e >> with that). Lots of ports (even at configure stage!) have checks for >> them. Since we generate locales from CLDR now, it will be no cost to >> bring all 8859-1 back to not violate POLA and not fix every failing po= rt. >> > Exp-run have been made and no ports were failing with the removed local= es. There is soft-fail, configure just marks that locales are not supported and use "C". Sorry I don't remember port names where I saw it right now and don't have a time to search for them right now too. Soft-fails (like in tcl with nl_langinfo) are almost impossible to detect excepting specific situation happens or source code inspection. Do we ever need them when there is no harm to keep 8859-1 locales? --=20 http://ache.vniz.net/ --CV3f7EI3iERDj0vSvSFiO0l5rNL3jVXkf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWSID6AAoJEKUckv0MjfbKBsQH/iQ3fB49jepAL4dc8cdQ98d4 6rXZtXlPBbYdmJY2GYA29hWvRLmq8e6ySRtI7wUu/VWyJbbIipTZHSHXpTc5lgXE K/aANZPyagcx+24d2JIltL0/J3TV7tZ0XP5qJioA8syB+2lfGSK5yT8d7pcsGot0 m/aQn39l0QIMKRYPdRHO+9P3n3CuX7cuhRBqI6VLVwJQPLocdHkXnb37TFqZkb0B V8X/dmoEU9Urov4TaM5gLU1ub/QoSY7M+NSKvQHL0UQzSEpYWUgKgGGRRJwKjKjn z8F+m5QU92vA0lRX4umOf4jV7Za/NtvAHJPssEBxmnepN3ChNofl2uk/OMA3KpY= =SMgy -----END PGP SIGNATURE----- --CV3f7EI3iERDj0vSvSFiO0l5rNL3jVXkf-- From owner-freebsd-current@freebsd.org Sun Nov 15 13:00:14 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEDC1A27975; Sun, 15 Nov 2015 13:00:13 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7010D1C11; Sun, 15 Nov 2015 13:00:13 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmuu63 with SMTP id u63so18344321wmu.0; Sun, 15 Nov 2015 05:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=lcSk1J8BaXvieEgzOrPdw1AdfBm8hlxmkNgmzz6noqA=; b=yFjhC4f4ugdcMh+mZCGC5Iwf9UsHkJnLt5LqlaJobFCTe7vnjH/TbZRbqeKX4XBnca ZOWMBD3ChA9R4nkdpNQYe7YzwjwhjO14hjY/g6+X4+gizsiS+vpb97KgLPRerIZIIFEW UEUEv8LfLUyHDLgw4puyhZ06FkCnkrRmOpva8NR8ErmfRMXMDz7VSqAwK+AsFHOu9cj1 oeJJIq3cXpWe+mNBw3huRnsAtaCmvSB/z4uouXgNcJIBvKBjqBUTLEAhgl4Vumpl9CVW KfGylyDNSvTnQxj5mu4ZUIeAqWVN70wVaz5At0otSy56YcMNMWgpOHUgiTA6hYRzapqp ++ew== X-Received: by 10.28.189.11 with SMTP id n11mr14872151wmf.27.1447592411948; Sun, 15 Nov 2015 05:00:11 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id u17sm13421200wmd.8.2015.11.15.05.00.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 05:00:11 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 15 Nov 2015 14:00:09 +0100 From: Baptiste Daroussin To: Andrey Chernov Cc: John Marino , NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Subject: Re: Need help fixing failing locale tests Message-ID: <20151115130009.GC93991@ivaldir.etoilebsd.net> References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline In-Reply-To: <564880FA.5000009@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:00:14 -0000 --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2015 at 03:56:26PM +0300, Andrey Chernov wrote: > On 15.11.2015 15:46, Baptiste Daroussin wrote: > > On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: > >> On 15.11.2015 10:09, John Marino wrote: > >> ISO8859-1 locales are legacy even if obsoleted in modern world (I agree > >> with that). Lots of ports (even at configure stage!) have checks for > >> them. Since we generate locales from CLDR now, it will be no cost to > >> bring all 8859-1 back to not violate POLA and not fix every failing po= rt. > >> > > Exp-run have been made and no ports were failing with the removed local= es. >=20 > There is soft-fail, configure just marks that locales are not supported > and use "C". Sorry I don't remember port names where I saw it right now > and don't have a time to search for them right now too. Soft-fails (like > in tcl with nl_langinfo) are almost impossible to detect excepting > specific situation happens or source code inspection. Do we ever need > them when there is no harm to keep 8859-1 locales? Is it ok if I readd those locales as aliases on 8859-15? Best regards, Bapt --ALfTUftag+2gvp1h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZIgdgACgkQ8kTtMUmk6EwlOwCgkRhZOcoVw0gvP/jsAnM7ItFZ oC0An3v56dqkFCLs/dj1pwk6QTsFOJDH =M9qd -----END PGP SIGNATURE----- --ALfTUftag+2gvp1h-- From owner-freebsd-current@freebsd.org Sun Nov 15 13:02:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EB56A27B29 for ; Sun, 15 Nov 2015 13:02:16 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1A95D1E56 for ; Sun, 15 Nov 2015 13:02:15 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.101] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 9746A15705 for ; Sun, 15 Nov 2015 14:54:01 +0200 (EET) From: Dan Partelly Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: libXO-ification - Why - and is it a symptom of deeper issues? Message-Id: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Date: Sun, 15 Nov 2015 14:54:01 +0200 To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:02:16 -0000 Hi all, I was looking at the new facility of dumping JSON,XML from many utils in = base and after some funny minutes, I couldn't stop ask myself =E2=80=9C = Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real = answer. Ill outline what I think: 1. Undoubtedly, it makes base code slightly harder to understand and = maintain.=20 2. I have seen the idea that this makes the information dumped by = utilities in the base easily accessible programatically. OK, maybe it = does , but it doesn't fit with the current paradigm of "tool | filter | tool=E2=80=9D= at all. There are no tools able to accept JSON and filter it in any = meaningful way, and I dont see too many ppl changing their code to read JSON instead of text. = I don't even see the base tools changing. This output may be useful in = corner cases only. 3. The integration of libxo IMO only points at a much deeper issue IMO. = It is only an expression of the need of a mechanism aimed at binary code = reuse. But it does not solve the problem, it only adds yet another = possibility in a world where too much choices already result in too much = splits and incompatible APIs.=20 4. This whole effort would have been IMO much better served by porting = the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, = much like the libs for geom, zfs , etc , ready for reuse of 3rd party = code. Eventually writing network control daemons in time over it , much = like solaris does. 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the = bestiary of ad hoc databases already existing in BSDs ? Programatic = readability, yes. but it does not add any real much needed functionality = such as *transactional databases* for system tools. Why not research a = proper solution - easily accessible by other programs ,orthogonal , = transactional, and ACL protected solution which can be used all over = the place , from OS boot, to ABI management, service management, network = management, user management. I hope this day will come, a day when I = will not have to edit a single config file manually, yet I would have = access to all the config and system state easy with wrapper APIs. In = the light of this point, why go with UCL ? It is not orthogonal, it is = not transnational, and editing the config files directly would result in = the same old human errors which bite as all from time to time. 5. It is my opinion that Solaris addressed some of those issue. Solaris = FMRI and SMF are lightyears ahead of the very tired models we keep using = on BSDs. Why not build on the insight offered by those (or even on the = insight offered by Windows :P) , then inventing more adhoc solutions and = ad-hoc databases, which do not address the real issues we have , like = binary code reuse, service management issues, lack of a system wide = published -subscriber bus ( not kdbus :P ) fault detection and reaction, = fault reporting, all much needed parts of a modern OS.=20 And now thee questions 1. Why lib XO ? Why burden the OS for some corner cases where it may be = useful ? 2. Was there any real talk on how to bring FreeBSD up to speed regarding = those issues ? A period of research on what exists, on what can be done = , and ensure important things are not showed in background and replaced = with yet another ad-hoc config database which lacks modern features ? =46rom where I am standing, this could be a project spawning multiple = years , but it would be well worth it, and in my opinion it would be = also worthy of=20 the freeSBD foundation sponsorship for several years in a row. The = features I touched upon became very important parts of oder OSes, and = rightly so.=20 Note: this message is serious and it is not intended to start flame wars, = religious crusades, or offend anyone.=20 =20= From owner-freebsd-current@freebsd.org Sun Nov 15 13:04:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 221E5A27C06 for ; Sun, 15 Nov 2015 13:04:44 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AAC0108C for ; Sun, 15 Nov 2015 13:04:42 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbcs9 with SMTP id cs9so75065821lbb.1 for ; Sun, 15 Nov 2015 05:04:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=puw2KXLCieNcJggY90Ya8fZPZ02xb+U0Njmf2uZJmc4=; b=NYPZFZaIHnOtKBlTVQ3X36qwwT0rFIxLd9BRylA9AIl5dHz8RIHGJO+s00ea+Ym7t+ AIYroCIfl27M28YaypFPVkKVgJumQN2ze2N6o/ak01Q1S0IyLQHBypmhUfsBR76Q5jxs gr9BQN0WAMIXNC2SJ57UbYGaS2Mz3UyFbIEgZrUNHf7DBNiQwY4dqq8TMjJ2QZ6+RjIw 70rZxNho7/f7AJi9ejrlrX0i/5ykBZJNvgSyjTNNBaS6Zn/zm8705jtBD3vUp1VwlQfj Qt69QOU0wqQ64uXIK8SzY6B0EcrK7tvX9p8sj38efMGVjX5chr+X+kWm0hd0P/vtYkUB ztDA== X-Gm-Message-State: ALoCoQlOIivxz3/WB1L4goUl4if0dGonKCXG6ryzTOnz6wiTdUiM8WCS0szgG6ZBbvkoYabQYZhS X-Received: by 10.112.151.7 with SMTP id um7mr14969442lbb.16.1447592675027; Sun, 15 Nov 2015 05:04:35 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id g193sm4753889lfb.6.2015.11.15.05.04.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 05:04:34 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <20151115130009.GC93991@ivaldir.etoilebsd.net> Cc: John Marino , NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <564882E1.5050404@freebsd.org> Date: Sun, 15 Nov 2015 16:04:33 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151115130009.GC93991@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MIqWb4iilpE53FpgbvoFfv3eroo7aJSsT" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:04:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MIqWb4iilpE53FpgbvoFfv3eroo7aJSsT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15.11.2015 16:00, Baptiste Daroussin wrote: > On Sun, Nov 15, 2015 at 03:56:26PM +0300, Andrey Chernov wrote: >> On 15.11.2015 15:46, Baptiste Daroussin wrote: >>> On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: >>>> On 15.11.2015 10:09, John Marino wrote: >>>> ISO8859-1 locales are legacy even if obsoleted in modern world (I ag= ree >>>> with that). Lots of ports (even at configure stage!) have checks for= >>>> them. Since we generate locales from CLDR now, it will be no cost to= >>>> bring all 8859-1 back to not violate POLA and not fix every failing = port. >>>> >>> Exp-run have been made and no ports were failing with the removed loc= ales. >> >> There is soft-fail, configure just marks that locales are not supporte= d >> and use "C". Sorry I don't remember port names where I saw it right no= w >> and don't have a time to search for them right now too. Soft-fails (li= ke >> in tcl with nl_langinfo) are almost impossible to detect excepting >> specific situation happens or source code inspection. Do we ever need >> them when there is no harm to keep 8859-1 locales? >=20 > Is it ok if I readd those locales as aliases on 8859-15? It is hacking solution leads to wrong collating order and character classes. It is better to generate true 8859-1 just in the same way you already do for 8859-15. BTW, I can't check right now, but in case 8859-5 is removed too, it is better to restore it, it was used in Suns as their standard Russian encoding. --=20 http://ache.vniz.net/ --MIqWb4iilpE53FpgbvoFfv3eroo7aJSsT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWSILhAAoJEKUckv0MjfbKEfMIAIW+80MDARSu4Sx8eL1Sn9Et PW351DbHU+hAILHkOZ9yCQa1OKRh981JmUNCi5ocyphuBf303BOgUfHyB5L1h2rf hQWFe78s+tPu1s1P3VlrVxZ5miakhTdPpyVfZDIqa3HO2jw94hxFAW96+JTINm+a +aWVlIRQk3+Q2qqGaIVTxloEeFRmRZPnNYWCFrXynftK8IIK3reUc53IzZ1AoJBP ZoodS1hQ6dsACRjwItoX8M5vY096vJ58QiZ4G+LyupoTBvJQY23S0CyEhRtNnMPb JldOMfofHRkoYrIgDwdgagBpl/P9+A41JynDnWm1QdC0/PkjBrgTaS5pqNX4IAs= =Bnpx -----END PGP SIGNATURE----- --MIqWb4iilpE53FpgbvoFfv3eroo7aJSsT-- From owner-freebsd-current@freebsd.org Sun Nov 15 13:10:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28787A27D71 for ; Sun, 15 Nov 2015 13:10:10 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A448B144D for ; Sun, 15 Nov 2015 13:10:09 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbkw15 with SMTP id kw15so75319061lbb.0 for ; Sun, 15 Nov 2015 05:10:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=JDX2dDuaZdq2EnJ/EHJcZHZUebySEUeBXOxdB6pnE8I=; b=ZqdrMGiOQon0w4b0hY2nBfpxhqHCv3Htu/8inLTaN7y2WKCdg0WEwMgYmiThfPqe30 TSSxUFBYQAzTKNB7zeFfCK5EtSbfb8a55zwhZ/Wfs6hGPkBGrR8AoBIu4rs/gUl6BxUx lPP8LM5Gy9dC4HhrX5I6H2mfOb6DdOidsGQpQHGCUYRw4b7WSXnyDhJ3NP3ebdYa0thU VEgSGKqIHz14//Icwl4nSpcG12zkjEcBUJzReVh/ds0MfLF9DqaL6Jkg+/N4zwAciia9 J7tTfBw86+T+3nf7wBUVtuituj+7eY4LiF4wCfHgnMKqKNUzSGvMnTlv20vlJhlgpWIQ ayCA== X-Gm-Message-State: ALoCoQmmy216ErDopISs+DdJuT7rcX2/OR8zcpktAVaWKtoc4JXvLyew4/2ngRQcmQpZ0aSwR5Pt X-Received: by 10.112.141.201 with SMTP id rq9mr14813272lbb.4.1447593007512; Sun, 15 Nov 2015 05:10:07 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id vz2sm4674039lbb.35.2015.11.15.05.10.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 05:10:06 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <5648842E.3050203@freebsd.org> Date: Sun, 15 Nov 2015 16:10:06 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564882A3.7060109@marino.st> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:10:10 -0000 > Well, there is "harm". The -1/-15 confusion happens a lot. It is user confusion and his responsibility. It not leads to wrong program build f.e. Moreover, you can't protect users who set 8859-1 that way, they do not convert to 8859-15 as you assume but start to complain everywhere that FreeBSD is not working instead. > Is the plan to keep every locale ever created for ever and ever? Never > do any kind of kind of cleanup or reorg? It will be nice to do it that way. FreeBSD have a little part of world locales, which indirectly assumes that they are really used. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 13:10:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9E6DA27E24 for ; Sun, 15 Nov 2015 13:10:50 +0000 (UTC) (envelope-from yonas@fizk.net) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1E5715FB for ; Sun, 15 Nov 2015 13:10:50 +0000 (UTC) (envelope-from yonas@fizk.net) Received: by iouu10 with SMTP id u10so130155217iou.0 for ; Sun, 15 Nov 2015 05:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fizk.net; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=T+MgI1jvUfB3K7VJW+ukxiSVdtJD1Emsu4uP4ntDU8I=; b=ZBkkK9+QB4PxE3i8HPPAxXEvM2NBVX2+z09owt4JCnx2kPZBGyBTvPWxnRCnCLV9Dd +mwJm1rsgE4f0DhPDIxFmhD42qhJvWpFBOYlF5+VemoK82UrDH8uFXAPvhUAgwjsJrK3 w203Sl0W6gFqYzn2QV4mqU0Zy/4PYZtcnYX2g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=T+MgI1jvUfB3K7VJW+ukxiSVdtJD1Emsu4uP4ntDU8I=; b=iAhgHq6RF7NPdRx7s1UfQDrc0sZ0N10e8SwEyI2i6r9VkAlbThZX1JJz2eM0WpsgiK KM3Y+30Ew62KogEBWsUGtCRwPc1ttEgH5aD4P3nsYkYIKvFJzDhRTzigm5alxs3urcw5 vD0qUWwoV6XYWDCLbVgxv8gq5sdnehtTNl7GP/wlWDJ2FMzslPBjNj5fbrjXuxXYzxjQ pb1CIvFAtfQsUQ9087OkosF6Cie7yafagtWlfu72rd1LCbGpsJ1OZcGze9e15IezRHg2 AABGnCluTTRyY4B1+W89ujr26tsB7PGDlMQWnSWfvQxOU2FDh8gtLf+hng0ERpxrbGfS BKgw== X-Gm-Message-State: ALoCoQk7c1iP+ALbkJTtTBDAk1GRUfHt9Ntn+5zrPy9dasYG1KupVemC5AwwRqp5ZxsP0YL4EHOD X-Received: by 10.107.6.146 with SMTP id f18mr26680741ioi.46.1447593049899; Sun, 15 Nov 2015 05:10:49 -0800 (PST) Received: from [192.168.2.200] (CPEbc4dfb965b33-CMbc4dfb965b30.cpe.net.cable.rogers.com. [99.236.139.136]) by smtp.gmail.com with ESMTPSA id i69sm10194626iod.27.2015.11.15.05.10.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 05:10:49 -0800 (PST) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Dan Partelly , freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Yonas Yanfa Message-ID: <56488457.507@fizk.net> Date: Sun, 15 Nov 2015 08:10:47 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:10:51 -0000 Hi Dan, Sounds like you'd be interested in NextBSD: https://en.wikipedia.org/wiki/NextBSD Cheers, Yonas On 11/15/2015 07:54, Dan Partelly wrote: > Hi all, > > I was looking at the new facility of dumping JSON,XML from many utils i= n base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: > > > 1. Undoubtedly, it makes base code slightly harder to understand and ma= intain. > 2. I have seen the idea that this makes the information dumped by utili= ties in the base easily accessible programatically. OK, maybe it does , b= ut > it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I > dont see too many ppl changing their code to read JSON instead of text.= I don't even see the base tools changing. This output may be useful in = corner cases only. > 3. The integration of libxo IMO only points at a much deeper issue IMO.= It is only an expression of the need of a mechanism aimed at binary code= reuse. But it does not solve the problem, it only adds yet another possi= bility in a world where too much choices already result in too much split= s and incompatible APIs. > 4. This whole effort would have been IMO much better served by porting= the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch like the libs for geom, zfs , etc , ready for reuse of 3rd party code.= Eventually writing network control daemons in time over it , much like s= olaris does. > > 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the be= stiary of ad hoc databases already existing in BSDs ? Programatic readabi= lity, yes. but it does not add any real much needed functionality such as= *transactional databases* for system tools. Why not research a proper = solution - easily accessible by other programs ,orthogonal , transactiona= l, and ACL protected solution which can be used all over the place , f= rom OS boot, to ABI management, service management, network management, u= ser management. I hope this day will come, a day when I will not have to= edit a single config file manually, yet I would have access to all the c= onfig and system state easy with wrapper APIs. In the light of this poin= t, why go with UCL ? It is not orthogonal, it is not transnational, and e= diting the config files directly would result in the same old human error= s which bite as all from time to time. > > 5. It is my opinion that Solaris addressed some of those issue. Solaris= FMRI and SMF are lightyears ahead of the very tired models we keep using= on BSDs. Why not build on the insight offered by those (or even on the i= nsight offered by Windows :P) , then inventing more adhoc solutions and a= d-hoc databases, which do not address the real issues we have , like bina= ry code reuse, service management issues, lack of a system wide publishe= d -subscriber bus ( not kdbus :P ) fault detection and reaction, fault re= porting, all much needed parts of a modern OS. > > And now thee questions > > 1. Why lib XO ? Why burden the OS for some corner cases where it may be= useful ? > > 2. Was there any real talk on how to bring FreeBSD up to speed regardin= g those issues ? A period of research on what exists, on what can be don= e , and ensure important things are not showed in background and replaced= with yet another ad-hoc config database which lacks modern features ? > From where I am standing, this could be a project spawning multiple ye= ars , but it would be well worth it, and in my opinion it would be also w= orthy of > the freeSBD foundation sponsorship for several years in a row. The feat= ures I touched upon became very important parts of oder OSes, and rightly= so. > > Note: > > this message is serious and it is not intended to start flame wars, rel= igious crusades, or offend anyone. > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" --=20 Yonas Yanfa In Love With Open Source Drupal :: GitHub=20 :: Mozilla=20 :: iPhone=20 fizk.net | yonas@fizk.net From owner-freebsd-current@freebsd.org Sun Nov 15 13:34:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07491A2F50A for ; Sun, 15 Nov 2015 13:34:51 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id DE38E1626; Sun, 15 Nov 2015 13:34:50 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5B501C4; Sun, 15 Nov 2015 13:34:51 +0000 (UTC) Date: Sun, 15 Nov 2015 13:34:48 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bapt@FreeBSD.org, mav@FreeBSD.org, trasz@FreeBSD.org, ngie@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1680900047.1.1447594491008.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD - Build #3530 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:34:51 -0000 FreeBSD_HEAD - Build #3530 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3530/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3530/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3530/console Change summaries: 290857 by trasz: Speed up rctl operation with large rulesets, by holding the lock during iteration instead of relocking it for each traversed rule. Reviewed by:=09mjg@ MFC after:=091 month Sponsored by:=09The FreeBSD Foundation Differential Revision:=09https://reviews.freebsd.org/D4110 290856 by bapt: also skip the definition of ':fopen_regular' to avoid the build to fail due= to unused variables defined by ATF macros 290855 by mav: Increase reset assertion time from 10 to 100us. On my own tests I see no effect from this change, but I also can't reproduce the reported problem in general. PR:=09=09127391 PR:=09=09204554 Submitted by:=09satz@iranger.com MFC after:=092 weeks 290851 by ngie: Change WARNS to 2 across the board with all the libc testcases This effectively "reverts" r290846 MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 290850 by ngie: Cast xdr_void to xdrproc_t to mute -Wincompatible-pointer-types warnings fr= om clang This pattern is used in other areas of lib/libc/rpc MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 290849 by ngie: Fix -Wmissing-braces warnings by adding braces around all the testcase inputs MFC after: 1 week X-MFC with: r290572 Sponsored by: EMC / Isilon Storage Division 290848 by ngie: Fix -Wunused warnings MFC after: 1 week X-MFC with: r290572 Sponsored by: EMC / Isilon Storage Division 290847 by ngie: Fix -Wunused warnings with variables used unlit code by adding appropriate = #ifdef guards around the variables MFC after: 3 days Sponsored by: EMC / Isilon Storage Division 290846 by ngie: Bump WARNS to 2 MFC after: 1 week X-MFC with: r290532 Sponsored by: EMC / Isilon Storage Division 290845 by ngie: Remove unused variables; sort by alignment where needed MFC after: 1 week X-MFC with: r290532 Sponsored by: EMC / Isilon Storage Division 290844 by ngie: Polish up iswctype_test - Split up the testcases into C locale and ja_JP.eucJP testcases. - Avoid a segfault in the event that setlocale fails, similar to r290843 - Replace `sizeof(x) / sizeof(*x)` pattern with `nitems(x)` MFC after: 1 week X-MFC with: r290532 Sponsored by: EMC / Isilon Storage Division 290843 by ngie: Polish up the tests a bit more after projects/collation was merged to head Provide more meaningful diagnostic messages if LC_CTYPE can't be set proper= ly instead of segfaulting, because setlocale returns NULL and strcmp(NULL, b) = will always segfault Split up the testcases so one failing (in this case en_US.ISO8859-15) won't cause the rest of the testcases to be skipped Remove some unused variables MFC after: 1 week X-MFC with: r290532 Sponsored by: EMC / Isilon Storage Division 290842 by ngie: Fix the Indian numbering system (hi_IN.ISCII-DEV) tests Submitted by: ache X-MFC with: r290494 (if that ever happens) Sponsored by: EMC / Isilon Storage Division 290840 by ngie: Setup the symlink to /sys to mirror one's current source, e.g. if my source tree was /usr/src/svn, /sys would point to usr/src/svn This fixes the assumption that the source tree will always exist at ${DESTDIR}/usr/src MFC after: 1 week PR: 76362 Reported by: Scot Hetzel Sponsored by: EMC / Isilon Storage Division The end of the build log: [...truncated 137526 lines...] --- protoent_test --- echo '#! /usr/libexec/atf-sh' > protoent_test.tmp cat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/net/t_protoent.sh >>= protoent_test.tmp chmod +x protoent_test.tmp mv protoent_test.tmp protoent_test --- servent_test --- echo '#! /usr/libexec/atf-sh' > servent_test.tmp cat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/net/t_servent.sh >>s= ervent_test.tmp chmod +x servent_test.tmp mv servent_test.tmp servent_test --- Kyuafile.auto --- =3D=3D=3D> lib/libc/tests/regex (all) --- h_regex --- (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.h_re= gex NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/Makefi= le _RECURSING_PROGS=3D PROG=3Dh_regex ) --- main.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex = -I/builds/FreeBSD_HEAD/lib/libc/regex -MD -MP -MF.depend.h_regex.main.o -MT= main.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall= -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-= string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-u= nused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conver= sion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promot= ed-parameter -Qunused-arguments -c /builds/FreeBSD_HEAD/contrib/netbsd-test= s/lib/libc/regex/main.c -o main.o --- all_subdir_gnu --- --- frame-base.o --- cc -O2 -pipe -Dxregcomp=3Dregcomp -Dxre_exec=3Dre_exec -Dxregexec=3Dreg= exec -Dxre_search=3Dre_search -Dxre_compile_fastmap=3Dre_compile_fastmap -D= xregerror=3Dregerror -Dxre_comp=3Dre_comp -Dxre_set_syntax=3Dre_set_syntax = -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEBUGDIR=3D\"/usr/l= ib/debug\" -I. -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../arch/amd64 = -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd -I/buil= ds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd/amd64 -I/build= s/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb -I/builds= /FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/config -I/= builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/inc= lude -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/= include -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/b= inutils/bfd -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/= libgdb/../../../lib/libreadline/readline/.. -MD -MP -MF.depend.frame-base.o= -MTframe-base.o -std=3Dgnu99 -fstack-protector-strong -Qunused-arguments= -c /builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb= /frame-base.c -o frame-base.o --- all_subdir_kerberos5 --- --- get_cred.po --- cc -pg -O2 -pipe -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../../= crypto/heimdal/lib/krb5 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../..= /../crypto/heimdal/lib/asn1 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/.= ./../../crypto/heimdal/lib/roken -I/builds/FreeBSD_HEAD/kerberos5/lib/libk= rb5/../../../crypto/heimdal/lib/ipc -I/builds/FreeBSD_HEAD/kerberos5/lib/l= ibkrb5/../../../crypto/heimdal/base -I. -DHAVE_CONFIG_H -I/builds/FreeBSD_H= EAD/kerberos5/lib/libkrb5/../../include -MD -MP -MF.depend.get_cred.po -MTg= et_cred.po -std=3Dgnu99 -fstack-protector-strong -Qunused-arguments -c /b= uilds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/g= et_cred.c -o get_cred.po --- all_subdir_gnu --- --- frame-unwind.o --- cc -O2 -pipe -Dxregcomp=3Dregcomp -Dxre_exec=3Dre_exec -Dxregexec=3Dreg= exec -Dxre_search=3Dre_search -Dxre_compile_fastmap=3Dre_compile_fastmap -D= xregerror=3Dregerror -Dxre_comp=3Dre_comp -Dxre_set_syntax=3Dre_set_syntax = -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEBUGDIR=3D\"/usr/l= ib/debug\" -I. -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../arch/amd64 = -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd -I/buil= ds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd/amd64 -I/build= s/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb -I/builds= /FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/config -I/= builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/inc= lude -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/= include -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/b= inutils/bfd -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/= libgdb/../../../lib/libreadline/readline/.. -MD -MP -MF.depend.frame-unwind= .o -MTframe-unwind.o -std=3Dgnu99 -fstack-protector-strong -Qunused-argum= ents -c /builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb= /gdb/frame-unwind.c -o frame-unwind.o --- all_subdir_lib --- --- split.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex = -I/builds/FreeBSD_HEAD/lib/libc/regex -MD -MP -MF.depend.h_regex.split.o -M= Tsplit.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wa= ll -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wn= o-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno= -unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conv= ersion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-prom= oted-parameter -Qunused-arguments -c /builds/FreeBSD_HEAD/contrib/netbsd-te= sts/lib/libc/regex/split.c -o split.o --- debug.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex = -I/builds/FreeBSD_HEAD/lib/libc/regex -MD -MP -MF.depend.h_regex.debug.o -M= Tdebug.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wa= ll -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wn= o-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno= -unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conv= ersion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-prom= oted-parameter -Qunused-arguments -c /builds/FreeBSD_HEAD/contrib/netbsd-te= sts/lib/libc/regex/debug.c -o debug.o --- all_subdir_gnu --- --- frame.o --- cc -O2 -pipe -Dxregcomp=3Dregcomp -Dxre_exec=3Dre_exec -Dxregexec=3Dreg= exec -Dxre_search=3Dre_search -Dxre_compile_fastmap=3Dre_compile_fastmap -D= xregerror=3Dregerror -Dxre_comp=3Dre_comp -Dxre_set_syntax=3Dre_set_syntax = -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEBUGDIR=3D\"/usr/l= ib/debug\" -I. -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../arch/amd64 = -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd -I/buil= ds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd/amd64 -I/build= s/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb -I/builds= /FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/config -I/= builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/inc= lude -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/= include -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/b= inutils/bfd -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/= libgdb/../../../lib/libreadline/readline/.. -MD -MP -MF.depend.frame.o -MTf= rame.o -std=3Dgnu99 -fstack-protector-strong -Qunused-arguments -c /build= s/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/frame.c -= o frame.o --- all_subdir_rescue --- --- radix.o --- cc -O2 -pipe -DRESCUE -MD -MP -MF.depend.radix.o -MTradix.o -std=3Dgnu99= -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W= -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Qunused-arguments -c /builds/FreeBSD_HEAD/sbin/routed/r= adix.c -o radix.o --- all_subdir_lib --- --- h_regex --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex -I/= builds/FreeBSD_HEAD/lib/libc/regex -std=3Dgnu99 -fstack-protector-strong -W= system-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointe= r-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno= -tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unus= ed-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno= -switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o h_regex mai= n.o split.o debug.o =20 --- exhaust_test --- (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.exha= ust_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/M= akefile _RECURSING_PROGS=3D PROG=3Dexhaust_test ) --- t_exhaust.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex = -DREGEX_SPENCER -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD= /contrib/netbsd-tests -MD -MP -MF.depend.exhaust_test.t_exhaust.o -MTt_exha= ust.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall = -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-s= tring-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-un= used-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-convers= ion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promote= d-parameter -Qunused-arguments -c /builds/FreeBSD_HEAD/contrib/netbsd-tests= /lib/libc/regex/t_exhaust.c -o t_exhaust.o --- exhaust_test --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex -DR= EGEX_SPENCER -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD/co= ntrib/netbsd-tests -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -= Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empt= y-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-co= mpare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno= -enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wn= o-knr-promoted-parameter -Qunused-arguments -L/builds/FreeBSD_HEAD/obj/bui= lds/FreeBSD_HEAD//lib/libnetbsd -o exhaust_test t_exhaust.o -lnetbsd -lpri= vateatf-c --- regex_att_test --- (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.rege= x_att_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex= /Makefile _RECURSING_PROGS=3D PROG=3Dregex_att_test ) --- t_regex_att.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex = -DREGEX_SPENCER -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD= /contrib/netbsd-tests -MD -MP -MF.depend.regex_att_test.t_regex_att.o -MTt_= regex_att.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror = -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -= Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-c= onversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Qunused-arguments -c /builds/FreeBSD_HEAD/contrib/netbsd= -tests/lib/libc/regex/t_regex_att.c -o t_regex_att.o --- all_subdir_rescue --- --- rdisc.o --- cc -O2 -pipe -DRESCUE -MD -MP -MF.depend.rdisc.o -MTrdisc.o -std=3Dgnu99= -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W= -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Qunused-arguments -c /builds/FreeBSD_HEAD/sbin/routed/r= disc.c -o rdisc.o --- all_subdir_kerberos5 --- --- get_default_principal.po --- cc -pg -O2 -pipe -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../../= crypto/heimdal/lib/krb5 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../..= /../crypto/heimdal/lib/asn1 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/.= ./../../crypto/heimdal/lib/roken -I/builds/FreeBSD_HEAD/kerberos5/lib/libk= rb5/../../../crypto/heimdal/lib/ipc -I/builds/FreeBSD_HEAD/kerberos5/lib/l= ibkrb5/../../../crypto/heimdal/base -I. -DHAVE_CONFIG_H -I/builds/FreeBSD_H= EAD/kerberos5/lib/libkrb5/../../include -MD -MP -MF.depend.get_default_prin= cipal.po -MTget_default_principal.po -std=3Dgnu99 -fstack-protector-strong = -Qunused-arguments -c /builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../..= /crypto/heimdal/lib/krb5/get_default_principal.c -o get_default_principal.p= o --- all_subdir_lib --- --- regex_att_test --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex -DR= EGEX_SPENCER -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD/co= ntrib/netbsd-tests -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -= Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empt= y-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-co= mpare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno= -enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wn= o-knr-promoted-parameter -Qunused-arguments -L/builds/FreeBSD_HEAD/obj/bui= lds/FreeBSD_HEAD//lib/libnetbsd -o regex_att_test t_regex_att.o -lnetbsd -= lutil -lprivateatf-c --- regex_test --- echo '#! /usr/libexec/atf-sh' > regex_test.tmp cat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/t_regex.sh >>r= egex_test.tmp --- all_subdir_gnu --- --- gdb-events.o --- cc -O2 -pipe -Dxregcomp=3Dregcomp -Dxre_exec=3Dre_exec -Dxregexec=3Dreg= exec -Dxre_search=3Dre_search -Dxre_compile_fastmap=3Dre_compile_fastmap -D= xregerror=3Dregerror -Dxre_comp=3Dre_comp -Dxre_set_syntax=3Dre_set_syntax = -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEBUGDIR=3D\"/usr/l= ib/debug\" -I. -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../arch/amd64 = -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd -I/buil= ds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd/amd64 -I/build= s/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb -I/builds= /FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/config -I/= builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/inc= lude -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/= include -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/b= inutils/bfd -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/= libgdb/../../../lib/libreadline/readline/.. -MD -MP -MF.depend.gdb-events.o= -MTgdb-events.o -std=3Dgnu99 -fstack-protector-strong -Qunused-arguments= -c /builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb= /gdb-events.c -o gdb-events.o --- all_subdir_lib --- chmod +x regex_test.tmp mv regex_test.tmp regex_test --- Kyuafile.auto --- =3D=3D=3D> lib/libc/tests/rpc (all) --- rpc_test --- (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.rpc_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Drpc_test ) --- t_rpc.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/lib/libc/tes= ts/rpc -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD/contrib/= netbsd-tests -MD -MP -MF.depend.rpc_test.t_rpc.o -MTt_rpc.o -std=3Dgnu99 -f= stack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-= uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-u= nused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-paren= theses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local= -typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-= arguments -c /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/rpc/t_rpc.c= -o t_rpc.o --- all_subdir_kerberos5 --- --- get_default_realm.po --- cc -pg -O2 -pipe -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../../= crypto/heimdal/lib/krb5 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../..= /../crypto/heimdal/lib/asn1 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/.= ./../../crypto/heimdal/lib/roken -I/builds/FreeBSD_HEAD/kerberos5/lib/libk= rb5/../../../crypto/heimdal/lib/ipc -I/builds/FreeBSD_HEAD/kerberos5/lib/l= ibkrb5/../../../crypto/heimdal/base -I. -DHAVE_CONFIG_H -I/builds/FreeBSD_H= EAD/kerberos5/lib/libkrb5/../../include -MD -MP -MF.depend.get_default_real= m.po -MTget_default_realm.po -std=3Dgnu99 -fstack-protector-strong -Qunus= ed-arguments -c /builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../../crypto/= heimdal/lib/krb5/get_default_realm.c -o get_default_realm.po --- all_subdir_gnu --- /builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/gdb= -events.c:367:15: warning: enumeration value 'nr_gdb_events' not handled in= switch [-Wswitch] switch (event->type) ^ --- all_subdir_rescue --- --- table.o --- cc -O2 -pipe -DRESCUE -MD -MP -MF.depend.table.o -MTtable.o -std=3Dgnu99= -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W= -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Qunused-arguments -c /builds/FreeBSD_HEAD/sbin/routed/t= able.c -o table.o --- all_subdir_lib --- --- rpc_test --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/lib/libc/tests/= rpc -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD/contrib/net= bsd-tests -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -W= all -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wn= o-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-con= version -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -Qunused-arguments -L/builds/FreeBSD_HEAD/obj/builds/FreeB= SD_HEAD//lib/libnetbsd -o rpc_test t_rpc.o -lrpcsvc -lutil -lnetbsd -lpriv= ateatf-c --- all_subdir_gnu --- 1 warning generated. --- gdbarch.o --- cc -O2 -pipe -Dxregcomp=3Dregcomp -Dxre_exec=3Dre_exec -Dxregexec=3Dreg= exec -Dxre_search=3Dre_search -Dxre_compile_fastmap=3Dre_compile_fastmap -D= xregerror=3Dregerror -Dxre_comp=3Dre_comp -Dxre_set_syntax=3Dre_set_syntax = -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEBUGDIR=3D\"/usr/l= ib/debug\" -I. -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../arch/amd64 = -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd -I/buil= ds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd/amd64 -I/build= s/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb -I/builds= /FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/config -I/= builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/inc= lude -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/= include -I/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/b= inutils/bfd -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/gnu/usr.bin/gdb/= libgdb/../../../lib/libreadline/readline/.. -MD -MP -MF.depend.gdbarch.o -M= Tgdbarch.o -std=3Dgnu99 -fstack-protector-strong -Qunused-arguments -c /b= uilds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/gdbar= ch.c -o gdbarch.o --- all_subdir_lib --- --- xdr_test --- (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.xdr_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Dxdr_test ) --- t_xdr.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/lib/libc/tes= ts/rpc -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD/contrib/= netbsd-tests -MD -MP -MF.depend.xdr_test.t_xdr.o -MTt_xdr.o -std=3Dgnu99 -f= stack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-= uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-u= nused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-paren= theses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local= -typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-= arguments -c /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/rpc/t_xdr.c= -o t_xdr.o --- h_testbits_xdr.o --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/lib/libc/tes= ts/rpc -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD/contrib/= netbsd-tests -MD -MP -MF.depend.xdr_test.h_testbits_xdr.o -MTh_testbits_xdr= .o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wn= o-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-stri= ng-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unuse= d-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion= -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-p= arameter -Qunused-arguments -c h_testbits_xdr.c -o h_testbits_xdr.o --- all_subdir_kerberos5 --- --- get_for_creds.po --- cc -pg -O2 -pipe -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../../= crypto/heimdal/lib/krb5 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../..= /../crypto/heimdal/lib/asn1 -I/builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/.= ./../../crypto/heimdal/lib/roken -I/builds/FreeBSD_HEAD/kerberos5/lib/libk= rb5/../../../crypto/heimdal/lib/ipc -I/builds/FreeBSD_HEAD/kerberos5/lib/l= ibkrb5/../../../crypto/heimdal/base -I. -DHAVE_CONFIG_H -I/builds/FreeBSD_H= EAD/kerberos5/lib/libkrb5/../../include -MD -MP -MF.depend.get_for_creds.po= -MTget_for_creds.po -std=3Dgnu99 -fstack-protector-strong -Qunused-argum= ents -c /builds/FreeBSD_HEAD/kerberos5/lib/libkrb5/../../../crypto/heimdal/= lib/krb5/get_for_creds.c -o get_for_creds.po --- all_subdir_lib --- --- xdr_test --- cc -O2 -pipe -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/lib/libc/tests/= rpc -I/builds/FreeBSD_HEAD/lib/libnetbsd -I/builds/FreeBSD_HEAD/contrib/net= bsd-tests -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -W= all -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wn= o-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-con= version -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -Qunused-arguments -L/builds/FreeBSD_HEAD/obj/builds/FreeB= SD_HEAD//lib/libnetbsd -o xdr_test h_testbits_xdr.o t_xdr.o -lrpcsvc -luti= l -lnetbsd -lprivateatf-c --- Kyuafile.auto --- =3D=3D=3D> lib/libc/tests/stdio (all) --- fdopen_test --- (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fdop= en_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfdopen_test ) --- fdopen_test.o --- cc -O2 -pipe -MD -MP -MF.depend.fdopen_test.fdopen_test.o -MTfdopen_test= .o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wn= o-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-stri= ng-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unuse= d-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion= -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-p= arameter -Qunused-arguments -c /builds/FreeBSD_HEAD/lib/libc/tests/stdio/fd= open_test.c -o fdopen_test.o --- fdopen_test --- cc -O2 -pipe -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror= -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-= conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -o fdopen_test fdopen_test.o -lpriv= ateatf-c --- fmemopen2_test --- (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fmem= open2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio= /Makefile _RECURSING_PROGS=3D PROG=3Dfmemopen2_test ) --- fmemopen2_test.o --- cc -O2 -pipe -MD -MP -MF.depend.fmemopen2_test.fmemopen2_test.o -MTfmemo= pen2_test.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror = -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -= Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-c= onversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Qunused-arguments -c /builds/FreeBSD_HEAD/lib/libc/tests= /stdio/fmemopen2_test.c -o fmemopen2_test.o /builds/FreeBSD_HEAD/lib/libc/tests/stdio/fmemopen2_test.c:108:7: error: un= used variable 'str' [-Werror,-Wunused-variable] char str[] =3D "A quick test"; ^ /builds/FreeBSD_HEAD/lib/libc/tests/stdio/fmemopen2_test.c:111:15: error: u= nused variable 'nofr' [-Werror,-Wunused-variable] size_t nofw, nofr, i; ^ 2 errors generated. *** [fmemopen2_test.o] Error code 1 make[7]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio 1 error make[7]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** [fmemopen2_test] Error code 2 make[6]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio 1 error make[6]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** [all] Error code 2 make[5]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests 1 error make[5]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests *** [all] Error code 2 make[4]: stopped in /builds/FreeBSD_HEAD/lib/libc 1 error make[4]: stopped in /builds/FreeBSD_HEAD/lib/libc --- all_subdir_rescue --- A failure has been detected in another branch of the parallel make make[6]: stopped in /builds/FreeBSD_HEAD/sbin/routed *** [routed_make] Error code 2 make[5]: stopped in /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/rescue/res= cue 1 error make[5]: stopped in /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/rescue/res= cue *** [objs] Error code 2 make[4]: stopped in /builds/FreeBSD_HEAD/rescue/rescue 1 error make[4]: stopped in /builds/FreeBSD_HEAD/rescue/rescue *** [all] Error code 2 make[3]: stopped in /builds/FreeBSD_HEAD/rescue 1 error make[3]: stopped in /builds/FreeBSD_HEAD/rescue --- all_subdir_kerberos5 --- A failure has been detected in another branch of the parallel make make[5]: stopped in /builds/FreeBSD_HEAD/kerberos5/lib/libkrb5 --- all_subdir_lib --- *** [all_subdir_libc] Error code 2 make[3]: stopped in /builds/FreeBSD_HEAD/lib 1 error make[3]: stopped in /builds/FreeBSD_HEAD/lib --- all_subdir_rescue --- *** [all_subdir_rescue] Error code 2 make[2]: stopped in /builds/FreeBSD_HEAD --- all_subdir_kerberos5 --- *** [all] Error code 2 make[4]: stopped in /builds/FreeBSD_HEAD/kerberos5/lib 1 error make[4]: stopped in /builds/FreeBSD_HEAD/kerberos5/lib --- all_subdir_lib --- *** [all_subdir_lib] Error code 2 make[2]: stopped in /builds/FreeBSD_HEAD --- all_subdir_kerberos5 --- *** [all_subdir_lib] Error code 2 make[3]: stopped in /builds/FreeBSD_HEAD/kerberos5 1 error make[3]: stopped in /builds/FreeBSD_HEAD/kerberos5 *** [all_subdir_kerberos5] Error code 2 make[2]: stopped in /builds/FreeBSD_HEAD --- all_subdir_gnu --- A failure has been detected in another branch of the parallel make make[6]: stopped in /builds/FreeBSD_HEAD/gnu/usr.bin/gdb/libgdb *** [all] Error code 2 make[5]: stopped in /builds/FreeBSD_HEAD/gnu/usr.bin/gdb 1 error make[5]: stopped in /builds/FreeBSD_HEAD/gnu/usr.bin/gdb *** [all_subdir_gdb] Error code 2 make[4]: stopped in /builds/FreeBSD_HEAD/gnu/usr.bin 1 error make[4]: stopped in /builds/FreeBSD_HEAD/gnu/usr.bin *** [all_subdir_usr.bin] Error code 2 make[3]: stopped in /builds/FreeBSD_HEAD/gnu 1 error make[3]: stopped in /builds/FreeBSD_HEAD/gnu *** [all_subdir_gnu] Error code 2 make[2]: stopped in /builds/FreeBSD_HEAD 4 errors make[2]: stopped in /builds/FreeBSD_HEAD *** [everything] Error code 2 make[1]: stopped in /builds/FreeBSD_HEAD 1 error make[1]: stopped in /builds/FreeBSD_HEAD *** [buildworld] Error code 2 make: stopped in /builds/FreeBSD_HEAD 1 error make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Sun Nov 15 13:03:43 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6ED3A27BAE; Sun, 15 Nov 2015 13:03:43 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B73E1061; Sun, 15 Nov 2015 13:03:42 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id A9D1A43BB2; Sun, 15 Nov 2015 07:03:34 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Andrey Chernov , Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino Message-ID: <564882A3.7060109@marino.st> Date: Sun, 15 Nov 2015 14:03:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <564880FA.5000009@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2015 13:36:29 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:03:43 -0000 On 11/15/2015 1:56 PM, Andrey Chernov wrote: > On 15.11.2015 15:46, Baptiste Daroussin wrote: >> On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: >>> On 15.11.2015 10:09, John Marino wrote: >>> ISO8859-1 locales are legacy even if obsoleted in modern world (I agree >>> with that). Lots of ports (even at configure stage!) have checks for >>> them. Since we generate locales from CLDR now, it will be no cost to >>> bring all 8859-1 back to not violate POLA and not fix every failing port. >>> >> Exp-run have been made and no ports were failing with the removed locales. > > There is soft-fail, configure just marks that locales are not supported > and use "C". Sorry I don't remember port names where I saw it right now > and don't have a time to search for them right now too. Soft-fails (like > in tcl with nl_langinfo) are almost impossible to detect excepting > specific situation happens or source code inspection. Do we ever need > them when there is no harm to keep 8859-1 locales? > Well, there is "harm". The -1/-15 confusion happens a lot. Is the plan to keep every locale ever created for ever and ever? Never do any kind of kind of cleanup or reorg? This is not really any kind of problem. Update the regression test and nobody will even notice after that in all liklihood. John From owner-freebsd-current@freebsd.org Sun Nov 15 13:38:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55983A2F62B for ; Sun, 15 Nov 2015 13:38:52 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 774DF19C7 for ; Sun, 15 Nov 2015 13:38:50 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 78332 invoked from network); 15 Nov 2015 13:38:48 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Nov 2015 13:38:48 -0000 Date: Sun, 15 Nov 2015 14:38:48 +0100 (CET) Message-Id: <20151115.143848.41679525.sthaug@nethelp.no> To: bapt@freebsd.org Cc: ache@freebsd.org, dragonflybsd@marino.st, yaneurabeya@gmail.com, rodrigc@FreeBSD.org, freebsd-current@freebsd.org, testing@freebsd.org Subject: Re: Need help fixing failing locale tests From: sthaug@nethelp.no In-Reply-To: <20151115130009.GC93991@ivaldir.etoilebsd.net> References: <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <20151115130009.GC93991@ivaldir.etoilebsd.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:38:52 -0000 > > There is soft-fail, configure just marks that locales are not supported > > and use "C". Sorry I don't remember port names where I saw it right now > > and don't have a time to search for them right now too. Soft-fails (like > > in tcl with nl_langinfo) are almost impossible to detect excepting > > specific situation happens or source code inspection. Do we ever need > > them when there is no harm to keep 8859-1 locales? > > Is it ok if I readd those locales as aliases on 8859-15? Why on earth would you want to do that when we can have the real thing? I still see no good reason for dropping 8859-1. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@freebsd.org Sun Nov 15 13:54:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B798EA2F983; Sun, 15 Nov 2015 13:54:26 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7125D10B6; Sun, 15 Nov 2015 13:54:26 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 9DAAD43BB2; Sun, 15 Nov 2015 07:54:23 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Andrey Chernov , marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: John Marino X-Enigmail-Draft-Status: N1110 Message-ID: <56488E8C.9080901@marino.st> Date: Sun, 15 Nov 2015 14:54:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <56488A76.1090502@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:54:26 -0000 On 11/15/2015 2:36 PM, Andrey Chernov wrote: > On 15.11.2015 16:14, John Marino wrote: >>> It is user confusion and his responsibility. It not leads to wrong >>> program build f.e. Moreover, you can't protect users who set 8859-1 that >>> way, they do not convert to 8859-15 as you assume but start to complain >>> everywhere that FreeBSD is not working instead. >> >> Invalid. "locale -a" shows what locales are available. >> The confusion is not with one user. It's with one user that produces >> document in one encoding and a second user that choses the wrong one >> (usually -1). -15 was designed to replace -1. > > No end-user use 'locale -a' to check locales. To quote you, that means it "user confusion and responsibility". Fine. He can "ls -d /usr/share/locales". Otherwise, how does said user set locales for the FIRST time. We are talking about people that install FreeBSD 11 as a release. If it's an upgrade, it's documented in UPDATING (it will be) and anybody on -CURRENT is taking responsibility for knowing what they are doing. *IF* this is an obstacle, it's either trivial or that user shouldn't be using -CURRENT to begin with. > An end-user keep some > 8859-1 version is set many years ago, and "FreeBSD not working" problem > I tell about is not different text document encoding, but program > failure due to inability to set his 8859-1 locale. Please provide an example of such a program (in ports). > In any case it is related to the user behavior an various views on it. > They can be different and I see no point to insist on my particular view > at all. But... Programs configure soft-fails shows real danger here. and the impact of this is ... ? > >> OpenBSD removed ISO8859* completely. > > OpenBSD was never good in locales in any case for all that years and > contributes nothing in that area (f.e. Citrus was made by NetBSD). Now > they try to simplify their life of supporting them, but since for us now > all locales are autogenerated from CLDR I see no room for simplification > in that way. Our "cleaned" locales (against to POLA) can be restored by > autogeneration with minimal efforts, and they even took very little disk > space. It's not a technical issue. -1 (and some -15) weren't removed for technical issues, but to keep order. >> Also invalid. Locales are not standardized with regard to encoding, so >> maintaining a museum of locales is specific to FreeBSD. Linux calls >> them differently. > > Most of our (old) locales have the same names as linux ones. Actually, none of the ISO* encodings. Linux will accept "ISO8859-1" because it's hyphen-insensitive, it it calls it "ISO-8859-1" Maybe obsolete ones like cp866, GB2312 ... but there are more different than the same. John From owner-freebsd-current@freebsd.org Sun Nov 15 14:01:02 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25384A2FAFA for ; Sun, 15 Nov 2015 14:01:02 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95B291364 for ; Sun, 15 Nov 2015 14:01:01 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbblt2 with SMTP id lt2so75872261lbb.3 for ; Sun, 15 Nov 2015 06:00:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ZMNU3217hrkV/GOttC06+8YQJwHUfnybxk+jw8K90Hc=; b=FE6ITusozsBLOvCwJkdS3tRq/7thddv+LoE2jwQ+msh+zzvZ0Bm+bMBvazx7tPUdsZ fbgPg4QjOVXwY7jFGbPAdoebnAbFEzXfox6Yuii0hi1iDTOQpeLTOsOO8rydBSXeq3++ 5+BbogtlpnMh9Ir2rX20PCCJgx+JwaIx30qXZPBoRjdXITzEv3k9M/9/TyXzxXdQtlnW RgAjghntuf+qe5AzW3Ju5VMn8POXrDF13ibmaH1K3/xLW42ARjltd9rmqaxxcklgNHGB ajnbz8KW4dLVj/Nq7jzPvkveGnCOJIgTC7TbeK8VruBzrSFyTY90Y4HQnvCdXik1oAxp ZKTA== X-Gm-Message-State: ALoCoQnACj+ynZsdueAzwLzHLoRWnXItXDppnTyk+YfoizOHtoVRnD3T6nUnZkDmdhD1NeTvsGz5 X-Received: by 10.112.180.131 with SMTP id do3mr14515966lbc.123.1447594615521; Sun, 15 Nov 2015 05:36:55 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id m80sm4772904lfm.15.2015.11.15.05.36.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 05:36:54 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov X-Enigmail-Draft-Status: N1110 Message-ID: <56488A76.1090502@freebsd.org> Date: Sun, 15 Nov 2015 16:36:54 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5648853F.2050901@marino.st> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 14:01:02 -0000 On 15.11.2015 16:14, John Marino wrote: >> It is user confusion and his responsibility. It not leads to wrong >> program build f.e. Moreover, you can't protect users who set 8859-1 that >> way, they do not convert to 8859-15 as you assume but start to complain >> everywhere that FreeBSD is not working instead. > > Invalid. "locale -a" shows what locales are available. > The confusion is not with one user. It's with one user that produces > document in one encoding and a second user that choses the wrong one > (usually -1). -15 was designed to replace -1. No end-user use 'locale -a' to check locales. An end-user keep some 8859-1 version is set many years ago, and "FreeBSD not working" problem I tell about is not different text document encoding, but program failure due to inability to set his 8859-1 locale. In any case it is related to the user behavior an various views on it. They can be different and I see no point to insist on my particular view at all. But... Programs configure soft-fails shows real danger here. > OpenBSD removed ISO8859* completely. OpenBSD was never good in locales in any case for all that years and contributes nothing in that area (f.e. Citrus was made by NetBSD). Now they try to simplify their life of supporting them, but since for us now all locales are autogenerated from CLDR I see no room for simplification in that way. Our "cleaned" locales (against to POLA) can be restored by autogeneration with minimal efforts, and they even took very little disk space. > Also invalid. Locales are not standardized with regard to encoding, so > maintaining a museum of locales is specific to FreeBSD. Linux calls > them differently. Most of our (old) locales have the same names as linux ones. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 13:08:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 408E8A27CD3; Sun, 15 Nov 2015 13:08:15 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F7771270; Sun, 15 Nov 2015 13:08:14 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 5E1E943BB2; Sun, 15 Nov 2015 07:08:12 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Andrey Chernov , Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <20151115130009.GC93991@ivaldir.etoilebsd.net> <564882E1.5050404@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino Message-ID: <564883B8.1060500@marino.st> Date: Sun, 15 Nov 2015 14:08:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <564882E1.5050404@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2015 14:05:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:08:15 -0000 On 11/15/2015 2:04 PM, Andrey Chernov wrote: > On 15.11.2015 16:00, Baptiste Daroussin wrote: >> On Sun, Nov 15, 2015 at 03:56:26PM +0300, Andrey Chernov wrote: >>> On 15.11.2015 15:46, Baptiste Daroussin wrote: >>>> On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: >>>>> On 15.11.2015 10:09, John Marino wrote: >>>>> ISO8859-1 locales are legacy even if obsoleted in modern world (I agree >>>>> with that). Lots of ports (even at configure stage!) have checks for >>>>> them. Since we generate locales from CLDR now, it will be no cost to >>>>> bring all 8859-1 back to not violate POLA and not fix every failing port. >>>>> >>>> Exp-run have been made and no ports were failing with the removed locales. >>> >>> There is soft-fail, configure just marks that locales are not supported >>> and use "C". Sorry I don't remember port names where I saw it right now >>> and don't have a time to search for them right now too. Soft-fails (like >>> in tcl with nl_langinfo) are almost impossible to detect excepting >>> specific situation happens or source code inspection. Do we ever need >>> them when there is no harm to keep 8859-1 locales? >> >> Is it ok if I readd those locales as aliases on 8859-15? > > It is hacking solution leads to wrong collating order and character > classes. It is better to generate true 8859-1 just in the same way you > already do for 8859-15. > > BTW, I can't check right now, but in case 8859-5 is removed too, it is > better to restore it, it was used in Suns as their standard Russian > encoding. > DragonFly: muscles# locale -a | grep 8859-5 uk_UA.ISO8859-5 be_BY.ISO8859-5 ru_RU.ISO8859-5 sr_Cyrl_RS.ISO8859-5 I agree that if -1 is brought back, it needs to be changed at the charset.xml level. At that point FreeBSD and DragonFly will diverge. I also agree using ports as justification for keeping -1 in western europe is invalid (as in, it's not causing problems in ports) John From owner-freebsd-current@freebsd.org Sun Nov 15 13:14:46 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51D1FA27FF0; Sun, 15 Nov 2015 13:14:46 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24C7C1A7C; Sun, 15 Nov 2015 13:14:45 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 9BB3C43BB2; Sun, 15 Nov 2015 07:14:42 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Andrey Chernov , marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino Message-ID: <5648853F.2050901@marino.st> Date: Sun, 15 Nov 2015 14:14:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <5648842E.3050203@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2015 14:05:29 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 13:14:46 -0000 On 11/15/2015 2:10 PM, Andrey Chernov wrote: >> Well, there is "harm". The -1/-15 confusion happens a lot. > > It is user confusion and his responsibility. It not leads to wrong > program build f.e. Moreover, you can't protect users who set 8859-1 that > way, they do not convert to 8859-15 as you assume but start to complain > everywhere that FreeBSD is not working instead. Invalid. "locale -a" shows what locales are available. The confusion is not with one user. It's with one user that produces document in one encoding and a second user that choses the wrong one (usually -1). -15 was designed to replace -1. OpenBSD removed ISO8859* completely. > >> Is the plan to keep every locale ever created for ever and ever? Never >> do any kind of kind of cleanup or reorg? > > It will be nice to do it that way. FreeBSD have a little part of world > locales, which indirectly assumes that they are really used. Also invalid. Locales are not standardized with regard to encoding, so maintaining a museum of locales is specific to FreeBSD. Linux calls them differently. John From owner-freebsd-current@freebsd.org Sun Nov 15 14:39:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3595DA2F2ED for ; Sun, 15 Nov 2015 14:39:51 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE1BE1A85 for ; Sun, 15 Nov 2015 14:39:50 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbcs9 with SMTP id cs9so75671005lbb.1 for ; Sun, 15 Nov 2015 06:39:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=N+/qrDhwqMSxblTFFZCVrUXzdiCabyNu+M3NcvUp4xQ=; b=V96vgKDaFv5F54QBpbw7Lvir18al3vHx7NVLJN8cnYLA8CMu6UAEEZBO7agJJCcRMY 3mzuMPFhZa1y27FfI3adoh8c90ZT8SQmtK15kcRTUnSVO47cHg8H8fpzdYB+ysys2Pvv vpdNwX9ut/BeKnyfNFabmQHOXE9v1r+jCY8Vh+cBgVQ5tVUg4vnl9545GCe7XLkoD6LX LHiayhnjd3+ENnouJslmxP1LInZ1TK73hi9syYe2+DC+/F0lR8xAFUQ+faG/Q9fcMDT+ YeezZn/n6Ie1gwBJBpre1jhHVb5vJxkwKAviqqxyd2Vb2Uckn3v3UOUegDLNU5DlIfUt ne5Q== X-Gm-Message-State: ALoCoQmUJoEna0x3sTrCosGSuQPkpODLXtuLW/Gumq81BoeMyy7qLh6sRjsTeYZX5z/9A3E8Ptos X-Received: by 10.112.39.5 with SMTP id l5mr1309893lbk.101.1447598388677; Sun, 15 Nov 2015 06:39:48 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id g193sm4810753lfb.6.2015.11.15.06.39.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 06:39:47 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: John Marino , marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov X-Enigmail-Draft-Status: N1110 Message-ID: <56489932.1080504@freebsd.org> Date: Sun, 15 Nov 2015 17:39:46 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56488E8C.9080901@marino.st> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 14:39:51 -0000 On 15.11.2015 16:54, John Marino wrote: > We are talking about people that install FreeBSD 11 as a release. If > it's an upgrade, it's documented in UPDATING (it will be) and anybody on > -CURRENT is taking responsibility for knowing what they are doing. *IF* > this is an obstacle, it's either trivial or that user shouldn't be using > -CURRENT to begin with. As I already say, I don't want to insist on any particular point of view in such area as human behavior. I just say that it is POLA violation (even while it is upgrade) and we can let users decide by themselves, what it best for them (without me at least). >> I tell about is not different text document encoding, but program >> failure due to inability to set his 8859-1 locale. > > Please provide an example of such a program (in ports). See gettext-0.19.6/gettext-tools/configure, part started with # Test for the usual locale name. I don't have time to dig more such code now, but I remember I saw more for sure. >> In any case it is related to the user behavior an various views on it. >> They can be different and I see no point to insist on my particular view >> at all. But... Programs configure soft-fails shows real danger here. > > and the impact of this is ... ? Various. It depends on for what reason program sense locale. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 14:59:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A1FCA2F7AF for ; Sun, 15 Nov 2015 14:59:10 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 101D912C6 for ; Sun, 15 Nov 2015 14:59:09 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lffu14 with SMTP id u14so74426887lff.1 for ; Sun, 15 Nov 2015 06:59:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8r3MIDVD3s6KpobvK42ZB9F6QMikNUZK6n77N0LqOKU=; b=S5ahObdRx0OmitGCJr5Oc6E6nFcNsWx+VtvO0P00JtEWm+4lxEm4dKgcPLZYA1XjRM RbV8596Y6V0aAViCkJdqosnsbwXQA0iQ+Ho800JbGYKiXVbNJa9DgMu75zVeCw5tDH6C eBYGOeSHLlskjoN2cYeTnd8SO6W84Rl3JwLkCYPlyEFHBWBxdKJ/CDG+eqk6n7E6cBF0 TCMypANiaGYrd5+E+AX0IR95mwPeZlyqYroxO8RpTntbVS3V9L0Mov5v+qS7SXXm+rPP dcJenwqAG1yvU2gGJ+ZIV7xp4EQ2+gc8TYneRLjCpF6GdENfOye5PB4p2DMi1pPk0Z3D RCtw== X-Gm-Message-State: ALoCoQnox99rnUI6y/uxFcZhl7Xf/f2e1expo4EyPamKNB82h6X0Ex2A/oUxeEx96hml/k3RTJQn X-Received: by 10.25.29.129 with SMTP id d123mr14883715lfd.4.1447599542365; Sun, 15 Nov 2015 06:59:02 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id 64sm4818105lfu.35.2015.11.15.06.59.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 06:59:01 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> <56489AEA.4060100@marino.st> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <56489DB4.5050000@freebsd.org> Date: Sun, 15 Nov 2015 17:59:00 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56489AEA.4060100@marino.st> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 14:59:10 -0000 On 15.11.2015 17:47, John Marino wrote: >>> Please provide an example of such a program (in ports). >> >> See gettext-0.19.6/gettext-tools/configure, part started with >> # Test for the usual locale name. >> I don't have time to dig more such code now, but I remember I saw more >> for sure. > If the ports framework is not overriding locale to "C" during the build > then that's probably something that should be introduced. Ports should > not be producing different results based on the configuration of the > building machine at the time. This is not about resetting locale to "C" during the build. Please really look at "configure" specific part mentioned above, it is you who ask at least one specific example and then it is you who ignore the answer takes my time to find it. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 15:01:29 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEBADA2F90B; Sun, 15 Nov 2015 15:01:28 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D0ED15BF; Sun, 15 Nov 2015 15:01:28 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmeo63 with SMTP id o63so18951418wme.2; Sun, 15 Nov 2015 07:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=TsvWtpzMkeXatdqk2PqsxVZGWdzuAhmK9PJCeHikABU=; b=OvWxX4dgMxvG2AMKO9Zed7n3ZIvU3Qxn+x1o7trHD7mMhkwwGx7MlbkKWwbBQ2iMJX /jd4EI+2GFdWcP8Bt1Gero7xLkRigT1GV7+Htq7m08rzlBsttzstMBbYlSZuW1iuPfZ4 3JXhZSNnY3j9JpHa5qV3enHoLfJoW6W2iiA9NcQZgovFhEXXvkh0m10YWY0zbXnSX3+p RRULYAiRaIBjL4YQ1NFRSjNd90P719JCHGmP/B1g22lK8qv2BC1mdl2KJzvd56TxfvKo HoarKO2c72ywEceviqTbymFzxVIasF4fiEpplnc11i1iWZGDsdq98a3BxR4ndIozr059 zsHg== X-Received: by 10.28.4.212 with SMTP id 203mr14871407wme.89.1447599687006; Sun, 15 Nov 2015 07:01:27 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id q6sm9248061wmd.8.2015.11.15.07.01.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 07:01:26 -0800 (PST) Sender: Baptiste Daroussin Date: Sun, 15 Nov 2015 16:01:24 +0100 From: Baptiste Daroussin To: Andrey Chernov Cc: John Marino , NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Subject: Re: Need help fixing failing locale tests Message-ID: <20151115150124.GE93991@ivaldir.etoilebsd.net> References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <20151115130009.GC93991@ivaldir.etoilebsd.net> <564882E1.5050404@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OZkY3AIuv2LYvjdk" Content-Disposition: inline In-Reply-To: <564882E1.5050404@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:01:29 -0000 --OZkY3AIuv2LYvjdk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2015 at 04:04:33PM +0300, Andrey Chernov wrote: > On 15.11.2015 16:00, Baptiste Daroussin wrote: > > On Sun, Nov 15, 2015 at 03:56:26PM +0300, Andrey Chernov wrote: > >> On 15.11.2015 15:46, Baptiste Daroussin wrote: > >>> On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: > >>>> On 15.11.2015 10:09, John Marino wrote: > >>>> ISO8859-1 locales are legacy even if obsoleted in modern world (I ag= ree > >>>> with that). Lots of ports (even at configure stage!) have checks for > >>>> them. Since we generate locales from CLDR now, it will be no cost to > >>>> bring all 8859-1 back to not violate POLA and not fix every failing = port. > >>>> > >>> Exp-run have been made and no ports were failing with the removed loc= ales. > >> > >> There is soft-fail, configure just marks that locales are not supported > >> and use "C". Sorry I don't remember port names where I saw it right now > >> and don't have a time to search for them right now too. Soft-fails (li= ke > >> in tcl with nl_langinfo) are almost impossible to detect excepting > >> specific situation happens or source code inspection. Do we ever need > >> them when there is no harm to keep 8859-1 locales? > >=20 > > Is it ok if I readd those locales as aliases on 8859-15? >=20 > It is hacking solution leads to wrong collating order and character > classes. It is better to generate true 8859-1 just in the same way you > already do for 8859-15. >=20 > BTW, I can't check right now, but in case 8859-5 is removed too, it is > better to restore it, it was used in Suns as their standard Russian > encoding. >=20 I have restored the 8859-1 The 8859-5 were never removed: be_BY.ISO8859-5 ru_RU.ISO8859-5 sr_Cyrl_RS.ISO8859-5 uk_UA.ISO8859-5 Best regards, Bapt --OZkY3AIuv2LYvjdk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZInkQACgkQ8kTtMUmk6Ex91wCgt+K0f8xPqxx7i0lLWXHBtrUI m70AnR2oSLlWYzm2dQi+31fHlxKkSq8l =D2Lo -----END PGP SIGNATURE----- --OZkY3AIuv2LYvjdk-- From owner-freebsd-current@freebsd.org Sun Nov 15 15:05:06 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2587EA2F9BE for ; Sun, 15 Nov 2015 15:05:06 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C508618DF for ; Sun, 15 Nov 2015 15:05:05 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lfaz4 with SMTP id z4so10920828lfa.0 for ; Sun, 15 Nov 2015 07:05:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=K9RUq5GuKR5F0g5iN22bZ7NWxm53p+IWuzzHGblWAI0=; b=Uz8RO3HJEK3LVLcKjZCMqJaD7XvnHuLZdyGFsEA0Jwf/Xkf7dvO+FpK4Eh0mUTvXz4 xQwa10Ef6AvidIH/xzkrADKFuWpgaYODd2U35AOyrrTjm7m/PtYCWAPM54HYgAOPE7r/ E79qu8FSTuwADNvmfylX7qYMRbECEO9IPX190EYiIr2FAsZ8B7Bh9Yos5/DF1MnTsk2V e0CmlRBb9ReDWRmqFKGQEsvvQTJ+mC9KO2y49x+vBU8thSFHzwGSfbWEf6Rk0lEjr9hc +DhQqgDjLGuV9siJE1RIZfshKtiAUMxW4IGReG2wAZlY0cX+bEIGd+SNXYRIk9yI/GpZ F04g== X-Gm-Message-State: ALoCoQlS4KXiHoiBeiosmE0JOzTsThx+FfRDYIymQ+dV4vpUeFceffmpgWd5OosAK3Vh+h9QSANl X-Received: by 10.25.149.9 with SMTP id x9mr8479607lfd.53.1447599903811; Sun, 15 Nov 2015 07:05:03 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id f189sm4825119lfe.19.2015.11.15.07.05.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 07:05:02 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <20151115130009.GC93991@ivaldir.etoilebsd.net> <564882E1.5050404@freebsd.org> <20151115150124.GE93991@ivaldir.etoilebsd.net> Cc: John Marino , NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <56489F1E.6090401@freebsd.org> Date: Sun, 15 Nov 2015 18:05:02 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151115150124.GE93991@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rn0bCf8tMfbxH0cdT4JxtpWekrb1fROBB" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:05:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rn0bCf8tMfbxH0cdT4JxtpWekrb1fROBB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15.11.2015 18:01, Baptiste Daroussin wrote: > I have restored the 8859-1 Thanx! BTW, speaking with John I find at least one configure script from ports which depends on 8859-1 presence. See gettext-0.19.6/gettext-tools/configure, part started with # Test for the usual locale name. --=20 http://ache.vniz.net/ --rn0bCf8tMfbxH0cdT4JxtpWekrb1fROBB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWSJ8eAAoJEKUckv0MjfbK1VQIANaUwgfOkqrJwczrwI4ui2gm y9eoXBAhViUO0qOrRsd8eNOl0+Y9riZIpMfk+TCcQLRhAOne+g40k/5cFaM0rOEI 6XoprFhWnZi8pB2Gde9z8r63M7q7zKOEqGFzP4WORaf6ospRfHsmIVkmpqgYbPRd j4mOrX6JLqmPOzJ1omebbShkaUjmstQuUIGthpAs2/kFR/cAq6kHUQk1vnOD4HGe Ljv/YKOlQBHm33o/jYmWkwSxmvsXZCWLmNW4jCSAG3WGyLzBFZMoFouBGxGEczCC dozeYbCYgE5R43/wp6PKNqTzCiVOkFmj82/TCcVyOV/ldYeRh2hspDQ75Hu/qiM= =epUF -----END PGP SIGNATURE----- --rn0bCf8tMfbxH0cdT4JxtpWekrb1fROBB-- From owner-freebsd-current@freebsd.org Sun Nov 15 15:38:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9EA6A2F106 for ; Sun, 15 Nov 2015 15:38:09 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FC7319AD for ; Sun, 15 Nov 2015 15:38:09 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbsy6 with SMTP id sy6so47454802lbb.2 for ; Sun, 15 Nov 2015 07:38:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=G/NCCaxV+AcH1npFoixvj5OhkqDtxnMBIOk1hIpxqM4=; b=HldEWbEsiPU0emUpfDINCFnRjy25jYYeT49osZCjohRthOZIYnIcwtCFiKucxd4upu P8/0ljmWNcX5ZPeh22P7Nh5MmMT4tA5H/8xFSORXtp1B3iDzh7Ci4GXZH0h92rO/VG1n arUPXECr+vf3WfZoISUeB0afCh8jyKDvgfNWJxOPt5KKMcNih2rEzvEZT/jCFiRcP/uR oqhUyACedowWE5uOT997Tl85+Zkp4Um9bdHNbnN0U87oJe4bcBbiY4oeu7detRFDoXt3 XyNwgUkyjHsaRm4bpjBEAVW56M5xNmP7sKV8a1GOq/Ll7f9VE+LyOiRIgLloCE0VjKPA G2Mg== X-Gm-Message-State: ALoCoQl6e0J7wEVeqwZgY1q6onWbAyu2be6pfLXmDWGst8JNFBiHrAlRhP14AhrOfN/7OEJHiqyw X-Received: by 10.112.198.69 with SMTP id ja5mr15452749lbc.106.1447601887378; Sun, 15 Nov 2015 07:38:07 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id t204sm4840170lfd.41.2015.11.15.07.38.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 07:38:06 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> <56489AEA.4060100@marino.st> <56489DB4.5050000@freebsd.org> <5648A211.40703@marino.st> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov X-Enigmail-Draft-Status: N1110 Message-ID: <5648A6DD.8020507@freebsd.org> Date: Sun, 15 Nov 2015 18:38:05 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5648A211.40703@marino.st> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:38:10 -0000 On 15.11.2015 18:17, John Marino wrote: >>>> See gettext-0.19.6/gettext-tools/configure, part started with >>>> # Test for the usual locale name. >>>> I don't have time to dig more such code now, but I remember I saw more >>>> for sure. > Of course it's the same topic. > If the configure of a port is affected by the locale, that's a big > problem. How is this not the same topic? This is environment problem, not presence or absence of some locales in the system (f.e. 8859-1 ones) we talked about. And can be easily fixed in the environment, unlike configure's silent script fallbacks, which can be fixed by recompiling only. About environment problem, we already have LANG=C somewhere in the /usr/ports/Mk/* (probably not in every place) and many ports set LANG=C or LC_ALL by themselves. > But I did look at gettext, which is configuring package based on what's > on the system (not environment). For the unicode checks, there is > obviously no issue. > > For the traditional checks, It's ironic, DragonFly uses short locales > like "fr_FR" which link to the approprioprate ISO8859 or UTF-8 locale. > Bapt removed them to avoid a bike shed and if he had not done that, this > gettext configure would not be an issue as "fr_FR" is the very first check. All parts are optional excepting language itself, so fr_FR is not short enough, but fr is. From POSIX: language[_territory][.codeset][@modifier] But I dislike short locales due to their uncertainty and remember some programs and shell scripts that attempts to parse locale name directly by itself for reasons I don't remember now. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 14:47:13 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D89AAA2F578; Sun, 15 Nov 2015 14:47:13 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A92A91E88; Sun, 15 Nov 2015 14:47:12 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 8825443BB2; Sun, 15 Nov 2015 08:47:09 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Andrey Chernov , Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino X-Enigmail-Draft-Status: N1110 Message-ID: <56489AEA.4060100@marino.st> Date: Sun, 15 Nov 2015 15:47:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <56489932.1080504@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2015 15:40:19 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 14:47:13 -0000 On 11/15/2015 3:39 PM, Andrey Chernov wrote: > As I already say, I don't want to insist on any particular point of view > in such area as human behavior. I just say that it is POLA violation > (even while it is upgrade) and we can let users decide by themselves, > what it best for them (without me at least). I am starting to think "POLA" as an acronym is subject to abuse. By this definition, *any* change would "astonish" a user (picturing the most incompetent user impossible too). POLA is meant for unreasonable and unexplained changes. I don't think tidying up locales for the first time in a decade is unreasonable or unexplained. Let's not dilute "POLA". It's pretty good but you can apply it to anything. >>> I tell about is not different text document encoding, but program >>> failure due to inability to set his 8859-1 locale. >> >> Please provide an example of such a program (in ports). > > See gettext-0.19.6/gettext-tools/configure, part started with > # Test for the usual locale name. > I don't have time to dig more such code now, but I remember I saw more > for sure. > >>> In any case it is related to the user behavior an various views on it. >>> They can be different and I see no point to insist on my particular view >>> at all. But... Programs configure soft-fails shows real danger here. >> >> and the impact of this is ... ? > > Various. It depends on for what reason program sense locale. If the ports framework is not overriding locale to "C" during the build then that's probably something that should be introduced. Ports should not be producing different results based on the configuration of the building machine at the time. Right? It's also good practice because C/POSIX never results in illegal sequence errors while locales such as UTF-8 easily can. John From owner-freebsd-current@freebsd.org Sun Nov 15 15:45:29 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC696A2F390 for ; Sun, 15 Nov 2015 15:45:29 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6987B1F7D for ; Sun, 15 Nov 2015 15:45:29 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbkw15 with SMTP id kw15so76310622lbb.0 for ; Sun, 15 Nov 2015 07:45:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=vzZ1Qe9gy3bT9ksmf766FC3PNVN4QIwf5VIYDHd6voU=; b=G4IT3ShBn+FbRdnUy2HApMatABPnIQrv8flwqz0WTJlRwauheY68fvJxt2xCOo/ah0 SKuJeprI3jqAqk+Ik562M2mF49U05Ky2Be3bl0zPPjGC4Q/LP3xlbAaLxH6CUhkIGKXy PU5rD3x2GHuBNZ3UnFHlKWmbC7zbUsvxeySKAVV/0Emg20OaH1IEmzm+mhgh1/JBxTKK DmC717lCHZ8sBOf4OX4dDhclebKkW2Ib/AJyI5+Ul7NsXeKIZeKg+guiuSVJE8C1gaGW fOmq6lkR+dFhWoYrmzWe7YceyPY487KDeW6mBdSX/8ySf5LbjG01jdoEa97Gx7ZYx/mD l8hA== X-Gm-Message-State: ALoCoQkOyWsQ3dBPQYXyOpdARyH6ciHKzEgWMAoRNBZZv/neVYYRMYxTnP0f0RL/GyGGpzZ45ipb X-Received: by 10.112.42.41 with SMTP id k9mr14720405lbl.63.1447602327099; Sun, 15 Nov 2015 07:45:27 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id l67sm4844095lfd.43.2015.11.15.07.45.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 07:45:25 -0800 (PST) Subject: Re: Need help fixing failing locale tests To: marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> <56489AEA.4060100@marino.st> <56489DB4.5050000@freebsd.org> <5648A211.40703@marino.st> <5648A6DD.8020507@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" From: Andrey Chernov Message-ID: <5648A895.2000407@freebsd.org> Date: Sun, 15 Nov 2015 18:45:25 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5648A6DD.8020507@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:45:29 -0000 On 15.11.2015 18:38, Andrey Chernov wrote: >> For the traditional checks, It's ironic, DragonFly uses short locales >> like "fr_FR" which link to the approprioprate ISO8859 or UTF-8 locale. >> Bapt removed them to avoid a bike shed and if he had not done that, this >> gettext configure would not be an issue as "fr_FR" is the very first check. > > But I dislike short locales due to their uncertainty And gettext-0.19.6/gettext-tools/configure is good example of that uncertainty. If DragonFly short locale fr_FR links to 8859-1, configure test does what it is intended, but if it links to UTF-8 it does not. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 15:54:46 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65CCEA2F65B for ; Sun, 15 Nov 2015 15:54:46 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 223C113C8 for ; Sun, 15 Nov 2015 15:54:45 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: (qmail 26622 invoked by uid 99); 15 Nov 2015 15:54:45 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 15 Nov 2015 15:54:45 +0000 Received: from [192.168.0.103] (unknown [181.55.232.163]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 5EB381A006D for ; Sun, 15 Nov 2015 15:54:43 +0000 (UTC) From: Pedro Giffuni Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Need help fixing failing locale tests Message-Id: Date: Sun, 15 Nov 2015 10:54:40 -0500 To: FreeBSD Current list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:54:46 -0000 FWIW; While I personally don=E2=80=99t use it, Latin is the official language = for the Holy See [1]. I think it is still taught in schools in Italy for = cultural reasons and because it=E2=80=99s supposed to make easier to learn other =E2=80=9Cromance=E2=80=9D languages. It shouldn't hurt to keep it but I have no strong opinion. Pedro. [1] https://en.wikipedia.org/wiki/Holy_See= From owner-freebsd-current@freebsd.org Sun Nov 15 16:11:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A13CEA2FABD; Sun, 15 Nov 2015 16:11:00 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52F2A1E40; Sun, 15 Nov 2015 16:10:59 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9967D28473; Sun, 15 Nov 2015 17:10:51 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B404728430; Sun, 15 Nov 2015 17:10:50 +0100 (CET) Message-ID: <5648AE8A.1010204@quip.cz> Date: Sun, 15 Nov 2015 17:10:50 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: marino@freebsd.org, Andrey Chernov , Baptiste Daroussin CC: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Subject: Re: Need help fixing failing locale tests References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> <56489AEA.4060100@marino.st> In-Reply-To: <56489AEA.4060100@marino.st> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 16:11:00 -0000 John Marino wrote on 11/15/2015 15:47: > On 11/15/2015 3:39 PM, Andrey Chernov wrote: >> As I already say, I don't want to insist on any particular point of view >> in such area as human behavior. I just say that it is POLA violation >> (even while it is upgrade) and we can let users decide by themselves, >> what it best for them (without me at least). > > I am starting to think "POLA" as an acronym is subject to abuse. By > this definition, *any* change would "astonish" a user (picturing the > most incompetent user impossible too). > > POLA is meant for unreasonable and unexplained changes. I don't think > tidying up locales for the first time in a decade is unreasonable or > unexplained. > > Let's not dilute "POLA". It's pretty good but you can apply it to anything. I agree. Everytime FreeBSD is changing something in the base, there are voices with "POLA". Removing Perl from base, removing BIND from base... these were more significant changes than changing something in locales. Miroslav Lachman From owner-freebsd-current@freebsd.org Sun Nov 15 16:18:35 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63B01A2FC8C; Sun, 15 Nov 2015 16:18:35 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 289F21121; Sun, 15 Nov 2015 16:18:35 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by pacej9 with SMTP id ej9so42013201pac.2; Sun, 15 Nov 2015 08:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=EXL0EEwBvsekrk3nO7vmjB4yuyjSt7ggOGoFtcaPkQc=; b=c45MLgukdCKkURBqsnqi0XCIbPwDKUQVc/Z6ro7qcBuyrBbFrm8bUUoLkbAFQtJzI1 +eRxqexpMFFG1ArPkgAw2E7F9GABfrttYzI3fs2no9kmxVPK9kOCUhWBo5S5p+s8QxAL ZXNxcavyJH+S+0M+IP+YI2B8VTqlFxfRDI4gm/Zg7VjDPzmKlg7wy+QdmGAm8YVFMwfX d1Q29mxLyxLp2VMPZVluyyLjIQ54jVJmcTgB0OXZHLkpulErzIO83CgTvu8ImL3+rI/1 bvk6WTey4YZZRERVwALCgNNj1ONCL3IVbmqQoAUEHeQmTSzQtD2UP9XlbAlvoRXf6Axw brHQ== X-Received: by 10.66.219.163 with SMTP id pp3mr46882608pac.55.1447604314395; Sun, 15 Nov 2015 08:18:34 -0800 (PST) Received: from [172.16.0.16] (ip68-8-104-248.sd.sd.cox.net. [68.8.104.248]) by smtp.gmail.com with ESMTPSA id by6sm31455777pab.25.2015.11.15.08.18.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 08:18:33 -0800 (PST) Subject: Re: Need help fixing failing locale tests Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7CAF4B03-C629-4CDC-BDCD-6D36260C4255"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Mitchell In-Reply-To: <5648AE8A.1010204@quip.cz> Date: Sun, 15 Nov 2015 08:18:30 -0800 Cc: marino@freebsd.org, Andrey Chernov , Baptiste Daroussin , NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Message-Id: <870CD01A-5816-4AE3-B8F5-5194637601C7@gmail.com> References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> <56489AEA.4060100@marino.st> <5648AE8A.1010204@quip.cz> To: Miroslav Lachman <000.fbsd@quip.cz> X-Mailer: Apple Mail (2.3096.5) X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 16:18:35 -0000 --Apple-Mail=_7CAF4B03-C629-4CDC-BDCD-6D36260C4255 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Documentation on any existing regressions and how they are expected to fail would be a good thing=E2=80=A6 Change is necessary, but so is = modification of a regression to continue to pass (or fail) as expected. Demonstration of = the unit testing process can also be very beneficial. : mdm > On Nov 15, 2015, at 8:10 AM, Miroslav Lachman <000.fbsd@quip.cz> = wrote: >=20 >>> can --Apple-Mail=_7CAF4B03-C629-4CDC-BDCD-6D36260C4255 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBTwwggQkoAMCAQICEQCLUjEWBNkFL7+nGoIADd0kMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTUxMDExMDAwMDAwWhcNMTYx MDEwMjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJtbWl0Y2hlbEBnbWFpbC5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgmZRbZzEbBU8Tqp4y2cc5RtDC2lUN3M+iusnt9ut+yiFL k8eFvGCgY3jzwcN1Gyc5r3+oOremRenzow2HWDMF/CApgeQHIhbXOSYldStEsVj2fG3fCd4dYnRT jOLZfSKIjhvWI/2TCZHYcnuEkEUZUlaVTHdKXW+0bXeNduuvC18z+duA17JBANv+cMyMW0B1GTN9 7qq8aZyqSHKL382N/9d2597YsUjgFG3SWNL2CxJdE2+sto52YUPk1pvz7y55uDK9CKaeQ/3c9+XV 5xCkL0qvwdyujQ3/dMbw+EZOpTLsgmcZZ6sC2/JhjYHnyZOk2Dd5DFD2ShKiAS9M4F/rAgMBAAGj ggHwMIIB7DAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUHFSYWff2 Vmw0nO/SYKAAR3fl0QQwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGll bnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBY BggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0 aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au Y29tb2RvY2EuY29tMB0GA1UdEQQWMBSBEm1taXRjaGVsQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAX6zky1D6pHDzwQszmn8083LLezoCJAs9adk62Fk/YWdkQ8r4je6nZdylcsGoNt5a7A/6 MUmLMRgXqoW4pyxrjs8n+d8aank9B+cWQOMYo9xhrN0kXZavlx59YAf1u+XSCQtO1NyIXO7NqO1K 7t0ZOI5c6cq+PAfwlGk7bSzbSMo8cS+lF8REIuN68uEHYTojOjT1hn756Pg3iFjFC12Qy3B3mCE6 EwgB8M6AnmvK3aKVdhYq9ZaxmSNUHrtbiiaJSge2GvbB+Y+iquf+uQbi5+03NiL/d3/KpKp9M/ug gD0u9f+zvyqZLCS6Rx4P7Gmye2qERQ+Q5P5UAYqp/dm0kTGCA8YwggPCAgEBMIGxMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCLUjEWBNkFL7+nGoIADd0kMAkG BSsOAwIaBQCgggHpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTExNTE2MTgzMVowIwYJKoZIhvcNAQkEMRYEFHP4oJN2Dk/jbZ2LHw6RDGF4GuK7MIHCBgkrBgEE AYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AItSMRYE2QUvv6caggAN3SQwgcQGCyqGSIb3DQEJEAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCLUjEWBNkFL7+nGoIADd0kMA0GCSqGSIb3DQEB AQUABIIBAFt0YaVdx/5Tk8EEl91lHP6kNLB0CBzm431lwftuWEICJOBtYgxyF6oSbskQcUZ5Lh25 v3pTdj+jBIGiZMDVdWind96wSVyONqFeB8oZJos1/XYPtYG81uetBJS1oTMARpt700AYBTYknz2G lOHDCt+yMcRORDbe6ai7aL+HSlqcyBz2xX3zVc3uQt8DeLHNm3Ph3e4TahMMftym3AUGNIqNJFD1 ZfYbZC0ly5Noc94QTQJ66PwNK817ZeclCXZSjkl94kCVKjc96nN26vpOkISgqZQo+oD31TRFpFtc HZM+nyBWBPWPui4IUept+bXqguUdtEfu6HXeeR9tgXujcVwAAAAAAAA= --Apple-Mail=_7CAF4B03-C629-4CDC-BDCD-6D36260C4255-- From owner-freebsd-current@freebsd.org Sun Nov 15 16:50:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99A19A30341 for ; Sun, 15 Nov 2015 16:50:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8B11013A8; Sun, 15 Nov 2015 16:50:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DA4F4151; Sun, 15 Nov 2015 16:50:01 +0000 (UTC) Date: Sun, 15 Nov 2015 16:49:58 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bapt@FreeBSD.org, trasz@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <551220452.4.1447606201796.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1680900047.1.1447594491008.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1680900047.1.1447594491008.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD - Build #3531 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 16:50:01 -0000 FreeBSD_HEAD - Build #3531 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3531/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3531/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3531/console Change summaries: 290866 by bapt: Regenerate locales after readding ISO8859-1 for locales that have ISO8859-15 Requested by: arche 290865 by bapt: Generate in the FreeBSD keyword when generating the Makefiles 290864 by bapt: Add ISO8859-1 everywhere ISO8859-15 exists 290863 by bapt: Allow to generate the locale when the source directory is not /usr/src 290862 by bapt: Simplify a bit the aliases generation 290861 by trasz: Doh, commit in a wrong directory. Fix r290857. MFC after: 1 month Sponsored by: The FreeBSD Foundation 290860 by bapt: Remove unused variables to fix building world 290859 by bapt: Rework locale-links to not make symlinks on directories but symlinks on files The goal here is to make the upgrade seamless for users Add aliases for zh_HK Remove bad symlinks created by previous bad upgrade procedure. Complete ObsoleteFiles.inc with more locales that have been removed From owner-freebsd-current@freebsd.org Sun Nov 15 16:51:18 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08D79A30454 for ; Sun, 15 Nov 2015 16:51:18 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id EAE0E1798 for ; Sun, 15 Nov 2015 16:51:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5020B152 for ; Sun, 15 Nov 2015 16:51:18 +0000 (UTC) Date: Sun, 15 Nov 2015 16:51:18 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: freebsd-current@freebsd.org Message-ID: <739674687.5.1447606278322.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #2743 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 16:51:18 -0000 See ------------------------------------------ [...truncated 3362 lines...] -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> =3D=3D=3D> lib/libc/tests (install) install -o root -g wheel -m 444 Kyuafile.auto =3D=3D=3D> lib/libc/tests/tls_dso (install) install -C -o root -g wheel -m 444 libh_tls_dynamic.a install -C -o root -g wheel -m 444 libh_tls_dynamic_p.a install -s -o root -g wheel -m 444 libh_tls_dynamic.so.1 install -l s libh_tls_dynamic.so.1 =3D=3D=3D> lib/libc/tests/c063 (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.facce= ssat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dfaccessat_test install) install -s -o root -g wheel -m 555 faccessat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fchmo= dat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfchmodat_test install) install -s -o root -g wheel -m 555 fchmodat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fchow= nat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfchownat_test install) install -s -o root -g wheel -m 555 fchownat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fexec= ve_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dfexecve_test install) install -s -o root -g wheel -m 555 fexecve_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fstat= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dfstatat_test install) install -s -o root -g wheel -m 555 fstatat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.linka= t_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Make= file _RECURSING_PROGS=3D PROG=3Dlinkat_test install) install -s -o root -g wheel -m 555 linkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mkdir= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dmkdirat_test install) install -s -o root -g wheel -m 555 mkdirat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mkfif= oat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dmkfifoat_test install) install -s -o root -g wheel -m 555 mkfifoat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mknod= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dmknodat_test install) install -s -o root -g wheel -m 555 mknodat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.opena= t_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Make= file _RECURSING_PROGS=3D PROG=3Dopenat_test install) install -s -o root -g wheel -m 555 openat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.readl= inkat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/= Makefile _RECURSING_PROGS=3D PROG=3Dreadlinkat_test install) install -s -o root -g wheel -m 555 readlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.renam= eat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Drenameat_test install) install -s -o root -g wheel -m 555 renameat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.symli= nkat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dsymlinkat_test install) install -s -o root -g wheel -m 555 symlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.unlin= kat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dunlinkat_test install) install -s -o root -g wheel -m 555 unlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.utime= nsat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dutimensat_test install) install -s -o root -g wheel -m 555 utimensat_test =3D=3D=3D> lib/libc/tests/db (install) install -o root -g wheel -m 555 db_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/db/README (cd /builds/FreeBSD_HEAD/lib/libc/tests/db && DEPENDFILE=3D.depend.h_db N= O_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/db/Makefile _RECUR= SING_PROGS=3D PROG=3Dh_db install) install -s -o root -g wheel -m 555 h_db =3D=3D=3D> lib/libc/tests/gen (install) install -o root -g wheel -m 444 Kyuafile.auto =3D=3D=3D> lib/libc/tests/gen/execve (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/execve && DEPENDFILE=3D.depend= .execve_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen= /execve/Makefile _RECURSING_PROGS=3D PROG=3Dexecve_test install) install -s -o root -g wheel -m 555 execve_test =3D=3D=3D> lib/libc/tests/gen/posix_spawn (install) install -o root -g wheel -m 555 h_nonexec install -o root -g wheel -m 555 h_zero install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_fileactions NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/te= sts/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_fileactions ins= tall) install -s -o root -g wheel -m 555 h_fileactions (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_spawn NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/ge= n/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_spawn install) install -s -o root -g wheel -m 555 h_spawn (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_spawnattr NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/test= s/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_spawnattr install= ) install -s -o root -g wheel -m 555 h_spawnattr (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.fileactions_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc= /tests/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dfileactions_tes= t install) install -s -o root -g wheel -m 555 fileactions_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.spawn_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests= /gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dspawn_test install) install -s -o root -g wheel -m 555 spawn_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.spawnattr_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/t= ests/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dspawnattr_test i= nstall) install -s -o root -g wheel -m 555 spawnattr_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.arc4ra= ndom_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Darc4random_test install) install -s -o root -g wheel -m 555 arc4random_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fmtche= ck2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Mak= efile _RECURSING_PROGS=3D PROG=3Dfmtcheck2_test install) install -s -o root -g wheel -m 555 fmtcheck2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fmtmsg= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dfmtmsg_test install) install -s -o root -g wheel -m 555 fmtmsg_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fnmatc= h2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Dfnmatch2_test install) install -s -o root -g wheel -m 555 fnmatch2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpclas= sify2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dfpclassify2_test install) install -s -o root -g wheel -m 555 fpclassify2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ftw_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Dftw_test install) install -s -o root -g wheel -m 555 ftw_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.popen_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dpopen_test install) install -s -o root -g wheel -m 555 popen_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.posix_= spawn_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dposix_spawn_test install) install -s -o root -g wheel -m 555 posix_spawn_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.wordex= p_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dwordexp_test install) install -s -o root -g wheel -m 555 wordexp_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.alarm_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dalarm_test install) install -s -o root -g wheel -m 555 alarm_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.assert= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dassert_test install) install -s -o root -g wheel -m 555 assert_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.basedi= rname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dbasedirname_test install) install -s -o root -g wheel -m 555 basedirname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.dir_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Ddir_test install) install -s -o root -g wheel -m 555 dir_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.floatu= nditf_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dfloatunditf_test install) install -s -o root -g wheel -m 555 floatunditf_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fnmatc= h_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dfnmatch_test install) install -s -o root -g wheel -m 555 fnmatch_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpclas= sify_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfpclassify_test install) install -s -o root -g wheel -m 555 fpclassify_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpsetm= ask_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Mak= efile _RECURSING_PROGS=3D PROG=3Dfpsetmask_test install) install -s -o root -g wheel -m 555 fpsetmask_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpsetr= ound_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfpsetround_test install) install -s -o root -g wheel -m 555 fpsetround_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ftok_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dftok_test install) install -s -o root -g wheel -m 555 ftok_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.getcwd= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dgetcwd_test install) install -s -o root -g wheel -m 555 getcwd_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.getgre= nt_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Dgetgrent_test install) install -s -o root -g wheel -m 555 getgrent_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.glob_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dglob_test install) install -s -o root -g wheel -m 555 glob_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.humani= ze_number_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/g= en/Makefile _RECURSING_PROGS=3D PROG=3Dhumanize_number_test install) install -s -o root -g wheel -m 555 humanize_number_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.isnan_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Disnan_test install) install -s -o root -g wheel -m 555 isnan_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.nice_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dnice_test install) install -s -o root -g wheel -m 555 nice_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.pause_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dpause_test install) install -s -o root -g wheel -m 555 pause_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.raise_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Draise_test install) install -s -o root -g wheel -m 555 raise_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.realpa= th_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Drealpath_test install) install -s -o root -g wheel -m 555 realpath_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.setdom= ainname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen= /Makefile _RECURSING_PROGS=3D PROG=3Dsetdomainname_test install) install -s -o root -g wheel -m 555 setdomainname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.sethos= tname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dsethostname_test install) install -s -o root -g wheel -m 555 sethostname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.sleep_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dsleep_test install) install -s -o root -g wheel -m 555 sleep_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.syslog= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dsyslog_test install) install -s -o root -g wheel -m 555 syslog_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.time_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dtime_test install) install -s -o root -g wheel -m 555 time_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ttynam= e_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dttyname_test install) install -s -o root -g wheel -m 555 ttyname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.vis_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Dvis_test install) install -s -o root -g wheel -m 555 vis_test =3D=3D=3D> lib/libc/tests/hash (install) install -o root -g wheel -m 555 hash_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/hash/data/md5test-in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib= /libc/hash/data/md5test-out /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/l= ibc/hash/data/sha1test-in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/lib= c/hash/data/sha1test-out /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc= /hash/data/sha1test2-out (cd /builds/FreeBSD_HEAD/lib/libc/tests/hash && DEPENDFILE=3D.depend.h_has= h NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/hash/Makefile = _RECURSING_PROGS=3D PROG=3Dh_hash install) install -s -o root -g wheel -m 555 h_hash (cd /builds/FreeBSD_HEAD/lib/libc/tests/hash && DEPENDFILE=3D.depend.sha2_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/hash/Makefi= le _RECURSING_PROGS=3D PROG=3Dsha2_test install) install -s -o root -g wheel -m 555 sha2_test =3D=3D=3D> lib/libc/tests/inet (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/inet && DEPENDFILE=3D.depend.inet_= network_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/ine= t/Makefile _RECURSING_PROGS=3D PROG=3Dinet_network_test install) install -s -o root -g wheel -m 555 inet_network_test =3D=3D=3D> lib/libc/tests/net (install) install -o root -g wheel -m 555 nsdispatch_test install -o root -g wheel -m 555 protoent_test install -o root -g wheel -m 555 servent_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/net/hosts /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/net/r= esolv.conf (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_nsd_= recurse NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Make= file _RECURSING_PROGS=3D PROG=3Dh_nsd_recurse install) install -s -o root -g wheel -m 555 h_nsd_recurse (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_prot= oent NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefil= e _RECURSING_PROGS=3D PROG=3Dh_protoent install) install -s -o root -g wheel -m 555 h_protoent (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_serv= ent NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefile= _RECURSING_PROGS=3D PROG=3Dh_servent install) install -s -o root -g wheel -m 555 h_servent (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_dns_= server NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makef= ile _RECURSING_PROGS=3D PROG=3Dh_dns_server install) install -s -o root -g wheel -m 555 h_dns_server (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.ether_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefil= e _RECURSING_PROGS=3D PROG=3Dether_test install) install -s -o root -g wheel -m 555 ether_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.eui64_= aton_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Deui64_aton_test install) install -s -o root -g wheel -m 555 eui64_aton_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.eui64_= ntoa_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Deui64_ntoa_test install) install -s -o root -g wheel -m 555 eui64_ntoa_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.getpro= toent_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/M= akefile _RECURSING_PROGS=3D PROG=3Dgetprotoent_test install) install -s -o root -g wheel -m 555 getprotoent_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.ether_= aton_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Dether_aton_test install) install -s -o root -g wheel -m 555 ether_aton_test =3D=3D=3D> lib/libc/tests/regex (install) install -o root -g wheel -m 555 regex_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/regex/README /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/re= gex/data/anchor.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex= /data/backref.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/d= ata/basic.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/= bracket.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/c_= comments.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/c= omplex.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/err= or.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/meta.in= /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/nospec.in /b= uilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/paren.in /build= s/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/regress.in /builds/= FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_bounded.in /bui= lds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_multi.in /b= uilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_ordinary.= in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/startend.i= n /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/subexp.in /= builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/subtle.in /bui= lds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/word_bound.in /bu= ilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/zero.in /builds/= FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/basic.dat /builds= /FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/categorization.d= at /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/forced= assoc.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att= /leftassoc.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/dat= a/att/nullsubexpr.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/re= gex/data/att/repetition.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/l= ibc/regex/data/att/rightassoc.dat (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.h_re= gex NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/Makefi= le _RECURSING_PROGS=3D PROG=3Dh_regex install) install -s -o root -g wheel -m 555 h_regex (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.exha= ust_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/M= akefile _RECURSING_PROGS=3D PROG=3Dexhaust_test install) install -s -o root -g wheel -m 555 exhaust_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.rege= x_att_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex= /Makefile _RECURSING_PROGS=3D PROG=3Dregex_att_test install) install -s -o root -g wheel -m 555 regex_att_test =3D=3D=3D> lib/libc/tests/rpc (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.rpc_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Drpc_test install) install -s -o root -g wheel -m 555 rpc_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.xdr_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Dxdr_test install) install -s -o root -g wheel -m 555 xdr_test =3D=3D=3D> lib/libc/tests/stdio (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fdop= en_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfdopen_test install) install -s -o root -g wheel -m 555 fdopen_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fmem= open2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio= /Makefile _RECURSING_PROGS=3D PROG=3Dfmemopen2_test install) install -s -o root -g wheel -m 555 fmemopen2_test install: fmemopen2_test: No such file or directory *** Error code 71 Stop. make[8]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** Error code 1 Stop. make[7]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** Error code 1 Stop. make[6]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests *** Error code 1 Stop. make[5]: stopped in /builds/FreeBSD_HEAD/lib/libc *** Error code 1 Stop. make[4]: stopped in /builds/FreeBSD_HEAD/lib *** Error code 1 Stop. make[3]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[2]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@freebsd.org Sun Nov 15 17:02:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BB48A3066F for ; Sun, 15 Nov 2015 17:02:39 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C48371CAB for ; Sun, 15 Nov 2015 17:02:38 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 0E6FC12102; Sun, 15 Nov 2015 19:02:36 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <56488457.507@fizk.net> Date: Sun, 15 Nov 2015 19:02:35 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <92D16EF0-97C7-4954-8E5E-65162ED1A06A@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <56488457.507@fizk.net> To: Yonas Yanfa X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 17:02:39 -0000 I know about NexBSD, but, as I said in my original message, I am = interested on what happen in FreeBSD proper, and what issues=20 XOification tries to solve )and if any proper process was given to = solving the identified issues , instead of just adding XO because=20 it could be added. > On 15 Nov 2015, at 15:10, Yonas Yanfa wrote: >=20 > Hi Dan, >=20 > Sounds like you'd be interested in NextBSD: >=20 > https://en.wikipedia.org/wiki/NextBSD >=20 > Cheers, > Yonas >=20 >=20 >=20 >=20 > Yonas Yanfa > In Love With Open Source > Drupal :: GitHub = :: Mozilla = :: iPhone = > fizk.net | yonas@fizk.net >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Nov 15 17:05:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E592BA306FB for ; Sun, 15 Nov 2015 17:05:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B40241E0E for ; Sun, 15 Nov 2015 17:05:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofh3 with SMTP id h3so139816300iof.3 for ; Sun, 15 Nov 2015 09:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vN1Api3pGd5x1H2jnLmt08G0oQua+QJKH/R72/ZjQeE=; b=tqFWI40N4krOO+aKYAvrTZcMA/cKM2oxtSxr6ebVDhqdoQOab/7J+wMVklnOIjCLCE /hzj5Xi3HhJo8I8pq4RY/Fd6xfoTeJu1LrngYnk0lHEB/CHci3Uy9Wvs6ld8523tmKp/ sMnGghaDxU6h9v7m3+mCUklHxNvkLHu/wdzXjUJmtuhJdoevA+m9HPuKP328c6sUeamO wlGY4RHa780568eCa/TFCwtz7ydVcXH5ui1AcwDSVkO7qoR8148updFc21MadkoHM7mJ WElDzzuMC+pXdcN4KHNUJvx2LiUxR88dyjiPGwqypeRSGe175L1MBUQXBOP66qUwQ1xB jgrQ== MIME-Version: 1.0 X-Received: by 10.107.10.199 with SMTP id 68mr28284832iok.75.1447607156204; Sun, 15 Nov 2015 09:05:56 -0800 (PST) Received: by 10.36.217.196 with HTTP; Sun, 15 Nov 2015 09:05:56 -0800 (PST) In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Date: Sun, 15 Nov 2015 09:05:56 -0800 Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Adrian Chadd To: Dan Partelly Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 17:05:57 -0000 Hi, The reason is simple - someone offered to do the work and push it through. This isn't a commercial thing where we get to make project decisions and allocate resources - the juniper folk came up with a solution that they're using and willing to push forward in freebsd. It's been an interesting experiment and maybe it shouldn't have been done in -HEAD, but it isn't all that pervasive and we've gotten good feedback from it all. -adrian From owner-freebsd-current@freebsd.org Sun Nov 15 15:17:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B8A5A2FBAE; Sun, 15 Nov 2015 15:17:44 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 129B81D70; Sun, 15 Nov 2015 15:17:43 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 272BD43BA5; Sun, 15 Nov 2015 09:17:40 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Andrey Chernov , marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> <56489AEA.4060100@marino.st> <56489DB4.5050000@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino X-Enigmail-Draft-Status: N1110 Message-ID: <5648A211.40703@marino.st> Date: Sun, 15 Nov 2015 16:17:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <56489DB4.5050000@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2015 17:09:22 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:17:44 -0000 On 11/15/2015 3:59 PM, Andrey Chernov wrote: > On 15.11.2015 17:47, John Marino wrote: >>>> Please provide an example of such a program (in ports). >>> >>> See gettext-0.19.6/gettext-tools/configure, part started with >>> # Test for the usual locale name. >>> I don't have time to dig more such code now, but I remember I saw more >>> for sure. > >> If the ports framework is not overriding locale to "C" during the build >> then that's probably something that should be introduced. Ports should >> not be producing different results based on the configuration of the >> building machine at the time. > > This is not about resetting locale to "C" during the build. Please > really look at "configure" specific part mentioned above, it is you who > ask at least one specific example and then it is you who ignore the > answer takes my time to find it. Hmmm? Of course it's the same topic. If the configure of a port is affected by the locale, that's a big problem. How is this not the same topic? But I did look at gettext, which is configuring package based on what's on the system (not environment). For the unicode checks, there is obviously no issue. For the traditional checks, It's ironic, DragonFly uses short locales like "fr_FR" which link to the approprioprate ISO8859 or UTF-8 locale. Bapt removed them to avoid a bike shed and if he had not done that, this gettext configure would not be an issue as "fr_FR" is the very first check. John From owner-freebsd-current@freebsd.org Sun Nov 15 15:57:04 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C923EA2F79E; Sun, 15 Nov 2015 15:57:04 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9784F1782; Sun, 15 Nov 2015 15:57:04 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id A7DD943BA5; Sun, 15 Nov 2015 09:57:00 -0600 (CST) Subject: Re: Need help fixing failing locale tests To: Andrey Chernov , marino@freebsd.org, Baptiste Daroussin References: <69242BD8-9010-47F0-9706-BE206376ECEA@gmail.com> <289892B6-EACE-4BDA-B838-D3DC750319DE@gmail.com> <56482FA9.2010803@marino.st> <56487973.5070803@freebsd.org> <20151115124656.GB93991@ivaldir.etoilebsd.net> <564880FA.5000009@freebsd.org> <564882A3.7060109@marino.st> <5648842E.3050203@freebsd.org> <5648853F.2050901@marino.st> <56488A76.1090502@freebsd.org> <56488E8C.9080901@marino.st> <56489932.1080504@freebsd.org> <56489AEA.4060100@marino.st> <56489DB4.5050000@freebsd.org> <5648A211.40703@marino.st> <5648A6DD.8020507@freebsd.org> Cc: NGie Cooper , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" Reply-To: marino@freebsd.org From: John Marino Message-ID: <5648AB48.9070908@marino.st> Date: Sun, 15 Nov 2015 16:56:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <5648A6DD.8020507@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2015 17:09:37 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:57:04 -0000 On 11/15/2015 4:38 PM, Andrey Chernov wrote: > On 15.11.2015 18:17, John Marino wrote: >> >> For the traditional checks, It's ironic, DragonFly uses short locales >> like "fr_FR" which link to the approprioprate ISO8859 or UTF-8 locale. >> Bapt removed them to avoid a bike shed and if he had not done that, this >> gettext configure would not be an issue as "fr_FR" is the very first check. > > All parts are optional excepting language itself, so fr_FR is not short > enough, but fr is. From POSIX: > > language[_territory][.codeset][@modifier] "fr" (or "french") by itself isn't very useful, so IMO language_territory is the minimum. > But I dislike short locales due to their uncertainty and remember some > programs and shell scripts that attempts to parse locale name directly > by itself for reasons I don't remember now. Absolutely true about the uncertainty. It's just subjective. We did what we thought made sense but bapt recognized an impeding bikeshed and just did away with it. For some reason gettext-tools only cares about french and japanese (thus easily patched). Here's what it looks like on current DragonFly: http://muscles.dragonflybsd.org/bulk/bleeding-edge-potential/latest-per-pkg/gettext-tools-0.19.6.log Note the identified traditional french is "fr_FR" which maps to fr_FR.ISO8859-15 on DragonFly. It's a moot point now I guess. ISO8859-1 has returned to FreeBSD for western europe (probably forever). John From owner-freebsd-current@freebsd.org Sun Nov 15 17:10:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BB8FA3082C for ; Sun, 15 Nov 2015 17:10:36 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4321203 for ; Sun, 15 Nov 2015 17:10:35 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 08B941181B; Sun, 15 Nov 2015 19:10:35 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: Date: Sun, 15 Nov 2015 19:10:34 +0200 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> To: Adrian Chadd X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 17:10:36 -0000 Meaning, is that simple to push things in head , if somone does the = work, even with with no proper review of the problem at hand , and the = proposed solutions ?=20 > On 15 Nov 2015, at 19:05, Adrian Chadd wrote: >=20 > Hi, >=20 > The reason is simple - someone offered to do the work and push it = through. >=20 > This isn't a commercial thing where we get to make project decisions > and allocate resources - the juniper folk came up with a solution that > they're using and willing to push forward in freebsd. It's been an > interesting experiment and maybe it shouldn't have been done in -HEAD, > but it isn't all that pervasive and we've gotten good feedback from it > all. >=20 >=20 > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Nov 15 17:37:57 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 211EDA30E38 for ; Sun, 15 Nov 2015 17:37:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2E3A134B for ; Sun, 15 Nov 2015 17:37:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofh3 with SMTP id h3so140206193iof.3 for ; Sun, 15 Nov 2015 09:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MRCWGCYKTw5ljZiWQxhHWDQyUul+epFGXjAXk9Tm4nM=; b=AQF0RBbINrZlLBkXTZS7pHfFv0cvgquI61+cJa/CA3KKFtmDF6LfjRTweNWZ5rse+A jo8v3Hg0onjFdEjS27qbJtUuIb49ByaaAyX9qdk8oUfXdF7LNmOB/FN/Z3HhY7R2v9vi U9RGbu0EpgrRDjFLGSEnZDPDhDy21HPOn+o7acHB8CftDi9HgyzVQJ9UvkTSLy8q4jqD UvBQRlJI2HZ0vId5BIibM0VSO/HLHLeNJIkZJxNifZ2ta4+sxzrhRjD0Vq1Mw9RNPLDt Uld0vClcVOc4X0gNP+zyAIxtyeg5wem6MYiknIcselacBlraYxwrnzcks1VniQPEAWQX dOUQ== MIME-Version: 1.0 X-Received: by 10.107.162.21 with SMTP id l21mr1380326ioe.123.1447609075974; Sun, 15 Nov 2015 09:37:55 -0800 (PST) Received: by 10.36.217.196 with HTTP; Sun, 15 Nov 2015 09:37:55 -0800 (PST) In-Reply-To: <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> Date: Sun, 15 Nov 2015 09:37:55 -0800 Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Adrian Chadd To: Dan Partelly Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 17:37:57 -0000 On 15 November 2015 at 09:10, Dan Partelly wrote: > Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? Nope and yup. The juniper folk had a solution to a problem multiple people had requested work on, and their proposal was by far the furthest along code and use wise. It's all fine and good making technical decisions based on drawings and handwaving and philosophizing, but at some point someone has to do the code. Juniper's libxo was the furthest along in implementation and production. -a From owner-freebsd-current@freebsd.org Sun Nov 15 17:51:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EA6AA2F208 for ; Sun, 15 Nov 2015 17:51:11 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FB881A84 for ; Sun, 15 Nov 2015 17:51:11 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lfs39 with SMTP id 39so75534532lfs.3 for ; Sun, 15 Nov 2015 09:51:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pxEvm921RwOawvKMmKF6zNcpPXwWPIjmdzab8J4sNOk=; b=c5RwUsMPxV0hHGtjBtvL2Nir7ZOvjwNndwZQfhuiEBAVT+i3wuBnaeSdY79rYRwX2A uKSxjBRyZD6rZcaNTPY0gx8iN5/75Prxrc7+79S9XW9HvjKNkYPWJktCgKpfSab9cCuW K/QsZ+AFE3UXSTHs8bhQAG24r6HE6BfIkpBnhgtXrskLbDcvBGNHcv0hnt5FbY70YWu8 islj8yPIr3lb14QqyauxNYHC1m8QEBurbqDv7ulUBVQBqcBxUeyeEw06xyKyqCm6XY2Z fnAr5TEC4y54+v6dNjEb9BDvuf3swiCHREXWnXmSBHam3A/xTOgHkPZrrSiwe8LZP8w3 +rJA== X-Gm-Message-State: ALoCoQmy670ADcxShOARiy6OWheqqmm/FU0rmpArG3oIW6aNW576L2Wl+B0zHs0zojSi8maKBVVi X-Received: by 10.25.17.232 with SMTP id 101mr14676676lfr.38.1447609868976; Sun, 15 Nov 2015 09:51:08 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id d203sm1394787lfg.39.2015.11.15.09.51.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 09:51:07 -0800 (PST) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Adrian Chadd , Dan Partelly References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> Cc: freebsd-current From: Andrey Chernov Message-ID: <5648C60B.6060205@freebsd.org> Date: Sun, 15 Nov 2015 20:51:07 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 17:51:11 -0000 On 15.11.2015 20:37, Adrian Chadd wrote: > On 15 November 2015 at 09:10, Dan Partelly wrote: >> Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? > > Nope and yup. The juniper folk had a solution to a problem multiple > people had requested work on, and their proposal was by far the > furthest along code and use wise. > > It's all fine and good making technical decisions based on drawings > and handwaving and philosophizing, but at some point someone has to do > the code. Juniper's libxo was the furthest along in implementation and > production. It seems it is the only and final argument for libXO existence. I remember 2 or 3 discussions against libXO spontaneously happens in the FreeBSD lists, all ended with that, approximately: "we already have the code and you have just speculations". Alternative and more architecture clean ideas, like making standalone template-oriented parser probably based on liXO, are never seriously considered, because nobody will code it, not for other reasons. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Sun Nov 15 18:02:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADA09A2F42E for ; Sun, 15 Nov 2015 18:02:16 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2CF1FC4 for ; Sun, 15 Nov 2015 18:02:16 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6D396DBD5 for ; Sun, 15 Nov 2015 18:02:14 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Allan Jude X-Enigmail-Draft-Status: N1110 Message-ID: <5648C89C.2050206@freebsd.org> Date: Sun, 15 Nov 2015 13:02:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kk1cvSuaCKkPaDmsUvoFduAcNtcJtCPjl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:02:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kk1cvSuaCKkPaDmsUvoFduAcNtcJtCPjl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-15 07:54, Dan Partelly wrote: >=20 > Hi all, >=20 > I was looking at the new facility of dumping JSON,XML from many utils i= n base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: >=20 >=20 > 1. Undoubtedly, it makes base code slightly harder to understand and ma= intain.=20 > 2. I have seen the idea that this makes the information dumped by utili= ties in the base easily accessible programatically. OK, maybe it does , b= ut > it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I > dont see too many ppl changing their code to read JSON instead of text.= I don't even see the base tools changing. This output may be useful in = corner cases only. > 3. The integration of libxo IMO only points at a much deeper issue IMO.= It is only an expression of the need of a mechanism aimed at binary code= reuse. But it does not solve the problem, it only adds yet another possi= bility in a world where too much choices already result in too much split= s and incompatible APIs.=20 > 4. This whole effort would have been IMO much better served by porting= the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch like the libs for geom, zfs , etc , ready for reuse of 3rd party code.= Eventually writing network control daemons in time over it , much like s= olaris does. >=20 > 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the be= stiary of ad hoc databases already existing in BSDs ? Programatic readabi= lity, yes. but it does not add any real much needed functionality such as= *transactional databases* for system tools. Why not research a proper = solution - easily accessible by other programs ,orthogonal , transactiona= l, and ACL protected solution which can be used all over the place , f= rom OS boot, to ABI management, service management, network management, u= ser management. I hope this day will come, a day when I will not have to= edit a single config file manually, yet I would have access to all the c= onfig and system state easy with wrapper APIs. In the light of this poin= t, why go with UCL ? It is not orthogonal, it is not transnational, and e= diting the config files directly would result in the same old human error= s which bite as all from time to time. >=20 > 5. It is my opinion that Solaris addressed some of those issue. Solaris= FMRI and SMF are lightyears ahead of the very tired models we keep using= on BSDs. Why not build on the insight offered by those (or even on the i= nsight offered by Windows :P) , then inventing more adhoc solutions and a= d-hoc databases, which do not address the real issues we have , like bina= ry code reuse, service management issues, lack of a system wide publishe= d -subscriber bus ( not kdbus :P ) fault detection and reaction, fault re= porting, all much needed parts of a modern OS.=20 >=20 > And now thee questions >=20 > 1. Why lib XO ? Why burden the OS for some corner cases where it may be= useful ? >=20 > 2. Was there any real talk on how to bring FreeBSD up to speed regardin= g those issues ? A period of research on what exists, on what can be don= e , and ensure important things are not showed in background and replaced= with yet another ad-hoc config database which lacks modern features ? > From where I am standing, this could be a project spawning multiple yea= rs , but it would be well worth it, and in my opinion it would be also wo= rthy of=20 > the freeSBD foundation sponsorship for several years in a row. The feat= ures I touched upon became very important parts of oder OSes, and rightly= so.=20 >=20 > Note: >=20 > this message is serious and it is not intended to start flame wars, rel= igious crusades, or offend anyone.=20 > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 lib-izing all of the utilities instead of using libxo is a better solution. It would likely be gratefully accepted if someone were to do it, but most likely, no one will. libxo exists now, and most applications can be converted very quickly (although care does need to be taken, and it sometimes has not been). There are tools available to filter json/ucl output, namely textproc/jq and my forthcoming uclcmd One of the major other consumers of the json/xml output of libxo, is web control panels. This is why Juniper is doing the work, and I can think of a list of other appliance vendors who would love to replace fragile per-application parsers with a json parser to extract data from various command line tools. UCL is a good solution to having a universal config file, and is better than the bespoke config files each utility has. A transactional database might be better (for some uses, likely less so for some people), but I don't hear anyone volunteering to do that work. So, libxo and libucl may not be the very best solutions, but they are the ones that are moving forward. I would welcome competing ideas/solutions, but someone would have to actually build them, not just rattle off some ideas on the mailing list. --=20 Allan Jude --kk1cvSuaCKkPaDmsUvoFduAcNtcJtCPjl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSMilAAoJEBmVNT4SmAt+lfoQAI2aZ0HU8EWL/ReP+dHDBYnF GOxZ3ZGllfMes0J+cDFklI3QVe6cC7juPB0x6jfkEQwV427KF0LyiglR8ZGqwHUJ L5h+c1y8+QAeMqtIbQfdABMj1s6kD4FaWakXJM5Uxbo2fIy1aZRYiX6IwT13+k2e 42pkUYDCvRS4Uyr8upr4kgSnLWx6ZkazQ0/xlrnZvv68BB1PlVUQgATyUEuCA16Z dT/2OqwENwH9yExHrZVmsUVq1FCbuK8sQebJT45Y92uVjbgdqBWVuFclRIze0Gze XFVfOTqDOVZGhLMWrPvnO4IJuml+YnZCFKh5qjGBX5joZD5v7ileS0bfwfZtsnoE xecii47hWdQu9nsS3x/ICu0ND9ewnLJekZthSntmSrFk71b64T3o0Yq9ucushM1p dUfh2PJiJM4U76vx0xNEy5S48iL7ge0NoBQff7Nbbl3GuXL2Eop8BDLVyu6ixPFQ eBg42//zm3zdOUXZ3ULhpZL7itSg9r6ubyFr7RDIrOpxpcYvEbM6MUDf/98bipKf Zxs1/nuxzCueCuj9yNDpr+/4CaQJn9KeluHjYAZIWxjIE1f55GU3OnqdUhqmYYwL oByizvCtq1JKxBa6p3ifAWWpz84irvfdymi9eEZYAomw0VkVViNUJFA6UafbQS3C GabbMeyi1uWGefLncudW =oIMJ -----END PGP SIGNATURE----- --kk1cvSuaCKkPaDmsUvoFduAcNtcJtCPjl-- From owner-freebsd-current@freebsd.org Sun Nov 15 18:05:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 269A5A2F4B9 for ; Sun, 15 Nov 2015 18:05:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E73881154; Sun, 15 Nov 2015 18:05:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igl9 with SMTP id 9so44595818igl.0; Sun, 15 Nov 2015 10:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NTG9l96nFNCm7CFamKXP1G+dNTLpOHKQ0K9rr/JUeQc=; b=Zloezj7I7tVqHzlrB1G5IQNjVHffPvQfrJ8d5DMXwzuc/24lnxKn4GC9S2K0X4oKMy W9Y2I+GNy4yvvhCZoYxIKK9n2je3cTu3wq97bfeBjSM+EokAuirDuioiksb+3kZtTdQC lZV+sZvIlh5ruAGaJRzbAMi9OiWbfmoFrKhc9Va3pPlWE7j8t9EPZu1A6odju7g0hV4j 67sd/b9I6xI84kcrPEiRIvNxVtJWsa3qvkSEHMZ7NwZCivaElvNtzPa0jXtHCmMzhJhS i+hpQSJ/YVVTfJ4thUntpQt+crk/AqZ1pk64KsrCNRcoKRI6K2ejJQv3I22q5bQCbvnR c9dg== MIME-Version: 1.0 X-Received: by 10.50.62.104 with SMTP id x8mr11974347igr.22.1447610709305; Sun, 15 Nov 2015 10:05:09 -0800 (PST) Received: by 10.36.217.196 with HTTP; Sun, 15 Nov 2015 10:05:09 -0800 (PST) In-Reply-To: <5648C60B.6060205@freebsd.org> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> Date: Sun, 15 Nov 2015 10:05:09 -0800 Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Adrian Chadd To: Andrey Chernov Cc: Dan Partelly , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:05:10 -0000 On 15 November 2015 at 09:51, Andrey Chernov wrote: > On 15.11.2015 20:37, Adrian Chadd wrote: >> On 15 November 2015 at 09:10, Dan Partelly wrote: >>> Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? >> >> Nope and yup. The juniper folk had a solution to a problem multiple >> people had requested work on, and their proposal was by far the >> furthest along code and use wise. >> >> It's all fine and good making technical decisions based on drawings >> and handwaving and philosophizing, but at some point someone has to do >> the code. Juniper's libxo was the furthest along in implementation and >> production. > > It seems it is the only and final argument for libXO existence. I > remember 2 or 3 discussions against libXO spontaneously happens in the > FreeBSD lists, all ended with that, approximately: "we already have the > code and you have just speculations". Alternative and more architecture > clean ideas, like making standalone template-oriented parser probably > based on liXO, are never seriously considered, because nobody will code > it, not for other reasons. Right. Technical progress is made when people do some work. You can do all the planning and designing you want, but computers available today run on code, not on hopes and dreams. :) I'd love to see the libxo stuff morph into a split between Allan/others idea of "libify things" and "stuff that handles output serialisation". Someone just has to do the design and do the code. So, who wants to code up the template driven, library-for-access, library-for-output-serialisation pieces? That's what we can commit. :) -adrian From owner-freebsd-current@freebsd.org Sun Nov 15 18:05:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45AF1A2F4E3 for ; Sun, 15 Nov 2015 18:05:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 247651237 for ; Sun, 15 Nov 2015 18:05:25 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7D288DBEA for ; Sun, 15 Nov 2015 18:05:25 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Allan Jude Message-ID: <5648C964.2020405@freebsd.org> Date: Sun, 15 Nov 2015 13:05:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:05:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-15 07:54, Dan Partelly wrote: >=20 > Hi all, >=20 > I was looking at the new facility of dumping JSON,XML from many utils i= n base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: >=20 >=20 > 1. Undoubtedly, it makes base code slightly harder to understand and ma= intain.=20 I am not sure that libxo actually makes the code any harder to understand and maintain. It might actually make it slightly better. replacing: printf("%s %s %d\n", foo, bar, number); with: xo_emit("{:foo/%s} {:bar/%s} {:number/%d}", foo, bar, number); it not really hurting much. > 2. I have seen the idea that this makes the information dumped by utili= ties in the base easily accessible programatically. OK, maybe it does , b= ut > it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I > dont see too many ppl changing their code to read JSON instead of text.= I don't even see the base tools changing. This output may be useful in = corner cases only. > 3. The integration of libxo IMO only points at a much deeper issue IMO.= It is only an expression of the need of a mechanism aimed at binary code= reuse. But it does not solve the problem, it only adds yet another possi= bility in a world where too much choices already result in too much split= s and incompatible APIs.=20 > 4. This whole effort would have been IMO much better served by porting= the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch like the libs for geom, zfs , etc , ready for reuse of 3rd party code.= Eventually writing network control daemons in time over it , much like s= olaris does. >=20 > 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the be= stiary of ad hoc databases already existing in BSDs ? Programatic readabi= lity, yes. but it does not add any real much needed functionality such as= *transactional databases* for system tools. Why not research a proper = solution - easily accessible by other programs ,orthogonal , transactiona= l, and ACL protected solution which can be used all over the place , f= rom OS boot, to ABI management, service management, network management, u= ser management. I hope this day will come, a day when I will not have to= edit a single config file manually, yet I would have access to all the c= onfig and system state easy with wrapper APIs. In the light of this poin= t, why go with UCL ? It is not orthogonal, it is not transnational, and e= diting the config files directly would result in the same old human error= s which bite as all from time to time. >=20 > 5. It is my opinion that Solaris addressed some of those issue. Solaris= FMRI and SMF are lightyears ahead of the very tired models we keep using= on BSDs. Why not build on the insight offered by those (or even on the i= nsight offered by Windows :P) , then inventing more adhoc solutions and a= d-hoc databases, which do not address the real issues we have , like bina= ry code reuse, service management issues, lack of a system wide publishe= d -subscriber bus ( not kdbus :P ) fault detection and reaction, fault re= porting, all much needed parts of a modern OS.=20 >=20 > And now thee questions >=20 > 1. Why lib XO ? Why burden the OS for some corner cases where it may be= useful ? >=20 > 2. Was there any real talk on how to bring FreeBSD up to speed regardin= g those issues ? A period of research on what exists, on what can be don= e , and ensure important things are not showed in background and replaced= with yet another ad-hoc config database which lacks modern features ? > From where I am standing, this could be a project spawning multiple yea= rs , but it would be well worth it, and in my opinion it would be also wo= rthy of=20 > the freeSBD foundation sponsorship for several years in a row. The feat= ures I touched upon became very important parts of oder OSes, and rightly= so.=20 >=20 > Note: >=20 > this message is serious and it is not intended to start flame wars, rel= igious crusades, or offend anyone.=20 > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 --=20 Allan Jude --tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSMlkAAoJEBmVNT4SmAt+OI8QAJAiDDNMt/ww9ggGcTL6zVhh 2ABJrP+pNwBmnFjjShn5tn86L4pmk6l2xCo+cxUaApP6YlNnJcsrRigfLE6B+B/V rrZP+wFzYpdTFVoNRP8a07+MhhczVrIXc5tj6HsZTP2WvsYYdqNzEATJxBQNjmBn J3PNGrNTNpejIdcY2Ox5XqnzkXQ/bXCC4M6ZELPZ3uuyOVXHXBl+4lNZ2nCDG+kW YI9YJ5tDgYaveCH8A+rm9M3VZnH+5YGE10N7486ljiSbWU8HgJuaFN/lSSM7V9Hu 04WGQjuO+gME4us1J8P3Zv8bHt0BWDhqgK5DBmS4/ITY6BoKl8KtREWGhrfEev1O hQ4/f2rB5C3/wfbmLcRgD0xeUaU/IYsgjIi/TqRG4kdYoCn+RkCm71CZLLhBt8IM GV0CwsPB5hAN6IHBbiT7T9iRgIuILFqSLrnR8/Cnao3dlT7mpXKECqYByub46kGT hv6LT40Mik8BGuSZoXcFeU45uu8QV7p+UgN6iz9AhOazafYZTnzsD2b0GlC/rSPm guAZtjppzUIJr2hVGebaQi5IWhvuRgrV8MhyW5Ut5UFt3A8UHJAUt3VDUpeQfZKk KXvB5wLxbqNrcVWuF7UOTw0BGmpxoejP5O6jKyosrKpjVr4QcwtSLm3uaTmqsrPh /ig7kXLyZVSY6WdPaxJV =wv11 -----END PGP SIGNATURE----- --tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm-- From owner-freebsd-current@freebsd.org Sun Nov 15 18:06:07 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A333DA2F584 for ; Sun, 15 Nov 2015 18:06:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0147.outbound.protection.outlook.com [157.56.110.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18B87138B for ; Sun, 15 Nov 2015 18:06:06 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from DM2PR0501CA0025.namprd05.prod.outlook.com (10.162.29.163) by BY2PR05MB063.namprd05.prod.outlook.com (10.242.34.151) with Microsoft SMTP Server (TLS) id 15.1.318.15; Sun, 15 Nov 2015 18:06:03 +0000 Received: from BN1BFFO11FD045.protection.gbl (2a01:111:f400:7c10::1:114) by DM2PR0501CA0025.outlook.office365.com (2a01:111:e400:5148::35) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Sun, 15 Nov 2015 18:06:03 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1BFFO11FD045.mail.protection.outlook.com (10.58.145.0) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sun, 15 Nov 2015 18:06:02 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 15 Nov 2015 10:05:54 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAFI5rD12622; Sun, 15 Nov 2015 10:05:53 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id EF42B580A9; Sun, 15 Nov 2015 10:05:52 -0800 (PST) To: Dan Partelly CC: Adrian Chadd , freebsd-current , Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? In-Reply-To: <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> Comments: In-reply-to: Dan Partelly message dated "Sun, 15 Nov 2015 19:10:34 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25582.1447610752.1@chaos> Date: Sun, 15 Nov 2015 10:05:52 -0800 Message-ID: <26127.1447610752@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD045; 1:uEAKFnJvUYjql+7cRcf+EXCGb9ELD0rNs1NUtwSCa3rxH9vHHV5r4zhSgOH0kASDM896CMmwfsZjVxG6BMcwkffHOeqG88ukVwlm5ezYJRkcTuKDKubqLBJ9XjaO4n0Gv9qdPIY1RuH4oP4RoQRQkMbTmKjFz1kzFr9OpFqGehQBI1X6BaUOxnmbGPsNK76PeROM6enzq0v99qS2o5d/Eaek7Wd/I5+P4r3jZu9Ona/1A1/pxZKBlPjGkT1tXLQaNJnXRLofiLZ14l14OmtgWFisK0htgVsiuux9lR+u76q5WVi8IdxVDoO1stWta5BjP7+FYXzyK+IAs52mGtxt99/bQxgdaGMunO6bGRTzSmUl71WZtXCuZbPfgg08NA7R X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(53824002)(199003)(189002)(47776003)(76506005)(50986999)(97736004)(46406003)(76176999)(105596002)(92566002)(57986006)(50226001)(77096005)(2950100001)(4001430100002)(586003)(5008740100001)(69596002)(117636001)(81156007)(23726002)(86362001)(87936001)(33716001)(106466001)(5007970100001)(11100500001)(50466002)(110136002)(189998001)(561944003)(6806005)(97756001)(5001960100002)(107886002)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB063; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB063; 2:M2H9wKyMxmYtPUsU9jIpvx0wRxbGe8yPYLyIN7xFoxdcinIngqARaYkB0z9XqnkUjPLrAuzHK4NO+xHjzlh7mePKc3Nmp3wBuqylvJfi0addPvOaTjzcGdqqr9fOzP/UD33r4l5Tu4c55moRgeOYY74nJANOAnuHdzPt2+K/uK0=; 3:kairdbYtqYK6hQfotzx7TKvh+Ec9I/VoF5NtgI0NOXxbm1ywJbbAPlzBYmhL5v0861hDWX1gHrpWpnQJiw4JoGsO1dDClKr9idMLXLJY/wLCDHWJHeya0WYOOevm43Crut5Wo33txf2BMdNKl5nXR5b3iggW2TG62gcIUEYILYAZNImYjx74z0q9AqoyOGokY4ekbTI2giEv36dPGtX17WzGxfvshXXj/V5wpFk9/vg=; 25:tZH6WOuxt4yCf/TRObw6h3gb4qgJuOfzBh1udLTNMxC79TOzDck4qgQOdawDqglhcRdMicDtTWnmmkcCPZ9VvQM6uXvuGZ679zQD2AiF7u2o/zZgiRj1KSeWv9RYlB5S4HsPIwLCwU0KKnGJge2IH/jjXFBn2AfX2+OofIRCZI7L92HBszR4zExLDEy4rcKo8WjXiD9HoF6qlLFOys2cyPp5tX/tUdY6Ct3zJuQcsI+KrasQJYjtv+4usRd8WnJMSRG3SxD1gWVahOBT5eqkMg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB063; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB063; 20:gjOHfV6uSCOqfN2a0WqfDAZYebWRJU6FCXBXb7mNfnlOJvzhLyUM3CEjIFAi1EqMqIE0+ODV5NM40p+iVb4vL4YwfTdH1+YXpaVYo5N5NHWLAJ8WuBeAazbVvlDM5C7wkc9fYTnrlvI40Pqz7zE420qRuMO+Npt2W3YEcA1viUh90Is9M4sXuWc1wNE3GxS6gXFHP6INj6RFBkNMB2Z0O7sWCDRCiSXkBXLmjkpzKatD/tRTK5aBy5JmdPJFhWOTKHNNhPlQVqoIhDJdEuOnasdamMkb2Vpja8rHFA5PqKYSRb3YljQoBDd8RgUoAH18DWZKRZom1s+BZyZe8hJ0YNRLx13rzt6A40cE2s3qbDpJvDBrQFjHvK4UeD/SVjjrnizBZe2yC06ZzY56LWi+jcLp+iV0qhv3XCOD10v1NxLU5hFX/KGvNmFYHG7an8hNURcAvpXuFB2J94GCiZ+IpSmQmH7R1wXMhYQWZC3zwPTeH4jKwJMRPUh+RZn/muBY; 4:Lo0h9TW5eeMA9uLWADfZqvryObdyLHzwBKM1cxrUYcHZZpCT6tozXj5pv6SQbFkHVYDHdoUa8yYIiWTg+zZEipH/nJIro+K7D8nREL5MysKu3w/FkfhzrvI26SC0F7LPFNvPkYWg5H3gCYY6i1/13NSl0vtO2sGc/Y6r7QJVq9ra4VVeucaVEuIfcmxskKA9JtUHpR82FfS7FJo3448sxbwPgdVRCGkagLTYxMbA/Eaemg6j/r7hCjxoxcHpHpV4HaHftqkDViczpVPPuCnQ99n2s5bWmtdD1Gb+b3+Zlbs6acpmEDUBItcZoxOuK5uxC3Mb6EI+yfSCk32Qbk0w2KlVePJBewjFNkTNA5MSitQeBchbnAYmR44e2N5BD9Il X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:BY2PR05MB063; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB063; X-Forefront-PRVS: 0761DE1EDD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB063; 23:CGvaT32t4VUiFJxQKLsFW1B4kRCS8EmLKmQ9mAJu9P?= =?us-ascii?Q?Xaj7FeZS/Ga169KeBVgnOsQZX69FKSiFp2+2j64X88cyJC7CkA2A5tMapCBJ?= =?us-ascii?Q?/VmhMjH1P5y2pLjorksbZXZMqHU1lds5Xe2B3AotSKqPFwfmjrOF29gT/x2C?= =?us-ascii?Q?Qu114YOfc7Duk1NG7O11V5tsqPkujBVJnEUHVM0ZOhoJqjckFCyvXtrmrTph?= =?us-ascii?Q?lLzDjvKmV5n+RHFDOz9l9dlUB1DPOP4hwYKGgZbmVGL4QmP0hhk73QxQMm/j?= =?us-ascii?Q?yv4Ztm6VT+QgrGkqIhcAg7LV0NZDtPxyFDe51BNyHOx4Xl/GhKCG3TWIo4ap?= =?us-ascii?Q?8p7J8MRJ+7GdpzujzjNLAm/zkR8gUE0aGmvmZ9RfZI8LREgc4oBY5Nt0UzkE?= =?us-ascii?Q?lak9VJsU98wHqeWmiyh/WXGURNgCDPoLkkHos77p9zIPSPfS1UYnNwh5TlJi?= =?us-ascii?Q?mCQUvEc+TG4mIp1qatGGQpZvsBRMK6MmCAT0RRZRsDINj+O6n8X3dxWbdMEW?= =?us-ascii?Q?v4CKUVycbv6vd0NT/v/HD5Kn6JOqxQR+SGCYHMAaq6U6XWEigJAVoxfHPIIj?= =?us-ascii?Q?4+Amp9hv7sDy0H0/ItJpyUkKFbywJZXqkGvNgeYgWoeNCKWdnQR0yyVm9Xhg?= =?us-ascii?Q?AtsjbcE8B4NCE6zBQrGua5ypIl2URQF/B2lmlgN6DUdINWt0RkhKlbw2b7ok?= =?us-ascii?Q?QOQQszvMy3DD1PeQRwKcraLw++nj6r+W8UK/de08yrhQnMp+B1eoZUUkKEWq?= =?us-ascii?Q?sy6gIcuYO5KI/SBVZdBLO3JGJELTnvzDHS3538DF57rddGcO5k+oDkv44OAH?= =?us-ascii?Q?ZZw5hOm4z/Appn9ZmWo/CRV2PIMJWqid7uIYsG6nRBO6bD08MDgo6yYKInne?= =?us-ascii?Q?izK++Pt0+ueotZ60q0XSbwU4QtOun8XAav7PeFQ3fa1E4Bw8MWcvWjhk4vIu?= =?us-ascii?Q?Jo4pUP/f+8rnlj/YbD1YJOtotj7RnMOMcVGzHXtvDuOW07VjWajL5xKcbPfx?= =?us-ascii?Q?yBkbCyyWAENAPcKhMRoYbrSwE4NewDana8nGxPOIa4ieJuT3vo69KwGmDAvI?= =?us-ascii?Q?RXwQuslxl9vaviTyYVNB+Fn4nb?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB063; 5:5h269joVe9KuO7t8e5PsFjA5UP09LMlg7d1ZKdO0K9D/rNI4ZM7XhJ+VlF7J6b+QdpaJfvs4jJFBpk9FLy49DDIW4dS6p1RZidBzRbeFBGV+Lmq8RehWY+D8plOX1aRrKW+BihQ2Ye0zmZtWncv4xA==; 24:NDiAsngK2KhURMMEYnAWwatFKHRqwwcB5HzU79OaaCjqe7AnERYjBo9CfZByIVMLhJmtfxiZ5++lUCQ0p+oDOAd2WKRMd1rzYI1wqAvwAvA=; 20:LU+szCxBRnGPmqoucWroIaucqmHUgf80OGyMHcMwU2eKwPKJFKM4OFWjyPabw2cSRq7Dm7ryZlff0hGBrnPmZw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2015 18:06:02.6194 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB063 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:06:07 -0000 Hi Dan > Meaning, is that simple to push things in head , if somone does the > work, even with with no proper review of the problem at hand , and the > proposed solutions ? Not sure what sort of review you are looking for. But I can speak to some of the history behind this. FreeBSD holds regular "vendor summit" meetings where folk using FreeBSD in products can get together - sort of a swap meet (I have this, I need this ...). At one such meeting at BSDCan 2011, I metioned that we (Juniper) had tweaked many of the startard tools to output XML, and asked if anyone else was interested in the facility. I was frankly surprised at the number of hands raised. There was clearly demand from a segment of the FreeBSD community. The ability to get machine parsable output from OS components is a big part of the success of Junos CLI, netconf etc. It took a few years to get some time from phil@ to design a solution that we could consider upstreaming - libxo was the result. BTW this is a "problem space" that phil has been deeply involved in for over 15 years, so yes I think we can say the problem has been studied. That demand I mentioned? also resulted in a GSoC project to do the same thing - though it was much like approach that Juniper had done over a decade ago that we had considered unsuitable for upstreaming. But it rather clearly demonstrates that there was demand beyond the whim of a small group of folk or just one company pushing something unwanted into the project. The number of developers who have jumped in to XO'ify apps also speaks to that. The original proposal was for XML only (that's what we'd used and found useful), but others wanted JSON as well. Libxo can also output very rich HTML - I forget which HTML or JSON, is used but this allows some seriously slick UI's to be implemented using a modern web browser. Hope that helps --sjg From owner-freebsd-current@freebsd.org Sun Nov 15 18:06:43 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68664A2F5C9 for ; Sun, 15 Nov 2015 18:06:43 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3033F14D0; Sun, 15 Nov 2015 18:06:43 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by igvg19 with SMTP id g19so62734324igv.1; Sun, 15 Nov 2015 10:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ywdoR0q6G6BUyb3qJjLCyGVJvzCbWR7FfLvN7+mgqs4=; b=EOfZXFttiKV1MBuLGWEPXPi97PCk7r0s7F4BP1k+g2eviy9wm9VQhnAWauOW3hD0Xw USzIpfYSPabA8wPqUaINZ06oXoy84F4mysyPPWUG1iwv7HFW0WnAHgJOUFupcc9/oaaS W7Yg03oW6rzs4kqjvQVmVRApnsnBmRTbETPPV1peIR7kLjF2ue0LdPrBs9d+jKMuexX4 ZX7gNn23dgdzCI4X8qeMzY9jepObvPfjm4zwP5Em1rvTYwoH7nsceEPuG7cUZGO1gD9I iX1NpOOw9pSpSFOzo/JiMht3cK7zHa4MpA3k52XTyEP3JyVGlDfU6gnO2hKjE1LWHnGe +Uog== X-Received: by 10.50.222.75 with SMTP id qk11mr13145136igc.60.1447610802619; Sun, 15 Nov 2015 10:06:42 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:5949:ebdc:f5b2:56d8? ([2601:601:800:126d:5949:ebdc:f5b2:56d8]) by smtp.gmail.com with ESMTPSA id 126sm1857706ion.32.2015.11.15.10.06.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 10:06:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Garrett Cooper X-Mailer: iPhone Mail (13B143) In-Reply-To: <5648C60B.6060205@freebsd.org> Date: Sun, 15 Nov 2015 10:06:40 -0800 Cc: Adrian Chadd , Dan Partelly , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> To: Andrey Chernov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:06:43 -0000 > On Nov 15, 2015, at 09:51, Andrey Chernov wrote: >=20 >> On 15.11.2015 20:37, Adrian Chadd wrote: >>> On 15 November 2015 at 09:10, Dan Partelly wrote= : >>> Meaning, is that simple to push things in head , if somone does the work= , even with with no proper review of the problem at hand , and the proposed s= olutions ? >>=20 >> Nope and yup. The juniper folk had a solution to a problem multiple >> people had requested work on, and their proposal was by far the >> furthest along code and use wise. >>=20 >> It's all fine and good making technical decisions based on drawings >> and handwaving and philosophizing, but at some point someone has to do >> the code. Juniper's libxo was the furthest along in implementation and >> production. >=20 > It seems it is the only and final argument for libXO existence. I > remember 2 or 3 discussions against libXO spontaneously happens in the > FreeBSD lists, all ended with that, approximately: "we already have the > code and you have just speculations". Alternative and more architecture > clean ideas, like making standalone template-oriented parser probably > based on liXO, are never seriously considered, because nobody will code > it, not for other reasons. We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't= seems like the best idea in the world to me from a end-user sysadmin/develo= per perspective. I could just as easily use standard tools like awk, grep, sed, and more adva= nced languages like perl or Python to parse output, and assuming output does= n't get a major rewrite, I'd just go with that method that's worked pretty w= ell for me over the last 10 years of my career.. Cheers, -NGie= From owner-freebsd-current@freebsd.org Sun Nov 15 18:09:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91725A2F6A5 for ; Sun, 15 Nov 2015 18:09:38 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 562321782 for ; Sun, 15 Nov 2015 18:09:37 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 62FA3DC07 for ; Sun, 15 Nov 2015 18:09:37 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> From: Allan Jude Message-ID: <5648CA60.3060800@freebsd.org> Date: Sun, 15 Nov 2015 13:09:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9cBls7lfNEjNBwMboC9donM9edpOWpuND" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:09:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9cBls7lfNEjNBwMboC9donM9edpOWpuND Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-11-15 13:06, Garrett Cooper wrote: >=20 >> On Nov 15, 2015, at 09:51, Andrey Chernov wrote: >> >>> On 15.11.2015 20:37, Adrian Chadd wrote: >>>> On 15 November 2015 at 09:10, Dan Partelly w= rote: >>>> Meaning, is that simple to push things in head , if somone does the = work, even with with no proper review of the problem at hand , and the pr= oposed solutions ? >>> >>> Nope and yup. The juniper folk had a solution to a problem multiple >>> people had requested work on, and their proposal was by far the >>> furthest along code and use wise. >>> >>> It's all fine and good making technical decisions based on drawings >>> and handwaving and philosophizing, but at some point someone has to d= o >>> the code. Juniper's libxo was the furthest along in implementation an= d >>> production. >> >> It seems it is the only and final argument for libXO existence. I >> remember 2 or 3 discussions against libXO spontaneously happens in the= >> FreeBSD lists, all ended with that, approximately: "we already have th= e >> code and you have just speculations". Alternative and more architectur= e >> clean ideas, like making standalone template-oriented parser probably >> based on liXO, are never seriously considered, because nobody will cod= e >> it, not for other reasons. >=20 > We lack a [dtd/json] spec for tools, so programming for xo'ification do= esn't seems like the best idea in the world to me from a end-user sysadmi= n/developer perspective. >=20 > I could just as easily use standard tools like awk, grep, sed, and more= advanced languages like perl or Python to parse output, and assuming out= put doesn't get a major rewrite, I'd just go with that method that's work= ed pretty well for me over the last 10 years of my career.. >=20 > Cheers, > -NGie > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 The big difference is, a json parser isn't going to blow up if a new field gets added in the middle, and your awk/grep/sed script probably wil= l. --=20 Allan Jude --9cBls7lfNEjNBwMboC9donM9edpOWpuND Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSMpgAAoJEBmVNT4SmAt+R+8P/jLkL4Y9NkIgytzgXssxSDj0 W+dI8jCdVbzO3T5SxPBGkIpACa+wihQ1Ockq/ABonFdJd7+dxNts6TpSB3OJe/AV Ug5apEWJIDPElTHCODAj1UBHPIXfBriZhumuFHj99olGT7k9sD8sQNpF7hkFazPi ftfIBLLv9ZS/cquFW76wO1mdhggpu2vtLOv5GaDvrOzNfeP2xgmuBc9ZaU32mylf 1ub9ySoPuuc54/KL/eLwPUFQTbFVODJMaysGXub4/DRgw5R8/sjp4QQUo3LR7cI0 BcAAvMI1M5QAbkXNoAhWw/lNEynH8kTsiATwOa/zp2xmLGBLC0yQfVTsK6YIJNaS kLEVbDJ1AbUJzvzpATOv7IB4UUDUsjxgtTTrrddL9uJhf8yHesyuiFQ7WhKVnkqE HoBxxhigVNEr+0eXbhLxeoBtDaX93pnJjU8irCkxDY1E9P5RRepI9Bxy2KunT9Ff 7uClcNORU6c2WSCsLUdFtBc2uB3esSgsIs2I1XPKJhGHZjwXwTy2pX77nSbhpe3n omE6R86X5RvGIPoVIX+48hKeO6L01uasi6Kstl8khQQjDB1bSxpxPv+04QfbjsSc sxqIZhWL+JmY99QlPnXSgiIOCve2GlAUnSRSP2jsteGeBVkzArm2tDoT7F50AJgl w8IPErRWrUK8jyf1OEfS =idqt -----END PGP SIGNATURE----- --9cBls7lfNEjNBwMboC9donM9edpOWpuND-- From owner-freebsd-current@freebsd.org Sun Nov 15 18:09:46 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DEC8A2F6CB; Sun, 15 Nov 2015 18:09:46 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0145.outbound.protection.outlook.com [157.56.110.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A30451836; Sun, 15 Nov 2015 18:09:45 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BY1PR0501CA0022.namprd05.prod.outlook.com (10.162.139.32) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.1.325.17; Sun, 15 Nov 2015 18:09:37 +0000 Received: from BN1BFFO11FD024.protection.gbl (2a01:111:f400:7c10::1:146) by BY1PR0501CA0022.outlook.office365.com (2a01:111:e400:4821::32) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Sun, 15 Nov 2015 18:09:36 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sun, 15 Nov 2015 18:09:36 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 15 Nov 2015 10:09:35 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAFI9YD15245; Sun, 15 Nov 2015 10:09:34 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 1118F580A9; Sun, 15 Nov 2015 10:09:34 -0800 (PST) To: Craig Rodrigues CC: Baptiste Daroussin , John Marino , freebsd-current Current , "freebsd-testing@freebsd.org" , Subject: Re: Need help fixing failing locale tests In-Reply-To: References: Comments: In-reply-to: Craig Rodrigues message dated "Sat, 14 Nov 2015 19:05:08 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21785.1447610974.1@chaos> Date: Sun, 15 Nov 2015 10:09:34 -0800 Message-ID: <4967.1447610974@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD024; 1:yxaDNKkUFzM4rpyzpOLYhAQYdxp65bf3AbYfR9SP4/n/CWJ/USO8uyiKHjTEQf1VfJdXfCAm2CMWQvp7nS9PGsN9yN2T8lJWU3XcStDf//zl11zAD6Qpzd7n130CU0sJY3L5h7+9me1NbkK5LbSjpqzlIDhQFpAgsxim912pWpSfGJaXgljVLr5jqhnB1aupAWmGihiHunoXytF520YFUwDaei3+LG1BVlJI7ktPE5rhm4NpPMce/C2PQ34V1vPm1pLNb4loJ+qw/hpL2qO1vQtUNFqh4XFKdpzsJdQ4tWUZGrfSw64r5iHrYWppbMpid82JzuhcLUSczsLCgqlLgA== X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(199003)(76506005)(57986006)(117636001)(5007970100001)(4001430100002)(50466002)(81156007)(5001960100002)(110136002)(50226001)(107886002)(106466001)(105596002)(69596002)(76176999)(97736004)(19580405001)(19580395003)(46406003)(33716001)(86362001)(50986999)(2950100001)(6806005)(87936001)(47776003)(189998001)(77096005)(23726002)(97756001)(11100500001)(92566002)(5008740100001)(558084003)(586003)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB056; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB056; 2:rpDnbGuS5wG2HZ7pu7NmI/7j87sY1utWX89CJnT3QaPf7PMoU0UHmdz5179j5gxyg6d9dC9PULUYpAQkNIYPnpmvv51bFXEQn3/YKb4ameEnPQn2Wflc/bA8eqKQK4KSk6HxibTvPT4XlbUsJXYKV57jllUF4h1s/iyaWFeO31A=; 3:YavzmsG9Y7UeYO54+nTV7CDirGR4eN8yHW1znAfSv09Hiy3kOtNT3hFXXM03+EB5zuOtoct2QMveAk7QWuIe2GQv1oVsKt9sXDvXeQg6xR5YZDHTD1NYzIPkdYWcJRPn8FLQhAI8Gm7FDAOZ0C4Q5CTRpySjbN6QIKqlm7JAfZMAjQkH/OLNsmxHZvEPYKC8WH9Z7w910n7/pn4Ycbw18u3/PoLTGrpn4B8Zc6vXmmI=; 25:tJPD+BQ1DEDAaW2+BEGCAeel+9ANteuPxEYegsokg7pKcqRLyOxhMHza2nRKOpuWXVKP1967DEJFVB2xH+/mXuws5RYPY9qPTHf0k5xenGOYAeNSn5CS84G+mze8aQOynM18RpBf5yxV2DWJcFjQWMS1GRFnp8BAxFruVEmGjursgy5SizrLravPsj4QQSrW4ERsLnw8VWia2LBLpFJXc9xYkKiJmPKGXDLFgwVthLeIBvgUwSqgkIgpGnjjs697zEB4uoJWgHVs+VRy13m6Yw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB056; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB056; 20:0DokmSkzXsJ2I9tilvmicL20oYPXMYtdPwYc7OSaATAMvZAAtNMtKV4OE7y1YHrue3aT0MYGdVgypAcvu/4gBlEjVKA7Ri9b57LD3tnD0KRv2tfWMV7oRRJ1F+3925mQguXrDGsFnT71YNAUmC/mYLwKdA+w9bqUUAuYrCCqAGYeHCv7Sr/GvneadL1sejq5+cIMqaMnPA8h8rJBFt2uRZqJnyvTceTNpdfKjjhtDmUFWdD4sDTwsjdwLXg2cNUn8woaprNfR6CmNodSryREzeDfViVINv6VFn/Er/bxj8++GKV2aroqwM779FpOPcOjZyAECd9HV+I1CZJCa8tKP8q4V2KiE21hepZTi4ngSNnAl4FkYn2Ekz+paZT8VzeXpmZqPzvXIXzTNh36+kW0vp2Ot5t8PWrV7g+6zHyr2dQTHQCkpVV9Ar9ONakPZPXPCIxxX3syYNVZtYAmoRCIL9hNItMIfAqWLEbj4/891EV8TRe9QAlRmOQqFHQa3Orm; 4:cbf8o2ZUrLOoCwpyxiS6Q0VWuxLLaH74Rsbi2qusBeWlNfHyDH1ZKXovPkbkvtEfHMtIaoU99emGy7Hky4visMWtjc2243VUqikIZ4t4ZExeOmZX9FFStcw5KQMzld5T+usC0OeQc3MYdLtWyQyZRlJig10cytAvNYonS3NiKu966qP1XwxESqkTWI3Suxg0dMuxxvuKRooy30Q6o8shB3qG52/fYO1Q8WVm4IbSaxqj4Oxgu/rcWWFtAHAeVdX61QAgQ9jBeunDbSKZ5FMRbPF0EUUYrsYU0rGCUa/9TeOoIH1Vw7bJvojWcIp2RgklzF1ft6MEiOApB//ECcDwV9RPSXyM7aVAiqAKJrvjd8/OUDFHnhTjFXrJgBxTrnVD X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BLUPR05MB056; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB056; X-Forefront-PRVS: 0761DE1EDD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB056; 23:h/mcdHtsF7rculBuF0apJD3ErZ/SE7A2xe505zZCBB?= =?us-ascii?Q?pLK29M+PDY1mRheJ8KZiJBD2FWjCpSWh26kr0ZG3P0CXL5kCsV64U8hOFteF?= =?us-ascii?Q?9JCK3Oc3aanjddtyrnEUMvTuwbMVvXDYxNNu7Ju2Bh8YKt+7yjyzGDnlb/sn?= =?us-ascii?Q?R85ucay0IGou9bBtTSPw9nxm1bEc6pYb/R3OkKZfUCtWstGhC9PKwyWFzER9?= =?us-ascii?Q?moQTIcVd8OCTwW5fmt7ldE+uhnboOWLSlMHf4ckHTGLSLhh/Ecvugxeqy1MW?= =?us-ascii?Q?2trTArnqyTbXZg2Tit073BRf+9hNY1gk1BhXYDSp4U02CK8aUHRo9nolEiGK?= =?us-ascii?Q?7AK+5zGw02u/i3vLoXIXru2Yfo8rFXAcQB0m+a7m1IcJ1LV6CVkF4gHqDh2k?= =?us-ascii?Q?v+EWdjktlEk86QDdDJBzgeMblarVcj6I1X7yx3BxAjS3Jc1XApuWjrhMI/gj?= =?us-ascii?Q?ScUmRH8B/ffNGbSTPskOOtHWpKkhumBVyefAdjHFp+D39nuAPscmtYSsQr+v?= =?us-ascii?Q?KkaqDu9PeBvd/1joLHu8Lsh1oXlqFv+rFEvHgIzJoV6qzgkFmRweoIGt63S0?= =?us-ascii?Q?8rf8gLdcDeFEa2yZ2qRg5d19FfKs22WcGNb9X6mxaGsJ+8jkmxdFxOchXya0?= =?us-ascii?Q?mhYf3Odfi92DZmJkddvdA31mthDrqNbA3Qr5HpL3CRcakCD/lZ7fWZ7tkNho?= =?us-ascii?Q?AtINjlSk2/L7yl/X473rPqmxxd9SMD6teusnqw/0Ub33fUo7z6Y55+yj7YMn?= =?us-ascii?Q?mdQNM0Nt3XLq6CZbm3+GCH86FHhS02qygLptC7DaBt0L04FkUYJhw5YFnyq9?= =?us-ascii?Q?/IhvceXvuGT3bKgC4vZbQbHcVSzFNhea5gpv4aJkADdVSgj6HxoG9wzAyKNZ?= =?us-ascii?Q?40dTks1/vkN3MG1oomqRQeeDh3ZOj1oewXX2A8WzUTLS8LRCxdmsy7REyZ6K?= =?us-ascii?Q?e6VXTYemE435ZENzDf21MRHveUmWcIaSkiYbEqV3IP0wFIw8zlx2ZaHjiZzD?= =?us-ascii?Q?2DcFl0WxEHBiEZycFN4oOpM7xFFfAhnxITIYcc8quVgjjFDhv/5bELk0nTZc?= =?us-ascii?Q?Ncc14lSTavkNNTXO0nM/CwAfkioDirXBzXlQhRydlr1xC5lMGuwPuNp/Pwna?= =?us-ascii?Q?8Q+YNbOp8=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB056; 5:T+gyFce9wWMPYGy/FXZL9AYA5Jk86KNojkTc6Wi1NpD5bVfHVcHB5SnCG/yL3luqDl+oBQcsYuVFpgOo1w+2LZzRtQMcThhuqnVXd8KlZOFa0htt/wZzu0GqAH3kdiDcpew85v4A3hYwbRlk1xn3yg==; 24:jov7JNuAO0LQtoohNGKvcev7j+v52RLUe3JRZSwGZtqBrIvfGc5C/QwpiDzAkOPF++FtvI1hznttYBNMH6nsu+RUNB71Ll3wBtWSwqlhDo0=; 20:vOcztjbBPkPWkVQneijqgUP5mzAyXQwWm+Ax1wOhjELgwmLGrj4AxmYRGr4BvWDZL/MxWQlmyZLXQq9TmQvACw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2015 18:09:36.6511 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB056 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:09:46 -0000 Craig Rodrigues wrote: > I don't know much about locales, so don't know what to do. I find LANG=C LC_ALL=C solves most locale induced issues. I suspect the tests in question assume the above anyway. From owner-freebsd-current@freebsd.org Sun Nov 15 18:10:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8329A2F854 for ; Sun, 15 Nov 2015 18:10:39 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABF291A32; Sun, 15 Nov 2015 18:10:39 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pabfh17 with SMTP id fh17so151879067pab.0; Sun, 15 Nov 2015 10:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KRJXsFOyXngQqhAt62136I23ISRrlWFyCyFREr9pyqI=; b=TAQf5NT1buDpwrE3KqJQWYjlyhVlCaUSt9u5NZ6nhX+I7TeaIsXhlrMW8dzD8xSmkC fXNzYTUPAHcQ0tOIise04as90Pu+jopyC9jtF+/eK0/rYtwrCKHBDQtXu2iTb9BH3u4D l61TLSp70HjcLawJEzEx/MLHru0P9LIQbAdRe7aJhBGyIx9PLWtNH1egh8wnryEGsdo+ /MXCh3BdSQStTJfCU3gjML8hxydxCwrjb0XJSFvT0WblITy98cebY4AAF7hJnooSMoz3 dLtdrO8iHaBy+aP/l19xo5GaoWf0z2/rCzOke3gzTdCd+2jx03zD7Pm9ifKiWtADn8b5 c5Eg== X-Received: by 10.68.68.233 with SMTP id z9mr43106292pbt.76.1447611039347; Sun, 15 Nov 2015 10:10:39 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:5949:ebdc:f5b2:56d8? ([2601:601:800:126d:5949:ebdc:f5b2:56d8]) by smtp.gmail.com with ESMTPSA id ws6sm31658750pbc.33.2015.11.15.10.10.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 10:10:38 -0800 (PST) Content-Type: text/plain; charset=cp932 Mime-Version: 1.0 (1.0) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Garrett Cooper X-Mailer: iPhone Mail (13B143) In-Reply-To: <5648C964.2020405@freebsd.org> Date: Sun, 15 Nov 2015 10:10:37 -0800 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> To: Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:10:39 -0000 > On Nov 15, 2015, at 10:05, Allan Jude wrote: >=20 >> On 2015-11-15 07:54, Dan Partelly wrote: >>=20 >> Hi all, >>=20 >> I was looking at the new facility of dumping JSON,XML from many utils in b= ase and after some funny minutes, I couldn't stop ask myself =81g Ok, this i= s funny , but why ? =81g And I couldn't find a real answer. Ill outline what= I think: >>=20 >>=20 >> 1. Undoubtedly, it makes base code slightly harder to understand and main= tain. >=20 > I am not sure that libxo actually makes the code any harder to > understand and maintain. It might actually make it slightly better. >=20 > replacing: >=20 > printf("%s %s %d\n", foo, bar, number); >=20 > with: >=20 > xo_emit("{:foo/%s} {:bar/%s} {:number/%d}", foo, bar, number); >=20 > it not really hurting much. That's by and large true, but there are other APIs that need to be called on= exit (xo_finish?) and in other scenarios where flushing, etc is needed. If y= ou don't do that, you don't get the output you expect (which broke uptime/w s= everal months ago..). Also, typos with the meta language into the xo_emit calls have bit is more t= han once ;(.= From owner-freebsd-current@freebsd.org Sun Nov 15 18:14:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF7C6A2FA90 for ; Sun, 15 Nov 2015 18:14:26 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7E881DDA; Sun, 15 Nov 2015 18:14:26 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by igcph11 with SMTP id ph11so44536759igc.1; Sun, 15 Nov 2015 10:14:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O4APO9nBJHx4hch0c4KeZquIVzLEt9jAWUdE5vRA8PQ=; b=waTOg5ykeQjk440FmVU4ua1mwYTKVNaJQA7TzK2HiwyyKHAFROhW0kN9XYAxY9Uywm W+xW/i/1NPUtRJOFDa+kzUF3vzW5qHBKWy3+7VtLIglZ/yc9OEIE94QxIOMFLuOar5xu YNLe/5aJGHcqZBwrpTKAos1WUdRUCGAgLzTEVQQM1CLmOh19k4HFmki/SOxZl2WWpaMG ZUnCZsjvID7Ul5/vM5f8m0YEypdNwkLGPhsoyPF3DH9oft7QfX4+1roOoFhOsVIKJrnA emVsNaSQcM+0758wTQkOZyAcZkK3KOEPpmNGhAJ+pLq4rD5bsK1cM904FnAYKkftR0xp iRAw== X-Received: by 10.50.49.109 with SMTP id t13mr13118592ign.89.1447611266059; Sun, 15 Nov 2015 10:14:26 -0800 (PST) Received: from [192.168.20.11] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id 26sm7567380iod.9.2015.11.15.10.14.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 10:14:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Garrett Cooper X-Mailer: iPhone Mail (13B143) In-Reply-To: <5648CA60.3060800@freebsd.org> Date: Sun, 15 Nov 2015 10:14:23 -0800 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> <5648CA60.3060800@freebsd.org> To: Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:14:27 -0000 > On Nov 15, 2015, at 10:09, Allan Jude wrote: ... > The big difference is, a json parser isn't going to blow up if a new > field gets added in the middle, and your awk/grep/sed script probably will= . That's a plus to those formats, yes, but if someone changes the field name (= which can happen today, on a whim, and would go unnoticed for a while becaus= e no tests/spec), you'll run into a KeyError in Python or an equivalent erro= r message in your language of choice. Thanks,= From owner-freebsd-current@freebsd.org Sun Nov 15 18:14:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5A42A2FAF6 for ; Sun, 15 Nov 2015 18:14:59 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id B42181F26 for ; Sun, 15 Nov 2015 18:14:59 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id A9B05DC2C; Sun, 15 Nov 2015 18:14:58 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Garrett Cooper References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> Cc: freebsd-current@freebsd.org From: Allan Jude Message-ID: <5648CBA1.9010300@freebsd.org> Date: Sun, 15 Nov 2015 13:14:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bDeksebbs7N90hkbf9EdKm51onWeKu0H7" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:14:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bDeksebbs7N90hkbf9EdKm51onWeKu0H7 Content-Type: text/plain; charset=shift_jis Content-Transfer-Encoding: quoted-printable On 2015-11-15 13:10, Garrett Cooper wrote: >=20 >> On Nov 15, 2015, at 10:05, Allan Jude wrote: >> >>> On 2015-11-15 07:54, Dan Partelly wrote: >>> >>> Hi all, >>> >>> I was looking at the new facility of dumping JSON,XML from many utils= in base and after some funny minutes, I couldn't stop ask myself =81g Ok= , this is funny , but why ? =81g And I couldn't find a real answer. Ill o= utline what I think: >>> >>> >>> 1. Undoubtedly, it makes base code slightly harder to understand and = maintain. >> >> I am not sure that libxo actually makes the code any harder to >> understand and maintain. It might actually make it slightly better. >> >> replacing: >> >> printf("%s %s %d\n", foo, bar, number); >> >> with: >> >> xo_emit("{:foo/%s} {:bar/%s} {:number/%d}", foo, bar, number); >> >> it not really hurting much. >=20 > That's by and large true, but there are other APIs that need to be call= ed on exit (xo_finish?) and in other scenarios where flushing, etc is nee= ded. If you don't do that, you don't get the output you expect (which bro= ke uptime/w several months ago..). You can setup an atexit() call to call xo_finish automatically when the program exits. The original changes to uptime had a few other issues, which I fixed. >=20 > Also, typos with the meta language into the xo_emit calls have bit is m= ore than once ;(. >=20 Yes, but, a typo in any change is likely to cause a problem. This is not a problem unique to libxo. --=20 Allan Jude --bDeksebbs7N90hkbf9EdKm51onWeKu0H7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSMuhAAoJEBmVNT4SmAt+lugP/2UPm2RiJ3zj8IHTBFmOROI8 +/GmRtX4g0jIz8JR55ZB9SQAQ8ItUVlMMT1V11zjgWGfw+DsJGVXYT3v+2D66zzg TX4c1FaIlUR2M/xBb0j9tq5xCIc1O7TXl5PTv/hvV/KWFVWOhq2gbEr5Dq0XEIm5 GVMzx86lAdewRn3qEniX9l1MTvMJM7DdVZdH54N6kSxJOO9ays+31tAM0DiaS1Ef DVhH+l0dU4Aeq/c5s+1yBjaj5b9X1Q3/JfGuM6i6D86/1Y04f6CEww5Cd3+jPpOr hySx09BlfAmwQQEKxHn+tV+AdrIpKl2RXBAlpi29hj/Im8Pk4zXc7+8kzj0fFAf8 LLibWal39CkCWS6+f+/NIiBc33pJDuiJcWeoPS1VSqKpHyzgFalJmfg7hDNijGaq dpLOpStU9c7SCbunzFTDIc+S9ZkCydLtBDR6cwRWfcbwuAp9i7Z1g3yl6yyLa3Zc iSIrbsn+VLWsbp9W3LhhY58h1ma53jUjIzNae/dYSY+qluIiHg6qfTCnIuhrhVXJ LK/YdS2qiCYnb8TyvZ49AUa+kq3rSLvJvZWV/mvgxq4KZs0/8rB4lrS7ngXtJu5Y 4k+Cci8z/SKzQoyscb+1Dag7Ld3fPJwaRf88pEjsmWKaLmp/pMZhxm7AhJzHhRAo Sxe0YBSMXfe0iRE+8FsT =zedu -----END PGP SIGNATURE----- --bDeksebbs7N90hkbf9EdKm51onWeKu0H7-- From owner-freebsd-current@freebsd.org Sun Nov 15 18:16:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A555A2FBD4 for ; Sun, 15 Nov 2015 18:16:49 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 65A75106E for ; Sun, 15 Nov 2015 18:16:48 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7AAC0DC3A; Sun, 15 Nov 2015 18:16:48 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Garrett Cooper References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> <5648CA60.3060800@freebsd.org> Cc: freebsd-current@freebsd.org From: Allan Jude Message-ID: <5648CC0F.6050708@freebsd.org> Date: Sun, 15 Nov 2015 13:16:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rs14iHBM4dtbESeBBridiTD08piUqJdfV" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:16:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rs14iHBM4dtbESeBBridiTD08piUqJdfV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-11-15 13:14, Garrett Cooper wrote: >=20 >> On Nov 15, 2015, at 10:09, Allan Jude wrote: >=20 > ... >=20 >> The big difference is, a json parser isn't going to blow up if a new >> field gets added in the middle, and your awk/grep/sed script probably = will. >=20 > That's a plus to those formats, yes, but if someone changes the field n= ame (which can happen today, on a whim, and would go unnoticed for a whil= e because no tests/spec), you'll run into a KeyError in Python or an equi= valent error message in your language of choice. >=20 > Thanks, >=20 But, if the same change was made to a pure text output, then our 'column 3' would suddenly be username instead of ip address, and your program would not work at intended either. so at least json would give you a warning. So, the need for a spec on the output is not specific to encoded outputs, changing the output in text is just as disruptful. --=20 Allan Jude --rs14iHBM4dtbESeBBridiTD08piUqJdfV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSMwPAAoJEBmVNT4SmAt+QikQAOzAIg4wCBJozkDlBq9xuQAn mgL0UVO5rJ3TBgbBfeFji0tn0FiHTQYhseu7u+TAKb2eWRb/XGz8VsV8b7BOQUGt TGx8hvlYTFRaVnZ9XYYMej6bYSbFxNla2CSL3vu9XImmv/B9qaqYhIFb6Q6nosqD p9z5RXzU0ehvX3T9ZXe8DRMMfy7zDf/0kenNVC8SHfZ2bdB9g83taikJodwoJHbF 81FKyRnURVK7MMK4oLSOHMaBTdr81v0Zh2ZTYQzglVQKZP+UGTOBk3cMZv95OgPt YL2Wde15bEVJIEHBKJZYbwDr21KqTPPELuFCObQ1M7F82xGlAZBtnx4ZUXap8QmD gn1WlrzP2DhhimdXQCpugIHtL/1bcwMVCXhQn/O2iaDmlCxyFvHdTTRawmb6N7/i MOL/TGg2wqIcOn837lugO75G3hzCNagwl+VSc1MIkKJN1VrCapjNRcm6lDjSCgbZ BfS6SQEBjzZirit/RAkz77MJmB21TGpf6PWaRpFQAZupEuHNmxjCFBqQn7OOoCe/ XesAuZ2qA+wbbyPQvgspJvHucFpjJvgBqeqSwX6vzN+UA+6aQoXq1YMRoSUZjaMc o17/Quik4JIsff8GIm3oN1XhRO4vIiqPbowc0qoh2FmvZN0Ky20392seFC3M5ZSB zxN4Zo/gVzaSlsGKSoLd =zd8n -----END PGP SIGNATURE----- --rs14iHBM4dtbESeBBridiTD08piUqJdfV-- From owner-freebsd-current@freebsd.org Sun Nov 15 18:23:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F8C5A2FDF7 for ; Sun, 15 Nov 2015 18:23:05 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 76C531782 for ; Sun, 15 Nov 2015 18:23:05 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id D1C1BDC4F for ; Sun, 15 Nov 2015 18:23:04 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> <5648CA60.3060800@freebsd.org> <5648CC0F.6050708@freebsd.org> From: Allan Jude Message-ID: <5648CD87.4020305@freebsd.org> Date: Sun, 15 Nov 2015 13:23:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5648CC0F.6050708@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XrlC8eblXKc55v61h5s1hWr8SEeTpiIWP" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:23:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XrlC8eblXKc55v61h5s1hWr8SEeTpiIWP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-11-15 13:16, Allan Jude wrote: > On 2015-11-15 13:14, Garrett Cooper wrote: >> >>> On Nov 15, 2015, at 10:09, Allan Jude wrote: >> >> ... >> >>> The big difference is, a json parser isn't going to blow up if a new >>> field gets added in the middle, and your awk/grep/sed script probably= will. >> >> That's a plus to those formats, yes, but if someone changes the field = name (which can happen today, on a whim, and would go unnoticed for a whi= le because no tests/spec), you'll run into a KeyError in Python or an equ= ivalent error message in your language of choice. >> >> Thanks, >> >=20 > But, if the same change was made to a pure text output, then our 'colum= n > 3' would suddenly be username instead of ip address, and your program > would not work at intended either. so at least json would give you a > warning. >=20 > So, the need for a spec on the output is not specific to encoded > outputs, changing the output in text is just as disruptful. >=20 Also, libxo now supports the versioning of output, to make it possible for your json parser to detect when a change to the schema has been made.= --=20 Allan Jude --XrlC8eblXKc55v61h5s1hWr8SEeTpiIWP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSM2HAAoJEBmVNT4SmAt+QIsQAKtY06eitEB7vx1l15KuMMrY 9eLlxsgFt5Lpu3dGPWlsoOp/mQGPpbSp5sAnrSR1vf6U6GklP2gekAk2j/knbT2U WjX58TXw0P74iDl4m6Umn6zHRVTYE9mKnTjUr2XvcY8KaNY9e5JBAGM4D6/ZUQPa MdqrtZrzzGy3fnIaITjg2g50easXbVg0b/vCASDD3QjfOFAMHY5VtS/dy9QmM99O h6zj1H03gNX0YdeXAMXp3/icop5O/TBpPeG/Spx3nhCFYLxjGLnCXovLCTpipyab 7ivhYzEufrQv/FQK61PW4KH/Oqi5/HngRe2etpaMx1Cenf6wJojj6pp8vd2Kyn/+ OjLs3u9wScKhWQcmfLirvFZJZGmPia1TZZJ619IV+6a5mKHPYtfjwZNDyE+rRRt1 9szBGUoKENta932tjgNoXabErYY0cp4ABuKtuMYf0/H4s7c6k2mP8f/y2E6nMzLh N9Xlck+KmNvob8XMmctG0NPEPxf8NQfIZyAhuOCQXw54KtyBvYj9871T2X3Djclg RJ+89j/0FffMKYzKz+7IP/DIv/wLY0n7rjqdXzuWTeCb3MQNpkb3FG2OTMd7YAsj KvrNLDjYPePfeBU3BjSa4xpc7FFEuIL2z86ftHvPwIpERfrugch7tbao7fKqPVEm h/rh84YpZss2FCQT+OnG =h826 -----END PGP SIGNATURE----- --XrlC8eblXKc55v61h5s1hWr8SEeTpiIWP-- From owner-freebsd-current@freebsd.org Sun Nov 15 18:26:18 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E3E6A2FE90 for ; Sun, 15 Nov 2015 18:26:18 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70BA218CE; Sun, 15 Nov 2015 18:26:18 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacej9 with SMTP id ej9so43668499pac.2; Sun, 15 Nov 2015 10:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oMHHhU8VqiUqGteM8Fau4RicWL8EZp4axlkIKtclJR8=; b=L7wrtgUFtZSf2zd6qMa8gt54xTweR7RfdRCl86f/KLPlSOhOK69oOouxaVKrhpoRKc 5l3wlVbvTGop5fWZXf0McX7lerZrrPpXLOb/FufGzb5eBMEY6OkQsteo2DFXSF5Kie7N RsNAg2vDlRlUt4OvLBnWUCoEP8uSoVd/1DCqUCbqid4/UiYFjJEIc3ui3U6yulTCN8kC KHyt0RJvxhGNmVHTcmo7Dx0vXe+x4a06gjZqXVfYx++TSGY0JVsjwxwgK3ItZcaHeRpv JPIVXAn23/rIA2acF8DYUE+PYjsCeJJxFR/QYw4LZD50tA2Pyqpxg6ykFnp+x9mckOkn sNhw== X-Received: by 10.68.241.41 with SMTP id wf9mr37451531pbc.145.1447611977983; Sun, 15 Nov 2015 10:26:17 -0800 (PST) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id iy1sm31693866pbb.85.2015.11.15.10.26.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 10:26:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: NGie Cooper In-Reply-To: <5648CBA1.9010300@freebsd.org> Date: Sun, 15 Nov 2015 10:26:15 -0800 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2C639B6D-578D-4D23-8863-44F9DD74C693@gmail.com> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> <5648CBA1.9010300@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:26:18 -0000 > On Nov 15, 2015, at 10:14, Allan Jude wrote: =E2=80=A6 > You can setup an atexit() call to call xo_finish automatically when = the > program exits. The original changes to uptime had a few other issues, > which I fixed. Programmers are lazy. Telling someone =E2=80=9Cyou need to setup an = atexit handler that calls xo_finish=E2=80=9D will be met with teeth = gnashing and complaints (I=E2=80=99ve had to deal with a bunch of people = who complain that FreeBSD is not Linux at $work; I don=E2=80=99t have = any interest in fighting developers over stuff like this). > Yes, but, a typo in any change is likely to cause a problem. This is = not > a problem unique to libxo. Yes, but there=E2=80=99s a big difference between a typo in !libxo with = the meta language, and a typo in libxo. Typo in !libxo: typos visible, = unless it was something silly like mis-spelling \n (which doesn=E2=80=99t = seem to happen much); typo in libxo: xo_emit call is invalid (no = output)/segfaults. Fortunately libxo seems to support __printflike :). Thanks, -NGie= From owner-freebsd-current@freebsd.org Sun Nov 15 18:30:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92DEEA2FF80 for ; Sun, 15 Nov 2015 18:30:16 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 592D41A6B; Sun, 15 Nov 2015 18:30:16 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by igbxm8 with SMTP id xm8so43734226igb.1; Sun, 15 Nov 2015 10:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kd52P4okpFDYiRAA4bjt2Rcy0Rxfx+bMvitrPFWk2Y4=; b=QKqPfDTqWCSG4h0apRcCPU9grGRo0Oud11fXtQVq+rWqJEnQIDN6vbSXS6UI0Rs+G8 MtFYtDPtyZUqQkSF1hQzTKdFqFP8LcO3rtzoVmCPumbSz1BkwWleke4HN+tTA2l2IPvs 5ue0ETKtLRj+fLKU/FZsLYxNJIjyqsPvAvcBOJO7CAnfmWNnEh3wWNjFsk+9Ck5vzAP0 xrVtQWRwvZMMOLC4NyCh1zafTOe29T+DqF+vlV4rFLWeifBEWWkGlmy67ldmd4QBIZ5z 4zPMrzpaxnZW6xDIXkCCLZ3h9XHH6om0m3J9qyuJwUuZc/tPMHODBrhJ3xOGqlHxg1tK PZjQ== X-Received: by 10.50.55.72 with SMTP id q8mr13305001igp.2.1447612215795; Sun, 15 Nov 2015 10:30:15 -0800 (PST) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id lo2sm5017998igb.17.2015.11.15.10.30.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 10:30:14 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: NGie Cooper In-Reply-To: <5648CD87.4020305@freebsd.org> Date: Sun, 15 Nov 2015 10:30:12 -0800 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <35BF04D9-332D-49E5-8927-AB542CADDB98@gmail.com> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> <5648CA60.3060800@freebsd.org> <5648CC0F.6050708@freebsd.org> <5648CD87.4020305@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:30:16 -0000 > On Nov 15, 2015, at 10:23, Allan Jude wrote: =85 > Also, libxo now supports the versioning of output, to make it possible > for your json parser to detect when a change to the schema has been = made. This is the ideal scenario, yes, if there was some design around the = libxo=92ification (even man page documentation would have been nice, but = that wasn=92t done :/). However, as I=92ve said many times before: no = spec, no tests -> not useful to endorse to others because things can = change at any given point in time and I don=92t want to be the support = hub for all things libxo at $work. Thanks, -NGie= From owner-freebsd-current@freebsd.org Sun Nov 15 19:12:35 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46FEBA3084F for ; Sun, 15 Nov 2015 19:12:35 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5C8A130C; Sun, 15 Nov 2015 19:12:33 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BL2PR05CA0048.namprd05.prod.outlook.com (10.255.226.48) by BN1PR05MB058.namprd05.prod.outlook.com (10.255.202.145) with Microsoft SMTP Server (TLS) id 15.1.325.17; Sun, 15 Nov 2015 19:12:25 +0000 Received: from BN1AFFO11FD039.protection.gbl (2a01:111:f400:7c10::196) by BL2PR05CA0048.outlook.office365.com (2a01:111:e400:c04::48) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Sun, 15 Nov 2015 19:12:24 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1AFFO11FD039.mail.protection.outlook.com (10.58.52.243) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Sun, 15 Nov 2015 19:12:24 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 15 Nov 2015 11:12:23 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAFJCMD68198; Sun, 15 Nov 2015 11:12:22 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id EF627580A9; Sun, 15 Nov 2015 11:12:21 -0800 (PST) To: Garrett Cooper CC: Andrey Chernov , Adrian Chadd , Dan Partelly , freebsd-current , Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? In-Reply-To: <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> Comments: In-reply-to: Garrett Cooper message dated "Sun, 15 Nov 2015 10:06:40 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10657.1447614741.1@chaos> Date: Sun, 15 Nov 2015 11:12:21 -0800 Message-ID: <6506.1447614741@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD039; 1:/TjpIvZpsF3ZyWSmSPPkr5XmpdSRbxdoMCgAs51kH7/FNUshBvSbDzufd0OOnPHrrlD3dHT8wCxdy2HUwrhUSqZLUIf/n3zRXA8cx83JFE2FrIdqPNunEPA0OpvnR0vtxv84SxwRggZy8v6D9pxNUefEIjhK0s/LaS7WvCszTkL98xxBSqIgtByHcu0P/hCEaWoAwTtbK701w5Js2nMKpPq5jyyKrtsXgSiYAfq4gDHsEIemsWmKYB8YlqME2/x70p9ERjwzVGXKUkcenTB5kNtxUvn7jBc5fTmtbWseW/ySXh2k3sI6+yWS5piBqYATmgKymkJgEBEiaUWhcKNaRMGiOKGbyN/0qjb6rIXiEHs51HHePx2mhwNz8rjlFrT9 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(199003)(76506005)(69596002)(81156007)(86362001)(47776003)(11100500001)(50986999)(6806005)(77096005)(2950100001)(107886002)(19580395003)(5007970100001)(19580405001)(97736004)(87936001)(4001430100002)(57986006)(110136002)(46406003)(105596002)(23726002)(33716001)(97756001)(106466001)(93886004)(189998001)(5001960100002)(586003)(50226001)(1411001)(92566002)(117636001)(5008740100001)(50466002)(76176999)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB058; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB058; 2:eX8V2i8204zl7SWDXtE1fpzblW388eBu8lUhrzrxDylQz0XwN/DrW4ExgrGEzYRDY2/eYFY6nMntvwp0WH6LE91rAUKfr8GOiPxnD5Y3NfDooI7au5dcms30ze0OxuMoKMu1zUpqhGp8TsOdtS4hcL2aazwns80qDUNq+fL2+bE=; 3:rrFxdsVWVh/S/Ju5H5gBn1uXgZoNceF/RmsfyT5gU9oMIBBTiTVmbF7Ub53d1CA/8NkFizpnqNt36BcF0habLfHaKsI8iPvbmSEU0H4fS1hqTlIUfJ4F12JkXA/W1ZnyUiyJGP//vTjGJUYb1JTks++m1+o/hWvUNY0JG0sfYX0fDUNLBRCTShgLAkgkrctpkkQNIZ82a2VKsAZxz3RwiyPvHiBlHtIbdgxVsLs7Vmc=; 25:JSsPoLAaSNJ3oHgsQaXTBdAaLuQ2hqwkn+Fl62/YTlmV9QxvBgczxgZWuZrX/docIP0NAhGm47Rm5LZpiQHmDFYDj6JekXmY+xt/tArVI4W/gm66lVTEFCQnoqi4LeVcQ+ow/8LAIC34weXH31YcQSTwXbuvplrTJu/HUFVByLQlmG1HXs9gcsAfNQ3bz/hevEfMSFE7aTuzey0Jn0enm18qAaLKBlBG661vkJl4qhnuL7TG3xrc+rfpkxKQ92kg X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB058; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB058; 20:dqnyfvTs0owaYwniHxp3GzI3TCjFYqi/huJVqenOWlrmTJSL2MWplZ1nbCRs+XBcAuAsq+ItPDpl4T2MQ2vmZJajrmQzTYOjl3x3/9cwsyHFbQL8hpHQ6rWYIDl2IrDSJ0rt30qufWsj+LUjrAg12u5LObz2cK05853xXZgjs5wpZjI4abkFtsR9P1BRC1b/aNODXG14yxxOpwdgsg1giNcXbQd4YEWik1Qvf/z2mdGWr9YIM6LO1Vm928/ZVjKe2FHPL0JEidbHFiZrG17kVtqKTrLsWeYSv65ynUqkF6WsKHul+RB4T/W022ulGxY9M8kbzq6g0KVMD9g+fx4Y3J/sKpwNid2rrwZ45+8nJ9efmaNvHrSPgtCe2M3NlLTBte+4g2c2zlFi0dlFzS/pPlPv79PU2tTGyENIA5rSnrJLi9OETDMwcb26HccEVtXhMCVEVUM+HVmETh5RSAZUMUmiRrrfnbqufmeGKOve0hz//mhO/Eu3YXKPGQk16hXp; 4:wYmI8p4SEjtVcfKi+n8P5mJIFAY74D12k5igKJgXC/+NoYg7H0CzqR6iH0fEdWCwcY3tTZpKZ06oNUATlQGNbZz8QjcZnXSOyc3GABfsskSQdSVfIoH4q9Ozil/uJt2yksSgJUHaf8iAiF6TfHpA1zTjt5ju4o2XusWCdSoQecQBN3+G6ahxe7wkY7MqTpPmeJovN88lmO/ooksyO877PGHjuNQ8Fqh7FR2bgHgYippe21T27kptrx8r0TEaiqGI2Ju0flqtgW7gTHTbg6llX6eXZrsVFTTIQTYxCypUgOV3hF6Wpdb1UIIru9d0kieIvvCWFs+F3g2htHH+GkSnG2v3RkoB+bRry1cfZ2QZzVGcmtVz64ShRhj8e1kBTJGt X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR05MB058; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB058; X-Forefront-PRVS: 0761DE1EDD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB058; 23:i6bIroZSC4Z0XQBNF56fLQRacjYOZq/0EMRkRL1OG6?= =?us-ascii?Q?3T3XD+reRvJT/WAmZH4bOS4L62XcdbsumawITG4pdsdMyWyyxb6D+QcEq57o?= =?us-ascii?Q?ECyrwKzUG1BiBIl2Nr5zgu6i3XMbxQ9hnleLpQs+lZlNZOzJpUjjFplgxj4h?= =?us-ascii?Q?WCVnAdr0upYQpC+MVpsLX9yDJHt3gWW1ljC8yW7lNBPO52xWz8WDGUJ130M1?= =?us-ascii?Q?87viIiniSTNxwRZUKf+4hXp60Fty0Vw6cL3VTgEBU0WtPcjhEtlnV+JrP8et?= =?us-ascii?Q?U8TNGHeqSHjjeT2shhWabvA+qgVQceL2Uk0vkVlDMDbzmrA0M/LRDQb5L1da?= =?us-ascii?Q?ysqlsJTv8SYwOTPjoPr+vjNOIHZhHt08JAfqI/EsAgZ/j+2ftSsz9iwkVJr6?= =?us-ascii?Q?ewQwMQninzveWP7GqGaDfLCoqLugovLXSBpt1WFULHoxzSNfRVhdWUNLejao?= =?us-ascii?Q?ftHiEjXjIxstZSBWdeieNFTiT2KwwJbFc5ZpOzBpkgx4zOFqZjg3LX5UV1bO?= =?us-ascii?Q?ISVbgNbSwZQsHn6mNGPwUQWMpER5Hqn4mKQmc4pQgybfMA502HLNbj3GkZI5?= =?us-ascii?Q?TCv/DRoP4LlIfKDmhcV39Yh4XsQkGDlC1IGqGkrznoX1XIZSAFnejE9IjWmh?= =?us-ascii?Q?oUzls0RbcHF01bsURgt3lc18pk9F1biRCrSjhHvtVXwAniPgLc2725M/O24m?= =?us-ascii?Q?fvIHA5HInUn5GC6b+Ot+5Attg9o6yyenjyGfX+TsA5DabhGdvniD4YX79mJe?= =?us-ascii?Q?XDVhR+RuZXZkbptYAOBkifSBUDUhtTnrMKE/Y65vBNDPGtBHHwPc5YIVLRUP?= =?us-ascii?Q?cjvr22ev3Iq4h3p00hQdBXEO6+C+LH/0tJ9JHyqVp8HEOGj/HouO5gtQqtga?= =?us-ascii?Q?wkmbcBj1MI/9p9SYjTgwihsaumaUOSOrZdUKRICIbQvBcUbNdSvmZW8HNQbN?= =?us-ascii?Q?Z891db3LWS1fPjzajI9sMHN39P+d9HbOQ0iuKdn/2aT+ekxVNBrP+pYljZrY?= =?us-ascii?Q?gs2aURfQHPyzpgKs9e6MgYwmHz6eROIHHQVdtjIfNPuadYFk92ocwEZieKyN?= =?us-ascii?Q?NhThseusSobx1Yx0oqj5puCRfZWg/l6AJpW2OBS0+2PS7NyXziq3GhLRhUiW?= =?us-ascii?Q?WJayG7EqXwGsPxO/DlJWkMZX6uD0cc?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB058; 5:wn4a8FmWuSxIUo7Dw6TaqbBUZ8OTpsEr1CIsTRg3CCR3eSbMRUdBav5vcphmC26THClilNaDyobnAD88dzNewfG6e4vgKQQLtYBx8mXd+Md4KxSQsk/duDb9nQFHPCOEJo5c20FhfzoV0ZGAQnt4GA==; 24:9svolxcYssmc+QgxaKbr7dPefOPjIHmhAOl8Du1Tsqb6d3DaQd8UIlF3pqThLJiryRH0zHLjEF69Vus3TwDdG4b3OHuYww6ff+G1mpzwx8k=; 20:KICQLvGThR/aDzk3+GHfewyOy8UhTGXJyg0tj4Wx60wcMklgaPifjcGM++p5eQmpmxDZ54t4965ZeiAbF/EgVQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2015 19:12:24.1726 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB058 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 19:12:35 -0000 Garrett Cooper wrote: > We lack a [dtd/json] spec for tools, so programming for xo'ification > doesn't seems like the best idea in the world to me from a end-user > sysadmin/developer perspective. A dtd etc is good for sure, and we (Juniper) do have them, as well as ui-police to help ensure things go smoothly - even that doesn't catch everything. But all that is a layer above something like libxo - which is just the mechanism. All that is fundamentally required to obtain a reasonable result is consistent use of verbs and nouns. > I could just as easily use standard tools like awk, grep, sed, and > more advanced languages like perl or Python to parse output, and If you are parsing plain text output - that is all the data you have and it is a small subset of what the app knows. XML and HTML allow the app to provide lots of ancilliary/meta data that is invaluable in doing clever things with the data. Eg. by simply marking something as hostname/ipaddr the ui can hook in pulldown menus to let you do things with that info. I don't know if we've released anything I can point you at easily but 5 minutes would suffice to make a believer of you ;-) BTW libifying apps is a nice thing too, but does not eliminate the need to do all the exact same UI work - just changes where you do it, since the libraries themselves would need to be XO'ified to be useful. From owner-freebsd-current@freebsd.org Sun Nov 15 19:26:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9C44A30A69 for ; Sun, 15 Nov 2015 19:26:05 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E49B18DD; Sun, 15 Nov 2015 19:26:04 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id tAFJPsMi093738 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2015 19:25:57 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: David Chisnall In-Reply-To: <6506.1447614741@chaos> Date: Sun, 15 Nov 2015 19:25:45 +0000 Cc: Garrett Cooper , Andrey Chernov , Adrian Chadd , Dan Partelly , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> <6506.1447614741@chaos> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 19:26:05 -0000 On 15 Nov 2015, at 19:12, Simon J. Gerraty wrote: >=20 > Garrett Cooper wrote: >> We lack a [dtd/json] spec for tools, so programming for xo'ification >> doesn't seems like the best idea in the world to me from a end-user >> sysadmin/developer perspective. >=20 > A dtd etc is good for sure, and we (Juniper) do have them, as well as > ui-police to help ensure things go smoothly - even that doesn't catch > everything. At the GSoC Mentor Summit, someone from GitHub pointed me at a tool[1] = for generating schemas from JSON (which can then be refined manually) = and can be used for validating that the schema is still respected in = newer versions. I hope to integrate something like this into our = regression test suite before 11. For the people complaining that there are no command-line tools for = filtering JSON in shell scripts, I=E2=80=99d suggest that they look at = JQ[2]. I=E2=80=99m not sure if it=E2=80=99s worth bringing it into = base, but being able to install it easily (textproc/jq, no dependencies) = from ports suddenly makes a load of stuff trivial with shell scripts = that were either incredibly hard or impossible prior to libxo. David [1] https://github.com/perenecabuto/json_schema_generator [2] https://stedolan.github.io/jq/ From owner-freebsd-current@freebsd.org Sun Nov 15 19:44:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C1CBA30D58 for ; Sun, 15 Nov 2015 19:44:44 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id A1A831114; Sun, 15 Nov 2015 19:44:43 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 3E2A312102; Sun, 15 Nov 2015 21:44:42 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <5648C89C.2050206@freebsd.org> Date: Sun, 15 Nov 2015 21:44:42 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 19:44:44 -0000 > I would welcome competing ideas/solutions, but someone would have to = actually build them, not just > rattle off some ideas on the mailing list. Am I missing the point of a mailing list ? it is a place to present and = exchange ideas, ask why some things are the way they are , and get = criticism. Rattling ideas is generally where it all starts. You cant = realistically expect one to start a pervasive project like transactioanl = databases for an OS configuration without not one mailing list = discussion, but a lot of consultation.=20 > There are tools available to filter json/ucl output yes they are. vim is one . sed is another. awk is the third =E2=80=A6 = But a pipe needs both ends to talk the same language. I can generate = json as output, i can filter it , but what tool in FreeBSD will accept = it as input ? None. A > and my forthcoming uclcmd What uclcmd does / will do ? =20 > UCL is a good solution to having a universal config file, and is = better > than the bespoke config files each utility has I agree with you, if you manage somehow to port every ad-hoc database = FreeBSD has in base to ucl, (including all the bestiary we have in /etc = ) and offer tools to parse them in the rc init system to fetch the = settings. I dont expect this to be done in one release , but do you tend = towards this in your projects ? One config format to rule them all is = good. Yet another config format in selected places in base is evil. > A transactional database > might be better (for some uses, likely less so for some people), but I > don't hear anyone volunteering to do that work. IIRC Solaris uses sqlite. Might be a decent solution. ( a lot of the ad = hoc unix databases are relational databases in disguise, with unix tools = acting as operators) And if you abstract a config interface API over = UCL, someone could benefit from it by plugging in a transactional = backend one day. All you would have to do is not directly plug in UCL, = but work on a orthogonal abstract API. You could even model it after = UCL API. Please consider it.=20 > I would welcome competing ideas/solutions, but someone would have to = actually build them, not just >=20 > lib-izing all of the utilities instead of using libxo is a better > solution. It would likely be gratefully accepted if someone were to do > it, but most likely, no one will. >=20 > libxo exists now, and most applications can be converted very quickly > (although care does need to be taken, and it sometimes has not been). >=20 > There are tools available to filter json/ucl output, namely = textproc/jq > and my forthcoming uclcmd >=20 > One of the major other consumers of the json/xml output of libxo, is = web > control panels. This is why Juniper is doing the work, and I can think > of a list of other appliance vendors who would love to replace fragile > per-application parsers with a json parser to extract data from = various > command line tools. >=20 > UCL is a good solution to having a universal config file, and is = better > than the bespoke config files each utility has. A transactional = database > might be better (for some uses, likely less so for some people), but I > don't hear anyone volunteering to do that work. >=20 > So, libxo and libucl may not be the very best solutions, but they are > the ones that are moving forward. I would welcome competing > ideas/solutions, but someone would have to actually build them, not = just > rattle off some ideas on the mailing list. >=20 > --=20 > Allan Jude >=20 From owner-freebsd-current@freebsd.org Sun Nov 15 19:48:17 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7342AA30DE4 for ; Sun, 15 Nov 2015 19:48:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1B51352 for ; Sun, 15 Nov 2015 19:48:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6DD921F6 for ; Sun, 15 Nov 2015 19:48:17 +0000 (UTC) Date: Sun, 15 Nov 2015 19:48:17 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: freebsd-current@freebsd.org Message-ID: <1675482905.12.1447616897417.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <739674687.5.1447606278322.JavaMail.jenkins@jenkins-9.freebsd.org> References: <739674687.5.1447606278322.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #2744 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 19:48:17 -0000 See ------------------------------------------ [...truncated 3362 lines...] -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> =3D=3D=3D> lib/libc/tests (install) install -o root -g wheel -m 444 Kyuafile.auto =3D=3D=3D> lib/libc/tests/tls_dso (install) install -C -o root -g wheel -m 444 libh_tls_dynamic.a install -C -o root -g wheel -m 444 libh_tls_dynamic_p.a install -s -o root -g wheel -m 444 libh_tls_dynamic.so.1 install -l s libh_tls_dynamic.so.1 =3D=3D=3D> lib/libc/tests/c063 (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.facce= ssat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dfaccessat_test install) install -s -o root -g wheel -m 555 faccessat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fchmo= dat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfchmodat_test install) install -s -o root -g wheel -m 555 fchmodat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fchow= nat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfchownat_test install) install -s -o root -g wheel -m 555 fchownat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fexec= ve_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dfexecve_test install) install -s -o root -g wheel -m 555 fexecve_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fstat= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dfstatat_test install) install -s -o root -g wheel -m 555 fstatat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.linka= t_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Make= file _RECURSING_PROGS=3D PROG=3Dlinkat_test install) install -s -o root -g wheel -m 555 linkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mkdir= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dmkdirat_test install) install -s -o root -g wheel -m 555 mkdirat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mkfif= oat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dmkfifoat_test install) install -s -o root -g wheel -m 555 mkfifoat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mknod= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dmknodat_test install) install -s -o root -g wheel -m 555 mknodat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.opena= t_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Make= file _RECURSING_PROGS=3D PROG=3Dopenat_test install) install -s -o root -g wheel -m 555 openat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.readl= inkat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/= Makefile _RECURSING_PROGS=3D PROG=3Dreadlinkat_test install) install -s -o root -g wheel -m 555 readlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.renam= eat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Drenameat_test install) install -s -o root -g wheel -m 555 renameat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.symli= nkat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dsymlinkat_test install) install -s -o root -g wheel -m 555 symlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.unlin= kat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dunlinkat_test install) install -s -o root -g wheel -m 555 unlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.utime= nsat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dutimensat_test install) install -s -o root -g wheel -m 555 utimensat_test =3D=3D=3D> lib/libc/tests/db (install) install -o root -g wheel -m 555 db_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/db/README (cd /builds/FreeBSD_HEAD/lib/libc/tests/db && DEPENDFILE=3D.depend.h_db N= O_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/db/Makefile _RECUR= SING_PROGS=3D PROG=3Dh_db install) install -s -o root -g wheel -m 555 h_db =3D=3D=3D> lib/libc/tests/gen (install) install -o root -g wheel -m 444 Kyuafile.auto =3D=3D=3D> lib/libc/tests/gen/execve (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/execve && DEPENDFILE=3D.depend= .execve_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen= /execve/Makefile _RECURSING_PROGS=3D PROG=3Dexecve_test install) install -s -o root -g wheel -m 555 execve_test =3D=3D=3D> lib/libc/tests/gen/posix_spawn (install) install -o root -g wheel -m 555 h_nonexec install -o root -g wheel -m 555 h_zero install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_fileactions NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/te= sts/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_fileactions ins= tall) install -s -o root -g wheel -m 555 h_fileactions (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_spawn NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/ge= n/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_spawn install) install -s -o root -g wheel -m 555 h_spawn (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_spawnattr NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/test= s/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_spawnattr install= ) install -s -o root -g wheel -m 555 h_spawnattr (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.fileactions_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc= /tests/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dfileactions_tes= t install) install -s -o root -g wheel -m 555 fileactions_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.spawn_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests= /gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dspawn_test install) install -s -o root -g wheel -m 555 spawn_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.spawnattr_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/t= ests/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dspawnattr_test i= nstall) install -s -o root -g wheel -m 555 spawnattr_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.arc4ra= ndom_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Darc4random_test install) install -s -o root -g wheel -m 555 arc4random_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fmtche= ck2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Mak= efile _RECURSING_PROGS=3D PROG=3Dfmtcheck2_test install) install -s -o root -g wheel -m 555 fmtcheck2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fmtmsg= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dfmtmsg_test install) install -s -o root -g wheel -m 555 fmtmsg_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fnmatc= h2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Dfnmatch2_test install) install -s -o root -g wheel -m 555 fnmatch2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpclas= sify2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dfpclassify2_test install) install -s -o root -g wheel -m 555 fpclassify2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ftw_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Dftw_test install) install -s -o root -g wheel -m 555 ftw_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.popen_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dpopen_test install) install -s -o root -g wheel -m 555 popen_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.posix_= spawn_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dposix_spawn_test install) install -s -o root -g wheel -m 555 posix_spawn_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.wordex= p_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dwordexp_test install) install -s -o root -g wheel -m 555 wordexp_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.alarm_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dalarm_test install) install -s -o root -g wheel -m 555 alarm_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.assert= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dassert_test install) install -s -o root -g wheel -m 555 assert_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.basedi= rname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dbasedirname_test install) install -s -o root -g wheel -m 555 basedirname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.dir_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Ddir_test install) install -s -o root -g wheel -m 555 dir_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.floatu= nditf_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dfloatunditf_test install) install -s -o root -g wheel -m 555 floatunditf_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fnmatc= h_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dfnmatch_test install) install -s -o root -g wheel -m 555 fnmatch_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpclas= sify_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfpclassify_test install) install -s -o root -g wheel -m 555 fpclassify_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpsetm= ask_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Mak= efile _RECURSING_PROGS=3D PROG=3Dfpsetmask_test install) install -s -o root -g wheel -m 555 fpsetmask_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpsetr= ound_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfpsetround_test install) install -s -o root -g wheel -m 555 fpsetround_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ftok_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dftok_test install) install -s -o root -g wheel -m 555 ftok_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.getcwd= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dgetcwd_test install) install -s -o root -g wheel -m 555 getcwd_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.getgre= nt_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Dgetgrent_test install) install -s -o root -g wheel -m 555 getgrent_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.glob_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dglob_test install) install -s -o root -g wheel -m 555 glob_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.humani= ze_number_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/g= en/Makefile _RECURSING_PROGS=3D PROG=3Dhumanize_number_test install) install -s -o root -g wheel -m 555 humanize_number_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.isnan_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Disnan_test install) install -s -o root -g wheel -m 555 isnan_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.nice_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dnice_test install) install -s -o root -g wheel -m 555 nice_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.pause_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dpause_test install) install -s -o root -g wheel -m 555 pause_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.raise_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Draise_test install) install -s -o root -g wheel -m 555 raise_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.realpa= th_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Drealpath_test install) install -s -o root -g wheel -m 555 realpath_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.setdom= ainname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen= /Makefile _RECURSING_PROGS=3D PROG=3Dsetdomainname_test install) install -s -o root -g wheel -m 555 setdomainname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.sethos= tname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dsethostname_test install) install -s -o root -g wheel -m 555 sethostname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.sleep_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dsleep_test install) install -s -o root -g wheel -m 555 sleep_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.syslog= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dsyslog_test install) install -s -o root -g wheel -m 555 syslog_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.time_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dtime_test install) install -s -o root -g wheel -m 555 time_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ttynam= e_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dttyname_test install) install -s -o root -g wheel -m 555 ttyname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.vis_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Dvis_test install) install -s -o root -g wheel -m 555 vis_test =3D=3D=3D> lib/libc/tests/hash (install) install -o root -g wheel -m 555 hash_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/hash/data/md5test-in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib= /libc/hash/data/md5test-out /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/l= ibc/hash/data/sha1test-in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/lib= c/hash/data/sha1test-out /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc= /hash/data/sha1test2-out (cd /builds/FreeBSD_HEAD/lib/libc/tests/hash && DEPENDFILE=3D.depend.h_has= h NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/hash/Makefile = _RECURSING_PROGS=3D PROG=3Dh_hash install) install -s -o root -g wheel -m 555 h_hash (cd /builds/FreeBSD_HEAD/lib/libc/tests/hash && DEPENDFILE=3D.depend.sha2_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/hash/Makefi= le _RECURSING_PROGS=3D PROG=3Dsha2_test install) install -s -o root -g wheel -m 555 sha2_test =3D=3D=3D> lib/libc/tests/inet (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/inet && DEPENDFILE=3D.depend.inet_= network_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/ine= t/Makefile _RECURSING_PROGS=3D PROG=3Dinet_network_test install) install -s -o root -g wheel -m 555 inet_network_test =3D=3D=3D> lib/libc/tests/net (install) install -o root -g wheel -m 555 nsdispatch_test install -o root -g wheel -m 555 protoent_test install -o root -g wheel -m 555 servent_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/net/hosts /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/net/r= esolv.conf (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_nsd_= recurse NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Make= file _RECURSING_PROGS=3D PROG=3Dh_nsd_recurse install) install -s -o root -g wheel -m 555 h_nsd_recurse (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_prot= oent NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefil= e _RECURSING_PROGS=3D PROG=3Dh_protoent install) install -s -o root -g wheel -m 555 h_protoent (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_serv= ent NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefile= _RECURSING_PROGS=3D PROG=3Dh_servent install) install -s -o root -g wheel -m 555 h_servent (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_dns_= server NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makef= ile _RECURSING_PROGS=3D PROG=3Dh_dns_server install) install -s -o root -g wheel -m 555 h_dns_server (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.ether_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefil= e _RECURSING_PROGS=3D PROG=3Dether_test install) install -s -o root -g wheel -m 555 ether_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.eui64_= aton_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Deui64_aton_test install) install -s -o root -g wheel -m 555 eui64_aton_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.eui64_= ntoa_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Deui64_ntoa_test install) install -s -o root -g wheel -m 555 eui64_ntoa_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.getpro= toent_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/M= akefile _RECURSING_PROGS=3D PROG=3Dgetprotoent_test install) install -s -o root -g wheel -m 555 getprotoent_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.ether_= aton_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Dether_aton_test install) install -s -o root -g wheel -m 555 ether_aton_test =3D=3D=3D> lib/libc/tests/regex (install) install -o root -g wheel -m 555 regex_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/regex/README /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/re= gex/data/anchor.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex= /data/backref.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/d= ata/basic.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/= bracket.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/c_= comments.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/c= omplex.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/err= or.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/meta.in= /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/nospec.in /b= uilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/paren.in /build= s/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/regress.in /builds/= FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_bounded.in /bui= lds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_multi.in /b= uilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_ordinary.= in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/startend.i= n /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/subexp.in /= builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/subtle.in /bui= lds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/word_bound.in /bu= ilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/zero.in /builds/= FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/basic.dat /builds= /FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/categorization.d= at /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/forced= assoc.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att= /leftassoc.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/dat= a/att/nullsubexpr.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/re= gex/data/att/repetition.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/l= ibc/regex/data/att/rightassoc.dat (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.h_re= gex NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/Makefi= le _RECURSING_PROGS=3D PROG=3Dh_regex install) install -s -o root -g wheel -m 555 h_regex (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.exha= ust_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/M= akefile _RECURSING_PROGS=3D PROG=3Dexhaust_test install) install -s -o root -g wheel -m 555 exhaust_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.rege= x_att_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex= /Makefile _RECURSING_PROGS=3D PROG=3Dregex_att_test install) install -s -o root -g wheel -m 555 regex_att_test =3D=3D=3D> lib/libc/tests/rpc (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.rpc_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Drpc_test install) install -s -o root -g wheel -m 555 rpc_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.xdr_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Dxdr_test install) install -s -o root -g wheel -m 555 xdr_test =3D=3D=3D> lib/libc/tests/stdio (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fdop= en_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfdopen_test install) install -s -o root -g wheel -m 555 fdopen_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fmem= open2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio= /Makefile _RECURSING_PROGS=3D PROG=3Dfmemopen2_test install) install -s -o root -g wheel -m 555 fmemopen2_test install: fmemopen2_test: No such file or directory *** Error code 71 Stop. make[8]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** Error code 1 Stop. make[7]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** Error code 1 Stop. make[6]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests *** Error code 1 Stop. make[5]: stopped in /builds/FreeBSD_HEAD/lib/libc *** Error code 1 Stop. make[4]: stopped in /builds/FreeBSD_HEAD/lib *** Error code 1 Stop. make[3]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[2]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@freebsd.org Sun Nov 15 19:48:53 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B80AA30E2F for ; Sun, 15 Nov 2015 19:48:53 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 20E5114D9 for ; Sun, 15 Nov 2015 19:48:52 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id EF2A212102; Sun, 15 Nov 2015 21:48:51 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <26127.1447610752@chaos> Date: Sun, 15 Nov 2015 21:48:51 +0200 Cc: Adrian Chadd , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <26127.1447610752@chaos> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 19:48:53 -0000 HI Simon, Thanks for the write-up . One question: >> The ability to get machine parsable output from OS components is a = big part of the success of Junos CLI, netconf etc. Once you get machine parsable output, and feed it to your GUIs , WEB, = other tools, and modify it, how do you feed it back to your underlying OS ?=20 From owner-freebsd-current@freebsd.org Sun Nov 15 20:04:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 727A7A30188 for ; Sun, 15 Nov 2015 20:04:22 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3200B1FA0 for ; Sun, 15 Nov 2015 20:04:21 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id D075512102; Sun, 15 Nov 2015 22:04:20 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: Date: Sun, 15 Nov 2015 22:04:20 +0200 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> To: Adrian Chadd X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 20:04:22 -0000 > It's all fine and good making technical decisions based on drawings > and handwaving and philosophizing, but at some point someone has to do > the code. HI Adrian, . What I eluded too is not a small project. It is something that would = need proper discussion and agreement, since it would be pervasive and = touch=20 critical parts of the OS, such as the init system, system config = databases , and add proper services management facility. It would also = benefit=20 from a new form of kernel IPC. It would need consensus from FreeBSD = board or whatever to have any chance of even starting up. Nobody in his=20= sane mind would start it otherwise. Most likely he would work in vain, =20 And when consensus that something HAS to be done will exist, and from = empty discussion you would have a implementation plan, when maybe the = FreeBSD foundation would get involved and sponsor such a important = project to see it done to the end. And there are efforts today to go down the path I mentioned, NextBSD is = the incarnation of such an effort. And while they offer code and they do = make progress I do not seeing anyone in FreeBSD beeing too eager to = commit that code :P (Im not saying that you should adapt launchd and add = another comapt layer for FreeBSD for mach ). I for one like what Solaris = does. What Im saying that such work would never be possible directly in = FreeBSD, because lack of consensus that anything serious should be done, = apart from patching on sides. I am saying that gathering consensus that something has to be done must = exist before any code is written . Else you wont get much.= From owner-freebsd-current@freebsd.org Sun Nov 15 21:57:23 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 678A0A2FC82 for ; Sun, 15 Nov 2015 21:57:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 49F971992 for ; Sun, 15 Nov 2015 21:57:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: by mailman.ysv.freebsd.org (Postfix) id 49EBDA2FC81; Sun, 15 Nov 2015 21:57:23 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49849A2FC80 for ; Sun, 15 Nov 2015 21:57:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B82971991 for ; Sun, 15 Nov 2015 21:57:22 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id tAFLv6nX020652 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Nov 2015 22:57:06 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id tAFLv6Bm020651; Sun, 15 Nov 2015 22:57:06 +0100 (CET) (envelope-from marius) Date: Sun, 15 Nov 2015 22:57:06 +0100 From: Marius Strobl To: David Wolfskill , current@freebsd.org Subject: Re: Wake on LAN broken (probably between r290542 - r290606)? Message-ID: <20151115215706.GH31931@alchemy.franken.de> References: <20151111143337.GN1235@albert.catwhisker.org> <20151114175636.GX91465@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20151114175636.GX91465@albert.catwhisker.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 15 Nov 2015 22:57:06 +0100 (CET) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 21:57:23 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Nov 14, 2015 at 09:56:36AM -0800, David Wolfskill wrote: > On Wed, Nov 11, 2015 at 06:33:37AM -0800, David Wolfskill wrote: > > ... > > But a quick perusal of > > doesn't show > > anything especially like a "smoking gun" -- to me, anyway. > > > > Can anyone else confirm or refute my observations? Or suggest a > > hint? I'll try narrowing it down myself, but I need to do it during > > times I'm at home (so I can manually power the machine back up when > > it fails to respond to WoL), so it may be a few days before I can > > accomplish much that way. > > .... > > r290565 still works; r290566 fails -- in my case. r290566 changed some > re(4) behavior, and the NIC on my affected machine is an re(4): > > re0@pci0:3:0:0: class=0x020000 card=0x05b71028 chip=0x816810ec rev=0x0c > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet > Controller' > class = network > subclass = ethernet > > from "pciconf -lv" while running: > > D freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1904 r290565M/290565:1100089: Sat Nov 14 09:44:33 PST 2015 root@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC amd64 > > I've placed a copy of a verbose dmes.boot in > . > > I'm happy to test suggested changes. > *sigh* Okay, could you please test whether the attached patch restores WOL capability for you? Marius --Qxx1br4bt0+wmkIi Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.diff" Index: if_re.c =================================================================== --- if_re.c (revision 290566) +++ if_re.c (working copy) @@ -3851,6 +3852,11 @@ re_setwol(struct rl_softc *sc) CSR_READ_1(sc, RL_GPIO) & ~0x01); } if ((ifp->if_capenable & IFCAP_WOL) != 0) { + if ((sc->rl_flags & RL_FLAG_8168G_PLUS) != 0) { + /* Disable RXDV gate. */ + CSR_WRITE_4(sc, RL_MISC, CSR_READ_4(sc, RL_MISC) & + ~0x00080000); + } re_set_rxmode(sc); if ((sc->rl_flags & RL_FLAG_WOL_MANLINK) != 0) re_set_linkspeed(sc); --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@freebsd.org Sun Nov 15 22:51:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4773A308B7 for ; Sun, 15 Nov 2015 22:51:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A1670127F for ; Sun, 15 Nov 2015 22:51:33 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 38062276 for ; Sun, 15 Nov 2015 22:51:34 +0000 (UTC) Date: Sun, 15 Nov 2015 22:51:34 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: freebsd-current@freebsd.org Message-ID: <684051696.16.1447627894171.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #2746 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 22:51:33 -0000 See ------------------------------------------ [...truncated 3362 lines...] -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> =3D=3D=3D> lib/libc/tests (install) install -o root -g wheel -m 444 Kyuafile.auto =3D=3D=3D> lib/libc/tests/tls_dso (install) install -C -o root -g wheel -m 444 libh_tls_dynamic.a install -C -o root -g wheel -m 444 libh_tls_dynamic_p.a install -s -o root -g wheel -m 444 libh_tls_dynamic.so.1 install -l s libh_tls_dynamic.so.1 =3D=3D=3D> lib/libc/tests/c063 (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.facce= ssat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dfaccessat_test install) install -s -o root -g wheel -m 555 faccessat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fchmo= dat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfchmodat_test install) install -s -o root -g wheel -m 555 fchmodat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fchow= nat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfchownat_test install) install -s -o root -g wheel -m 555 fchownat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fexec= ve_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dfexecve_test install) install -s -o root -g wheel -m 555 fexecve_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.fstat= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dfstatat_test install) install -s -o root -g wheel -m 555 fstatat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.linka= t_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Make= file _RECURSING_PROGS=3D PROG=3Dlinkat_test install) install -s -o root -g wheel -m 555 linkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mkdir= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dmkdirat_test install) install -s -o root -g wheel -m 555 mkdirat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mkfif= oat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dmkfifoat_test install) install -s -o root -g wheel -m 555 mkfifoat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.mknod= at_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Mak= efile _RECURSING_PROGS=3D PROG=3Dmknodat_test install) install -s -o root -g wheel -m 555 mknodat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.opena= t_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Make= file _RECURSING_PROGS=3D PROG=3Dopenat_test install) install -s -o root -g wheel -m 555 openat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.readl= inkat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/= Makefile _RECURSING_PROGS=3D PROG=3Dreadlinkat_test install) install -s -o root -g wheel -m 555 readlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.renam= eat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Drenameat_test install) install -s -o root -g wheel -m 555 renameat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.symli= nkat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dsymlinkat_test install) install -s -o root -g wheel -m 555 symlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.unlin= kat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/Ma= kefile _RECURSING_PROGS=3D PROG=3Dunlinkat_test install) install -s -o root -g wheel -m 555 unlinkat_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/c063 && DEPENDFILE=3D.depend.utime= nsat_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/c063/M= akefile _RECURSING_PROGS=3D PROG=3Dutimensat_test install) install -s -o root -g wheel -m 555 utimensat_test =3D=3D=3D> lib/libc/tests/db (install) install -o root -g wheel -m 555 db_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/db/README (cd /builds/FreeBSD_HEAD/lib/libc/tests/db && DEPENDFILE=3D.depend.h_db N= O_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/db/Makefile _RECUR= SING_PROGS=3D PROG=3Dh_db install) install -s -o root -g wheel -m 555 h_db =3D=3D=3D> lib/libc/tests/gen (install) install -o root -g wheel -m 444 Kyuafile.auto =3D=3D=3D> lib/libc/tests/gen/execve (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/execve && DEPENDFILE=3D.depend= .execve_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen= /execve/Makefile _RECURSING_PROGS=3D PROG=3Dexecve_test install) install -s -o root -g wheel -m 555 execve_test =3D=3D=3D> lib/libc/tests/gen/posix_spawn (install) install -o root -g wheel -m 555 h_nonexec install -o root -g wheel -m 555 h_zero install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_fileactions NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/te= sts/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_fileactions ins= tall) install -s -o root -g wheel -m 555 h_fileactions (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_spawn NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/ge= n/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_spawn install) install -s -o root -g wheel -m 555 h_spawn (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.h_spawnattr NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/test= s/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dh_spawnattr install= ) install -s -o root -g wheel -m 555 h_spawnattr (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.fileactions_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc= /tests/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dfileactions_tes= t install) install -s -o root -g wheel -m 555 fileactions_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.spawn_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests= /gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dspawn_test install) install -s -o root -g wheel -m 555 spawn_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen/posix_spawn && DEPENDFILE=3D.d= epend.spawnattr_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/t= ests/gen/posix_spawn/Makefile _RECURSING_PROGS=3D PROG=3Dspawnattr_test i= nstall) install -s -o root -g wheel -m 555 spawnattr_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.arc4ra= ndom_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Darc4random_test install) install -s -o root -g wheel -m 555 arc4random_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fmtche= ck2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Mak= efile _RECURSING_PROGS=3D PROG=3Dfmtcheck2_test install) install -s -o root -g wheel -m 555 fmtcheck2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fmtmsg= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dfmtmsg_test install) install -s -o root -g wheel -m 555 fmtmsg_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fnmatc= h2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Dfnmatch2_test install) install -s -o root -g wheel -m 555 fnmatch2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpclas= sify2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dfpclassify2_test install) install -s -o root -g wheel -m 555 fpclassify2_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ftw_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Dftw_test install) install -s -o root -g wheel -m 555 ftw_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.popen_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dpopen_test install) install -s -o root -g wheel -m 555 popen_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.posix_= spawn_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dposix_spawn_test install) install -s -o root -g wheel -m 555 posix_spawn_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.wordex= p_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dwordexp_test install) install -s -o root -g wheel -m 555 wordexp_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.alarm_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dalarm_test install) install -s -o root -g wheel -m 555 alarm_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.assert= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dassert_test install) install -s -o root -g wheel -m 555 assert_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.basedi= rname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dbasedirname_test install) install -s -o root -g wheel -m 555 basedirname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.dir_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Ddir_test install) install -s -o root -g wheel -m 555 dir_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.floatu= nditf_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dfloatunditf_test install) install -s -o root -g wheel -m 555 floatunditf_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fnmatc= h_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dfnmatch_test install) install -s -o root -g wheel -m 555 fnmatch_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpclas= sify_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfpclassify_test install) install -s -o root -g wheel -m 555 fpclassify_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpsetm= ask_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Mak= efile _RECURSING_PROGS=3D PROG=3Dfpsetmask_test install) install -s -o root -g wheel -m 555 fpsetmask_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.fpsetr= ound_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfpsetround_test install) install -s -o root -g wheel -m 555 fpsetround_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ftok_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dftok_test install) install -s -o root -g wheel -m 555 ftok_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.getcwd= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dgetcwd_test install) install -s -o root -g wheel -m 555 getcwd_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.getgre= nt_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Dgetgrent_test install) install -s -o root -g wheel -m 555 getgrent_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.glob_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dglob_test install) install -s -o root -g wheel -m 555 glob_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.humani= ze_number_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/g= en/Makefile _RECURSING_PROGS=3D PROG=3Dhumanize_number_test install) install -s -o root -g wheel -m 555 humanize_number_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.isnan_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Disnan_test install) install -s -o root -g wheel -m 555 isnan_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.nice_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dnice_test install) install -s -o root -g wheel -m 555 nice_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.pause_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dpause_test install) install -s -o root -g wheel -m 555 pause_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.raise_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Draise_test install) install -s -o root -g wheel -m 555 raise_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.realpa= th_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Make= file _RECURSING_PROGS=3D PROG=3Drealpath_test install) install -s -o root -g wheel -m 555 realpath_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.setdom= ainname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen= /Makefile _RECURSING_PROGS=3D PROG=3Dsetdomainname_test install) install -s -o root -g wheel -m 555 setdomainname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.sethos= tname_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/M= akefile _RECURSING_PROGS=3D PROG=3Dsethostname_test install) install -s -o root -g wheel -m 555 sethostname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.sleep_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefil= e _RECURSING_PROGS=3D PROG=3Dsleep_test install) install -s -o root -g wheel -m 555 sleep_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.syslog= _test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefi= le _RECURSING_PROGS=3D PROG=3Dsyslog_test install) install -s -o root -g wheel -m 555 syslog_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.time_t= est NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile= _RECURSING_PROGS=3D PROG=3Dtime_test install) install -s -o root -g wheel -m 555 time_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.ttynam= e_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makef= ile _RECURSING_PROGS=3D PROG=3Dttyname_test install) install -s -o root -g wheel -m 555 ttyname_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/gen && DEPENDFILE=3D.depend.vis_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/gen/Makefile = _RECURSING_PROGS=3D PROG=3Dvis_test install) install -s -o root -g wheel -m 555 vis_test =3D=3D=3D> lib/libc/tests/hash (install) install -o root -g wheel -m 555 hash_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/hash/data/md5test-in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib= /libc/hash/data/md5test-out /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/l= ibc/hash/data/sha1test-in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/lib= c/hash/data/sha1test-out /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc= /hash/data/sha1test2-out (cd /builds/FreeBSD_HEAD/lib/libc/tests/hash && DEPENDFILE=3D.depend.h_has= h NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/hash/Makefile = _RECURSING_PROGS=3D PROG=3Dh_hash install) install -s -o root -g wheel -m 555 h_hash (cd /builds/FreeBSD_HEAD/lib/libc/tests/hash && DEPENDFILE=3D.depend.sha2_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/hash/Makefi= le _RECURSING_PROGS=3D PROG=3Dsha2_test install) install -s -o root -g wheel -m 555 sha2_test =3D=3D=3D> lib/libc/tests/inet (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/inet && DEPENDFILE=3D.depend.inet_= network_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/ine= t/Makefile _RECURSING_PROGS=3D PROG=3Dinet_network_test install) install -s -o root -g wheel -m 555 inet_network_test =3D=3D=3D> lib/libc/tests/net (install) install -o root -g wheel -m 555 nsdispatch_test install -o root -g wheel -m 555 protoent_test install -o root -g wheel -m 555 servent_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/net/hosts /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/net/r= esolv.conf (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_nsd_= recurse NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Make= file _RECURSING_PROGS=3D PROG=3Dh_nsd_recurse install) install -s -o root -g wheel -m 555 h_nsd_recurse (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_prot= oent NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefil= e _RECURSING_PROGS=3D PROG=3Dh_protoent install) install -s -o root -g wheel -m 555 h_protoent (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_serv= ent NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefile= _RECURSING_PROGS=3D PROG=3Dh_servent install) install -s -o root -g wheel -m 555 h_servent (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.h_dns_= server NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makef= ile _RECURSING_PROGS=3D PROG=3Dh_dns_server install) install -s -o root -g wheel -m 555 h_dns_server (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.ether_= test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Makefil= e _RECURSING_PROGS=3D PROG=3Dether_test install) install -s -o root -g wheel -m 555 ether_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.eui64_= aton_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Deui64_aton_test install) install -s -o root -g wheel -m 555 eui64_aton_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.eui64_= ntoa_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Deui64_ntoa_test install) install -s -o root -g wheel -m 555 eui64_ntoa_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.getpro= toent_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/M= akefile _RECURSING_PROGS=3D PROG=3Dgetprotoent_test install) install -s -o root -g wheel -m 555 getprotoent_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/net && DEPENDFILE=3D.depend.ether_= aton_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/net/Ma= kefile _RECURSING_PROGS=3D PROG=3Dether_aton_test install) install -s -o root -g wheel -m 555 ether_aton_test =3D=3D=3D> lib/libc/tests/regex (install) install -o root -g wheel -m 555 regex_test install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/contrib/netbsd-tests/= lib/libc/regex/README /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/re= gex/data/anchor.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex= /data/backref.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/d= ata/basic.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/= bracket.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/c_= comments.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/c= omplex.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/err= or.in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/meta.in= /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/nospec.in /b= uilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/paren.in /build= s/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/regress.in /builds/= FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_bounded.in /bui= lds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_multi.in /b= uilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/repet_ordinary.= in /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/startend.i= n /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/subexp.in /= builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/subtle.in /bui= lds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/word_bound.in /bu= ilds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/zero.in /builds/= FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/basic.dat /builds= /FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/categorization.d= at /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att/forced= assoc.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/data/att= /leftassoc.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/regex/dat= a/att/nullsubexpr.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/re= gex/data/att/repetition.dat /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/l= ibc/regex/data/att/rightassoc.dat (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.h_re= gex NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/Makefi= le _RECURSING_PROGS=3D PROG=3Dh_regex install) install -s -o root -g wheel -m 555 h_regex (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.exha= ust_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex/M= akefile _RECURSING_PROGS=3D PROG=3Dexhaust_test install) install -s -o root -g wheel -m 555 exhaust_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/regex && DEPENDFILE=3D.depend.rege= x_att_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/regex= /Makefile _RECURSING_PROGS=3D PROG=3Dregex_att_test install) install -s -o root -g wheel -m 555 regex_att_test =3D=3D=3D> lib/libc/tests/rpc (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.rpc_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Drpc_test install) install -s -o root -g wheel -m 555 rpc_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/rpc && DEPENDFILE=3D.depend.xdr_te= st NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/rpc/Makefile = _RECURSING_PROGS=3D PROG=3Dxdr_test install) install -s -o root -g wheel -m 555 xdr_test =3D=3D=3D> lib/libc/tests/stdio (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fdop= en_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio/Ma= kefile _RECURSING_PROGS=3D PROG=3Dfdopen_test install) install -s -o root -g wheel -m 555 fdopen_test (cd /builds/FreeBSD_HEAD/lib/libc/tests/stdio && DEPENDFILE=3D.depend.fmem= open2_test NO_SUBDIR=3D1 make -f /builds/FreeBSD_HEAD/lib/libc/tests/stdio= /Makefile _RECURSING_PROGS=3D PROG=3Dfmemopen2_test install) install -s -o root -g wheel -m 555 fmemopen2_test install: fmemopen2_test: No such file or directory *** Error code 71 Stop. make[8]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** Error code 1 Stop. make[7]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests/stdio *** Error code 1 Stop. make[6]: stopped in /builds/FreeBSD_HEAD/lib/libc/tests *** Error code 1 Stop. make[5]: stopped in /builds/FreeBSD_HEAD/lib/libc *** Error code 1 Stop. make[4]: stopped in /builds/FreeBSD_HEAD/lib *** Error code 1 Stop. make[3]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[2]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@freebsd.org Sun Nov 15 22:57:54 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 839B8A3095C for ; Sun, 15 Nov 2015 22:57:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 66E4815FD for ; Sun, 15 Nov 2015 22:57:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 644E0A3095B; Sun, 15 Nov 2015 22:57:54 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62EF7A3095A for ; Sun, 15 Nov 2015 22:57:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03C8815FC for ; Sun, 15 Nov 2015 22:57:53 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id tAFMvmxp006515; Sun, 15 Nov 2015 14:57:48 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id tAFMvm5I006514; Sun, 15 Nov 2015 14:57:48 -0800 (PST) (envelope-from david) Date: Sun, 15 Nov 2015 14:57:48 -0800 From: David Wolfskill To: Marius Strobl Cc: current@freebsd.org Subject: Re: Wake on LAN broken (probably between r290542 - r290606)? Message-ID: <20151115225748.GC1211@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Marius Strobl , current@freebsd.org References: <20151111143337.GN1235@albert.catwhisker.org> <20151114175636.GX91465@albert.catwhisker.org> <20151115215706.GH31931@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB" Content-Disposition: inline In-Reply-To: <20151115215706.GH31931@alchemy.franken.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 22:57:54 -0000 --gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2015 at 10:57:06PM +0100, Marius Strobl wrote: > ... > > I've placed a copy of a verbose dmes.boot in > > . > >=20 > > I'm happy to test suggested changes. > >=20 >=20 > *sigh* Okay, could you please test whether the attached patch restores > WOL capability for you? > .... Aye; that worked for me. I used the slice where I had tested r290566 and r290565 (most recently, the latter), used "svn update -r290566" to update sources to r290566 first, then used "svn patch" to apply the aptch, then re-built world & kernel & re-installed kernel & world, then rebooted, then "shutdown -p now" to power off. Once serial console reported: =2E.. re0: link state changed to DOWN re0: link state changed to UP acpi0: Powering system off I used /usr/local/bin/wol on the machine that is supposed to wake the build machine up, and it powered right up as it did before. Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --gr/z0/N6AeWAPJVB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWSQ3sXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7xYAQAJu1g8CNaDmDDO5BtGgk/z2X vKgilQ8I3RhSsZHPAZjrDfZORx/crp1nQszuNpgmpY0fJ5mU9iqKSzNeB4ZlpVEm C53X/fehmF0Q5ANuHU5dPAb194/z+QUveSB/CDXya4bkgDsY7WiRoDeZrxrJS6NU 6GrjbXyNPNCszE8p0A62VWKJzcMRgOQQEtP2C/w2Bm09U0ew9rFbMuJTGmCT8051 pglubj5pGt9WAQ0cGjG/TfA2jPTWXr9kQsB/ZOWTR96k91f7MoKcW7ZzRdvibitd u4yynNJeAUA2trda1GXwClbaj1drXV+LjK/WbDOdYXga4qghWVZWOdQgVy5D4mSC cq81HLoY/8eRvZyo0s8Ecve1gif2fvGWtQfmnH434EhlcwG0UHiM/qIVv3+VeXue NXmA/12Phyofr/RpfNfiO94fFCOODaSdVvlwh6pCRq7otClT/VGwyW0xN/WgY7rM sshzmjPvALDhXHtl0Dpo8MJCclj9opjcKid6C0NvqSFgnkG7WnobGkP4tnGFa12K lq+CYZ+BBYSE+UY+0O0rFm/UzstGgJMyKr5yFtphV8J8VCnAdK/U/p0gNvkTS2uz EKa9I4++rJUQI2gy5MGBAJdX5rHWaMc8MyT/HDjMvoWU3+TBhNzJT35fB/1ppraW nK3aBzQSnsKE6pgkJQ/f =X/fo -----END PGP SIGNATURE----- --gr/z0/N6AeWAPJVB-- From owner-freebsd-current@freebsd.org Sun Nov 15 23:36:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB4FCA30FC0 for ; Sun, 15 Nov 2015 23:36:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AD251359; Sun, 15 Nov 2015 23:36:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id tAFNa6Bi005630; Sun, 15 Nov 2015 15:36:10 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201511152336.tAFNa6Bi005630@gw.catspoiler.org> Date: Sun, 15 Nov 2015 15:36:06 -0800 (PST) From: Don Lewis Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: allanjude@freebsd.org cc: freebsd-current@freebsd.org In-Reply-To: <5648CA60.3060800@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 23:36:15 -0000 On 15 Nov, Allan Jude wrote: > On 2015-11-15 13:06, Garrett Cooper wrote: >> >>> On Nov 15, 2015, at 09:51, Andrey Chernov wrote: >>> >>>> On 15.11.2015 20:37, Adrian Chadd wrote: >>>>> On 15 November 2015 at 09:10, Dan Partelly wrote: >>>>> Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? >>>> >>>> Nope and yup. The juniper folk had a solution to a problem multiple >>>> people had requested work on, and their proposal was by far the >>>> furthest along code and use wise. >>>> >>>> It's all fine and good making technical decisions based on drawings >>>> and handwaving and philosophizing, but at some point someone has to do >>>> the code. Juniper's libxo was the furthest along in implementation and >>>> production. >>> >>> It seems it is the only and final argument for libXO existence. I >>> remember 2 or 3 discussions against libXO spontaneously happens in the >>> FreeBSD lists, all ended with that, approximately: "we already have the >>> code and you have just speculations". Alternative and more architecture >>> clean ideas, like making standalone template-oriented parser probably >>> based on liXO, are never seriously considered, because nobody will code >>> it, not for other reasons. >> >> We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't seems like the best idea in the world to me from a end-user sysadmin/developer perspective. >> >> I could just as easily use standard tools like awk, grep, sed, and more advanced languages like perl or Python to parse output, and assuming output doesn't get a major rewrite, I'd just go with that method that's worked pretty well for me over the last 10 years of my career.. >> >> Cheers, >> -NGie >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > The big difference is, a json parser isn't going to blow up if a new > field gets added in the middle, and your awk/grep/sed script probably will. Or more likely, if some value gets large causing adjacent columns run together. Or even if you the utility is used to display something where some of the data contains whitespace. How is an awk script going to cope with this: # grep spacey /etc/passwd spacey user:*:6666:6666:Update Builder:/tmp/spacey:/bin/csh # su 'spacey user' % cd ~ % touch 'a file' % ls -l total 1 -rw-r--r-- 1 spacey user 6666 0 Nov 15 15:24 a file vs a json parser: % ls --libxo json -l {"__version": "1", "file-information": {"directory": [{"total-blocks":1, "entry": [{"name":"a file","mode":"-rw-r--r--","mode_octal":644,"links":1,"user":"spacey user","group":"6666","type":"regular","size":0,"modify-time":1447629885}]}]} } From owner-freebsd-current@freebsd.org Mon Nov 16 01:57:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 823D2A2FBFA for ; Mon, 16 Nov 2015 01:57:56 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 553DA1537; Mon, 16 Nov 2015 01:57:56 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by padhx2 with SMTP id hx2so157854708pad.1; Sun, 15 Nov 2015 17:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=LM/fngTMQRrqh2FdQ3KDGcuTAOGn3brUfF0sppRLWFk=; b=0TZUj1Hr9BCdncAqQjihhNoJXX2ZK5ANIDQ5d6WtHyQEjpF1wYx5f7E5OewlDelDLW ZU0cA5tpD81LZsaYUM8Zmo1rYZl+gyEDJgjbVQP4SVYypDfLb83v1fSssM8huI3qvOFA mjqy3FtXN7O2Jmoe3jpln+Y5XZDO/DkbKfRev5VDS9lUtyLXNgXk2pPyhSg1q9meLR6+ WxkOOd9tdV2zkAebNAMwx0MRMkJDv5zNLxZtXmho6lC7gpTSJz7W+jDVIf/kyOhHVxwa L63g0LdoPJzmKMM2oRZhYP80binYEmXn7ZwdjpTYo2TLkkQvYIPfbgDfUvIUL2KyX10a f9wg== X-Received: by 10.67.14.201 with SMTP id fi9mr50131094pad.41.1447639075883; Sun, 15 Nov 2015 17:57:55 -0800 (PST) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id rc5sm32691246pbc.95.2015.11.15.17.57.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 17:57:54 -0800 (PST) From: NGie Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: make installworld failing with locales due to broken symlinks Date: Sun, 15 Nov 2015 17:57:52 -0800 Message-Id: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Cc: Baptiste Daroussin , Bryan Drewery To: freebsd-current Current Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 01:57:56 -0000 Hi, I run into this error when running `make installworld` with a = world installed prior and during the projects/collation merge to head = =E2=80=94 reason is that the target for the symlink doesn=E2=80=99t = exist. This might be fallout from recent build changes, or a side effect = of the broken symlinks=E2=80=A6 Thanks, -NGie install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or = directory *** Error code 71 Stop. make[5]: stopped in /usr/src/git/share/ctypedef *** Error code 1 Stop. make[4]: stopped in /usr/src/git/share *** Error code 1 Stop. make[3]: stopped in /usr/src/git *** Error code 1 Stop. make[2]: stopped in /usr/src/git *** Error code 1 Stop. make[1]: stopped in /usr/src/git *** Error code 1 Stop. make: stopped in /usr/src/git $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 = /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> = ../la_LN.ISO8859-1/LC_CTYPE $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE /usr/share/locale/la_LN.ISO8859-1 $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory= From owner-freebsd-current@freebsd.org Mon Nov 16 02:27:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3584A2F4F1 for ; Mon, 16 Nov 2015 02:27:21 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1ABD191D for ; Mon, 16 Nov 2015 02:27:21 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykdr82 with SMTP id r82so217492034ykd.3 for ; Sun, 15 Nov 2015 18:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=bkK+oS230dlAZKe09FY6NptdwQXOH9bPPDuRezxWhG8=; b=GDA6JgobmREv6TnsFg94d5NlK6Askt43o4BSXJKzuBuJIVzu1fPBBuVL0y0stSdX8t cCivB1Bur3ae74cYIHIzCQtRxFxd+j8/+97y8iA0/jbOVwFX1y0pFldu4STqkMsDB6ZW 1AjtWLd8OZgGALWE1+cRE3fT3727kWIiIzsi7AEDiUGltr77mS0dHNMf777Kh+a6X5HA AsNkIW6WlMO9AjYA8fehpbahqJpYSOmGEdGcTUZwEizPJ9od/u7WjXAr9qIUPseKfCvw ReQcFAc8q4HkZQ472dtAcxyQ7EeN+/hOL30sZyGDP0LACD+KZ0+51LMtLf93hmD/XRFP jeXw== MIME-Version: 1.0 X-Received: by 10.13.196.193 with SMTP id g184mr32586814ywd.293.1447640840739; Sun, 15 Nov 2015 18:27:20 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Sun, 15 Nov 2015 18:27:20 -0800 (PST) In-Reply-To: References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Date: Sun, 15 Nov 2015 18:27:20 -0800 X-Google-Sender-Auth: xcv6GgCVZG9MWhjOwV0ScW_VPL4 Message-ID: Subject: Re: make installworld failing with locales due to broken symlinks From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 02:27:22 -0000 On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper wrote: > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > I built the latest world, and then did the following: rm -fr /tmp/testdir mkdir /tmp/testdir make installworld DESTDIR=/tmp/testdir cd /tmp/testdir/usr/share/locale for f in $(find . -type l) ; do [ ! -e $f ] && echo "$f does not exist"; done ./zh_CN.GB2312/LC_NUMERIC does not exist ./zh_CN.GB2312/LC_MONETARY does not exist ./zh_CN.GB2312/LC_COLLATE does not exist ./zh_CN.GB2312/LC_CTYPE does not exist ./zh_CN.GB2312/LC_MESSAGES does not exist ./zh_CN.GB2312/LC_TIME does not exist ./zh_CN.eucCN/LC_MESSAGES does not exist ./zh_CN.eucCN/LC_NUMERIC does not exist ./zh_CN.eucCN/LC_TIME does not exist ./zh_CN.eucCN/LC_CTYPE does not exist ./zh_CN.eucCN/LC_MONETARY does not exist ./zh_CN.eucCN/LC_COLLATE does not exist ./zh_HK.UTF-8/LC_NUMERIC does not exist ./zh_HK.UTF-8/LC_MONETARY does not exist ./zh_HK.UTF-8/LC_COLLATE does not exist ./zh_HK.UTF-8/LC_MESSAGES does not exist ./zh_HK.UTF-8/LC_TIME does not exist ./zh_HK.UTF-8/LC_CTYPE does not exist ./zh_CN.GBK/LC_CTYPE does not exist ./zh_CN.GBK/LC_NUMERIC does not exist ./zh_CN.GBK/LC_MESSAGES does not exist ./zh_CN.GBK/LC_COLLATE does not exist ./zh_CN.GBK/LC_MONETARY does not exist ./zh_CN.GBK/LC_TIME does not exist ./zh_CN.GB18030/LC_COLLATE does not exist ./zh_CN.GB18030/LC_MESSAGES does not exist ./zh_CN.GB18030/LC_CTYPE does not exist ./zh_CN.GB18030/LC_TIME does not exist ./zh_CN.GB18030/LC_NUMERIC does not exist ./zh_CN.GB18030/LC_MONETARY does not exist ./zh_TW.UTF-8/LC_MESSAGES does not exist ./zh_TW.UTF-8/LC_NUMERIC does not exist ./zh_TW.UTF-8/LC_MONETARY does not exist ./zh_TW.UTF-8/LC_TIME does not exist ./zh_TW.UTF-8/LC_CTYPE does not exist ./zh_TW.UTF-8/LC_COLLATE does not exist ./zh_HK.Big5HKSCS/LC_MONETARY does not exist ./zh_HK.Big5HKSCS/LC_NUMERIC does not exist ./zh_HK.Big5HKSCS/LC_CTYPE does not exist ./zh_HK.Big5HKSCS/LC_TIME does not exist ./zh_HK.Big5HKSCS/LC_COLLATE does not exist ./zh_HK.Big5HKSCS/LC_MESSAGES does not exist ./zh_TW.Big5/LC_MONETARY does not exist ./zh_TW.Big5/LC_CTYPE does not exist ./zh_TW.Big5/LC_TIME does not exist ./zh_TW.Big5/LC_NUMERIC does not exist ./zh_TW.Big5/LC_MESSAGES does not exist ./zh_TW.Big5/LC_COLLATE does not exist -- Craig From owner-freebsd-current@freebsd.org Mon Nov 16 02:37:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EF41A2F6FF for ; Mon, 16 Nov 2015 02:37:19 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A2371DE6 for ; Mon, 16 Nov 2015 02:37:18 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbblt2 with SMTP id lt2so80875903lbb.3 for ; Sun, 15 Nov 2015 18:37:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=cKEbxTpYY1fB5o8T8S2cyVb3jymaPdNt7vNyTgbbeHY=; b=khzbUduGGMrQFd1R0gfDHu04aOX2xrcze0yuAglbpWoJwp3KjLityBrtl3N7wNRPJ8 DJ9UUkt3rTAT5/HaqOSTo+4C6T1QFj+EzPKD2tclx4kMf5//GySp+vDUDWEvZOIbAa+I gIn0OznIeoOT295G6I9V6h695tDXtPDRZjC75zncRJY4NS0qam7RhHSJ7BnTh5a46NhN 7iOSInoNZtmpsar96B47Ed0ZhwX4H8h6uZkI3QnJzISTBSTQqkHxl94Kr8N/LuCTpg7/ hUTyqtUjvnEohqKfNlHUSSHRDswVGzzxGUFnq7u/GF7Ot0/YcKKhcXCznTPiyv+mdx7H 12qw== X-Gm-Message-State: ALoCoQleg/dug5d64Xf7M2/lvhQIBNsPauOaeh2Hv7Q1pQq7PLDU3VPLEB+fftcq0A4MdqqHoaod X-Received: by 10.112.35.196 with SMTP id k4mr15710809lbj.3.1447641436010; Sun, 15 Nov 2015 18:37:16 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id un3sm1398983lbc.28.2015.11.15.18.37.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 18:37:15 -0800 (PST) Subject: Re: make installworld failing with locales due to broken symlinks To: NGie Cooper , freebsd-current Current References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Cc: Baptiste Daroussin , Bryan Drewery From: Andrey Chernov Message-ID: <5649415A.8010408@freebsd.org> Date: Mon, 16 Nov 2015 05:37:14 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 02:37:19 -0000 On 16.11.2015 4:57, NGie Cooper wrote: > make: stopped in /usr/src/git > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > /usr/share/locale/la_LN.ISO8859-1 > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory As I remember, we already hit this type of problem before with old locales. "ln -sf" and "rm -rf" should be used everywhere on install target to avoid that. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Mon Nov 16 02:41:02 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55AEFA2F7C2 for ; Mon, 16 Nov 2015 02:41:02 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6B861045 for ; Mon, 16 Nov 2015 02:41:01 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbsy6 with SMTP id sy6so51811238lbb.2 for ; Sun, 15 Nov 2015 18:40:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=kXhHnxfbvUu1dIzUhptoGakAIJJSXb5SC1e6qcqUr3I=; b=I31rGPci0fRJaUiHn7LsvQxqoAYxpSA6eR7UTg3YOaHqVKCp27zTxQeEzBKdafHxKy IHArD364cHFRDneXVIaE17XsTI7Z6Bau74j0eXfpXhC1dUuPH7IcDHTByT+DG6D1SxsN D8FSLP0yezYjBpUed6UPpkMRIfygrYnVrKGNLkQVEtRmeKVkVFoIa4DAcxs6uroSp39W 0yHxVdyQxwFcTrKDCp6tmVJuH76oMV92Vqc8jb8GKmRt+D8O3PL9Vq1D5aSneiBSfFWy eztfBuJR5nDuYEKCecNb5DHFTY7f0sC4i577+meZlUfW/RGh0y8bi9Ygl69BS5Nzf6ml K9Mg== X-Gm-Message-State: ALoCoQm1lecihTCFnT7XZWmBt4oX7hLH8i02wakgaA01LLz5f5v2cAjWvyaCncj6xm1mM36LlZ5/ X-Received: by 10.112.12.73 with SMTP id w9mr15861855lbb.36.1447641659831; Sun, 15 Nov 2015 18:40:59 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id ki2sm333327lbc.15.2015.11.15.18.40.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 18:40:59 -0800 (PST) Subject: Re: make installworld failing with locales due to broken symlinks To: NGie Cooper , freebsd-current Current References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> <5649415A.8010408@freebsd.org> Cc: Baptiste Daroussin , Bryan Drewery From: Andrey Chernov Message-ID: <5649423A.7080201@freebsd.org> Date: Mon, 16 Nov 2015 05:40:58 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5649415A.8010408@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 02:41:02 -0000 On 16.11.2015 5:37, Andrey Chernov wrote: > On 16.11.2015 4:57, NGie Cooper wrote: >> make: stopped in /usr/src/git >> $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE >> lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE >> $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE >> /usr/share/locale/la_LN.ISO8859-1 >> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` >> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > > As I remember, we already hit this type of problem before with old > locales. "ln -sf" and "rm -rf" should be used everywhere on install > target to avoid that. > Oops, auto-typo. "rm -f" instead, since all directories are created by mtree. -- http://ache.vniz.net/ From owner-freebsd-current@freebsd.org Mon Nov 16 03:08:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96AE6A2FE6F for ; Mon, 16 Nov 2015 03:08:21 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50A841F76; Mon, 16 Nov 2015 03:08:21 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykdr82 with SMTP id r82so218553975ykd.3; Sun, 15 Nov 2015 19:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZakKw2yB3IQHsneX+Ao+UvinAURyC36y1442ljFy8jc=; b=tjC4WQPa5Y67g9ErCcnc+KNjSaO5jNVT5o9b1nGATnZ57tvVT8tlzHiczhJ04E0yzh Q7+kLshG2mHIDMgvLYik1QwcFriwBXHTBOmfua2/6mZ9LGQjAHwCcl1U9r/c+S615zjo tZ3WXhIXt04a1BAr0dk0jq1/FMS6KkaSBB0xatjeHr3Q/+/rXMHktQOyG5BKmB1nzOda tTlp1HS+xDcZ6Aq+uH1FXVZSjZ9JtTeHagMyQoNPLSf2YwNxj8epNqGgYrro2Cf52UHX wmaD6/ba5ua2Q8huLxtIKYEu6zALUh7XbM5rs7PxvCa5kBcQqpl+h3TTF/FQQk5yjgR0 1xjg== MIME-Version: 1.0 X-Received: by 10.13.196.193 with SMTP id g184mr32713828ywd.293.1447643299224; Sun, 15 Nov 2015 19:08:19 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Sun, 15 Nov 2015 19:08:19 -0800 (PST) In-Reply-To: References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Date: Sun, 15 Nov 2015 19:08:19 -0800 X-Google-Sender-Auth: 7yz4z6GKbXecLAjls4biH-kREk0 Message-ID: Subject: Re: make installworld failing with locales due to broken symlinks From: Craig Rodrigues To: freebsd-current Current Cc: Bryan Drewery , Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 03:08:21 -0000 On Sun, Nov 15, 2015 at 6:27 PM, Craig Rodrigues wrote: > On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper > wrote: > >> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` >> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory >> > > > I built the latest world, and then did the following: > > rm -fr /tmp/testdir > mkdir /tmp/testdir > > make installworld DESTDIR=/tmp/testdir > > cd /tmp/testdir/usr/share/locale > for f in $(find . -type l) ; do [ ! -e $f ] && echo "$f does not exist"; > done > > ./zh_CN.GB2312/LC_NUMERIC does not exist > ./zh_CN.GB2312/LC_MONETARY does not exist > ./zh_CN.GB2312/LC_COLLATE does not exist > ./zh_CN.GB2312/LC_CTYPE does not exist > ./zh_CN.GB2312/LC_MESSAGES does not exist > ./zh_CN.GB2312/LC_TIME does not exist > ./zh_CN.eucCN/LC_MESSAGES does not exist > ./zh_CN.eucCN/LC_NUMERIC does not exist > ./zh_CN.eucCN/LC_TIME does not exist > ./zh_CN.eucCN/LC_CTYPE does not exist > ./zh_CN.eucCN/LC_MONETARY does not exist > ./zh_CN.eucCN/LC_COLLATE does not exist > ./zh_HK.UTF-8/LC_NUMERIC does not exist > ./zh_HK.UTF-8/LC_MONETARY does not exist > ./zh_HK.UTF-8/LC_COLLATE does not exist > ./zh_HK.UTF-8/LC_MESSAGES does not exist > ./zh_HK.UTF-8/LC_TIME does not exist > ./zh_HK.UTF-8/LC_CTYPE does not exist > ./zh_CN.GBK/LC_CTYPE does not exist > ./zh_CN.GBK/LC_NUMERIC does not exist > ./zh_CN.GBK/LC_MESSAGES does not exist > ./zh_CN.GBK/LC_COLLATE does not exist > ./zh_CN.GBK/LC_MONETARY does not exist > ./zh_CN.GBK/LC_TIME does not exist > ./zh_CN.GB18030/LC_COLLATE does not exist > ./zh_CN.GB18030/LC_MESSAGES does not exist > ./zh_CN.GB18030/LC_CTYPE does not exist > ./zh_CN.GB18030/LC_TIME does not exist > ./zh_CN.GB18030/LC_NUMERIC does not exist > ./zh_CN.GB18030/LC_MONETARY does not exist > ./zh_TW.UTF-8/LC_MESSAGES does not exist > ./zh_TW.UTF-8/LC_NUMERIC does not exist > ./zh_TW.UTF-8/LC_MONETARY does not exist > ./zh_TW.UTF-8/LC_TIME does not exist > ./zh_TW.UTF-8/LC_CTYPE does not exist > ./zh_TW.UTF-8/LC_COLLATE does not exist > ./zh_HK.Big5HKSCS/LC_MONETARY does not exist > ./zh_HK.Big5HKSCS/LC_NUMERIC does not exist > ./zh_HK.Big5HKSCS/LC_CTYPE does not exist > ./zh_HK.Big5HKSCS/LC_TIME does not exist > ./zh_HK.Big5HKSCS/LC_COLLATE does not exist > ./zh_HK.Big5HKSCS/LC_MESSAGES does not exist > ./zh_TW.Big5/LC_MONETARY does not exist > ./zh_TW.Big5/LC_CTYPE does not exist > ./zh_TW.Big5/LC_TIME does not exist > ./zh_TW.Big5/LC_NUMERIC does not exist > ./zh_TW.Big5/LC_MESSAGES does not exist > ./zh_TW.Big5/LC_COLLATE does not exist > > -- > Craig > > This fixed it for me: Index: Makefile =================================================================== --- Makefile (revision 290902) +++ Makefile (working copy) @@ -15,7 +15,7 @@ .for from to in ${ALIASES} .for f in ${LC_FILES} -SYMLINKS+= ${from}/${f} ${LOCALEDIR}/${to}/${f} +SYMLINKS+= ../${from}/${f} ${LOCALEDIR}/${to}/${f} .endfor .endfor -- Craig From owner-freebsd-current@freebsd.org Mon Nov 16 03:16:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30F2CA3005D for ; Mon, 16 Nov 2015 03:16:00 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E99CC14E5; Mon, 16 Nov 2015 03:15:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pabfh17 with SMTP id fh17so161786776pab.0; Sun, 15 Nov 2015 19:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=blT7tMshtIoc+bO4e/SfPGHaERR2jhuHPgCKPoSGX5A=; b=QF+S2sbfb+yetf7oNXRfKOZQV4qx8GfIM/hSovnxzFnGaHZ3psyc0Km23elHFzEYIK Fj1uVh1IRN3nkdlkB2euoF9Fqmj20Aqi0rcYssunT3LqqSA+Wds+2NeCY5KKICv/pZ6g HRJIQoOVZgKoYd28wMKztp8mk+1phy0bGpiXc029eRTclThR3/Kf7vcn56FUmeRjLMtv BeqmOF3LlxEGmD4YO8VF528xjkzmTtFEXml3MFx8ItwgEz178qvjZ+jmOU4F5xtrgRNw +p/vZDFT6Ns8vf/nK60MCbKD7hgRQBz80UgIGxLWGBK8WG4czFTcNkEhDrZoK4Nl8kGO 0Bhg== X-Received: by 10.68.65.8 with SMTP id t8mr47463081pbs.99.1447643759442; Sun, 15 Nov 2015 19:15:59 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:fd52:9a90:172f:f1ee? ([2601:601:800:126d:fd52:9a90:172f:f1ee]) by smtp.gmail.com with ESMTPSA id bd2sm5632506pbb.25.2015.11.15.19.15.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Nov 2015 19:15:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: make installworld failing with locales due to broken symlinks From: NGie Cooper In-Reply-To: Date: Sun, 15 Nov 2015 19:15:56 -0800 Cc: freebsd-current Current , Bryan Drewery , Baptiste Daroussin Content-Transfer-Encoding: 7bit Message-Id: References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 03:16:00 -0000 > On Nov 15, 2015, at 19:08, Craig Rodrigues wrote: > > On Sun, Nov 15, 2015 at 6:27 PM, Craig Rodrigues > wrote: > >> On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper >> wrote: >> >>> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` >>> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory >>> >> >> >> I built the latest world, and then did the following: >> >> rm -fr /tmp/testdir >> mkdir /tmp/testdir >> >> make installworld DESTDIR=/tmp/testdir >> >> cd /tmp/testdir/usr/share/locale >> for f in $(find . -type l) ; do [ ! -e $f ] && echo "$f does not exist"; >> done >> >> ./zh_CN.GB2312/LC_NUMERIC does not exist >> ./zh_CN.GB2312/LC_MONETARY does not exist >> ./zh_CN.GB2312/LC_COLLATE does not exist >> ./zh_CN.GB2312/LC_CTYPE does not exist >> ./zh_CN.GB2312/LC_MESSAGES does not exist >> ./zh_CN.GB2312/LC_TIME does not exist >> ./zh_CN.eucCN/LC_MESSAGES does not exist >> ./zh_CN.eucCN/LC_NUMERIC does not exist >> ./zh_CN.eucCN/LC_TIME does not exist >> ./zh_CN.eucCN/LC_CTYPE does not exist >> ./zh_CN.eucCN/LC_MONETARY does not exist >> ./zh_CN.eucCN/LC_COLLATE does not exist >> ./zh_HK.UTF-8/LC_NUMERIC does not exist >> ./zh_HK.UTF-8/LC_MONETARY does not exist >> ./zh_HK.UTF-8/LC_COLLATE does not exist >> ./zh_HK.UTF-8/LC_MESSAGES does not exist >> ./zh_HK.UTF-8/LC_TIME does not exist >> ./zh_HK.UTF-8/LC_CTYPE does not exist >> ./zh_CN.GBK/LC_CTYPE does not exist >> ./zh_CN.GBK/LC_NUMERIC does not exist >> ./zh_CN.GBK/LC_MESSAGES does not exist >> ./zh_CN.GBK/LC_COLLATE does not exist >> ./zh_CN.GBK/LC_MONETARY does not exist >> ./zh_CN.GBK/LC_TIME does not exist >> ./zh_CN.GB18030/LC_COLLATE does not exist >> ./zh_CN.GB18030/LC_MESSAGES does not exist >> ./zh_CN.GB18030/LC_CTYPE does not exist >> ./zh_CN.GB18030/LC_TIME does not exist >> ./zh_CN.GB18030/LC_NUMERIC does not exist >> ./zh_CN.GB18030/LC_MONETARY does not exist >> ./zh_TW.UTF-8/LC_MESSAGES does not exist >> ./zh_TW.UTF-8/LC_NUMERIC does not exist >> ./zh_TW.UTF-8/LC_MONETARY does not exist >> ./zh_TW.UTF-8/LC_TIME does not exist >> ./zh_TW.UTF-8/LC_CTYPE does not exist >> ./zh_TW.UTF-8/LC_COLLATE does not exist >> ./zh_HK.Big5HKSCS/LC_MONETARY does not exist >> ./zh_HK.Big5HKSCS/LC_NUMERIC does not exist >> ./zh_HK.Big5HKSCS/LC_CTYPE does not exist >> ./zh_HK.Big5HKSCS/LC_TIME does not exist >> ./zh_HK.Big5HKSCS/LC_COLLATE does not exist >> ./zh_HK.Big5HKSCS/LC_MESSAGES does not exist >> ./zh_TW.Big5/LC_MONETARY does not exist >> ./zh_TW.Big5/LC_CTYPE does not exist >> ./zh_TW.Big5/LC_TIME does not exist >> ./zh_TW.Big5/LC_NUMERIC does not exist >> ./zh_TW.Big5/LC_MESSAGES does not exist >> ./zh_TW.Big5/LC_COLLATE does not exist >> >> -- >> Craig >> >> > > > This fixed it for me: > > Index: Makefile > =================================================================== > --- Makefile (revision 290902) > +++ Makefile (working copy) > @@ -15,7 +15,7 @@ > > .for from to in ${ALIASES} > .for f in ${LC_FILES} > -SYMLINKS+= ${from}/${f} ${LOCALEDIR}/${to}/${f} > +SYMLINKS+= ../${from}/${f} ${LOCALEDIR}/${to}/${f} > .endfor > .endfor LGTM From owner-freebsd-current@freebsd.org Mon Nov 16 02:24:20 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C8E4A2F45C for ; Mon, 16 Nov 2015 02:24:20 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEF1A17C7; Mon, 16 Nov 2015 02:24:19 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykdv3 with SMTP id v3so217734589ykd.0; Sun, 15 Nov 2015 18:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5Z0c6KXp0CQgPrmKT+2g8m53Iuas0+8qgxZuSFnLLGc=; b=k/AAlA1xu52rRY6uNZOtIcn/1+hmQ1kP4CgLH0QptR3S0FKDFAv7R0bHQq2FqbkmA6 fCiu4XXqzIwM6+pJ0ZcxKhTI1WtJ+r7nREYFDsr9iuB5FIitGVMHYpVtq0I3//6pjuP6 UcaB6oit1k5TGXZOAffmsJAUtuNC0O/qv0T0kpNeLkdB2npCyfYlV4mrzMqAbC5kCKde Z+U1kruc3FhRLKtSsVnKRLuBZY/If6iowl2ITiV4nCYeDTkbMAx/WXYUpvNrqGcZvHjE v0zkV3II2PFv32MF/ZCAJ29atGg9sh2MxUindUSPeV4teMgdNi4zgjmEZD6eind4sR6G zNDQ== MIME-Version: 1.0 X-Received: by 10.13.224.3 with SMTP id j3mr34008769ywe.246.1447640658875; Sun, 15 Nov 2015 18:24:18 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Sun, 15 Nov 2015 18:24:18 -0800 (PST) In-Reply-To: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Date: Sun, 15 Nov 2015 18:24:18 -0800 X-Google-Sender-Auth: ci8amlzw5k-61RM8a1b-ow1TfTU Message-ID: Subject: Re: make installworld failing with locales due to broken symlinks From: Craig Rodrigues To: freebsd-current Current Cc: Baptiste Daroussin , Bryan Drewery X-Mailman-Approved-At: Mon, 16 Nov 2015 03:16:46 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 02:24:20 -0000 On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper wrote: > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > I built the latest world, and then did the following: rm -fr /tmp/testdir mkdir /tmp/testdir make installworld DESTDIR=/tmp/testdir cd /tmp/testdir/usr/share/locale for f in $(find . -type l) ; do [ ! -e $f ] && echo "$f does not exist"; done ./zh_CN.GB2312/LC_NUMERIC does not exist ./zh_CN.GB2312/LC_MONETARY does not exist ./zh_CN.GB2312/LC_COLLATE does not exist ./zh_CN.GB2312/LC_CTYPE does not exist ./zh_CN.GB2312/LC_MESSAGES does not exist ./zh_CN.GB2312/LC_TIME does not exist ./zh_CN.eucCN/LC_MESSAGES does not exist ./zh_CN.eucCN/LC_NUMERIC does not exist ./zh_CN.eucCN/LC_TIME does not exist ./zh_CN.eucCN/LC_CTYPE does not exist ./zh_CN.eucCN/LC_MONETARY does not exist ./zh_CN.eucCN/LC_COLLATE does not exist ./zh_HK.UTF-8/LC_NUMERIC does not exist ./zh_HK.UTF-8/LC_MONETARY does not exist ./zh_HK.UTF-8/LC_COLLATE does not exist ./zh_HK.UTF-8/LC_MESSAGES does not exist ./zh_HK.UTF-8/LC_TIME does not exist ./zh_HK.UTF-8/LC_CTYPE does not exist ./zh_CN.GBK/LC_CTYPE does not exist ./zh_CN.GBK/LC_NUMERIC does not exist ./zh_CN.GBK/LC_MESSAGES does not exist ./zh_CN.GBK/LC_COLLATE does not exist ./zh_CN.GBK/LC_MONETARY does not exist ./zh_CN.GBK/LC_TIME does not exist ./zh_CN.GB18030/LC_COLLATE does not exist ./zh_CN.GB18030/LC_MESSAGES does not exist ./zh_CN.GB18030/LC_CTYPE does not exist ./zh_CN.GB18030/LC_TIME does not exist ./zh_CN.GB18030/LC_NUMERIC does not exist ./zh_CN.GB18030/LC_MONETARY does not exist ./zh_TW.UTF-8/LC_MESSAGES does not exist ./zh_TW.UTF-8/LC_NUMERIC does not exist ./zh_TW.UTF-8/LC_MONETARY does not exist ./zh_TW.UTF-8/LC_TIME does not exist ./zh_TW.UTF-8/LC_CTYPE does not exist ./zh_TW.UTF-8/LC_COLLATE does not exist ./zh_HK.Big5HKSCS/LC_MONETARY does not exist ./zh_HK.Big5HKSCS/LC_NUMERIC does not exist ./zh_HK.Big5HKSCS/LC_CTYPE does not exist ./zh_HK.Big5HKSCS/LC_TIME does not exist ./zh_HK.Big5HKSCS/LC_COLLATE does not exist ./zh_HK.Big5HKSCS/LC_MESSAGES does not exist ./zh_TW.Big5/LC_MONETARY does not exist ./zh_TW.Big5/LC_CTYPE does not exist ./zh_TW.Big5/LC_TIME does not exist ./zh_TW.Big5/LC_NUMERIC does not exist ./zh_TW.Big5/LC_MESSAGES does not exist ./zh_TW.Big5/LC_COLLATE does not exist -- Craig From owner-freebsd-current@freebsd.org Mon Nov 16 03:59:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10331A30884 for ; Mon, 16 Nov 2015 03:59:56 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3B171E5D; Mon, 16 Nov 2015 03:59:55 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykba77 with SMTP id a77so219391374ykb.2; Sun, 15 Nov 2015 19:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2C9BEgKcB78fXa7QmZ3LMU5IUBGaquxn7+tF//grNNM=; b=DtIthengsWPb6hM+ml0c0Ox7l7frR4/UUUxekV5iARir04aBTxiezpTnQtL/eSbIkV Anbp6ctW5w8xgzgjdfaFDV786CK1aHJmFxjSzX+CH5+k4/iMlI6mVJBf1wxdtKmCllKi KQFBKPpDON/oOiUvJxMYapR/rnXTaIOz0oTaeEgvGaksRtdImYMLwGj4NkanifsxOAQX K3eoRs3F0y0LTDdFhXmbotx+ae9WbxeB2qscKVOhmiGd+FpT3X4xFsFWwDNChnHU6wIE VfMko4XYTeiVNmr5oZLdbn1KOmjoRTtBcTkSA28LEkPk3cEXo9jLOnnu/gcdPCuryzA5 A8iA== MIME-Version: 1.0 X-Received: by 10.13.232.71 with SMTP id r68mr15932501ywe.283.1447646394914; Sun, 15 Nov 2015 19:59:54 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Sun, 15 Nov 2015 19:59:54 -0800 (PST) In-Reply-To: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Date: Sun, 15 Nov 2015 19:59:54 -0800 X-Google-Sender-Auth: Y61LyZW0dS4H7PNPnfeCINEyHS8 Message-ID: Subject: Re: make installworld failing with locales due to broken symlinks From: Craig Rodrigues To: NGie Cooper Cc: freebsd-current Current , Baptiste Daroussin , Bryan Drewery Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 03:59:56 -0000 On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper wrote: > > install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or > directory > *** Error code 71 > > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 > /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > /usr/share/locale/la_LN.ISO8859-1 > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > Hi, I ran into the same error when I tried to upgrade a system that I did an installworld on 2 days ago. -- Craig From owner-freebsd-current@freebsd.org Mon Nov 16 06:29:31 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D254AA305AD for ; Mon, 16 Nov 2015 06:29:31 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BC21814EC; Mon, 16 Nov 2015 06:29:31 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D4BB53F1; Mon, 16 Nov 2015 06:29:30 +0000 (UTC) Date: Mon, 16 Nov 2015 06:29:29 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1168262390.19.1447655369532.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1543785087.31.1447543893000.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1543785087.31.1447543893000.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1695 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 06:29:31 -0000 FreeBSD_HEAD-tests - Build #1695 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1695/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1695/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1695/console Change summaries: No changes The failed test cases: 6 tests failed. FAILED: lib.libc.locale.c16rtomb_test.c16rtomb_iso_8859_15_test Error Message: setlocale(LC_CTYPE, "en_US.ISO8859-15") failed; errno=22 FAILED: lib.libc.locale.io_test.good_big5_getwc Error Message: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/locale/t_io.c:155: getwc(fp) != 0xcf40 FAILED: lib.libc.locale.io_test.good_big5_swprintf Error Message: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/locale/t_io.c:117: swprintf(obuf, sizeof(obuf), L"%ls\n", ibuf) != 2 FAILED: lib.libc.locale.io_test.good_big5_wprintf Error Message: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/locale/t_io.c:102: wprintf(L"%ls\n", ibuf) != 2 FAILED: lib.libc.locale.mbrtoc16_test.mbrtoc16_iso_8859_15_test Error Message: setlocale(LC_CTYPE, "en_US.ISO8859-15") failed; errno=22 FAILED: lib.libc.locale.mbtowc_test.mbtowc Error Message: Test case was expecting a failure but none were raised From owner-freebsd-current@freebsd.org Mon Nov 16 07:12:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D92ACA30D50 for ; Mon, 16 Nov 2015 07:12:56 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A53B1A43 for ; Mon, 16 Nov 2015 07:12:56 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1ZyDuy-003dbJ-9N>; Mon, 16 Nov 2015 08:09:36 +0100 Received: from x55b38740.dyn.telefonica.de ([85.179.135.64] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1ZyDuy-002oUc-3g>; Mon, 16 Nov 2015 08:09:36 +0100 Date: Mon, 16 Nov 2015 08:09:31 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT installworld fails: LC_CTYPE: No such file or directory Message-ID: <20151116080931.73011b01.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/2_rXmOn2KGnx82bNv=itUar"; protocol="application/pgp-signature" X-Originating-IP: 85.179.135.64 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 07:12:56 -0000 --Sig_/2_rXmOn2KGnx82bNv=itUar Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The recent CURRENT starts dropping "make installworld" since two days ago, = now at revision 290923, with the error shown below. Regards, oh [...] =3D=3D=3D> share/ctypedef (install) install -o root -g wheel -m 444 be_BY.CP1131.LC_CTYPE /usr/share/locale/be_BY.CP1131/LC_CTYPE install -o r= oot -g wheel -m 444 ca_IT.ISO8859-1.LC_CTYPE /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE install: /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or direct= ory *** Error code 71 --Sig_/2_rXmOn2KGnx82bNv=itUar Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWSYErAAoJEOgBcD7A/5N8GW0H/is0rwpCJpDmbW0clFE1dzGV lONgha3Pi9oTxgitgu3hPEVhr3dGgWBUi7RU/I3B23azR38AfkEQ8BEdQszAGi/b +F/huPK7dqhrMfm7bl/7VttyotOb7t1BH3ev7xwBJ6lWbgzh6HB8lTwdWlNyyIGQ nmQIfktoyKcBW0Sy5D2dUNqXzkRU82geaH4RkrEvlmGzZcClkVsy4CgKYppy0xof PxFVtYfU63vdIIobLIrKvaACunqWWnH6+Q+D/8B3bBGRE0LrNzxatmWSJ6y1UJnT vtWvdDaHzaf1NctbDpxtL3Rtvb7OfFZxg04ZgcdNPo/kGOZR8mvFhsQJkuB2pKQ= =3zsZ -----END PGP SIGNATURE----- --Sig_/2_rXmOn2KGnx82bNv=itUar-- From owner-freebsd-current@freebsd.org Mon Nov 16 07:14:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0254DA30EBB for ; Mon, 16 Nov 2015 07:14:39 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B489B1C52; Mon, 16 Nov 2015 07:14:38 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1ZyDzo-003eYN-Tn>; Mon, 16 Nov 2015 08:14:36 +0100 Received: from x55b38740.dyn.telefonica.de ([85.179.135.64] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1ZyDzo-002oqh-MU>; Mon, 16 Nov 2015 08:14:36 +0100 Date: Mon, 16 Nov 2015 08:14:36 +0100 From: "O. Hartmann" To: Craig Rodrigues Cc: NGie Cooper , freebsd-current Current , Baptiste Daroussin , Bryan Drewery Subject: Re: make installworld failing with locales due to broken symlinks Message-ID: <20151116081436.218566a9.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> Organization: FU Berlin X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Z3i17Zy/41glcPHgKW11M4L"; protocol="application/pgp-signature" X-Originating-IP: 85.179.135.64 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 07:14:39 -0000 --Sig_/Z3i17Zy/41glcPHgKW11M4L Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 15 Nov 2015 19:59:54 -0800 Craig Rodrigues schrieb: > On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper wrot= e: >=20 > > > > install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or > > directory > > *** Error code 71 > > > > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 > > /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTY= PE > > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > /usr/share/locale/la_LN.ISO8859-1 > > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > > =20 >=20 >=20 > Hi, >=20 > I ran into the same error when I tried to upgrade a system that I did an > installworld on > 2 days ago. >=20 > -- > Craig > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" A "me, too" from here, I'm with CURRENT at revision 290924. Still failing t= o "make installworld". Kind regards, oh --Sig_/Z3i17Zy/41glcPHgKW11M4L Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWSYJcAAoJEOgBcD7A/5N8pdEIAKetouPz4punViImYWZndFcK +kpNWRfbr/uxTibaCWE3z3H7MYCvAg3dwUhK6znWwpVSxcJrschVK7DpQGOgPhrj S0tOdteQfg7rsBnPIWwPuabYIHwZ0pHuyS2wrqJVZdNzqsTwci03ktNEsLYaGzSX Xr1EzFUG2T7dcsp0PSKGFodcoFId5W7lcQSvKssRezgazKECC86CGcr4vwRoQ7CB zmFYOWXgFWDutiQ0h1JGC3hR7Dz4iRay7vKhKLFnYOKTYu0w6QBBg1Cb6/zsbvMo fzoOR19gX7rL8AHp1FvBvPS4YhHRkUreMtfsnabgwUOMpCpGodxl3YMIWgDJ7s8= =rYNg -----END PGP SIGNATURE----- --Sig_/Z3i17Zy/41glcPHgKW11M4L-- From owner-freebsd-current@freebsd.org Mon Nov 16 07:22:29 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13E59A300BE for ; Mon, 16 Nov 2015 07:22:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3E621FBE; Mon, 16 Nov 2015 07:22:28 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1ZyE7O-003gAe-Vs>; Mon, 16 Nov 2015 08:22:26 +0100 Received: from x55b38740.dyn.telefonica.de ([85.179.135.64] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1ZyE7O-002pYK-PA>; Mon, 16 Nov 2015 08:22:26 +0100 Date: Mon, 16 Nov 2015 08:22:26 +0100 From: "O. Hartmann" To: Craig Rodrigues Cc: NGie Cooper , freebsd-current Current , Baptiste Daroussin , Bryan Drewery Subject: Re: make installworld failing with locales due to broken symlinks Message-ID: <20151116082226.6a44ac3a.ohartman@zedat.fu-berlin.de> In-Reply-To: <20151116081436.218566a9.ohartman@zedat.fu-berlin.de> References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> <20151116081436.218566a9.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/rruA_TZkWtYMbr7PSon2X4T"; protocol="application/pgp-signature" X-Originating-IP: 85.179.135.64 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 07:22:29 -0000 --Sig_/rruA_TZkWtYMbr7PSon2X4T Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 16 Nov 2015 08:14:36 +0100 "O. Hartmann" schrieb: > Am Sun, 15 Nov 2015 19:59:54 -0800 > Craig Rodrigues schrieb: >=20 > > On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper wr= ote: > > =20 > > > > > > install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or > > > directory > > > *** Error code 71 > > > > > > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 > > > /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_C= TYPE > > > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > /usr/share/locale/la_LN.ISO8859-1 > > > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > > > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > > > =20 > >=20 > >=20 > > Hi, > >=20 > > I ran into the same error when I tried to upgrade a system that I did an > > installworld on > > 2 days ago. > >=20 > > -- > > Craig > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 >=20 > A "me, too" from here, I'm with CURRENT at revision 290924. Still failing= to "make > installworld". >=20 > Kind regards, >=20 > oh All right, missed the part "rm -rf". I deleted the file/link in question an= d the world gets installed as usual. oh --Sig_/rruA_TZkWtYMbr7PSon2X4T Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWSYQyAAoJEOgBcD7A/5N8fe4H/3+endTD3HNg1gC0w1YiFr0F eRhL7b2dJ6i9PP2s9dCSIjbR+ps1or4DdYqXZPvZv7odN//Tgu7V8dmvEapUioh5 uC2dND78na9XJw05P71B9IE6Mc8JOGBMhMQbrBVREQitc+adsf1De5c1N9rSSvlA 6Paez1JaE3thPZD9E/fki55adG/nIOzhizJZW17oXV4HlPQFgr0/r0bnMylGkv8h gxX4N0YDpYhrMRlXEyb4lTMDXhcPKdh+koQMCYbnJNj9gJemG/ylcnjoN6SImWd2 oyFrGrQ1/OE5hyiLWI6EzdUb8w5R+q7KBqt41zVb6qe2r3ydXIOIokDOTmbkUlk= =e5fx -----END PGP SIGNATURE----- --Sig_/rruA_TZkWtYMbr7PSon2X4T-- From owner-freebsd-current@freebsd.org Mon Nov 16 08:09:02 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52EE7A30BF5; Mon, 16 Nov 2015 08:09:02 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 162621322; Mon, 16 Nov 2015 08:09:02 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykdr82 with SMTP id r82so226070849ykd.3; Mon, 16 Nov 2015 00:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=zv6HFFGNGvyl+fldYhvuudeWvscLJviAk9ER+SQHmVQ=; b=L6h4k27xjDBMoBulpwrhan6wvAU7QMx/Lg+rmuutaqyODP6KsQhkolj2mkFsxMYBUE DkgG13skYP2sE5ijpHhCm2bTGauZ+4bNH4VPP2dwtUULCoDnXbZA7Y6EiFeQHn14ICNd HTHb+AJVspnSjoQvSnUyxi4eTWSGGRk9OiwYLT00xG9Jeum51zmhIoAtvOr3s9G9+juz TTO6Imvmtk3HNlbfPq9I1SvYZtbWWN5G610mnRXHWarPGJ8JCFYb7q4KaWaTWnIj6UXO MSlsuW/UzpQRGZbTJ2XXhpTF9Z6rLvoW8vGIcXtVW7FVywa5ZVI+Va6MJ1CIw6Ot5oDU 3/Gw== MIME-Version: 1.0 X-Received: by 10.13.196.193 with SMTP id g184mr33645908ywd.293.1447661341204; Mon, 16 Nov 2015 00:09:01 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Mon, 16 Nov 2015 00:09:01 -0800 (PST) Date: Mon, 16 Nov 2015 00:09:01 -0800 X-Google-Sender-Auth: 7VbFJrphzU-czd9sFbEZ-8rXRC8 Message-ID: Subject: Missing locales causing test failures From: Craig Rodrigues To: Baptiste Daroussin , Bryan Drewery Cc: "freebsd-testing@freebsd.org" , freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 08:09:02 -0000 Hi, I compared the output of "locale -a" from a CURRENT system built a few days ago, to the latest build. The latest build still has some missing locales, af_ZA.ISO8859-15 en_AU.ISO8859-15 en_CA.ISO8859-15 en_NZ.ISO8859-15 en_US.ISO8859-15 fr_CA.ISO8859-15 lt_LT.ISO8859-4 sr_YU.ISO8859-2 sr_YU.ISO8859-5 sr_YU.UTF-8 Can we bring these back? Their absence is causing test failures. -- Craig From owner-freebsd-current@freebsd.org Mon Nov 16 08:25:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19302A30F1C; Mon, 16 Nov 2015 08:25:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D7931B73; Mon, 16 Nov 2015 08:25:38 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmec201 with SMTP id c201so163462015wme.0; Mon, 16 Nov 2015 00:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BNBh0csRLoNzJfU0KTqXO8CaHRWVvho6ebxdwR9eFe0=; b=J33sINXiQ+gqAH2TMVHJ/gSsTRxNuRKbYExLZ3sWy2fYHYJRh9nDoKcLlhIYnTDqcv dQS7eU8GW6hh0AZO0XahSYJlBkbm47atbglRE2TqqAHsoSG4seE8R9C69B3TVxh+DJWS t+buNUB5rJqs0DjJToQXDfvdeAYmkTu1mjTf84k6Yfmf5HdvBqe9AAihxjY0L5taDNX5 Fb/zlgIZpESB2klA+jFxtBU5XRAGroFByi7WEHKqffueW+7sN8OtCOHKDpfcJYJYPOKF xri/Fx8UltfnirQAoJ8u+ZwwLwlXIIGI6jjQxIG809LeKQk1CvbUyoj1Izyfi5IcQDVp 9TVQ== X-Received: by 10.28.9.204 with SMTP id 195mr18589529wmj.88.1447662336401; Mon, 16 Nov 2015 00:25:36 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id lf10sm33254384wjb.23.2015.11.16.00.25.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 00:25:35 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 16 Nov 2015 09:25:33 +0100 From: Baptiste Daroussin To: Craig Rodrigues Cc: Bryan Drewery , "freebsd-testing@freebsd.org" , freebsd-current Current Subject: Re: Missing locales causing test failures Message-ID: <20151116082531.GL93991@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1hKfHPzOXWu1rh0v" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 08:25:39 -0000 --1hKfHPzOXWu1rh0v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2015 at 12:09:01AM -0800, Craig Rodrigues wrote: > Hi, >=20 > I compared the output of "locale -a" from a CURRENT system built > a few days ago, to the latest build. The latest build still has some > missing locales, >=20 >=20 > af_ZA.ISO8859-15 > en_AU.ISO8859-15 > en_CA.ISO8859-15 > en_NZ.ISO8859-15 > en_US.ISO8859-15 > fr_CA.ISO8859-15 > lt_LT.ISO8859-4 > sr_YU.ISO8859-2 > sr_YU.ISO8859-5 > sr_YU.UTF-8 >=20 > Can we bring these back? Their absence is causing test failures. >=20 I would be surprised they do cause any failures. do you have a link to the = said failures? Best regards, Bapt --1hKfHPzOXWu1rh0v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZJkvsACgkQ8kTtMUmk6Ez0+gCfeXnwHebttSUcD5JVh2fMsohK 5wEAniOx4ZStINNb32XzjR1HYNHI/NG2 =XScr -----END PGP SIGNATURE----- --1hKfHPzOXWu1rh0v-- From owner-freebsd-current@freebsd.org Mon Nov 16 08:28:07 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96BAEA30FA4 for ; Mon, 16 Nov 2015 08:28:07 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 295E31CE6; Mon, 16 Nov 2015 08:28:07 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmec201 with SMTP id c201so108168431wme.1; Mon, 16 Nov 2015 00:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Z2GLVcOrWCrcx5/+Ll3SQHHTbet3YUlrQg9lQMnCppQ=; b=FfX5gf3CEk1Zy8qxPBUlG9UZ1TOyY26YZVKGjNZlDXyu1QuW2KhRMOs7PTXaeVosLv hKIAQe8pqv9BnCaSEsTvIyzqgB2lIQsZSkWhFLtgSAWSFj//KmSOfZzgfI3DVgTwFS08 HsfgeFRw7PEpYg+DcT+9k7IihlD13cHqfjsElC9KzQBUM7WIcSTpb9Jv1VmF3z2dv1Wm 27j/+3twD7QcLehoPAqCreTfwF+Htc4/az9I8GwijkX2Gnj6z5ALMkDSAXMTPbvJZu/u 0KOEHR+/rXrnUUpSnq/mkTHeerTH6czJUNMFFaoQ+WNkPtyyTjzNyKJ2+5//v4IrdfFZ GXSg== X-Received: by 10.28.182.11 with SMTP id g11mr18195415wmf.42.1447662485539; Mon, 16 Nov 2015 00:28:05 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id z66sm4090391wmz.7.2015.11.16.00.28.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 00:28:05 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 16 Nov 2015 09:28:03 +0100 From: Baptiste Daroussin To: "O. Hartmann" Cc: Craig Rodrigues , NGie Cooper , freebsd-current Current , Bryan Drewery Subject: Re: make installworld failing with locales due to broken symlinks Message-ID: <20151116082801.GM93991@ivaldir.etoilebsd.net> References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> <20151116081436.218566a9.ohartman@zedat.fu-berlin.de> <20151116082226.6a44ac3a.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kunpHVz1op/+13PW" Content-Disposition: inline In-Reply-To: <20151116082226.6a44ac3a.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 08:28:07 -0000 --kunpHVz1op/+13PW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2015 at 08:22:26AM +0100, O. Hartmann wrote: > Am Mon, 16 Nov 2015 08:14:36 +0100 > "O. Hartmann" schrieb: >=20 > > Am Sun, 15 Nov 2015 19:59:54 -0800 > > Craig Rodrigues schrieb: > >=20 > > > On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper = wrote: > > > =20 > > > > > > > > install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file = or > > > > directory > > > > *** Error code 71 > > > > > > > > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 > > > > /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC= _CTYPE > > > > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > > /usr/share/locale/la_LN.ISO8859-1 > > > > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > > > > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > > > > =20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > I ran into the same error when I tried to upgrade a system that I did= an > > > installworld on > > > 2 days ago. > > >=20 > > > -- > > > Craig > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= =2Eorg" =20 > >=20 > > A "me, too" from here, I'm with CURRENT at revision 290924. Still faili= ng to "make > > installworld". > >=20 > > Kind regards, > >=20 > > oh >=20 > All right, missed the part "rm -rf". I deleted the file/link in question = and the world > gets installed as usual. Since yesterday (and the fixes from Craig on the symlinks today) that shoul= d not be needed anymore. Best regards, Bapt --kunpHVz1op/+13PW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZJk5EACgkQ8kTtMUmk6EyFsACfY71nYUeP/plqbXooifnWHY+F hVYAn3/8uXeGBEh886PaHJ8YB8nEvcxl =E5xp -----END PGP SIGNATURE----- --kunpHVz1op/+13PW-- From owner-freebsd-current@freebsd.org Mon Nov 16 08:29:25 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57170A3000F; Mon, 16 Nov 2015 08:29:25 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14D701E0C; Mon, 16 Nov 2015 08:29:25 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykdr82 with SMTP id r82so226686440ykd.3; Mon, 16 Nov 2015 00:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yshgAnWXHJ0uE55ZpCOMBXaVs+pHrA5K0ec7BVZ68oQ=; b=SsDOnCCZGq6I8Dti9eO1ziKvMVNj1ouTpwOrjREVQtquY3WV/nOHte5Lbd/l4U5EhB Xq51p7KBN6Mne/bRN7JaSm4KRTKjD2Je1jPKseeWMPssoivfpMVSLIPgqz2RuSps3pfF bVbgzBx4u1W0VKNCrQKvADpgGjeijqkFYfMR8s/lWIztk7J/AM8l9sO+C0qk0yDqRYiP XdAmW++q4VproM33Qpp17dXToVDdzg0yyb3P6xs04+8oXtP0TvKo9Vm9+kjrM6T5jDpx Fx8l9yv50Ta1hPRBzNglDACxPlvz1tL9RmhsxFA+KoUux7qjtTFIY/jgiOUUhA8CYzmR YSbA== MIME-Version: 1.0 X-Received: by 10.129.146.197 with SMTP id j188mr34110932ywg.19.1447662564239; Mon, 16 Nov 2015 00:29:24 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.37.95.9 with HTTP; Mon, 16 Nov 2015 00:29:24 -0800 (PST) In-Reply-To: <20151116082531.GL93991@ivaldir.etoilebsd.net> References: <20151116082531.GL93991@ivaldir.etoilebsd.net> Date: Mon, 16 Nov 2015 00:29:24 -0800 X-Google-Sender-Auth: rUJ5GsxvHz1gOQ1cGYHTFgq56OU Message-ID: Subject: Re: Missing locales causing test failures From: Craig Rodrigues To: Baptiste Daroussin Cc: Bryan Drewery , "freebsd-testing@freebsd.org" , freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 08:29:25 -0000 On Mon, Nov 16, 2015 at 12:25 AM, Baptiste Daroussin wrote: > On Mon, Nov 16, 2015 at 12:09:01AM -0800, Craig Rodrigues wrote: > > Hi, > > > > I compared the output of "locale -a" from a CURRENT system built > > a few days ago, to the latest build. The latest build still has some > > missing locales, > > > > > > af_ZA.ISO8859-15 > > en_AU.ISO8859-15 > > en_CA.ISO8859-15 > > en_NZ.ISO8859-15 > > en_US.ISO8859-15 > > fr_CA.ISO8859-15 > > lt_LT.ISO8859-4 > > sr_YU.ISO8859-2 > > sr_YU.ISO8859-5 > > sr_YU.UTF-8 > > > > Can we bring these back? Their absence is causing test failures. > > > I would be surprised they do cause any failures. do you have a link to the > said > failures? > https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1695/testReport/ From owner-freebsd-current@freebsd.org Mon Nov 16 09:20:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 823A3A30C25 for ; Mon, 16 Nov 2015 09:20:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5AF1281; Mon, 16 Nov 2015 09:20:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 987C14B8; Mon, 16 Nov 2015 09:20:15 +0000 (UTC) Date: Mon, 16 Nov 2015 09:20:14 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1700038958.21.1447665615244.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1168262390.19.1447655369532.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1168262390.19.1447655369532.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1696 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 09:20:15 -0000 FreeBSD_HEAD-tests - Build #1696 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1696/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1696/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1696/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Mon Nov 16 09:35:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FD15A2E06F for ; Mon, 16 Nov 2015 09:35:38 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62CD71B93; Mon, 16 Nov 2015 09:35:37 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1ZyGCF-000NNa-Aq>; Mon, 16 Nov 2015 10:35:35 +0100 Received: from x5ce13eec.dyn.telefonica.de ([92.225.62.236] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1ZyGCF-00324l-3Y>; Mon, 16 Nov 2015 10:35:35 +0100 Date: Mon, 16 Nov 2015 10:35:34 +0100 From: "O. Hartmann" To: Baptiste Daroussin Cc: Craig Rodrigues , NGie Cooper , freebsd-current Current , Bryan Drewery Subject: Re: make installworld failing with locales due to broken symlinks Message-ID: <20151116103534.5f2ae783.ohartman@zedat.fu-berlin.de> In-Reply-To: <20151116082801.GM93991@ivaldir.etoilebsd.net> References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> <20151116081436.218566a9.ohartman@zedat.fu-berlin.de> <20151116082226.6a44ac3a.ohartman@zedat.fu-berlin.de> <20151116082801.GM93991@ivaldir.etoilebsd.net> Organization: FU Berlin X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/+wNdeyivGLCzQRksDoPo8oQ"; protocol="application/pgp-signature" X-Originating-IP: 92.225.62.236 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 09:35:38 -0000 --Sig_/+wNdeyivGLCzQRksDoPo8oQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 16 Nov 2015 09:28:03 +0100 Baptiste Daroussin schrieb: > On Mon, Nov 16, 2015 at 08:22:26AM +0100, O. Hartmann wrote: > > Am Mon, 16 Nov 2015 08:14:36 +0100 > > "O. Hartmann" schrieb: > > =20 > > > Am Sun, 15 Nov 2015 19:59:54 -0800 > > > Craig Rodrigues schrieb: > > > =20 > > > > On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper wrote: > > > > =20 > > > > > > > > > > install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such fil= e or > > > > > directory > > > > > *** Error code 71 > > > > > > > > > > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > > > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 > > > > > /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/= LC_CTYPE > > > > > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > > > /usr/share/locale/la_LN.ISO8859-1 > > > > > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > > > > > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > > > > > =20 > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > I ran into the same error when I tried to upgrade a system that I d= id an > > > > installworld on > > > > 2 days ago. > > > >=20 > > > > -- > > > > Craig > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" =20 > > >=20 > > > A "me, too" from here, I'm with CURRENT at revision 290924. Still fai= ling to "make > > > installworld". > > >=20 > > > Kind regards, > > >=20 > > > oh =20 > >=20 > > All right, missed the part "rm -rf". I deleted the file/link in questio= n and the world > > gets installed as usual. =20 >=20 > Since yesterday (and the fixes from Craig on the symlinks today) that sho= uld not > be needed anymore. >=20 > Best regards, > Bapt That ist NOT(!) the case in: URL: http://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 290925 Node Kind: directory Schedule: normal Last Changed Author: ae Last Changed Rev: 290924 Last Changed Date: 2015-11-16 08:10:42 +0100 (Mo., 16 Nov. 2015) I just updated a box running now FreeBSD CURRENT FreeBSD 11.0-CURRENT #11 r= 290688: Wed Nov 11 21:27:57 CET 2015 amd64. Kind regards, oh --Sig_/+wNdeyivGLCzQRksDoPo8oQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWSaNmAAoJEOgBcD7A/5N8qIMH/jQ2VG63Z4wFjikSXRMOgLze Zobqw6xMID9UC09mROIrg9WjkYL3B0cTOdv0+Yhr3HPb68kSe1WYtDwFXrLLoY84 /kjvBmXWvg0lULg3TikFPkZDt/xW0TkTPonXXySbGoFqPOpNT36E0MnlRz83rot8 GoOtK9BJR67A/R6Y76lBuD5/8aHufFnPAedZR+cSF4+BkYowXaKtMXb064ObZ8N3 6IcW+Ca//8oaKgy4Rp9YoCscXco2S3Q9Gs2MISOqV+8eE5n4awamnE+hbi7XPv4c O7WhfBrVeUIcIaK8EeS64c97vG4zulit2mVbAQbCoJrgEIkAVRwug01uB0tic8Q= =QKbP -----END PGP SIGNATURE----- --Sig_/+wNdeyivGLCzQRksDoPo8oQ-- From owner-freebsd-current@freebsd.org Mon Nov 16 09:43:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A6C1A2E3A9 for ; Mon, 16 Nov 2015 09:43:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D97110B4; Mon, 16 Nov 2015 09:43:38 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmdw130 with SMTP id w130so102727871wmd.0; Mon, 16 Nov 2015 01:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=aYdo7UMitOxwYAl4gpnlARwlcFERMGYoPcqv+Q35iUA=; b=h5eE+ZoLnmezxYMe31hOFZiAzKbBVxdjp4lXhLuEnH2VYobt2UYRrCQJ3XeOjh5vPg rAVYKfn1gpOepsDEXQfBH/h6atyjqH92pmHYPtwiI503wtdTYEuHG3IlQzMrI/q3i1nl 3NWUdd4f1IJzJKfdedVCBJKL8khBzc1Ny6pPOnlMCREV6wKKd0ylOKPtOHRS9SzAH2iQ HnKAiXKdoNj9F540HLVEFVgALJqBELYeucH4OUobfz0PF80YnlsA08++eVEl9SwYDt3U 0QKYVIXU9N/BT7ZQ0pJklbMWU5phVknGXpnN+MwpgpPG0zboJo0zMaRIuKmyBMxfSeni imHg== X-Received: by 10.194.78.15 with SMTP id x15mr40259110wjw.144.1447667016672; Mon, 16 Nov 2015 01:43:36 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id cv3sm32245669wjc.20.2015.11.16.01.43.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 01:43:35 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 16 Nov 2015 10:43:33 +0100 From: Baptiste Daroussin To: "O. Hartmann" Cc: Craig Rodrigues , NGie Cooper , freebsd-current Current , Bryan Drewery Subject: Re: make installworld failing with locales due to broken symlinks Message-ID: <20151116094333.GA55780@ivaldir.etoilebsd.net> References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> <20151116081436.218566a9.ohartman@zedat.fu-berlin.de> <20151116082226.6a44ac3a.ohartman@zedat.fu-berlin.de> <20151116082801.GM93991@ivaldir.etoilebsd.net> <20151116103534.5f2ae783.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <20151116103534.5f2ae783.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 09:43:39 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2015 at 10:35:34AM +0100, O. Hartmann wrote: > Am Mon, 16 Nov 2015 09:28:03 +0100 > Baptiste Daroussin schrieb: >=20 > > On Mon, Nov 16, 2015 at 08:22:26AM +0100, O. Hartmann wrote: > > > Am Mon, 16 Nov 2015 08:14:36 +0100 > > > "O. Hartmann" schrieb: > > > =20 > > > > Am Sun, 15 Nov 2015 19:59:54 -0800 > > > > Craig Rodrigues schrieb: > > > > =20 > > > > > On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper wrote: > > > > > =20 > > > > > > > > > > > > install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such f= ile or > > > > > > directory > > > > > > *** Error code 71 > > > > > > > > > > > > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > > > > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 > > > > > > /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-= 1/LC_CTYPE > > > > > > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > > > > > > /usr/share/locale/la_LN.ISO8859-1 > > > > > > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > > > > > > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory > > > > > > =20 > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > I ran into the same error when I tried to upgrade a system that I= did an > > > > > installworld on > > > > > 2 days ago. > > > > >=20 > > > > > -- > > > > > Craig > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" =20 > > > >=20 > > > > A "me, too" from here, I'm with CURRENT at revision 290924. Still f= ailing to "make > > > > installworld". > > > >=20 > > > > Kind regards, > > > >=20 > > > > oh =20 > > >=20 > > > All right, missed the part "rm -rf". I deleted the file/link in quest= ion and the world > > > gets installed as usual. =20 > >=20 > > Since yesterday (and the fixes from Craig on the symlinks today) that s= hould not > > be needed anymore. > >=20 > > Best regards, > > Bapt >=20 > That ist NOT(!) the case in: >=20 I meant updating from a pre-collation current to a current as of today. any= one that updated in the meantime would have to rm -rf yes. I will add an entry = on UPDATING about that. Best regards, Bapt --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEUEARECAAYFAlZJpUUACgkQ8kTtMUmk6Ey/twCXUT1/yqM7iNz0RauFtxpLTIGs XgCfXq5U/4+GtC1907bEGFN4iBZwpFM= =qfCN -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-current@freebsd.org Mon Nov 16 09:47:02 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2A8BA2E573 for ; Mon, 16 Nov 2015 09:47:02 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD713133A for ; Mon, 16 Nov 2015 09:47:02 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 747BA78A1 for ; Mon, 16 Nov 2015 10:46:59 +0100 (CET) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Jan Bramkamp Message-ID: <5649A612.3090905@rlwinm.de> Date: Mon, 16 Nov 2015 10:46:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 09:47:03 -0000 On 15/11/15 13:54, Dan Partelly wrote: > 2. I have seen the idea that this makes the information dumped by utilities in the base easily accessible programatically. OK, maybe it does , but > it doesn't fit with the current paradigm of "tool | filter | tool” at all. There are no tools able to accept JSON and filter it in any meaningful way, and I > dont see too many ppl changing their code to read JSON instead of text. I don't even see the base tools changing. This output may be useful in corner cases only. There is jq [https://stedolan.github.io/jq/]. You can think of it as sed + awk + grep for streams of JSON objects. From owner-freebsd-current@freebsd.org Mon Nov 16 12:01:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60EB2A2FB17 for ; Mon, 16 Nov 2015 12:01:51 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 511981B92; Mon, 16 Nov 2015 12:01:51 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1637B512; Mon, 16 Nov 2015 12:01:50 +0000 (UTC) Date: Mon, 16 Nov 2015 12:01:49 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1796309839.23.1447675309559.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1700038958.21.1447665615244.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1700038958.21.1447665615244.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1697 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 12:01:51 -0000 FreeBSD_HEAD-tests - Build #1697 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1697/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1697/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1697/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Mon Nov 16 04:13:23 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40BAAA30CFB for ; Mon, 16 Nov 2015 04:13:23 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD1F01B2E for ; Mon, 16 Nov 2015 04:13:22 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igcph11 with SMTP id ph11so49719653igc.1 for ; Sun, 15 Nov 2015 20:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:content-type:mime-version:subject:date; bh=mkxzA2EUmBC7KeVf2OqzyYLJeec3c95yKQo5IPHwuxI=; b=UkQwqFVd5jsm5OHjUIHCP9pXCxlPGfcYuM+0VZveUc98C0AAfn+wDSneIHo4Iv68Os SnkbgBOyv/oxa77a/mLVOM4C2c+FjYS8gnpTkG1STcSrxn9F71v7UA13aY+NKpq0BNop 0cck8NjVsTt+2eO0+bWf7SYFzzORigdNhhYNaDq4tgCRE8/DUydSOeot/9/3WxiEwRy7 CxrxWSJDBkfpLpS39Npb05zftI8AOEol8Z2mfWzRQtShxwttfIsOqItCIe2eRlMVclhP X3Q2HB3waB2EqYkgz/Orf0GnbfWcJl7cCV00QtBrL3f6bVxMRtiFXsUCNrERhqdc33Y8 7AyA== X-Received: by 10.50.114.233 with SMTP id jj9mr5550629igb.32.1447647202114; Sun, 15 Nov 2015 20:13:22 -0800 (PST) Received: from blackstar.knownspace (c-98-240-160-157.hsd1.mn.comcast.net. [98.240.160.157]) by smtp.gmail.com with ESMTPSA id o77sm10670021ioe.11.2015.11.15.20.13.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 15 Nov 2015 20:13:21 -0800 (PST) Message-Id: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> From: Justin Hibbits To: FreeBSD Current Content-Type: multipart/mixed; boundary=Apple-Mail-18--958907149 Mime-Version: 1.0 (Apple Message framework v936) Subject: CFT: uintmax_t rman Date: Sun, 15 Nov 2015 22:13:31 -0600 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 16 Nov 2015 12:23:17 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 04:13:23 -0000 --Apple-Mail-18--958907149 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit (Attempted to send this yesterday, but appears it didn't go through. Apologies if it really did go through). As part of a project getting FreeBSD on the Freescale P5020 SoC, I increased the width of resources, from u_long(32 bits on 32-bit archs, 64 bits on 64-bit archs) to uintmax_t (currently 64 bits on all archs). I have it working on PowerPC, but have not tested it on any other architecture, I have no other systems to test it with, so I need help. This passes a tinderbox build. I need this tested on other archs, the more the better, especially i386, including PAE. It should be effectively a no-op on most architectures, especially 64- bit archs, though there were some checks I found in x86 code clamping address checks to under 4GB, commented as necessary purely for rman. If this isn't the case, and we can't yet handle the checks being removed, they can go in, but that needs testing. It should apply cleanly to recent head. - Justin --Apple-Mail-18--958907149 Content-Disposition: attachment; filename=rman_umax.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="rman_umax.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/nexus.c =================================================================== --- sys/arm/arm/nexus.c (revision 290622) +++ sys/arm/arm/nexus.c (working copy) @@ -82,7 +82,7 @@ static int nexus_print_child(device_t, device_t); static device_t nexus_add_child(device_t, u_int, const char *, int); static struct resource *nexus_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, u_int); static int nexus_activate_resource(device_t, device_t, int, int, struct resource *); #ifdef ARM_INTRNG @@ -159,7 +159,7 @@ { mem_rman.rm_start = 0; - mem_rman.rm_end = ~0ul; + mem_rman.rm_end = ~0; mem_rman.rm_type = RMAN_ARRAY; mem_rman.rm_descr = "I/O memory addresses"; if (rman_init(&mem_rman) || rman_manage_region(&mem_rman, 0, ~0)) @@ -212,7 +212,7 @@ */ static struct resource * nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *rv; struct rman *rm; Index: sys/arm/at91/at91.c =================================================================== --- sys/arm/at91/at91.c (revision 290622) +++ sys/arm/at91/at91.c (working copy) @@ -304,7 +304,7 @@ static struct resource * at91_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct at91_softc *sc = device_get_softc(dev); struct resource_list_entry *rle; @@ -321,7 +321,7 @@ return (NULL); if (rle->res) panic("Resource rid %d type %d already in use", *rid, type); - if (start == 0UL && end == ~0UL) { + if (start == 0 && end == ~0) { start = rle->start; count = ulmax(count, rle->count); end = ulmax(rle->end, start + count - 1); @@ -412,7 +412,7 @@ struct resource *r) { #if 0 - u_long p; + uintmax_t p; int error; if (type == SYS_RES_MEMORY) { Index: sys/arm/at91/at91_pinctrl.c =================================================================== --- sys/arm/at91/at91_pinctrl.c (revision 290622) +++ sys/arm/at91/at91_pinctrl.c (working copy) @@ -280,7 +280,7 @@ * Request for the default allocation with a given rid: use resource * list stored in the local device info. */ - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == ~0)) { if ((di = device_get_ivars(child)) == NULL) return (NULL); Index: sys/arm/cavium/cns11xx/econa.c =================================================================== --- sys/arm/cavium/cns11xx/econa.c (revision 290622) +++ sys/arm/cavium/cns11xx/econa.c (working copy) @@ -408,7 +408,7 @@ static struct resource * econa_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct econa_softc *sc = device_get_softc(dev); struct resource_list_entry *rle; @@ -425,7 +425,7 @@ } if (rle->res) panic("Resource rid %d type %d already in use", *rid, type); - if (start == 0UL && end == ~0UL) { + if (start == 0 && end == ~0) { start = rle->start; count = ulmax(count, rle->count); end = ulmax(rle->end, start + count - 1); Index: sys/arm/mv/mv_localbus.c =================================================================== --- sys/arm/mv/mv_localbus.c (revision 290622) +++ sys/arm/mv/mv_localbus.c (working copy) @@ -100,7 +100,7 @@ static int localbus_print_child(device_t, device_t); static struct resource *localbus_alloc_resource(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); static struct resource_list *localbus_get_resource_list(device_t, device_t); static ofw_bus_get_devinfo_t localbus_get_devinfo; @@ -332,7 +332,7 @@ static struct resource * localbus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct localbus_devinfo *di; struct resource_list_entry *rle; @@ -341,7 +341,7 @@ * Request for the default allocation with a given rid: use resource * list stored in the local device info. */ - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == ~0)) { if ((di = device_get_ivars(child)) == NULL) return (NULL); Index: sys/arm/mv/mv_pci.c =================================================================== --- sys/arm/mv/mv_pci.c (revision 290622) +++ sys/arm/mv/mv_pci.c (working copy) @@ -332,7 +332,7 @@ static int mv_pcib_attach(device_t); static struct resource *mv_pcib_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, u_int); static int mv_pcib_release_resource(device_t, device_t, int, int, struct resource *); static int mv_pcib_read_ivar(device_t, device_t, int, uintptr_t *); @@ -830,7 +830,7 @@ static struct resource * mv_pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct mv_pcib_softc *sc = device_get_softc(dev); struct rman *rm = NULL; @@ -848,7 +848,7 @@ type, rid, start, end, count, flags)); }; - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == ~0)) { start = sc->sc_mem_base; end = sc->sc_mem_base + sc->sc_mem_size - 1; count = sc->sc_mem_size; Index: sys/arm/versatile/versatile_pci.c =================================================================== --- sys/arm/versatile/versatile_pci.c (revision 290622) +++ sys/arm/versatile/versatile_pci.c (working copy) @@ -305,7 +305,7 @@ static struct resource * versatile_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct versatile_pci_softc *sc = device_get_softc(bus); Index: sys/arm/xscale/i8134x/i81342.c =================================================================== --- sys/arm/xscale/i8134x/i81342.c (revision 290622) +++ sys/arm/xscale/i8134x/i81342.c (working copy) @@ -409,7 +409,7 @@ static struct resource * i81342_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct i81342_softc *sc = device_get_softc(dev); struct resource *rv; Index: sys/arm/xscale/i8134x/i81342_pci.c =================================================================== --- sys/arm/xscale/i8134x/i81342_pci.c (revision 290622) +++ sys/arm/xscale/i8134x/i81342_pci.c (working copy) @@ -328,7 +328,7 @@ static struct resource * i81342_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct i81342_pci_softc *sc = device_get_softc(bus); struct resource *rv; @@ -383,7 +383,7 @@ i81342_pci_activate_resource(device_t bus, device_t child, int type, int rid, struct resource *r) { - u_long p; + bus_space_handle_t p; int error; if (type == SYS_RES_MEMORY) { Index: sys/arm/xscale/i8134x/obio.c =================================================================== --- sys/arm/xscale/i8134x/obio.c (revision 290622) +++ sys/arm/xscale/i8134x/obio.c (working copy) @@ -91,7 +91,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *rv; struct rman *rm; Index: sys/arm/xscale/ixp425/avila_ata.c =================================================================== --- sys/arm/xscale/ixp425/avila_ata.c (revision 290622) +++ sys/arm/xscale/ixp425/avila_ata.c (working copy) @@ -282,12 +282,12 @@ static struct resource * ata_avila_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ata_avila_softc *sc = device_get_softc(dev); KASSERT(type == SYS_RES_IRQ && *rid == ATA_IRQ_RID, - ("type %u rid %u start %lu end %lu count %lu flags %u", + ("type %u rid %u start %ju end %ju count %ju flags %u", type, *rid, start, end, count, flags)); /* doesn't matter what we return so reuse the real thing */ Index: sys/arm/xscale/ixp425/ixp425.c =================================================================== --- sys/arm/xscale/ixp425/ixp425.c (revision 290622) +++ sys/arm/xscale/ixp425/ixp425.c (working copy) @@ -496,7 +496,7 @@ static struct resource * ixp425_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ixp425_softc *sc = device_get_softc(dev); const struct hwvtrans *vtrans; @@ -533,7 +533,7 @@ (start - vtrans->hwbase); if (bootverbose) device_printf(child, - "%s: assign 0x%lx:0x%lx%s\n", + "%s: assign 0x%jx:0x%jx%s\n", __func__, start, end - start, vtrans->isa4x ? " A4X" : vtrans->isslow ? " SLOW" : ""); @@ -542,7 +542,7 @@ vtrans = gethwvtrans(start, end - start); if (vtrans == NULL) { /* likely means above table needs to be updated */ - device_printf(child, "%s: no mapping for 0x%lx:0x%lx\n", + device_printf(child, "%s: no mapping for 0x%jx:0x%jx\n", __func__, start, end - start); return NULL; } @@ -549,7 +549,7 @@ rv = rman_reserve_resource(&sc->sc_mem_rman, start, end, end - start, flags, child); if (rv == NULL) { - device_printf(child, "%s: cannot reserve 0x%lx:0x%lx\n", + device_printf(child, "%s: cannot reserve 0x%jx:0x%jx\n", __func__, start, end - start); return NULL; } @@ -586,7 +586,7 @@ if (type == SYS_RES_MEMORY) { vtrans = gethwvtrans(rman_get_start(r), rman_get_size(r)); if (vtrans == NULL) { /* NB: should not happen */ - device_printf(child, "%s: no mapping for 0x%lx:0x%lx\n", + device_printf(child, "%s: no mapping for 0x%jx:0x%jx\n", __func__, rman_get_start(r), rman_get_size(r)); return (ENOENT); } Index: sys/arm/xscale/ixp425/ixp425_pci.c =================================================================== --- sys/arm/xscale/ixp425/ixp425_pci.c (revision 290622) +++ sys/arm/xscale/ixp425/ixp425_pci.c (working copy) @@ -269,7 +269,7 @@ static struct resource * ixppcib_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ixppcib_softc *sc = device_get_softc(bus); struct rman *rmanp; Index: sys/arm/xscale/pxa/pxa_obio.c =================================================================== --- sys/arm/xscale/pxa/pxa_obio.c (revision 290622) +++ sys/arm/xscale/pxa/pxa_obio.c (working copy) @@ -50,7 +50,7 @@ static struct resource_list * pxa_get_resource_list(device_t, device_t); static struct resource * pxa_alloc_resource(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); static int pxa_release_resource(device_t, device_t, int, int, struct resource *); static int pxa_activate_resource(device_t, device_t, @@ -57,7 +57,7 @@ int, int, struct resource *); static struct resource * pxa_alloc_gpio_irq(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); struct obio_device { const char *od_name; @@ -224,7 +224,7 @@ static struct resource * pxa_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct obio_softc *sc; struct obio_device *od; @@ -351,7 +351,7 @@ static struct resource * pxa_alloc_gpio_irq(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct obio_softc *sc; struct obio_device *od; @@ -390,7 +390,7 @@ } if (bootverbose) - device_printf(dev, "lazy allocation of irq %ld for %s\n", + device_printf(dev, "lazy allocation of irq %jd for %s\n", start, device_get_nameunit(child)); return (rv); Index: sys/arm/xscale/pxa/pxa_smi.c =================================================================== --- sys/arm/xscale/pxa/pxa_smi.c (revision 290622) +++ sys/arm/xscale/pxa/pxa_smi.c (working copy) @@ -70,7 +70,7 @@ static int pxa_smi_read_ivar(device_t, device_t, int, uintptr_t *); static struct resource * pxa_smi_alloc_resource(device_t, device_t, - int, int *, u_long, u_long, u_long, u_int); + int, int *, uintmax_t, uintmax_t, uintmax_t, u_int); static int pxa_smi_release_resource(device_t, device_t, int, int, struct resource *); static int pxa_smi_activate_resource(device_t, device_t, @@ -176,7 +176,7 @@ static struct resource * pxa_smi_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct pxa_smi_softc *sc; struct smi_ivars *smid; Index: sys/arm64/arm64/gic_v3_fdt.c =================================================================== --- sys/arm64/arm64/gic_v3_fdt.c (revision 290622) +++ sys/arm64/arm64/gic_v3_fdt.c (working copy) @@ -54,7 +54,7 @@ static int gic_v3_fdt_attach(device_t); static struct resource *gic_v3_ofw_bus_alloc_res(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, u_int); static const struct ofw_bus_devinfo *gic_v3_ofw_get_devinfo(device_t, device_t); static device_method_t gic_v3_fdt_methods[] = { @@ -174,13 +174,13 @@ static struct resource * gic_v3_ofw_bus_alloc_res(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct gic_v3_ofw_devinfo *di; struct resource_list_entry *rle; int ranges_len; - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == ~0)) { if ((di = device_get_ivars(child)) == NULL) return (NULL); if (type != SYS_RES_MEMORY) Index: sys/arm64/arm64/nexus.c =================================================================== --- sys/arm64/arm64/nexus.c (revision 290622) +++ sys/arm64/arm64/nexus.c (working copy) @@ -99,13 +99,14 @@ static int nexus_print_child(device_t, device_t); static device_t nexus_add_child(device_t, u_int, const char *, int); static struct resource *nexus_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, u_int); static int nexus_activate_resource(device_t, device_t, int, int, struct resource *); static int nexus_config_intr(device_t dev, int irq, enum intr_trigger trig, enum intr_polarity pol); static struct resource_list *nexus_get_reslist(device_t, device_t); -static int nexus_set_resource(device_t, device_t, int, int, u_long, u_long); +static int nexus_set_resource(device_t, device_t, int, int, + uintmax_t, uintmax_t); static int nexus_deactivate_resource(device_t, device_t, int, int, struct resource *); @@ -145,13 +146,13 @@ { mem_rman.rm_start = 0; - mem_rman.rm_end = ~0ul; + mem_rman.rm_end = ~0; mem_rman.rm_type = RMAN_ARRAY; mem_rman.rm_descr = "I/O memory addresses"; if (rman_init(&mem_rman) || rman_manage_region(&mem_rman, 0, ~0)) panic("nexus_attach mem_rman"); irq_rman.rm_start = 0; - irq_rman.rm_end = ~0ul; + irq_rman.rm_end = ~0; irq_rman.rm_type = RMAN_ARRAY; irq_rman.rm_descr = "Interrupts"; if (rman_init(&irq_rman) || rman_manage_region(&irq_rman, 0, ~0)) @@ -201,7 +202,7 @@ */ static struct resource * nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct nexus_device *ndev = DEVTONX(child); struct resource *rv; @@ -215,7 +216,7 @@ * (ie. they aren't maintained by a child bus), then work out * the start/end values. */ - if ((start == 0UL) && (end == ~0UL) && (count == 1)) { + if ((start == 0) && (end == ~0) && (count == 1)) { if (device_get_parent(child) != bus || ndev == NULL) return(NULL); rle = resource_list_find(&ndev->nx_resources, type, *rid); @@ -332,7 +333,7 @@ static int nexus_set_resource(device_t dev, device_t child, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { struct nexus_device *ndev = DEVTONX(child); struct resource_list *rl = &ndev->nx_resources; Index: sys/arm64/cavium/thunder_pcie.c =================================================================== --- sys/arm64/cavium/thunder_pcie.c (revision 290622) +++ sys/arm64/cavium/thunder_pcie.c (working copy) @@ -110,7 +110,7 @@ /* Forward prototypes */ static struct resource *thunder_pcie_alloc_resource(device_t, - device_t, int, int *, u_long, u_long, u_long, u_int); + device_t, int, int *, uintmax_t, uintmax_t, uintmax_t, u_int); static int thunder_pcie_attach(device_t); static int thunder_pcie_identify_pcib(device_t); static int thunder_pcie_maxslots(device_t); @@ -431,7 +431,7 @@ static struct resource * thunder_pcie_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct thunder_pcie_softc *sc = device_get_softc(dev); struct rman *rm = NULL; @@ -450,7 +450,7 @@ type, rid, start, end, count, flags)); }; - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == ~0)) { /* Read BAR manually to get resource address and size */ pci_read_bar(child, *rid, &map, &testval, NULL); @@ -519,7 +519,7 @@ thunder_pcie_identify_pcib(device_t dev) { struct thunder_pcie_softc *sc; - u_long start; + uintmax_t start; sc = device_get_softc(dev); start = bus_get_resource_start(dev, SYS_RES_MEMORY, 0); Index: sys/arm64/cavium/thunder_pcie_pem.c =================================================================== --- sys/arm64/cavium/thunder_pcie_pem.c (revision 290622) +++ sys/arm64/cavium/thunder_pcie_pem.c (working copy) @@ -126,7 +126,7 @@ }; static struct resource * thunder_pem_alloc_resource(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); static int thunder_pem_attach(device_t); static int thunder_pem_detach(device_t); static uint64_t thunder_pem_config_reg_read(struct thunder_pem_softc *, int); @@ -229,7 +229,7 @@ thunder_pem_identify(device_t dev) { struct thunder_pem_softc *sc; - u_long start; + uintmax_t start; sc = device_get_softc(dev); start = rman_get_start(sc->reg); @@ -425,7 +425,7 @@ static struct resource * thunder_pem_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct thunder_pem_softc *sc = device_get_softc(dev); struct rman *rm = NULL; @@ -446,7 +446,7 @@ end, count, flags)); }; - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == ~0)) { device_printf(dev, "Cannot allocate resource with unspecified range\n"); goto fail; Index: sys/boot/fdt/dts/powerpc/p5020ds.dts =================================================================== --- sys/boot/fdt/dts/powerpc/p5020ds.dts (revision 290622) +++ sys/boot/fdt/dts/powerpc/p5020ds.dts (working copy) @@ -54,11 +54,12 @@ emi1_rgmii = &hydra_mdio_rgmii; emi1_sgmii = &hydra_mdio_sgmii; emi2_xgmii = &hydra_mdio_xgmii; + soc = &soc; }; memory { device_type = "memory"; - reg = <0x00000000 0x00000000 0x00000000 0x80000000>; + reg = <0x00000000 0x00000000 0x00000000 0xc0000000>; }; dcsr: dcsr@f00000000 { @@ -340,8 +341,9 @@ enet3: ethernet@e6000 { tbi-handle = <&tbi3>; - phy-handle = <&phy_sgmii_1f>; - phy-connection-type = "sgmii"; + phy-handle = <&phy_rgmii_0>; + phy-connection-type = "rgmii"; + local-mac-address = [ 00 50 c2 20 db 11 ]; }; mdio@e7120 { @@ -361,6 +363,7 @@ tbi-handle = <&tbi4>; phy-handle = <&phy_rgmii_1>; phy-connection-type = "rgmii"; + local-mac-address = [ 00 50 c2 20 db 12 ]; }; mdio@e9120 { @@ -477,8 +480,10 @@ pci0: pcie@ffe200000 { reg = <0xf 0xfe200000 0 0x1000>; - ranges = <0x02000000 0 0x80000000 0x0 0x80000000 0x0 0x10000000 - 0x01000000 0 0x00000000 0x0 0xff000000 0x0 0x00010000>; + //ranges = <0x02000000 0 0x80000000 0x0 0x80000000 0x0 0x10000000 + // 0x01000000 0 0x00000000 0x0 0xff000000 0x0 0x00010000>; + ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000 + 0x1000000 0x0 0x00000000 0xf 0xf8000000 0x0 0x00010000>; pcie@0 { ranges = <0x02000000 0 0x80000000 0x02000000 0 0x80000000 @@ -492,8 +497,10 @@ pci1: pcie@ffe201000 { reg = <0xf 0xfe201000 0 0x1000>; - ranges = <0x02000000 0x0 0x90000000 0x0 0x90000000 0x0 0x10000000 - 0x01000000 0x0 0x00000000 0x0 0xff010000 0x0 0x00010000>; + //ranges = <0x02000000 0x0 0x90000000 0x0 0x90000000 0x0 0x10000000 + // 0x01000000 0x0 0x00000000 0x0 0xff010000 0x0 0x00010000>; + ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000 + 0x1000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>; pcie@0 { ranges = <0x02000000 0 0x90000000 0x02000000 0 0x90000000 @@ -507,8 +514,10 @@ pci2: pcie@ffe202000 { reg = <0xf 0xfe202000 0 0x1000>; - ranges = <0x02000000 0 0xa0000000 0x0 0xa0000000 0 0x10000000 - 0x01000000 0 0x00000000 0x0 0xff020000 0 0x00010000>; + //ranges = <0x02000000 0 0xa0000000 0x0 0xa0000000 0 0x10000000 + // 0x01000000 0 0x00000000 0x0 0xff020000 0 0x00010000>; + ranges = <0x2000000 0x0 0xe0000000 0xc 0x40000000 0x0 0x20000000 + 0x1000000 0x0 0x00000000 0xf 0xf8020000 0x0 0x00010000>; pcie@0 { ranges = <0x02000000 0 0xa0000000 0x02000000 0 0xa0000000 @@ -522,8 +531,10 @@ pci3: pcie@ffe203000 { reg = <0xf 0xfe203000 0 0x1000>; - ranges = <0x02000000 0 0xb0000000 0x0 0xb0000000 0 0x08000000 - 0x01000000 0 0x00000000 0x0 0xff030000 0 0x00010000>; + //ranges = <0x02000000 0 0xb0000000 0x0 0xb0000000 0 0x08000000 + // 0x01000000 0 0x00000000 0x0 0xff030000 0 0x00010000>; + ranges = <0x2000000 0x0 0xe0000000 0xc 0x60000000 0x0 0x20000000 + 0x1000000 0x0 0x00000000 0xf 0xf8030000 0x0 0x00010000>; pcie@0 { ranges = <0x02000000 0 0xb0000000 0x02000000 0 0xb0000000 @@ -542,7 +553,7 @@ compatible = "fsl,p5020-dpa-ethernet", "fsl,dpa-ethernet"; fsl,qman-channel = <&qpool1>; fsl,fman-mac = <&enet0>; - status = "okay"; + status = "disabled"; }; ethernet@1 { compatible = "fsl,p5020-dpa-ethernet", "fsl,dpa-ethernet"; @@ -560,7 +571,7 @@ compatible = "fsl,p5020-dpa-ethernet", "fsl,dpa-ethernet"; fsl,qman-channel = <&qpool1>; fsl,fman-mac = <&enet3>; - status = "disabled"; + status = "okay"; }; ethernet@4 { compatible = "fsl,p5020-dpa-ethernet", "fsl,dpa-ethernet"; Index: sys/compat/ndis/kern_ndis.c =================================================================== --- sys/compat/ndis/kern_ndis.c (revision 290622) +++ sys/compat/ndis/kern_ndis.c (working copy) @@ -348,13 +348,13 @@ ndis_add_sysctl(sc, "BusType", "Bus Type", buf, NDIS_FLAG_RDONLY); if (sc->ndis_res_io != NULL) { - sprintf(buf, "0x%lx", rman_get_start(sc->ndis_res_io)); + sprintf(buf, "0x%jx", rman_get_start(sc->ndis_res_io)); ndis_add_sysctl(sc, "IOBaseAddress", "Base I/O Address", buf, NDIS_FLAG_RDONLY); } if (sc->ndis_irq != NULL) { - sprintf(buf, "%lu", rman_get_start(sc->ndis_irq)); + sprintf(buf, "%ju", rman_get_start(sc->ndis_irq)); ndis_add_sysctl(sc, "InterruptNumber", "Interrupt Number", buf, NDIS_FLAG_RDONLY); } Index: sys/conf/files.powerpc =================================================================== --- sys/conf/files.powerpc (revision 290622) +++ sys/conf/files.powerpc (working copy) @@ -74,7 +74,7 @@ dev/tsec/if_tsec.c optional tsec dev/tsec/if_tsec_fdt.c optional tsec fdt dev/uart/uart_cpu_powerpc.c optional uart -dev/usb/controller/ehci_fsl.c optional ehci mpc85xx +dev/usb/controller/ehci_fsl.c optional ehci mpc85xx | ehci qoriq_dpaa dev/vt/hw/ofwfb/ofwfb.c optional vt aim kern/kern_clocksource.c standard kern/subr_dummy_vdso_tc.c standard @@ -133,15 +133,15 @@ powerpc/mpc85xx/atpic.c optional mpc85xx isa powerpc/mpc85xx/ds1553_bus_fdt.c optional ds1553 fdt powerpc/mpc85xx/ds1553_core.c optional ds1553 -powerpc/mpc85xx/fsl_sdhc.c optional mpc85xx sdhc +powerpc/mpc85xx/fsl_sdhc.c optional mpc85xx sdhc | qoriq_dpaa sdhc powerpc/mpc85xx/i2c.c optional iicbus fdt powerpc/mpc85xx/isa.c optional mpc85xx isa -powerpc/mpc85xx/lbc.c optional mpc85xx -powerpc/mpc85xx/mpc85xx.c optional mpc85xx +powerpc/mpc85xx/lbc.c optional mpc85xx | qoriq_dpaa +powerpc/mpc85xx/mpc85xx.c optional mpc85xx | qoriq_dpaa powerpc/mpc85xx/mpc85xx_gpio.c optional mpc85xx gpio -powerpc/mpc85xx/platform_mpc85xx.c optional mpc85xx -powerpc/mpc85xx/pci_mpc85xx.c optional pci mpc85xx -powerpc/mpc85xx/pci_mpc85xx_pcib.c optional pci mpc85xx +powerpc/mpc85xx/platform_mpc85xx.c optional mpc85xx | qoriq_dpaa +powerpc/mpc85xx/pci_mpc85xx.c optional pci mpc85xx | pci qoriq_dpaa +powerpc/mpc85xx/pci_mpc85xx_pcib.c optional pci mpc85xx | pci qoriq_dpaa powerpc/ofw/ofw_machdep.c standard powerpc/ofw/ofw_pci.c optional pci powerpc/ofw/ofw_pcibus.c optional pci Index: sys/conf/options.powerpc =================================================================== --- sys/conf/options.powerpc (revision 290622) +++ sys/conf/options.powerpc (working copy) @@ -19,6 +19,7 @@ GFB_NO_MODE_CHANGE opt_gfb.h MPC85XX opt_platform.h +QORIQ_DPAA opt_platform.h POWERMAC opt_platform.h PS3 opt_platform.h MAMBO Index: sys/dev/aac/aac.c =================================================================== --- sys/dev/aac/aac.c (revision 290622) +++ sys/dev/aac/aac.c (working copy) @@ -1781,7 +1781,7 @@ bus_release_resource(sc->aac_dev, SYS_RES_MEMORY, rid, sc->aac_regs_res1); sc->aac_regs_res1 = bus_alloc_resource(sc->aac_dev, - SYS_RES_MEMORY, &rid, 0ul, ~0ul, atu_size, RF_ACTIVE); + SYS_RES_MEMORY, &rid, 0, ~0, atu_size, RF_ACTIVE); if (sc->aac_regs_res1 == NULL) { sc->aac_regs_res1 = bus_alloc_resource_any( sc->aac_dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); Index: sys/dev/aacraid/aacraid.c =================================================================== --- sys/dev/aacraid/aacraid.c (revision 290622) +++ sys/dev/aacraid/aacraid.c (working copy) @@ -1665,7 +1665,7 @@ sc->aac_regs_rid0, sc->aac_regs_res0); sc->aac_regs_res0 = bus_alloc_resource( sc->aac_dev, SYS_RES_MEMORY, &sc->aac_regs_rid0, - 0ul, ~0ul, atu_size, RF_ACTIVE); + 0, ~0, atu_size, RF_ACTIVE); if (sc->aac_regs_res0 == NULL) { sc->aac_regs_res0 = bus_alloc_resource_any( sc->aac_dev, SYS_RES_MEMORY, Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 290622) +++ sys/dev/acpica/acpi.c (working copy) @@ -121,12 +121,12 @@ static void acpi_reserve_resources(device_t dev); static int acpi_sysres_alloc(device_t dev); static int acpi_set_resource(device_t dev, device_t child, int type, - int rid, u_long start, u_long count); + int rid, uintmax_t start, uintmax_t count); static struct resource *acpi_alloc_resource(device_t bus, device_t child, - int type, int *rid, u_long start, u_long end, - u_long count, u_int flags); + int type, int *rid, uintmax_t start, uintmax_t end, + uintmax_t count, u_int flags); static int acpi_adjust_resource(device_t bus, device_t child, int type, - struct resource *r, u_long start, u_long end); + struct resource *r, uintmax_t start, uintmax_t end); static int acpi_release_resource(device_t bus, device_t child, int type, int rid, struct resource *r); static void acpi_delete_resource(device_t bus, device_t child, int type, @@ -460,7 +460,7 @@ panic("acpi rman_init IO ports failed"); acpi_rman_mem.rm_type = RMAN_ARRAY; acpi_rman_mem.rm_start = 0; - acpi_rman_mem.rm_end = ~0ul; + acpi_rman_mem.rm_end = ~0; acpi_rman_mem.rm_descr = "ACPI I/O memory addresses"; if (rman_init(&acpi_rman_mem) != 0) panic("acpi rman_init memory failed"); @@ -793,10 +793,10 @@ int retval = 0; retval += bus_print_child_header(bus, child); - retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#lx"); - retval += resource_list_print_type(rl, "iomem", SYS_RES_MEMORY, "%#lx"); - retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld"); - retval += resource_list_print_type(rl, "drq", SYS_RES_DRQ, "%ld"); + retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#jx"); + retval += resource_list_print_type(rl, "iomem", SYS_RES_MEMORY, "%#jx"); + retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%jd"); + retval += resource_list_print_type(rl, "drq", SYS_RES_DRQ, "%jd"); if (device_get_flags(child)) retval += printf(" flags %#x", device_get_flags(child)); retval += bus_print_child_domain(bus, child); @@ -1154,7 +1154,7 @@ rl = BUS_GET_RESOURCE_LIST(device_get_parent(dev), dev); STAILQ_FOREACH(rle, rl, link) { if (rle->res != NULL) { - device_printf(dev, "duplicate resource for %lx\n", rle->start); + device_printf(dev, "duplicate resource for %jx\n", rle->start); continue; } @@ -1177,7 +1177,7 @@ rman_manage_region(rm, rman_get_start(res), rman_get_end(res)); rle->res = res; } else if (bootverbose) - device_printf(dev, "reservation of %lx, %lx (%d) failed\n", + device_printf(dev, "reservation of %jx, %jx (%d) failed\n", rle->start, rle->count, rle->type); } return (0); @@ -1247,13 +1247,13 @@ static int acpi_set_resource(device_t dev, device_t child, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { struct acpi_softc *sc = device_get_softc(dev); struct acpi_device *ad = device_get_ivars(child); struct resource_list *rl = &ad->ad_rl; ACPI_DEVICE_INFO *devinfo; - u_long end; + uintmax_t end; /* Ignore IRQ resources for PCI link devices. */ if (type == SYS_RES_IRQ && ACPI_ID_PROBE(dev, child, pcilink_ids) != NULL) @@ -1323,7 +1323,7 @@ static struct resource * acpi_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { ACPI_RESOURCE ares; struct acpi_device *ad; @@ -1330,7 +1330,7 @@ struct resource_list_entry *rle; struct resource_list *rl; struct resource *res; - int isdefault = (start == 0UL && end == ~0UL); + int isdefault = (start == 0 && end == ~0); /* * First attempt at allocating the resource. For direct children, @@ -1399,8 +1399,8 @@ * system resources. */ struct resource * -acpi_alloc_sysres(device_t child, int type, int *rid, u_long start, u_long end, - u_long count, u_int flags) +acpi_alloc_sysres(device_t child, int type, int *rid, uintmax_t start, + uintmax_t end, uintmax_t count, u_int flags) { struct rman *rm; struct resource *res; @@ -1450,7 +1450,7 @@ static int acpi_adjust_resource(device_t bus, device_t child, int type, struct resource *r, - u_long start, u_long end) + uintmax_t start, uintmax_t end) { if (acpi_is_resource_managed(type, r)) Index: sys/dev/acpica/acpi_hpet.c =================================================================== --- sys/dev/acpica/acpi_hpet.c (revision 290622) +++ sys/dev/acpica/acpi_hpet.c (working copy) @@ -322,7 +322,7 @@ static int hpet_find_irq_rid(device_t dev, u_long start, u_long end) { - u_long irq; + uintmax_t irq; int error, rid; for (rid = 0;; rid++) { @@ -442,7 +442,7 @@ /* Validate that we can access the whole region. */ if (rman_get_size(sc->mem_res) < HPET_MEM_WIDTH) { - device_printf(dev, "memory region width %ld too small\n", + device_printf(dev, "memory region width %jd too small\n", rman_get_size(sc->mem_res)); bus_free_resource(dev, SYS_RES_MEMORY, sc->mem_res); return (ENXIO); Index: sys/dev/acpica/acpi_pcib_acpi.c =================================================================== --- sys/dev/acpica/acpi_pcib_acpi.c (revision 290622) +++ sys/dev/acpica/acpi_pcib_acpi.c (working copy) @@ -91,12 +91,12 @@ int *irq); static struct resource *acpi_pcib_acpi_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags); #ifdef NEW_PCIB static int acpi_pcib_acpi_adjust_resource(device_t dev, device_t child, int type, struct resource *r, - u_long start, u_long end); + uintmax_t start, uintmax_t end); #ifdef PCI_RES_BUS static int acpi_pcib_acpi_release_resource(device_t dev, device_t child, int type, int rid, @@ -283,7 +283,7 @@ #if defined(NEW_PCIB) && defined(PCI_RES_BUS) static int -first_decoded_bus(struct acpi_hpcib_softc *sc, u_long *startp) +first_decoded_bus(struct acpi_hpcib_softc *sc, uintmax_t *startp) { struct resource_list_entry *rle; @@ -304,7 +304,7 @@ u_int slot, func, busok; #if defined(NEW_PCIB) && defined(PCI_RES_BUS) struct resource *bus_res; - u_long start; + uintmax_t start; int rid; #endif uint8_t busno; @@ -584,7 +584,7 @@ struct resource * acpi_pcib_acpi_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { #ifdef NEW_PCIB struct acpi_hpcib_softc *sc; @@ -625,7 +625,7 @@ #ifdef NEW_PCIB int acpi_pcib_acpi_adjust_resource(device_t dev, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct acpi_hpcib_softc *sc; Index: sys/dev/acpica/acpi_resource.c =================================================================== --- sys/dev/acpica/acpi_resource.c (revision 290622) +++ sys/dev/acpica/acpi_resource.c (working copy) @@ -671,7 +671,7 @@ struct resource_list_entry *bus_rle, *dev_rle; struct resource_list *bus_rl, *dev_rl; int done, type; - u_long start, end, count; + uintmax_t start, end, count; /* * Loop through all current resources to see if the new one overlaps Index: sys/dev/acpica/acpi_timer.c =================================================================== --- sys/dev/acpica/acpi_timer.c (revision 290622) +++ sys/dev/acpica/acpi_timer.c (working copy) @@ -122,7 +122,7 @@ acpi_timer_identify(driver_t *driver, device_t parent) { device_t dev; - u_long rlen, rstart; + uintmax_t rlen, rstart; int rid, rtype; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -152,7 +152,7 @@ rlen = AcpiGbl_FADT.PmTimerLength; rstart = AcpiGbl_FADT.XPmTimerBlock.Address; if (bus_set_resource(dev, rtype, rid, rstart, rlen)) - device_printf(dev, "couldn't set resource (%s 0x%lx+0x%lx)\n", + device_printf(dev, "couldn't set resource (%s 0x%jx+0x%jx)\n", (rtype == SYS_RES_IOPORT) ? "port" : "mem", rstart, rlen); return_VOID; } Index: sys/dev/acpica/acpivar.h =================================================================== --- sys/dev/acpica/acpivar.h (revision 290622) +++ sys/dev/acpica/acpivar.h (working copy) @@ -383,7 +383,8 @@ ACPI_STATUS acpi_parse_resources(device_t dev, ACPI_HANDLE handle, struct acpi_parse_resource_set *set, void *arg); struct resource *acpi_alloc_sysres(device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags); + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags); /* ACPI event handling */ UINT32 acpi_event_power_button_sleep(void *context); Index: sys/dev/advansys/adv_isa.c =================================================================== --- sys/dev/advansys/adv_isa.c (revision 290622) +++ sys/dev/advansys/adv_isa.c (working copy) @@ -109,7 +109,7 @@ { int port_index; int max_port_index; - u_long iobase, iocount, irq; + uintmax_t iobase, iocount, irq; int user_iobase = 0; int rid = 0; void *ih; @@ -136,7 +136,7 @@ || (iobase != adv_isa_ioports[port_index])) { if (bootverbose) device_printf(dev, - "Invalid baseport of 0x%lx specified. " + "Invalid baseport of 0x%jx specified. " "Nearest valid baseport is 0x%x. Failing " "probe.\n", iobase, (port_index <= max_port_index) ? Index: sys/dev/aha/aha_isa.c =================================================================== --- sys/dev/aha/aha_isa.c (revision 290622) +++ sys/dev/aha/aha_isa.c (working copy) @@ -121,7 +121,7 @@ port_rid = 0; aha->port = bus_alloc_resource(dev, SYS_RES_IOPORT, &port_rid, - 0ul, ~0ul, AHA_NREGS, RF_ACTIVE); + 0, ~0, AHA_NREGS, RF_ACTIVE); if (aha->port == NULL) return (ENXIO); @@ -192,7 +192,7 @@ aha->dev = dev; aha->portrid = 0; aha->port = bus_alloc_resource(dev, SYS_RES_IOPORT, &aha->portrid, - 0ul, ~0ul, AHA_NREGS, RF_ACTIVE); + 0, ~0, AHA_NREGS, RF_ACTIVE); if (!aha->port) { device_printf(dev, "Unable to allocate I/O ports\n"); goto fail; Index: sys/dev/ahci/ahci.c =================================================================== --- sys/dev/ahci/ahci.c (revision 290622) +++ sys/dev/ahci/ahci.c (working copy) @@ -520,7 +520,7 @@ struct resource * ahci_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ahci_controller *ctlr = device_get_softc(dev); struct resource *res; Index: sys/dev/ahci/ahci.h =================================================================== --- sys/dev/ahci/ahci.h (revision 290622) +++ sys/dev/ahci/ahci.h (working copy) @@ -612,7 +612,7 @@ int ahci_setup_interrupt(device_t dev); int ahci_print_child(device_t dev, device_t child); struct resource *ahci_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags); + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags); int ahci_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); int ahci_setup_intr(device_t dev, device_t child, struct resource *irq, Index: sys/dev/aic/aic_isa.c =================================================================== --- sys/dev/aic/aic_isa.c (revision 290622) +++ sys/dev/aic/aic_isa.c (working copy) @@ -76,7 +76,7 @@ rid = 0; sc->sc_port = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, AIC_ISA_PORTSIZE, RF_ACTIVE); + 0, ~0, AIC_ISA_PORTSIZE, RF_ACTIVE); if (!sc->sc_port) { device_printf(dev, "I/O port allocation failed\n"); return (ENOMEM); Index: sys/dev/aic/aic_pccard.c =================================================================== --- sys/dev/aic/aic_pccard.c (revision 290622) +++ sys/dev/aic/aic_pccard.c (working copy) @@ -78,7 +78,7 @@ rid = 0; sc->sc_port = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, AIC_PCCARD_PORTSIZE, RF_ACTIVE); + 0, ~0, AIC_PCCARD_PORTSIZE, RF_ACTIVE); if (!sc->sc_port) return (ENOMEM); Index: sys/dev/amdsbwd/amdsbwd.c =================================================================== --- sys/dev/amdsbwd/amdsbwd.c (revision 290622) +++ sys/dev/amdsbwd/amdsbwd.c (working copy) @@ -395,7 +395,7 @@ return (ENXIO); } rid = 0; - res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0ul, ~0ul, + res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, AMDSB_PMIO_WIDTH, RF_ACTIVE | RF_SHAREABLE); if (res == NULL) { device_printf(dev, "bus_alloc_resource for IO failed\n"); Index: sys/dev/an/if_an.c =================================================================== --- sys/dev/an/if_an.c (revision 290622) +++ sys/dev/an/if_an.c (working copy) @@ -395,7 +395,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, size, RF_ACTIVE); + 0, ~0, size, RF_ACTIVE); if (res) { sc->port_rid = rid; sc->port_res = res; @@ -414,7 +414,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, - 0ul, ~0ul, size, RF_ACTIVE); + 0, ~0, size, RF_ACTIVE); if (res) { sc->mem_rid = rid; sc->mem_res = res; @@ -434,7 +434,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, - 0ul, ~0ul, size, RF_ACTIVE); + 0, ~0, size, RF_ACTIVE); if (res) { sc->mem_aux_rid = rid; sc->mem_aux_res = res; Index: sys/dev/arcmsr/arcmsr.c =================================================================== --- sys/dev/arcmsr/arcmsr.c (revision 290622) +++ sys/dev/arcmsr/arcmsr.c (working copy) @@ -4115,7 +4115,7 @@ u_int32_t rid0 = PCIR_BAR(0); vm_offset_t mem_base0; - acb->sys_res_arcmsr[0] = bus_alloc_resource(dev,SYS_RES_MEMORY, &rid0, 0ul, ~0ul, 0x1000, RF_ACTIVE); + acb->sys_res_arcmsr[0] = bus_alloc_resource(dev,SYS_RES_MEMORY, &rid0, 0, ~0, 0x1000, RF_ACTIVE); if(acb->sys_res_arcmsr[0] == NULL) { arcmsr_free_resource(acb); printf("arcmsr%d: bus_alloc_resource failure!\n", device_get_unit(dev)); @@ -4145,10 +4145,10 @@ for(i=0; i < 2; i++) { if(i == 0) { acb->sys_res_arcmsr[i] = bus_alloc_resource(dev,SYS_RES_MEMORY, &rid[i], - 0ul, ~0ul, sizeof(struct HBB_DOORBELL), RF_ACTIVE); + 0, ~0, sizeof(struct HBB_DOORBELL), RF_ACTIVE); } else { acb->sys_res_arcmsr[i] = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid[i], - 0ul, ~0ul, sizeof(struct HBB_RWBUFFER), RF_ACTIVE); + 0, ~0, sizeof(struct HBB_RWBUFFER), RF_ACTIVE); } if(acb->sys_res_arcmsr[i] == NULL) { arcmsr_free_resource(acb); @@ -4180,7 +4180,7 @@ u_int32_t rid0 = PCIR_BAR(1); vm_offset_t mem_base0; - acb->sys_res_arcmsr[0] = bus_alloc_resource(dev,SYS_RES_MEMORY, &rid0, 0ul, ~0ul, sizeof(struct HBC_MessageUnit), RF_ACTIVE); + acb->sys_res_arcmsr[0] = bus_alloc_resource(dev,SYS_RES_MEMORY, &rid0, 0, ~0, sizeof(struct HBC_MessageUnit), RF_ACTIVE); if(acb->sys_res_arcmsr[0] == NULL) { arcmsr_free_resource(acb); printf("arcmsr%d: bus_alloc_resource failure!\n", device_get_unit(dev)); @@ -4207,7 +4207,7 @@ u_int32_t rid0 = PCIR_BAR(0); vm_offset_t mem_base0; - acb->sys_res_arcmsr[0] = bus_alloc_resource(dev,SYS_RES_MEMORY, &rid0, 0ul, ~0ul, sizeof(struct HBD_MessageUnit), RF_ACTIVE); + acb->sys_res_arcmsr[0] = bus_alloc_resource(dev,SYS_RES_MEMORY, &rid0, 0, ~0, sizeof(struct HBD_MessageUnit), RF_ACTIVE); if(acb->sys_res_arcmsr[0] == NULL) { arcmsr_free_resource(acb); printf("arcmsr%d: bus_alloc_resource failure!\n", device_get_unit(dev)); @@ -4279,7 +4279,7 @@ } /* After setting up the adapter, map our interrupt */ rid = 0; - irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0ul, ~0ul, 1, RF_SHAREABLE | RF_ACTIVE); + irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE); if(irqres == NULL || #if __FreeBSD_version >= 700025 bus_setup_intr(dev, irqres, INTR_TYPE_CAM|INTR_ENTROPY|INTR_MPSAFE, NULL, arcmsr_intr_handler, acb, &acb->ih)) { Index: sys/dev/ata/ata-cbus.c =================================================================== --- sys/dev/ata/ata-cbus.c (revision 290622) +++ sys/dev/ata/ata-cbus.c (working copy) @@ -67,7 +67,7 @@ { struct resource *io; int rid; - u_long tmp; + uintmax_t tmp; /* dont probe PnP devices */ if (isa_get_vendorid(dev)) @@ -168,7 +168,8 @@ static struct resource * ata_cbus_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct ata_cbus_controller *ctlr = device_get_softc(dev); Index: sys/dev/ata/ata-isa.c =================================================================== --- sys/dev/ata/ata-isa.c (revision 290622) +++ sys/dev/ata/ata-isa.c (working copy) @@ -60,7 +60,8 @@ ata_isa_probe(device_t dev) { struct resource *io = NULL, *ctlio = NULL; - u_long tmp; + uintmax_t tmp; + uintmax_t tcount; int rid; /* check isapnp ids */ @@ -74,7 +75,7 @@ return ENXIO; /* set the altport range */ - if (bus_get_resource(dev, SYS_RES_IOPORT, ATA_CTLADDR_RID, &tmp, &tmp)) { + if (bus_get_resource(dev, SYS_RES_IOPORT, ATA_CTLADDR_RID, &tmp, &tcount)) { bus_set_resource(dev, SYS_RES_IOPORT, ATA_CTLADDR_RID, rman_get_start(io) + ATA_CTLOFFSET, ATA_CTLIOSIZE); } @@ -81,7 +82,7 @@ /* allocate the altport range */ rid = ATA_CTLADDR_RID; - if (!(ctlio = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, + if (!(ctlio = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, RM_MAX_END, ATA_CTLIOSIZE, RF_ACTIVE))) { bus_release_resource(dev, SYS_RES_IOPORT, ATA_IOADDR_RID, io); return ENXIO; @@ -100,7 +101,8 @@ { struct ata_channel *ch = device_get_softc(dev); struct resource *io = NULL, *ctlio = NULL; - u_long tmp; + uintmax_t tmp; + uintmax_t tcount; int i, rid; if (ch->attached) @@ -114,7 +116,7 @@ return ENXIO; /* set the altport range */ - if (bus_get_resource(dev, SYS_RES_IOPORT, ATA_CTLADDR_RID, &tmp, &tmp)) { + if (bus_get_resource(dev, SYS_RES_IOPORT, ATA_CTLADDR_RID, &tmp, &tcount)) { bus_set_resource(dev, SYS_RES_IOPORT, ATA_CTLADDR_RID, rman_get_start(io) + ATA_CTLOFFSET, ATA_CTLIOSIZE); } Index: sys/dev/ata/ata-pci.c =================================================================== --- sys/dev/ata/ata-pci.c (revision 290622) +++ sys/dev/ata/ata-pci.c (working copy) @@ -217,7 +217,8 @@ struct resource * ata_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct ata_pci_controller *controller = device_get_softc(dev); struct resource *res = NULL; Index: sys/dev/ata/ata-pci.h =================================================================== --- sys/dev/ata/ata-pci.h (revision 290622) +++ sys/dev/ata/ata-pci.h (working copy) @@ -535,7 +535,7 @@ int ata_pci_print_child(device_t dev, device_t child); int ata_pci_child_location_str(device_t dev, device_t child, char *buf, size_t buflen); -struct resource * ata_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags); +struct resource * ata_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags); int ata_pci_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); int ata_pci_setup_intr(device_t dev, device_t child, struct resource *irq, int flags, driver_filter_t *filter, driver_intr_t *function, void *argument, void **cookiep); int ata_pci_teardown_intr(device_t dev, device_t child, struct resource *irq, void *cookie); Index: sys/dev/ata/chipsets/ata-promise.c =================================================================== --- sys/dev/ata/chipsets/ata-promise.c (revision 290622) +++ sys/dev/ata/chipsets/ata-promise.c (working copy) @@ -191,18 +191,19 @@ !BUS_READ_IVAR(device_get_parent(GRANDPARENT(dev)), GRANDPARENT(dev), PCI_IVAR_DEVID, &devid) && ((devid == ATA_DEC_21150) || (devid == ATA_DEC_21150_1))) { - static long start = 0, end = 0; + static uintmax_t start = 0; + static uintmax_t count = 0; if (pci_get_slot(dev) == 1) { - bus_get_resource(dev, SYS_RES_IRQ, 0, &start, &end); + bus_get_resource(dev, SYS_RES_IRQ, 0, &start, &count); strcat(buffer, " (channel 0+1)"); } - else if (pci_get_slot(dev) == 2 && start && end) { - bus_set_resource(dev, SYS_RES_IRQ, 0, start, end); + else if (pci_get_slot(dev) == 2 && start && count) { + bus_set_resource(dev, SYS_RES_IRQ, 0, start, count); strcat(buffer, " (channel 2+3)"); } else { - start = end = 0; + start = count = 0; } } sprintf(buffer, "%s %s controller", buffer, ata_mode2str(idx->max_dma)); Index: sys/dev/atkbdc/atkbdc_ebus.c =================================================================== --- sys/dev/atkbdc/atkbdc_ebus.c (revision 290622) +++ sys/dev/atkbdc/atkbdc_ebus.c (working copy) @@ -91,7 +91,7 @@ atkbdc_ebus_probe(device_t dev) { struct resource *port0, *port1; - u_long count, start; + uintmax_t count, start; int error, rid; if (strcmp(ofw_bus_get_name(dev), "8042") != 0) @@ -176,7 +176,7 @@ atkbdc_device_t *adi; device_t cdev; phandle_t child; - u_long count, intr, start; + uintmax_t count, intr, start; int children, error, rid, unit; char *cname, *dname; Index: sys/dev/atkbdc/atkbdc_isa.c =================================================================== --- sys/dev/atkbdc/atkbdc_isa.c (revision 290622) +++ sys/dev/atkbdc/atkbdc_isa.c (working copy) @@ -50,8 +50,8 @@ static device_t atkbdc_isa_add_child(device_t bus, u_int order, const char *name, int unit); static struct resource *atkbdc_isa_alloc_resource(device_t dev, device_t child, - int type, int *rid, u_long start, u_long end, - u_long count, u_int flags); + int type, int *rid, uintmax_t start, uintmax_t end, + uintmax_t count, u_int flags); static int atkbdc_isa_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); @@ -97,8 +97,8 @@ { struct resource *port0; struct resource *port1; - u_long start; - u_long count; + uintmax_t start; + uintmax_t count; int error; int rid; #if defined(__i386__) || defined(__amd64__) @@ -295,7 +295,7 @@ struct resource * atkbdc_isa_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { atkbdc_softc_t *sc; Index: sys/dev/atkbdc/atkbdc_subr.c =================================================================== --- sys/dev/atkbdc/atkbdc_subr.c (revision 290622) +++ sys/dev/atkbdc/atkbdc_subr.c (working copy) @@ -51,7 +51,7 @@ atkbdc_print_child(device_t bus, device_t dev) { atkbdc_device_t *kbdcdev; - u_long irq; + uintmax_t irq; int flags; int retval = 0; @@ -63,7 +63,7 @@ retval += printf(" flags 0x%x", flags); irq = bus_get_resource_start(dev, SYS_RES_IRQ, kbdcdev->rid); if (irq != 0) - retval += printf(" irq %ld", irq); + retval += printf(" irq %jd", irq); retval += bus_print_child_footer(bus, dev); return (retval); Index: sys/dev/bxe/bxe.c =================================================================== --- sys/dev/bxe/bxe.c (revision 290622) +++ sys/dev/bxe/bxe.c (working copy) @@ -13389,7 +13389,7 @@ sc->bar[i].handle = rman_get_bushandle(sc->bar[i].resource); sc->bar[i].kva = (vm_offset_t)rman_get_virtual(sc->bar[i].resource); - BLOGI(sc, "PCI BAR%d [%02x] memory allocated: %p-%p (%ld) -> %p\n", + BLOGI(sc, "PCI BAR%d [%02x] memory allocated: %p-%p (%jd) -> %p\n", i, PCIR_BAR(i), (void *)rman_get_start(sc->bar[i].resource), (void *)rman_get_end(sc->bar[i].resource), Index: sys/dev/cardbus/cardbus_cis.c =================================================================== --- sys/dev/cardbus/cardbus_cis.c (revision 290622) +++ sys/dev/cardbus/cardbus_cis.c (working copy) @@ -59,7 +59,7 @@ #define DPRINTF(a) if (cardbus_cis_debug) printf a #define DEVPRINTF(x) if (cardbus_cis_debug) device_printf x -#define CIS_CONFIG_SPACE (struct resource *)~0UL +#define CIS_CONFIG_SPACE (struct resource *)~0 static int decode_tuple_generic(device_t cbdev, device_t child, int id, int len, uint8_t *tupledata, uint32_t start, uint32_t *off, @@ -485,7 +485,8 @@ "to read CIS.\n"); return (NULL); } - DEVPRINTF((cbdev, "CIS Mapped to %#lx\n", rman_get_start(res))); + DEVPRINTF((cbdev, "CIS Mapped to %#jx\n", + rman_get_start(res))); /* Flip to the right ROM image if CIS is in ROM */ if (space == PCIM_CIS_ASI_ROM) { Index: sys/dev/cm/if_cm_isa.c =================================================================== --- sys/dev/cm/if_cm_isa.c (revision 290622) +++ sys/dev/cm/if_cm_isa.c (working copy) @@ -64,7 +64,7 @@ rid = 0; sc->port_res = bus_alloc_resource( - dev, SYS_RES_IOPORT, &rid, 0ul, ~0ul, CM_IO_PORTS, RF_ACTIVE); + dev, SYS_RES_IOPORT, &rid, 0, ~0, CM_IO_PORTS, RF_ACTIVE); if (sc->port_res == NULL) return (ENOENT); @@ -75,7 +75,7 @@ rid = 0; sc->mem_res = bus_alloc_resource( - dev, SYS_RES_MEMORY, &rid, 0ul, ~0ul, CM_MEM_SIZE, RF_ACTIVE); + dev, SYS_RES_MEMORY, &rid, 0, ~0, CM_MEM_SIZE, RF_ACTIVE); if (sc->mem_res == NULL) { cm_release_resources(dev); return (ENOENT); Index: sys/dev/cs/if_cs.c =================================================================== --- sys/dev/cs/if_cs.c (revision 290622) +++ sys/dev/cs/if_cs.c (working copy) @@ -258,7 +258,7 @@ { int i; int error; - u_long irq, junk; + uintmax_t irq, junk; struct cs_softc *sc = device_get_softc(dev); unsigned rev_type = 0; uint16_t id; @@ -407,7 +407,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, size, RF_ACTIVE); + 0, ~0, size, RF_ACTIVE); if (res == NULL) return (ENOENT); sc->port_rid = rid; Index: sys/dev/ct/ct_isa.c =================================================================== --- sys/dev/ct/ct_isa.c (revision 290622) +++ sys/dev/ct/ct_isa.c (working copy) @@ -318,7 +318,7 @@ *memhp = NULL; port_rid = 0; - *iohp = bus_alloc_resource(dev, SYS_RES_IOPORT, &port_rid, 0ul, ~0ul, + *iohp = bus_alloc_resource(dev, SYS_RES_IOPORT, &port_rid, 0, ~0, BSHW_IOSZ, RF_ACTIVE); if (*iohp == NULL) return ENXIO; @@ -327,7 +327,7 @@ return 0; mem_rid = 0; - *memhp = bus_alloc_resource(dev, SYS_RES_MEMORY, &mem_rid, 0ul, ~0ul, + *memhp = bus_alloc_resource(dev, SYS_RES_MEMORY, &mem_rid, 0, ~0, BSHW_MEMSZ, RF_ACTIVE); if (*memhp == NULL) { bus_release_resource(dev, SYS_RES_IOPORT, port_rid, *iohp); Index: sys/dev/ctau/if_ct.c =================================================================== --- sys/dev/ctau/if_ct.c (revision 290622) +++ sys/dev/ctau/if_ct.c (working copy) @@ -317,8 +317,8 @@ static char dmatab [] = { 7, 6, 5, 0 }; static char irqtab [] = { 5, 10, 11, 7, 3, 15, 12, 0 }; -static int ct_is_free_res (device_t dev, int rid, int type, u_long start, - u_long end, u_long count) +static int ct_is_free_res (device_t dev, int rid, int type, uintmax_t start, + uintmax_t end, uintmax_t count) { struct resource *res; @@ -332,7 +332,7 @@ static void ct_identify (driver_t *driver, device_t dev) { - u_long iobase, rescount; + uintmax_t iobase, rescount; int devcount; device_t *devices; device_t child; @@ -440,7 +440,7 @@ static int ct_probe (device_t dev) { int unit = device_get_unit (dev); - u_long iobase, rescount; + uintmax_t iobase, rescount; if (!device_get_desc (dev) || strcmp (device_get_desc (dev), "Cronyx Tau-ISA")) @@ -459,7 +459,7 @@ } if (!ct_probe_board (iobase, -1, -1)) { - printf ("ct%d: probing for Tau-ISA at %lx faild\n", unit, iobase); + printf ("ct%d: probing for Tau-ISA at %jx faild\n", unit, iobase); return ENXIO; } @@ -529,7 +529,7 @@ static int ct_attach (device_t dev) { bdrv_t *bd = device_get_softc (dev); - u_long iobase, drq, irq, rescount; + uintmax_t iobase, drq, irq, rescount; int unit = device_get_unit (dev); char *ct_ln = CT_LOCK_NAME; ct_board_t *b; @@ -632,7 +632,7 @@ ct_ln[2] = '0' + unit; mtx_init (&bd->ct_mtx, ct_ln, MTX_NETWORK_LOCK, MTX_DEF|MTX_RECURSE); if (! probe_irq (b, irq)) { - printf ("ct%d: irq %ld not functional\n", unit, irq); + printf ("ct%d: irq %jd not functional\n", unit, irq); bd->board = 0; adapter [unit] = 0; free (b, M_DEVBUF); @@ -651,7 +651,7 @@ if (bus_setup_intr (dev, bd->irq_res, INTR_TYPE_NET|INTR_MPSAFE, NULL, ct_intr, bd, &bd->intrhand)) { - printf ("ct%d: Can't setup irq %ld\n", unit, irq); + printf ("ct%d: Can't setup irq %jd\n", unit, irq); bd->board = 0; adapter [unit] = 0; free (b, M_DEVBUF); Index: sys/dev/cx/if_cx.c =================================================================== --- sys/dev/cx/if_cx.c (revision 290622) +++ sys/dev/cx/if_cx.c (working copy) @@ -405,8 +405,8 @@ static char dmatab [] = { 7, 6, 5, 0 }; static char irqtab [] = { 5, 10, 11, 7, 3, 15, 12, 0 }; -static int cx_is_free_res (device_t dev, int rid, int type, u_long start, - u_long end, u_long count) +static int cx_is_free_res (device_t dev, int rid, int type, uintmax_t start, + uintmax_t end, uintmax_t count) { struct resource *res; @@ -420,7 +420,7 @@ static void cx_identify (driver_t *driver, device_t dev) { - u_long iobase, rescount; + uintmax_t iobase, rescount; int devcount; device_t *devices; device_t child; @@ -530,7 +530,7 @@ { int unit = device_get_unit (dev); int i; - u_long iobase, rescount; + uintmax_t iobase, rescount; if (!device_get_desc (dev) || strcmp (device_get_desc (dev), "Cronyx Sigma")) @@ -629,7 +629,7 @@ static int cx_attach (device_t dev) { bdrv_t *bd = device_get_softc (dev); - u_long iobase, drq, irq, rescount; + uintmax_t iobase, drq, irq, rescount; int unit = device_get_unit (dev); char *cx_ln = CX_LOCK_NAME; cx_board_t *b; Index: sys/dev/cy/cy_isa.c =================================================================== --- sys/dev/cy/cy_isa.c (revision 290622) +++ sys/dev/cy/cy_isa.c (working copy) @@ -81,7 +81,7 @@ mem_rid = 0; mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &mem_rid, - 0ul, ~0ul, 0ul, RF_ACTIVE); + 0, ~0, 0, RF_ACTIVE); if (mem_res == NULL) { device_printf(dev, "ioport resource allocation failed\n"); return (ENXIO); @@ -113,7 +113,7 @@ mem_rid = 0; mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &mem_rid, - 0ul, ~0ul, 0ul, RF_ACTIVE); + 0, ~0, 0, RF_ACTIVE); if (mem_res == NULL) { device_printf(dev, "memory resource allocation failed\n"); goto fail; @@ -127,7 +127,7 @@ } irq_rid = 0; - irq_res = bus_alloc_resource(dev, SYS_RES_IRQ, &irq_rid, 0ul, ~0ul, 0ul, + irq_res = bus_alloc_resource(dev, SYS_RES_IRQ, &irq_rid, 0, ~0, 0, RF_SHAREABLE | RF_ACTIVE); if (irq_res == NULL) { device_printf(dev, "interrupt resource allocation failed\n"); Index: sys/dev/cy/cy_pci.c =================================================================== --- sys/dev/cy/cy_pci.c (revision 290622) +++ sys/dev/cy/cy_pci.c (working copy) @@ -115,7 +115,7 @@ ioport_rid = CY_PCI_BASE_ADDR1; ioport_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &ioport_rid, - 0ul, ~0ul, 0ul, RF_ACTIVE); + 0, ~0, 0, RF_ACTIVE); if (ioport_res == NULL) { device_printf(dev, "ioport resource allocation failed\n"); goto fail; @@ -124,7 +124,7 @@ mem_rid = CY_PCI_BASE_ADDR2; mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &mem_rid, - 0ul, ~0ul, 0ul, RF_ACTIVE); + 0, ~0, 0, RF_ACTIVE); if (mem_res == NULL) { device_printf(dev, "memory resource allocation failed\n"); goto fail; @@ -138,7 +138,7 @@ } irq_rid = 0; - irq_res = bus_alloc_resource(dev, SYS_RES_IRQ, &irq_rid, 0ul, ~0ul, 0ul, + irq_res = bus_alloc_resource(dev, SYS_RES_IRQ, &irq_rid, 0, ~0, 0, RF_SHAREABLE | RF_ACTIVE); if (irq_res == NULL) { device_printf(dev, "interrupt resource allocation failed\n"); Index: sys/dev/digi/digi_isa.c =================================================================== --- sys/dev/digi/digi_isa.c (revision 290622) +++ sys/dev/digi/digi_isa.c (working copy) @@ -278,7 +278,7 @@ /* Temporarily map our io ports */ sc->res.iorid = 0; sc->res.io = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->res.iorid, - 0ul, ~0ul, IO_SIZE, RF_ACTIVE); + 0, ~0, IO_SIZE, RF_ACTIVE); if (sc->res.io == NULL) return (ENXIO); @@ -292,7 +292,7 @@ /* Temporarily map our memory */ sc->res.mrid = 0; sc->res.mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->res.mrid, - 0ul, ~0ul, sc->win_size, 0); + 0, ~0, sc->win_size, 0); if (sc->res.mem == NULL) { device_printf(dev, "0x%lx: Memory range is in use\n", sc->pmem); bus_release_resource(dev, SYS_RES_IOPORT, sc->res.iorid, @@ -343,7 +343,7 @@ /* Allocate resources (verified in digi_isa_probe()) */ sc->res.iorid = 0; sc->res.io = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->res.iorid, - 0ul, ~0ul, iosize, RF_ACTIVE); + 0, ~0, iosize, RF_ACTIVE); if (sc->res.io == NULL) return (ENXIO); @@ -357,7 +357,7 @@ sc->res.mrid = 0; sc->res.mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->res.mrid, - 0ul, ~0ul, msize, RF_ACTIVE); + 0, ~0, msize, RF_ACTIVE); if (sc->res.mem == NULL) { device_printf(dev, "0x%lx: Memory range is in use\n", sc->pmem); sc->hidewin(sc); Index: sys/dev/drm2/i915/i915_dma.c =================================================================== --- sys/dev/drm2/i915/i915_dma.c (revision 290622) +++ sys/dev/drm2/i915/i915_dma.c (working copy) @@ -1142,7 +1142,7 @@ vga = device_get_parent(dev->dev); dev_priv->mch_res_rid = 0x100; dev_priv->mch_res = BUS_ALLOC_RESOURCE(device_get_parent(vga), - dev->dev, SYS_RES_MEMORY, &dev_priv->mch_res_rid, 0, ~0UL, + dev->dev, SYS_RES_MEMORY, &dev_priv->mch_res_rid, 0, ~0, MCHBAR_SIZE, RF_ACTIVE | RF_SHAREABLE); if (dev_priv->mch_res == NULL) { DRM_DEBUG_DRIVER("failed bus alloc\n"); Index: sys/dev/ed/if_ed.c =================================================================== --- sys/dev/ed/if_ed.c (revision 290622) +++ sys/dev/ed/if_ed.c (working copy) @@ -164,7 +164,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, size, RF_ACTIVE); + 0, ~0, size, RF_ACTIVE); if (res) { sc->port_res = res; sc->port_used = size; @@ -185,7 +185,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, - 0ul, ~0ul, size, RF_ACTIVE); + 0, ~0, size, RF_ACTIVE); if (res) { sc->mem_res = res; sc->mem_used = size; Index: sys/dev/ed/if_ed_3c503.c =================================================================== --- sys/dev/ed/if_ed_3c503.c (revision 290622) +++ sys/dev/ed/if_ed_3c503.c (working copy) @@ -74,7 +74,7 @@ int i; u_int memsize; u_char isa16bit; - u_long conf_maddr, conf_msize, irq, junk, pmem; + uintmax_t conf_maddr, conf_msize, irq, junk, pmem; error = ed_alloc_port(dev, 0, ED_3COM_IO_PORTS); if (error) @@ -324,7 +324,7 @@ ed_asic_outb(sc, ED_3COM_IDCFR, ED_3COM_IDCFR_IRQ5); break; default: - device_printf(dev, "Invalid irq configuration (%ld) must be 3-5,9 for 3c503\n", + device_printf(dev, "Invalid irq configuration (%jd) must be 3-5,9 for 3c503\n", irq); return (ENXIO); } Index: sys/dev/ed/if_ed_cbus.c =================================================================== --- sys/dev/ed/if_ed_cbus.c (revision 290622) +++ sys/dev/ed/if_ed_cbus.c (working copy) @@ -607,7 +607,7 @@ { struct ed_softc *sc = device_get_softc(dev); int error; - u_long conf_maddr, conf_msize; + uintmax_t conf_maddr, conf_msize; error = bus_get_resource(dev, SYS_RES_MEMORY, 0, &conf_maddr, &conf_msize); @@ -1001,7 +1001,7 @@ struct ed_softc *sc = device_get_softc(dev); int error; u_char tmp; - u_long conf_irq, junk; + uintmax_t conf_irq, junk; #ifdef DIAGNOSTIC u_char tmp_s; #endif @@ -1021,7 +1021,7 @@ if (((rman_get_start(sc->port_res) & 0x0fff) != 0x03d0) || ((rman_get_start(sc->port_res) & 0xf000) < (u_short) 0xa000)) { #ifdef DIAGNOSTIC - device_printf(dev, "Invalid i/o port configuration (0x%lx) " + device_printf(dev, "Invalid i/o port configuration (0x%jx) " "must be %s for %s\n", rman_get_start(sc->port_res), "0x[a-f]3d0", "CNET98"); #endif @@ -1032,7 +1032,7 @@ /* Check window area address */ tmp_s = rman_get_start(sc->mem_res) >> 12; if (tmp_s < 0x80) { - device_printf(dev, "Please change window address(0x%lx)\n", + device_printf(dev, "Please change window address(0x%jx)\n", rman_get_start(sc->mem_res)); return (ENXIO); } @@ -1040,8 +1040,8 @@ tmp_s &= 0x0f; tmp = rman_get_start(sc->port_res) >> 12; if ((tmp_s <= tmp) && (tmp < (tmp_s + 4))) { - device_printf(dev, "Please change iobase address(0x%lx) " - "or window address(0x%lx)\n", + device_printf(dev, "Please change iobase address(0x%jx) " + "or window address(0x%jx)\n", rman_get_start(sc->port_res), rman_get_start(sc->mem_res)); return (ENXIO); @@ -1128,7 +1128,7 @@ tmp = ED_CNET98_INT_IRQ13; break; default: - device_printf(dev, "Invalid irq configuration (%ld) must be " + device_printf(dev, "Invalid irq configuration (%jd) must be " "%s for %s\n", conf_irq, "3,5,6,9,12,13", "CNET98"); return (ENXIO); } @@ -1157,7 +1157,7 @@ int error; int i; u_char romdata[ETHER_ADDR_LEN * 2], tmp; - u_long conf_irq, junk; + uintmax_t conf_irq, junk; error = ed98_alloc_port(dev, port_rid); if (error) @@ -1169,7 +1169,7 @@ /* Check I/O address. 0x[0-f]3d0 are allowed. */ if ((rman_get_start(sc->port_res) & 0x0fff) != 0x03d0) { #ifdef DIAGNOSTIC - device_printf(dev, "Invalid i/o port configuration (0x%lx) " + device_printf(dev, "Invalid i/o port configuration (0x%jx) " "must be %s for %s\n", rman_get_start(sc->port_res), "0x?3d0", "CNET98E/L"); #endif @@ -1223,7 +1223,7 @@ break; #endif default: - device_printf(dev, "Invalid irq configuration (%ld) must be " + device_printf(dev, "Invalid irq configuration (%jd) must be " "%s for %s\n", conf_irq, "3,5,6", "CNET98E/L"); return (ENXIO); } @@ -1251,7 +1251,7 @@ struct ed_softc *sc = device_get_softc(dev); int error; u_char tmp; - u_long conf_irq, junk; + uintmax_t conf_irq, junk; error = ed98_probe_Novell(dev, port_rid, flags); if (error) @@ -1285,7 +1285,7 @@ tmp = ED_NEC77_IRQ13; break; default: - device_printf(dev, "Invalid irq configuration (%ld) must be " + device_printf(dev, "Invalid irq configuration (%jd) must be " "%s for %s\n", conf_irq, "3,5,6,12,13", "PC-9801-77"); return (ENXIO); } @@ -1303,7 +1303,7 @@ struct ed_softc *sc = device_get_softc(dev); int error; u_char tmp; - u_long conf_irq, junk; + uintmax_t conf_irq, junk; error = ed98_probe_Novell(dev, port_rid, flags); if (error) @@ -1337,7 +1337,7 @@ tmp = ED_NW98X_IRQ13; break; default: - device_printf(dev, "Invalid irq configuration (%ld) must be " + device_printf(dev, "Invalid irq configuration (%jd) must be " "%s for %s\n", conf_irq, "3,5,6,12,13", "EC/EP-98X"); return (ENXIO); } @@ -1427,7 +1427,7 @@ struct ed_softc *sc = device_get_softc(dev); int error; u_char tmp; - u_long conf_irq, junk; + uintmax_t conf_irq, junk; error = ed98_alloc_port(dev, port_rid); if (error) @@ -1439,7 +1439,7 @@ /* Check I/O address. 00d[02468ace] are allowed. */ if ((rman_get_start(sc->port_res) & ~0x000e) != 0x00d0) { #ifdef DIAGNOSTIC - device_printf(dev, "Invalid i/o port configuration (0x%lx) " + device_printf(dev, "Invalid i/o port configuration (0x%jx) " "must be %s for %s\n", rman_get_start(sc->port_res), "0xd?", "SB9801"); #endif @@ -1475,7 +1475,7 @@ tmp = ED_SB98_CFG_IRQ12; break; default: - device_printf(dev, "Invalid irq configuration (%ld) must be " + device_printf(dev, "Invalid irq configuration (%jd) must be " "%s for %s\n", conf_irq, "3,5,6,12", "SB9801"); return (ENXIO); } Index: sys/dev/ed/if_ed_hpp.c =================================================================== --- sys/dev/ed/if_ed_hpp.c (revision 290622) +++ sys/dev/ed/if_ed_hpp.c (working copy) @@ -126,7 +126,7 @@ u_char irq; /* board configured IRQ */ uint8_t test_pattern[ED_HPP_TEST_SIZE]; /* read/write areas for */ uint8_t test_buffer[ED_HPP_TEST_SIZE]; /* probing card */ - u_long conf_maddr, conf_msize, conf_irq, junk; + uintmax_t conf_maddr, conf_msize, conf_irq, junk; error = ed_alloc_port(dev, 0, ED_HPP_IO_PORTS); if (error) Index: sys/dev/ed/if_ed_pccard.c =================================================================== --- sys/dev/ed/if_ed_pccard.c (revision 290622) +++ sys/dev/ed/if_ed_pccard.c (working copy) @@ -510,7 +510,7 @@ if (rman_get_size(sc->port_res) == ED_NOVELL_IO_PORTS / 2) { port_rid++; sc->port_res2 = bus_alloc_resource(dev, SYS_RES_IOPORT, - &port_rid, 0ul, ~0ul, 1, RF_ACTIVE); + &port_rid, 0, ~0, 1, RF_ACTIVE); if (sc->port_res2 == NULL || rman_get_size(sc->port_res2) != ED_NOVELL_IO_PORTS / 2) { error = ENXIO; Index: sys/dev/ed/if_ed_wd80x3.c =================================================================== --- sys/dev/ed/if_ed_wd80x3.c (revision 290622) +++ sys/dev/ed/if_ed_wd80x3.c (working copy) @@ -97,7 +97,7 @@ int i; u_int memsize; u_char iptr, isa16bit, sum, totalsum; - u_long irq, junk, pmem; + uintmax_t irq, junk, pmem; sc->chip_type = ED_CHIP_TYPE_DP8390; Index: sys/dev/eisa/eisaconf.c =================================================================== --- sys/dev/eisa/eisaconf.c (revision 290622) +++ sys/dev/eisa/eisaconf.c (working copy) @@ -352,7 +352,7 @@ static struct resource * eisa_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { int isdefault; struct eisa_device *e_dev = device_get_ivars(child); @@ -359,7 +359,7 @@ struct resource *rv, **rvp = 0; isdefault = (device_get_parent(child) == dev && - start == 0UL && end == ~0UL && count == 1); + start == 0 && end == ~0 && count == 1); switch (type) { case SYS_RES_IRQ: Index: sys/dev/fb/s3_pci.c =================================================================== --- sys/dev/fb/s3_pci.c (revision 290622) +++ sys/dev/fb/s3_pci.c (working copy) @@ -479,7 +479,7 @@ */ rid = 0; if (!(sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, 0, RF_ACTIVE | RF_SHAREABLE))) { + 0, ~0, 0, RF_ACTIVE | RF_SHAREABLE))) { printf("%s: port resource allocation failed!\n", __func__); goto error; } @@ -488,7 +488,7 @@ rid = 1; if (!(sc->enh_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, 0, RF_ACTIVE | RF_SHAREABLE))) { + 0, ~0, 0, RF_ACTIVE | RF_SHAREABLE))) { printf("%s: enhanced port resource allocation failed!\n", __func__); goto error; Index: sys/dev/fdc/fdc_isa.c =================================================================== --- sys/dev/fdc/fdc_isa.c (revision 290622) +++ sys/dev/fdc/fdc_isa.c (working copy) @@ -90,7 +90,7 @@ for (rid = 0; ; rid++) { newrid = rid; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &newrid, - 0ul, ~0ul, rid == 0 ? nport : 1, RF_ACTIVE); + 0, ~0, rid == 0 ? nport : 1, RF_ACTIVE); if (res == NULL) break; /* Index: sys/dev/fdc/fdc_pccard.c =================================================================== --- sys/dev/fdc/fdc_pccard.c (revision 290622) +++ sys/dev/fdc/fdc_pccard.c (working copy) @@ -56,7 +56,7 @@ int rid, i; rid = 0; - res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0ul, ~0ul, 1, + res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, 1, RF_ACTIVE); if (res == NULL) { device_printf(dev, "cannot alloc I/O port range\n"); Index: sys/dev/fdt/simplebus.c =================================================================== --- sys/dev/fdt/simplebus.c (revision 290622) +++ sys/dev/fdt/simplebus.c (working copy) @@ -46,7 +46,7 @@ static int simplebus_probe(device_t dev); static int simplebus_attach(device_t dev); static struct resource *simplebus_alloc_resource(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); static void simplebus_probe_nomatch(device_t bus, device_t child); static int simplebus_print_child(device_t bus, device_t child); static device_t simplebus_add_child(device_t dev, u_int order, @@ -318,7 +318,7 @@ static struct resource * simplebus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct simplebus_softc *sc; struct simplebus_devinfo *di; @@ -331,7 +331,7 @@ * Request for the default allocation with a given rid: use resource * list stored in the local device info. */ - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == RM_MAX_END)) { if ((di = device_get_ivars(child)) == NULL) return (NULL); @@ -365,7 +365,7 @@ if (j == sc->nranges && sc->nranges != 0) { if (bootverbose) device_printf(bus, "Could not map resource " - "%#lx-%#lx\n", start, end); + "%#jx-%#jx\n", start, end); return (NULL); } @@ -381,8 +381,8 @@ int rv; rv = 0; - rv += resource_list_print_type(&di->rl, "mem", SYS_RES_MEMORY, "%#lx"); - rv += resource_list_print_type(&di->rl, "irq", SYS_RES_IRQ, "%ld"); + rv += resource_list_print_type(&di->rl, "mem", SYS_RES_MEMORY, "%#jx"); + rv += resource_list_print_type(&di->rl, "irq", SYS_RES_IRQ, "%jd"); return (rv); } Index: sys/dev/fe/if_fe.c =================================================================== --- sys/dev/fe/if_fe.c (revision 290622) +++ sys/dev/fe/if_fe.c (working copy) @@ -881,7 +881,7 @@ rid = 0; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, size, RF_ACTIVE); + 0, ~0, size, RF_ACTIVE); if (res) { sc->port_used = size; sc->port_res = res; Index: sys/dev/fe/if_fe_cbus.c =================================================================== --- sys/dev/fe/if_fe_cbus.c (revision 290622) +++ sys/dev/fe/if_fe_cbus.c (working copy) @@ -298,7 +298,7 @@ { struct fe_softc *sc = device_get_softc(dev); int i, n; - u_long iobase, irq; + uintmax_t iobase, irq; u_char sum; static struct fe_simple_probe_struct probe_table [] = { @@ -398,7 +398,7 @@ { struct fe_softc *sc = device_get_softc(dev); int i, n, xirq, error; - u_long iobase, irq; + uintmax_t iobase, irq; u_char eeprom [JLI_EEPROM_SIZE]; u_short const * irqmap; @@ -524,7 +524,7 @@ fe_probe_cnet9ne (device_t dev) { struct fe_softc *sc = device_get_softc(dev); - u_long iobase, irq; + uintmax_t iobase, irq; static struct fe_simple_probe_struct probe_table [] = { { FE_DLCR2, 0x58, 0x00 }, @@ -598,7 +598,7 @@ fe_probe_ssi(device_t dev) { struct fe_softc *sc = device_get_softc(dev); - u_long iobase, irq; + uintmax_t iobase, irq; u_char eeprom [SSI_EEPROM_SIZE]; static struct fe_simple_probe_struct probe_table [] = { @@ -676,7 +676,7 @@ { struct fe_softc *sc = device_get_softc(dev); - u_long iobase, irq; + uintmax_t iobase, irq; u_char eeprom [LNX_EEPROM_SIZE]; static struct fe_simple_probe_struct probe_table [] = { @@ -804,7 +804,7 @@ struct fe_softc *sc = device_get_softc(dev); u_char sum, save7; - u_long iobase, irq; + uintmax_t iobase, irq; int i; static struct fe_simple_probe_struct const probe_table [] = { { FE_DLCR2, 0x58, 0x00 }, @@ -949,7 +949,7 @@ struct fe_softc *sc = device_get_softc(dev); int i; - u_long iobase, irq; + uintmax_t iobase, irq; u_char eeprom [REX_EEPROM_SIZE]; static struct fe_simple_probe_struct probe_table [] = { Index: sys/dev/fe/if_fe_isa.c =================================================================== --- sys/dev/fe/if_fe_isa.c (revision 290622) +++ sys/dev/fe/if_fe_isa.c (working copy) @@ -203,7 +203,7 @@ { struct fe_softc *sc = device_get_softc(dev); int n; - u_long iobase, irq; + uintmax_t iobase, irq; static u_short const irqmap [ 4 ] = { 3, 7, 10, 15 }; @@ -698,7 +698,7 @@ { struct fe_softc *sc = device_get_softc(dev); int i, n, error, xirq; - u_long iobase, irq; + uintmax_t iobase, irq; u_char eeprom [JLI_EEPROM_SIZE]; u_short const * irqmap; @@ -816,7 +816,7 @@ fe_probe_ssi(device_t dev) { struct fe_softc *sc = device_get_softc(dev); - u_long iobase, irq; + uintmax_t iobase, irq; u_char eeprom [SSI_EEPROM_SIZE]; static struct fe_simple_probe_struct probe_table [] = { @@ -878,7 +878,7 @@ fe_probe_lnx(device_t dev) { struct fe_softc *sc = device_get_softc(dev); - u_long iobase, irq; + uintmax_t iobase, irq; u_char eeprom [LNX_EEPROM_SIZE]; static struct fe_simple_probe_struct probe_table [] = { @@ -946,7 +946,7 @@ fe_probe_gwy(device_t dev) { struct fe_softc *sc = device_get_softc(dev); - u_long iobase, irq; + uintmax_t iobase, irq; static struct fe_simple_probe_struct probe_table [] = { /* { FE_DLCR2, 0x70, 0x00 }, */ @@ -999,7 +999,7 @@ fe_probe_ubn(device_t dev) { struct fe_softc *sc = device_get_softc(dev); - u_long iobase, irq; + uintmax_t iobase, irq; #if 0 u_char sum; #endif Index: sys/dev/gpio/gpiobus.c =================================================================== --- sys/dev/gpio/gpiobus.c (revision 290622) +++ sys/dev/gpio/gpiobus.c (working copy) @@ -178,7 +178,7 @@ sc->sc_intr_rman.rm_type = RMAN_ARRAY; sc->sc_intr_rman.rm_descr = "GPIO Interrupts"; if (rman_init(&sc->sc_intr_rman) != 0 || - rman_manage_region(&sc->sc_intr_rman, 0, ~0) != 0) + rman_manage_region(&sc->sc_intr_rman, 0, RM_MAX_END) != 0) panic("%s: failed to set up rman.", __func__); if (GPIO_PIN_MAX(sc->sc_dev, &sc->sc_npins) != 0) @@ -488,7 +488,7 @@ static int gpiobus_set_resource(device_t dev, device_t child, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { struct gpiobus_ivar *devi; struct resource_list_entry *rle; @@ -506,7 +506,7 @@ static struct resource * gpiobus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct gpiobus_softc *sc; struct resource *rv; @@ -516,7 +516,7 @@ if (type != SYS_RES_IRQ) return (NULL); - isdefault = (start == 0UL && end == ~0UL && count == 1); + isdefault = (start == 0 && end == ~0 && count == 1); rle = NULL; if (isdefault) { rl = BUS_GET_RESOURCE_LIST(bus, child); Index: sys/dev/hpt27xx/hpt27xx_osm_bsd.c =================================================================== --- sys/dev/hpt27xx/hpt27xx_osm_bsd.c (revision 290622) +++ sys/dev/hpt27xx/hpt27xx_osm_bsd.c (working copy) @@ -1261,7 +1261,7 @@ for (hba = vbus_ext->hba_list; hba; hba = hba->next) { int rid = 0; if ((hba->irq_res = bus_alloc_resource(hba->pcidev, - SYS_RES_IRQ, &rid, 0, ~0ul, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) + SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) { os_printk("can't allocate interrupt"); return ; Index: sys/dev/hptiop/hptiop.c =================================================================== --- sys/dev/hptiop/hptiop.c (revision 290622) +++ sys/dev/hptiop/hptiop.c (working copy) @@ -2053,7 +2053,7 @@ rid = 0; if ((hba->irq_res = bus_alloc_resource(hba->pcidev, SYS_RES_IRQ, - &rid, 0, ~0ul, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) { + &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) { device_printf(dev, "allocate irq failed!\n"); goto free_hba_path; } Index: sys/dev/hptmv/entry.c =================================================================== --- sys/dev/hptmv/entry.c (revision 290622) +++ sys/dev/hptmv/entry.c (working copy) @@ -1990,7 +1990,7 @@ return rid; rid = 0; - if ((pAdapter->hpt_irq = bus_alloc_resource(pAdapter->hpt_dev, SYS_RES_IRQ, &rid, 0, ~0ul, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) + if ((pAdapter->hpt_irq = bus_alloc_resource(pAdapter->hpt_dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) { hpt_printk(("can't allocate interrupt\n")); return(ENXIO); Index: sys/dev/hptnr/hptnr_osm_bsd.c =================================================================== --- sys/dev/hptnr/hptnr_osm_bsd.c (revision 290622) +++ sys/dev/hptnr/hptnr_osm_bsd.c (working copy) @@ -1446,7 +1446,7 @@ for (hba = vbus_ext->hba_list; hba; hba = hba->next) { int rid = 0; if ((hba->irq_res = bus_alloc_resource(hba->pcidev, - SYS_RES_IRQ, &rid, 0, ~0ul, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) + SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) { os_printk("can't allocate interrupt"); return ; Index: sys/dev/hptrr/hptrr_osm_bsd.c =================================================================== --- sys/dev/hptrr/hptrr_osm_bsd.c (revision 290622) +++ sys/dev/hptrr/hptrr_osm_bsd.c (working copy) @@ -1094,7 +1094,7 @@ for (hba = vbus_ext->hba_list; hba; hba = hba->next) { int rid = 0; if ((hba->irq_res = bus_alloc_resource(hba->pcidev, - SYS_RES_IRQ, &rid, 0, ~0ul, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) + SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE)) == NULL) { os_printk("can't allocate interrupt"); return ; Index: sys/dev/ichsmb/ichsmb_pci.c =================================================================== --- sys/dev/ichsmb/ichsmb_pci.c (revision 290622) +++ sys/dev/ichsmb/ichsmb_pci.c (working copy) @@ -241,7 +241,7 @@ &sc->io_rid, 0, ~0, 16, RF_ACTIVE); if (sc->io_res == NULL) sc->io_res = bus_alloc_resource(dev, SYS_RES_IOPORT, - &sc->io_rid, 0ul, ~0ul, 32, RF_ACTIVE); + &sc->io_rid, 0, ~0, 32, RF_ACTIVE); if (sc->io_res == NULL) { device_printf(dev, "can't map I/O\n"); error = ENXIO; Index: sys/dev/if_ndis/if_ndis_pccard.c =================================================================== --- sys/dev/if_ndis/if_ndis_pccard.c (revision 290622) +++ sys/dev/if_ndis/if_ndis_pccard.c (working copy) @@ -281,7 +281,7 @@ sc = arg; rid = NDIS_AM_RID; sc->ndis_res_am = bus_alloc_resource(sc->ndis_dev, SYS_RES_MEMORY, - &rid, 0UL, ~0UL, 0x1000, RF_ACTIVE); + &rid, 0, ~0, 0x1000, RF_ACTIVE); if (sc->ndis_res_am == NULL) { device_printf(sc->ndis_dev, Index: sys/dev/iicbus/iicoc.c =================================================================== --- sys/dev/iicbus/iicoc.c (revision 290622) +++ sys/dev/iicbus/iicoc.c (working copy) @@ -208,7 +208,7 @@ mtx_init(&sc->sc_mtx, "iicoc", "iicoc", MTX_DEF); sc->mem_rid = 0; sc->mem_res = bus_alloc_resource(dev, - SYS_RES_MEMORY, &sc->mem_rid, 0ul, ~0ul, 0x100, RF_ACTIVE); + SYS_RES_MEMORY, &sc->mem_rid, 0, ~0, 0x100, RF_ACTIVE); if (sc->mem_res == NULL) { device_printf(dev, "Could not allocate bus resource.\n"); Index: sys/dev/iir/iir_pci.c =================================================================== --- sys/dev/iir/iir_pci.c (revision 290622) +++ sys/dev/iir/iir_pci.c (working copy) @@ -228,7 +228,7 @@ /* check and reset interface area */ bus_write_4(gdt->sc_dpmem, GDT_MPR_IC, htole32(GDT_MPR_MAGIC)); if (bus_read_4(gdt->sc_dpmem, GDT_MPR_IC) != htole32(GDT_MPR_MAGIC)) { - device_printf(dev, "cannot access DPMEM at 0x%lx (shadowed?)\n", + device_printf(dev, "cannot access DPMEM at 0x%jx (shadowed?)\n", rman_get_start(gdt->sc_dpmem)); error = ENXIO; goto err; Index: sys/dev/mca/mca_bus.c =================================================================== --- sys/dev/mca/mca_bus.c (revision 290622) +++ sys/dev/mca/mca_bus.c (working copy) @@ -365,11 +365,11 @@ rid = 0; while ((rle = resource_list_find(&(m_dev->rl), SYS_RES_IOPORT, rid++))) { if (rle->count == 1) { - snprintf(buf, sizeof(buf), "%s%lx", + snprintf(buf, sizeof(buf), "%s%jx", ((rid == 1) ? "io 0x" : "0x"), rle->start); } else { - snprintf(buf, sizeof(buf), "%s%lx-0x%lx", + snprintf(buf, sizeof(buf), "%s%jx-0x%jx", ((rid == 1) ? "io 0x" : "0x"), rle->start, (rle->start + rle->count)); @@ -381,11 +381,11 @@ rid = 0; while ((rle = resource_list_find(&(m_dev->rl), SYS_RES_MEMORY, rid++))) { if (rle->count == 1) { - snprintf(buf, sizeof(buf), "%s%lx", + snprintf(buf, sizeof(buf), "%s%jx", ((rid == 1) ? "mem 0x" : "0x"), rle->start); } else { - snprintf(buf, sizeof(buf), "%s%lx-0x%lx", + snprintf(buf, sizeof(buf), "%s%jx-0x%jx", ((rid == 1) ? "mem 0x" : "0x"), rle->start, (rle->start + rle->count)); @@ -396,7 +396,7 @@ rid = 0; while ((rle = resource_list_find(&(m_dev->rl), SYS_RES_IRQ, rid++))) { - snprintf(buf, sizeof(buf), "irq %ld", rle->start); + snprintf(buf, sizeof(buf), "irq %jd", rle->start); mca_reg_print(child, buf, ((rid == 1) ? &separator : NULL), &column); } @@ -403,7 +403,7 @@ rid = 0; while ((rle = resource_list_find(&(m_dev->rl), SYS_RES_DRQ, rid++))) { - snprintf(buf, sizeof(buf), "drq %lx", rle->start); + snprintf(buf, sizeof(buf), "drq %jx", rle->start); mca_reg_print(child, buf, ((rid == 1) ? &separator : NULL), &column); } @@ -456,7 +456,7 @@ static struct resource * mca_alloc_resource (device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct mca_device * m_dev = device_get_ivars(child); struct resource_list_entry * rle; @@ -463,7 +463,7 @@ int isdefault; int passthrough; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); passthrough = (device_get_parent(child) != dev); if (!passthrough && !isdefault) { Index: sys/dev/mii/mii.c =================================================================== --- sys/dev/mii/mii.c (revision 290622) +++ sys/dev/mii/mii.c (working copy) @@ -401,6 +401,7 @@ ivars->mii_flags = flags; *miibus = device_add_child(dev, "miibus", -1); if (*miibus == NULL) { + printf("%s: can't add child\n", __func__); rv = ENXIO; goto fail; } @@ -509,6 +510,7 @@ goto fail; free(children, M_TEMP); if (nchildren == 0) { + printf("%s: no children to enumerate\n", __func__); rv = ENXIO; goto fail; } Index: sys/dev/mvs/mvs_pci.c =================================================================== --- sys/dev/mvs/mvs_pci.c (revision 290622) +++ sys/dev/mvs/mvs_pci.c (working copy) @@ -389,7 +389,8 @@ static struct resource * mvs_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct mvs_controller *ctlr = device_get_softc(dev); int unit = ((struct mvs_channel *)device_get_softc(child))->unit; Index: sys/dev/mvs/mvs_soc.c =================================================================== --- sys/dev/mvs/mvs_soc.c (revision 290622) +++ sys/dev/mvs/mvs_soc.c (working copy) @@ -336,7 +336,7 @@ static struct resource * mvs_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct mvs_controller *ctlr = device_get_softc(dev); int unit = ((struct mvs_channel *)device_get_softc(child))->unit; Index: sys/dev/mxge/if_mxge.c =================================================================== --- sys/dev/mxge/if_mxge.c (revision 290622) +++ sys/dev/mxge/if_mxge.c (working copy) @@ -4612,7 +4612,7 @@ device_printf(sc->dev, "using %d msix IRQs:", sc->num_slices); for (i = 0; i < sc->num_slices; i++) - printf(" %ld", rman_get_start(sc->msix_irq_res[i])); + printf(" %jd", rman_get_start(sc->msix_irq_res[i])); printf("\n"); } return (0); @@ -4668,7 +4668,7 @@ return ENXIO; } if (mxge_verbose) - device_printf(sc->dev, "using %s irq %ld\n", + device_printf(sc->dev, "using %s irq %jd\n", sc->legacy_irq ? "INTx" : "MSI", rman_get_start(sc->irq_res)); err = bus_setup_intr(sc->dev, sc->irq_res, @@ -4823,7 +4823,7 @@ sc->sram = rman_get_virtual(sc->mem_res); sc->sram_size = 2*1024*1024 - (2*(48*1024)+(32*1024)) - 0x100; if (sc->sram_size > rman_get_size(sc->mem_res)) { - device_printf(dev, "impossible memory region size %ld\n", + device_printf(dev, "impossible memory region size %jd\n", rman_get_size(sc->mem_res)); err = ENXIO; goto abort_with_mem_res; Index: sys/dev/ncv/ncr53c500_pccard.c =================================================================== --- sys/dev/ncv/ncr53c500_pccard.c (revision 290622) +++ sys/dev/ncv/ncr53c500_pccard.c (working copy) @@ -142,7 +142,7 @@ { struct ncv_softc *sc = device_get_softc(dev); u_int32_t flags = device_get_flags(dev); - u_long ioaddr, iosize, maddr, msize; + uintmax_t ioaddr, iosize, maddr, msize; int error; bus_addr_t offset = 0; Index: sys/dev/nsp/nsp_pccard.c =================================================================== --- sys/dev/nsp/nsp_pccard.c (revision 290622) +++ sys/dev/nsp/nsp_pccard.c (working copy) @@ -115,7 +115,7 @@ nsp_alloc_resource(device_t dev) { struct nsp_softc *sc = device_get_softc(dev); - u_long ioaddr, iosize, maddr, msize; + uintmax_t ioaddr, iosize, maddr, msize; int error; error = bus_get_resource(dev, SYS_RES_IOPORT, 0, &ioaddr, &iosize); Index: sys/dev/ntb/ntb_hw/ntb_hw.c =================================================================== --- sys/dev/ntb/ntb_hw/ntb_hw.c (revision 290622) +++ sys/dev/ntb/ntb_hw/ntb_hw.c (working copy) @@ -730,7 +730,7 @@ * Ideally I could have just specified the size when I allocated the * resource like: * bus_alloc_resource(ntb->device, - * SYS_RES_MEMORY, &bar->pci_resource_id, 0ul, ~0ul, + * SYS_RES_MEMORY, &bar->pci_resource_id, 0, ~0, * 1ul << bar_size_bits, RF_ACTIVE); * but the PCI driver does not honor the size in this call, so we have * to modify it after the fact. Index: sys/dev/oce/oce_hw.c =================================================================== --- sys/dev/oce/oce_hw.c (revision 290622) +++ sys/dev/oce/oce_hw.c (working copy) @@ -270,7 +270,7 @@ else sc->devcfg_res = bus_alloc_resource(sc->dev, SYS_RES_MEMORY, &rr, - 0ul, ~0ul, 32768, + 0, ~0, 32768, RF_ACTIVE|RF_SHAREABLE); if (!sc->devcfg_res) Index: sys/dev/ofw/ofwbus.c =================================================================== --- sys/dev/ofw/ofwbus.c (revision 290622) +++ sys/dev/ofw/ofwbus.c (working copy) @@ -156,7 +156,7 @@ sc->sc_mem_rman.rm_descr = "Device Memory"; if (rman_init(&sc->sc_intr_rman) != 0 || rman_init(&sc->sc_mem_rman) != 0 || - rman_manage_region(&sc->sc_intr_rman, 0, ~0) != 0 || + rman_manage_region(&sc->sc_intr_rman, 0, RM_MAX_END) != 0 || rman_manage_region(&sc->sc_mem_rman, 0, BUS_SPACE_MAXADDR) != 0) panic("%s: failed to set up rmans.", __func__); @@ -178,7 +178,7 @@ static struct resource * ofwbus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ofwbus_softc *sc; struct rman *rm; @@ -186,7 +186,7 @@ struct resource_list_entry *rle; int isdefault, passthrough; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == RM_MAX_END); passthrough = (device_get_parent(child) != bus); sc = device_get_softc(bus); rle = NULL; @@ -200,8 +200,8 @@ return (NULL); } start = rle->start; - count = ulmax(count, rle->count); - end = ulmax(rle->end, start + count - 1); + count = ummax(count, rle->count); + end = ummax(rle->end, start + count - 1); } switch (type) { @@ -239,7 +239,7 @@ static int ofwbus_adjust_resource(device_t bus, device_t child __unused, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct ofwbus_softc *sc; struct rman *rm; Index: sys/dev/pccard/pccard.c =================================================================== --- sys/dev/pccard/pccard.c (revision 290622) +++ sys/dev/pccard/pccard.c (working copy) @@ -97,9 +97,9 @@ const char *name, int type, int count, const char *format); static int pccard_print_child(device_t dev, device_t child); static int pccard_set_resource(device_t dev, device_t child, int type, - int rid, u_long start, u_long count); + int rid, uintmax_t start, uintmax_t count); static int pccard_get_resource(device_t dev, device_t child, int type, - int rid, u_long *startp, u_long *countp); + int rid, uintmax_t *startp, uintmax_t *countp); static void pccard_delete_resource(device_t dev, device_t child, int type, int rid); static int pccard_set_res_flags(device_t dev, device_t child, int type, @@ -113,8 +113,8 @@ uintptr_t *result); static void pccard_driver_added(device_t dev, driver_t *driver); static struct resource *pccard_alloc_resource(device_t dev, - device_t child, int type, int *rid, u_long start, - u_long end, u_long count, u_int flags); + device_t child, int type, int *rid, uintmax_t start, + uintmax_t end, uintmax_t count, u_int flags); static int pccard_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); static void pccard_child_detached(device_t parent, device_t dev); @@ -474,7 +474,7 @@ struct pccard_ce_iospace *ios; struct pccard_ce_memspace *mems; device_t bus; - u_long start, end, len; + uintmax_t start, end, len; int i, rid, spaces; if (pf->pf_flags & PFF_ENABLED) { @@ -506,8 +506,8 @@ if (start) end = start + ios->length - 1; else - end = ~0UL; - DEVPRINTF((bus, "I/O rid %d start %#lx end %#lx\n", + end = ~0; + DEVPRINTF((bus, "I/O rid %d start %#jx end %#jx\n", i, start, end)); rid = i; len = ios->length; @@ -530,10 +530,10 @@ if (start) end = start + mems->length - 1; else - end = ~0UL; - DEVPRINTF((bus, "Memory rid %d start %#lx end %#lx\ncardaddr %#lx hostaddr %#lx length %#lx\n", - i, start, end, mems->cardaddr, mems->hostaddr, - mems->length)); + end = ~0; + DEVPRINTF((bus, "Memory rid %d start %#jx end %#jx\ncardaddr %#jx hostaddr %#jx length %#jx\n", + i, start, end, (uintmax_t)mems->cardaddr, (uintmax_t)mems->hostaddr, + (uintmax_t)mems->length)); rid = i; len = mems->length; r = bus_alloc_resource(bus, SYS_RES_MEMORY, &rid, @@ -602,7 +602,7 @@ device_printf(pf->sc->dev, "function_free: Resource still owned by " "child, oops. " - "(type=%d, rid=%d, addr=%#lx)\n", + "(type=%d, rid=%d, addr=%#jx)\n", rle->type, rle->rid, rman_get_start(rle->res)); BUS_RELEASE_RESOURCE(device_get_parent(pf->sc->dev), @@ -614,8 +614,8 @@ } static void -pccard_mfc_adjust_iobase(struct pccard_function *pf, bus_addr_t addr, - bus_addr_t offset, bus_size_t size) +pccard_mfc_adjust_iobase(struct pccard_function *pf, uintmax_t addr, + uintmax_t offset, uintmax_t size) { bus_size_t iosize, tmp; @@ -697,7 +697,7 @@ &pf->ccr_rid, 0, ~0, PCCARD_MEM_PAGE_SIZE, RF_ACTIVE); if (!pf->ccr_res) goto bad; - DEVPRINTF((dev, "ccr_res == %#lx-%#lx, base=%#x\n", + DEVPRINTF((dev, "ccr_res == %#jx-%#jx, base=%#x\n", rman_get_start(pf->ccr_res), rman_get_end(pf->ccr_res), pf->ccr_base)); CARD_SET_RES_FLAGS(device_get_parent(dev), dev, SYS_RES_MEMORY, @@ -923,7 +923,7 @@ static int pccard_set_resource(device_t dev, device_t child, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { struct pccard_ivar *devi = PCCARD_IVAR(child); struct resource_list *rl = &devi->resources; @@ -952,7 +952,7 @@ static int pccard_get_resource(device_t dev, device_t child, int type, int rid, - u_long *startp, u_long *countp) + uintmax_t *startp, uintmax_t *countp) { struct pccard_ivar *devi = PCCARD_IVAR(child); struct resource_list *rl = &devi->resources; @@ -1132,12 +1132,12 @@ static struct resource * pccard_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct pccard_ivar *dinfo; struct resource_list_entry *rle = 0; int passthrough = (device_get_parent(child) != dev); - int isdefault = (start == 0 && end == ~0UL && count == 1); + int isdefault = (start == 0 && end == ~0 && count == 1); struct resource *r = NULL; /* XXX I'm no longer sure this is right */ @@ -1197,7 +1197,7 @@ if (!rle) { device_printf(dev, "Allocated resource not found, " - "%d %#x %#lx %#lx\n", + "%d %#x %#jx %#jx\n", type, rid, rman_get_start(r), rman_get_size(r)); return ENOENT; } Index: sys/dev/pccard/pccard_cis.c =================================================================== --- sys/dev/pccard/pccard_cis.c (revision 290622) +++ sys/dev/pccard/pccard_cis.c (working copy) @@ -151,7 +151,7 @@ tuple.memh = rman_get_bushandle(res); tuple.ptr = 0; - DPRINTF(("cis mem map %#x (resource: %#lx)\n", + DPRINTF(("cis mem map %#x (resource: %#jx)\n", (unsigned int) tuple.memh, rman_get_start(res))); tuple.mult = 2; @@ -576,9 +576,9 @@ printf("; iomask %#lx, iospace", cfe->iomask); for (i = 0; i < cfe->num_iospace; i++) { - printf(" %#lx", cfe->iospace[i].start); + printf(" %#jx", cfe->iospace[i].start); if (cfe->iospace[i].length) - printf("-%#lx", + printf("-%#jx", cfe->iospace[i].start + cfe->iospace[i].length - 1); } @@ -587,14 +587,14 @@ printf("; memspace"); for (i = 0; i < cfe->num_memspace; i++) { - printf(" %#lx", + printf(" %#jx", cfe->memspace[i].cardaddr); if (cfe->memspace[i].length) - printf("-%#lx", + printf("-%#jx", cfe->memspace[i].cardaddr + cfe->memspace[i].length - 1); if (cfe->memspace[i].hostaddr) - printf("@%#lx", + printf("@%#jx", cfe->memspace[i].hostaddr); } } Index: sys/dev/pccard/pccardvarp.h =================================================================== --- sys/dev/pccard/pccardvarp.h (revision 290622) +++ sys/dev/pccard/pccardvarp.h (working copy) @@ -48,14 +48,14 @@ #define PCCARD_CFE_AUDIO 0x0800 struct pccard_ce_iospace { - u_long length; - u_long start; + uintmax_t length; + uintmax_t start; }; struct pccard_ce_memspace { - u_long length; - u_long cardaddr; - u_long hostaddr; + uintmax_t length; + uintmax_t cardaddr; + uintmax_t hostaddr; }; struct pccard_config_entry { Index: sys/dev/pccbb/pccbb.c =================================================================== --- sys/dev/pccbb/pccbb.c (revision 290622) +++ sys/dev/pccbb/pccbb.c (working copy) @@ -166,8 +166,8 @@ static int cbb_cardbus_deactivate_resource(device_t brdev, device_t child, int type, int rid, struct resource *res); static struct resource *cbb_cardbus_alloc_resource(device_t brdev, - device_t child, int type, int *rid, u_long start, - u_long end, u_long count, u_int flags); + device_t child, int type, int *rid, uintmax_t start, + uintmax_t end, uintmax_t count, u_int flags); static int cbb_cardbus_release_resource(device_t brdev, device_t child, int type, int rid, struct resource *res); static int cbb_cardbus_power_enable_socket(device_t brdev, @@ -229,7 +229,7 @@ while ((rle = SLIST_FIRST(&sc->rl)) != NULL) { device_printf(sc->dev, "Danger Will Robinson: Resource " "left allocated! This is a bug... " - "(rid=%x, type=%d, addr=%lx)\n", rle->rid, rle->type, + "(rid=%x, type=%d, addr=%jx)\n", rle->rid, rle->type, rman_get_start(rle->res)); SLIST_REMOVE_HEAD(&sc->rl, link); free(rle, M_DEVBUF); @@ -1230,19 +1230,19 @@ static struct resource * cbb_cardbus_alloc_resource(device_t brdev, device_t child, int type, - int *rid, u_long start, u_long end, u_long count, u_int flags) + int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct cbb_softc *sc = device_get_softc(brdev); int tmp; struct resource *res; - u_long align; + uintmax_t align; switch (type) { case SYS_RES_IRQ: tmp = rman_get_start(sc->irq_res); if (start > tmp || end < tmp || count != 1) { - device_printf(child, "requested interrupt %ld-%ld," - "count = %ld not supported by cbb\n", + device_printf(child, "requested interrupt %jd-%jd," + "count = %jd not supported by cbb\n", start, end, count); return (NULL); } @@ -1395,7 +1395,7 @@ static struct resource * cbb_pcic_alloc_resource(device_t brdev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res = NULL; struct cbb_softc *sc = device_get_softc(brdev); @@ -1425,8 +1425,8 @@ case SYS_RES_IRQ: tmp = rman_get_start(sc->irq_res); if (start > tmp || end < tmp || count != 1) { - device_printf(child, "requested interrupt %ld-%ld," - "count = %ld not supported by cbb\n", + device_printf(child, "requested interrupt %jd-%jd," + "count = %jd not supported by cbb\n", start, end, count); return (NULL); } @@ -1538,7 +1538,7 @@ struct resource * cbb_alloc_resource(device_t brdev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct cbb_softc *sc = device_get_softc(brdev); Index: sys/dev/pccbb/pccbb_pci.c =================================================================== --- sys/dev/pccbb/pccbb_pci.c (revision 290622) +++ sys/dev/pccbb/pccbb_pci.c (working copy) @@ -313,7 +313,7 @@ mtx_destroy(&sc->mtx); return (ENOMEM); } else { - DEVPRINTF((brdev, "Found memory at %08lx\n", + DEVPRINTF((brdev, "Found memory at %jx\n", rman_get_start(sc->base_res))); } @@ -783,7 +783,7 @@ #if defined(NEW_PCIB) && defined(PCI_RES_BUS) static struct resource * cbb_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct cbb_softc *sc; @@ -797,7 +797,7 @@ static int cbb_pci_adjust_resource(device_t bus, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct cbb_softc *sc; Index: sys/dev/pccbb/pccbbvar.h =================================================================== --- sys/dev/pccbb/pccbbvar.h (revision 290622) +++ sys/dev/pccbb/pccbbvar.h (working copy) @@ -113,7 +113,7 @@ int cbb_activate_resource(device_t brdev, device_t child, int type, int rid, struct resource *r); struct resource *cbb_alloc_resource(device_t brdev, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, + int type, int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags); void cbb_child_detached(device_t brdev, device_t child); int cbb_child_present(device_t parent, device_t child); Index: sys/dev/pcf/pcf_isa.c =================================================================== --- sys/dev/pcf/pcf_isa.c (revision 290622) +++ sys/dev/pcf/pcf_isa.c (working copy) @@ -100,7 +100,7 @@ static int pcf_isa_probe(device_t dev) { - u_long start, count; + uintmax_t start, count; u_int rid = 0, port, error; /* skip PnP probes */ Index: sys/dev/pci/hostb_pci.c =================================================================== --- sys/dev/pci/hostb_pci.c (revision 290622) +++ sys/dev/pci/hostb_pci.c (working copy) @@ -102,7 +102,7 @@ static struct resource * pci_hostb_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int flags) { return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Index: sys/dev/pci/isa_pci.c =================================================================== --- sys/dev/pci/isa_pci.c (revision 290622) +++ sys/dev/pci/isa_pci.c (working copy) @@ -52,8 +52,8 @@ static int isab_pci_probe(device_t dev); static int isab_pci_attach(device_t dev); static struct resource * isab_pci_alloc_resource(device_t dev, - device_t child, int type, int *rid, u_long start, u_long end, u_long count, - u_int flags); + device_t child, int type, int *rid, uintmax_t start, uintmax_t end, + uintmax_t count, u_int flags); static int isab_pci_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); @@ -169,7 +169,7 @@ static struct resource * isab_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct isab_pci_softc *sc; int bar; Index: sys/dev/pci/pci.c =================================================================== --- sys/dev/pci/pci.c (revision 290622) +++ sys/dev/pci/pci.c (working copy) @@ -1557,7 +1557,7 @@ if (bootverbose) { rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, 1); if (actual == 1) - device_printf(child, "using IRQ %lu for MSI-X\n", + device_printf(child, "using IRQ %ju for MSI-X\n", rle->start); else { int run; @@ -1567,7 +1567,7 @@ * IRQ values as ranges. 'irq' is the previous IRQ. * 'run' is true if we are in a range. */ - device_printf(child, "using IRQs %lu", rle->start); + device_printf(child, "using IRQs %ju", rle->start); irq = rle->start; run = 0; for (i = 1; i < actual; i++) { @@ -1588,7 +1588,7 @@ } /* Start new range. */ - printf(",%lu", rle->start); + printf(",%ju", rle->start); irq = rle->start; } @@ -2922,7 +2922,7 @@ pm = pci_add_bar(dev, reg, map, mapsize); if (bootverbose) { printf("\tmap[%02x]: type %s, range %2d, base %#jx, size %2d", - reg, pci_maptype(map), maprange, (uintmax_t)base, mapsize); + reg, pci_maptype(map), maprange, base, mapsize); if (type == SYS_RES_IOPORT && !pci_porten(dev)) printf(", port disabled\n"); else if (type == SYS_RES_MEMORY && !pci_memen(dev)) @@ -2984,7 +2984,7 @@ flags |= RF_PREFETCHABLE; if (basezero || base == pci_mapbase(testval) || pci_clear_bars) { start = 0; /* Let the parent decide. */ - end = ~0ul; + end = ~0; } else { start = base; end = base + count - 1; @@ -2999,7 +2999,7 @@ */ res = resource_list_reserve(rl, bus, dev, type, ®, start, end, count, flags); - if (pci_do_realloc_bars && res == NULL && (start != 0 || end != ~0ul)) { + if (pci_do_realloc_bars && res == NULL && (start != 0 || end != ~0)) { /* * If the allocation fails, try to allocate a resource for * this BAR using any available range. The firmware felt @@ -3007,8 +3007,8 @@ * disable decoding if we can help it. */ resource_list_delete(rl, type, reg); - resource_list_add(rl, type, reg, 0, ~0ul, count); - res = resource_list_reserve(rl, bus, dev, type, ®, 0, ~0ul, + resource_list_add(rl, type, reg, 0, ~0, count); + res = resource_list_reserve(rl, bus, dev, type, ®, 0, ~0, count, flags); } if (res == NULL) { @@ -3329,7 +3329,7 @@ { struct resource *res; char *cp; - u_long start, end, count; + uintmax_t start, end, count; int rid, sec_bus, sec_reg, sub_bus, sub_reg, sup_bus; switch (cfg->hdrtype & PCIM_HDRTYPE) { @@ -3399,7 +3399,7 @@ end = sub_bus; count = end - start + 1; - resource_list_add(rl, PCI_RES_BUS, 0, 0ul, ~0ul, count); + resource_list_add(rl, PCI_RES_BUS, 0, 0, ~0, count); /* * If requested, clear secondary bus registers in @@ -3429,8 +3429,8 @@ } static struct resource * -pci_alloc_secbus(device_t dev, device_t child, int *rid, u_long start, - u_long end, u_long count, u_int flags) +pci_alloc_secbus(device_t dev, device_t child, int *rid, __uintmax_t start, + __uintmax_t end, __uintmax_t count, u_int flags) { struct pci_devinfo *dinfo; pcicfgregs *cfg; @@ -3464,13 +3464,13 @@ start, end, count, flags & ~RF_ACTIVE); if (res == NULL) { resource_list_delete(rl, PCI_RES_BUS, *rid); - device_printf(child, "allocating %lu bus%s failed\n", + device_printf(child, "allocating %ju bus%s failed\n", count, count == 1 ? "" : "es"); return (NULL); } if (bootverbose) device_printf(child, - "Lazy allocation of %lu bus%s at %lu\n", count, + "Lazy allocation of %ju bus%s at %ju\n", count, count == 1 ? "" : "es", rman_get_start(res)); PCI_WRITE_CONFIG(dev, child, sec_reg, rman_get_start(res), 1); PCI_WRITE_CONFIG(dev, child, sub_reg, rman_get_end(res), 1); @@ -3615,9 +3615,10 @@ continue; if (hdrtype & PCIM_MFDEV) pcifunchigh = PCIB_MAXFUNCS(pcib); - for (f = first_func; f <= pcifunchigh; f++) + for (f = first_func; f <= pcifunchigh; f++) { pci_identify_function(pcib, dev, domain, busno, s, f, dinfo_size); + } } #undef REG } @@ -4102,9 +4103,9 @@ retval += bus_print_child_header(dev, child); - retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#lx"); - retval += resource_list_print_type(rl, "mem", SYS_RES_MEMORY, "%#lx"); - retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld"); + retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#jx"); + retval += resource_list_print_type(rl, "mem", SYS_RES_MEMORY, "%#jx"); + retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%jd"); if (device_get_flags(dev)) retval += printf(" flags %#x", device_get_flags(dev)); @@ -4594,7 +4595,8 @@ static struct resource * pci_reserve_map(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int num, u_int flags) + __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int num, + u_int flags) { struct pci_devinfo *dinfo = device_get_ivars(child); struct resource_list *rl = &dinfo->resources; @@ -4676,13 +4678,13 @@ if (res == NULL) { resource_list_delete(rl, type, *rid); device_printf(child, - "%#lx bytes of rid %#x res %d failed (%#lx, %#lx).\n", + "%#jx bytes of rid %#x res %d failed (%#jx, %#jx).\n", count, *rid, type, start, end); goto out; } if (bootverbose) device_printf(child, - "Lazy allocation of %#lx bytes rid %#x type %d at %#lx\n", + "Lazy allocation of %#jx bytes rid %#x type %d at %#jx\n", count, *rid, type, rman_get_start(res)); map = rman_get_start(res); pci_write_bar(child, pm, map); @@ -4692,7 +4694,8 @@ struct resource * pci_alloc_multi_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_long num, u_int flags) + __uintmax_t start, __uintmax_t end, __uintmax_t count, u_long num, + u_int flags) { struct pci_devinfo *dinfo; struct resource_list *rl; @@ -4767,7 +4770,7 @@ struct resource * pci_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int flags) { #ifdef PCI_IOV struct pci_devinfo *dinfo; @@ -4958,7 +4961,7 @@ resource_list_busy(rl, type, rid)) { device_printf(dev, "delete_resource: " "Resource still owned by child, oops. " - "(type=%d, rid=%d, addr=%lx)\n", + "(type=%d, rid=%d, addr=%jx)\n", type, rid, rman_get_start(rle->res)); return; } Index: sys/dev/pci/pci_host_generic.c =================================================================== --- sys/dev/pci/pci_host_generic.c (revision 290622) +++ sys/dev/pci/pci_host_generic.c (working copy) @@ -123,8 +123,8 @@ static int generic_pcie_write_ivar(device_t dev, device_t child, int index, uintptr_t value); static struct resource *generic_pcie_alloc_resource(device_t dev, - device_t child, int type, int *rid, u_long start, u_long end, - u_long count, u_int flags); + device_t child, int type, int *rid, __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); static int generic_pcie_release_resource(device_t dev, device_t child, int type, int rid, struct resource *res); @@ -461,7 +461,7 @@ static struct resource * generic_pcie_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int flags) { struct generic_pcie_softc *sc; struct resource *res; @@ -506,7 +506,7 @@ static int generic_pcie_adjust_resource(device_t dev, device_t child, int type, - struct resource *res, u_long start, u_long end) + struct resource *res, __uintmax_t start, __uintmax_t end) { struct generic_pcie_softc *sc; struct rman *rm; Index: sys/dev/pci/pci_iov.c =================================================================== --- sys/dev/pci/pci_iov.c (revision 290622) +++ sys/dev/pci/pci_iov.c (working copy) @@ -320,7 +320,7 @@ struct resource *res; struct pcicfg_iov *iov; device_t dev, bus; - u_long start, end; + uintmax_t start, end; pci_addr_t bar_size; int rid; @@ -330,8 +330,8 @@ rid = iov->iov_pos + PCIR_SRIOV_BAR(bar); bar_size = 1 << bar_shift; - res = pci_alloc_multi_resource(bus, dev, SYS_RES_MEMORY, &rid, 0ul, - ~0ul, 1, iov->iov_num_vfs, RF_ACTIVE); + res = pci_alloc_multi_resource(bus, dev, SYS_RES_MEMORY, &rid, 0, + ~0, 1, iov->iov_num_vfs, RF_ACTIVE); if (res == NULL) return (ENXIO); @@ -498,7 +498,7 @@ int error; iov->rman.rm_start = 0; - iov->rman.rm_end = ~0ul; + iov->rman.rm_end = ~0; iov->rman.rm_type = RMAN_ARRAY; snprintf(iov->rman_name, sizeof(iov->rman_name), "%s VF I/O memory", device_get_nameunit(pf)); @@ -890,8 +890,8 @@ } struct resource * -pci_vf_alloc_mem_resource(device_t dev, device_t child, int *rid, u_long start, - u_long end, u_long count, u_int flags) +pci_vf_alloc_mem_resource(device_t dev, device_t child, int *rid, + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct pci_devinfo *dinfo; struct pcicfg_iov *iov; @@ -898,7 +898,7 @@ struct pci_map *map; struct resource *res; struct resource_list_entry *rle; - u_long bar_start, bar_end; + uintmax_t bar_start, bar_end; pci_addr_t bar_length; int error; Index: sys/dev/pci/pci_pci.c =================================================================== --- sys/dev/pci/pci_pci.c (revision 290622) +++ sys/dev/pci/pci_pci.c (working copy) @@ -212,9 +212,10 @@ * ISA alias range. */ static int -pcib_is_isa_range(struct pcib_softc *sc, u_long start, u_long end, u_long count) +pcib_is_isa_range(struct pcib_softc *sc, uintmax_t start, uintmax_t end, + uintmax_t count) { - u_long next_alias; + uintmax_t next_alias; if (!(sc->bridgectl & PCIB_BCR_ISA_ENABLE)) return (0); @@ -246,7 +247,7 @@ alias: if (bootverbose) device_printf(sc->dev, - "I/O range %#lx-%#lx overlaps with an ISA alias\n", start, + "I/O range %#jx-%#jx overlaps with an ISA alias\n", start, end); return (1); } @@ -275,13 +276,13 @@ } } -typedef void (nonisa_callback)(u_long start, u_long end, void *arg); +typedef void (nonisa_callback)(uintmax_t start, uintmax_t end, void *arg); static void -pcib_walk_nonisa_ranges(u_long start, u_long end, nonisa_callback *cb, +pcib_walk_nonisa_ranges(uintmax_t start, uintmax_t end, nonisa_callback *cb, void *arg) { - u_long next_end; + uintmax_t next_end; /* * If start is within an ISA alias range, move up to the start @@ -309,7 +310,7 @@ } static void -count_ranges(u_long start, u_long end, void *arg) +count_ranges(uintmax_t start, uintmax_t end, void *arg) { int *countp; @@ -324,7 +325,7 @@ }; static void -alloc_ranges(u_long start, u_long end, void *arg) +alloc_ranges(uintmax_t start, uintmax_t end, void *arg) { struct alloc_state *as; struct pcib_window *w; @@ -338,7 +339,7 @@ rid = w->reg; if (bootverbose) device_printf(as->sc->dev, - "allocating non-ISA range %#lx-%#lx\n", start, end); + "allocating non-ISA range %#jx-%#jx\n", start, end); as->res[as->count] = bus_alloc_resource(as->sc->dev, SYS_RES_IOPORT, &rid, start, end, end - start + 1, 0); if (as->res[as->count] == NULL) @@ -348,7 +349,7 @@ } static int -pcib_alloc_nonisa_ranges(struct pcib_softc *sc, u_long start, u_long end) +pcib_alloc_nonisa_ranges(struct pcib_softc *sc, uintmax_t start, uintmax_t end) { struct alloc_state as; int i, new_count; @@ -387,8 +388,8 @@ char buf[64]; int error, rid; - if (max_address != (u_long)max_address) - max_address = ~0ul; + if (max_address != (uintmax_t)max_address) + max_address = ~(uintmax_t)0; w->rman.rm_start = 0; w->rman.rm_end = max_address; w->rman.rm_type = RMAN_ARRAY; @@ -576,7 +577,7 @@ * if one exists, or a new bus range if one does not. */ rid = 0; - bus->res = bus_alloc_resource(dev, PCI_RES_BUS, &rid, 0ul, ~0ul, + bus->res = bus_alloc_resource(dev, PCI_RES_BUS, &rid, 0, ~0, min_count, 0); if (bus->res == NULL) { /* @@ -583,7 +584,7 @@ * Fall back to just allocating a range of a single bus * number. */ - bus->res = bus_alloc_resource(dev, PCI_RES_BUS, &rid, 0ul, ~0ul, + bus->res = bus_alloc_resource(dev, PCI_RES_BUS, &rid, 0, ~0, 1, 0); } else if (rman_get_size(bus->res) < min_count) /* @@ -609,7 +610,7 @@ static struct resource * pcib_suballoc_bus(struct pcib_secbus *bus, device_t child, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res; @@ -620,7 +621,7 @@ if (bootverbose) device_printf(bus->dev, - "allocated bus range (%lu-%lu) for rid %d of %s\n", + "allocated bus range (%ju-%ju) for rid %d of %s\n", rman_get_start(res), rman_get_end(res), *rid, pcib_child_name(child)); rman_set_rid(res, *rid); @@ -633,9 +634,9 @@ * subbus. */ static int -pcib_grow_subbus(struct pcib_secbus *bus, u_long new_end) +pcib_grow_subbus(struct pcib_secbus *bus, uintmax_t new_end) { - u_long old_end; + uintmax_t old_end; int error; old_end = rman_get_end(bus->res); @@ -645,7 +646,7 @@ if (error) return (error); if (bootverbose) - device_printf(bus->dev, "grew bus range to %lu-%lu\n", + device_printf(bus->dev, "grew bus range to %ju-%ju\n", rman_get_start(bus->res), rman_get_end(bus->res)); error = rman_manage_region(&bus->rman, old_end + 1, rman_get_end(bus->res)); @@ -658,10 +659,10 @@ struct resource * pcib_alloc_subbus(struct pcib_secbus *bus, device_t child, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res; - u_long start_free, end_free, new_end; + uintmax_t start_free, end_free, new_end; /* * First, see if the request can be satisified by the existing @@ -693,8 +694,8 @@ /* Finally, attempt to grow the existing resource. */ if (bootverbose) { device_printf(bus->dev, - "attempting to grow bus range for %lu buses\n", count); - printf("\tback candidate range: %lu-%lu\n", start_free, + "attempting to grow bus range for %ju buses\n", count); + printf("\tback candidate range: %ju-%ju\n", start_free, new_end); } if (pcib_grow_subbus(bus, new_end) == 0) @@ -1158,8 +1159,8 @@ */ static struct resource * pcib_suballoc_resource(struct pcib_softc *sc, struct pcib_window *w, - device_t child, int type, int *rid, u_long start, u_long end, u_long count, - u_int flags) + device_t child, int type, int *rid, uintmax_t start, uintmax_t end, + uintmax_t count, u_int flags) { struct resource *res; @@ -1173,7 +1174,7 @@ if (bootverbose) device_printf(sc->dev, - "allocated %s range (%#lx-%#lx) for rid %x of %s\n", + "allocated %s range (%#jx-%#jx) for rid %x of %s\n", w->name, rman_get_start(res), rman_get_end(res), *rid, pcib_child_name(child)); rman_set_rid(res, *rid); @@ -1196,10 +1197,10 @@ /* Allocate a fresh resource range for an unconfigured window. */ static int pcib_alloc_new_window(struct pcib_softc *sc, struct pcib_window *w, int type, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res; - u_long base, limit, wmask; + uintmax_t base, limit, wmask; int rid; /* @@ -1269,7 +1270,7 @@ /* Try to expand an existing window to the requested base and limit. */ static int pcib_expand_window(struct pcib_softc *sc, struct pcib_window *w, int type, - u_long base, u_long limit) + uintmax_t base, uintmax_t limit) { struct resource *res; int error, i, force_64k_base; @@ -1367,9 +1368,9 @@ */ static int pcib_grow_window(struct pcib_softc *sc, struct pcib_window *w, int type, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { - u_long align, start_free, end_free, front, back, wmask; + uintmax_t align, start_free, end_free, front, back, wmask; int error; /* @@ -1388,7 +1389,7 @@ end = w->rman.rm_end; if (start + count - 1 > end || start + count < start) return (EINVAL); - wmask = (1ul << w->step) - 1; + wmask = ((uintmax_t)1 << w->step) - 1; /* * If there is no resource at all, just try to allocate enough @@ -1400,7 +1401,7 @@ if (error) { if (bootverbose) device_printf(sc->dev, - "failed to allocate initial %s window (%#lx-%#lx,%#lx)\n", + "failed to allocate initial %s window (%#jx-%#jx,%#jx)\n", w->name, start, end, count); return (error); } @@ -1432,9 +1433,9 @@ */ if (bootverbose) device_printf(sc->dev, - "attempting to grow %s window for (%#lx-%#lx,%#lx)\n", + "attempting to grow %s window for (%#jx-%#jx,%#jx)\n", w->name, start, end, count); - align = 1ul << RF_ALIGNMENT(flags); + align = (uintmax_t)1 << RF_ALIGNMENT(flags); if (start < w->base) { if (rman_first_free_region(&w->rman, &start_free, &end_free) != 0 || start_free != w->base) @@ -1456,7 +1457,7 @@ */ if (front >= start && front <= end_free) { if (bootverbose) - printf("\tfront candidate range: %#lx-%#lx\n", + printf("\tfront candidate range: %#jx-%#jx\n", front, end_free); front &= ~wmask; front = w->base - front; @@ -1484,7 +1485,7 @@ */ if (back <= end && start_free <= back) { if (bootverbose) - printf("\tback candidate range: %#lx-%#lx\n", + printf("\tback candidate range: %#jx-%#jx\n", start_free, back); back |= wmask; back -= w->limit; @@ -1534,7 +1535,7 @@ */ struct resource * pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct pcib_softc *sc; struct resource *r; @@ -1623,7 +1624,7 @@ int pcib_adjust_resource(device_t bus, device_t child, int type, struct resource *r, - u_long start, u_long end) + uintmax_t start, uintmax_t end) { struct pcib_softc *sc; @@ -1658,7 +1659,7 @@ */ struct resource * pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct pcib_softc *sc = device_get_softc(dev); const char *name, *suffix; @@ -1708,7 +1709,7 @@ #endif } if (end < start) { - device_printf(dev, "ioport: end (%lx) < start (%lx)\n", + device_printf(dev, "ioport: end (%jx) < start (%jx)\n", end, start); start = 0; end = 0; @@ -1716,13 +1717,13 @@ } if (!ok) { device_printf(dev, "%s%srequested unsupported I/O " - "range 0x%lx-0x%lx (decoding 0x%x-0x%x)\n", + "range 0x%jx-0x%jx (decoding 0x%x-0x%x)\n", name, suffix, start, end, sc->iobase, sc->iolimit); return (NULL); } if (bootverbose) device_printf(dev, - "%s%srequested I/O range 0x%lx-0x%lx: in range\n", + "%s%srequested I/O range 0x%jx-0x%jx: in range\n", name, suffix, start, end); break; @@ -1777,7 +1778,7 @@ #endif } if (end < start) { - device_printf(dev, "memory: end (%lx) < start (%lx)\n", + device_printf(dev, "memory: end (%jx) < start (%jx)\n", end, start); start = 0; end = 0; @@ -1785,7 +1786,7 @@ } if (!ok && bootverbose) device_printf(dev, - "%s%srequested unsupported memory range %#lx-%#lx " + "%s%srequested unsupported memory range %#jx-%#jx " "(decoding %#jx-%#jx, %#jx-%#jx)\n", name, suffix, start, end, (uintmax_t)sc->membase, (uintmax_t)sc->memlimit, @@ -1794,7 +1795,7 @@ return (NULL); if (bootverbose) device_printf(dev,"%s%srequested memory range " - "0x%lx-0x%lx: good\n", + "0x%jx-0x%jx: good\n", name, suffix, start, end); break; Index: sys/dev/pci/pci_private.h =================================================================== --- sys/dev/pci/pci_private.h (revision 290622) +++ sys/dev/pci/pci_private.h (working copy) @@ -103,8 +103,8 @@ int pci_msi_count_method(device_t dev, device_t child); int pci_msix_count_method(device_t dev, device_t child); struct resource *pci_alloc_resource(device_t dev, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, - u_int flags); + int type, int *rid, __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); int pci_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); int pci_activate_resource(device_t dev, device_t child, int type, @@ -149,8 +149,8 @@ pci_addr_t size); struct resource *pci_alloc_multi_resource(device_t dev, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, - u_long num, u_int flags); + int type, int *rid, __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_long num, u_int flags); int pci_iov_attach_method(device_t bus, device_t dev, struct nvlist *pf_schema, struct nvlist *vf_schema); @@ -160,8 +160,8 @@ uint16_t rid, uint16_t vid, uint16_t did); struct resource *pci_vf_alloc_mem_resource(device_t dev, device_t child, - int *rid, u_long start, u_long end, u_long count, - u_int flags); + int *rid, __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); int pci_vf_release_mem_resource(device_t dev, device_t child, int rid, struct resource *r); #endif /* _PCI_PRIVATE_H_ */ Index: sys/dev/pci/pci_subr.c =================================================================== --- sys/dev/pci/pci_subr.c (revision 290622) +++ sys/dev/pci/pci_subr.c (working copy) @@ -178,14 +178,14 @@ } int -pcib_host_res_decodes(struct pcib_host_resources *hr, int type, u_long start, - u_long end, u_int flags) +pcib_host_res_decodes(struct pcib_host_resources *hr, int type, uintmax_t start, + uintmax_t end, u_int flags) { struct resource_list_entry *rle; int rid; if (bootverbose) - device_printf(hr->hr_pcib, "decoding %d %srange %#lx-%#lx\n", + device_printf(hr->hr_pcib, "decoding %d %srange %#jx-%#jx\n", type, flags & RF_PREFETCHABLE ? "prefetchable ": "", start, end); rid = resource_list_add_next(&hr->hr_rl, type, start, end, @@ -201,11 +201,11 @@ struct resource * pcib_host_res_alloc(struct pcib_host_resources *hr, device_t dev, int type, - int *rid, u_long start, u_long end, u_long count, u_int flags) + int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource_list_entry *rle; struct resource *r; - u_long new_start, new_end; + uintmax_t new_start, new_end; if (flags & RF_PREFETCHABLE) KASSERT(type == SYS_RES_MEMORY, @@ -229,8 +229,8 @@ if (((flags & RF_PREFETCHABLE) != 0) != ((rle->flags & RLE_PREFETCH) != 0)) continue; - new_start = ulmax(start, rle->start); - new_end = ulmin(end, rle->end); + new_start = ummax(start, rle->start); + new_end = ummin(end, rle->end); if (new_start > new_end || new_start + count - 1 > new_end || new_start + count < new_start) @@ -240,7 +240,7 @@ if (r != NULL) { if (bootverbose) device_printf(hr->hr_pcib, - "allocated type %d (%#lx-%#lx) for rid %x of %s\n", + "allocated type %d (%#jx-%#jx) for rid %x of %s\n", type, rman_get_start(r), rman_get_end(r), *rid, pcib_child_name(dev)); return (r); @@ -261,7 +261,7 @@ int pcib_host_res_adjust(struct pcib_host_resources *hr, device_t dev, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct resource_list_entry *rle; @@ -329,8 +329,8 @@ } struct resource * -pci_domain_alloc_bus(int domain, device_t dev, int *rid, u_long start, - u_long end, u_long count, u_int flags) +pci_domain_alloc_bus(int domain, device_t dev, int *rid, uintmax_t start, + uintmax_t end, uintmax_t count, u_int flags) { struct pci_domain *d; struct resource *res; @@ -349,7 +349,7 @@ int pci_domain_adjust_bus(int domain, device_t dev, struct resource *r, - u_long start, u_long end) + uintmax_t start, uintmax_t end) { #ifdef INVARIANTS struct pci_domain *d; Index: sys/dev/pci/pcib_private.h =================================================================== --- sys/dev/pci/pcib_private.h (revision 290622) +++ sys/dev/pci/pcib_private.h (working copy) @@ -49,13 +49,13 @@ int pcib_host_res_free(device_t pcib, struct pcib_host_resources *hr); int pcib_host_res_decodes(struct pcib_host_resources *hr, int type, - u_long start, u_long end, u_int flags); + __uintmax_t start, __uintmax_t end, u_int flags); struct resource *pcib_host_res_alloc(struct pcib_host_resources *hr, - device_t dev, int type, int *rid, u_long start, u_long end, - u_long count, u_int flags); + device_t dev, int type, int *rid, __uintmax_t start, + __uintmax_t end, __uintmax_t count, u_int flags); int pcib_host_res_adjust(struct pcib_host_resources *hr, - device_t dev, int type, struct resource *r, u_long start, - u_long end); + device_t dev, int type, struct resource *r, __uintmax_t start, + __uintmax_t end); #endif /* @@ -132,13 +132,13 @@ int slot, int func, uint8_t *busnum); #if defined(NEW_PCIB) && defined(PCI_RES_BUS) struct resource *pci_domain_alloc_bus(int domain, device_t dev, int *rid, - u_long start, u_long end, u_long count, u_int flags); + __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int flags); int pci_domain_adjust_bus(int domain, device_t dev, - struct resource *r, u_long start, u_long end); + struct resource *r, __uintmax_t start, __uintmax_t end); int pci_domain_release_bus(int domain, device_t dev, int rid, struct resource *r); struct resource *pcib_alloc_subbus(struct pcib_secbus *bus, device_t child, - int *rid, u_long start, u_long end, u_long count, + int *rid, __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int flags); void pcib_setup_secbus(device_t dev, struct pcib_secbus *bus, int min_count); @@ -152,10 +152,11 @@ int pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result); int pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value); struct resource *pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags); + __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); #ifdef NEW_PCIB int pcib_adjust_resource(device_t bus, device_t child, int type, - struct resource *r, u_long start, u_long end); + struct resource *r, __uintmax_t start, __uintmax_t end); int pcib_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); #endif Index: sys/dev/pci/pcivar.h =================================================================== --- sys/dev/pci/pcivar.h (revision 290622) +++ sys/dev/pci/pcivar.h (working copy) @@ -402,7 +402,7 @@ * Check if the address range falls within the VGA defined address range(s) */ static __inline int -pci_is_vga_ioport_range(u_long start, u_long end) +pci_is_vga_ioport_range(__uintmax_t start, __uintmax_t end) { return (((start >= 0x3b0 && end <= 0x3bb) || @@ -410,7 +410,7 @@ } static __inline int -pci_is_vga_memory_range(u_long start, u_long end) +pci_is_vga_memory_range(__uintmax_t start, __uintmax_t end) { return ((start >= 0xa0000 && end <= 0xbffff) ? 1 : 0); Index: sys/dev/pci/vga_pci.c =================================================================== --- sys/dev/pci/vga_pci.c (revision 290622) +++ sys/dev/pci/vga_pci.c (working copy) @@ -68,7 +68,8 @@ static struct vga_resource *lookup_res(struct vga_pci_softc *sc, int rid); static struct resource *vga_pci_alloc_resource(device_t dev, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, u_int flags); + int type, int *rid, uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags); static int vga_pci_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); @@ -163,8 +164,8 @@ #endif rid = PCIR_BIOS; - res = vga_pci_alloc_resource(dev, NULL, SYS_RES_MEMORY, &rid, 0ul, - ~0ul, 1, RF_ACTIVE); + res = vga_pci_alloc_resource(dev, NULL, SYS_RES_MEMORY, &rid, 0, + RM_MAX_END, 1, RF_ACTIVE); if (res == NULL) { return (NULL); } @@ -333,7 +334,7 @@ static struct resource * vga_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct vga_resource *vr; Index: sys/dev/ppc/ppc.c =================================================================== --- sys/dev/ppc/ppc.c (revision 290622) +++ sys/dev/ppc/ppc.c (working copy) @@ -1674,7 +1674,7 @@ #endif struct ppc_data *ppc; int error; - u_long port; + uintmax_t port; /* * Allocate the ppc_data structure. @@ -1699,7 +1699,7 @@ next_bios_ppc += 1; if (bootverbose) device_printf(dev, - "parallel port found at 0x%lx\n", port); + "parallel port found at 0x%jx\n", port); } #else if ((next_bios_ppc < BIOS_MAX_PPC) && @@ -1707,7 +1707,7 @@ port = *(BIOS_PORTS + next_bios_ppc++); if (bootverbose) device_printf(dev, - "parallel port found at 0x%lx\n", port); + "parallel port found at 0x%jx\n", port); } else { device_printf(dev, "parallel port not found.\n"); return (ENXIO); @@ -2015,7 +2015,7 @@ */ struct resource * ppc_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ppc_data *ppc = DEVTOSOFTC(bus); Index: sys/dev/ppc/ppcvar.h =================================================================== --- sys/dev/ppc/ppcvar.h (revision 290622) +++ sys/dev/ppc/ppcvar.h (working copy) @@ -41,7 +41,7 @@ int ppc_exec_microseq(device_t, struct ppb_microseq **); struct resource *ppc_alloc_resource(device_t bus, device_t child, int type, - int *rid, u_long start, u_long end, u_long count, u_int flags); + int *rid, __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int flags); int ppc_release_resource(device_t bus, device_t child, int type, int rid, struct resource *r); int ppc_reset_epp(device_t); Index: sys/dev/proto/proto_bus_isa.c =================================================================== --- sys/dev/proto/proto_bus_isa.c (revision 290622) +++ sys/dev/proto/proto_bus_isa.c (working copy) @@ -80,7 +80,7 @@ return (ENODEV); sb = sbuf_new_auto(); - sbuf_printf(sb, "%s:%#lx", proto_isa_prefix, rman_get_start(res)); + sbuf_printf(sb, "%s:%#jx", proto_isa_prefix, rman_get_start(res)); sbuf_finish(sb); device_set_desc_copy(dev, sbuf_data(sb)); sbuf_delete(sb); Index: sys/dev/puc/puc.c =================================================================== --- sys/dev/puc/puc.c (revision 290622) +++ sys/dev/puc/puc.c (working copy) @@ -78,7 +78,7 @@ { struct puc_bar *bar; struct rman *rm; - u_long end, start; + uintmax_t end, start; int error, i; /* Find the BAR entry with the given RID. */ @@ -474,7 +474,7 @@ struct resource * puc_bus_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct puc_port *port; struct resource *res; @@ -495,7 +495,7 @@ return (NULL); /* We only support default allocations. */ - if (start != 0UL || end != ~0UL) + if (start != 0 || end != ~0) return (NULL); if (type == port->p_bar->b_type) @@ -567,11 +567,11 @@ int puc_bus_get_resource(device_t dev, device_t child, int type, int rid, - u_long *startp, u_long *countp) + uintmax_t *startp, uintmax_t *countp) { struct puc_port *port; struct resource *res; - u_long start; + uintmax_t start; /* Get our immediate child. */ while (child != NULL && device_get_parent(child) != dev) Index: sys/dev/puc/puc_bfe.h =================================================================== --- sys/dev/puc/puc_bfe.h (revision 290622) +++ sys/dev/puc/puc_bfe.h (working copy) @@ -85,9 +85,9 @@ int puc_bus_child_location_str(device_t, device_t, char *, size_t); int puc_bus_child_pnpinfo_str(device_t, device_t, char *, size_t); -struct resource *puc_bus_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); -int puc_bus_get_resource(device_t, device_t, int, int, u_long *, u_long *); +struct resource *puc_bus_alloc_resource(device_t, device_t, int, int *, + uintmax_t, uintmax_t, uintmax_t, u_int); +int puc_bus_get_resource(device_t, device_t, int, int, uintmax_t *, uintmax_t *); int puc_bus_print_child(device_t, device_t); int puc_bus_read_ivar(device_t, device_t, int, uintptr_t *); int puc_bus_release_resource(device_t, device_t, int, int, struct resource *); Index: sys/dev/quicc/quicc_bfe.h =================================================================== --- sys/dev/quicc/quicc_bfe.h (revision 290622) +++ sys/dev/quicc/quicc_bfe.h (working copy) @@ -61,8 +61,9 @@ int quicc_bfe_probe(device_t, u_int); struct resource *quicc_bus_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); -int quicc_bus_get_resource(device_t, device_t, int, int, u_long *, u_long *); + uintmax_t, uintmax_t, uintmax_t, u_int); +int quicc_bus_get_resource(device_t, device_t, int, int, + uintmax_t *, uintmax_t *); int quicc_bus_read_ivar(device_t, device_t, int, uintptr_t *); int quicc_bus_release_resource(device_t, device_t, int, int, struct resource *); int quicc_bus_setup_intr(device_t, device_t, struct resource *, int, Index: sys/dev/quicc/quicc_core.c =================================================================== --- sys/dev/quicc/quicc_core.c (revision 290622) +++ sys/dev/quicc/quicc_core.c (working copy) @@ -101,7 +101,7 @@ struct quicc_softc *sc; struct resource_list_entry *rle; const char *sep; - u_long size, start; + uintmax_t size, start; int error; sc = device_get_softc(dev); @@ -254,7 +254,7 @@ struct resource * quicc_bus_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct quicc_device *qd; struct resource_list_entry *rle; @@ -263,7 +263,7 @@ return (NULL); /* We only support default allocations. */ - if (start != 0UL || end != ~0UL) + if (start != 0 || end != ~0) return (NULL); qd = device_get_ivars(child); @@ -284,7 +284,7 @@ int quicc_bus_get_resource(device_t dev, device_t child, int type, int rid, - u_long *startp, u_long *countp) + uintmax_t *startp, uintmax_t *countp) { struct quicc_device *qd; struct resource_list_entry *rle; Index: sys/dev/rc/rc.c =================================================================== --- sys/dev/rc/rc.c (revision 290622) +++ sys/dev/rc/rc.c (working copy) @@ -243,7 +243,7 @@ for (i = 0; i < IOBASE_ADDRS; i++) { x = i; sc->sc_port[i] = bus_alloc_resource(dev, SYS_RES_IOPORT, &x, - 0ul, ~0ul, 0x10, RF_ACTIVE); + 0, ~0, 0x10, RF_ACTIVE); if (x != i) { device_printf(dev, "ioport %d was rid %d\n", i, x); goto fail; Index: sys/dev/sbni/if_sbni_isa.c =================================================================== --- sys/dev/sbni/if_sbni_isa.c (revision 290622) +++ sys/dev/sbni/if_sbni_isa.c (working copy) @@ -87,7 +87,7 @@ sc = device_get_softc(dev); sc->io_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->io_rid, - 0ul, ~0ul, SBNI_PORTS, RF_ACTIVE); + 0, ~0, SBNI_PORTS, RF_ACTIVE); if (!sc->io_res) { printf("sbni: cannot allocate io ports!\n"); return (ENOENT); Index: sys/dev/sbni/if_sbni_pci.c =================================================================== --- sys/dev/sbni/if_sbni_pci.c (revision 290622) +++ sys/dev/sbni/if_sbni_pci.c (working copy) @@ -96,7 +96,7 @@ sc->io_rid = PCIR_BAR(0); sc->io_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->io_rid, - 0ul, ~0ul, ports, RF_ACTIVE); + 0, ~0, ports, RF_ACTIVE); if (!sc->io_res) { device_printf(dev, "cannot allocate io ports!\n"); if (sc->slave_sc) Index: sys/dev/scc/scc_bfe.h =================================================================== --- sys/dev/scc/scc_bfe.h (revision 290622) +++ sys/dev/scc/scc_bfe.h (working copy) @@ -143,8 +143,8 @@ int scc_bfe_probe(device_t dev, u_int regshft, u_int rclk, u_int rid); struct resource *scc_bus_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); -int scc_bus_get_resource(device_t, device_t, int, int, u_long *, u_long *); + __uintmax_t, __uintmax_t, __uintmax_t, u_int); +int scc_bus_get_resource(device_t, device_t, int, int, __uintmax_t *, __uintmax_t *); int scc_bus_read_ivar(device_t, device_t, int, uintptr_t *); int scc_bus_release_resource(device_t, device_t, int, int, struct resource *); int scc_bus_setup_intr(device_t, device_t, struct resource *, int, Index: sys/dev/scc/scc_core.c =================================================================== --- sys/dev/scc/scc_core.c (revision 290622) +++ sys/dev/scc/scc_core.c (working copy) @@ -103,7 +103,7 @@ struct scc_softc *sc, *sc0; const char *sep; bus_space_handle_t bh; - u_long base, size, start, sz; + __uintmax_t base, size, start, sz; int c, error, mode, sysdev; /* @@ -407,7 +407,7 @@ struct resource * scc_bus_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + __uintmax_t start, __uintmax_t end, __uintmax_t count, u_int flags) { struct resource_list_entry *rle; struct scc_chan *ch; @@ -417,7 +417,7 @@ return (NULL); /* We only support default allocations. */ - if (start != 0UL || end != ~0UL) + if (start != 0 || end != ~0) return (NULL); m = device_get_ivars(child); @@ -431,7 +431,7 @@ int scc_bus_get_resource(device_t dev, device_t child, int type, int rid, - u_long *startp, u_long *countp) + __uintmax_t *startp, __uintmax_t *countp) { struct resource_list_entry *rle; struct scc_chan *ch; Index: sys/dev/sdhci/sdhci_pci.c =================================================================== --- sys/dev/sdhci/sdhci_pci.c (revision 290622) +++ sys/dev/sdhci/sdhci_pci.c (working copy) @@ -331,7 +331,7 @@ /* Allocate memory. */ rid = PCIR_BAR(bar + i); sc->mem_res[i] = bus_alloc_resource(dev, SYS_RES_MEMORY, - &rid, 0ul, ~0ul, 0x100, RF_ACTIVE); + &rid, 0, ~0, 0x100, RF_ACTIVE); if (sc->mem_res[i] == NULL) { device_printf(dev, "Can't allocate memory for slot %d\n", i); continue; Index: sys/dev/siba/siba.c =================================================================== --- sys/dev/siba/siba.c (revision 290622) +++ sys/dev/siba/siba.c (working copy) @@ -92,8 +92,8 @@ struct resource *); static device_t siba_add_child(device_t, u_int, const char *, int); static struct resource * - siba_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); + siba_alloc_resource(device_t, device_t, int, int *, uintmax_t, + uintmax_t, uintmax_t, u_int); static int siba_attach(device_t); #ifdef notyet static void siba_destroy_devinfo(struct siba_devinfo *); @@ -371,7 +371,7 @@ static struct resource * siba_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *rv; struct resource_list *rl; @@ -383,7 +383,7 @@ printf("%s: entry\n", __func__); #endif - isdefault = (start == 0UL && end == ~0UL && count == 1); + isdefault = (start == 0 && end == ~0 && count == 1); needactivate = flags & RF_ACTIVE; rl = BUS_GET_RESOURCE_LIST(bus, child); rle = NULL; Index: sys/dev/siba/siba_bwn.c =================================================================== --- sys/dev/siba/siba_bwn.c (revision 290622) +++ sys/dev/siba/siba_bwn.c (working copy) @@ -242,7 +242,7 @@ /* proxying to the parent */ static struct resource * siba_bwn_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { return (BUS_ALLOC_RESOURCE(device_get_parent(dev), dev, Index: sys/dev/siba/siba_pcib.c =================================================================== --- sys/dev/siba/siba_pcib.c (revision 290622) +++ sys/dev/siba/siba_pcib.c (working copy) @@ -92,7 +92,7 @@ int, struct resource *); static struct resource * siba_pcib_alloc_resource(device_t, device_t, int, int *, - u_long , u_long, u_long, u_int); + uintmax_t , uintmax_t, uintmax_t, u_int); static int siba_pcib_attach(device_t); static int siba_pcib_deactivate_resource(device_t, device_t, int, int, struct resource *); @@ -249,7 +249,7 @@ static struct resource * siba_pcib_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { #if 1 Index: sys/dev/siis/siis.c =================================================================== --- sys/dev/siis/siis.c (revision 290622) +++ sys/dev/siis/siis.c (working copy) @@ -314,7 +314,7 @@ static struct resource * siis_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct siis_controller *ctlr = device_get_softc(dev); int unit = ((struct siis_channel *)device_get_softc(child))->unit; Index: sys/dev/snc/if_snc.c =================================================================== --- sys/dev/snc/if_snc.c (revision 290622) +++ sys/dev/snc/if_snc.c (working copy) @@ -73,7 +73,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, SNEC_NREGS, RF_ACTIVE); + 0, ~0, SNEC_NREGS, RF_ACTIVE); if (res) { sc->ioport = res; sc->ioport_rid = rid; @@ -96,7 +96,7 @@ struct resource *res; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, - 0ul, ~0ul, SNEC_NMEMS, RF_ACTIVE); + 0, ~0, SNEC_NMEMS, RF_ACTIVE); if (res) { sc->iomem = res; sc->iomem_rid = rid; Index: sys/dev/snc/if_snc_cbus.c =================================================================== --- sys/dev/snc/if_snc_cbus.c (revision 290622) +++ sys/dev/snc/if_snc_cbus.c (working copy) @@ -72,7 +72,7 @@ { struct isa_device *idev = DEVTOISA(dev); struct isa_config config; - u_long start, count; + uintmax_t start, count; int rid; bzero(&config, sizeof(config)); @@ -148,7 +148,7 @@ bus_set_resource(dev, SYS_RES_IOPORT, rid, port, SNEC_NREGS); res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, SNEC_NREGS, + 0, ~0, SNEC_NREGS, 0 /* !RF_ACTIVE */); if (res) break; } Index: sys/dev/sound/isa/ad1816.c =================================================================== --- sys/dev/sound/isa/ad1816.c (revision 290622) +++ sys/dev/sound/isa/ad1816.c (working copy) @@ -624,11 +624,11 @@ goto no; } if (ad1816->drq2) - snprintf(status2, SND_STATUSLEN, ":%ld", rman_get_start(ad1816->drq2)); + snprintf(status2, SND_STATUSLEN, ":%jd", rman_get_start(ad1816->drq2)); else status2[0] = '\0'; - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld drq %ld%s bufsz %u %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd drq %jd%s bufsz %u %s", rman_get_start(ad1816->io_base), rman_get_start(ad1816->irq), rman_get_start(ad1816->drq1), Index: sys/dev/sound/isa/ess.c =================================================================== --- sys/dev/sound/isa/ess.c (revision 290622) +++ sys/dev/sound/isa/ess.c (working copy) @@ -867,12 +867,12 @@ } if (sc->drq2) - snprintf(buf, SND_STATUSLEN, ":%ld", rman_get_start(sc->drq2)); + snprintf(buf, SND_STATUSLEN, ":%jd", rman_get_start(sc->drq2)); else buf[0] = '\0'; - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld drq %ld%s bufsz %u %s", - rman_get_start(sc->io_base), rman_get_start(sc->irq), + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd drq %jd%s bufsz %u %s", + rman_get_start(sc->io_base), rman_get_start(sc->irq), rman_get_start(sc->drq1), buf, sc->bufsize, PCM_KLDSTRING(snd_ess)); Index: sys/dev/sound/isa/gusc.c =================================================================== --- sys/dev/sound/isa/gusc.c (revision 290622) +++ sys/dev/sound/isa/gusc.c (working copy) @@ -91,7 +91,7 @@ static int gusisa_probe(device_t dev); static void gusc_intr(void *); static struct resource *gusc_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags); + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags); static int gusc_release_resource(device_t bus, device_t child, int type, int rid, struct resource *r); @@ -350,7 +350,7 @@ static struct resource * gusc_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { sc_p scp; int *alloced, rid_max, alloced_max; Index: sys/dev/sound/isa/mss.c =================================================================== --- sys/dev/sound/isa/mss.c (revision 290622) +++ sys/dev/sound/isa/mss.c (working copy) @@ -1325,7 +1325,7 @@ } tmp &= 0x3f; if (!(tmp == 0x04 || tmp == 0x0f || tmp == 0x00 || tmp == 0x05)) { - BVDDB(printf("No MSS signature detected on port 0x%lx (0x%x)\n", + BVDDB(printf("No MSS signature detected on port 0x%jx (0x%x)\n", rman_get_start(mss->io_base), tmpx)); goto no; } @@ -1766,7 +1766,7 @@ else status2[0] = '\0'; - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld drq %d%s bufsz %u", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd drq %d%s bufsz %u", rman_get_start(mss->io_base), rman_get_start(mss->irq), pdma, status2, mss->bufsize); if (pcm_register(dev, mss, 1, 1)) goto no; Index: sys/dev/sound/isa/sb16.c =================================================================== --- sys/dev/sound/isa/sb16.c (revision 290622) +++ sys/dev/sound/isa/sb16.c (working copy) @@ -854,11 +854,11 @@ } if (!(pcm_getflags(dev) & SD_F_SIMPLEX)) - snprintf(status2, SND_STATUSLEN, ":%ld", rman_get_start(sb->drq2)); + snprintf(status2, SND_STATUSLEN, ":%jd", rman_get_start(sb->drq2)); else status2[0] = '\0'; - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld drq %ld%s bufsz %u %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd drq %jd%s bufsz %u %s", rman_get_start(sb->io_base), rman_get_start(sb->irq), rman_get_start(sb->drq1), status2, sb->bufsize, PCM_KLDSTRING(snd_sb16)); Index: sys/dev/sound/isa/sb8.c =================================================================== --- sys/dev/sound/isa/sb8.c (revision 290622) +++ sys/dev/sound/isa/sb8.c (working copy) @@ -749,7 +749,7 @@ goto no; } - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld drq %ld bufsz %u %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd drq %jd bufsz %u %s", rman_get_start(sb->io_base), rman_get_start(sb->irq), rman_get_start(sb->drq), sb->bufsize, PCM_KLDSTRING(snd_sb8)); Index: sys/dev/sound/isa/sbc.c =================================================================== --- sys/dev/sound/isa/sbc.c (revision 290622) +++ sys/dev/sound/isa/sbc.c (working copy) @@ -80,7 +80,7 @@ static void sbc_intr(void *p); static struct resource *sbc_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags); + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags); static int sbc_release_resource(device_t bus, device_t child, int type, int rid, struct resource *r); static int sbc_setup_intr(device_t dev, device_t child, struct resource *irq, @@ -573,7 +573,7 @@ static struct resource * sbc_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct sbc_softc *scp; int *alloced, rid_max, alloced_max; Index: sys/dev/sound/pci/als4000.c =================================================================== --- sys/dev/sound/pci/als4000.c (revision 290622) +++ sys/dev/sound/pci/als4000.c (working copy) @@ -848,7 +848,7 @@ pcm_addchan(dev, PCMDIR_PLAY, &alspchan_class, sc); pcm_addchan(dev, PCMDIR_REC, &alsrchan_class, sc); - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd %s", rman_get_start(sc->reg), rman_get_start(sc->irq),PCM_KLDSTRING(snd_als4000)); pcm_setstatus(dev, status); return 0; Index: sys/dev/sound/pci/atiixp.c =================================================================== --- sys/dev/sound/pci/atiixp.c (revision 290622) +++ sys/dev/sound/pci/atiixp.c (working copy) @@ -1097,7 +1097,7 @@ "polling", CTLTYPE_INT | CTLFLAG_RW, sc->dev, sizeof(sc->dev), sysctl_atiixp_polling, "I", "Enable polling mode"); - snprintf(status, SND_STATUSLEN, "at memory 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at memory 0x%jx irq %jd %s", rman_get_start(sc->reg), rman_get_start(sc->irq), PCM_KLDSTRING(snd_atiixp)); Index: sys/dev/sound/pci/aureal.c =================================================================== --- sys/dev/sound/pci/aureal.c (revision 290622) +++ sys/dev/sound/pci/aureal.c (working copy) @@ -645,7 +645,7 @@ goto bad; } - snprintf(status, SND_STATUSLEN, "at %s 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at %s 0x%jx irq %jd %s", (type[0] == SYS_RES_IOPORT)? "io" : "memory", rman_get_start(reg[0]), rman_get_start(irq),PCM_KLDSTRING(snd_aureal)); Index: sys/dev/sound/pci/cmi.c =================================================================== --- sys/dev/sound/pci/cmi.c (revision 290622) +++ sys/dev/sound/pci/cmi.c (working copy) @@ -995,7 +995,7 @@ pcm_addchan(dev, PCMDIR_PLAY, &cmichan_class, sc); pcm_addchan(dev, PCMDIR_REC, &cmichan_class, sc); - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd %s", rman_get_start(sc->reg), rman_get_start(sc->irq),PCM_KLDSTRING(snd_cmi)); pcm_setstatus(dev, status); Index: sys/dev/sound/pci/cs4281.c =================================================================== --- sys/dev/sound/pci/cs4281.c (revision 290622) +++ sys/dev/sound/pci/cs4281.c (working copy) @@ -850,7 +850,7 @@ pcm_addchan(dev, PCMDIR_PLAY, &cs4281chan_class, sc); pcm_addchan(dev, PCMDIR_REC, &cs4281chan_class, sc); - snprintf(status, SND_STATUSLEN, "at %s 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at %s 0x%jx irq %jd %s", (sc->regtype == SYS_RES_IOPORT)? "io" : "memory", rman_get_start(sc->reg), rman_get_start(sc->irq),PCM_KLDSTRING(snd_cs4281)); pcm_setstatus(dev, status); Index: sys/dev/sound/pci/csa.c =================================================================== --- sys/dev/sound/pci/csa.c (revision 290622) +++ sys/dev/sound/pci/csa.c (working copy) @@ -81,7 +81,8 @@ static int csa_probe(device_t dev); static int csa_attach(device_t dev); static struct resource *csa_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags); + uintmax_t start, uintmax_t end, + uintmax_t count, u_int flags); static int csa_release_resource(device_t bus, device_t child, int type, int rid, struct resource *r); static int csa_setup_intr(device_t bus, device_t child, @@ -396,7 +397,7 @@ static struct resource * csa_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { sc_p scp; csa_res *resp; Index: sys/dev/sound/pci/csapcm.c =================================================================== --- sys/dev/sound/pci/csapcm.c (revision 290622) +++ sys/dev/sound/pci/csapcm.c (working copy) @@ -821,7 +821,7 @@ return (ENXIO); } - snprintf(status, SND_STATUSLEN, "at irq %ld %s", + snprintf(status, SND_STATUSLEN, "at irq %jd %s", rman_get_start(resp->irq),PCM_KLDSTRING(snd_csa)); /* Enable interrupt. */ Index: sys/dev/sound/pci/ds1.c =================================================================== --- sys/dev/sound/pci/ds1.c (revision 290622) +++ sys/dev/sound/pci/ds1.c (working copy) @@ -1010,7 +1010,7 @@ goto bad; } - snprintf(status, SND_STATUSLEN, "at memory 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at memory 0x%jx irq %jd %s", rman_get_start(sc->reg), rman_get_start(sc->irq),PCM_KLDSTRING(snd_ds1)); if (pcm_register(dev, sc, DS1_CHANS, 2)) Index: sys/dev/sound/pci/emu10k1.c =================================================================== --- sys/dev/sound/pci/emu10k1.c (revision 290622) +++ sys/dev/sound/pci/emu10k1.c (working copy) @@ -2132,7 +2132,7 @@ goto bad; } - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd %s", rman_get_start(sc->reg), rman_get_start(sc->irq), PCM_KLDSTRING(snd_emu10k1)); Index: sys/dev/sound/pci/emu10kx.c =================================================================== --- sys/dev/sound/pci/emu10kx.c (revision 290622) +++ sys/dev/sound/pci/emu10kx.c (working copy) @@ -3225,7 +3225,7 @@ device_printf(dev, "unable to create control device\n"); goto bad; } - snprintf(status, 255, "rev %d at io 0x%lx irq %ld", sc->rev, rman_get_start(sc->reg), rman_get_start(sc->irq)); + snprintf(status, 255, "rev %d at io 0x%jx irq %jd", sc->rev, rman_get_start(sc->reg), rman_get_start(sc->irq)); /* Voices */ for (i = 0; i < NUM_G; i++) { Index: sys/dev/sound/pci/envy24.c =================================================================== --- sys/dev/sound/pci/envy24.c (revision 290622) +++ sys/dev/sound/pci/envy24.c (working copy) @@ -2599,7 +2599,7 @@ /* set status iformation */ snprintf(status, SND_STATUSLEN, - "at io 0x%lx:%ld,0x%lx:%ld,0x%lx:%ld,0x%lx:%ld irq %ld", + "at io 0x%jx:%jd,0x%jx:%jd,0x%jx:%jd,0x%jx:%jd irq %jd", rman_get_start(sc->cs), rman_get_end(sc->cs) - rman_get_start(sc->cs) + 1, rman_get_start(sc->ddma), Index: sys/dev/sound/pci/envy24ht.c =================================================================== --- sys/dev/sound/pci/envy24ht.c (revision 290622) +++ sys/dev/sound/pci/envy24ht.c (working copy) @@ -2507,7 +2507,7 @@ /* set status iformation */ snprintf(status, SND_STATUSLEN, - "at io 0x%lx:%ld,0x%lx:%ld irq %ld", + "at io 0x%jx:%jd,0x%jx:%jd irq %jd", rman_get_start(sc->cs), rman_get_end(sc->cs) - rman_get_start(sc->cs) + 1, rman_get_start(sc->mt), Index: sys/dev/sound/pci/es137x.c =================================================================== --- sys/dev/sound/pci/es137x.c (revision 290622) +++ sys/dev/sound/pci/es137x.c (working copy) @@ -1856,7 +1856,7 @@ goto bad; } - snprintf(status, SND_STATUSLEN, "at %s 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at %s 0x%jx irq %jd %s", (es->regtype == SYS_RES_IOPORT)? "io" : "memory", rman_get_start(es->reg), rman_get_start(es->irq), PCM_KLDSTRING(snd_es137x)); Index: sys/dev/sound/pci/fm801.c =================================================================== --- sys/dev/sound/pci/fm801.c (revision 290622) +++ sys/dev/sound/pci/fm801.c (working copy) @@ -639,7 +639,7 @@ goto oops; } - snprintf(status, 64, "at %s 0x%lx irq %ld %s", + snprintf(status, 64, "at %s 0x%jx irq %jd %s", (fm801->regtype == SYS_RES_IOPORT)? "io" : "memory", rman_get_start(fm801->reg), rman_get_start(fm801->irq),PCM_KLDSTRING(snd_fm801)); @@ -716,7 +716,8 @@ static struct resource * fm801_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct fm801_info *fm801; Index: sys/dev/sound/pci/hdspe-pcm.c =================================================================== --- sys/dev/sound/pci/hdspe-pcm.c (revision 290622) +++ sys/dev/sound/pci/hdspe-pcm.c (working copy) @@ -668,7 +668,7 @@ scp->chnum++; } - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd %s", rman_get_start(scp->sc->cs), rman_get_start(scp->sc->irq), PCM_KLDSTRING(snd_hdspe)); Index: sys/dev/sound/pci/ich.c =================================================================== --- sys/dev/sound/pci/ich.c (revision 290622) +++ sys/dev/sound/pci/ich.c (working copy) @@ -687,7 +687,7 @@ char status[SND_STATUSLEN]; snprintf(status, SND_STATUSLEN, - "at io 0x%lx, 0x%lx irq %ld bufsz %u %s", + "at io 0x%jx, 0x%jx irq %jd bufsz %u %s", rman_get_start(sc->nambar), rman_get_start(sc->nabmbar), rman_get_start(sc->irq), sc->bufsz,PCM_KLDSTRING(snd_ich)); Index: sys/dev/sound/pci/maestro.c =================================================================== --- sys/dev/sound/pci/maestro.c (revision 290622) +++ sys/dev/sound/pci/maestro.c (working copy) @@ -1917,7 +1917,7 @@ adjust_pchbase(ess->pch, ess->playchns, ess->bufsz); snprintf(status, SND_STATUSLEN, - "port 0x%lx-0x%lx irq %ld at device %d.%d on pci%d", + "port 0x%jx-0x%jx irq %jd at device %d.%d on pci%d", rman_get_start(reg), rman_get_end(reg), rman_get_start(irq), pci_get_slot(dev), pci_get_function(dev), pci_get_bus(dev)); pcm_setstatus(dev, status); Index: sys/dev/sound/pci/maestro3.c =================================================================== --- sys/dev/sound/pci/maestro3.c (revision 290622) +++ sys/dev/sound/pci/maestro3.c (working copy) @@ -1440,7 +1440,7 @@ goto bad; } } - snprintf(status, SND_STATUSLEN, "at %s 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at %s 0x%jx irq %jd %s", (sc->regtype == SYS_RES_IOPORT)? "io" : "memory", rman_get_start(sc->reg), rman_get_start(sc->irq), PCM_KLDSTRING(snd_maestro3)); Index: sys/dev/sound/pci/neomagic.c =================================================================== --- sys/dev/sound/pci/neomagic.c (revision 290622) +++ sys/dev/sound/pci/neomagic.c (working copy) @@ -702,7 +702,7 @@ goto bad; } - snprintf(status, SND_STATUSLEN, "at memory 0x%lx, 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at memory 0x%jx, 0x%jx irq %jd %s", rman_get_start(sc->buf), rman_get_start(sc->reg), rman_get_start(sc->irq),PCM_KLDSTRING(snd_neomagic)); Index: sys/dev/sound/pci/solo.c =================================================================== --- sys/dev/sound/pci/solo.c (revision 290622) +++ sys/dev/sound/pci/solo.c (working copy) @@ -1051,7 +1051,7 @@ if (mixer_init(dev, &solomixer_class, sc)) goto no; - snprintf(status, SND_STATUSLEN, "at io 0x%lx,0x%lx,0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx,0x%jx,0x%jx irq %jd %s", rman_get_start(sc->io), rman_get_start(sc->sb), rman_get_start(sc->vc), rman_get_start(sc->irq),PCM_KLDSTRING(snd_solo)); Index: sys/dev/sound/pci/t4dwave.c =================================================================== --- sys/dev/sound/pci/t4dwave.c (revision 290622) +++ sys/dev/sound/pci/t4dwave.c (working copy) @@ -948,7 +948,7 @@ goto bad; } - snprintf(status, 64, "at io 0x%lx irq %ld %s", + snprintf(status, 64, "at io 0x%jx irq %jd %s", rman_get_start(tr->reg), rman_get_start(tr->irq),PCM_KLDSTRING(snd_t4dwave)); if (pcm_register(dev, tr, dacn, 1)) Index: sys/dev/sound/pci/via8233.c =================================================================== --- sys/dev/sound/pci/via8233.c (revision 290622) +++ sys/dev/sound/pci/via8233.c (working copy) @@ -1348,7 +1348,7 @@ ac97_setextmode(via->codec, ext); } - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd %s", rman_get_start(via->reg), rman_get_start(via->irq), PCM_KLDSTRING(snd_via8233)); Index: sys/dev/sound/pci/via82c686.c =================================================================== --- sys/dev/sound/pci/via82c686.c (revision 290622) +++ sys/dev/sound/pci/via82c686.c (working copy) @@ -590,7 +590,7 @@ NSEGS * sizeof(struct via_dma_op), dma_cb, via, 0) != 0) goto bad; - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd %s", rman_get_start(via->reg), rman_get_start(via->irq), PCM_KLDSTRING(snd_via82c686)); Index: sys/dev/sound/pci/vibes.c =================================================================== --- sys/dev/sound/pci/vibes.c (revision 290622) +++ sys/dev/sound/pci/vibes.c (working copy) @@ -721,9 +721,10 @@ static int sv_attach(device_t dev) { struct sc_info *sc; + uintmax_t count, midi_start, games_start; u_int32_t data; char status[SND_STATUSLEN]; - u_long midi_start, games_start, count, sdmaa, sdmac, ml, mu; + u_long sdmaa, sdmac, ml, mu; sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK | M_ZERO); sc->dev = dev; @@ -815,7 +816,7 @@ ((mu - ml) % 0x200)) { device_printf(dev, "sv_attach: resource assumptions not met " "(midi 0x%08lx, games 0x%08lx)\n", - midi_start, games_start); + (u_long)midi_start, (u_long)games_start); goto fail; } @@ -876,7 +877,7 @@ pcm_addchan(dev, PCMDIR_PLAY, &svpchan_class, sc); pcm_addchan(dev, PCMDIR_REC, &svrchan_class, sc); - snprintf(status, SND_STATUSLEN, "at io 0x%lx irq %ld %s", + snprintf(status, SND_STATUSLEN, "at io 0x%jx irq %jd %s", rman_get_start(sc->enh_reg), rman_get_start(sc->irq),PCM_KLDSTRING(snd_vibes)); pcm_setstatus(dev, status); Index: sys/dev/stg/tmc18c30_subr.c =================================================================== --- sys/dev/stg/tmc18c30_subr.c (revision 290622) +++ sys/dev/stg/tmc18c30_subr.c (working copy) @@ -65,7 +65,7 @@ stg_alloc_resource(device_t dev) { struct stg_softc * sc = device_get_softc(dev); - u_long maddr, msize; + uintmax_t maddr, msize; int error; mtx_init(&sc->sc_sclow.sl_lock, "stg", NULL, MTX_DEF); Index: sys/dev/wl/if_wl.c =================================================================== --- sys/dev/wl/if_wl.c (revision 290622) +++ sys/dev/wl/if_wl.c (working copy) @@ -388,7 +388,7 @@ struct wl_softc *sc; char *str = "wl%d: board out of range [0..%d]\n"; u_char inbuf[100]; - unsigned long junk, sirq; + uintmax_t junk, sirq; int error, irq; error = ISA_PNP_PROBE(device_get_parent(device), device, wl_ids); @@ -495,7 +495,7 @@ } #ifdef WLDEBUG - printf("wlattach: base %lx, unit %d\n", rman_get_start(sc->res_ioport), + printf("wlattach: base %jx, unit %d\n", rman_get_start(sc->res_ioport), device_get_unit(device)); #endif @@ -605,7 +605,7 @@ int ports = 16; /* Number of ports */ sc->res_ioport = bus_alloc_resource(device, SYS_RES_IOPORT, - &sc->rid_ioport, 0ul, ~0ul, ports, RF_ACTIVE); + &sc->rid_ioport, 0, ~0, ports, RF_ACTIVE); if (sc->res_ioport == NULL) goto errexit; Index: sys/dev/xe/if_xe.c =================================================================== --- sys/dev/xe/if_xe.c (revision 290622) +++ sys/dev/xe/if_xe.c (working copy) @@ -1964,7 +1964,7 @@ if (!sc->modem) { sc->port_rid = 0; /* 0 is managed by pccard */ sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, - &sc->port_rid, 0ul, ~0ul, 16, RF_ACTIVE); + &sc->port_rid, 0, ~0, 16, RF_ACTIVE); } else if (sc->dingo) { /* * Find a 16 byte aligned ioport for the card. @@ -1983,7 +1983,7 @@ sc->port_res); start = (rman_get_start(sc->port_res) + 15) & ~0xf; } while (1); - DEVPRINTF(1, (dev, "RealPort port 0x%0lx, size 0x%0lx\n", + DEVPRINTF(1, (dev, "RealPort port 0x%0jx, size 0x%0jx\n", bus_get_resource_start(dev, SYS_RES_IOPORT, sc->port_rid), bus_get_resource_count(dev, SYS_RES_IOPORT, sc->port_rid))); } else if (sc->ce2) { @@ -1998,7 +1998,7 @@ DEVPRINTF(1, (dev, "Finding I/O port for CEM2/CEM3\n")); sc->ce2_port_rid = 0; /* 0 is managed by pccard */ sc->ce2_port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, - &sc->ce2_port_rid, 0ul, ~0ul, 8, RF_ACTIVE); + &sc->ce2_port_rid, 0, ~0, 8, RF_ACTIVE); if (sc->ce2_port_res == NULL) { DEVPRINTF(1, (dev, "Cannot allocate I/O port for modem\n")); @@ -2023,7 +2023,7 @@ sc->port_res); sc->port_res = NULL; } - DEVPRINTF(1, (dev, "CEM2/CEM3 port 0x%0lx, size 0x%0lx\n", + DEVPRINTF(1, (dev, "CEM2/CEM3 port 0x%0jx, size 0x%0jx\n", bus_get_resource_start(dev, SYS_RES_IOPORT, sc->port_rid), bus_get_resource_count(dev, SYS_RES_IOPORT, sc->port_rid))); } Index: sys/dev/xe/if_xe_pccard.c =================================================================== --- sys/dev/xe/if_xe_pccard.c (revision 290622) +++ sys/dev/xe/if_xe_pccard.c (working copy) @@ -140,7 +140,7 @@ DEVPRINTF(2, (dev, "cemfix\n")); - DEVPRINTF(1, (dev, "CEM I/O port 0x%0lx, size 0x%0lx\n", + DEVPRINTF(1, (dev, "CEM I/O port 0x%0jx, size 0x%0jx\n", bus_get_resource_start(dev, SYS_RES_IOPORT, sc->port_rid), bus_get_resource_count(dev, SYS_RES_IOPORT, sc->port_rid))); Index: sys/isa/isa_common.c =================================================================== --- sys/isa/isa_common.c (revision 290622) +++ sys/isa/isa_common.c (working copy) @@ -483,7 +483,7 @@ if (!rle->res) { rid = rle->rid; resource_list_alloc(rl, dev, child, rle->type, &rid, - 0ul, ~0ul, 1, 0); + 0, ~0, 1, 0); } } } @@ -928,7 +928,7 @@ static int isa_set_resource(device_t dev, device_t child, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { struct isa_device* idev = DEVTOISA(child); struct resource_list *rl = &idev->id_resources; Index: sys/isa/isa_common.h =================================================================== --- sys/isa/isa_common.h (revision 290622) +++ sys/isa/isa_common.h (working copy) @@ -69,7 +69,8 @@ */ extern void isa_init(device_t dev); extern struct resource *isa_alloc_resource(device_t bus, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, u_int flags); + int type, int *rid, uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags); extern int isa_release_resource(device_t bus, device_t child, int type, int rid, struct resource *r); Index: sys/kern/bus_if.m =================================================================== --- sys/kern/bus_if.m (revision 290622) +++ sys/kern/bus_if.m (working copy) @@ -44,8 +44,8 @@ CODE { static struct resource * null_alloc_resource(device_t dev, device_t child, - int type, int *rid, u_long start, u_long end, - u_long count, u_int flags) + int type, int *rid, __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags) { return (0); } @@ -247,9 +247,9 @@ * @param _type the type of resource to allocate * @param _rid a pointer to the resource identifier * @param _start hint at the start of the resource range - pass - * @c 0UL for any start address + * @c 0 for any start address * @param _end hint at the end of the resource range - pass - * @c ~0UL for any end address + * @c ~0 for any end address * @param _count hint at the size of range required - pass @c 1 * for any size * @param _flags any extra flags to control the resource @@ -264,9 +264,9 @@ device_t _child; int _type; int *_rid; - u_long _start; - u_long _end; - u_long _count; + __uintmax_t _start; + __uintmax_t _end; + __uintmax_t _count; u_int _flags; } DEFAULT null_alloc_resource; @@ -332,8 +332,8 @@ device_t _child; int _type; struct resource *_res; - u_long _start; - u_long _end; + __uintmax_t _start; + __uintmax_t _end; }; /** @@ -433,8 +433,8 @@ device_t _child; int _type; int _rid; - u_long _start; - u_long _count; + __uintmax_t _start; + __uintmax_t _count; }; /** @@ -457,8 +457,8 @@ device_t _child; int _type; int _rid; - u_long *_startp; - u_long *_countp; + __uintmax_t *_startp; + __uintmax_t *_countp; }; /** Index: sys/kern/init_main.c =================================================================== --- sys/kern/init_main.c (revision 290622) +++ sys/kern/init_main.c (working copy) @@ -103,6 +103,7 @@ struct vmspace vmspace0; struct proc *initproc; +#define VERBOSE_SYSINIT 1 #ifndef BOOTHOWTO #define BOOTHOWTO 0 #endif Index: sys/kern/kern_cons.c =================================================================== --- sys/kern/kern_cons.c (revision 290622) +++ sys/kern/kern_cons.c (working copy) @@ -161,7 +161,7 @@ /* * Release early console. */ - early_putc = NULL; + //early_putc = NULL; #endif } Index: sys/kern/subr_bus.c =================================================================== --- sys/kern/subr_bus.c (revision 290622) +++ sys/kern/subr_bus.c (working copy) @@ -3063,8 +3063,8 @@ * @param count XXX end-start+1 */ int -resource_list_add_next(struct resource_list *rl, int type, u_long start, - u_long end, u_long count) +resource_list_add_next(struct resource_list *rl, int type, uintmax_t start, + uintmax_t end, uintmax_t count) { int rid; @@ -3092,7 +3092,7 @@ */ struct resource_list_entry * resource_list_add(struct resource_list *rl, int type, int rid, - u_long start, u_long end, u_long count) + uintmax_t start, uintmax_t end, uintmax_t count) { struct resource_list_entry *rle; @@ -3236,9 +3236,9 @@ * @param type the type of resource to allocate * @param rid a pointer to the resource identifier * @param start hint at the start of the resource range - pass - * @c 0UL for any start address + * @c 0 for any start address * @param end hint at the end of the resource range - pass - * @c ~0UL for any end address + * @c ~0 for any end address * @param count hint at the size of range required - pass @c 1 * for any size * @param flags any extra flags to control the resource @@ -3250,7 +3250,7 @@ */ struct resource * resource_list_reserve(struct resource_list *rl, device_t bus, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, u_int flags) + int type, int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource_list_entry *rle = NULL; int passthrough = (device_get_parent(child) != bus); @@ -3293,9 +3293,9 @@ * @param type the type of resource to allocate * @param rid a pointer to the resource identifier * @param start hint at the start of the resource range - pass - * @c 0UL for any start address + * @c 0 for any start address * @param end hint at the end of the resource range - pass - * @c ~0UL for any end address + * @c ~0 for any end address * @param count hint at the size of range required - pass @c 1 * for any size * @param flags any extra flags to control the resource @@ -3307,11 +3307,11 @@ */ struct resource * resource_list_alloc(struct resource_list *rl, device_t bus, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, u_int flags) + int type, int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource_list_entry *rle = NULL; int passthrough = (device_get_parent(child) != bus); - int isdefault = (start == 0UL && end == ~0UL); + int isdefault = (start == 0 && end == ~0); if (passthrough) { return (BUS_ALLOC_RESOURCE(device_get_parent(bus), child, @@ -3949,7 +3949,7 @@ */ int bus_generic_adjust_resource(device_t dev, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { /* Propagate up the bus hierarchy until someone handles it. */ if (dev->parent) @@ -3966,7 +3966,7 @@ */ struct resource * bus_generic_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { /* Propagate up the bus hierarchy until someone handles it. */ if (dev->parent) @@ -4104,7 +4104,7 @@ */ int bus_generic_rl_get_resource(device_t dev, device_t child, int type, int rid, - u_long *startp, u_long *countp) + uintmax_t *startp, uintmax_t *countp) { struct resource_list * rl = NULL; struct resource_list_entry * rle = NULL; @@ -4135,7 +4135,7 @@ */ int bus_generic_rl_set_resource(device_t dev, device_t child, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { struct resource_list * rl = NULL; @@ -4203,7 +4203,7 @@ */ struct resource * bus_generic_rl_alloc_resource(device_t dev, device_t child, int type, - int *rid, u_long start, u_long end, u_long count, u_int flags) + int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource_list * rl = NULL; @@ -4289,8 +4289,8 @@ * parent of @p dev. */ struct resource * -bus_alloc_resource(device_t dev, int type, int *rid, u_long start, u_long end, - u_long count, u_int flags) +bus_alloc_resource(device_t dev, int type, int *rid, uintmax_t start, uintmax_t end, + uintmax_t count, u_int flags) { if (dev->parent == NULL) return (NULL); @@ -4305,8 +4305,8 @@ * parent of @p dev. */ int -bus_adjust_resource(device_t dev, int type, struct resource *r, u_long start, - u_long end) +bus_adjust_resource(device_t dev, int type, struct resource *r, uintmax_t start, + uintmax_t end) { if (dev->parent == NULL) return (EINVAL); @@ -4436,7 +4436,7 @@ */ int bus_set_resource(device_t dev, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { return (BUS_SET_RESOURCE(device_get_parent(dev), dev, type, rid, start, count)); @@ -4450,7 +4450,7 @@ */ int bus_get_resource(device_t dev, int type, int rid, - u_long *startp, u_long *countp) + uintmax_t *startp, uintmax_t *countp) { return (BUS_GET_RESOURCE(device_get_parent(dev), dev, type, rid, startp, countp)); @@ -4462,10 +4462,11 @@ * This function simply calls the BUS_GET_RESOURCE() method of the * parent of @p dev and returns the start value. */ -u_long +uintmax_t bus_get_resource_start(device_t dev, int type, int rid) { - u_long start, count; + uintmax_t start; + uintmax_t count; int error; error = BUS_GET_RESOURCE(device_get_parent(dev), dev, type, rid, @@ -4481,10 +4482,11 @@ * This function simply calls the BUS_GET_RESOURCE() method of the * parent of @p dev and returns the count value. */ -u_long +uintmax_t bus_get_resource_count(device_t dev, int type, int rid) { - u_long start, count; + uintmax_t start; + uintmax_t count; int error; error = BUS_GET_RESOURCE(device_get_parent(dev), dev, type, rid, Index: sys/kern/subr_rman.c =================================================================== --- sys/kern/subr_rman.c (revision 290622) +++ sys/kern/subr_rman.c (working copy) @@ -90,8 +90,8 @@ TAILQ_ENTRY(resource_i) r_link; LIST_ENTRY(resource_i) r_sharelink; LIST_HEAD(, resource_i) *r_sharehead; - u_long r_start; /* index of the first entry in this resource */ - u_long r_end; /* index of the last entry (inclusive) */ + uintmax_t r_start; /* index of the first entry in this resource */ + uintmax_t r_end; /* index of the last entry (inclusive) */ u_int r_flags; void *r_virtual; /* virtual address of this resource */ struct device *r_dev; /* device which has allocated this resource */ @@ -135,7 +135,7 @@ } if (rm->rm_start == 0 && rm->rm_end == 0) - rm->rm_end = ~0ul; + rm->rm_end = RM_MAX_END; if (rm->rm_type == RMAN_UNINIT) panic("rman_init"); if (rm->rm_type == RMAN_GAUGE) @@ -154,12 +154,12 @@ } int -rman_manage_region(struct rman *rm, u_long start, u_long end) +rman_manage_region(struct rman *rm, uintmax_t start, uintmax_t end) { struct resource_i *r, *s, *t; int rv = 0; - DPRINTF(("rman_manage_region: <%s> request: start %#lx, end %#lx\n", + DPRINTF(("rman_manage_region: <%s> request: start %#jx, end %#jx\n", rm->rm_descr, start, end)); if (start < rm->rm_start || end > rm->rm_end) return EINVAL; @@ -174,7 +174,7 @@ /* Skip entries before us. */ TAILQ_FOREACH(s, &rm->rm_list, r_link) { - if (s->r_end == ULONG_MAX) + if (s->r_end == RM_MAX_END) break; if (s->r_end + 1 >= r->r_start) break; @@ -274,7 +274,7 @@ } int -rman_first_free_region(struct rman *rm, u_long *start, u_long *end) +rman_first_free_region(struct rman *rm, uintmax_t *start, uintmax_t *end) { struct resource_i *r; @@ -292,7 +292,7 @@ } int -rman_last_free_region(struct rman *rm, u_long *start, u_long *end) +rman_last_free_region(struct rman *rm, uintmax_t *start, uintmax_t *end) { struct resource_i *r; @@ -311,7 +311,7 @@ /* Shrink or extend one or both ends of an allocated resource. */ int -rman_adjust_resource(struct resource *rr, u_long start, u_long end) +rman_adjust_resource(struct resource *rr, uintmax_t start, uintmax_t end) { struct resource_i *r, *s, *t, *new; struct rman *rm; @@ -434,18 +434,18 @@ #define SHARE_TYPE(f) (f & (RF_SHAREABLE | RF_PREFETCHABLE)) struct resource * -rman_reserve_resource_bound(struct rman *rm, u_long start, u_long end, - u_long count, u_long bound, u_int flags, +rman_reserve_resource_bound(struct rman *rm, uintmax_t start, uintmax_t end, + uintmax_t count, uintmax_t bound, u_int flags, struct device *dev) { u_int new_rflags; struct resource_i *r, *s, *rv; - u_long rstart, rend, amask, bmask; + uintmax_t rstart, rend, amask, bmask; rv = NULL; - DPRINTF(("rman_reserve_resource_bound: <%s> request: [%#lx, %#lx], " - "length %#lx, flags %u, device %s\n", rm->rm_descr, start, end, + DPRINTF(("rman_reserve_resource_bound: <%s> request: [%#jx, %#jx], " + "length %#jx, flags %x, device %s\n", rm->rm_descr, start, end, count, flags, dev == NULL ? "" : device_get_nameunit(dev))); KASSERT((flags & RF_FIRSTSHARE) == 0, @@ -454,10 +454,20 @@ mtx_lock(rm->rm_mtx); + r = TAILQ_FIRST(&rm->rm_list); + if (r == NULL) { + DPRINTF(("NULL list head\n")); + } else { + DPRINTF(("rman_reserve_resource_bound: trying %#jx <%#jx,%#jx>\n", + r->r_end, start, count-1)); + } for (r = TAILQ_FIRST(&rm->rm_list); r && r->r_end < start + count - 1; - r = TAILQ_NEXT(r, r_link)) + r = TAILQ_NEXT(r, r_link)) { ; + DPRINTF(("rman_reserve_resource_bound: tried %#jx <%#jx,%#jx>\n", + r->r_end, start, count-1)); + } if (r == NULL) { DPRINTF(("could not find a region\n")); @@ -464,9 +474,9 @@ goto out; } - amask = (1ul << RF_ALIGNMENT(flags)) - 1; - KASSERT(start <= ULONG_MAX - amask, - ("start (%#lx) + amask (%#lx) would wrap around", start, amask)); + amask = (1ull << RF_ALIGNMENT(flags)) - 1; + KASSERT(start <= BUS_SPACE_MAXADDR - amask, + ("start (%#jx) + amask (%#jx) would wrap around", start, amask)); /* If bound is 0, bmask will also be 0 */ bmask = ~(bound - 1); @@ -474,18 +484,18 @@ * First try to find an acceptable totally-unshared region. */ for (s = r; s; s = TAILQ_NEXT(s, r_link)) { - DPRINTF(("considering [%#lx, %#lx]\n", s->r_start, s->r_end)); + DPRINTF(("considering [%#jx, %#jx]\n", s->r_start, s->r_end)); /* * The resource list is sorted, so there is no point in * searching further once r_start is too large. */ if (s->r_start > end - (count - 1)) { - DPRINTF(("s->r_start (%#lx) + count - 1> end (%#lx)\n", + DPRINTF(("s->r_start (%#jx) + count - 1> end (%#jx)\n", s->r_start, end)); break; } - if (s->r_start > ULONG_MAX - amask) { - DPRINTF(("s->r_start (%#lx) + amask (%#lx) too large\n", + if (s->r_start > BUS_SPACE_MAXADDR - amask) { + DPRINTF(("s->r_start (%#jx) + amask (%#jx) too large\n", s->r_start, amask)); break; } @@ -493,7 +503,7 @@ DPRINTF(("region is allocated\n")); continue; } - rstart = ulmax(s->r_start, start); + rstart = ummax(s->r_start, start); /* * Try to find a region by adjusting to boundary and alignment * until both conditions are satisfied. This is not an optimal @@ -505,16 +515,16 @@ rstart += bound - (rstart & ~bmask); } while ((rstart & amask) != 0 && rstart < end && rstart < s->r_end); - rend = ulmin(s->r_end, ulmax(rstart + count - 1, end)); + rend = ummin(s->r_end, ummax(rstart + count - 1, end)); if (rstart > rend) { DPRINTF(("adjusted start exceeds end\n")); continue; } - DPRINTF(("truncated region: [%#lx, %#lx]; size %#lx (requested %#lx)\n", + DPRINTF(("truncated region: [%#jx, %#jx]; size %#jx (requested %#jx)\n", rstart, rend, (rend - rstart + 1), count)); if ((rend - rstart + 1) >= count) { - DPRINTF(("candidate region: [%#lx, %#lx], size %#lx\n", + DPRINTF(("candidate region: [%#jx, %#jx], size %#jx\n", rstart, rend, (rend - rstart + 1))); if ((s->r_end - s->r_start + 1) == count) { DPRINTF(("candidate region is entire chunk\n")); @@ -545,7 +555,7 @@ if (s->r_start < rv->r_start && s->r_end > rv->r_end) { DPRINTF(("splitting region in three parts: " - "[%#lx, %#lx]; [%#lx, %#lx]; [%#lx, %#lx]\n", + "[%#jx, %#jx]; [%#jx, %#jx]; [%#jx, %#jx]\n", s->r_start, rv->r_start - 1, rv->r_start, rv->r_end, rv->r_end + 1, s->r_end)); @@ -641,8 +651,8 @@ } struct resource * -rman_reserve_resource(struct rman *rm, u_long start, u_long end, u_long count, - u_int flags, struct device *dev) +rman_reserve_resource(struct rman *rm, uintmax_t start, uintmax_t end, + uintmax_t count, u_int flags, struct device *dev) { return (rman_reserve_resource_bound(rm, start, end, count, 0, flags, @@ -803,13 +813,13 @@ } void -rman_set_start(struct resource *r, u_long start) +rman_set_start(struct resource *r, uintmax_t start) { r->__r_i->r_start = start; } -u_long +uintmax_t rman_get_start(struct resource *r) { @@ -817,13 +827,13 @@ } void -rman_set_end(struct resource *r, u_long end) +rman_set_end(struct resource *r, uintmax_t end) { r->__r_i->r_end = end; } -u_long +uintmax_t rman_get_end(struct resource *r) { @@ -830,7 +840,7 @@ return (r->__r_i->r_end); } -u_long +uintmax_t rman_get_size(struct resource *r) { @@ -1032,8 +1042,8 @@ if (db_pager_quit) return; - db_printf("rman %p: %s (0x%lx-0x%lx full range)\n", - rm, rm->rm_descr, rm->rm_start, rm->rm_end); + db_printf("rman %p: %s (0x%jx-0x%jx full range)\n", + rm, rm->rm_descr, (uintmax_t)rm->rm_start, (uintmax_t)rm->rm_end); } static void @@ -1051,7 +1061,7 @@ devname = "nomatch"; } else devname = NULL; - db_printf(" 0x%lx-0x%lx (RID=%d) ", + db_printf(" 0x%jx-0x%jx (RID=%d) ", r->r_start, r->r_end, r->r_rid); if (devname != NULL) db_printf("(%s)\n", devname); Index: sys/mips/adm5120/admpci.c =================================================================== --- sys/mips/adm5120/admpci.c (revision 290622) +++ sys/mips/adm5120/admpci.c (working copy) @@ -356,7 +356,7 @@ static struct resource * admpci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { return (NULL); Index: sys/mips/adm5120/obio.c =================================================================== --- sys/mips/adm5120/obio.c (revision 290622) +++ sys/mips/adm5120/obio.c (working copy) @@ -103,8 +103,8 @@ struct resource *); static device_t obio_add_child(device_t, u_int, const char *, int); static struct resource * - obio_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); + obio_alloc_resource(device_t, device_t, int, int *, uintmax_t, + uintmax_t, uintmax_t, u_int); static int obio_attach(device_t); static int obio_deactivate_resource(device_t, device_t, int, int, struct resource *); @@ -222,7 +222,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct obio_softc *sc = device_get_softc(bus); struct obio_ivar *ivar = device_get_ivars(child); Index: sys/mips/alchemy/obio.c =================================================================== --- sys/mips/alchemy/obio.c (revision 290622) +++ sys/mips/alchemy/obio.c (working copy) @@ -103,8 +103,8 @@ struct resource *); static device_t obio_add_child(device_t, u_int, const char *, int); static struct resource * - obio_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); + obio_alloc_resource(device_t, device_t, int, int *, uintmax_t, + uintmax_t, uintmax_t, u_int); static int obio_attach(device_t); static int obio_deactivate_resource(device_t, device_t, int, int, struct resource *); @@ -223,7 +223,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct obio_softc *sc = device_get_softc(bus); struct obio_ivar *ivar = device_get_ivars(child); @@ -232,7 +232,7 @@ struct rman *rm; int isdefault, needactivate, passthrough; - isdefault = (start == 0UL && end == ~0UL && count == 1); + isdefault = (start == 0 && end == ~0 && count == 1); needactivate = flags & RF_ACTIVE; passthrough = (device_get_parent(child) != bus); rle = NULL; Index: sys/mips/atheros/apb.c =================================================================== --- sys/mips/atheros/apb.c (revision 290622) +++ sys/mips/atheros/apb.c (working copy) @@ -63,8 +63,8 @@ struct resource *); static device_t apb_add_child(device_t, u_int, const char *, int); static struct resource * - apb_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); + apb_alloc_resource(device_t, device_t, int, int *, uintmax_t, + uintmax_t, uintmax_t, u_int); static int apb_attach(device_t); static int apb_deactivate_resource(device_t, device_t, int, int, struct resource *); @@ -161,7 +161,7 @@ static struct resource * apb_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct apb_softc *sc = device_get_softc(bus); struct apb_ivar *ivar = device_get_ivars(child); @@ -170,7 +170,7 @@ struct rman *rm; int isdefault, needactivate, passthrough; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); needactivate = flags & RF_ACTIVE; /* * Pass memory requests to nexus device @@ -178,7 +178,7 @@ passthrough = (device_get_parent(child) != bus); rle = NULL; - dprintf("%s: entry (%p, %p, %d, %d, %p, %p, %ld, %d)\n", + dprintf("%s: entry (%p, %p, %d, %d, %p, %p, %jd, %d)\n", __func__, bus, child, type, *rid, (void *)(intptr_t)start, (void *)(intptr_t)end, count, flags); Index: sys/mips/atheros/ar71xx_pci.c =================================================================== --- sys/mips/atheros/ar71xx_pci.c (revision 290622) +++ sys/mips/atheros/ar71xx_pci.c (working copy) @@ -500,7 +500,7 @@ static struct resource * ar71xx_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ar71xx_pci_softc *sc = device_get_softc(bus); Index: sys/mips/atheros/ar724x_pci.c =================================================================== --- sys/mips/atheros/ar724x_pci.c (revision 290622) +++ sys/mips/atheros/ar724x_pci.c (working copy) @@ -465,7 +465,7 @@ static struct resource * ar724x_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ar71xx_pci_softc *sc = device_get_softc(bus); struct resource *rv; Index: sys/mips/atheros/qca955x_pci.c =================================================================== --- sys/mips/atheros/qca955x_pci.c (revision 290622) +++ sys/mips/atheros/qca955x_pci.c (working copy) @@ -398,7 +398,7 @@ static struct resource * qca955x_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ar71xx_pci_softc *sc = device_get_softc(bus); struct resource *rv; Index: sys/mips/beri/beri_simplebus.c =================================================================== --- sys/mips/beri/beri_simplebus.c (revision 290622) +++ sys/mips/beri/beri_simplebus.c (working copy) @@ -85,7 +85,7 @@ static int simplebus_activate_resource(device_t, device_t, int, int, struct resource *); static struct resource *simplebus_alloc_resource(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); static int simplebus_deactivate_resource(device_t, device_t, int, int, struct resource *); static int simplebus_release_resource(device_t, device_t, int, int, @@ -250,7 +250,7 @@ static struct resource * simplebus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { device_t ic; struct simplebus_devinfo *di; @@ -260,7 +260,7 @@ * Request for the default allocation with a given rid: use resource * list stored in the local device info. */ - if ((start == 0UL) && (end == ~0UL)) { + if ((start == 0) && (end == ~0)) { if ((di = device_get_ivars(child)) == NULL) return (NULL); Index: sys/mips/cavium/ciu.c =================================================================== --- sys/mips/cavium/ciu.c (revision 290622) +++ sys/mips/cavium/ciu.c (working copy) @@ -75,7 +75,8 @@ static int ciu_probe(device_t); static int ciu_attach(device_t); static struct resource *ciu_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, + u_int); static int ciu_setup_intr(device_t, device_t, struct resource *, int, driver_filter_t *, driver_intr_t *, void *, void **); @@ -171,7 +172,7 @@ static struct resource * ciu_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res; struct ciu_softc *sc; Index: sys/mips/cavium/obio.c =================================================================== --- sys/mips/cavium/obio.c (revision 290622) +++ sys/mips/cavium/obio.c (working copy) @@ -119,7 +119,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *rv; struct rman *rm; Index: sys/mips/cavium/octopci.c =================================================================== --- sys/mips/cavium/octopci.c (revision 290622) +++ sys/mips/cavium/octopci.c (working copy) @@ -86,7 +86,8 @@ static int octopci_read_ivar(device_t, device_t, int, uintptr_t *); static struct resource *octopci_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, + uintmax_t, u_int); static int octopci_activate_resource(device_t, device_t, int, int, struct resource *); static int octopci_maxslots(device_t); @@ -231,7 +232,7 @@ static struct resource * octopci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct octopci_softc *sc; struct resource *res; Index: sys/mips/idt/idtpci.c =================================================================== --- sys/mips/idt/idtpci.c (revision 290622) +++ sys/mips/idt/idtpci.c (working copy) @@ -465,7 +465,7 @@ static struct resource * idtpci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct idtpci_softc *sc = device_get_softc(bus); Index: sys/mips/idt/obio.c =================================================================== --- sys/mips/idt/obio.c (revision 290622) +++ sys/mips/idt/obio.c (working copy) @@ -59,8 +59,8 @@ struct resource *); static device_t obio_add_child(device_t, u_int, const char *, int); static struct resource * - obio_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); + obio_alloc_resource(device_t, device_t, int, int *, uintmax_t, + uintmax_t, uintmax_t, u_int); static int obio_attach(device_t); static int obio_deactivate_resource(device_t, device_t, int, int, struct resource *); @@ -156,7 +156,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct obio_softc *sc = device_get_softc(bus); struct obio_ivar *ivar = device_get_ivars(child); @@ -165,7 +165,7 @@ struct rman *rm; int isdefault, needactivate, passthrough; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); needactivate = flags & RF_ACTIVE; passthrough = (device_get_parent(child) != bus); rle = NULL; Index: sys/mips/malta/gt.c =================================================================== --- sys/mips/malta/gt.c (revision 290622) +++ sys/mips/malta/gt.c (working copy) @@ -76,7 +76,7 @@ static struct resource * gt_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, type, rid, start, end, count, flags)); Index: sys/mips/malta/gt_pci.c =================================================================== --- sys/mips/malta/gt_pci.c (revision 290622) +++ sys/mips/malta/gt_pci.c (working copy) @@ -150,7 +150,7 @@ uint32_t, int); static int gt_pci_route_interrupt(device_t pcib, device_t dev, int pin); static struct resource * gt_pci_alloc_resource(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); static void gt_pci_mask_irq(void *source) @@ -631,7 +631,7 @@ static struct resource * gt_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct gt_pci_softc *sc = device_get_softc(bus); struct resource *rv = NULL; Index: sys/mips/malta/obio.c =================================================================== --- sys/mips/malta/obio.c (revision 290622) +++ sys/mips/malta/obio.c (working copy) @@ -111,7 +111,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *rv; struct rman *rm; Index: sys/mips/mips/cpu.c =================================================================== --- sys/mips/mips/cpu.c (revision 290622) +++ sys/mips/mips/cpu.c (working copy) @@ -356,7 +356,8 @@ static int cpu_probe(device_t); static int cpu_attach(device_t); static struct resource *cpu_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, + u_int); static int cpu_setup_intr(device_t, device_t, struct resource *, int, driver_filter_t *f, driver_intr_t *, void *, void **); @@ -429,7 +430,7 @@ static struct resource * cpu_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res; Index: sys/mips/mips/nexus.c =================================================================== --- sys/mips/mips/nexus.c (revision 290622) +++ sys/mips/mips/nexus.c (working copy) @@ -81,22 +81,22 @@ static struct rman mem_rman; static struct resource * - nexus_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); + nexus_alloc_resource(device_t, device_t, int, int *, uintmax_t, + uintmax_t, uintmax_t, u_int); static device_t nexus_add_child(device_t, u_int, const char *, int); static int nexus_attach(device_t); static void nexus_delete_resource(device_t, device_t, int, int); static struct resource_list * nexus_get_reslist(device_t, device_t); -static int nexus_get_resource(device_t, device_t, int, int, u_long *, - u_long *); +static int nexus_get_resource(device_t, device_t, int, int, uintmax_t *, + uintmax_t *); static int nexus_print_child(device_t, device_t); static int nexus_print_all_resources(device_t dev); static int nexus_probe(device_t); static int nexus_release_resource(device_t, device_t, int, int, struct resource *); -static int nexus_set_resource(device_t, device_t, int, int, u_long, - u_long); +static int nexus_set_resource(device_t, device_t, int, int, uintmax_t, + uintmax_t); static int nexus_activate_resource(device_t, device_t, int, int, struct resource *); static int nexus_deactivate_resource(device_t, device_t, int, int, @@ -154,7 +154,7 @@ } mem_rman.rm_start = 0; - mem_rman.rm_end = ~0ul; + mem_rman.rm_end = ~0; mem_rman.rm_type = RMAN_ARRAY; mem_rman.rm_descr = "Memory addresses"; if (rman_init(&mem_rman) != 0 || @@ -236,7 +236,7 @@ */ static struct resource * nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct nexus_device *ndev = DEVTONX(child); struct resource *rv; @@ -244,12 +244,12 @@ struct rman *rm; int isdefault, needactivate, passthrough; - dprintf("%s: entry (%p, %p, %d, %p, %p, %p, %ld, %d)\n", + dprintf("%s: entry (%p, %p, %d, %p, %p, %p, %jd, %d)\n", __func__, bus, child, type, rid, (void *)(intptr_t)start, (void *)(intptr_t)end, count, flags); dprintf("%s: requested rid is %d\n", __func__, *rid); - isdefault = (start == 0UL && end == ~0UL && count == 1); + isdefault = (start == 0 && end == ~0 && count == 1); needactivate = flags & RF_ACTIVE; passthrough = (device_get_parent(child) != bus); rle = NULL; @@ -313,13 +313,13 @@ static int nexus_set_resource(device_t dev, device_t child, int type, int rid, - u_long start, u_long count) + uintmax_t start, uintmax_t count) { struct nexus_device *ndev = DEVTONX(child); struct resource_list *rl = &ndev->nx_resources; struct resource_list_entry *rle; - dprintf("%s: entry (%p, %p, %d, %d, %p, %ld)\n", + dprintf("%s: entry (%p, %p, %d, %d, %p, %jd)\n", __func__, dev, child, type, rid, (void *)(intptr_t)start, count); rle = resource_list_add(rl, type, rid, start, start + count - 1, @@ -332,7 +332,7 @@ static int nexus_get_resource(device_t dev, device_t child, int type, int rid, - u_long *startp, u_long *countp) + uintmax_t *startp, uintmax_t *countp) { struct nexus_device *ndev = DEVTONX(child); struct resource_list *rl = &ndev->nx_resources; Index: sys/mips/nlm/xlp_pci.c =================================================================== --- sys/mips/nlm/xlp_pci.c (revision 290622) +++ sys/mips/nlm/xlp_pci.c (working copy) @@ -433,7 +433,7 @@ if (error) return error; if (rman_get_start(irq) != rman_get_end(irq)) { - device_printf(dev, "Interrupt allocation %lu != %lu\n", + device_printf(dev, "Interrupt allocation %ju != %ju\n", rman_get_start(irq), rman_get_end(irq)); return (EINVAL); } Index: sys/mips/nlm/xlp_simplebus.c =================================================================== --- sys/mips/nlm/xlp_simplebus.c (revision 290622) +++ sys/mips/nlm/xlp_simplebus.c (working copy) @@ -72,7 +72,7 @@ */ static int xlp_simplebus_probe(device_t dev); static struct resource *xlp_simplebus_alloc_resource(device_t, device_t, int, - int *, u_long, u_long, u_long, u_int); + int *, uintmax_t, uintmax_t, uintmax_t, u_int); static int xlp_simplebus_activate_resource(device_t, device_t, int, int, struct resource *); static int xlp_simplebus_setup_intr(device_t, device_t, @@ -116,7 +116,7 @@ panic("xlp_simplebus_init_resources irq_rman"); port_rman.rm_start = 0; - port_rman.rm_end = ~0ul; + port_rman.rm_end = ~0; port_rman.rm_type = RMAN_ARRAY; port_rman.rm_descr = "I/O ports"; if (rman_init(&port_rman) @@ -124,7 +124,7 @@ panic("xlp_simplebus_init_resources port_rman"); mem_rman.rm_start = 0; - mem_rman.rm_end = ~0ul; + mem_rman.rm_end = ~0; mem_rman.rm_type = RMAN_ARRAY; mem_rman.rm_descr = "I/O memory"; if (rman_init(&mem_rman) @@ -132,7 +132,7 @@ panic("xlp_simplebus_init_resources mem_rman"); pci_ecfg_rman.rm_start = 0; - pci_ecfg_rman.rm_end = ~0ul; + pci_ecfg_rman.rm_end = ~0; pci_ecfg_rman.rm_type = RMAN_ARRAY; pci_ecfg_rman.rm_descr = "PCI ECFG IO"; if (rman_init(&pci_ecfg_rman) || rman_manage_region(&pci_ecfg_rman, @@ -140,7 +140,7 @@ panic("xlp_simplebus_init_resources pci_ecfg_rman"); gbu_rman.rm_start = 0; - gbu_rman.rm_end = ~0ul; + gbu_rman.rm_end = ~0; gbu_rman.rm_type = RMAN_ARRAY; gbu_rman.rm_descr = "Flash region"; if (rman_init(&gbu_rman) @@ -174,7 +174,7 @@ static struct resource * xlp_simplebus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct rman *rm; struct resource *rv; @@ -192,7 +192,7 @@ bustag = NULL; if (!passthrough) { - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); if (isdefault) { rle = resource_list_find(&di->rl, type, *rid); if (rle == NULL) @@ -218,7 +218,7 @@ if (j == sc->nranges && sc->nranges != 0) { if (bootverbose) device_printf(bus, "Could not map resource " - "%#lx-%#lx\n", start, end); + "%#jx-%#jx\n", start, end); return (NULL); } } @@ -244,7 +244,7 @@ } else { if (bootverbose) device_printf(bus, "Invalid MEM range" - "%#lx-%#lx\n", start, end); + "%#jx-%#jx\n", start, end); return (NULL); } break; Index: sys/mips/rmi/iodi.c =================================================================== --- sys/mips/rmi/iodi.c (revision 290622) +++ sys/mips/rmi/iodi.c (working copy) @@ -67,7 +67,7 @@ static struct resource * iodi_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, u_int); static int iodi_activate_resource(device_t, device_t, int, int, @@ -126,7 +126,7 @@ static struct resource * iodi_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res = malloc(sizeof(*res), M_DEVBUF, M_WAITOK); const char *name = device_get_name(child); @@ -135,17 +135,17 @@ #ifdef DEBUG switch (type) { case SYS_RES_IRQ: - device_printf(bus, "IRQ resource - for %s %lx-%lx\n", + device_printf(bus, "IRQ resource - for %s %jx-%jx\n", device_get_nameunit(child), start, end); break; case SYS_RES_IOPORT: - device_printf(bus, "IOPORT resource - for %s %lx-%lx\n", + device_printf(bus, "IOPORT resource - for %s %jx-%jx\n", device_get_nameunit(child), start, end); break; case SYS_RES_MEMORY: - device_printf(bus, "MEMORY resource - for %s %lx-%lx\n", + device_printf(bus, "MEMORY resource - for %s %jx-%jx\n", device_get_nameunit(child), start, end); break; } Index: sys/mips/rmi/xlr_pci.c =================================================================== --- sys/mips/rmi/xlr_pci.c (revision 290622) +++ sys/mips/rmi/xlr_pci.c (working copy) @@ -126,7 +126,7 @@ panic("pci_init_resources irq_rman"); port_rman.rm_start = 0; - port_rman.rm_end = ~0ul; + port_rman.rm_end = ~0; port_rman.rm_type = RMAN_ARRAY; port_rman.rm_descr = "I/O ports"; if (rman_init(&port_rman) @@ -134,7 +134,7 @@ panic("pci_init_resources port_rman"); mem_rman.rm_start = 0; - mem_rman.rm_end = ~0ul; + mem_rman.rm_end = ~0; mem_rman.rm_type = RMAN_ARRAY; mem_rman.rm_descr = "I/O memory"; if (rman_init(&mem_rman) @@ -468,7 +468,7 @@ if (error) return error; if (rman_get_start(irq) != rman_get_end(irq)) { - device_printf(dev, "Interrupt allocation %lu != %lu\n", + device_printf(dev, "Interrupt allocation %ju != %ju\n", rman_get_start(irq), rman_get_end(irq)); return (EINVAL); } @@ -516,7 +516,7 @@ static struct resource * xlr_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct rman *rm; struct resource *rv; Index: sys/mips/rt305x/obio.c =================================================================== --- sys/mips/rt305x/obio.c (revision 290622) +++ sys/mips/rt305x/obio.c (working copy) @@ -98,8 +98,8 @@ struct resource *); static device_t obio_add_child(device_t, u_int, const char *, int); static struct resource * - obio_alloc_resource(device_t, device_t, int, int *, u_long, - u_long, u_long, u_int); + obio_alloc_resource(device_t, device_t, int, int *, uintmax_t, + uintmax_t, uintmax_t, u_int); static int obio_attach(device_t); static int obio_deactivate_resource(device_t, device_t, int, int, struct resource *); @@ -269,7 +269,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct obio_softc *sc = device_get_softc(bus); struct obio_ivar *ivar = device_get_ivars(child); @@ -278,7 +278,7 @@ struct rman *rm; int isdefault, needactivate, passthrough; - isdefault = (start == 0UL && end == ~0UL && count == 1); + isdefault = (start == 0 && end == ~0 && count == 1); needactivate = flags & RF_ACTIVE; passthrough = (device_get_parent(child) != bus); rle = NULL; Index: sys/mips/rt305x/rt305x_gpio.c =================================================================== --- sys/mips/rt305x/rt305x_gpio.c (revision 290622) +++ sys/mips/rt305x/rt305x_gpio.c (working copy) @@ -546,7 +546,7 @@ #ifdef notyet static struct resource * rt305x_gpio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct obio_softc *sc = device_get_softc(bus); struct resource *rv; Index: sys/mips/sentry5/obio.c =================================================================== --- sys/mips/sentry5/obio.c (revision 290622) +++ sys/mips/sentry5/obio.c (working copy) @@ -113,7 +113,7 @@ static struct resource * obio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *rv; struct rman *rm; Index: sys/mips/sibyte/sb_zbbus.c =================================================================== --- sys/mips/sibyte/sb_zbbus.c (revision 290622) +++ sys/mips/sibyte/sb_zbbus.c (working copy) @@ -280,7 +280,7 @@ static struct resource * zbbus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res; int intrnum, intsrc, isdefault; @@ -288,7 +288,7 @@ struct resource_list_entry *rle; struct zbbus_devinfo *dinfo; - isdefault = (start == 0UL && end == ~0UL && count == 1); + isdefault = (start == 0 && end == ~0 && count == 1); /* * Our direct child is asking for a default resource allocation. Index: sys/mips/sibyte/sb_zbpci.c =================================================================== --- sys/mips/sibyte/sb_zbpci.c (revision 290622) +++ sys/mips/sibyte/sb_zbpci.c (working copy) @@ -165,7 +165,7 @@ static struct resource * zbpci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource *res; Index: sys/pc98/cbus/pmc.c =================================================================== --- sys/pc98/cbus/pmc.c (revision 290622) +++ sys/pc98/cbus/pmc.c (working copy) @@ -101,7 +101,7 @@ rid = 0; sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, - 0ul, ~0ul, PMC_ISA_PORTSIZE, + 0, ~0, PMC_ISA_PORTSIZE, RF_ACTIVE); if (sc->port_res == NULL) { return (ENOMEM); Index: sys/pc98/pc98/canbus.c =================================================================== --- sys/pc98/pc98/canbus.c (revision 290622) +++ sys/pc98/pc98/canbus.c (working copy) @@ -84,7 +84,7 @@ static int canbus_print_child(device_t, device_t); static device_t canbus_add_child(device_t, u_int, const char *, int); static struct resource * canbus_alloc_resource( - device_t, device_t, int, int *, u_long, u_long, u_long, u_int); + device_t, device_t, int, int *, uintmax_t, uintmax_t, uintmax_t, u_int); static int canbus_activate_resource( device_t, device_t, int, int, struct resource *); static int canbus_deactivate_resource( @@ -92,7 +92,7 @@ static int canbus_release_resource( device_t, device_t, int, int, struct resource *); static int canbus_set_resource ( - device_t, device_t, int, int, u_long, u_long); + device_t, device_t, int, int, uintmax_t, uintmax_t); static void canbus_delete_resource(device_t, device_t, int, int); /* canbus local function */ @@ -254,7 +254,7 @@ static struct resource * canbus_alloc_resource(device_t dev, device_t child, int type, - int *rid, u_long start, u_long end, u_long count, u_int flags) + int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, type, rid, start, end, count, flags)); @@ -286,7 +286,8 @@ static int canbus_set_resource ( - device_t dev, device_t child, int type, int rid, u_long start, u_long count) + device_t dev, device_t child, int type, int rid, uintmax_t start, + uintmax_t count) { struct canbus_device *cbdev = (struct canbus_device *)device_get_ivars(child); Index: sys/powerpc/include/platform.h =================================================================== --- sys/powerpc/include/platform.h (revision 290622) +++ sys/powerpc/include/platform.h (working copy) @@ -39,8 +39,8 @@ #include struct mem_region { - vm_offset_t mr_start; - vm_size_t mr_size; + uint64_t mr_start; + uint64_t mr_size; }; void mem_regions(struct mem_region **, int *, struct mem_region **, int *); Index: sys/powerpc/mpc85xx/isa.c =================================================================== --- sys/powerpc/mpc85xx/isa.c (revision 290622) +++ sys/powerpc/mpc85xx/isa.c (working copy) @@ -52,7 +52,7 @@ struct resource_list *rl = &idev->id_resources; int isdefault, passthrough, rids; - isdefault = (start == 0UL && end == ~0UL) ? 1 : 0; + isdefault = (start == 0 && end == ~0) ? 1 : 0; passthrough = (device_get_parent(child) != bus) ? 1 : 0; if (!passthrough && !isdefault && Index: sys/powerpc/mpc85xx/lbc.c =================================================================== --- sys/powerpc/mpc85xx/lbc.c (revision 290622) +++ sys/powerpc/mpc85xx/lbc.c (working copy) @@ -69,7 +69,7 @@ static int lbc_attach(device_t); static int lbc_shutdown(device_t); static struct resource *lbc_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, u_int); static int lbc_print_child(device_t, device_t); static int lbc_release_resource(device_t, device_t, int, int, struct resource *); @@ -126,7 +126,7 @@ { int n = 15; - if (size == ~0UL) + if (size == ~0) return (0); while (n < 32) { @@ -503,8 +503,8 @@ rm = &sc->sc_rman; rm->rm_type = RMAN_ARRAY; rm->rm_descr = "Local Bus Space"; - rm->rm_start = 0UL; - rm->rm_end = ~0UL; + rm->rm_start = 0; + rm->rm_end = ~0; error = rman_init(rm); if (error) goto fail; @@ -663,7 +663,7 @@ static struct resource * lbc_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct lbc_softc *sc; struct lbc_devinfo *di; @@ -673,7 +673,7 @@ int needactivate; /* We only support default allocations. */ - if (start != 0ul || end != ~0ul) + if (start != 0 || end != ~0) return (NULL); sc = device_get_softc(bus); @@ -712,8 +712,8 @@ res = rman_reserve_resource(rm, start, end, count, flags, child); if (res == NULL) { - device_printf(bus, "failed to reserve resource %#lx - %#lx " - "(%#lx)\n", start, end, count); + device_printf(bus, "failed to reserve resource %#jx - %#jx " + "(%#jx)\n", start, end, count); return (NULL); } @@ -743,8 +743,8 @@ rv = 0; rv += bus_print_child_header(dev, child); - rv += resource_list_print_type(rl, "mem", SYS_RES_MEMORY, "%#lx"); - rv += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld"); + rv += resource_list_print_type(rl, "mem", SYS_RES_MEMORY, "%#jx"); + rv += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%jd"); rv += bus_print_child_footer(dev, child); return (rv); Index: sys/powerpc/ofw/ofw_pci.c =================================================================== --- sys/powerpc/ofw/ofw_pci.c (revision 290622) +++ sys/powerpc/ofw/ofw_pci.c (working copy) @@ -62,8 +62,8 @@ static int ofw_pci_read_ivar(device_t, device_t, int, uintptr_t *); static struct resource * ofw_pci_alloc_resource(device_t bus, - device_t child, int type, int *rid, u_long start, - u_long end, u_long count, u_int flags); + device_t child, int type, int *rid, uintmax_t start, + uintmax_t end, uintmax_t count, u_int flags); static int ofw_pci_release_resource(device_t bus, device_t child, int type, int rid, struct resource *res); static int ofw_pci_activate_resource(device_t bus, device_t child, @@ -72,8 +72,8 @@ device_t child, int type, int rid, struct resource *res); static int ofw_pci_adjust_resource(device_t bus, device_t child, - int type, struct resource *res, u_long start, - u_long end); + int type, struct resource *res, uintmax_t start, + uintmax_t end); /* * pcib interface. @@ -307,7 +307,7 @@ static struct resource * ofw_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ofw_pci_softc *sc; struct resource *rv; @@ -387,10 +387,10 @@ } if (type == SYS_RES_MEMORY || type == SYS_RES_IOPORT) { struct ofw_pci_range *rp; - vm_offset_t start; + vm_paddr_t start; int space; - start = (vm_offset_t)rman_get_start(res); + start = (vm_paddr_t)rman_get_start(res); /* * Map this through the ranges list @@ -419,8 +419,8 @@ } if (bootverbose) - printf("ofw_pci mapdev: start %zx, len %ld\n", start, - rman_get_size(res)); + printf("ofw_pci mapdev: start %jx, len %jd\n", + (uintmax_t)start, rman_get_size(res)); p = pmap_mapdev(start, (vm_size_t)rman_get_size(res)); if (p == NULL) @@ -453,7 +453,7 @@ static int ofw_pci_adjust_resource(device_t bus, device_t child, int type, - struct resource *res, u_long start, u_long end) + struct resource *res, uintmax_t start, uintmax_t end) { struct rman *rm = NULL; struct ofw_pci_softc *sc = device_get_softc(bus); Index: sys/powerpc/powermac/macgpio.c =================================================================== --- sys/powerpc/powermac/macgpio.c (revision 290622) +++ sys/powerpc/powermac/macgpio.c (working copy) @@ -71,7 +71,7 @@ static int macgpio_print_child(device_t dev, device_t child); static void macgpio_probe_nomatch(device_t, device_t); static struct resource *macgpio_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, u_int); static int macgpio_activate_resource(device_t, device_t, int, int, struct resource *); static int macgpio_deactivate_resource(device_t, device_t, int, int, @@ -267,7 +267,8 @@ static struct resource * macgpio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct macgpio_devinfo *dinfo; Index: sys/powerpc/powermac/macio.c =================================================================== --- sys/powerpc/powermac/macio.c (revision 290622) +++ sys/powerpc/powermac/macio.c (working copy) @@ -78,7 +78,8 @@ static int macio_print_child(device_t dev, device_t child); static void macio_probe_nomatch(device_t, device_t); static struct resource *macio_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, + u_int); static int macio_activate_resource(device_t, device_t, int, int, struct resource *); static int macio_deactivate_resource(device_t, device_t, int, int, @@ -479,7 +480,8 @@ static struct resource * macio_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct macio_softc *sc; int needactivate; Index: sys/powerpc/powermac/uninorth.c =================================================================== --- sys/powerpc/powermac/uninorth.c (revision 290622) +++ sys/powerpc/powermac/uninorth.c (working copy) @@ -72,7 +72,8 @@ static int unin_chip_print_child(device_t dev, device_t child); static void unin_chip_probe_nomatch(device_t, device_t); static struct resource *unin_chip_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, + uintmax_t, u_int); static int unin_chip_activate_resource(device_t, device_t, int, int, struct resource *); static int unin_chip_deactivate_resource(device_t, device_t, int, int, @@ -455,7 +456,8 @@ static struct resource * unin_chip_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct unin_chip_softc *sc; int needactivate; @@ -589,7 +591,7 @@ start = (vm_offset_t) rman_get_start(res); if (bootverbose) - printf("unin mapdev: start %zx, len %ld\n", start, + printf("unin mapdev: start %zx, len %jd\n", start, rman_get_size(res)); p = pmap_mapdev(start, (vm_size_t) rman_get_size(res)); Index: sys/powerpc/powerpc/nexus.c =================================================================== --- sys/powerpc/powerpc/nexus.c (revision 290622) +++ sys/powerpc/powerpc/nexus.c (working copy) @@ -189,13 +189,13 @@ { if (type == SYS_RES_MEMORY) { - vm_offset_t start; + vm_paddr_t start; void *p; - start = (vm_offset_t) rman_get_start(r); + start = rman_get_start(r); if (bootverbose) - printf("nexus mapdev: start %zx, len %ld\n", start, - rman_get_size(r)); + printf("nexus mapdev: start %jx, len %jd\n", + (uintmax_t)start, rman_get_size(r)); p = pmap_mapdev(start, (vm_size_t) rman_get_size(r)); if (p == NULL) Index: sys/powerpc/powerpc/platform.c =================================================================== --- sys/powerpc/powerpc/platform.c (revision 290622) +++ sys/powerpc/powerpc/platform.c (working copy) @@ -86,8 +86,8 @@ memr_merge(struct mem_region *from, struct mem_region *to) { vm_offset_t end; - end = ulmax(to->mr_start + to->mr_size, from->mr_start + from->mr_size); - to->mr_start = ulmin(from->mr_start, to->mr_start); + end = ummax(to->mr_start + to->mr_size, from->mr_start + from->mr_size); + to->mr_start = ummin(from->mr_start, to->mr_start); to->mr_size = end - to->mr_start; } Index: sys/powerpc/psim/ata_iobus.c =================================================================== --- sys/powerpc/psim/ata_iobus.c (revision 290622) +++ sys/powerpc/psim/ata_iobus.c (working copy) @@ -59,7 +59,8 @@ static int ata_iobus_probe(device_t dev); static int ata_iobus_print_child(device_t dev, device_t child); struct resource *ata_iobus_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, + u_int); static int ata_iobus_release_resource(device_t, device_t, int, int, struct resource *); @@ -135,7 +136,8 @@ struct resource * ata_iobus_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct resource *res = NULL; int myrid; Index: sys/powerpc/psim/iobus.c =================================================================== --- sys/powerpc/psim/iobus.c (revision 290622) +++ sys/powerpc/psim/iobus.c (working copy) @@ -72,7 +72,8 @@ static int iobus_read_ivar(device_t, device_t, int, uintptr_t *); static int iobus_write_ivar(device_t, device_t, int, uintptr_t); static struct resource *iobus_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, + u_int); static int iobus_activate_resource(device_t, device_t, int, int, struct resource *); static int iobus_deactivate_resource(device_t, device_t, int, int, @@ -305,7 +306,8 @@ static struct resource * iobus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct iobus_softc *sc; int needactivate; Index: sys/sparc64/central/central.c =================================================================== --- sys/sparc64/central/central.c (revision 290622) +++ sys/sparc64/central/central.c (working copy) @@ -183,8 +183,8 @@ static int central_adjust_resource(device_t bus __unused, device_t child __unused, - int type __unused, struct resource *r __unused, u_long start __unused, - u_long end __unused) + int type __unused, struct resource *r __unused, uintmax_t start __unused, + uintmax_t end __unused) { return (ENXIO); @@ -215,7 +215,7 @@ static struct resource * central_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource_list *rl; struct resource_list_entry *rle; @@ -228,7 +228,7 @@ int passthrough; int i; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); passthrough = (device_get_parent(child) != bus); res = NULL; rle = NULL; Index: sys/sparc64/ebus/ebus.c =================================================================== --- sys/sparc64/ebus/ebus.c (revision 290622) +++ sys/sparc64/ebus/ebus.c (working copy) @@ -427,7 +427,7 @@ static struct resource * ebus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ebus_softc *sc; struct resource_list *rl; @@ -438,7 +438,7 @@ uint64_t cend, cstart, offset; int i, isdefault, passthrough, ridx; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); passthrough = (device_get_parent(child) != bus); sc = device_get_softc(bus); rl = BUS_GET_RESOURCE_LIST(bus, child); @@ -544,8 +544,8 @@ static int ebus_adjust_resource(device_t bus __unused, device_t child __unused, - int type __unused, struct resource *res __unused, u_long start __unused, - u_long end __unused) + int type __unused, struct resource *res __unused, uintmax_t start __unused, + uintmax_t end __unused) { return (ENXIO); Index: sys/sparc64/fhc/fhc.c =================================================================== --- sys/sparc64/fhc/fhc.c (revision 290622) +++ sys/sparc64/fhc/fhc.c (working copy) @@ -420,7 +420,7 @@ static struct resource * fhc_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource_list *rl; struct resource_list_entry *rle; @@ -433,7 +433,7 @@ int passthrough; int i; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); passthrough = (device_get_parent(child) != bus); res = NULL; rle = NULL; @@ -479,8 +479,8 @@ static int fhc_adjust_resource(device_t bus __unused, device_t child __unused, - int type __unused, struct resource *r __unused, u_long start __unused, - u_long end __unused) + int type __unused, struct resource *r __unused, uintmax_t start __unused, + uintmax_t end __unused) { return (ENXIO); Index: sys/sparc64/isa/isa.c =================================================================== --- sys/sparc64/isa/isa.c (revision 290622) +++ sys/sparc64/isa/isa.c (working copy) @@ -273,16 +273,16 @@ struct resource * isa_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { /* * Consider adding a resource definition. */ int passthrough = (device_get_parent(child) != bus); - int isdefault = (start == 0UL && end == ~0UL); + int isdefault = (start == 0 && end == ~0); struct resource_list *rl; struct resource_list_entry *rle; - u_long base, limit; + uintmax_t base, limit; rl = BUS_GET_RESOURCE_LIST(bus, child); if (!passthrough && !isdefault) { Index: sys/sparc64/pci/apb.c =================================================================== --- sys/sparc64/pci/apb.c (revision 290622) +++ sys/sparc64/pci/apb.c (working copy) @@ -130,13 +130,13 @@ } static void -apb_map_print(uint8_t map, u_long scale) +apb_map_print(uint8_t map, uintmax_t scale) { int i, first; for (first = 1, i = 0; i < 8; i++) { if ((map & (1 << i)) != 0) { - printf("%s0x%lx-0x%lx", first ? "" : ", ", + printf("%s0x%jx-0x%jx", first ? "" : ", ", i * scale, (i + 1) * scale - 1); first = 0; } @@ -144,7 +144,7 @@ } static int -apb_checkrange(uint8_t map, u_long scale, u_long start, u_long end) +apb_checkrange(uint8_t map, uintmax_t scale, uintmax_t start, uintmax_t end) { int i, ei; @@ -227,7 +227,7 @@ */ static struct resource * apb_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct apb_softc *sc; @@ -253,13 +253,13 @@ case SYS_RES_IOPORT: if (!apb_checkrange(sc->sc_iomap, APB_IO_SCALE, start, end)) { device_printf(dev, "device %s requested unsupported " - "I/O range 0x%lx-0x%lx\n", + "I/O range 0x%jx-0x%jx\n", device_get_nameunit(child), start, end); return (NULL); } if (bootverbose) device_printf(sc->sc_bsc.ops_pcib_sc.dev, "device " - "%s requested decoded I/O range 0x%lx-0x%lx\n", + "%s requested decoded I/O range 0x%jx-0x%jx\n", device_get_nameunit(child), start, end); break; case SYS_RES_MEMORY: @@ -266,13 +266,13 @@ if (!apb_checkrange(sc->sc_memmap, APB_MEM_SCALE, start, end)) { device_printf(dev, "device %s requested unsupported " - "memory range 0x%lx-0x%lx\n", + "memory range 0x%jx-0x%jx\n", device_get_nameunit(child), start, end); return (NULL); } if (bootverbose) device_printf(sc->sc_bsc.ops_pcib_sc.dev, "device " - "%s requested decoded memory range 0x%lx-0x%lx\n", + "%s requested decoded memory range 0x%jx-0x%jx\n", device_get_nameunit(child), start, end); break; } @@ -287,7 +287,7 @@ static int apb_adjust_resource(device_t dev, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct apb_softc *sc; Index: sys/sparc64/pci/fire.c =================================================================== --- sys/sparc64/pci/fire.c (revision 290622) +++ sys/sparc64/pci/fire.c (working copy) @@ -1852,7 +1852,7 @@ static struct resource * fire_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct fire_softc *sc; Index: sys/sparc64/pci/ofw_pci.c =================================================================== --- sys/sparc64/pci/ofw_pci.c (revision 290622) +++ sys/sparc64/pci/ofw_pci.c (working copy) @@ -287,7 +287,7 @@ struct resource * ofw_pci_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct ofw_pci_softc *sc; struct resource *rv; @@ -362,7 +362,7 @@ int ofw_pci_adjust_resource(device_t bus, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct ofw_pci_softc *sc; struct rman *rm; Index: sys/sparc64/pci/psycho.c =================================================================== --- sys/sparc64/pci/psycho.c (revision 290622) +++ sys/sparc64/pci/psycho.c (working copy) @@ -1038,7 +1038,7 @@ static struct resource * psycho_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct psycho_softc *sc; Index: sys/sparc64/pci/sbbc.c =================================================================== --- sys/sparc64/pci/sbbc.c (revision 290622) +++ sys/sparc64/pci/sbbc.c (working copy) @@ -397,7 +397,7 @@ static struct resource * sbbc_bus_alloc_resource(device_t dev, device_t child __unused, int type, - int *rid, u_long start, u_long end, u_long count, u_int flags) + int *rid, uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct sbbc_softc *sc; @@ -435,8 +435,8 @@ static int sbbc_bus_adjust_resource(device_t bus __unused, device_t child __unused, - int type __unused, struct resource *res __unused, u_long start __unused, - u_long end __unused) + int type __unused, struct resource *res __unused, uintmax_t start __unused, + uintmax_t end __unused) { return (ENXIO); Index: sys/sparc64/pci/schizo.c =================================================================== --- sys/sparc64/pci/schizo.c (revision 290622) +++ sys/sparc64/pci/schizo.c (working copy) @@ -1196,7 +1196,7 @@ static struct resource * schizo_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct schizo_softc *sc; Index: sys/sparc64/sbus/sbus.c =================================================================== --- sys/sparc64/sbus/sbus.c (revision 290622) +++ sys/sparc64/sbus/sbus.c (working copy) @@ -710,7 +710,7 @@ static struct resource * sbus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct sbus_softc *sc; struct rman *rm; @@ -723,7 +723,7 @@ int i, slot; int isdefault, passthrough; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); passthrough = (device_get_parent(child) != bus); rle = NULL; sc = device_get_softc(bus); @@ -821,7 +821,7 @@ static int sbus_adjust_resource(device_t bus, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct sbus_softc *sc; int i; Index: sys/sparc64/sparc64/nexus.c =================================================================== --- sys/sparc64/sparc64/nexus.c (revision 290622) +++ sys/sparc64/sparc64/nexus.c (working copy) @@ -359,7 +359,7 @@ static struct resource * nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct nexus_softc *sc; struct rman *rm; @@ -368,7 +368,7 @@ device_t nexus; int isdefault, passthrough; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); passthrough = (device_get_parent(child) != bus); nexus = bus; while (strcmp(device_get_name(device_get_parent(nexus)), "root") != 0) @@ -445,7 +445,7 @@ static int nexus_adjust_resource(device_t bus, device_t child __unused, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct nexus_softc *sc; struct rman *rm; Index: sys/sparc64/sparc64/upa.c =================================================================== --- sys/sparc64/sparc64/upa.c (revision 290622) +++ sys/sparc64/sparc64/upa.c (working copy) @@ -194,7 +194,7 @@ int i, imr, j, rid; #if 1 device_t *children, schizo; - u_long scount, sstart, ucount, ustart; + uintmax_t scount, sstart, ucount, ustart; int nchildren; #endif @@ -403,7 +403,7 @@ static struct resource * upa_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct resource_list *rl; struct resource_list_entry *rle; @@ -412,7 +412,7 @@ bus_addr_t cend, cstart; int i, isdefault, passthrough; - isdefault = (start == 0UL && end == ~0UL); + isdefault = (start == 0 && end == ~0); passthrough = (device_get_parent(child) != dev); sc = device_get_softc(dev); rl = BUS_GET_RESOURCE_LIST(dev, child); @@ -510,8 +510,8 @@ static int upa_adjust_resource(device_t bus __unused, device_t child __unused, - int type __unused, struct resource *r __unused, u_long start __unused, - u_long end __unused) + int type __unused, struct resource *r __unused, uintmax_t start __unused, + uintmax_t end __unused) { return (ENXIO); Index: sys/sys/bus.h =================================================================== --- sys/sys/bus.h (revision 290622) +++ sys/sys/bus.h (working copy) @@ -29,6 +29,7 @@ #ifndef _SYS_BUS_H_ #define _SYS_BUS_H_ +#include #include #include #include @@ -292,9 +293,9 @@ int rid; /**< @brief resource identifier */ int flags; /**< @brief resource flags */ struct resource *res; /**< @brief the real resource when allocated */ - u_long start; /**< @brief start of resource range */ - u_long end; /**< @brief end of resource range */ - u_long count; /**< @brief count within range */ + __uintmax_t start; /**< @brief start of resource range */ + __uintmax_t end; /**< @brief end of resource range */ + __uintmax_t count; /**< @brief count within range */ }; STAILQ_HEAD(resource_list, resource_list_entry); @@ -307,10 +308,10 @@ struct resource_list_entry * resource_list_add(struct resource_list *rl, int type, int rid, - u_long start, u_long end, u_long count); + __uintmax_t start, __uintmax_t end, __uintmax_t count); int resource_list_add_next(struct resource_list *rl, int type, - u_long start, u_long end, u_long count); + __uintmax_t start, __uintmax_t end, __uintmax_t count); int resource_list_busy(struct resource_list *rl, int type, int rid); int resource_list_reserved(struct resource_list *rl, int type, int rid); @@ -323,8 +324,8 @@ resource_list_alloc(struct resource_list *rl, device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, - u_long count, u_int flags); + __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); int resource_list_release(struct resource_list *rl, device_t bus, device_t child, int type, int rid, struct resource *res); @@ -335,8 +336,8 @@ resource_list_reserve(struct resource_list *rl, device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, - u_long count, u_int flags); + __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); int resource_list_unreserve(struct resource_list *rl, device_t bus, device_t child, int type, int rid); @@ -362,12 +363,12 @@ bus_generic_add_child(device_t dev, u_int order, const char *name, int unit); int bus_generic_adjust_resource(device_t bus, device_t child, int type, - struct resource *r, u_long start, - u_long end); + struct resource *r, __uintmax_t start, + __uintmax_t end); struct resource * bus_generic_alloc_resource(device_t bus, device_t child, int type, - int *rid, u_long start, u_long end, - u_long count, u_int flags); + int *rid, __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); int bus_generic_attach(device_t dev); int bus_generic_bind_intr(device_t dev, device_t child, struct resource *irq, int cpu); @@ -405,12 +406,12 @@ struct resource * bus_generic_rl_alloc_resource (device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + __uintmax_t, __uintmax_t, __uintmax_t, u_int); void bus_generic_rl_delete_resource (device_t, device_t, int, int); -int bus_generic_rl_get_resource (device_t, device_t, int, int, u_long *, - u_long *); -int bus_generic_rl_set_resource (device_t, device_t, int, int, u_long, - u_long); +int bus_generic_rl_get_resource (device_t, device_t, int, int, __uintmax_t *, + __uintmax_t *); +int bus_generic_rl_set_resource (device_t, device_t, int, int, __uintmax_t, + __uintmax_t); int bus_generic_rl_release_resource (device_t, device_t, int, int, struct resource *); @@ -439,10 +440,10 @@ struct resource **res); int bus_adjust_resource(device_t child, int type, struct resource *r, - u_long start, u_long end); + __uintmax_t start, __uintmax_t end); struct resource *bus_alloc_resource(device_t dev, int type, int *rid, - u_long start, u_long end, u_long count, - u_int flags); + __uintmax_t start, __uintmax_t end, + __uintmax_t count, u_int flags); int bus_activate_resource(device_t dev, int type, int rid, struct resource *r); int bus_deactivate_resource(device_t dev, int type, int rid, @@ -460,11 +461,11 @@ int bus_describe_intr(device_t dev, struct resource *irq, void *cookie, const char *fmt, ...); int bus_set_resource(device_t dev, int type, int rid, - u_long start, u_long count); + __uintmax_t start, __uintmax_t count); int bus_get_resource(device_t dev, int type, int rid, - u_long *startp, u_long *countp); -u_long bus_get_resource_start(device_t dev, int type, int rid); -u_long bus_get_resource_count(device_t dev, int type, int rid); + __uintmax_t *startp, __uintmax_t *countp); +__uintmax_t bus_get_resource_start(device_t dev, int type, int rid); +__uintmax_t bus_get_resource_count(device_t dev, int type, int rid); void bus_delete_resource(device_t dev, int type, int rid); int bus_child_present(device_t child); int bus_child_pnpinfo_str(device_t child, char *buf, size_t buflen); @@ -474,7 +475,7 @@ static __inline struct resource * bus_alloc_resource_any(device_t dev, int type, int *rid, u_int flags) { - return (bus_alloc_resource(dev, type, rid, 0ul, ~0ul, 1, flags)); + return (bus_alloc_resource(dev, type, rid, 0, ~0, 1, flags)); } /* Index: sys/sys/libkern.h =================================================================== --- sys/sys/libkern.h (revision 290622) +++ sys/sys/libkern.h (working copy) @@ -63,6 +63,16 @@ static __inline quad_t qmin(quad_t a, quad_t b) { return (a < b ? a : b); } static __inline u_long ulmax(u_long a, u_long b) { return (a > b ? a : b); } static __inline u_long ulmin(u_long a, u_long b) { return (a < b ? a : b); } +static __inline __uintmax_t ummax(__uintmax_t a, __uintmax_t b) +{ + + return (a > b ? a : b); +} +static __inline __uintmax_t ummin(__uintmax_t a, __uintmax_t b) +{ + + return (a < b ? a : b); +} static __inline off_t omax(off_t a, off_t b) { return (a > b ? a : b); } static __inline off_t omin(off_t a, off_t b) { return (a < b ? a : b); } Index: sys/sys/rman.h =================================================================== --- sys/sys/rman.h (revision 290622) +++ sys/sys/rman.h (working copy) @@ -47,6 +47,7 @@ #define RF_FIRSTSHARE 0x0020 /* first in sharing list */ #define RF_PREFETCHABLE 0x0040 /* resource is prefetchable */ #define RF_OPTIONAL 0x0080 /* for bus_alloc_resources() */ +#define RF_CACHEABLE 0x0100 /* memory resource is cacheable */ #define RF_ALIGNMENT_SHIFT 10 /* alignment size bit starts bit 10 */ #define RF_ALIGNMENT_MASK (0x003F << RF_ALIGNMENT_SHIFT) @@ -54,6 +55,9 @@ #define RF_ALIGNMENT_LOG2(x) ((x) << RF_ALIGNMENT_SHIFT) #define RF_ALIGNMENT(x) (((x) & RF_ALIGNMENT_MASK) >> RF_ALIGNMENT_SHIFT) +#define RM_MIN_START ((__uintmax_t)0) +#define RM_MAX_END (~(__uintmax_t)0) + enum rman_type { RMAN_UNINIT = 0, RMAN_GAUGE, RMAN_ARRAY }; /* @@ -70,8 +74,8 @@ uintptr_t r_device; /* device owning this resource */ char r_devname[RM_TEXTLEN]; /* device name XXX obsolete */ - u_long r_start; /* offset in resource space */ - u_long r_size; /* size in resource space */ + __uintmax_t r_start; /* offset in resource space */ + __uintmax_t r_size; /* size in resource space */ u_int r_flags; /* RF_* flags */ }; @@ -79,8 +83,8 @@ uintptr_t rm_handle; /* rman uniquifier */ char rm_descr[RM_TEXTLEN]; /* rman description */ - u_long rm_start; /* base of managed region */ - u_long rm_size; /* size of managed region */ + __uintmax_t rm_start; /* base of managed region */ + bus_size_t rm_size; /* size of managed region */ enum rman_type rm_type; /* region type */ }; @@ -108,8 +112,8 @@ struct resource_head rm_list; struct mtx *rm_mtx; /* mutex used to protect rm_list */ TAILQ_ENTRY(rman) rm_link; /* link in list of all rmans */ - u_long rm_start; /* index of globally first entry */ - u_long rm_end; /* index of globally last entry */ + __uintmax_t rm_start; /* index of globally first entry */ + __uintmax_t rm_end; /* index of globally last entry */ enum rman_type rm_type; /* what type of resource this is */ const char *rm_descr; /* text descripion of this resource */ }; @@ -116,39 +120,39 @@ TAILQ_HEAD(rman_head, rman); int rman_activate_resource(struct resource *r); -int rman_adjust_resource(struct resource *r, u_long start, u_long end); +int rman_adjust_resource(struct resource *r, __uintmax_t start, __uintmax_t end); int rman_await_resource(struct resource *r, int pri, int timo); -int rman_first_free_region(struct rman *rm, u_long *start, u_long *end); +int rman_first_free_region(struct rman *rm, __uintmax_t *start, __uintmax_t *end); bus_space_handle_t rman_get_bushandle(struct resource *); bus_space_tag_t rman_get_bustag(struct resource *); -u_long rman_get_end(struct resource *); +__uintmax_t rman_get_end(struct resource *); struct device *rman_get_device(struct resource *); u_int rman_get_flags(struct resource *); int rman_get_rid(struct resource *); -u_long rman_get_size(struct resource *); -u_long rman_get_start(struct resource *); +__uintmax_t rman_get_size(struct resource *); +__uintmax_t rman_get_start(struct resource *); void *rman_get_virtual(struct resource *); int rman_deactivate_resource(struct resource *r); int rman_fini(struct rman *rm); int rman_init(struct rman *rm); int rman_init_from_resource(struct rman *rm, struct resource *r); -int rman_last_free_region(struct rman *rm, u_long *start, u_long *end); +int rman_last_free_region(struct rman *rm, __uintmax_t *start, __uintmax_t *end); uint32_t rman_make_alignment_flags(uint32_t size); -int rman_manage_region(struct rman *rm, u_long start, u_long end); +int rman_manage_region(struct rman *rm, __uintmax_t start, __uintmax_t end); int rman_is_region_manager(struct resource *r, struct rman *rm); int rman_release_resource(struct resource *r); -struct resource *rman_reserve_resource(struct rman *rm, u_long start, - u_long end, u_long count, +struct resource *rman_reserve_resource(struct rman *rm, __uintmax_t start, + __uintmax_t end, __uintmax_t count, u_int flags, struct device *dev); -struct resource *rman_reserve_resource_bound(struct rman *rm, u_long start, - u_long end, u_long count, u_long bound, +struct resource *rman_reserve_resource_bound(struct rman *rm, __uintmax_t start, + __uintmax_t end, __uintmax_t count, __uintmax_t bound, u_int flags, struct device *dev); void rman_set_bushandle(struct resource *_r, bus_space_handle_t _h); void rman_set_bustag(struct resource *_r, bus_space_tag_t _t); void rman_set_device(struct resource *_r, struct device *_dev); -void rman_set_end(struct resource *_r, u_long _end); +void rman_set_end(struct resource *_r, __uintmax_t _end); void rman_set_rid(struct resource *_r, int _rid); -void rman_set_start(struct resource *_r, u_long _start); +void rman_set_start(struct resource *_r, __uintmax_t _start); void rman_set_virtual(struct resource *_r, void *_v); extern struct rman_head rman_head; Index: sys/x86/include/legacyvar.h =================================================================== --- sys/x86/include/legacyvar.h (revision 290622) +++ sys/x86/include/legacyvar.h (working copy) @@ -56,9 +56,10 @@ int legacy_pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value); struct resource *legacy_pcib_alloc_resource(device_t dev, device_t child, - int type, int *rid, u_long start, u_long end, u_long count, u_int flags); + int type, int *rid, uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags); int legacy_pcib_adjust_resource(device_t dev, device_t child, int type, - struct resource *r, u_long start, u_long end); + struct resource *r, uintmax_t start, uintmax_t end); int legacy_pcib_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r); int legacy_pcib_alloc_msi(device_t pcib, device_t dev, int count, Index: sys/x86/include/pci_cfgreg.h =================================================================== --- sys/x86/include/pci_cfgreg.h (revision 290622) +++ sys/x86/include/pci_cfgreg.h (working copy) @@ -46,7 +46,7 @@ #define CONF2_ENABLE_CHK 0x0e #define CONF2_ENABLE_RES 0x0e -u_long hostb_alloc_start(int type, u_long start, u_long end, u_long count); +uintmax_t hostb_alloc_start(int type, uintmax_t start, uintmax_t end, uintmax_t count); int pcie_cfgregopen(uint64_t base, uint8_t minbus, uint8_t maxbus); int pci_cfgregopen(void); u_int32_t pci_cfgregread(int bus, int slot, int func, int reg, int bytes); Index: sys/x86/isa/atrtc.c =================================================================== --- sys/x86/isa/atrtc.c (revision 290622) +++ sys/x86/isa/atrtc.c (working copy) @@ -241,7 +241,7 @@ atrtc_attach(device_t dev) { struct atrtc_softc *sc; - u_long s; + uintmax_t s; int i; sc = device_get_softc(dev); Index: sys/x86/isa/clock.c =================================================================== --- sys/x86/isa/clock.c (revision 290622) +++ sys/x86/isa/clock.c (working copy) @@ -656,7 +656,7 @@ attimer_attach(device_t dev) { struct attimer_softc *sc; - u_long s; + uintmax_t s; int i; attimer_sc = sc = device_get_softc(dev); Index: sys/x86/isa/isa.c =================================================================== --- sys/x86/isa/isa.c (revision 290622) +++ sys/x86/isa/isa.c (working copy) @@ -88,13 +88,13 @@ */ struct resource * isa_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { /* * Consider adding a resource definition. */ int passthrough = (device_get_parent(child) != bus); - int isdefault = (start == 0UL && end == ~0UL); + int isdefault = (start == 0 && end == ~0); struct isa_device* idev = DEVTOISA(child); struct resource_list *rl = &idev->id_resources; struct resource_list_entry *rle; Index: sys/x86/pci/pci_bus.c =================================================================== --- sys/x86/pci/pci_bus.c (revision 290622) +++ sys/x86/pci/pci_bus.c (working copy) @@ -578,8 +578,8 @@ SYSCTL_ULONG(_hw_pci, OID_AUTO, host_mem_start, CTLFLAG_RDTUN, &host_mem_start, 0, "Limit the host bridge memory to being above this address."); -u_long -hostb_alloc_start(int type, u_long start, u_long end, u_long count) +uintmax_t +hostb_alloc_start(int type, uintmax_t start, uintmax_t end, uintmax_t count) { if (start + count - 1 != end) { @@ -593,7 +593,7 @@ struct resource * legacy_pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { #if defined(NEW_PCIB) && defined(PCI_RES_BUS) @@ -609,7 +609,7 @@ #if defined(NEW_PCIB) && defined(PCI_RES_BUS) int legacy_pcib_adjust_resource(device_t dev, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { if (type == PCI_RES_BUS) Index: sys/x86/pci/qpi.c =================================================================== --- sys/x86/pci/qpi.c (revision 290622) +++ sys/x86/pci/qpi.c (working copy) @@ -241,7 +241,7 @@ #if defined(NEW_PCIB) && defined(PCI_RES_BUS) static struct resource * qpi_pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { if (type == PCI_RES_BUS) Index: sys/x86/x86/io_apic.c =================================================================== --- sys/x86/x86/io_apic.c (revision 290622) +++ sys/x86/x86/io_apic.c (working copy) @@ -987,14 +987,6 @@ { int error; -#ifdef PAE - /* - * Resources use long's to track resources, so we can't - * include memory regions above 4GB. - */ - if (base >= ~0ul) - return; -#endif error = bus_set_resource(dev, SYS_RES_MEMORY, rid, base, length); if (error) panic("apic_add_resource: resource %d failed set with %d", rid, Index: sys/x86/x86/mptable_pci.c =================================================================== --- sys/x86/x86/mptable_pci.c (revision 290622) +++ sys/x86/x86/mptable_pci.c (working copy) @@ -75,7 +75,7 @@ #ifdef NEW_PCIB static int -mptable_is_isa_range(u_long start, u_long end) +mptable_is_isa_range(uintmax_t start, uintmax_t end) { if (end >= 0x10000) @@ -88,7 +88,7 @@ } static int -mptable_is_vga_range(u_long start, u_long end) +mptable_is_vga_range(uintmax_t start, uintmax_t end) { if (end >= 0x10000) return (0); @@ -101,7 +101,7 @@ static struct resource * mptable_hostb_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, u_int flags) { struct mptable_hostb_softc *sc; @@ -142,7 +142,7 @@ static int mptable_hostb_adjust_resource(device_t dev, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct mptable_hostb_softc *sc; Index: sys/x86/x86/nexus.c =================================================================== --- sys/x86/x86/nexus.c (revision 290622) +++ sys/x86/x86/nexus.c (working copy) @@ -99,9 +99,10 @@ static device_t nexus_add_child(device_t bus, u_int order, const char *name, int unit); static struct resource *nexus_alloc_resource(device_t, device_t, int, int *, - u_long, u_long, u_long, u_int); + uintmax_t, uintmax_t, uintmax_t, + u_int); static int nexus_adjust_resource(device_t, device_t, int, struct resource *, - u_long, u_long); + uintmax_t, uintmax_t); #ifdef SMP static int nexus_bind_intr(device_t, device_t, struct resource *, int); #endif @@ -122,8 +123,10 @@ static int nexus_teardown_intr(device_t, device_t, struct resource *, void *); static struct resource_list *nexus_get_reslist(device_t dev, device_t child); -static int nexus_set_resource(device_t, device_t, int, int, u_long, u_long); -static int nexus_get_resource(device_t, device_t, int, int, u_long *, u_long *); +static int nexus_set_resource(device_t, device_t, int, int, + uintmax_t, uintmax_t); +static int nexus_get_resource(device_t, device_t, int, int, + uintmax_t *, uintmax_t *); static void nexus_delete_resource(device_t, device_t, int, int); #ifdef DEV_APIC static int nexus_alloc_msi(device_t pcib, device_t dev, int count, int maxcount, int *irqs); @@ -259,7 +262,7 @@ panic("nexus_init_resources port_rman"); mem_rman.rm_start = 0; - mem_rman.rm_end = ~0ul; + mem_rman.rm_end = ~0; mem_rman.rm_type = RMAN_ARRAY; mem_rman.rm_descr = "I/O memory addresses"; if (rman_init(&mem_rman) @@ -359,7 +362,8 @@ */ static struct resource * nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags) + uintmax_t start, uintmax_t end, uintmax_t count, + u_int flags) { struct nexus_device *ndev = DEVTONX(child); struct resource *rv; @@ -373,7 +377,7 @@ * (ie. they aren't maintained by a child bus), then work out * the start/end values. */ - if ((start == 0UL) && (end == ~0UL) && (count == 1)) { + if ((start == 0) && (end == ~0) && (count == 1)) { if (device_get_parent(child) != bus || ndev == NULL) return(NULL); rle = resource_list_find(&ndev->nx_resources, type, *rid); @@ -406,7 +410,7 @@ static int nexus_adjust_resource(device_t bus, device_t child, int type, - struct resource *r, u_long start, u_long end) + struct resource *r, uintmax_t start, uintmax_t end) { struct rman *rm; @@ -574,7 +578,8 @@ } static int -nexus_set_resource(device_t dev, device_t child, int type, int rid, u_long start, u_long count) +nexus_set_resource(device_t dev, device_t child, int type, int rid, + uintmax_t start, uintmax_t count) { struct nexus_device *ndev = DEVTONX(child); struct resource_list *rl = &ndev->nx_resources; @@ -585,7 +590,8 @@ } static int -nexus_get_resource(device_t dev, device_t child, int type, int rid, u_long *startp, u_long *countp) +nexus_get_resource(device_t dev, device_t child, int type, int rid, + uintmax_t *startp, uintmax_t *countp) { struct nexus_device *ndev = DEVTONX(child); struct resource_list *rl = &ndev->nx_resources; @@ -701,14 +707,6 @@ if (smap->type != SMAP_TYPE_MEMORY || smap->length == 0) continue; -#ifdef __i386__ - /* - * Resources use long's to track resources, so - * we can't include memory regions above 4GB. - */ - if (smap->base > ~0ul) - continue; -#endif error = bus_set_resource(dev, SYS_RES_MEMORY, rid, smap->base, smap->length); if (error) @@ -735,14 +733,6 @@ * segment is 0. */ for (rid = 0, p = dump_avail; p[1] != 0; rid++, p += 2) { -#ifdef PAE - /* - * Resources use long's to track resources, so we can't - * include memory regions above 4GB. - */ - if (p[0] > ~0ul) - break; -#endif error = bus_set_resource(dev, SYS_RES_MEMORY, rid, p[0], p[1] - p[0]); if (error) Index: sys/x86/xen/xenpv.c =================================================================== --- sys/x86/xen/xenpv.c (revision 290622) +++ sys/x86/xen/xenpv.c (working copy) @@ -120,7 +120,7 @@ int error; res = bus_alloc_resource(child, SYS_RES_MEMORY, res_id, LOW_MEM_LIMIT, - ~0ul, size, RF_ACTIVE); + ~0, size, RF_ACTIVE); if (res == NULL) return (NULL); --Apple-Mail-18--958907149-- From owner-freebsd-current@freebsd.org Mon Nov 16 17:08:55 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB9B7A30A51 for ; Mon, 16 Nov 2015 17:08:54 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id C996C1AE8 for ; Mon, 16 Nov 2015 17:08:54 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 90C81DF9F; Mon, 16 Nov 2015 17:08:48 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Dan Partelly References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> Cc: freebsd-current@freebsd.org From: Allan Jude X-Enigmail-Draft-Status: N1110 Message-ID: <564A0D9D.1060400@freebsd.org> Date: Mon, 16 Nov 2015 12:08:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HNlj8XK8u868bQ93OPEQfqbX8S2HlnNQj" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:08:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HNlj8XK8u868bQ93OPEQfqbX8S2HlnNQj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-15 14:44, Dan Partelly wrote: >> I would welcome competing ideas/solutions, but someone would have to a= ctually build them, not just >=20 >> rattle off some ideas on the mailing list. >=20 > Am I missing the point of a mailing list ? it is a place to present an= d exchange ideas, ask why some things are the way they are , and get crit= icism. Rattling ideas is generally where it all starts. You cant realisti= cally expect one to start a pervasive project like transactioanl database= s for an OS configuration without not one mailing list discussion, but a = lot of consultation.=20 >=20 Sorry, I didn't mean to say we shouldn't talk about this. The reason for the less-than-warm response you got from multiple people, is that this is the third or fourth such discussion on the mailing list (this is what mailing list archives are for). Once every so many months, someone rants about how libxo is horrible and is ruining the base system, and wants to lib-ize everything. And no one every does it. Meanwhile, libxo actually gets worked on. >=20 >> There are tools available to filter json/ucl output > yes they are. vim is one . sed is another. awk is the third =E2=80=A6 = But a pipe needs both ends to talk the same language. I can generate json= as output, i can filter it , but what tool in FreeBSD will accept it as= input ? None. A >=20 >> and my forthcoming uclcmd >=20 > What uclcmd does / will do ? =20 It can read, filter, and write UCL (as well as JSON, YAML, and msgpack. Hopefully it will be able to do NVLists in a few months). It is designed to be able to view, extract information from, and edit config files. AsiaBSDCon Paper: http://allanjude.com/talks/AsiaBSDCon2015_paper_-_UCL_for_FreeBSD.pdf BSDCan Dev Summit working group: Wiki Page: https://wiki.freebsd.org/201506DevSummit/UCL Slides: http://www.allanjude.com/bsd/BSDCan2015_-_UCL_Working_Group.pdf Additional Slides about libucl: http://www.allanjude.com/bsd/cebka_BSDCan2015-UCL.pdf Video: BSDCan Presentation: Slides: http://allanjude.com/talks/BSDCan2015_-_UCL_for_FreeBSD.pdf Video: https://www.youtube.com/watch?v=3D8l6bhKIDecg >=20 >> UCL is a good solution to having a universal config file, and is bette= r >> than the bespoke config files each utility has >=20 >=20 > I agree with you, if you manage somehow to port every ad-hoc database F= reeBSD has in base to ucl, (including all the bestiary we have in /etc ) = and offer tools to parse them in the rc init system to fetch the settings= =2E I dont expect this to be done in one release , but do you tend toward= s this in your projects ? One config format to rule them all is good. Yet= another config format in selected places in base is evil. >=20 The goal is to change everything, and I am making progress. The working group at BSDCan had quite a wish list of things to convert, including a bunch that I figured people would prefer not to touch, like login.conf (I need to polish that patch and get it up for review) >> A transactional database >> might be better (for some uses, likely less so for some people), but I= >> don't hear anyone volunteering to do that work. >=20 > IIRC Solaris uses sqlite. Might be a decent solution. ( a lot of the ad= hoc unix databases are relational databases in disguise, with unix tools= acting as operators) And if you abstract a config interface API over UC= L, someone could benefit from it by plugging in a transactional backend = one day. All you would have to do is not directly plug in UCL, but work o= n a orthogonal abstract API. You could even model it after UCL API. > Please consider it.=20 >=20 For bhyve, the basic design they have in mind is UCL config files that are parsed and presented to the application as an nvlist, which it then passed between modules of bhyve (like networking, out-of-band access, graphics, disk (vmdk, qcow, etc)), without the base bhyve application having to know what config options modules actually support. It seems like a reasonable design to me. I don't know that further abuse of sqlite is actually a good idea, but I am still a bit new at this. >=20 >> I would welcome competing ideas/solutions, but someone would have to a= ctually build them, not just >=20 >> >> lib-izing all of the utilities instead of using libxo is a better >> solution. It would likely be gratefully accepted if someone were to do= >> it, but most likely, no one will. >> >> libxo exists now, and most applications can be converted very quickly >> (although care does need to be taken, and it sometimes has not been). >> >> There are tools available to filter json/ucl output, namely textproc/j= q >> and my forthcoming uclcmd >> >> One of the major other consumers of the json/xml output of libxo, is w= eb >> control panels. This is why Juniper is doing the work, and I can think= >> of a list of other appliance vendors who would love to replace fragile= >> per-application parsers with a json parser to extract data from variou= s >> command line tools. >> >> UCL is a good solution to having a universal config file, and is bette= r >> than the bespoke config files each utility has. A transactional databa= se >> might be better (for some uses, likely less so for some people), but I= >> don't hear anyone volunteering to do that work. >> >> So, libxo and libucl may not be the very best solutions, but they are >> the ones that are moving forward. I would welcome competing >> ideas/solutions, but someone would have to actually build them, not ju= st >> rattle off some ideas on the mailing list. >> >> --=20 >> Allan Jude >> >=20 --=20 Allan Jude --HNlj8XK8u868bQ93OPEQfqbX8S2HlnNQj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSg2kAAoJEBmVNT4SmAt+JfYQAJMu2sJq3h8VEgcRFf199GKr pYS+PWbteJpKh8M4goBSGLvpom7NI1V5vfPC+04YoEpAhQZYO24zfS5q7sHkujv8 F52ERz1iOONwEt5A/fvkTew38rJEq1htdW/18siNg1KJQU2491FO9Rhcv99NE/SV HRbWHq81r/mY23/uaGbfzxj5jFf3h62yrLqz2xbweZc29Om2ouEA6HeulzHkDp0h VszRrwfIokdDcKyNuRIugy45HVx2AO4ltHoxn3DKbL26QNGs5qTsOWVdhoIiVFeS 3VJO5GwLqVo9RGPLGdCEvAuE9XBPdQjkQ0PT6/1tTulubLI4VoB/X9REb2kSZjNK bKBRqSbYfVo0lI8GIU0ahPEx6ipO/def3pgzl6wpg98dxBoF+gBG2STVgqkBmuM0 Y0yFGlKZ8vOe27N+ZUmPFGqAD3sBT2YCSvQpTJGkhwJKhPKbKImWnIUrE7nh68n1 mJAZb0cm2WtJUTTh7rzVwvl9x25E5jGUfweGjYuks6TAqYvKyYsNCu7Ce5feF5Q2 cuzdz+YdQVgViZCTr+tti2IFETeoy/rkxNc8PIYFoAYOlf/s+hqI3REYta5QAJzk 15K2K+qQFIPqPryh6hYX5OWVT4+BvctrN8AOOV0AJSIzgd1k3sGZq1Mp+lCfYQVq MdtoNzwOw4JsnMUEBfuF =xpx8 -----END PGP SIGNATURE----- --HNlj8XK8u868bQ93OPEQfqbX8S2HlnNQj-- From owner-freebsd-current@freebsd.org Mon Nov 16 17:09:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0CE2A30AF6 for ; Mon, 16 Nov 2015 17:09:47 +0000 (UTC) (envelope-from elizabeth@interlinked.me) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.65.240.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AB081D98 for ; Mon, 16 Nov 2015 17:09:46 +0000 (UTC) (envelope-from elizabeth@interlinked.me) Received: (qmail 22515 invoked from network); 16 Nov 2015 17:17:59 -0000 Received: from ip68-13-249-237.ok.ok.cox.net (HELO ?192.168.1.73?) (emyers@wilcox-tech.com@68.13.249.237) by mail.foxkit.us with ESMTPA; 16 Nov 2015 17:17:59 -0000 Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Elizabeth Myers Message-ID: <564A0DD4.7030505@interlinked.me> Date: Mon, 16 Nov 2015 11:09:40 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:09:47 -0000 On 15/11/15 06:54, Dan Partelly wrote: > Hi all, > > I was looking at the new facility of dumping JSON,XML from many utils i= n base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: > > > 1. Undoubtedly, it makes base code slightly harder to understand and ma= intain.=20 > 2. I have seen the idea that this makes the information dumped by utili= ties in the base easily accessible programatically. OK, maybe it does , b= ut > it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I > dont see too many ppl changing their code to read JSON instead of text.= I don't even see the base tools changing. This output may be useful in = corner cases only. > 3. The integration of libxo IMO only points at a much deeper issue IMO.= It is only an expression of the need of a mechanism aimed at binary code= reuse. But it does not solve the problem, it only adds yet another possi= bility in a world where too much choices already result in too much split= s and incompatible APIs.=20 > 4. This whole effort would have been IMO much better served by porting= the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch like the libs for geom, zfs , etc , ready for reuse of 3rd party code.= Eventually writing network control daemons in time over it , much like s= olaris does. > > 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the be= stiary of ad hoc databases already existing in BSDs ? Programatic readabi= lity, yes. but it does not add any real much needed functionality such as= *transactional databases* for system tools. Why not research a proper = solution - easily accessible by other programs ,orthogonal , transactiona= l, and ACL protected solution which can be used all over the place , f= rom OS boot, to ABI management, service management, network management, u= ser management. I hope this day will come, a day when I will not have to= edit a single config file manually, yet I would have access to all the c= onfig and system state easy with wrapper APIs. In the light of this poin= t, why go with UCL ? It is not orthogonal, it is not transnational, and e= diting the config files directly would result in the same old human error= s which bite as all from time to time. > > 5. It is my opinion that Solaris addressed some of those issue. Solaris= FMRI and SMF are lightyears ahead of the very tired models we keep using= on BSDs. Why not build on the insight offered by those (or even on the i= nsight offered by Windows :P) , then inventing more adhoc solutions and a= d-hoc databases, which do not address the real issues we have , like bina= ry code reuse, service management issues, lack of a system wide publishe= d -subscriber bus ( not kdbus :P ) fault detection and reaction, fault re= porting, all much needed parts of a modern OS.=20 > > And now thee questions > > 1. Why lib XO ? Why burden the OS for some corner cases where it may be= useful ? > > 2. Was there any real talk on how to bring FreeBSD up to speed regardin= g those issues ? A period of research on what exists, on what can be don= e , and ensure important things are not showed in background and replaced= with yet another ad-hoc config database which lacks modern features ? > From where I am standing, this could be a project spawning multiple yea= rs , but it would be well worth it, and in my opinion it would be also wo= rthy of=20 > the freeSBD foundation sponsorship for several years in a row. The feat= ures I touched upon became very important parts of oder OSes, and rightly= so.=20 > > Note: > > this message is serious and it is not intended to start flame wars, rel= igious crusades, or offend anyone.=20 > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" It seems to boil down to the golden rule: he who has the gold, makes the rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD foundation and employ many devs, so they got their way. That's all there is to it. -- Regards, Elizabeth Myers From owner-freebsd-current@freebsd.org Mon Nov 16 17:16:31 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB07AA30D79 for ; Mon, 16 Nov 2015 17:16:30 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id C79D114B4 for ; Mon, 16 Nov 2015 17:16:30 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C75D0DFEE for ; Mon, 16 Nov 2015 17:16:29 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564A0DD4.7030505@interlinked.me> From: Allan Jude X-Enigmail-Draft-Status: N1110 Message-ID: <564A0F71.7060700@freebsd.org> Date: Mon, 16 Nov 2015 12:16:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564A0DD4.7030505@interlinked.me> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N9tRqgCf96cJra1M5duEPwiT6cDo2pxgb" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:16:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N9tRqgCf96cJra1M5duEPwiT6cDo2pxgb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-16 12:09, Elizabeth Myers wrote: > On 15/11/15 06:54, Dan Partelly wrote: >> Hi all, >> >> I was looking at the new facility of dumping JSON,XML from many utils = in base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: >> >> >> 1. Undoubtedly, it makes base code slightly harder to understand and m= aintain.=20 >> 2. I have seen the idea that this makes the information dumped by util= ities in the base easily accessible programatically. OK, maybe it does , = but >> it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I >> dont see too many ppl changing their code to read JSON instead of text= =2E I don't even see the base tools changing. This output may be useful = in corner cases only. >> 3. The integration of libxo IMO only points at a much deeper issue IMO= =2E It is only an expression of the need of a mechanism aimed at binary c= ode reuse. But it does not solve the problem, it only adds yet another po= ssibility in a world where too much choices already result in too much sp= lits and incompatible APIs.=20 >> 4. This whole effort would have been IMO much better served by portin= g the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, m= uch like the libs for geom, zfs , etc , ready for reuse of 3rd party code= =2E Eventually writing network control daemons in time over it , much lik= e solaris does. >> >> 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet= induce another orthogonality violation. What makes UCL better than the b= estiary of ad hoc databases already existing in BSDs ? Programatic readab= ility, yes. but it does not add any real much needed functionality such a= s *transactional databases* for system tools. Why not research a proper= solution - easily accessible by other programs ,orthogonal , transaction= al, and ACL protected solution which can be used all over the place , = from OS boot, to ABI management, service management, network management, = user management. I hope this day will come, a day when I will not have t= o edit a single config file manually, yet I would have access to all the = config and system state easy with wrapper APIs. In the light of this poi= nt, why go with UCL ? It is not orthogonal, it is not transnational, and = editing the config files directly would result in the same old human erro= rs which bite as all from time to time. >> >> 5. It is my opinion that Solaris addressed some of those issue. Solari= s FMRI and SMF are lightyears ahead of the very tired models we keep usin= g on BSDs. Why not build on the insight offered by those (or even on the = insight offered by Windows :P) , then inventing more adhoc solutions and = ad-hoc databases, which do not address the real issues we have , like bin= ary code reuse, service management issues, lack of a system wide publish= ed -subscriber bus ( not kdbus :P ) fault detection and reaction, fault r= eporting, all much needed parts of a modern OS.=20 >> >> And now thee questions >> >> 1. Why lib XO ? Why burden the OS for some corner cases where it may b= e useful ? >> >> 2. Was there any real talk on how to bring FreeBSD up to speed regardi= ng those issues ? A period of research on what exists, on what can be do= ne , and ensure important things are not showed in background and replace= d with yet another ad-hoc config database which lacks modern features ? >> From where I am standing, this could be a project spawning multiple ye= ars , but it would be well worth it, and in my opinion it would be also w= orthy of=20 >> the freeSBD foundation sponsorship for several years in a row. The fea= tures I touched upon became very important parts of oder OSes, and rightl= y so.=20 >> >> Note: >> >> this message is serious and it is not intended to start flame wars, re= ligious crusades, or offend anyone.=20 >> =20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >=20 > It seems to boil down to the golden rule: he who has the gold, makes th= e > rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD > foundation and employ many devs, so they got their way. >=20 > That's all there is to it. >=20 As Simon pointed out, many more people than Juniper wanted it. Juniper had a less generalized version of this in their own tree, and would have happily kept it to them selves, but they went to the extra effort of generalizing it and cleaning it up to commit it to base, because at a FreeBSD Vendor Summit, a number of other companies wished for the same functionality. Even my small 3 person company greatly desires this functionality, and this is why I have been helping to convert additional utilities to use libxo. How big of a donor you are to the FreeBSD Foundation does not affect the committable of your code. Having code ready to commit, vs just a vague plan, does help your solution win out over another proposed solution thou= gh. > -- > Regards, > Elizabeth Myers >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 --=20 Allan Jude --N9tRqgCf96cJra1M5duEPwiT6cDo2pxgb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSg9xAAoJEBmVNT4SmAt+NMYQAOHihxbSOB2AsEv7OCynVijn XyEzQcIwWDKYgzdMAusGJuEpyQouqzNZgfHFVfCidJw4YcP+7kna99hB8UQAyJEx nRh217YtmxOKA3XCEuBV79co7uXs+MKgz5lol6veiVcVPKkYN3Kvtl2xkIQb9Vvm OUz8OQ22mTDASocxBjZFFcTGpJ9hD1COlZejbrPUVk3bjrsiksUkmwOWoC7/uot3 /9nioHT5gEt/uIgcmTtfj2WcPHD6kraWI9MxsMMgQlKBoYo0OtTeRs+bC7tMJRES GhKtaPsoYDVNJfz0HpM+HWVbCnsgcalzwvl5j5TALd1D+1xRuBvVrjiKldIP0WA6 qaq7fD2IAvzRIe+WAPtJctgTXC6j6i0B2OarQiE6jh56KPqaCWqNI8wprv1e/YC5 p31CrgM+QSV665h/x3gAX0Cqi+gHAZhQq5XWfJe4WxtHJNYVHuOXqHWTdwb6F7fi An3u/e81+A0WwuikhEE22lvxsZoUkVRAy25fy/tEuD0jcF+MEBz/9Mn8+r2d0iTl tCjQ3Q+RHizZ+ybTI3QetAZ4wR7y6tSY5aghqa/ciNoPYRj8Vm779ri60zFuSU2p jtKQ4dLFV+//BZu/oFprfm8bd6kIlWJICuOn18gFCZa5YWztV3XDIcDR3dNvoWPi Ms6qjwCrnjOwK1RzTB6I =YYP4 -----END PGP SIGNATURE----- --N9tRqgCf96cJra1M5duEPwiT6cDo2pxgb-- From owner-freebsd-current@freebsd.org Mon Nov 16 17:31:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14BE4A3029E for ; Mon, 16 Nov 2015 17:31:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D05E511CC for ; Mon, 16 Nov 2015 17:31:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by iouu10 with SMTP id u10so160819487iou.0 for ; Mon, 16 Nov 2015 09:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=ME9nXhBcmgqt7X2KjIB8ML0dHKevKmxaqvn1VV6lyjI=; b=oj2zO+xMfaLKX8DNsRVyMHzIPzE58omAL5jPRH/pDSkVy0PfxDvxw2diLQLMqQgSlH e7fvNsVCHLoZXf2B4QYoTbiua3sjMgZTC66Lp5mS4fTT0mNUYZwLmzjzlLxvmiN3o6wA GG7UdUVdiz/tWZh0MemwybSUqcHxwlA9bfaJzOEfJOWpTHqMG5pcx0CFzu037EXdTSo1 zn94ktsCFwdw9ntKa6W84lhAfS4DMltKxnRFkZqsYmEPyrX2q7+9H0HAG+5liPd7AVHp 7MHGtcd+bWpZZX/P4692D+4SmncXWLBOK6ZkGBty38k/R2CWaiKC6OfQk5ZXHRzRxfni m/FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ME9nXhBcmgqt7X2KjIB8ML0dHKevKmxaqvn1VV6lyjI=; b=jUOhDyT6gONK6Zy7Beb+cFEPYk2dYukhXd91nnjw3/HnLh/uJEqbgYN1+Tzq8UGFY1 gQJtb/A/PGQ6fDkK351OxVvAnlFIkT37Nhah5Yw6QdUZL5bo+G/rNM554nfBtsgpw/lf eRoQ60mnZOBpGPp5TcBjigBB1AmWxCQTU9i6mypvarDvbSU9XSXUaWuwXK2/PB61AR0l FkdBLDvlL8hxYxQWpuEB/YDOEiPhqek3YmYUL+fo/0bNQYEYeibMMRfAeEYYrLBMC5oF dn41CeF3skrX8zRxikxobwkssIFqT3k/Q22MYuILsoa2C2D0ZfXBQQWa1QcK7NX5IOkO qB+Q== X-Gm-Message-State: ALoCoQnWFtaZt+pGRnxD7B7rirq3DgBjbqOqMhmSaHgruXzXiPSyjuwjNY9hKSWviroDxB/z05mN X-Received: by 10.107.25.81 with SMTP id 78mr28461934ioz.127.1447695077846; Mon, 16 Nov 2015 09:31:17 -0800 (PST) Received: from ?IPv6:2601:280:4900:3700:710f:9f5c:5426:f54e? ([2601:280:4900:3700:710f:9f5c:5426:f54e]) by smtp.gmail.com with ESMTPSA id fs10sm6548813igb.18.2015.11.16.09.31.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Nov 2015 09:31:17 -0800 (PST) Sender: Warner Losh Subject: Re: CFT: uintmax_t rman Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_121AC1C5-0E33-4F7F-8C87-010CC726DBFB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> Date: Mon, 16 Nov 2015 10:31:11 -0700 Cc: FreeBSD Current Message-Id: <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:31:19 -0000 --Apple-Mail=_121AC1C5-0E33-4F7F-8C87-010CC726DBFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > On Nov 15, 2015, at 9:13 PM, Justin Hibbits = wrote: >=20 > (Attempted to send this yesterday, but appears it didn't go through. = Apologies if it really did go through). >=20 > As part of a project getting FreeBSD on the Freescale P5020 SoC, I = increased the width of resources, from u_long(32 bits on 32-bit archs, = 64 bits on 64-bit archs) to uintmax_t (currently 64 bits on all archs). = I have it working on PowerPC, but have not tested it on any other = architecture, I have no other systems to test it with, so I need help. = This passes a tinderbox build. I need this tested on other archs, the = more the better, especially i386, including PAE. >=20 > It should be effectively a no-op on most architectures, especially = 64-bit archs, though there were some checks I found in x86 code clamping = address checks to under 4GB, commented as necessary purely for rman. If = this isn't the case, and we can't yet handle the checks being removed, = they can go in, but that needs testing. It should apply cleanly to = recent head. I like the idea. There=E2=80=99s nothing offensive enough in the diffs = to comment upon here (though I suppose I could see a few spots one could = quibble over if one were so inclined). I wonder, though, why not make its own typedef, even if it is just = =E2=80=98typedef man_res_t uintmax_t;=E2=80=99 in the rman headers? Warner --Apple-Mail=_121AC1C5-0E33-4F7F-8C87-010CC726DBFB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWShLgAAoJEGwc0Sh9sBEAB7YP/3Qo+bfyoRXhZ5cLVAghaZH9 Jbsn2VHRRhgMzq1UoIf65qV9f3tIBLKinYOnwBcYWTrCQ7pPib6a8chZrqE52r1g CZor5iSGD+zWpQnpDID7OF2SXbNV3RxlMzr4wJD5P161HDspgtyYHtDB7L7Mbrfh Wm/Hfq7DnEPFMItTD/JrRLyrpRpf9+Fm6EFx9F/RgdAHTglqannaKriTwBgOkpR8 fE2x29jZsFQxK63Qu36dofgpHkL10pS8L6pzjQjc+11nPa9mpdftBKwZjxlPjMbu CpX35gt2Udcwp0ohwfeinnZ3p6CPjCCGbT9V7ttRMpt7mgzC6AHCJQHq4xJhoWJF FfZp9JbZ3C9H04yUfjMFREKcy8Ufmz++sj91xTnNOtlfQKQFX3C57+3p1fS82YuL MYgUWgZULzOOU6BPzMVt1JVVhkN3sI/UuaXBm80/FIPK2cXEGiMc27RIg6bmlfD8 E5pJUj9lQzBmnUPug4hXAoUdZWt5718eC89hM1kUbhVvWYk2eM37Skhw7nU0uDxV PBS98QGrgUQgjszD9MAdbHo/5VMdVSVPd86Suo7Y3ZB93B0V2UCc6Hu6z8g74kQU KaaCwF9QvnUtaWqiDi6scvwV4ZcHBXrq3gLRl5t1Lqr5lN9n3gN9TusLIRXn0tUr gBk0qrNdpMv3mamiID16 =Fmq5 -----END PGP SIGNATURE----- --Apple-Mail=_121AC1C5-0E33-4F7F-8C87-010CC726DBFB-- From owner-freebsd-current@freebsd.org Mon Nov 16 17:34:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBAF3A30337 for ; Mon, 16 Nov 2015 17:34:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AD4DB14C9; Mon, 16 Nov 2015 17:34:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 953B95F3; Mon, 16 Nov 2015 17:34:01 +0000 (UTC) Date: Mon, 16 Nov 2015 17:34:01 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1467870686.25.1447695241454.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1796309839.23.1447675309559.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1796309839.23.1447675309559.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1698 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:34:01 -0000 FreeBSD_HEAD-tests - Build #1698 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1698/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1698/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1698/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Mon Nov 16 17:36:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16696A3042C for ; Mon, 16 Nov 2015 17:36:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D658F1900 for ; Mon, 16 Nov 2015 17:36:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from c124.sec.cl.cam.ac.uk (c124.sec.cl.cam.ac.uk [128.232.18.124]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id tAGHa6JZ000598 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2015 17:36:07 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: David Chisnall In-Reply-To: <564A0DD4.7030505@interlinked.me> Date: Mon, 16 Nov 2015 17:36:05 +0000 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564A0DD4.7030505@interlinked.me> To: Elizabeth Myers X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:36:10 -0000 On 16 Nov 2015, at 17:09, Elizabeth Myers = wrote: >=20 > It seems to boil down to the golden rule: he who has the gold, makes = the > rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD > foundation and employ many devs, so they got their way. >=20 > That's all there is to it. I think that=E2=80=99s a mischaracterisation. =20 (Core hat on:) Juniper=E2=80=99s status as a donor to the FreeBSD = Foundation has absolutely no baring on their ability to get code = committed. The libxo code was accepted because it solves a problem that = a number of FreeBSD users (and downstream consumers of FreeBSD) have. Libucl is primarily developed by a PhD student. He is not backed by a = large corporation or an organisation that donates to the FreeBSD = Foundation. His code is accepted for precisely the same reason as = libxo: it solves a problem that many people have identified is real. Development is, however, driven by people willing to actually do the = work, and being willing to listen to feedback from other developers. If = someone started committing a load of code that is only of use to them = and makes life harder for everyone else, then Core would be quick to = request that it be reverted. This rarely happens, because we try hard = to avoid giving commit bits to people who don=E2=80=99t play well with = others. Phil has put a lot of effort into libxo and, most importantly, listened = to community feedback. For example, his recent changes to libxo from = feedback at BSDCam (where he led a session discussing it and related = topics) means that libxo can now be used to trivially add localisation = to the a load of base system utilities. This is something that was not = in the Juniper system that inspired libxo, because it is not something = that they need (Juniper=E2=80=99s interface provides a choice between US = English and US English). This is part of the reason why Phil was recently awarded his commit bit: = he isn=E2=80=99t just writing code that Juniper wants, he=E2=80=99s = writing code that benefits both Juniper and the wider community and is = willing to adapt it to provide wider benefits. This is *precisely* how = open source is supposed to work: Juniper benefits by (eventually) being = able to reduce their diffs to upstream, everyone else benefits from = having the new features, and development is led by consensus of what is = useful. (Core hat off:) I slightly disagree with Alan=E2=80=99s comment that = librarification of base system utilities addresses the same problems. = There are three related problems: - Being able to expose the same functionality as the base system = utilities to C code. - Being able to expose this functionality via bindings to high-level = languages. - Being able to drive complex scripting from the command line and shell = scripts. Libxo directly addresses the last of these points and inefficiently = addresses the first and second. Librarification would address the first = and (possibly) the second. They are overlapping requirements. For some = the second, the combination would likely be the best solution for a lot = of requirements (i.e. have library calls that produce the JSON that = Lua/Python/Ruby/JavaScript/Intercal can turn into native objects). I would very much like to see all of the base system functionality = exposed in terms of libraries, but this is a huge challenge. Good API = design is *hard*. Tools like libucl and libxo allow people to build = high-level wrappers and experiment with API design easily outside of the = base system, in such a way that does not give us difficult C API = compatibility requirements that we have to respect for the next few = decades, and will allow us to be more informed when it comes to = designing these APIs. David From owner-freebsd-current@freebsd.org Mon Nov 16 17:39:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6DBCA304AB for ; Mon, 16 Nov 2015 17:39:21 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C6E361A6B; Mon, 16 Nov 2015 17:39:20 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.102] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 845E61D8B7; Mon, 16 Nov 2015 19:39:13 +0200 (EET) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <564A0F71.7060700@freebsd.org> Date: Mon, 16 Nov 2015 19:39:12 +0200 Cc: freebsd-current@freebsd.org Message-Id: <7644107F-8C34-431D-9367-680A609BE7F5@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564A0DD4.7030505@interlinked.me> <564A0F71.7060700@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:39:21 -0000 > How big of a donor you are to the FreeBSD Foundation does not affect = the > committable of your code. Having code ready to commit, vs just a vague > plan, does help your solution win out over another proposed solution = though Then surely you will salvage something from a lot of GsoCs where people = wrote code with various degrees of success, only=20 to never hear again of anintegration, or an evaluation of that code, = and possible integration.=20 One which directly interests me: what happened to the BSD libctf code = from GSoc ? Was the resulted code evaluated ? If=20 it falls short, where it does ? Can it be salvaged ?=20 Libxo might be a fine facility to have for some corner cases, but it = doesnt solve the problem of binary code reuse in general. Might have = solved it fast for Juniper. It is yet another stick into a scaffolding = of shell scripts which should have been replaced years ago with proper = libraries, services and IPC, opening the road towards modern service = management, service frameworks , fault management , fault response and = transactional OS databases=20 =20 I continue to believe this is or will become shortly an issue of utmost = importance , one which is worthy of the status of a FreeBSD=20 initiated and sponsored object.=20 > On 16 Nov 2015, at 19:16, Allan Jude wrote: >=20 > On 2015-11-16 12:09, Elizabeth Myers wrote: >> On 15/11/15 06:54, Dan Partelly wrote: >>> Hi all, >>>=20 >>> I was looking at the new facility of dumping JSON,XML from many = utils in base and after some funny minutes, I couldn't stop ask myself = =E2=80=9C Ok, this is funny , but why ? =E2=80=9C And I couldn't find a = real answer. Ill outline what I think: >>>=20 >>>=20 >>> 1. Undoubtedly, it makes base code slightly harder to understand and = maintain.=20 >>> 2. I have seen the idea that this makes the information dumped by = utilities in the base easily accessible programatically. OK, maybe it = does , but >>> it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any = meaningful way, and I >>> dont see too many ppl changing their code to read JSON instead of = text. I don't even see the base tools changing. This output may be = useful in corner cases only. >>> 3. The integration of libxo IMO only points at a much deeper issue = IMO. It is only an expression of the need of a mechanism aimed at binary = code reuse. But it does not solve the problem, it only adds yet another = possibility in a world where too much choices already result in too much = splits and incompatible APIs.=20 >>> 4. This whole effort would have been IMO much better served by = porting the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library = API, much like the libs for geom, zfs , etc , ready for reuse of 3rd = party code. Eventually writing network control daemons in time over it , = much like solaris does. >>>=20 >>> 5. A port of partial OS config data to UCL =E2=80=A6. would induce = yet induce another orthogonality violation. What makes UCL better than = the bestiary of ad hoc databases already existing in BSDs ? Programatic = readability, yes. but it does not add any real much needed functionality = such as *transactional databases* for system tools. Why not research a = proper solution - easily accessible by other programs ,orthogonal , = transactional, and ACL protected solution which can be used all over = the place , from OS boot, to ABI management, service management, network = management, user management. I hope this day will come, a day when I = will not have to edit a single config file manually, yet I would have = access to all the config and system state easy with wrapper APIs. In = the light of this point, why go with UCL ? It is not orthogonal, it is = not transnational, and editing the config files directly would result in = the same old human errors which bite as all from time to time. >>>=20 >>> 5. It is my opinion that Solaris addressed some of those issue. = Solaris FMRI and SMF are lightyears ahead of the very tired models we = keep using on BSDs. Why not build on the insight offered by those (or = even on the insight offered by Windows :P) , then inventing more adhoc = solutions and ad-hoc databases, which do not address the real issues we = have , like binary code reuse, service management issues, lack of a = system wide published -subscriber bus ( not kdbus :P ) fault detection = and reaction, fault reporting, all much needed parts of a modern OS.=20 >>>=20 >>> And now thee questions >>>=20 >>> 1. Why lib XO ? Why burden the OS for some corner cases where it may = be useful ? >>>=20 >>> 2. Was there any real talk on how to bring FreeBSD up to speed = regarding those issues ? A period of research on what exists, on what = can be done , and ensure important things are not showed in background = and replaced with yet another ad-hoc config database which lacks modern = features ? >>> =46rom where I am standing, this could be a project spawning = multiple years , but it would be well worth it, and in my opinion it = would be also worthy of=20 >>> the freeSBD foundation sponsorship for several years in a row. The = features I touched upon became very important parts of oder OSes, and = rightly so.=20 >>>=20 >>> Note: >>>=20 >>> this message is serious and it is not intended to start flame wars, = religious crusades, or offend anyone.=20 >>>=20 >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 >> It seems to boil down to the golden rule: he who has the gold, makes = the >> rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD >> foundation and employ many devs, so they got their way. >>=20 >> That's all there is to it. >>=20 >=20 > As Simon pointed out, many more people than Juniper wanted it. Juniper > had a less generalized version of this in their own tree, and would = have > happily kept it to them selves, but they went to the extra effort of > generalizing it and cleaning it up to commit it to base, because at a > FreeBSD Vendor Summit, a number of other companies wished for the same > functionality. >=20 > Even my small 3 person company greatly desires this functionality, and > this is why I have been helping to convert additional utilities to use > libxo. >=20 > How big of a donor you are to the FreeBSD Foundation does not affect = the > committable of your code. Having code ready to commit, vs just a vague > plan, does help your solution win out over another proposed solution = though. >=20 >> -- >> Regards, >> Elizabeth Myers >>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org = mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current = >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org = " >>=20 >=20 >=20 > --=20 > Allan Jude From owner-freebsd-current@freebsd.org Mon Nov 16 18:06:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFBD3A30BF5 for ; Mon, 16 Nov 2015 18:06:11 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8835B17DC; Mon, 16 Nov 2015 18:06:10 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.102] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 29D291F14F; Mon, 16 Nov 2015 20:06:09 +0200 (EET) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <564A0D9D.1060400@freebsd.org> Date: Mon, 16 Nov 2015 20:06:08 +0200 Cc: freebsd-current@freebsd.org Message-Id: <7F8C680E-5718-4AE5-BEB6-50D4659EBDB4@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> <564A0D9D.1060400@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 18:06:11 -0000 Thanks for the details Allan, To be frank , Im not expecting any warm response. It wouldn't bother me = if you would all have answered me like rabid dogs, as long i would get = answers to some questions I have.=20 Libxo is not horrible per se, but adoption made me painfully aware of a = deep problem in BSDs, the aforementioned issue of binary code reuse. The = problem is a very difficult one, indeed, Microsoft for example worked = for decades on it. Libraries, framework, ATL , COM technologies where = all attempts to solve this issue on the Windows platform. And i dare to = say they didn't managed to solve it completely :P What I wanted to see if there are developers who aknowledge that there = is an issue with binary code reuse, and if there are any plans to solve = this proper. (see the end of David Chisnall message ) Also, you , the developers, are in much better position than outsiders = to make the FreeBSD aware of those issue, and , start some projects = sponsored by the foundation. You are the insiders, you are the ones = which are closer to the decisional factors in the foundation of where = the money will flow. > On 16 Nov 2015, at 19:08, Allan Jude wrote: >=20 > On 2015-11-15 14:44, Dan Partelly wrote: >>> I would welcome competing ideas/solutions, but someone would have to = actually build them, not just >>=20 >>> rattle off some ideas on the mailing list. >>=20 >> Am I missing the point of a mailing list ? it is a place to present = and exchange ideas, ask why some things are the way they are , and get = criticism. Rattling ideas is generally where it all starts. You cant = realistically expect one to start a pervasive project like transactioanl = databases for an OS configuration without not one mailing list = discussion, but a lot of consultation.=20 >>=20 >=20 > Sorry, I didn't mean to say we shouldn't talk about this. The reason = for > the less-than-warm response you got from multiple people, is that this > is the third or fourth such discussion on the mailing list (this is = what > mailing list archives are for). Once every so many months, someone = rants > about how libxo is horrible and is ruining the base system, and wants = to > lib-ize everything. And no one every does it. Meanwhile, libxo = actually > gets worked on. >=20 >>=20 >>> There are tools available to filter json/ucl output >> yes they are. vim is one . sed is another. awk is the third =E2=80=A6 = But a pipe needs both ends to talk the same language. I can generate = json as output, i can filter it , but what tool in FreeBSD will accept = it as input ? None. A >>=20 >>> and my forthcoming uclcmd >>=20 >> What uclcmd does / will do ? =20 >=20 > It can read, filter, and write UCL (as well as JSON, YAML, and = msgpack. > Hopefully it will be able to do NVLists in a few months). >=20 > It is designed to be able to view, extract information from, and edit > config files. >=20 > AsiaBSDCon Paper: > http://allanjude.com/talks/AsiaBSDCon2015_paper_-_UCL_for_FreeBSD.pdf = >=20 > BSDCan Dev Summit working group: > Wiki Page: https://wiki.freebsd.org/201506DevSummit/UCL = > Slides: = http://www.allanjude.com/bsd/BSDCan2015_-_UCL_Working_Group.pdf = > Additional Slides about libucl: > http://www.allanjude.com/bsd/cebka_BSDCan2015-UCL.pdf = > Video: >=20 > BSDCan Presentation: > Slides: = http://allanjude.com/talks/BSDCan2015_-_UCL_for_FreeBSD.pdf = > Video: https://www.youtube.com/watch?v=3D8l6bhKIDecg = >=20 >>=20 >>> UCL is a good solution to having a universal config file, and is = better >>> than the bespoke config files each utility has >>=20 >>=20 >> I agree with you, if you manage somehow to port every ad-hoc database = FreeBSD has in base to ucl, (including all the bestiary we have in /etc = ) and offer tools to parse them in the rc init system to fetch the = settings. I dont expect this to be done in one release , but do you tend = towards this in your projects ? One config format to rule them all is = good. Yet another config format in selected places in base is evil. >>=20 >=20 > The goal is to change everything, and I am making progress. The = working > group at BSDCan had quite a wish list of things to convert, including = a > bunch that I figured people would prefer not to touch, like login.conf > (I need to polish that patch and get it up for review) >=20 >>> A transactional database >>> might be better (for some uses, likely less so for some people), but = I >>> don't hear anyone volunteering to do that work. >>=20 >> IIRC Solaris uses sqlite. Might be a decent solution. ( a lot of the = ad hoc unix databases are relational databases in disguise, with unix = tools acting as operators) And if you abstract a config interface API = over UCL, someone could benefit from it by plugging in a transactional = backend one day. All you would have to do is not directly plug in UCL, = but work on a orthogonal abstract API. You could even model it after = UCL API. >> Please consider it.=20 >>=20 >=20 > For bhyve, the basic design they have in mind is UCL config files that > are parsed and presented to the application as an nvlist, which it = then > passed between modules of bhyve (like networking, out-of-band access, > graphics, disk (vmdk, qcow, etc)), without the base bhyve application > having to know what config options modules actually support. It seems > like a reasonable design to me. >=20 > I don't know that further abuse of sqlite is actually a good idea, but = I > am still a bit new at this. >=20 >>=20 >>> I would welcome competing ideas/solutions, but someone would have to = actually build them, not just >>=20 >>>=20 >>> lib-izing all of the utilities instead of using libxo is a better >>> solution. It would likely be gratefully accepted if someone were to = do >>> it, but most likely, no one will. >>>=20 >>> libxo exists now, and most applications can be converted very = quickly >>> (although care does need to be taken, and it sometimes has not = been). >>>=20 >>> There are tools available to filter json/ucl output, namely = textproc/jq >>> and my forthcoming uclcmd >>>=20 >>> One of the major other consumers of the json/xml output of libxo, is = web >>> control panels. This is why Juniper is doing the work, and I can = think >>> of a list of other appliance vendors who would love to replace = fragile >>> per-application parsers with a json parser to extract data from = various >>> command line tools. >>>=20 >>> UCL is a good solution to having a universal config file, and is = better >>> than the bespoke config files each utility has. A transactional = database >>> might be better (for some uses, likely less so for some people), but = I >>> don't hear anyone volunteering to do that work. >>>=20 >>> So, libxo and libucl may not be the very best solutions, but they = are >>> the ones that are moving forward. I would welcome competing >>> ideas/solutions, but someone would have to actually build them, not = just >>> rattle off some ideas on the mailing list. >>>=20 >>> --=20 >>> Allan Jude >>>=20 >>=20 >=20 >=20 > --=20 > Allan Jude From owner-freebsd-current@freebsd.org Mon Nov 16 18:18:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 149BDA30FC6 for ; Mon, 16 Nov 2015 18:18:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D44C21E00; Mon, 16 Nov 2015 18:18:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbf6 with SMTP id f6so5735494igb.0; Mon, 16 Nov 2015 10:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4OVBjBmtgTr9nGyatkU8SCeg3N6qI5qyHiWn3ffu1jw=; b=ZhEQZWfF5v8mkfqHptfPHEQ0OYJ8KfKGwmBiski5YmUoghhcjLv+nffCVX4canQy/j HKBFJS+zayuVDwG5lVBYpuBUjzcaOCuf5RGYasp0miQ7lqAAYTZ76BS+hHNrEJe33wYc tHtNJ09yrfLBsKuwP6t+yhff64O7vZyl3aJSn7OcEPqzGAHRu8VSicPztLJAXiQWWqpT Csttk/OWy93hyItm0vIm6E1sIcuxh8TSjhbAbYvE9RSUdJErX19cKQYHhI8fK0yDoPtV JJ7mtSuCh270eW5Kc6FM7fbNLpqcssLV8myUQ4HPDvbqD+9gc334dGldbFFyk6Fr8c3d ZN2w== MIME-Version: 1.0 X-Received: by 10.50.136.226 with SMTP id qd2mr18337700igb.37.1447697912253; Mon, 16 Nov 2015 10:18:32 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 16 Nov 2015 10:18:31 -0800 (PST) In-Reply-To: <7F8C680E-5718-4AE5-BEB6-50D4659EBDB4@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> <564A0D9D.1060400@freebsd.org> <7F8C680E-5718-4AE5-BEB6-50D4659EBDB4@rdsor.ro> Date: Mon, 16 Nov 2015 10:18:31 -0800 Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Adrian Chadd To: Dan Partelly Cc: Allan Jude , freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 18:18:33 -0000 On 16 November 2015 at 10:06, Dan Partelly wrote: > Thanks for the details Allan, > > To be frank , Im not expecting any warm response. It wouldn't bother me i= f you would all have answered me like rabid dogs, as long i would get answ= ers to some questions I have. Oh, I hope you don't think my responses weren't warm. I mean, I'd like to see this fixed, and I'd like to see the libxo stuff morph into a much bigger, more comprehensive solution. But we had to start somewhere. > > Libxo is not horrible per se, but adoption made me painfully aware of a d= eep problem in BSDs, the aforementioned issue of binary code reuse. The pro= blem is a very difficult one, indeed, Microsoft for example worked for dec= ades on it. Libraries, framework, ATL , COM technologies where all attempts= to solve this issue on the Windows platform. And i dare to say they didn'= t managed to solve it completely :P Juniper open sourced an implementation of what they've done internally and they've worked on it in github in a very open fashion. It's been a bit rocky, but the libxo developers have been responsive and IMHO pretty swell at being on top of things. > > What I wanted to see if there are developers who aknowledge that there is= an issue with binary code reuse, and if there are any plans to solve this = proper. (see the end of David Chisnall message ) > > Also, you , the developers, are in much better position than outsiders to= make the FreeBSD aware of those issue, and , start some projects sponsored= by the foundation. You are the insiders, you are the ones which are closer= to the decisional factors in the foundation of where the money will flow. Hi, So we in the freebsd development community know it's an issue and would like it fixed. But the freebsd community developers aren't exactly flush with money or time to go work on all the pieces we know are broken and need working on. We all do what we can. Now, companies and groups like the foundation can and do sponsor work. The foundation would like to sponsor projects like this; someone just has to write up a proposal and send it to the foundation. But the proposal has to include actually doing the work. If you'd like the foundation to be more active in this area then I suggest talking to the foundation directly. We all know and agree it's something that should be addressed. I plan on attacking the binary code reuse a bit by turning the net80211 bits of ifconfig into a library and starting to use it from other places. I hope other people follow suit. If you'd like to participate and aren't afraid of a bit of C code then this could be a fun introduction project! -adrian From owner-freebsd-current@freebsd.org Mon Nov 16 20:31:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C08BA30084 for ; Mon, 16 Nov 2015 20:31:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id E284D1238; Mon, 16 Nov 2015 20:31:00 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.102] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 0B9671F14F; Mon, 16 Nov 2015 22:30:59 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: Date: Mon, 16 Nov 2015 22:30:59 +0200 Cc: Allan Jude , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <2CC95A67-50CB-4376-B6F1-7304DD8CA90E@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> <564A0D9D.1060400@freebsd.org> <7F8C680E-5718-4AE5-BEB6-50D4659EBDB4@rdsor.ro> To: Adrian Chadd X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:31:01 -0000 Hi Adrian, No, no, none wasn't unwelcoming or cold. Thanks for your responses > I plan on attacking the binary code reuse a bit by turning the > net80211 bits of ifconfig into a library and starting to use it from > other places This is great news. ifconfig is an obvious target. I personally am more = interested in the part dealing=20 with ethernet from ifconfig, but if you are willing to help/mentor and = direct the effort maybe we can arrange something.=20 How do you propose to proceed from here ?=20 dan =20 From owner-freebsd-current@freebsd.org Mon Nov 16 20:34:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EACBCA302FE for ; Mon, 16 Nov 2015 20:34:00 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id DAFC319BE; Mon, 16 Nov 2015 20:34:00 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 23A7A66F; Mon, 16 Nov 2015 20:34:01 +0000 (UTC) Date: Mon, 16 Nov 2015 20:34:00 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <830924306.29.1447706041073.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1467870686.25.1447695241454.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1467870686.25.1447695241454.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1699 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:34:01 -0000 FreeBSD_HEAD-tests - Build #1699 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1699/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1699/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1699/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Mon Nov 16 20:54:42 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10FFDA306F0 for ; Mon, 16 Nov 2015 20:54:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE78413DF; Mon, 16 Nov 2015 20:54:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iouu10 with SMTP id u10so167093161iou.0; Mon, 16 Nov 2015 12:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x7tMeTzHae5k7cpXvvNVvj86uX5GVusM0T72ejU0ElQ=; b=ZTiwba6QFB0Tk9ipvgRQ5O/23PtXERK4UcsHXWrgdi3pA/ebspsYEgy7MQorUIPy0v 9t6oqq2CrjTtJR4wlDwZW312SuR5sVryBekVXrFaaNQqBM8Cy9APnHt91i9uMh/LaN5g emgoab/QvossuOVBNFeeR/kcY/HswbDR8c5y9p7/VWeq3ls6WF90VDeUucDpGt+COdtZ aEX/mMIwSm5BIyqztvyi6zv5rpwqt+xSeyJeAgXNQdVSWznsKWxAhLzo3Mv74s4JGZza mIEWAE9R8/SjRPSKhcLyK22YvrR9tMlpFEjHaNR7JA7Gf+g0/CXNK9Gn7YwhacJTfxJ/ yNbg== MIME-Version: 1.0 X-Received: by 10.107.11.147 with SMTP id 19mr8979463iol.165.1447707281328; Mon, 16 Nov 2015 12:54:41 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 16 Nov 2015 12:54:41 -0800 (PST) In-Reply-To: <2CC95A67-50CB-4376-B6F1-7304DD8CA90E@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> <564A0D9D.1060400@freebsd.org> <7F8C680E-5718-4AE5-BEB6-50D4659EBDB4@rdsor.ro> <2CC95A67-50CB-4376-B6F1-7304DD8CA90E@rdsor.ro> Date: Mon, 16 Nov 2015 12:54:41 -0800 Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Adrian Chadd To: Dan Partelly Cc: Allan Jude , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:54:42 -0000 On 16 November 2015 at 12:30, Dan Partelly wrote: > Hi Adrian, > > > No, no, none wasn't unwelcoming or cold. Thanks for your responses > >> I plan on attacking the binary code reuse a bit by turning the >> net80211 bits of ifconfig into a library and starting to use it from >> other places > > This is great news. ifconfig is an obvious target. I personally am more interested in the part dealing > with ethernet from ifconfig, but if you are willing to help/mentor and direct the effort maybe we can arrange something. > How do you propose to proceed from here ? I'm goign to start by taking the net80211 regdomain code out of ifconfig and putting it in a library. There are some ioctl calls too to manipulate the net80211 state and query it for things like scan list, etc. I'm also going to try and pull those out into a library. If you'd like to tackle something like this in ifconfig, I'd start by say doing the same with software bridge support. It should be relatively self contained and be a good target for turning into a library. -a From owner-freebsd-current@freebsd.org Mon Nov 16 20:55:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B5E2A3077C for ; Mon, 16 Nov 2015 20:55:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BB51158B for ; Mon, 16 Nov 2015 20:55:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by qkfo3 with SMTP id o3so123395745qkf.1 for ; Mon, 16 Nov 2015 12:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd_org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=qSXWsZ5qZJFTCHECfGdlUGjVFK4q1mj4E4h01MIte68=; b=TrkgyapZ08CJRvhgwnBKbOukrZmapvmP5EeW7RQOKEmP7JTaT++kfAGEbnPlpplp38 lqw/V3idWQh2XX8azHnlRwVpLmMHn9VOBEoMSKRoo9x2R8hxnE+Ubzu5pMq5Ao2yKGXP tPmBPvFIXOPpSSR7iVa2W3zlOF311ADxnARNr0AhFuHa/Ce3I4XsJZ9n57xfscmhUT+Y kw6QlQXHr26SI2q2WmL0qKxLUF4Pzsyi0Sj4DIGHfhyAq20RAExxoFY0Af6NZA2fsdv+ XhUkpQ0E/y2HP31aRNb0S5dR50gRHQSlAy08AXmFlMdrdHtFyXjLbWPDvg6rLvZ5jXye hhRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=qSXWsZ5qZJFTCHECfGdlUGjVFK4q1mj4E4h01MIte68=; b=Xm45WDVDN3uMvR4jA5BI8Je62dXPp4JI8sMwEvpLKWlefCgJeTdEYiRwphNXiV3wwb 69kVIDWhnUnCVvGE88sZC/h48lnl+d/R72BytGRXOmiKZ80dx1WDD/WA+0PVwaxngVpr dc+J6S/1H1tGaHCPwajxY6LVQg2rqVKyF2J9Rrde/xUck+Isyhk8LB6x+69EktMV1EhN mNqm2bOS+fWYEFKRvxXJYEN79jVDcurEwGAKDKnLb+RMoUHAMKKDlfOgWou57ptJFIcI vxUUf1jnIa3+4IalN3r0mYKoQIoSByuwWA9QZpCz1+wpxVUqvoFr5fRKb5wkh5phKyDS KmGg== X-Gm-Message-State: ALoCoQn8faujvtTl/obCFuODTlhluIkQbyMPwT8hKbMJWFjlt1yofrIy6dyWqtev4KLrB94HGy5IE+3udHEiGJfECfY9QJuBYce5zAE6XJ7ydBPq3QIA21OYxRweM8bc6xmxfnc2GU7Ec4vTGvZTJyt3dZNSgxtaT9qDa8P7up3Q7+ftkwga4KfG8LyuMrtJjXzS/nWBbOk9 X-Received: by 10.55.71.146 with SMTP id u140mr37562974qka.17.1447707335026; Mon, 16 Nov 2015 12:55:35 -0800 (PST) Received: from mutt-hardenedbsd ([63.88.83.104]) by smtp.gmail.com with ESMTPSA id k9sm8744580qgd.21.2015.11.16.12.55.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 12:55:33 -0800 (PST) Date: Mon, 16 Nov 2015 15:55:31 -0500 From: Shawn Webb To: freebsd-current@freebsd.org Subject: buildkernel failure Message-ID: <20151116205531.GA99595@mutt-hardenedbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:55:36 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey All, I'm experiencing a buildkernel failure only when doing a multi-job build (-jN). Doing a single-job build works fine. Below is the error I'm getting. =3D=3D=3D=3D Begin Log =3D=3D=3D=3D In file included from /usr/src/sys/modules/tests/framework/../../../tests/f= ramework/kern_testfrwk.c:34: /usr/src/sys/sys/bus.h:655:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. mkdep: compile failed --- .depend --- *** [.depend] Error code 1 make[4]: stopped in /usr/src/sys/modules/tests/framework =3D=3D=3D=3D End Log =3D=3D=3D=3D Thanks, --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWSkLAAAoJEGqEZY9SRW7uRZ0QAMWXo8agsX3/g7LQytcwjg7v DvIwSuIKzww3jzE+BYv7H06Hk+ETdnnFMR1NHz8dRbYWPVTMJ5OyWUeySXIIKzr1 e29G9VhZmUoO6DDt37l2hzou7bVb8vhFkwL+4cI9dHMjnZ8vN1b9+RaMNN1yPqyq ANmryk5co8o0oFKPtU49p5llCXoAtegJ814Ea3f81ZcQ680tqeAFxGkfwetqjK3W Edgn3qkyk6pnVN5hetv95gjyzknws4kZLTzRTm9LKDgz0WxU+8z7e27QCDwxuL5p z7lDWaUYE+PV54C/Vo6Lz+OF5E2PP33sQ8j461e/Owpk2ZQf1bej0Oi5cCVKF1pX 7VzDwh0a5mOHUbot7V4p4qFy6SBu2bJjfxC3QGO84YGphiFJkD4f5Gzx6dyUCpOq zKhltDZ8Lp1fZj8lBLGF0x0i+LvC4JvQMju3cnUE4x/W086/LZWP5XdZze4zsK89 +Jik9ootIXF4UB8qoMYjAiaFZcVg9gGdn+vTA31GdekI/iU5pB3MKYArVsuBZNtd gS7jVpZYEn5eb/8VEEsK05i9rlackDAZlmhvUJb37hfXh13nWoG9aHH1CY0aRXlc VSG413bXxaPiqg/XicbAwexHzPhJxT4Xolcr0J7Wu0h9xH/G0KN6CeTF2K6621tb sodCQqeMEFZOCOlLkpxh =cbsK -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-current@freebsd.org Mon Nov 16 20:59:32 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CB7BA30907 for ; Mon, 16 Nov 2015 20:59:32 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20BC619C2 for ; Mon, 16 Nov 2015 20:59:32 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by wmec201 with SMTP id c201so138679395wme.1 for ; Mon, 16 Nov 2015 12:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mQaefTAqc8ORAgxOqP7wL/FVSshmBP0zg37hgM2vt0o=; b=pv2Kb+uzL3gUDQVrCRXV/UxbPm97qaQ+4SUadwtSJNHVca4m6Xn8Ur7avMnj4b4Ufe dMjWtlsmVZzq6d0adRu3CG7MD7KClQ6ap1OWn40lSWNalu5PLQ4KEDVHv9NKcSirQAXw AGMyyXB0V0opT+ZOTAByELKRzV84y+L22l6PEFHnRKU1TF9jmXuZkbi1hsuv51eUjMJz y7dNt/X6Q/0eCAt8wTI0+Oliy/Frh+P/CUtW93MBWYaEKpdL6DKwSa+qqjUHdgRHsrQm emVbF1f/6Y0E0sZlszFmTXzgHIvSAsYvzFx/1LrKakQtQX4tMBbURq93QEC8waJQCcWD yaUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mQaefTAqc8ORAgxOqP7wL/FVSshmBP0zg37hgM2vt0o=; b=Hv2khVbnjmjniQLcnY//Aa3/HBAZ8AzMxsQ7tqZoDTq95dels+yt/zyrGMd287kM5U dAUTgKg2bNTqgisbeLw70pDui/S/46qNcOE3ZrDRbWbD4Ax6xtU7zn66fwk9RyYqPhW4 6jLmH2foIH8HJxwbqL8vnTxVavQvQO5luIQJ6EdRDte9QtP8v2NrJ+MQLwYuizY1MGOP aa/Q+qXGvvJzgESBJ9kwxsGMSbvhfbHSOMDFsRiXTIyomIG2oaRfz331SIiFhqCAsO5K TXOmN/jEwoZ7rOoa4AqU6AndGf3y2NeyD01LrIRToWxV0UP8VXntA89PGSeCiVeB7EbX laLA== X-Gm-Message-State: ALoCoQnkbdjnSdaF7837Wt2DdaOfs0dKSjwJQoSiXcsb6K+s7n9tDNpm83I49CmkfDp2xSWKNwWl MIME-Version: 1.0 X-Received: by 10.194.116.100 with SMTP id jv4mr37511103wjb.67.1447707570214; Mon, 16 Nov 2015 12:59:30 -0800 (PST) Received: by 10.194.158.225 with HTTP; Mon, 16 Nov 2015 12:59:30 -0800 (PST) In-Reply-To: <20151116205531.GA99595@mutt-hardenedbsd> References: <20151116205531.GA99595@mutt-hardenedbsd> Date: Mon, 16 Nov 2015 21:59:30 +0100 Message-ID: Subject: Re: buildkernel failure From: Oliver Pinter To: Shawn Webb Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:59:32 -0000 On 11/16/15, Shawn Webb wrote: > Hey All, > > I'm experiencing a buildkernel failure only when doing a multi-job build > (-jN). Doing a single-job build works fine. Below is the error I'm > getting. > > ==== Begin Log ==== > In file included from > /usr/src/sys/modules/tests/framework/../../../tests/framework/kern_testfrwk.c:34: > /usr/src/sys/sys/bus.h:655:10: fatal error: 'device_if.h' file not found > #include "device_if.h" > ^ > 1 error generated. > mkdep: compile failed > --- .depend --- > *** [.depend] Error code 1 > > make[4]: stopped in /usr/src/sys/modules/tests/framework > ==== End Log ==== And some more occurrence: http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/299/console http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/298/console http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/297/console And when building fine: http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd64/300/console > > Thanks, > > -- > Shawn Webb > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > From owner-freebsd-current@freebsd.org Mon Nov 16 21:04:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B229A30AF9 for ; Mon, 16 Nov 2015 21:04:10 +0000 (UTC) (envelope-from gad@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8107B1DA9 for ; Mon, 16 Nov 2015 21:04:10 +0000 (UTC) (envelope-from gad@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 858) id 7FD2D19E9; Mon, 16 Nov 2015 21:04:10 +0000 (UTC) To: freebsd-current@freebsd.org Subject: libXO-ification - tangent on JSON choices Message-Id: <20151116210410.7FD2D19E9@freefall.freebsd.org> Date: Mon, 16 Nov 2015 21:04:10 +0000 (UTC) From: gad@freebsd.org (Garance A Drosehn) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 21:04:10 -0000 First let me say that I wish I had more time to contribute to the project, but I seem to be caught in variety of long drawn-out hassles in real-life. Otherwise I would already know the answer to this question: Is there some specification for what JSON is created by the various FBSD utilities? I did not see any discussion of that in the earlier threads on this. I don't mean "what is syntatically correct JSON?", I mean some kind of guidelines of what property-names would be used across commands, and what values should be for those properties. I came across the following project while watching a series of videos on youtube. I think I started out watching something about Clojure, or ruby, or d-lang, and ended up at this: http://jsonapi.org/ http://jsonapi.org/format/ And I must admit I haven't even taken the time to read the whole spec, but what I did read seemed interesting. It doesn't cover much, so I'd expect a spec for freebsd command outputs would need to be more detailed. Is there such a spec already written up, at least in a rough outline? -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-current@freebsd.org Mon Nov 16 22:03:08 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFBCCA317B9 for ; Mon, 16 Nov 2015 22:03:08 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0132.outbound.protection.outlook.com [157.56.111.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D77513D1 for ; Mon, 16 Nov 2015 22:03:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from SN1PR05CA0039.namprd05.prod.outlook.com (10.163.68.177) by BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) with Microsoft SMTP Server (TLS) id 15.1.325.17; Mon, 16 Nov 2015 22:03:00 +0000 Received: from BY2FFO11FD015.protection.gbl (207.46.163.237) by SN1PR05CA0039.outlook.office365.com (10.163.68.177) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Mon, 16 Nov 2015 22:03:00 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Mon, 16 Nov 2015 22:02:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Nov 2015 14:02:59 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAGM2vD78065; Mon, 16 Nov 2015 14:02:57 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 7C57D580A9; Mon, 16 Nov 2015 14:02:57 -0800 (PST) To: Dan Partelly CC: Adrian Chadd , freebsd-current , Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? In-Reply-To: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <26127.1447610752@chaos> Comments: In-reply-to: Dan Partelly message dated "Sun, 15 Nov 2015 21:48:51 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22937.1447711377.1@chaos> Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Nov 2015 14:02:57 -0800 Message-ID: <18325.1447711377@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD015; 1:gIZRlJPet4hvxyKtpECaPzKk6c3EKduQnEJunmX4OdE0S4gmuwTwQid9jUeutg4bLh7j66sZUqpOelxL2zuwgZlc45yLppZy8T9DvK93Rb7wNxI4vYIkiyIQUIuQJFmq39FiRxesR/fLhMaqqLtGrBWaiaMM9J3Wpx1UHUMtCOlFqJdNtvMY4suh4id4Yogggv19iJ74gqVIdyBp7ex0f4U+nyz0E/qjD9HRx3GuF4dUpihDVFnHYIOHuLTtffRc7uxr7uZmrm1NIN0JKNvGf7SIqkRiNAszhn9kCP8rr3AN1vWggewcZqs3e4I5XUDmIV2A9xzLE3M+2FIf2Kq5zzywKALNMAmwlLI/tT6AUiP4uLOeB13sTMISnEDhwQMj X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(24454002)(2950100001)(97756001)(57986006)(23726002)(50466002)(93886004)(77096005)(86362001)(69596002)(50226001)(19580395003)(76176999)(19580405001)(76506005)(50986999)(21840400001)(6806005)(4001430100002)(107886002)(33716001)(189998001)(87936001)(97736004)(586003)(5001960100002)(81156007)(11100500001)(46406003)(110136002)(92566002)(117636001)(5008740100001)(105596002)(106466001)(5007970100001)(47776003)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB054; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB054; 2:LCXw9nTdh/2ggUijS7nxVvvPnHE+Y7emTtboSlcI2myjs3pIF/kl1ZXhC9hjhUdjSDx82t4Itla78bv5L5wULeUqMOd/vzk3ExeYGy6A/2qy8YEa7MJ/D3vGC0PymF0ZsgtMyfEkoZNwA2gzHje/sizISMhVLHA2N36k0sFEZts=; 3:BEI/6iZmnjMxTa7I0JE2RdQjh44jVJHtVaiJ3xel/fUegXLa4YbSr2WrNB/BOPHenzfq/XZRbjEvvEORFK3q4Bb8VymZO0FgCU5GZrk6kDh4LZlzXoHmr47W9+9jV7WrQbvw0TZz/yz5YpYIH8nfV+ocTeqvYOpaFFaHKz5HpgRhpp2fB6zWkm/dm4cGun6zPmnmSnpMPGlA+IOOEM+RYG/yFgfbBHxYe/u9ci3rVJg=; 25:NxhrNY7QeHRZ/u6g6f8Lr9HKge1O+bFd6GcbhatFKdMkqFB9ulqBihFpG5L3pYUiF/4ODesSAL38KzD+oQBocuAhs+zdV5ECHlq69Ry05hLTJ11P72BvfwiXDEKdwf3D+0Q9ObUrWNm1/vZFY7ws0tSaB9TB/gPedJprLM/G6YTaSN89iLnQuGieNNuxggswMfzw+PRbYiNhMruEaZi+ZkH8jKoyY+tKRuxxXjPuuj+WnFYcud0OqxwUE1iseK+8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB054; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB054; 20:heLxyGvwPgumoKm96w6T41N4vIZrWBgT9YBHNbSHi6KgUf/Dh9WwBvOKz8naO0/ISQnpN+56ZFSQXKfvznD7qaHUxAEO9/t+TDECy0FEfwaEi4H/ji9AQH7JoTHF8BAnifrMKOrQmXEUsDMX2YyztEQIoYEskVyC51nIx/NkhpKnzjoG0vxben1szBBVesBS/XMUgb/Kgwomso7+A0N059O/2FwNrZsLR91jY26fNaj4naCDbZN+kfi7WqCbH09J+Mmu0JCH/NXr3wn+Uwy3siCu5WABlvLamrKQEtp2zEPom/Y7TqLSwjsiqLCh+jGl9/c3eSJ+EMr0D2SkT8ffkraW4V1OuDLHvVoD4Je9Kn4AUVvBNIr26KIFz4WpQ/w/33byRxF5S9D6CvEahLQ1/Cg2bTDhk4GvWVfggtpKu8FaAA2ITDXb4IuctZ2PiEn42g/kwGhITXY9QYZUo+5gJstdYk1AuhgFyJJcQBnp+WmNUx18u+Tf0N7a2gv801xt; 4:n8LPQtwsEKb0fQTxAzq/GTJjwZd+5kL2ywFTnb0UqXDcz4GSg8SHthusUo+pFbO66mUr2WHyCN2KJ8x5GpKmDwspG6NFO5zM1BqC8yqggNUJbfPd25nSyElMNpoJ1hx5/BmvE17PeHPHENcjjgotdGllVvrr1NbomNdWCj/aaiDHS2/WAiwHwqq+MW2mOG9WdgjqeFXfW8InKOOcF8dT0nTcrR2lcNOwyuQ5sOkU+hjopvLi413CLWpY7s0Xnxq9eYrtwVaICSC9KsUgQ3i/qoupg16Ux5Vqxp3qMwKQbdwZ2wVbbfT5dDSDxWXX/rIQU3o63Rv5pv0mQPFADp6DIR+gxtFo42cMngtOxq6PCmSUPhMlmyoHOknT7K8RcqX8 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR05MB054; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB054; X-Forefront-PRVS: 0762FFD075 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB054; 23:n1R99N5kmSKCEP/zIuPqTgTSUV3qlW/Q6TGwq4umjQ?= =?us-ascii?Q?CQYiCpjYGkrT463r/kp0yCLnYnLv9TBBeenPhlnGYNYbp6jykk7JJZQsbiLi?= =?us-ascii?Q?pcGuvX25YSVSAmMP1cUN/tWsREbEOT6/y31aexJgcgeCe1UUpCtZ8QfRXL6I?= =?us-ascii?Q?tieMCrZdvRxyDW6N+aM8maBtQuRGfY6LOkMcvDIQP5W0lo/BVTR+rBnqIZ2u?= =?us-ascii?Q?+iexo9LAO84+LLlsE8ANBEfdahRtTabXQ4dw+1cjae0gOMkliu89XEjbzw+c?= =?us-ascii?Q?AClP85HsHvnAXmJBwEBCoGfuNR8MMCVqJ0cIv25zAZE1PdHOIG7lgsgu8Ucb?= =?us-ascii?Q?Iv6JgS7nrKEiPVX4oebGthQgY6cDiWbMGu2f1LhQi3q4TBTFeLhEtrkb26U6?= =?us-ascii?Q?qxAJhSKGLQWT+g2s7mvzS6TOiEALhfV32ed7NIp6A+U7r1H798mHwe43lQZU?= =?us-ascii?Q?hNoRJx6GmVeUCnZJJlBG8+Nc8LDzPpnQNENyUKEbgE++AFCs2DA+mwZNAhqd?= =?us-ascii?Q?XN6URaCzz5q9FdEF7SNDKTg+JbJamJLBCJK0yqrj6AY5PNZluQHKK3F+zCKX?= =?us-ascii?Q?9fop1UV0jDnyzj77qD7+7b1b1bG1ycJtQyKlHkq1SD8yG7EoMECzJovFNaVs?= =?us-ascii?Q?wWEkG0IOVucNcn5cE1jsl7AkYI3HPTEls9Eh9VYv0Pk+e2WrcLeMo36ga5SM?= =?us-ascii?Q?ncbFxMGGobhWDHaQTGnszU/sCAkM67ZIzyghFiyL5fTiHBaBp4UhUu15FkG6?= =?us-ascii?Q?ilwVEV10kmMaqofwguD4x6YtTz3QPAg1QIvPzX2RRS1i8MkD7wFiNgyFqe3R?= =?us-ascii?Q?HiZmBQ8imgcNIDCfE8VxhicvJESVNuJ0Td8plRM2kGLPXuF0ak5I4O69Tij5?= =?us-ascii?Q?P1/i6/6/Cce2Fc3iWKFpYRX3cAqFBMhfPv/D8wTgyFGhEnSoyIbJvcrUIhg8?= =?us-ascii?Q?LABu11mxzgg4cZ6ZU3hPVL3e98thfKNv3mY8BV1K0EGy4DFvAQTnDGZCpfkl?= =?us-ascii?Q?lqZZ1lGODMmttYbDUPR13QEXfveh6DRix6mINIGXKEjXAvU/5L5JyTskOfIo?= =?us-ascii?Q?D23xcGCE5mVF/WHTMbhmLWbDVSWdWtfjJDRM4+cIeshHsgqaB5rfzOY1vH0b?= =?us-ascii?Q?4kyOgv1JA3j4l1VUybM66H9tNMb/GU?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB054; 5:42r5dh0Sld+MfBGM6u1OzHl77Ch/Yb/w7g6gaZCbEBfb2zPc1wVEc+EsbJ81WwoHvZA41MqHK1NkgvbmyWoP3vLWKEjf7CY8t25fTmzvvfwi74uzLaIVa/b5NVdeMV16qyZuzDPrAvsoAGm8fb6TzQ==; 24:uC8+210FVBVlLNoRbWGkpPEagFLpfbLc/Ee+Yob98IJS943lEkgAxWu3e0BuaIeuMEvp/8uTAKteNk2KKqlCehPpt73TMfYlRnHKUzvXKT4=; 20:Im+XiXb0ran0lWChoUNtrTi++9ZGhOfv8PGu8maZvFde9z208Cucm/NGuZAC/6iufj0Wo/PVW1tLfNS0xf7Wow== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2015 22:02:59.6631 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB054 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 22:03:08 -0000 Dan Partelly wrote: > >> The ability to get machine parsable output from OS components is a bi= g part of the success of Junos CLI, netconf etc. > = > Once you get machine parsable output, and feed it to your GUIs , WEB, > other tools, and modify it, how do you feed it back to your underlying > OS ? We didn't make any changes to the way tools are run as there was no need. All requests - whether from CLI, NETCONF etc, are channeled into the MGD (management daemon) to verify input, permissions etc (Junos implements very fine grained permission system), and act accordingly. From owner-freebsd-current@freebsd.org Mon Nov 16 23:31:53 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60F54A305B7 for ; Mon, 16 Nov 2015 23:31:53 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 53FF8178A; Mon, 16 Nov 2015 23:31:53 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9421E6EA; Mon, 16 Nov 2015 23:31:53 +0000 (UTC) Date: Mon, 16 Nov 2015 23:31:53 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1881894481.33.1447716713508.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <830924306.29.1447706041073.JavaMail.jenkins@jenkins-9.freebsd.org> References: <830924306.29.1447706041073.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1700 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 23:31:53 -0000 FreeBSD_HEAD-tests - Build #1700 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1700/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1700/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1700/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Tue Nov 17 00:31:09 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2EFEA3131E for ; Tue, 17 Nov 2015 00:31:09 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3910D1185 for ; Tue, 17 Nov 2015 00:31:08 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-f79d06d000004b20-1a-564a74172c46 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B5.22.19232.7147A465; Mon, 16 Nov 2015 19:25:59 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAH0PwBm014040; Mon, 16 Nov 2015 19:25:58 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAH0PttL009021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 19:25:57 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tAH0PseH014087; Mon, 16 Nov 2015 19:25:54 -0500 (EST) Date: Mon, 16 Nov 2015 19:25:54 -0500 (EST) From: Benjamin Kaduk To: Warner Losh cc: Justin Hibbits , FreeBSD Current Subject: Re: CFT: uintmax_t rman In-Reply-To: <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> Message-ID: References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUixCmqrCte4hVmcG6DtMWVvdtYLOa8+cBk 8XTrckYHZo8Pu7+yesz4NJ/FY+esu+wBzFFcNimpOZllqUX6dglcGf3nZ7IVvBOoeNGygqWB 8SJvFyMnh4SAicTUlWeZIWwxiQv31rN1MXJxCAksZpKYe/MOE4SzkVFi8e+pUM4hJomP24+z QzgNjBJz1t9mBelnEdCWODrtPNgsNgEViZlvNrKB2CICChKrjtxlAbGZBRIlujf1s4PYwkDx X6eXg9VwCthJbF/1CqyGV8BRYs7dbiYQW0ggT2LBxalgtqiAjsTq/VOgagQlTs58AjUzUOLG tXOsELajxIcXr5gnMArNQlI2C0nZLCRlELaOxM0Zi9kgbG2J+zfbgGwOsJoF6yoXMLKtYpRN ya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECI4bSf4djN8OKh1iFOBgVOLhbfjrGSbE mlhWXJl7iFGSg0lJlFeh0CtMiC8pP6UyI7E4I76oNCe1+BCjBAezkggvVwRQjjclsbIqtSgf JiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgvd2EVCjYFFqempFWmZOCUKaiYMTZDgP 0PCNIDW8xQWJucWZ6RD5U4yKUuK8S0ESAiCJjNI8uF5wWtvNpPqKURzoFWFeg2KgKh5gSoTr fgU0mAlo8IkGT5DBJYkIKakGxirO1usMAVK9f0Mf2Wrqp6/QqAxk7HjxMdZA9MDX7y1fj/uW WGSJ2s55FLjkwv3QH25WjE//zlGYaHl5TaPOv7Psh0QVyv32Lzt8Sn/F8vvW3wNnbDL8WifU O/HjIqGtO1w7Dn22Ko/3Xn99ilz4BBe1dkEBdcam9c/3sIjf3fSxVW29CN+6uUosxRmJhlrM RcWJAKoKwxdGAwAA Content-Type: TEXT/PLAIN; charset=ISO-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 00:31:09 -0000 On Mon, 16 Nov 2015, Warner Losh wrote: > > > > On Nov 15, 2015, at 9:13 PM, Justin Hibbits wrot= e: > > > > (Attempted to send this yesterday, but appears it didn't go through. A= pologies if it really did go through). > > > > As part of a project getting FreeBSD on the Freescale P5020 SoC, I incr= eased the width of resources, from u_long(32 bits on 32-bit archs, 64 bits = on 64-bit archs) to uintmax_t (currently 64 bits on all archs). I have it = working on PowerPC, but have not tested it on any other architecture, I hav= e no other systems to test it with, so I need help. This passes a tinderbo= x build. I need this tested on other archs, the more the better, especiall= y i386, including PAE. > > > > It should be effectively a no-op on most architectures, especially 64-b= it archs, though there were some checks I found in x86 code clamping addres= s checks to under 4GB, commented as necessary purely for rman. If this isn= 't the case, and we can't yet handle the checks being removed, they can go = in, but that needs testing. It should apply cleanly to recent head. > > I like the idea. There=A2s nothing offensive enough in the diffs to comme= nt upon here (though I suppose I could see a few spots one could quibble ov= er if one were so inclined). > > I wonder, though, why not make its own typedef, even if it is just > =A1typedef man_res_t uintmax_t;=A2 in the rman headers? Channeling my inner bde (maybe?), the typedef is probably helpful, but uintmax_t seems less so. uintmax_t has no guaranteed ABI, so a fixed-width type like uint64_t seems beter, assuming that uintmax_t is currently uint64_t everywhere (which I think is the case but did not verify). -Ben From owner-freebsd-current@freebsd.org Tue Nov 17 02:13:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CF31A30E54 for ; Tue, 17 Nov 2015 02:13:22 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 635141303; Tue, 17 Nov 2015 02:13:22 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8004:7515:6d56:aa8e:b437:27b3]) by elvis.mu.org (Postfix) with ESMTPSA id A601D345A921; Mon, 16 Nov 2015 18:13:16 -0800 (PST) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Allan Jude , freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> <5648CA60.3060800@freebsd.org> From: Alfred Perlstein Organization: FreeBSD Message-ID: <564A8D3C.2080900@freebsd.org> Date: Mon, 16 Nov 2015 18:13:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5648CA60.3060800@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 02:13:22 -0000 On 11/15/15 10:09 AM, Allan Jude wrote: > On 2015-11-15 13:06, Garrett Cooper wrote: >>> On Nov 15, 2015, at 09:51, Andrey Chernov wrote: >>> >>>> On 15.11.2015 20:37, Adrian Chadd wrote: >>>>> On 15 November 2015 at 09:10, Dan Partelly wrote: >>>>> Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? >>>> Nope and yup. The juniper folk had a solution to a problem multiple >>>> people had requested work on, and their proposal was by far the >>>> furthest along code and use wise. >>>> >>>> It's all fine and good making technical decisions based on drawings >>>> and handwaving and philosophizing, but at some point someone has to do >>>> the code. Juniper's libxo was the furthest along in implementation and >>>> production. >>> It seems it is the only and final argument for libXO existence. I >>> remember 2 or 3 discussions against libXO spontaneously happens in the >>> FreeBSD lists, all ended with that, approximately: "we already have the >>> code and you have just speculations". Alternative and more architecture >>> clean ideas, like making standalone template-oriented parser probably >>> based on liXO, are never seriously considered, because nobody will code >>> it, not for other reasons. >> We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't seems like the best idea in the world to me from a end-user sysadmin/developer perspective. >> >> I could just as easily use standard tools like awk, grep, sed, and more advanced languages like perl or Python to parse output, and assuming output doesn't get a major rewrite, I'd just go with that method that's worked pretty well for me over the last 10 years of my career.. >> >> > The big difference is, a json parser isn't going to blow up if a new > field gets added in the middle, and your awk/grep/sed script probably will. > Alan is exactly correct. This is EXACTLY why it is important. It allows us to focus on the text UI without worrying about the 5000 tools built to parse the output of the utilities. It allows us to grow a useful text UI. Second is that parsing is as simple as doing "json2struct()" in whatever language you're using and then selecting a field as opposed to writing terrible regex. It's basically "libification" of the program without actual libification. Next step is to actually libify the programs. Libifying the programs would be VERY, VERY cool. But "libification" doesn't make json output not useful. -Alfred From owner-freebsd-current@freebsd.org Tue Nov 17 02:22:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5461A310E6 for ; Tue, 17 Nov 2015 02:22:16 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id A29761938; Tue, 17 Nov 2015 02:22:16 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8004:7515:6d56:aa8e:b437:27b3]) by elvis.mu.org (Postfix) with ESMTPSA id 8D106345A920; Mon, 16 Nov 2015 18:22:16 -0800 (PST) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Allan Jude , freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564A0DD4.7030505@interlinked.me> <564A0F71.7060700@freebsd.org> From: Alfred Perlstein Organization: FreeBSD Message-ID: <564A8F58.6020907@freebsd.org> Date: Mon, 16 Nov 2015 18:22:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564A0F71.7060700@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 02:22:16 -0000 On 11/16/15 9:16 AM, Allan Jude wrote: > On 2015-11-16 12:09, Elizabeth Myers wrote: >> On 15/11/15 06:54, Dan Partelly wrote: >>> Hi all, >>> >>> I was looking at the new facility of dumping JSON,XML from many utils= in base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: >>> >>> >>> 1. Undoubtedly, it makes base code slightly harder to understand and = maintain. >>> 2. I have seen the idea that this makes the information dumped by uti= lities in the base easily accessible programatically. OK, maybe it does ,= but >>> it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I >>> dont see too many ppl changing their code to read JSON instead of tex= t. I don't even see the base tools changing. This output may be useful i= n corner cases only. >>> 3. The integration of libxo IMO only points at a much deeper issue IM= O. It is only an expression of the need of a mechanism aimed at binary co= de reuse. But it does not solve the problem, it only adds yet another pos= sibility in a world where too much choices already result in too much spl= its and incompatible APIs. >>> 4. This whole effort would have been IMO much better served by porti= ng the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, = much like the libs for geom, zfs , etc , ready for reuse of 3rd party cod= e. Eventually writing network control daemons in time over it , much like= solaris does. >>> >>> 5. A port of partial OS config data to UCL =E2=80=A6. would induce ye= t induce another orthogonality violation. What makes UCL better than the = bestiary of ad hoc databases already existing in BSDs ? Programatic reada= bility, yes. but it does not add any real much needed functionality such = as *transactional databases* for system tools. Why not research a prope= r solution - easily accessible by other programs ,orthogonal , transactio= nal, and ACL protected solution which can be used all over the place ,= from OS boot, to ABI management, service management, network management,= user management. I hope this day will come, a day when I will not have = to edit a single config file manually, yet I would have access to all the= config and system state easy with wrapper APIs. In the light of this po= int, why go with UCL ? It is not orthogonal, it is not transnational, and= editing the config files directly would result in the same old human err= ors which bite as all from time to time. >>> >>> 5. It is my opinion that Solaris addressed some of those issue. Solar= is FMRI and SMF are lightyears ahead of the very tired models we keep usi= ng on BSDs. Why not build on the insight offered by those (or even on the= insight offered by Windows :P) , then inventing more adhoc solutions and= ad-hoc databases, which do not address the real issues we have , like bi= nary code reuse, service management issues, lack of a system wide publis= hed -subscriber bus ( not kdbus :P ) fault detection and reaction, fault = reporting, all much needed parts of a modern OS. >>> >>> And now thee questions >>> >>> 1. Why lib XO ? Why burden the OS for some corner cases where it may = be useful ? >>> >>> 2. Was there any real talk on how to bring FreeBSD up to speed regard= ing those issues ? A period of research on what exists, on what can be d= one , and ensure important things are not showed in background and replac= ed with yet another ad-hoc config database which lacks modern features ? >>> From where I am standing, this could be a project spawning multiple = years , but it would be well worth it, and in my opinion it would be also= worthy of >>> the freeSBD foundation sponsorship for several years in a row. The fe= atures I touched upon became very important parts of oder OSes, and right= ly so. >>> >>> Note: >>> >>> this message is serious and it is not intended to start flame wars, r= eligious crusades, or offend anyone. >>> =20 >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= =2Eorg" >> It seems to boil down to the golden rule: he who has the gold, makes t= he >> rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD >> foundation and employ many devs, so they got their way. >> >> That's all there is to it. >> > As Simon pointed out, many more people than Juniper wanted it. Juniper > had a less generalized version of this in their own tree, and would hav= e > happily kept it to them selves, but they went to the extra effort of > generalizing it and cleaning it up to commit it to base, because at a > FreeBSD Vendor Summit, a number of other companies wished for the same > functionality. > > Even my small 3 person company greatly desires this functionality, and > this is why I have been helping to convert additional utilities to use > libxo. > > How big of a donor you are to the FreeBSD Foundation does not affect th= e > committable of your code. Having code ready to commit, vs just a vague > plan, does help your solution win out over another proposed solution th= ough. +1, my last two companies needed this functionality. Asking my non-platform team members to parse=20 ifconfig/sysctl/vmstat/iostat/etc output was ruining my day and their=20 day, every day. :) -Alfred >> -- >> Regards, >> Elizabeth Myers >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> > From owner-freebsd-current@freebsd.org Tue Nov 17 02:24:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02A0EA31154 for ; Tue, 17 Nov 2015 02:24:19 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E6EC31AA8; Tue, 17 Nov 2015 02:24:18 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8004:7515:6d56:aa8e:b437:27b3]) by elvis.mu.org (Postfix) with ESMTPSA id 7C87A345A921; Mon, 16 Nov 2015 18:24:18 -0800 (PST) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Dan Partelly , Allan Jude References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564A0DD4.7030505@interlinked.me> <564A0F71.7060700@freebsd.org> <7644107F-8C34-431D-9367-680A609BE7F5@rdsor.ro> Cc: freebsd-current@freebsd.org From: Alfred Perlstein Organization: FreeBSD Message-ID: <564A8FD2.8090908@freebsd.org> Date: Mon, 16 Nov 2015 18:24:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7644107F-8C34-431D-9367-680A609BE7F5@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 02:24:19 -0000 On 11/16/15 9:39 AM, Dan Partelly wrote: >> How big of a donor you are to the FreeBSD Foundation does not affect the >> committable of your code. Having code ready to commit, vs just a vague >> plan, does help your solution win out over another proposed solution though > > Then surely you will salvage something from a lot of GsoCs where people wrote code with various degrees of success, only > to never hear again of anintegration, or an evaluation of that code, and possible integration. > > One which directly interests me: what happened to the BSD libctf code from GSoc ? Was the resulted code evaluated ? If > it falls short, where it does ? Can it be salvaged ? > > Libxo might be a fine facility to have for some corner cases, but it doesnt solve the problem of binary code reuse in general. Might have solved it fast for Juniper. It is yet another stick into a scaffolding of shell scripts which should have been replaced years ago with proper libraries, services and IPC, opening the road towards modern service management, service frameworks , fault management , fault response and transactional OS databases > > I continue to believe this is or will become shortly an issue of utmost importance , one which is worthy of the status of a FreeBSD > initiated and sponsored object. > Yes. We will get there. -Alfred (who pushed for libxo as well) From owner-freebsd-current@freebsd.org Tue Nov 17 02:31:17 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40F56A312A7 for ; Tue, 17 Nov 2015 02:31:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2F0271E85; Tue, 17 Nov 2015 02:31:17 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8AD577A3; Tue, 17 Nov 2015 02:31:17 +0000 (UTC) Date: Tue, 17 Nov 2015 02:31:17 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1060502192.39.1447727477434.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1881894481.33.1447716713508.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1881894481.33.1447716713508.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1701 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 02:31:17 -0000 FreeBSD_HEAD-tests - Build #1701 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1701/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1701/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1701/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Tue Nov 17 05:34:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A6D5A31E24 for ; Tue, 17 Nov 2015 05:34:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 72C0E1A3B; Tue, 17 Nov 2015 05:34:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3C2AB82F; Tue, 17 Nov 2015 05:34:52 +0000 (UTC) Date: Tue, 17 Nov 2015 05:34:51 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2134787324.41.1447738491658.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1060502192.39.1447727477434.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1060502192.39.1447727477434.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1702 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 05:34:52 -0000 FreeBSD_HEAD-tests - Build #1702 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1702/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1702/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1702/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Tue Nov 17 06:29:32 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E452DA305B2 for ; Tue, 17 Nov 2015 06:29:32 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id A8A311BE5 for ; Tue, 17 Nov 2015 06:29:32 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 8F80E1C984; Tue, 17 Nov 2015 08:29:28 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <18325.1447711377@chaos> Date: Tue, 17 Nov 2015 08:29:28 +0200 Cc: Adrian Chadd , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <26127.1447610752@chaos> <18325.1447711377@chaos> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 06:29:33 -0000 Management daemon with fine grained permission, extremely useful. Would = Juniper consider donating to FreeBSD under a BSD license portions of = this code, the MGD, which could be reused in FreeBSD ? A fine grained = permission system on daemon IPC and the scaffoldings of a management = configuration daemon would help FreeBSD. I am very grateful your company = helped us with libxo. Now you could help with the other end of the = system. =20 So Juniper, thank you for contributing, and please help the OS who makes = us all tick. Dan > On 17 Nov 2015, at 00:02, Simon J. Gerraty wrote: >=20 > Dan Partelly wrote: >>>> The ability to get machine parsable output from OS components is a = big part of the success of Junos CLI, netconf etc. >>=20 >> Once you get machine parsable output, and feed it to your GUIs , WEB, >> other tools, and modify it, how do you feed it back to your = underlying >> OS ? >=20 > We didn't make any changes to the way tools are run as there was no > need. >=20 > All requests - whether from CLI, NETCONF etc, are channeled into the = MGD > (management daemon) to verify input, permissions etc (Junos implements > very fine grained permission system), and act accordingly. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Nov 17 08:09:18 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87C2EA31A95 for ; Tue, 17 Nov 2015 08:09:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19F1411EE for ; Tue, 17 Nov 2015 08:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tAH896CK030442 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Nov 2015 10:09:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tAH896CK030442 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tAH896FN030433; Tue, 17 Nov 2015 10:09:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Nov 2015 10:09:06 +0200 From: Konstantin Belousov To: Benjamin Kaduk Cc: Warner Losh , Justin Hibbits , FreeBSD Current Subject: Re: CFT: uintmax_t rman Message-ID: <20151117080906.GA58629@kib.kiev.ua> References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 08:09:18 -0000 On Mon, Nov 16, 2015 at 07:25:54PM -0500, Benjamin Kaduk wrote: > Channeling my inner bde (maybe?), the typedef is probably helpful, but > uintmax_t seems less so. uintmax_t has no guaranteed ABI, so a > fixed-width type like uint64_t seems beter, assuming that uintmax_t is > currently uint64_t everywhere (which I think is the case but did not > verify). The statement about {u}intmax_t not having a guaranteed ABI is wrong, I believe. You cannot change the type after it is exposed. I am sure that ANSI C or POSIX would introduce intthistimerealmax_t after long long long type is added (only half-joking). From owner-freebsd-current@freebsd.org Tue Nov 17 09:04:24 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B93AA301A7 for ; Tue, 17 Nov 2015 09:04:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 504E8196A for ; Tue, 17 Nov 2015 09:04:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-231-48.lns20.per1.internode.on.net [121.45.231.48]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tAH94HDZ026447 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Nov 2015 01:04:21 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Dan Partelly , freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Julian Elischer Message-ID: <564AED8B.4080809@freebsd.org> Date: Tue, 17 Nov 2015 17:04:11 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:04:24 -0000 On 11/15/15 8:54 PM, Dan Partelly wrote: > Hi all, > > I was looking at the new facility of dumping JSON,XML from many utils i= n base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: > > > 1. Undoubtedly, it makes base code slightly harder to understand and ma= intain. > 2. I have seen the idea that this makes the information dumped by utili= ties in the base easily accessible programatically. OK, maybe it does , b= ut > it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I > dont see too many ppl changing their code to read JSON instead of text.= I don't even see the base tools changing. This output may be useful in = corner cases only. > 3. The integration of libxo IMO only points at a much deeper issue IMO.= It is only an expression of the need of a mechanism aimed at binary code= reuse. But it does not solve the problem, it only adds yet another possi= bility in a world where too much choices already result in too much split= s and incompatible APIs. > 4. This whole effort would have been IMO much better served by porting= the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch like the libs for geom, zfs , etc , ready for reuse of 3rd party code.= Eventually writing network control daemons in time over it , much like s= olaris does. > > 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the be= stiary of ad hoc databases already existing in BSDs ? Programatic readabi= lity, yes. but it does not add any real much needed functionality such as= *transactional databases* for system tools. Why not research a proper = solution - easily accessible by other programs ,orthogonal , transactiona= l, and ACL protected solution which can be used all over the place , f= rom OS boot, to ABI management, service management, network management, u= ser management. I hope this day will come, a day when I will not have to= edit a single config file manually, yet I would have access to all the c= onfig and system state easy with wrapper APIs. In the light of this poin= t, why go with UCL ? It is not orthogonal, it is not transnational, and e= diting the config files directly would result in the same old human error= s which bite as all from time to time. > > 5. It is my opinion that Solaris addressed some of those issue. Solaris= FMRI and SMF are lightyears ahead of the very tired models we keep using= on BSDs. Why not build on the insight offered by those (or even on the i= nsight offered by Windows :P) , then inventing more adhoc solutions and a= d-hoc databases, which do not address the real issues we have , like bina= ry code reuse, service management issues, lack of a system wide publishe= d -subscriber bus ( not kdbus :P ) fault detection and reaction, fault re= porting, all much needed parts of a modern OS. > > And now thee questions > > 1. Why lib XO ? Why burden the OS for some corner cases where it may be= useful ? > > 2. Was there any real talk on how to bring FreeBSD up to speed regardin= g those issues ? A period of research on what exists, on what can be don= e , and ensure important things are not showed in background and replaced= with yet another ad-hoc config database which lacks modern features ? > >From where I am standing, this could be a project spawning multiple ye= ars , but it would be well worth it, and in my opinion it would be also w= orthy of > the freeSBD foundation sponsorship for several years in a row. The feat= ures I touched upon became very important parts of oder OSes, and rightly= so. > > Note: > > this message is serious and it is not intended to start flame wars, rel= igious crusades, or offend anyone. Amen. I have stated before that I believe this is a mistake... actually, no,=20 not "mistake" actually.. let's say "suboptimal and aesthetically=20 dipleasing". It has every hallmark of "the wrong answer" in my gut feeling. I believe it is being pushed by Juniper to make it easier to make=20 appliances, but I'm not sure I remember correctly. I remember that there was a set of slides somewhere that give the=20 justifications and thinking behind it. But quick look failed to find it.. As a 'currently mostly inactive=20 (kids + $JOB ) I feel iti sn't my place to argue against it too much=20 if currently active deveelopers want it, but it doesn't ring quite=20 right to me.. The ifconfig issue is a separate issue, but yes that=20 could be a good library to have. Personally I would have liked it if in '91 we had followed one very=20 serious suggestion, and implemented every user command as a base 'library', and a tcl=20 wrapper script that gave the external behaviour. then every command=20 could have been made extensible to output various formats etc. by=20 having an alternate tcl script to run in that case. > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > From owner-freebsd-current@freebsd.org Tue Nov 17 09:05:45 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B931CA30220 for ; Tue, 17 Nov 2015 09:05:45 +0000 (UTC) (envelope-from 214748mv@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86C611AA2 for ; Tue, 17 Nov 2015 09:05:45 +0000 (UTC) (envelope-from 214748mv@gmail.com) Received: by igvi2 with SMTP id i2so92847263igv.0 for ; Tue, 17 Nov 2015 01:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O79y95evouN2bWRbMEER497BnSDs1JYphji2Lz79HGU=; b=v7Q6Yvwihekm1wIU7zrTAFDb+nifdEcksjhqvWzo1s+jP9a399E/rmL11JfHLHChVx jiQ4ASBtYsf32NJ44eR77ydWrPEEN6KUT8J5hxLF/gZb8M85+mc9w6xUDJJzu+eUTFCW HzVQ9hx+RvqttizSHDl1T8oPpUuZFGw81sq1cHXKVzEwKhogQtdCrA1E/SFJs07V+rPI juXEIUXq8l5skWMBtDJqY0HazfsOYlbvpmimqeIMl8fWYWrHGAx0NKOnpyedyaG//IdB 5Y+FNzTBNXgCe5P4bqEhmVou6DNwG/T3YDPjv2MDzrYIrsmXSJOV2qaoy1wMPyynVB95 IS4g== MIME-Version: 1.0 X-Received: by 10.50.131.229 with SMTP id op5mr801693igb.83.1447751144930; Tue, 17 Nov 2015 01:05:44 -0800 (PST) Received: by 10.79.70.130 with HTTP; Tue, 17 Nov 2015 01:05:44 -0800 (PST) Date: Tue, 17 Nov 2015 10:05:44 +0100 Message-ID: Subject: =?UTF-8?B?4oCYenBvb2wgZ2V04oCZIGNvbW1hbmQgaGVscCBvdXRwdXQu?= From: "Ranjan1018 ." <214748mv@gmail.com> To: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:05:45 -0000 Hi, running the command $ zpool get missing property argument usage: get [-Hp] [-o "all" | field[,...]] <"all" | property[,...]> ... the following properties are supported: PROPERTY EDIT VALUES allocated NO capacity NO dedupratio NO <1.00x or higher if deduped> expandsize NO fragmentation NO free NO freeing NO guid NO health NO leaked NO size NO altroot YES autoexpand YES on | off autoreplace YES on | off bootfs YES cachefile YES | none comment YES dedupditto YES delegation YES on | off failmode YES wait | continue | panic listsnapshots YES on | off readonly YES on | off version YES feature@... YES disabled | enabled | active The feature@ properties must be appended with a feature name. See zpool-features(7). I notice that: - the property =E2=80=9Ccapacity=E2=80=9D is a and not a - the property =E2=80=9Cname=E2=80=9D is missing. Regards Maurizio From owner-freebsd-current@freebsd.org Tue Nov 17 09:09:20 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2FF8A303D8 for ; Tue, 17 Nov 2015 09:09:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AADE71D42; Tue, 17 Nov 2015 09:09:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-231-48.lns20.per1.internode.on.net [121.45.231.48]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tAH99F5I026467 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Nov 2015 01:09:18 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Andrey Chernov , Adrian Chadd , Dan Partelly References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> Cc: freebsd-current From: Julian Elischer Message-ID: <564AEEB5.10207@freebsd.org> Date: Tue, 17 Nov 2015 17:09:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5648C60B.6060205@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:09:20 -0000 On 11/16/15 1:51 AM, Andrey Chernov wrote: > On 15.11.2015 20:37, Adrian Chadd wrote: >> On 15 November 2015 at 09:10, Dan Partelly wrote: >>> Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? >> Nope and yup. The juniper folk had a solution to a problem multiple >> people had requested work on, and their proposal was by far the >> furthest along code and use wise. >> >> It's all fine and good making technical decisions based on drawings >> and handwaving and philosophizing, but at some point someone has to do >> the code. Juniper's libxo was the furthest along in implementation and >> production. > It seems it is the only and final argument for libXO existence. I > remember 2 or 3 discussions against libXO spontaneously happens in the > FreeBSD lists, all ended with that, approximately: "we already have the > code and you have just speculations". Alternative and more architecture > clean ideas, like making standalone template-oriented parser probably > based on liXO, are never seriously considered, because nobody will code > it, not for other reasons. I believe that was my suggestion.. (thus automatically gaining negative votes from certain scandinavian countries). I still think it is better because it would give a framework for adding templates for third party applications for which libXO will NEVER be an option. LibXO could be the backend for outputing the data. > From owner-freebsd-current@freebsd.org Tue Nov 17 09:11:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C85CA304DA for ; Tue, 17 Nov 2015 09:11:05 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D2671F31; Tue, 17 Nov 2015 09:11:04 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by wmww144 with SMTP id w144so15982747wmw.0; Tue, 17 Nov 2015 01:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pz3TvXSQYD26qKeaHjGFYOpXFN/+9Khz7hMO7ciY1L8=; b=0TINepeHcO4d442RkfJCIAJ7L3aIqsGh/nBoRveepUCNLiZIxPXgWQnerLvdxL020g EoxqDz40VqDaRhuoaiIbcP54B01VlSPw3/lb6IUDY2BKwxeFBkZ89PZFZt1muXOYn2wu AUBR+II8GX9Mb9WmI6tWtxA5h23WUl6GcKB1q7KtSOUVp8vsPt19hiMl5+KB5mgjJIFT chnGR/4AfOnTv8/D6tr/WZ2ab0/ROLGEsQ4708qfNrAzdoNAMXYVuqED1Jp9cve4yXJr HEMJhOgcLVR8fZH0MNk4gWn0vszwE1Mt9s5OkhC2/iXjVByqDNVizB+ZGcO4v5N2NA4R 8Vaw== MIME-Version: 1.0 X-Received: by 10.194.86.161 with SMTP id q1mr49720508wjz.88.1447751463096; Tue, 17 Nov 2015 01:11:03 -0800 (PST) Received: by 10.28.16.206 with HTTP; Tue, 17 Nov 2015 01:11:02 -0800 (PST) In-Reply-To: <564AED8B.4080809@freebsd.org> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564AED8B.4080809@freebsd.org> Date: Tue, 17 Nov 2015 10:11:02 +0100 Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Andreas Nilsson To: Julian Elischer Cc: Dan Partelly , Current FreeBSD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:11:05 -0000 On Tue, Nov 17, 2015 at 10:04 AM, Julian Elischer wrote: > On 11/15/15 8:54 PM, Dan Partelly wrote: > >> Hi all, >> >> I was looking at the new facility of dumping JSON,XML from many utils in >> base and after some funny minutes, I couldn't stop ask myself =E2=80=9C = Ok, this is >> funny , but why ? =E2=80=9C And I couldn't find a real answer. Ill outli= ne what I >> think: >> >> >> 1. Undoubtedly, it makes base code slightly harder to understand and >> maintain. >> 2. I have seen the idea that this makes the information dumped by >> utilities in the base easily accessible programatically. OK, maybe it do= es >> , but >> it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at >> all. There are no tools able to accept JSON and filter it in any meaning= ful >> way, and I >> dont see too many ppl changing their code to read JSON instead of text. >> I don't even see the base tools changing. This output may be useful in >> corner cases only. >> 3. The integration of libxo IMO only points at a much deeper issue IMO. >> It is only an expression of the need of a mechanism aimed at binary code >> reuse. But it does not solve the problem, it only adds yet another >> possibility in a world where too much choices already result in too much >> splits and incompatible APIs. >> 4. This whole effort would have been IMO much better served by porting >> the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch >> like the libs for geom, zfs , etc , ready for reuse of 3rd party code. >> Eventually writing network control daemons in time over it , much like >> solaris does. >> >> 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet i= nduce >> another orthogonality violation. What makes UCL better than the bestiary= of >> ad hoc databases already existing in BSDs ? Programatic readability, yes= . >> but it does not add any real much needed functionality such as >> *transactional databases* for system tools. Why not research a proper >> solution - easily accessible by other programs ,orthogonal , transaction= al, >> and ACL protected solution which can be used all over the place , fro= m >> OS boot, to ABI management, service management, network management, user >> management. I hope this day will come, a day when I will not have to ed= it >> a single config file manually, yet I would have access to all the config >> and system state easy with wrapper APIs. In the light of this point, wh= y >> go with UCL ? It is not orthogonal, it is not transnational, and editing >> the config files directly would result in the same old human errors whic= h >> bite as all from time to time. >> >> 5. It is my opinion that Solaris addressed some of those issue. Solaris >> FMRI and SMF are lightyears ahead of the very tired models we keep using= on >> BSDs. Why not build on the insight offered by those (or even on the insi= ght >> offered by Windows :P) , then inventing more adhoc solutions and ad-hoc >> databases, which do not address the real issues we have , like binary co= de >> reuse, service management issues, lack of a system wide published >> -subscriber bus ( not kdbus :P ) fault detection and reaction, fault >> reporting, all much needed parts of a modern OS. >> >> And now thee questions >> >> 1. Why lib XO ? Why burden the OS for some corner cases where it may be >> useful ? >> >> 2. Was there any real talk on how to bring FreeBSD up to speed regarding >> those issues ? A period of research on what exists, on what can be done= , >> and ensure important things are not showed in background and replaced wi= th >> yet another ad-hoc config database which lacks modern features ? >> >From where I am standing, this could be a project spawning multiple >> years , but it would be well worth it, and in my opinion it would be als= o >> worthy of >> the freeSBD foundation sponsorship for several years in a row. The >> features I touched upon became very important parts of oder OSes, and >> rightly so. >> >> Note: >> >> this message is serious and it is not intended to start flame wars, >> religious crusades, or offend anyone. >> > Amen. > > I have stated before that I believe this is a mistake... actually, no, no= t > "mistake" actually.. let's say "suboptimal and aesthetically dipleasing". > It has every hallmark of "the wrong answer" in my gut feeling. > I believe it is being pushed by Juniper to make it easier to make > appliances, but I'm not sure I remember correctly. > I remember that there was a set of slides somewhere that give the > justifications and thinking behind it. > But quick look failed to find it.. As a 'currently mostly inactive (kids > + $JOB ) I feel iti sn't my place to argue against it too much if current= ly > active deveelopers want it, but it doesn't ring quite right to me.. The > ifconfig issue is a separate issue, but yes that could be a good library = to > have. > > Personally I would have liked it if in '91 we had followed one very > serious suggestion, > and implemented every user command as a base 'library', and a tcl wrappe= r > script that gave the external behaviour. then every command could have be= en > made extensible to output various formats etc. by having an alternate tcl > script to run in that case. > > > I for one find this really really promising. I think it will really simplify adopting https://github.com/clicon/clicon to make a slick cli. UCL also has it's place in that vision. If the daemons should read from config files or query a "database" is a good question, where I see pros and cons for both approaches. Best regards Andreas > > > _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> >> >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Tue Nov 17 09:20:43 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1667A30712 for ; Tue, 17 Nov 2015 09:20:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E57B1333 for ; Tue, 17 Nov 2015 09:20:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-231-48.lns20.per1.internode.on.net [121.45.231.48]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tAH9Kc5Q026514 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 17 Nov 2015 01:20:41 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <201511152336.tAFNa6Bi005630@gw.catspoiler.org> From: Julian Elischer Message-ID: <564AF161.7030104@freebsd.org> Date: Tue, 17 Nov 2015 17:20:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201511152336.tAFNa6Bi005630@gw.catspoiler.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:20:43 -0000 On 11/16/15 7:36 AM, Don Lewis wrote: > On 15 Nov, Allan Jude wrote: >> On 2015-11-15 13:06, Garrett Cooper wrote: >>>> On Nov 15, 2015, at 09:51, Andrey Chernov wrote: >>>> >>>>> On 15.11.2015 20:37, Adrian Chadd wrote: >>>>>> On 15 November 2015 at 09:10, Dan Partelly wrote: >>>>>> Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? >>>>> Nope and yup. The juniper folk had a solution to a problem multiple >>>>> people had requested work on, and their proposal was by far the >>>>> furthest along code and use wise. >>>>> >>>>> It's all fine and good making technical decisions based on drawings >>>>> and handwaving and philosophizing, but at some point someone has to do >>>>> the code. Juniper's libxo was the furthest along in implementation and >>>>> production. >>>> It seems it is the only and final argument for libXO existence. I >>>> remember 2 or 3 discussions against libXO spontaneously happens in the >>>> FreeBSD lists, all ended with that, approximately: "we already have the >>>> code and you have just speculations". Alternative and more architecture >>>> clean ideas, like making standalone template-oriented parser probably >>>> based on liXO, are never seriously considered, because nobody will code >>>> it, not for other reasons. >>> We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't seems like the best idea in the world to me from a end-user sysadmin/developer perspective. >>> >>> I could just as easily use standard tools like awk, grep, sed, and more advanced languages like perl or Python to parse output, and assuming output doesn't get a major rewrite, I'd just go with that method that's worked pretty well for me over the last 10 years of my career.. >>> >>> Cheers, >>> -NGie >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> The big difference is, a json parser isn't going to blow up if a new >> field gets added in the middle, and your awk/grep/sed script probably will. > Or more likely, if some value gets large causing adjacent columns run > together. Or even if you the utility is used to display something where > some of the data contains whitespace. > > How is an awk script going to cope with this: the suggestion I made, which was refered to earlier, was that we add one very smart tool to our quiver. one that can take a template, (a grammar decription) and parse these things in an meaningful manner There are already tools that do this for HANDWRITING. If we can't do it for regular computer text I'd be very surprised. Given a correct front end.. you should be able to take sample outputs of a program and generate the template. Given a few months with no job, lots of money and time, I think it would be a grand project. Unfortunately I do not have these conditions so I will limit complaints to the fact that "I am not sure this is the way to do this" but I will not stop the libXO-ification of the utilities. (not that I could, but I mean that my objections do not raise to the level of "moral outrage" :-) . > > # grep spacey /etc/passwd > spacey user:*:6666:6666:Update Builder:/tmp/spacey:/bin/csh > # su 'spacey user' > % cd ~ > % touch 'a file' > % ls -l > total 1 > -rw-r--r-- 1 spacey user 6666 0 Nov 15 15:24 a file > > vs a json parser: > > % ls --libxo json -l > {"__version": "1", "file-information": {"directory": [{"total-blocks":1, "entry": [{"name":"a file","mode":"-rw-r--r--","mode_octal":644,"links":1,"user":"spacey user","group":"6666","type":"regular","size":0,"modify-time":1447629885}]}]} > } > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Nov 17 09:53:48 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08D8FA30FD9 for ; Tue, 17 Nov 2015 09:53:48 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from turad.lysandor.de (turad.lysandor.de [136.243.10.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB43212B4 for ; Tue, 17 Nov 2015 09:53:46 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from localhost (localhost [127.0.0.1]) by turad.lysandor.de (Postfix) with ESMTP id 7B09DAAC114 for ; Tue, 17 Nov 2015 10:45:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at turad.lysandor.de Received: from turad.lysandor.de ([127.0.0.1]) by localhost (turad.lysandor.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJzoYWyuLpcR for ; Tue, 17 Nov 2015 10:45:49 +0100 (CET) Received: from Haven.purplekraken.com (x4d02bc35.dyn.telefonica.de [77.2.188.53]) (Authenticated sender: flo@snakeoilproductions.net) by turad.lysandor.de (Postfix) with ESMTPSA id 34AD4AAC08E for ; Tue, 17 Nov 2015 10:45:47 +0100 (CET) To: freebsd-current@freebsd.org From: Florian Limberger Subject: Panic while waiting on wlan0 Message-ID: <564AF74A.2090700@snakeoilproductions.net> Date: Tue, 17 Nov 2015 10:45:46 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020303030809090808000405" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:53:48 -0000 This is a multi-part message in MIME format. --------------020303030809090808000405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I am running -CURRENT on my Lenovo T410 notebook since nearly a year now and am now experiencing my first reliable occuring panic. Since I am interested into getting more involved, I want not only to give a report on this, but ask for directions on how I can help to fix the issue. The crash occurs on bad wifi reception, either on startup, if “waiting 30s for default interface” is not interrupted, or at a later point if the wpa_supplicant is not able to establish a connection (mostly due to a wrong passphrase, which is not the case if the wifi reception is better). Core.txt and the dump info are attached. I am using git commit 71f160e0193fee45242bebeff7f1282846e83d2c. Best regards, florian --------------020303030809090808000405 Content-Type: text/plain; charset=UTF-8; name="core.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="core.txt" bmFjaHRzY2hhdHRlbi5vcmtsYW4uZGUgZHVtcGVkIGNvcmUgLSBzZWUgL3Zhci9jcmFzaC92 bWNvcmUuOAoKVHVlIE5vdiAxMSAyMzozNjoxMSBDRVQgMjAxNAoKRnJlZUJTRCBuYWNodHNj aGF0dGVuLm9ya2xhbi5kZSAxMC4wLVJFTEVBU0UtcDEyIEZyZWVCU0QgMTAuMC1SRUxFQVNF LXAxMiAjMDogVHVlIE5vdiAgNCAwNTowNzoxNyBVVEMgMjAxNCAgICAgcm9vdEBhbWQ2NC1i dWlsZGVyLmRhZW1vbm9sb2d5Lm5ldDovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDICBh bWQ2NAoKcGFuaWM6IHBhZ2UgZmF1bHQKCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNvcHly aWdodCAyMDA0IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBz b2Z0d2FyZSwgY292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFu ZCB5b3UgYXJlCndlbGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGll cyBvZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuClR5cGUgInNob3cgY29weWluZyIg dG8gc2VlIHRoZSBjb25kaXRpb25zLgpUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5 IGZvciBHREIuICBUeXBlICJzaG93IHdhcnJhbnR5IiBmb3IgZGV0YWlscy4KVGhpcyBHREIg d2FzIGNvbmZpZ3VyZWQgYXMgImFtZDY0LW1hcmNlbC1mcmVlYnNkIi4uLgoKVW5yZWFkIHBv cnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoKPDExOD5TdG9wcGluZyBkZXZk Lgo8MTE4PldhaXRpbmcgZm9yIFBJRFM6IDg4OS4KPDExOD5Xcml0aW5nIGVudHJvcHkgZmls ZTouCjwxMTg+Lgo8MTE4PlRlcm1pbmF0ZWQKPDExOD5Ob3YgMTEgMjM6MzQ6NDAgbmFjaHRz Y2hhdHRlbiBzeXNsb2dkOiBleGl0aW5nIG9uIHNpZ25hbCAxNQoKCkZhdGFsIHRyYXAgMTI6 IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKY3B1aWQgPSAwOyBhcGljIGlkID0g MDAKZmF1bHQgdmlydHVhbCBhZGRyZXNzCT0gMHgwCmZhdWx0IGNvZGUJCT0gc3VwZXJ2aXNv ciByZWFkIGluc3RydWN0aW9uLCBwYWdlIG5vdCBwcmVzZW50Cmluc3RydWN0aW9uIHBvaW50 ZXIJPSAweDIwOjB4MApzdGFjayBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZlMDEx N2VkNjdiMApmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZlMDAwMTMwNWZl OApjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJ CQk9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBl ZmxhZ3MJPSBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMwpjdXJyZW50IHBy b2Nlc3MJCT0gMTQwOSAoWG9yZykKdHJhcCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1 bHQKY3B1aWQgPSAwCktEQjogc3RhY2sgYmFja3RyYWNlOgojMCAweGZmZmZmZmZmODA4ZTdl OTAgYXQga2RiX2JhY2t0cmFjZSsweDYwCiMxIDB4ZmZmZmZmZmY4MDhhZjk3NSBhdCBwYW5p YysweDE1NQojMiAweGZmZmZmZmZmODBjOGU4MzIgYXQgdHJhcF9mYXRhbCsweDNhMgojMyAw eGZmZmZmZmZmODBjOGViMDkgYXQgdHJhcF9wZmF1bHQrMHgyYzkKIzQgMHhmZmZmZmZmZjgw YzhlMjk2IGF0IHRyYXArMHg1ZTYKIzUgMHhmZmZmZmZmZjgwYzc1NTMyIGF0IGNhbGx0cmFw KzB4OApVcHRpbWU6IDJtMzVzCkR1bXBpbmcgMjgyIG91dCBvZiAzOTE5IE1COi4uNiUuLjEy JS4uMjMlLi4zNCUuLjQ2JS4uNTElLi42MyUuLjc0JS4uODUlLi45MSUKClJlYWRpbmcgc3lt Ym9scyBmcm9tIC9ib290L2tlcm5lbC9jb3JldGVtcC5rby5zeW1ib2xzLi4uZG9uZS4KTG9h ZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9jb3JldGVtcC5rby5zeW1ib2xzClJlYWRp bmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9hY3BpX2libS5rby5zeW1ib2xzLi4uZG9u ZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9hY3BpX2libS5rby5zeW1ib2xz ClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9jcHVmcmVxLmtvLnN5bWJvbHMu Li5kb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2NwdWZyZXEua28uc3lt Ym9scwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvY3B1Y3RsLmtvLnN5bWJv bHMuLi5kb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2NwdWN0bC5rby5z eW1ib2xzClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L21vZHVsZXMvbnZpZGlhLmtvLi4u ZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L21vZHVsZXMvbnZpZGlhLmtvClJlYWRp bmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9uZ191YnQua28uc3ltYm9scy4uLmRvbmUu CkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvbmdfdWJ0LmtvLnN5bWJvbHMKUmVh ZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL25ldGdyYXBoLmtvLnN5bWJvbHMuLi5k b25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL25ldGdyYXBoLmtvLnN5bWJv bHMKUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL25nX2hjaS5rby5zeW1ib2xz Li4uZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9uZ19oY2kua28uc3lt Ym9scwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbmdfYmx1ZXRvb3RoLmtv LnN5bWJvbHMuLi5kb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL25nX2Js dWV0b290aC5rby5zeW1ib2xzClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9s aW51eC5rby5zeW1ib2xzLi4uZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5l bC9saW51eC5rby5zeW1ib2xzCiMwICBkb2FkdW1wICh0ZXh0ZHVtcD08dmFsdWUgb3B0aW1p emVkIG91dD4pIGF0IHBjcHUuaDoyMTkKMjE5CXBjcHUuaDogTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeS4KCWluIHBjcHUuaAooa2dkYikgIzAgIGRvYWR1bXAgKHRleHRkdW1wPTx2YWx1 ZSBvcHRpbWl6ZWQgb3V0PikgYXQgcGNwdS5oOjIxOQojMSAgMHhmZmZmZmZmZjgwOGFmNWYw IGluIGtlcm5fcmVib290IChob3d0bz0yNjApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3NodXRkb3duLmM6NDQ3CiMyICAweGZmZmZmZmZmODA4YWY5YjQgaW4gcGFuaWMgKGZt dD08dmFsdWUgb3B0aW1pemVkIG91dD4pCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X3NodXRkb3duLmM6NzU0CiMzICAweGZmZmZmZmZmODBjOGU4MzIgaW4gdHJhcF9mYXRhbCAo ZnJhbWU9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKICAgIGV2YT08dmFsdWUgb3B0aW1pemVk IG91dD4pIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6ODgyCiM0ICAweGZm ZmZmZmZmODBjOGViMDkgaW4gdHJhcF9wZmF1bHQgKGZyYW1lPTB4ZmZmZmZlMDExN2VkNjcw MCwgdXNlcm1vZGU9MCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6 Njk5CiM1ICAweGZmZmZmZmZmODBjOGUyOTYgaW4gdHJhcCAoZnJhbWU9MHhmZmZmZmUwMTE3 ZWQ2NzAwKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo0NjMKIzYg IDB4ZmZmZmZmZmY4MGM3NTUzMiBpbiBjYWxsdHJhcCAoKQogICAgYXQgL3Vzci9zcmMvc3lz L2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjIzMgojNyAgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpCkN1cnJlbnQgbGFuZ3VhZ2U6ICBhdXRvOyBjdXJyZW50bHkgbWluaW1hbAooa2dk YikgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KcHMgLWF4bAoKIFVJRCAgUElEIFBQSUQgQ1BVICBQ UkkgTkkgICAgVlNaIFJTUyBNV0NIQU4gICBTVEFUIFRUICAgICAgVElNRSBDT01NQU5ECiAg IDAgICAgMCAgICAwICAgMCAgLTUyICAwICAgICAgMCAgIDAgLSAgICAgICAgRExzICAgLSAg IDA6MDAuMDQgW2tlcm5lbF0KICAgMCAgICAxICAgIDAgICAwICAgNTIgIDAgICA5NDI4ICAg MCB3YWl0ICAgICBETHMgICAtICAgMDowMC4wMSBbaW5pdF0KICAgMCAgICAyICAgIDAgICAw ICAtMTYgIDAgICAgICAwICAgMCB3YWl0aW5nXyBETCAgICAtICAgMDowMC4wMCBbc2N0cF9p dGVyYXRvcgogICAwICAgIDMgICAgMCAgIDAgIC0xNiAgMCAgICAgIDAgICAwIGNjYl9zY2Fu IERMICAgIC0gICAwOjAwLjAwIFt4cHRfdGhyZF0KICAgMCAgICA0ICAgIDAgICAwICAtMTYg IDAgICAgICAwICAgMCBpZGxlICAgICBETCAgICAtICAgMDowMC4wMCBbZW5jX2RhZW1vbjBd CiAgIDAgICAgNSAgICAwICAgMCAgLTE2ICAwICAgICAgMCAgIDAgcHNsZWVwICAgREwgICAg LSAgIDA6MDAuMDAgW3BhZ2VkYWVtb25dCiAgIDAgICAgNiAgICAwICAgMCAgLTE2ICAwICAg ICAgMCAgIDAgcHNsZWVwICAgREwgICAgLSAgIDA6MDAuMDAgW3ZtZGFlbW9uXQogICAwICAg IDcgICAgMCAgIDAgIDE1NSAgMCAgICAgIDAgICAwIHBnemVybyAgIERMICAgIC0gICAwOjAw LjAwIFtwYWdlemVyb10KICAgMCAgICA4ICAgIDAgICAwICAtMTYgIDAgICAgICAwICAgMCBw c2xlZXAgICBETCAgICAtICAgMDowMC4wMCBbYnVmZGFlbW9uXQogICAwICAgIDkgICAgMCAg IDAgIC0xNiAgMCAgICAgIDAgICAwIHZscnV3dCAgIERMICAgIC0gICAwOjAwLjAwIFt2bmxy dV0KICAgMCAgIDEwICAgIDAgICAwICAtMTYgIDAgICAgICAwICAgMCBhdWRpdF93byBETCAg ICAtICAgMDowMC4wMCBbYXVkaXRdCiAgIDAgICAxMSAgICAwICAgMCAgMTU1ICAwICAgICAg MCAgIDAgLSAgICAgICAgUkwgICAgLSAgMTA6MDMuNTIgW2lkbGVdCiAgIDAgICAxMiAgICAw ICAgMCAgLTg0ICAwICAgICAgMCAgIDAgLSAgICAgICAgV0wgICAgLSAgIDA6MDAuNTcgW2lu dHJdCiAgIDAgICAxMyAgICAwICAgMCAgIC04ICAwICAgICAgMCAgIDAgLSAgICAgICAgREwg ICAgLSAgIDA6MDAuMDYgW2dlb21dCiAgIDAgICAxNCAgICAwICAgMCAgLTE2ICAwICAgICAg MCAgIDAgLSAgICAgICAgREwgICAgLSAgIDA6MDAuMDIgW3JhbmRfaGFydmVzdHEKICAgMCAg IDE1ICAgIDAgICAwICAtNjggIDAgICAgICAwICAgMCAtICAgICAgICBETCAgICAtICAgMDow MC4wMyBbdXNiXQogICAwICAgMTYgICAgMCAgIDAgIC0xNiAgMCAgICAgIDAgICAwIHR6cG9s bCAgIERMICAgIC0gICAwOjAwLjAwIFthY3BpX3RoZXJtYWxdCiAgIDAgICAxNyAgICAwICAg MCAgLTE2ICAwICAgICAgMCAgIDAgY29vbGluZyAgREwgICAgLSAgIDA6MDAuMDAgW2FjcGlf Y29vbGluZzAKICAgMCAgIDE4ICAgIDAgICAwICAgMTYgIDAgICAgICAwICAgMCBzeW5jZXIg ICBETCAgICAtICAgMDowMC4wMCBbc3luY2VyXQogICAwICAgMTkgICAgMCAgIDAgICAyMCAg MCAgICAgIDAgICAwIHNkZmx1c2ggIERMICAgIC0gICAwOjAwLjAwIFtzb2Z0ZGVwZmx1c2hd CiAgIDAgIDg3MiAgICAwICAgMCAgLTE2ICAwICAgICAgMCAgIDAgc2xlZXAgICAgREwgICAg LSAgIDA6MDAuMDAgW25nX3F1ZXVlXQoxMDAxIDEzOTIgICAgMSAgIDAgICAyMCAgMCAgMTI1 NDAgICAwIHBhdXNlICAgIEQgICAgIC0gICAwOjAwLjAxIFtta3NoXQoxMDAxIDEzOTUgMTM5 MiAgIDAgICAyMCAgMCAgMTY5OTYgICAwIHdhaXQgICAgIEQrICAgIC0gICAwOjAwLjAwIFtz aF0KMTAwMSAxNDA4IDEzOTUgICAwICAgMjAgIDAgIDI2MDM2ICAgMCBuYW5zbHAgICBEKyAg ICAtICAgMDowMC4wMCBbeGluaXRdCiAgIDAgMTQwOSAxNDA4ICAgMCAgIDQwICAwIDkyOTQ1 NiAgIDAgLSAgICAgICAgUiAgICAgLSAgIDA6MDMuMzcgW1hvcmddCjEwMDEgMTQxMSAxNDA4 ICAgMCAtMTAwICAwICAgICAgMCAgIDAgLSAgICAgICAgWlcgICAgLSAgIDA6MDAuMDAgPGRl ZnVuY3Q+CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1zCgogICAgODM0NzcgY3B1IGNv bnRleHQgc3dpdGNoZXMKICAgIDE3Mjg0IGRldmljZSBpbnRlcnJ1cHRzCiAgICAgMzg3NyBz b2Z0d2FyZSBpbnRlcnJ1cHRzCiAgIDEzNjAyMiB0cmFwcwogICAyMjQwNzUgc3lzdGVtIGNh bGxzCiAgICAgICAyMCBrZXJuZWwgdGhyZWFkcyBjcmVhdGVkCiAgICAgMTM4MSAgZm9yaygp IGNhbGxzCiAgICAgIDI2NiB2Zm9yaygpIGNhbGxzCiAgICAgICAgMCByZm9yaygpIGNhbGxz CiAgICAgICAgMCBzd2FwIHBhZ2VyIHBhZ2VpbnMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFn ZXMgcGFnZWQgaW4KICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZW91dHMKICAgICAgICAwIHN3 YXAgcGFnZXIgcGFnZXMgcGFnZWQgb3V0CiAgICAgMTY5MiB2bm9kZSBwYWdlciBwYWdlaW5z CiAgICAxNjc2NyB2bm9kZSBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgdm5vZGUg cGFnZXIgcGFnZW91dHMKICAgICAgICAwIHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIG91dAog ICAgICAgIDAgcGFnZSBkYWVtb24gd2FrZXVwcwogICAgICAgIDAgcGFnZXMgZXhhbWluZWQg YnkgdGhlIHBhZ2UgZGFlbW9uCiAgICAgICA1MCBwYWdlcyByZWFjdGl2YXRlZAogICAgNTE4 ODggY29weS1vbi13cml0ZSBmYXVsdHMKICAgICAgNDQ3IGNvcHktb24td3JpdGUgb3B0aW1p emVkIGZhdWx0cwogICAgNTU5ODEgemVybyBmaWxsIHBhZ2VzIHplcm9lZAogICAgICAgIDAg emVybyBmaWxsIHBhZ2VzIHByZXplcm9lZAogICAgICAgIDAgaW50cmFuc2l0IGJsb2NraW5n IHBhZ2UgZmF1bHRzCiAgIDEyNzE0NiB0b3RhbCBWTSBmYXVsdHMgdGFrZW4KICAgICAxODI0 IHBhZ2UgZmF1bHRzIHJlcXVpcmluZyBJL08KICAgICAgICAwIHBhZ2VzIGFmZmVjdGVkIGJ5 IGtlcm5lbCB0aHJlYWQgY3JlYXRpb24KICAgIDUwMDk2IHBhZ2VzIGFmZmVjdGVkIGJ5ICBm b3JrKCkKICAgICA5NTgyIHBhZ2VzIGFmZmVjdGVkIGJ5IHZmb3JrKCkKICAgICAgICAwIHBh Z2VzIGFmZmVjdGVkIGJ5IHJmb3JrKCkKICAgICAgICAwIHBhZ2VzIGNhY2hlZAogICAxODI5 MzggcGFnZXMgZnJlZWQKICAgICAgICAwIHBhZ2VzIGZyZWVkIGJ5IGRhZW1vbgogICAgICAg IDAgcGFnZXMgZnJlZWQgYnkgZXhpdGluZyBwcm9jZXNzZXMKICAgICA1MzkxIHBhZ2VzIGFj dGl2ZQogICAgMTI0NTcgcGFnZXMgaW5hY3RpdmUKICAgICAxODc3IHBhZ2VzIGluIFZNIGNh Y2hlCiAgICAyOTQ2NCBwYWdlcyB3aXJlZCBkb3duCiAgIDkyMTQwMCBwYWdlcyBmcmVlCiAg ICAgNDA5NiBieXRlcyBwZXIgcGFnZQogICAgNjQ5OTggdG90YWwgbmFtZSBsb29rdXBzCiAg ICAgICAgICBjYWNoZSBoaXRzICg4NCUgcG9zICsgMTAlIG5lZykgc3lzdGVtIDAlIHBlci1k aXJlY3RvcnkKICAgICAgICAgIGRlbGV0aW9ucyAwJSwgZmFsc2VoaXRzIDAlLCB0b29sb25n IDAlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1tCgogICAgICAgICBUeXBlIEluVXNl IE1lbVVzZSBIaWdoVXNlIFJlcXVlc3RzICBTaXplKHMpCiAgICAgICBVU0JkZXYgICAgMjUg ICAgIDNLICAgICAgIC0gICAgICAgMzIgIDMyLDY0LDEyOCwyNTYsMTAyNAogICAgICAgICBj ZGV2ICAgICA4ICAgICAySyAgICAgICAtICAgICAgICA4ICAyNTYKICAgICAgZW50cm9weSAg MTAyNiAgICA2NUsgICAgICAgLSAgICAgMTAzMyAgMzIsNjQsNDA5NgogICAgICBDQU0gU0lN ICAgICA2ICAgICAySyAgICAgICAtICAgICAgICA2ICAyNTYKICAgICBmaWxlZGVzYyAgICA0 MiAgICA2M0sgICAgICAgLSAgICAgMTY5NiAgMTYsMjA0OCw0MDk2CiAgICAgICAgc2lnaW8g ICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDIgIDY0CiAgICAgZmlsZWNhcHMgICAgIDAg ICAgIDBLICAgICAgIC0gICAgICAgIDMgIDE2CiAgICAgIGtkdHJhY2UgICAxNDQgICAgMzJL ICAgICAgIC0gICAgIDE3ODYgIDY0LDI1NgogICAgICAgICBrZW52ICAgIDg5ICAgIDEySyAg ICAgICAtICAgICAgMTAyICAxNiwzMiw2NCwxMjgKICAgICAgIGtxdWV1ZSAgICAgMCAgICAg MEsgICAgICAgLSAgICAgICA0NCAgMjU2LDUxMiwyMDQ4CiAgICBwcm9jLWFyZ3MgICAgIDYg ICAgIDFLICAgICAgIC0gICAgICA1NzggIDE2LDMyLDY0LDEyOCwyNTYKICAgICAgIGtiZG11 eCAgICAgNiAgICAxOEsgICAgICAgLSAgICAgICAgNiAgMTYsNTEyLDEwMjQsMjA0OAogICAg ICAgIGhob29rICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYKICAgICAgaXRo cmVhZCAgIDEwMiAgICAxN0sgICAgICAgLSAgICAgIDEwMiAgMzIsMTI4LDI1NgogICAgICAg ICAgTEVEICAgIDIwICAgICAySyAgICAgICAtICAgICAgIDIwICAxNiwxMjgKICAgICAgIEtU UkFDRSAgIDEwMCAgICAxM0sgICAgICAgLSAgICAgIDEwMCAgMTI4CiAgICAgIENBTSBYUFQg ICAgMzMgICAgIDNLICAgICAgIC0gICAgICAxMjggIDE2LDMyLDY0LDEyOCwyNTYsMTAyNAog ICAgICBzY3NpX2NkICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDEwICAxNgogICAgICAg bGlua2VyICAgMjY0ICAgNTc3SyAgICAgICAtICAgICAgMzM4ICAxNiwzMiw2NCwxMjgsMjU2 LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgIGxvY2tmICAgICAyICAgICAxSyAgICAgICAt ICAgICAgIDkwICA2NCwxMjgKICAgbG9naW5jbGFzcyAgICAgMiAgICAgMUsgICAgICAgLSAg ICAgICAxNSAgNjQKICAgICAgIGRldmJ1ZiAyMjU4OSAzNjY4NUsgICAgICAgLSAgICAyMzA1 OSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAgdGVtcCAg ICAzMiAgICAxOUsgICAgICAgLSAgICAgMzQyMiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAy NCwyMDQ4LDQwOTYKICAgICAgIGlwNm5kcCAgICAgNSAgICAgMUsgICAgICAgLSAgICAgICAg NSAgNjQsMTI4CiAgICAgICBtb2R1bGUgICA0ODQgICAgNjFLICAgICAgIC0gICAgICA0ODUg IDEyOAogICAgIG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAg ICAgICAgIG9zZCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTYsNjQKICAgICBw bWNob29rcyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4CiAgICAgICAgIGhk YWEgICAgMjEgICAgMjVLICAgICAgIC0gICAgICAgMjEgIDI1Niw1MTIsMTAyNCwyMDQ4LDQw OTYKICAgICAgICAgaGRhYyAgICAgMiAgICAgMksgICAgICAgLSAgICAgICAgMiAgNTEyLDEw MjQKICAgICAgICBoZGFjYyAgICAgNSAgICAgMUsgICAgICAgLSAgICAgICAgNSAgMzIKICAg ICAgICAgcGdycCAgICAgNSAgICAgMUsgICAgICAgLSAgICAgICA1NCAgMTI4CiAgICAgIHNl c3Npb24gICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgMjggIDEyOAogICAgICAgICBwcm9j ICAgICAyICAgIDMySyAgICAgICAtICAgICAgICAyICAKICAgICAgc3VicHJvYyAgICA5OSAg IDE0MUsgICAgICAgLSAgICAgMTc0MiAgNTEyLDQwOTYKICAgICAgICAgY3JlZCAgICAyNCAg ICAgNEsgICAgICAgLSAgICAgNzE3MiAgNjQsMjU2CiAgICAgICBwbGltaXQgICAgIDIgICAg IDFLICAgICAgIC0gICAgICAyMDcgIDI1NgogICAgICB1aWRpbmZvICAgICAzICAgICA1SyAg ICAgICAtICAgICAgIDIwICAxMjgsNDA5NgogICAgICBDQU0gREVWICAgICA5ICAgIDE4SyAg ICAgICAtICAgICAgIDE0ICAyMDQ4CiAgICAgU0NTSSBFTkMgICAgMjUgICAxMDBLICAgICAg IC0gICAgICAgNDUgIDE2LDY0LDI1NiwyMDQ4CiAgICAgcGNpX2xpbmsgICAgMTYgICAgIDJL ICAgICAgIC0gICAgICAgMTYgIDMyLDEyOAogICAgICAgc3lzY3RsICAgICAwICAgICAwSyAg ICAgICAtICAgICAgNDM5ICAxNiwzMiw2NAogICAgc3lzY3Rsb2lkICA1NDY2ICAgMjczSyAg ICAgICAtICAgICA1NTgxICAxNiwzMiw2NCwxMjgKICAgIHN5c2N0bHRtcCAgICAgMCAgICAg MEsgICAgICAgLSAgICAgIDIwMyAgMTYsMzIsNjQsMTI4LDI1NgogICAgICB0aWRoYXNoICAg ICAxICAgIDMySyAgICAgICAtICAgICAgICAxICAKICAgICAgY2FsbG91dCAgICAgNSAgMjE4 NEsgICAgICAgLSAgICAgICAgNSAgCiAgICAgICAgIHVtdHggICAyNDAgICAgMzBLICAgICAg IC0gICAgICAyNDAgIDEyOAogICAgIHAxMDAzLjFiICAgICAxICAgICAxSyAgICAgICAtICAg ICAgICAxICAxNgogICAgICAgICBTV0FQICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAy ICA2NAogICAgICAgICAgYnVzICAxMzExICAgMTE2SyAgICAgICAtICAgICA2ODkyICAxNiwz Miw2NCwxMjgsMjU2LDEwMjQsMjA0OAogICAgICAgYnVzLXNjICAgMTA3ICAgMzkxSyAgICAg ICAtICAgICA0Mzk4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAg ICBkZXZzdGF0ICAgIDEwICAgIDIxSyAgICAgICAtICAgICAgIDEwICAzMiw0MDk2CiBldmVu dGhhbmRsZXIgICAgODggICAgIDdLICAgICAgIC0gICAgICAgODggIDY0LDEyOAogICAgICAg ICBrb2JqICAgMzMyICAxMzI4SyAgICAgICAtICAgICAgNjc3ICA0MDk2CiAgICBhY3BpX3Bl cmYgICAgIDQgICAgIDJLICAgICAgIC0gICAgICAgIDQgIDUxMgogICAgICBQZXItY3B1ICAg ICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAzMgogICAgICAgREVWRlMzICAgMTQxICAg IDM2SyAgICAgICAtICAgICAgMTc3ICAyNTYKICAgICAgIERFVkZTMSAgIDEyMSAgICA2MUsg ICAgICAgLSAgICAgIDE0NyAgNTEyCiAgICAgICAgIHJtYW4gICAyNjUgICAgMzFLICAgICAg IC0gICAgICA2MTIgIDE2LDMyLDEyOAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAg ICAtICAgICAxMDYwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAg ICAgc2dsaXN0ICAgICAzICAgICAxSyAgICAgICAtICAgICAgIDIyICAzMiwyNTYsNTEyLDEw MjQsNDA5NgogICBERVZGU19SVUxFICAgIDU1ICAgIDI2SyAgICAgICAtICAgICAgIDU1ICA2 NCw1MTIKICAgICAgICBERVZGUyAgICAyMCAgICAgMUsgICAgICAgLSAgICAgICAyMiAgMTYs MTI4CiAgICAgICBERVZGU1AgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgMTggIDY0CiAg ICB0YXNrcXVldWUgICAgMjMgICAgIDRLICAgICAgIC0gICAgICAgMjMgIDE2LDMyLDI1Ngog ICAgICAgVW5pdG5vICAgIDIwICAgICAySyAgICAgICAtICAgICAgMzk0ICAzMiw2NAogICAg ICAgICB2bWVtICAgICAzICAgMTY0SyAgICAgICAtICAgICAgICA2ICAxMDI0LDIwNDgsNDA5 NgogICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtICAgICAyMzk3ICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDQwOTYKICAgICAgIHNlbGVjdCAgICAyNSAgICAgNEsgICAg ICAgLSAgICAgICAyNSAgMTI4CiAgICAgICAgICBpb3YgICAgIDAgICAgIDBLICAgICAgIC0g ICAgMjUzNTggIDE2LDY0LDEyOCwyNTYsNTEyCiAgICAgICAgICBtc2cgICAgIDQgICAgMzBL ICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAgMTA2 SyAgICAgICAtICAgICAgICA0ICAyMDQ4LDQwOTYKICAgICAgICAgIHNobSAgICAgMiAgIDEy MEsgICAgICAgLSAgICAgICAgMyAgCiAgICAgICAgICB0dHkgICAgMTggICAgMThLICAgICAg IC0gICAgICAgMTkgIDEwMjQKICAgICAgICAgIHB0cyAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgICAgMSAgMjU2CiAgICAgbWJ1Zl90YWcgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAg NzAgIDMyLDY0CiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0gICAgICAgIDEg IAogICAgICAgc29uYW1lICAgICAxICAgICAxSyAgICAgICAtICAgIDE1Mzc2ICAxNiwzMiw2 NCwxMjgKICAgICAgICAgIHBjYiAgICAxMyAgIDY2MUsgICAgICAgLSAgICAgICA0NSAgMTYs MzIsMTI4LDEwMjQsMjA0OAogICAgIHZmc2NhY2hlICAgICAxICAyMDQ4SyAgICAgICAtICAg ICAgICAxICAKICAgY2xfc2F2ZWJ1ZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMSAg NjQKICAgICB2ZnNfaGFzaCAgICAgMSAgMTAyNEsgICAgICAgLSAgICAgICAgMSAgCiAgICAg ICB2bm9kZXMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDI1NgogICAgICAgIG1v dW50ICAgIDQ2ICAgICAzSyAgICAgICAtICAgICAgMTE2ICAxNiwzMiw2NCwxMjgsMjU2CiAg dm5vZGVtYXJrZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNTQgIDUxMgogICAgICAg ICAgQlBGICAgICA0ICAgICAxSyAgICAgICAtICAgICAgIDE5ICAxNiwxMjgsNTEyLDQwOTYK ICAgICAgICBpZm5ldCAgICAgNSAgICAgOUsgICAgICAgLSAgICAgICAgNSAgMTI4LDIwNDgK ICAgICAgIGlmYWRkciAgIDE4MSAgICAyMEsgICAgICAgLSAgICAgIDE4MiAgMzIsNjQsMTI4 LDI1Niw1MTIsMjA0OCw0MDk2CiAgZXRoZXJfbXVsdGkgICAgMTkgICAgIDFLICAgICAgIC0g ICAgICAgMjggIDE2LDMyLDY0CiAgICAgICAgY2xvbmUgICAgIDcgICAgIDFLICAgICAgIC0g ICAgICAgIDcgIDEyOAogICAgICAgYXJwY29tICAgICAyICAgICAxSyAgICAgICAtICAgICAg ICAyICAxNgogICAgICBsbHRhYmxlICAgIDExICAgICA1SyAgICAgICAtICAgICAgIDEyICAy NTYsNTEyCiAgICAgcm91dGV0YmwgICAgMzEgICAgIDZLICAgICAgIC0gICAgICAyNzggIDMy LDY0LDEyOCwyNTYsNTEyCiAgICAgODAyMTF2YXAgICAgIDEgICAgIDRLICAgICAgIC0gICAg ICAgIDEgIDQwOTYKICA4MDIxMWNyeXB0byAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAg MiAgMTI4LDUxMgogICAgIDgwMjExY29tICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAx ICAKICAgIDgwMjExbm9kZSAgICAgMSAgICAxNksgICAgICAgLSAgICAgICAgNSAgCiAgODAy MTFub2RlaWUgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMTYgIDMyLDI1Niw1MTIKIDgw MjExcmF0ZWN0bCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgNiAgMTYsNjQKICAgIDgw MjExc2NhbiAgICAgMiAgICAgNksgICAgICAgLSAgICAgICAxMyAgNTEyLDIwNDgsNDA5Ngog ICAgICAgICBpZ21wICAgICA0ICAgICAxSyAgICAgICAtICAgICAgICA0ICAyNTYKICAgICBp bl9tdWx0aSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMjU2CiAgICBzY3RwX2Ff aXQgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDMgIDE2CiAgICAgc2N0cF92cmYgICAg IDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAgc2N0cF9pZmEgICAgIDMgICAg IDFLICAgICAgIC0gICAgICAgIDQgIDEyOAogICAgIHNjdHBfaWZuICAgICAxICAgICAxSyAg ICAgICAtICAgICAgICAyICAxMjgKICAgIHNjdHBfaXRlciAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgMyAgMjU2CiAgICBob3N0Y2FjaGUgICAgIDEgICAgMjhLICAgICAgIC0gICAg ICAgIDEgIAogICAgIHN5bmNhY2hlICAgICAxICAgIDY0SyAgICAgICAtICAgICAgICAxICAK ICAgIGluNl9tdWx0aSAgICAxNSAgICAgMksgICAgICAgLSAgICAgICAxNSAgMzIsMjU2CiAg ICAgICAgICBtbGQgICAgIDQgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDEyOAogICAgICBO RlMgRkhBICAgICAxICAgICAySyAgICAgICAtICAgICAgICAxICAyMDQ4CiAgICAgICAgICBy cGMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgphdWRpdF9ldmNsYXNzICAg MTg3ICAgICA2SyAgICAgICAtICAgICAgMjI4ICAzMgogICAgICBwYWdlZGVwICAgICA3ICAg MTMwSyAgICAgICAtICAgICAgIDMxICAyNTYKICAgICBpbm9kZWRlcCAgICAyNSAgMTAzNksg ICAgICAgLSAgICAgIDE0OSAgNTEyCiAgICBibXNhZmVtYXAgICAgIDMgICAgIDlLICAgICAg IC0gICAgICAgODQgIDI1NgogICAgICAgbmV3YmxrICAgICA5ICAyMDUwSyAgICAgICAtICAg ICAgIDY4ICAyNTYKICAgICBmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAg MiAgMTI4CiAgICAgZnJlZWJsa3MgICAgMTUgICAgIDRLICAgICAgIC0gICAgICAgNTMgIDI1 NgogICAgIGZyZWVmaWxlICAgICAxICAgICAxSyAgICAgICAtICAgICAgIDQzICA2NAogICAg ICAgZGlyYWRkICAgICAyICAgICAxSyAgICAgICAtICAgICAgIDY0ICAxMjgKICAgICAgICBt a2RpciAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxMiAgMTI4CiAgICAgICBkaXJyZW0g ICAgMTIgICAgIDJLICAgICAgIC0gICAgICAgNjAgIDEyOAogICAgbmV3ZGlyYmxrICAgICAw ICAgICAwSyAgICAgICAtICAgICAgICA2ICA2NAogICAgIGZyZWV3b3JrICAgIDE2ICAgICAy SyAgICAgICAtICAgICAgIDU2ICAxNiwxMjgKICAgICAgamFkZHJlZiAgICAgMCAgICAgMEsg ICAgICAgLSAgICAgICA3NiAgMTI4CiAgICAgIGpyZW1yZWYgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgNzIgIDEyOAogICAgICAgam12cmVmICAgICAwICAgICAwSyAgICAgICAtICAg ICAgICAxICAxMjgKICAgICAgam5ld2JsayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICA2 NyAgMTI4CiAgICBqZnJlZWZyYWcgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDIgIDEy OAogICAgICAgICBqc2VnICAgICA1ICAgICAxSyAgICAgICAtICAgICAgIDM1ICAxMjgKICAg ICAganNlZ2RlcCAgICAyMyAgICAgMksgICAgICAgLSAgICAgIDIxNyAgNjQKICAgICAgICBz YmRlcCAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxNCAgNjQKICAgICBzYXZlZGlubyAg ICAgMCAgICAgMEsgICAgICAgLSAgICAgICAyMSAgMjU2CiAgICAgIGpibG9ja3MgICAgIDQg ICAgIDFLICAgICAgIC0gICAgICAgIDQgIDEyOCwyNTYKICB1ZnNfZGlyaGFzaCAgICA2MCAg ICAxMksgICAgICAgLSAgICAgICA2MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIKICAgIHVmc19x dW90YSAgICAgMSAgMTAyNEsgICAgICAgLSAgICAgICAgMSAgCiAgICB1ZnNfbW91bnQgICAg IDYgICAgMjlLICAgICAgIC0gICAgICAgIDYgIDUxMiw0MDk2CiAgICB2bV9wZ2RhdGEgICAg IDEgICA1MTJLICAgICAgIC0gICAgICAgIDIgIDEyOAogICAgICBVTUFIYXNoICAgICAyICAg ICAxSyAgICAgICAtICAgICAgICAyICA1MTIKICAgIHBmc19ub2RlcyAgICAyMSAgICAgNksg ICAgICAgLSAgICAgICAyMSAgMjU2CiAgICAgIG1lbWRlc2MgICAgIDEgICAgIDRLICAgICAg IC0gICAgICAgIDIgIDQwOTYKICBwZnNfdm5jYWNoZSAgICAgMyAgICAgMUsgICAgICAgLSAg ICAgICAgMyAgNjQKICAgICAgICAgR0VPTSAgICA5NyAgICAxNksgICAgICAgLSAgICAgMTE5 NSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4CiAgICAgICBmZWVkZXIgICAgMjUg ICAgIDNLICAgICAgIC0gICAgICAgMzMgIDMyLDEyOAogICAgIGF0a2JkZGV2ICAgICAyICAg ICAxSyAgICAgICAtICAgICAgICAyICA2NAogICAgICBDQU0gQ0NCICAgIDM2ICAgIDcySyAg ICAgICAtICAgICAgIDY2ICAyMDQ4CiAgICAgICAgbWl4ZXIgICAgIDYgICAgMjRLICAgICAg IC0gICAgICAgIDYgIDQwOTYKICAgIHJhaWRfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgIDE5MiAgMzIsMTI4LDI1NgogICAgIGFjcGlpbnRyICAgICAxICAgICAxSyAgICAgICAt ICAgICAgICAxICA2NAogICAgICAgICBVQVJUICAgICAzICAgICAzSyAgICAgICAtICAgICAg ICAzICAxNiwxMDI0Cm1kX252aWRpYV9kYXRhICAgICAwICAgICAwSyAgICAgICAtICAgICAg IDMxICA1MTIKICAgICAgIGFjcGljYSAgNjA1OSAgIDYxMUsgICAgICAgLSAgICA2NjUxNSAg MTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICBtZF9zaWlfZGF0YSAgICAg MCAgICAgMEsgICAgICAgLSAgICAgICAzMSAgNTEyCiAgICAgQ0FNIHBhdGggICAgMTIgICAg IDFLICAgICAgIC0gICAgICAgMzkgIDMyCiAgIENBTSBwZXJpcGggICAgIDggICAgIDJLICAg ICAgIC0gICAgICAgMjMgIDE2LDMyLDY0LDEyOCwyNTYKICAgICBhY3BpdGFzayAgICAgMSAg ICAgOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgICBhcG1kZXYgICAgIDEgICAgIDFLICAg ICAgIC0gICAgICAgIDEgIDEyOAogICBtYWR0X3RhYmxlICAgICAwICAgICAwSyAgICAgICAt ICAgICAgICAxICA0MDk2CiAgICAgIGFjcGlzZW0gICAgMjcgICAgIDRLICAgICAgIC0gICAg ICAgMjcgIDEyOAogICAgQ0FNIHF1ZXVlICAgIDE5ICAgICA1SyAgICAgICAtICAgICAgIDUw ICAxNiwzMiw1MTIKICAgICAgYWNwaWRldiAgICA1MSAgICAgNEsgICAgICAgLSAgICAgICA1 MSAgNjQKQ0FNIGRldiBxdWV1ZSAgICAgNiAgICAgMUsgICAgICAgLSAgICAgICAgNiAgMzIK ICAgICAgaW9fYXBpYyAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICAg ICAgICAgTUNBICAgIDE0ICAgICAySyAgICAgICAtICAgICAgIDE0ICAzMiwxMjgKICAgICAg ICAgIG1zaSAgICAxMyAgICAgMksgICAgICAgLSAgICAgICAxMyAgMTI4CiAgICAgbmV4dXNk ZXYgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2CiAgICAgICBpc2FkZXYgICAg IDggICAgIDFLICAgICAgIC0gICAgICAgIDggIDEyOAogICAgICAgICAgVVNCICAgIDM1ICAg IDQxSyAgICAgICAtICAgICAgIDUwICAxNiwzMiwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5 NgogICAgICAgY3B1Y3RsICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAzMgogICAg ICAgbnZpZGlhICAgMzk5ICAxNDI1SyAgICAgICAtICAgICA1MDI0ICAxNiwzMiw2NCwxMjgs MjU2LDUxMiwxMDI0LDIwNDgsNDA5NgpuZXRncmFwaF9ub2RlICAgICAyICAgICAxSyAgICAg ICAtICAgICAgICAyICAxMjgKICAgICAgICBsaW51eCAgICAxNSAgICAgMUsgICAgICAgLSAg ICAgICAxNSAgNjQKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQgLXoKCklURU0gICAgICAg ICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZSRUUgICAgICBSRVEgRkFJ TCBTTEVFUAoKVU1BIEtlZ3M6ICAgICAgICAgICAgICAgMzg0LCAgICAgIDAsICAgICAgOTgs ICAgICAgIDIsICAgICAgOTgsICAgMCwgICAwClVNQSBab25lczogICAgICAgICAgICAgMTE1 MiwgICAgICAwLCAgICAgIDk4LCAgICAgICAxLCAgICAgIDk4LCAgIDAsICAgMApVTUEgU2xh YnM6ICAgICAgICAgICAgICAgODAsICAgICAgMCwgICAgMTQ1MCwgICAgICA1MCwgICAgMzEy OSwgICAwLCAgIDAKVU1BIFJDbnRTbGFiczogICAgICAgICAgIDg4LCAgICAgIDAsICAgICAy ODEsICAgICAgMzQsICAgICAyODEsICAgMCwgICAwClVNQSBIYXNoOiAgICAgICAgICAgICAg IDI1NiwgICAgICAwLCAgICAgICA4LCAgICAgICA3LCAgICAgIDEwLCAgIDAsICAgMAo0IEJ1 Y2tldDogICAgICAgICAgICAgICAgMzIsICAgICAgMCwgICAgICA2MywgICAgIDQzNywgICAg MTI2MiwgICAwLCAgIDAKOCBCdWNrZXQ6ICAgICAgICAgICAgICAgIDY0LCAgICAgIDAsICAg ICAgMzksICAgICA1MTksICAgICA0OTcsICAgMCwgICAwCjE2IEJ1Y2tldDogICAgICAgICAg ICAgIDEyOCwgICAgICAwLCAgICAgIDU1LCAgICAgNDcyLCAgICAgMTAyLCAgMzgsICAgMAoz MiBCdWNrZXQ6ICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgICA0NiwgICAgIDIwOSwg ICAgIDExNiwgMTAyLCAgIDAKNjQgQnVja2V0OiAgICAgICAgICAgICAgNTEyLCAgICAgIDAs ICAgICAxMDcsICAgICAgNzcsICAgICAzNjQsICA5OSwgICAwCjEyOCBCdWNrZXQ6ICAgICAg ICAgICAgMTAyNCwgICAgICAwLCAgICAgMTUxLCAgICAgIDI1LCAgICAgODQ4LCAgMTIsICAg MAp2bWVtIGJ0YWc6ICAgICAgICAgICAgICAgNTYsICAgICAgMCwgICAxMDI3OSwgICAgMjU3 MiwgICAxMjYwOSwgMTgxLCAgIDAKVk0gT0JKRUNUOiAgICAgICAgICAgICAgMjU2LCAgICAg IDAsICAgIDExMTksICAgICA4NDYsICAgMjA3MTIsICAgMCwgICAwClJBRElYIE5PREU6ICAg ICAgICAgICAgIDE0NCwgICAgICAwLCAgICAzNTkwLCAgICAxNDA1LCAgIDQ0OTA2LCAgNDks ICAgMApNQVA6ICAgICAgICAgICAgICAgICAgICAyNDAsICAgICAgMCwgICAgICAgMywgICAg ICA2MSwgICAgICAgMywgICAwLCAgIDAKS01BUCBFTlRSWTogICAgICAgICAgICAgMTI4LCAg ICAgIDAsICAgICAgMTAsICAgICAzOTMsICAgICAgMjYsICAgMCwgICAwCk1BUCBFTlRSWTog ICAgICAgICAgICAgIDEyOCwgICAgICAwLCAgICAgMTgxLCAgICAxMzM4LCAgIDQ2MjkwLCAg IDAsICAgMApWTVNQQUNFOiAgICAgICAgICAgICAgICA0NDgsICAgICAgMCwgICAgICAgNSwg ICAgIDE0OCwgICAgMTY0OSwgICAwLCAgIDAKZmFrZXBnOiAgICAgICAgICAgICAgICAgMTA0 LCAgICAgIDAsICAgICAgIDgsICAgICA1MjQsICAgICAyNTMsICAgMCwgICAwCm10X3pvbmU6 ICAgICAgICAgICAgICAgNDExMiwgICAgICAwLCAgICAgMzU0LCAgICAgICAwLCAgICAgMzU0 LCAgIDAsICAgMAoxNjogICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgMCwgICAgMjY0 MCwgICAgIDM3MiwgICAzODI2NiwgICAwLCAgIDAKMzI6ICAgICAgICAgICAgICAgICAgICAg IDMyLCAgICAgIDAsICAgIDMwNjMsICAgICA1NjIsICAgMTA5OTgsICAgMCwgICAwCjY0OiAg ICAgICAgICAgICAgICAgICAgICA2NCwgICAgICAwLCAgIDEyODgwLCAgICAgNzYwLCAgIDQ0 NDA5LCAgIDAsICAgMAoxMjg6ICAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAx MjE1MCwgICAgIDYyMiwgICA1NTkxNSwgICAwLCAgIDAKMjU2OiAgICAgICAgICAgICAgICAg ICAgMjU2LCAgICAgIDAsICAgICA3NDgsICAgICA2NjIsICAgIDczMjksICAgMCwgICAwCjUx MjogICAgICAgICAgICAgICAgICAgIDUxMiwgICAgICAwLCAgICAgNTU2LCAgICAgMjYwLCAg ICAyNzQ3LCAgIDAsICAgMAoxMDI0OiAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwg ICAgICA5MSwgICAgIDE3NywgICAgMzcwMiwgICAwLCAgIDAKMjA0ODogICAgICAgICAgICAg ICAgICAyMDQ4LCAgICAgIDAsICAgICAxMzUsICAgICAgOTEsICAgIDM4MjksICAgMCwgICAw CjQwOTY6ICAgICAgICAgICAgICAgICAgNDA5NiwgICAgICAwLCAgICAgNDYyLCAgICAgIDQ1 LCAgICAyODM0LCAgIDAsICAgMApTTEVFUFFVRVVFOiAgICAgICAgICAgICAgODAsICAgICAg MCwgICAgIDEyMSwgICAgIDE1OCwgICAgIDEyMSwgICAwLCAgIDAKdWludDY0IHBjcHU6ICAg ICAgICAgICAgICA4LCAgICAgIDAsICAgIDE0NDAsICAgICAgOTYsICAgIDE0NDAsICAgMCwg ICAwCkZpbGVzOiAgICAgICAgICAgICAgICAgICA4MCwgICAgICAwLCAgICAgIDE1LCAgICAg NDg1LCAgIDEwODM4LCAgIDAsICAgMApUVVJOU1RJTEU6ICAgICAgICAgICAgICAxMzYsICAg ICAgMCwgICAgIDEyMSwgICAgICA3OSwgICAgIDEyMSwgICAwLCAgIDAKcmxfZW50cnk6ICAg ICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAgNTIsICAgICA0NDgsICAgICAgNTIsICAg MCwgICAwCnVtdHggcGk6ICAgICAgICAgICAgICAgICA5NiwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMApNQUMgbGFiZWxzOiAgICAgICAgICAgICAgNDAs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKUFJPQzogICAg ICAgICAgICAgICAgICAxMjA4LCAgICAgIDAsICAgICAgMjUsICAgICAgNDcsICAgIDE2Njcs ICAgMCwgICAwClRIUkVBRDogICAgICAgICAgICAgICAgMTE2OCwgICAgICAwLCAgICAgMTE3 LCAgICAgICAzLCAgICAgMTE3LCAgIDAsICAgMApjcHVzZXQ6ICAgICAgICAgICAgICAgICAg NzIsICAgICAgMCwgICAgICA2OCwgICAgIDIwNywgICAgICA2OCwgICAwLCAgIDAKYXVkaXRf cmVjb3JkOiAgICAgICAgICAxMjQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCm1idWZfcGFja2V0OiAgICAgICAgICAgIDI1NiwgMTU1MzE2MCwgICAg ICAgMCwgICAgIDQxNiwgICAgIDYxOSwgNDA1LCAgIDAKbWJ1ZjogICAgICAgICAgICAgICAg ICAgMjU2LCAxNTUzMTYwLCAgICAgIDY1LCAgICAgMjgwLCAgICAyOTcyLCAyMDksICAgMApt YnVmX2NsdXN0ZXI6ICAgICAgICAgIDIwNDgsIDI0MjY4MCwgICAgIDQwNSwgICAgICAxMSwg ICAgIDQwNSwgICAwLCAgIDAKbWJ1Zl9qdW1ib19wYWdlOiAgICAgICA0MDk2LCAxMjEzMzks ICAgICAgNjQsICAgICAgIDksICAgIDE4MjEsICAgMCwgICAwCm1idWZfanVtYm9fOWs6ICAg ICAgICAgOTIxNiwgMTA3ODU2LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MAptYnVmX2p1bWJvXzE2azogICAgICAgMTYzODQsICA4MDg5MiwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKbWJ1Zl9leHRfcmVmY250OiAgICAgICAgICA0LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnR0eWlucTogICAgICAg ICAgICAgICAgIDE2MCwgICAgICAwLCAgICAgIDE1LCAgICAgMjM1LCAgICAgNTcwLCAgIDAs ICAgMAp0dHlvdXRxOiAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgICAgOCwgICAg IDI0NywgICAgIDI4OCwgICAwLCAgIDAKZ19iaW86ICAgICAgICAgICAgICAgICAgMjQ4LCAg ICAgIDAsICAgICAgIDAsICAgICA0OTYsICAgMTExNTcsICAgMCwgICAwCmF0YV9yZXF1ZXN0 OiAgICAgICAgICAgIDMzNiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMAp2dG5ldF90eF9oZHI6ICAgICAgICAgICAgMjQsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKbnZfc3RhY2tfdDogICAgICAgICAgIDEyMjg4 LCAgICAgIDAsICAgICAgIDcsICAgICAgIDQsICAgICAyMDYsICAgMCwgICAwCkZQVV9zYXZl X2FyZWE6ICAgICAgICAgIDUxMiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApWTk9ERTogICAgICAgICAgICAgICAgICA0NzIsICAgICAgMCwgICAgMTA0 OCwgICAgICA1NiwgICAgMTEwNCwgICAwLCAgIDAKVk5PREVQT0xMOiAgICAgICAgICAgICAg MTEyLCAgICAgIDAsICAgICAgIDIsICAgICAxMzgsICAgICAgIDIsICAgMCwgICAwCkJVRiBU UklFOiAgICAgICAgICAgICAgIDE0NCwgICAgICAwLCAgICAgMTQ3LCAgIDI1NjExLCAgICAg NTUxLCAgIDAsICAgMApTIFZGUyBDYWNoZTogICAgICAgICAgICAxMDgsICAgICAgMCwgICAg MTAwOSwgICAgIDI1MSwgICAgMzAwMiwgICAwLCAgIDAKU1RTIFZGUyBDYWNoZTogICAgICAg ICAgMTQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkwg VkZTIENhY2hlOiAgICAgICAgICAgIDMyOCwgICAgICAwLCAgICAgIDM0LCAgICAgIDI2LCAg ICAgIDM0LCAgIDAsICAgMApMVFMgVkZTIENhY2hlOiAgICAgICAgICAzNjgsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTkFNRUk6ICAgICAgICAgICAg ICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAsICAgICAgNjgsICAgMjUyMTcsICAgMCwgICAw Ck5DTE5PREU6ICAgICAgICAgICAgICAgIDUyOCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMApESVJIQVNIOiAgICAgICAgICAgICAgIDEwMjQsICAgICAg MCwgICAgIDEwMywgICAgICAyOSwgICAgIDEwMywgICAwLCAgIDAKTW91bnRwb2ludHM6ICAg ICAgICAgICAgODE2LCAgICAgIDAsICAgICAgIDQsICAgICAgMjYsICAgICAgIDQsICAgMCwg ICAwCnBpcGU6ICAgICAgICAgICAgICAgICAgIDc0NCwgICAgICAwLCAgICAgICAwLCAgICAg IDU1LCAgICAgOTg5LCAgIDAsICAgMApwcm9jZGVzYzogICAgICAgICAgICAgICAxMjgsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKa3NpZ2luZm86ICAg ICAgICAgICAgICAgMTEyLCAgICAgIDAsICAgICAgNjEsICAgICA5ODksICAgICAxMTIsICAg MCwgICAwCml0aW1lcjogICAgICAgICAgICAgICAgIDM1MiwgICAgICAwLCAgICAgICAwLCAg ICAgIDMzLCAgICAgICAxLCAgIDAsICAgMApLTk9URTogICAgICAgICAgICAgICAgICAxMjgs ICAgICAgMCwgICAgICAgMCwgICAgIDUyNywgICAgICAyMSwgICAwLCAgIDAKc29ja2V0OiAg ICAgICAgICAgICAgICAgNjk2LCAxMjU0MjAsICAgICAgIDQsICAgICAgNzYsICAgIDI4NTUs ICAgMCwgICAwCmlwcTogICAgICAgICAgICAgICAgICAgICA1NiwgICA3NTk3LCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp1ZHBfaW5wY2I6ICAgICAgICAgICAgICAz OTIsIDEyNTQyMCwgICAgICAgMCwgICAgIDEyMCwgICAgIDI1MiwgICAwLCAgIDAKdWRwY2I6 ICAgICAgICAgICAgICAgICAgIDE2LCAxMjU1MDAsICAgICAgIDAsICAgICA1MDIsICAgICAy NTIsICAgMCwgICAwCnRjcF9pbnBjYjogICAgICAgICAgICAgIDM5MiwgMTI1NDIwLCAgICAg ICAyLCAgICAgMTE4LCAgICAgIDExLCAgIDAsICAgMAp0Y3BjYjogICAgICAgICAgICAgICAg IDEwMjQsIDEyNTQyMCwgICAgICAgMiwgICAgICA1MCwgICAgICAxMSwgICAwLCAgIDAKdGNw dHc6ICAgICAgICAgICAgICAgICAgIDg4LCAgMjUxMTAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwCnN5bmNhY2hlOiAgICAgICAgICAgICAgIDE2MCwgIDE1Mzc1LCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApob3N0Y2FjaGU6ICAgICAgICAg ICAgICAxMzYsICAxNTM3MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAK dGNwcmVhc3M6ICAgICAgICAgICAgICAgIDQwLCAgMTUyMDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnNhY2tob2xlOiAgICAgICAgICAgICAgICAzMiwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX2VwOiAgICAgICAg ICAgICAgIDE0MDgsIDEyNTQyMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKc2N0cF9hc29jOiAgICAgICAgICAgICAyMzUyLCAgNDAwMDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfbGFkZHI6ICAgICAgICAgICAgICA0OCwgIDgw MDEyLCAgICAgICAwLCAgICAgMzMyLCAgICAgICA0LCAgIDAsICAgMApzY3RwX3JhZGRyOiAg ICAgICAgICAgICA3MjgsICA4MDAwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKc2N0cF9jaHVuazogICAgICAgICAgICAgMTM2LCA0MDAwMjYsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfcmVhZHE6ICAgICAgICAgICAgIDEwNCwg NDAwMDI2LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX3N0cmVh bV9tc2dfb3V0OiAgICAxMDQsIDQwMDAyNiwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKc2N0cF9hc2NvbmY6ICAgICAgICAgICAgIDQwLCA0MDAwMDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfYXNjb25mX2FjazogICAgICAgICA0 OCwgNDAwMDYwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApyaXBjYjog ICAgICAgICAgICAgICAgICAzOTIsIDEyNTQyMCwgICAgICAgMCwgICAgICAzMCwgICAgICAg MSwgICAwLCAgIDAKdW5wY2I6ICAgICAgICAgICAgICAgICAgMjQwLCAxMjU0MjQsICAgICAg IDIsICAgICAyNTQsICAgIDI1NzUsICAgMCwgICAwCnJ0ZW50cnk6ICAgICAgICAgICAgICAg IDIwMCwgICAgICAwLCAgICAgIDEyLCAgICAgMTg4LCAgICAgIDE0LCAgIDAsICAgMApzZWxm ZDogICAgICAgICAgICAgICAgICAgNTYsICAgICAgMCwgICAgICAzMCwgICAgIDUzOCwgICAz NzM0MiwgICAwLCAgIDAKU1dBUE1FVEE6ICAgICAgICAgICAgICAgMjg4LCA0ODUzNjgsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkZGUyBpbm9kZTogICAgICAgICAg ICAgIDE2OCwgICAgICAwLCAgICAxMDAwLCAgICAgMTA0LCAgICAxMDQ0LCAgIDAsICAgMApG RlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKRkZTMiBkaW5vZGU6ICAgICAgICAgICAgMjU2LCAgICAgIDAs ICAgIDEwMDAsICAgICAgNTAsICAgIDEwNDMsICAgMCwgICAwCk5ldEdyYXBoIGl0ZW1zOiAg ICAgICAgICA3MiwgICA0MTIzLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MApOZXRHcmFwaCBkYXRhIGl0ZW1zOiAgICAgNzIsICAgIDUyNywgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1pCgpp bnRlcnJ1cHQgICAgICAgICAgICAgICAgICAgICAgICAgIHRvdGFsICAgICAgIHJhdGUKaXJx MTogYXRrYmQwICAgICAgICAgICAgICAgICAgICAgICAgIDYzOSAgICAgICAgIDE1CmlycTk6 IGFjcGkwICAgICAgICAgICAgICAgICAgICAgICAgICA0NjIgICAgICAgICAxMQppcnExMjog cHNtMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAzICAgICAgICAgIDAKaXJxMTc6IGhk YWMwIHVhcnQyICAgICAgICAgICAgICAgICAgICAyMCAgICAgICAgICAwCmlycTE5OiBlaGNp MSAgICAgICAgICAgICAgICAgICAgICAgICAzODYgICAgICAgICAgOQppcnEyMzogZWhjaTAg ICAgICAgICAgICAgICAgICAgICAgICAgMzk0ICAgICAgICAgIDkKaXJxMjU2OiBocGV0MDp0 MCAgICAgICAgICAgICAgICAgICAgMzE2MCAgICAgICAgIDc1CmlycTI1NzogaHBldDA6dDEg ICAgICAgICAgICAgICAgICAgIDE4OTMgICAgICAgICA0NQppcnEyNTg6IGhwZXQwOnQyICAg ICAgICAgICAgICAgICAgICAgNjAxICAgICAgICAgMTQKaXJxMjU5OiBocGV0MDp0MyAgICAg ICAgICAgICAgICAgICAgMTA3NCAgICAgICAgIDI1CmlycTI2NDogdmdhcGNpMCAgICAgICAg ICAgICAgICAgICAgICA0OTMgICAgICAgICAxMQppcnEyNjY6IGhkYWMxICAgICAgICAgICAg ICAgICAgICAgICAgIDU5ICAgICAgICAgIDEKaXJxMjY3OiBpd24wICAgICAgICAgICAgICAg ICAgICAgICAgNDU1MyAgICAgICAgMTA4CmlycTI2ODogYWhjaTAgICAgICAgICAgICAgICAg ICAgICAgIDM1NDcgICAgICAgICA4NApUb3RhbCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDE3Mjg0ICAgICAgICA0MTEKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtVAoKIDE1 LzEyNTQxNiBmaWxlcwowTS8wTSBzd2FwIHNwYWNlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KcHN0 YXQgLXMKCkRldmljZSAgICAgICAgICA1MTItYmxvY2tzICAgICBVc2VkICAgIEF2YWlsIENh cGFjaXR5CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaW9zdGF0Cgppb3N0YXQ6IGt2bV9yZWFkKF90 a19uaW4pOiBpbnZhbGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0OiBkaXNhYmxpbmcgVFRZIHN0 YXRpc3RpY3MKICAgICAgICAgICAgYWRhMCAgICAgICAgICAgICAgY2QwICAgICAgICAgICAg cGFzczAgICAgICAgICAgICAgY3B1CiAgS0IvdCB0cHMgIE1CL3MgICBLQi90IHRwcyAgTUIv cyAgIEtCL3QgdHBzICBNQi9zICB1cyBuaSBzeSBpbiBpZAogMjYuOTYgIDgxICAyLjE1ICAg MC4wMCAgIDEgIDAuMDAgICAwLjAwICAgMCAgMC4wMCAgIDAgIDAgIDEgIDAgOTkKCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQppcGNzIC1hCgpNZXNzYWdlIFF1ZXVlczoKVCAgICAgICAgICAgSUQg ICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENH Uk9VUCAgICAgICAgICAgICAgICAgQ0JZVEVTICAgICAgICAgICAgICAgICBRTlVNICAgICAg ICAgICAgICAgUUJZVEVTICAgICAgICBMU1BJRCAgICAgICAgTFJQSUQgU1RJTUUgICAgUlRJ TUUgICAgQ1RJTUUgICAKClNoYXJlZCBNZW1vcnk6ClQgICAgICAgICAgIElEICAgICAgICAg IEtFWSBNT0RFICAgICAgICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAg ICAgICBOQVRUQ0ggICAgICAgIFNFR1NaICAgICAgICAgQ1BJRCAgICAgICAgIExQSUQgQVRJ TUUgICAgRFRJTUUgICAgQ1RJTUUgICAKClNlbWFwaG9yZXM6ClQgICAgICAgICAgIElEICAg ICAgICAgIEtFWSBNT0RFICAgICAgICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JP VVAgICAgICAgICAgTlNFTVMgT1RJTUUgICAgQ1RJTUUgICAKCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KaXBjcyAtVAoKbXNnaW5mbzoKCW1zZ21heDogICAgICAgIDE2Mzg0CShtYXggY2hhcmFj dGVycyBpbiBhIG1lc3NhZ2UpCgltc2dtbmk6ICAgICAgICAgICA0MAkoIyBvZiBtZXNzYWdl IHF1ZXVlcykKCW1zZ21uYjogICAgICAgICAyMDQ4CShtYXggY2hhcmFjdGVycyBpbiBhIG1l c3NhZ2UgcXVldWUpCgltc2d0cWw6ICAgICAgICAgICA0MAkobWF4ICMgb2YgbWVzc2FnZXMg aW4gc3lzdGVtKQoJbXNnc3N6OiAgICAgICAgICAgIDgJKHNpemUgb2YgYSBtZXNzYWdlIHNl Z21lbnQpCgltc2dzZWc6ICAgICAgICAgMjA0OAkoIyBvZiBtZXNzYWdlIHNlZ21lbnRzIGlu IHN5c3RlbSkKCnNobWluZm86CglzaG1tYXg6ICAgIDEzNDIxNzcyOAkobWF4IHNoYXJlZCBt ZW1vcnkgc2VnbWVudCBzaXplKQoJc2htbWluOiAgICAgICAgICAgIDEJKG1pbiBzaGFyZWQg bWVtb3J5IHNlZ21lbnQgc2l6ZSkKCXNobW1uaTogICAgICAgICAxMDI0CShtYXggbnVtYmVy IG9mIHNoYXJlZCBtZW1vcnkgaWRlbnRpZmllcnMpCglzaG1zZWc6ICAgICAgICAgMTAyNAko bWF4IHNoYXJlZCBtZW1vcnkgc2VnbWVudHMgcGVyIHByb2Nlc3MpCglzaG1hbGw6ICAgICAg ICAzMjc2OAkobWF4IGFtb3VudCBvZiBzaGFyZWQgbWVtb3J5IGluIHBhZ2VzKQoKc2VtaW5m bzoKCXNlbW1uaTogICAgICAgICAgIDUwCSgjIG9mIHNlbWFwaG9yZSBpZGVudGlmaWVycykK CXNlbW1uczogICAgICAgICAgMzQwCSgjIG9mIHNlbWFwaG9yZXMgaW4gc3lzdGVtKQoJc2Vt bW51OiAgICAgICAgICAxNTAJKCMgb2YgdW5kbyBzdHJ1Y3R1cmVzIGluIHN5c3RlbSkKCXNl bW1zbDogICAgICAgICAgMzQwCShtYXggIyBvZiBzZW1hcGhvcmVzIHBlciBpZCkKCXNlbW9w bTogICAgICAgICAgMTAwCShtYXggIyBvZiBvcGVyYXRpb25zIHBlciBzZW1vcCBjYWxsKQoJ c2VtdW1lOiAgICAgICAgICAgNTAJKG1heCAjIG9mIHVuZG8gZW50cmllcyBwZXIgcHJvY2Vz cykKCXNlbXVzejogICAgICAgICAgNjMyCShzaXplIGluIGJ5dGVzIG9mIHVuZG8gc3RydWN0 dXJlKQoJc2Vtdm14OiAgICAgICAgMzI3NjcJKHNlbWFwaG9yZSBtYXhpbXVtIHZhbHVlKQoJ c2VtYWVtOiAgICAgICAgMTYzODQJKGFkanVzdCBvbiBleGl0IG1heCB2YWx1ZSkKCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KbmZzc3RhdAoKQ2xpZW50IEluZm86ClJwYyBDb3VudHM6CiAgR2V0 YXR0ciAgIFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJlYWQgICAgIFdyaXRl ICAgIENyZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAogICBSZW5h bWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGlyICAgUmVhZGRpciAg UmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9k ICAgIEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClJwYyBJbmZvOgogVGltZWRP dXQgICBJbnZhbGlkIFggUmVwbGllcyAgIFJldHJpZXMgIFJlcXVlc3RzCiAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKQ2FjaGUgSW5mbzoKQXR0 ciBIaXRzICAgIE1pc3NlcyBMa3VwIEhpdHMgICAgTWlzc2VzIEJpb1IgSGl0cyAgICBNaXNz ZXMgQmlvVyBIaXRzICAgIE1pc3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCkJpb1JM SGl0cyAgICBNaXNzZXMgQmlvRCBIaXRzICAgIE1pc3NlcyBEaXJFIEhpdHMgICAgTWlzc2Vz IEFjY3MgSGl0cyAgICBNaXNzZXMKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAoKU2VydmVy IEluZm86CiAgR2V0YXR0ciAgIFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJl YWQgICAgIFdyaXRlICAgIENyZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMAogICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGly ICAgUmVhZGRpciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAg IDAKICAgIE1rbm9kICAgIEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1pdAog ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClNlcnZl ciBSZXQtRmFpbGVkCiAgICAgICAgICAgICAgICAwClNlcnZlciBGYXVsdHMKICAgICAgICAg ICAgMApTZXJ2ZXIgQ2FjaGUgU3RhdHM6CiAgIElucHJvZyAgICAgIElkZW0gIE5vbi1pZGVt ICAgIE1pc3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2Vy dmVyIFdyaXRlIEdhdGhlcmluZzoKIFdyaXRlT3BzICBXcml0ZVJQQyAgIE9wc2F2ZWQKICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0 IC1zCgp0Y3A6CgkwIHBhY2tldHMgc2VudAoJCTAgZGF0YSBwYWNrZXRzICgwIGJ5dGVzKQoJ CTAgZGF0YSBwYWNrZXRzICgwIGJ5dGVzKSByZXRyYW5zbWl0dGVkCgkJMCBkYXRhIHBhY2tl dHMgdW5uZWNlc3NhcmlseSByZXRyYW5zbWl0dGVkCgkJMCByZXNlbmRzIGluaXRpYXRlZCBi eSBNVFUgZGlzY292ZXJ5CgkJMCBhY2stb25seSBwYWNrZXRzICgwIGRlbGF5ZWQpCgkJMCBV Ukcgb25seSBwYWNrZXRzCgkJMCB3aW5kb3cgcHJvYmUgcGFja2V0cwoJCTAgd2luZG93IHVw ZGF0ZSBwYWNrZXRzCgkJMCBjb250cm9sIHBhY2tldHMKCTAgcGFja2V0cyByZWNlaXZlZAoJ CTAgYWNrcyAoZm9yIDAgYnl0ZXMpCgkJMCBkdXBsaWNhdGUgYWNrcwoJCTAgYWNrcyBmb3Ig dW5zZW50IGRhdGEKCQkwIHBhY2tldHMgKDAgYnl0ZXMpIHJlY2VpdmVkIGluLXNlcXVlbmNl CgkJMCBjb21wbGV0ZWx5IGR1cGxpY2F0ZSBwYWNrZXRzICgwIGJ5dGVzKQoJCTAgb2xkIGR1 cGxpY2F0ZSBwYWNrZXRzCgkJMCBwYWNrZXRzIHdpdGggc29tZSBkdXAuIGRhdGEgKDAgYnl0 ZXMgZHVwZWQpCgkJMCBvdXQtb2Ytb3JkZXIgcGFja2V0cyAoMCBieXRlcykKCQkwIHBhY2tl dHMgKDAgYnl0ZXMpIG9mIGRhdGEgYWZ0ZXIgd2luZG93CgkJMCB3aW5kb3cgcHJvYmVzCgkJ MCB3aW5kb3cgdXBkYXRlIHBhY2tldHMKCQkwIHBhY2tldHMgcmVjZWl2ZWQgYWZ0ZXIgY2xv c2UKCQkwIGRpc2NhcmRlZCBmb3IgYmFkIGNoZWNrc3VtcwoJCTAgZGlzY2FyZGVkIGZvciBi YWQgaGVhZGVyIG9mZnNldCBmaWVsZHMKCQkwIGRpc2NhcmRlZCBiZWNhdXNlIHBhY2tldCB0 b28gc2hvcnQKCQkwIGRpc2NhcmRlZCBkdWUgdG8gbWVtb3J5IHByb2JsZW1zCgkwIGNvbm5l Y3Rpb24gcmVxdWVzdHMKCTAgY29ubmVjdGlvbiBhY2NlcHRzCgkwIGJhZCBjb25uZWN0aW9u IGF0dGVtcHRzCgkwIGxpc3RlbiBxdWV1ZSBvdmVyZmxvd3MKCTAgaWdub3JlZCBSU1RzIGlu IHRoZSB3aW5kb3dzCgkwIGNvbm5lY3Rpb25zIGVzdGFibGlzaGVkIChpbmNsdWRpbmcgYWNj ZXB0cykKCTkgY29ubmVjdGlvbnMgY2xvc2VkIChpbmNsdWRpbmcgMCBkcm9wcykKCQkwIGNv bm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVkIFJUVCBvbiBjbG9zZQoJCTAgY29ubmVjdGlvbnMg dXBkYXRlZCBjYWNoZWQgUlRUIHZhcmlhbmNlIG9uIGNsb3NlCgkJMCBjb25uZWN0aW9ucyB1 cGRhdGVkIGNhY2hlZCBzc3RocmVzaCBvbiBjbG9zZQoJMCBlbWJyeW9uaWMgY29ubmVjdGlv bnMgZHJvcHBlZAoJMCBzZWdtZW50cyB1cGRhdGVkIHJ0dCAob2YgMCBhdHRlbXB0cykKCTAg cmV0cmFuc21pdCB0aW1lb3V0cwoJCTAgY29ubmVjdGlvbnMgZHJvcHBlZCBieSByZXhtaXQg dGltZW91dAoJMCBwZXJzaXN0IHRpbWVvdXRzCgkJMCBjb25uZWN0aW9ucyBkcm9wcGVkIGJ5 IHBlcnNpc3QgdGltZW91dAoJMCBDb25uZWN0aW9ucyAoZmluX3dhaXRfMikgZHJvcHBlZCBi ZWNhdXNlIG9mIHRpbWVvdXQKCTAga2VlcGFsaXZlIHRpbWVvdXRzCgkJMCBrZWVwYWxpdmUg cHJvYmVzIHNlbnQKCQkwIGNvbm5lY3Rpb25zIGRyb3BwZWQgYnkga2VlcGFsaXZlCgkwIGNv cnJlY3QgQUNLIGhlYWRlciBwcmVkaWN0aW9ucwoJMCBjb3JyZWN0IGRhdGEgcGFja2V0IGhl YWRlciBwcmVkaWN0aW9ucwoJMCBzeW5jYWNoZSBlbnRyaWVzIGFkZGVkCgkJMCByZXRyYW5z bWl0dGVkCgkJMCBkdXBzeW4KCQkwIGRyb3BwZWQKCQkwIGNvbXBsZXRlZAoJCTAgYnVja2V0 IG92ZXJmbG93CgkJMCBjYWNoZSBvdmVyZmxvdwoJCTAgcmVzZXQKCQkwIHN0YWxlCgkJMCBh Ym9ydGVkCgkJMCBiYWRhY2sKCQkwIHVucmVhY2gKCQkwIHpvbmUgZmFpbHVyZXMKCTAgY29v a2llcyBzZW50CgkwIGNvb2tpZXMgcmVjZWl2ZWQKCTAgaG9zdGNhY2hlIGVudHJpZXMgYWRk ZWQKCQkwIGJ1Y2tldCBvdmVyZmxvdwoJMCBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkwIHNl Z21lbnQgcmV4bWl0cyBpbiBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkwIGJ5dGUgcmV4bWl0 cyBpbiBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkwIFNBQ0sgb3B0aW9ucyAoU0FDSyBibG9j a3MpIHJlY2VpdmVkCgkwIFNBQ0sgb3B0aW9ucyAoU0FDSyBibG9ja3MpIHNlbnQKCTAgU0FD SyBzY29yZWJvYXJkIG92ZXJmbG93CgkwIHBhY2tldHMgd2l0aCBFQ04gQ0UgYml0IHNldAoJ MCBwYWNrZXRzIHdpdGggRUNOIEVDVCgwKSBiaXQgc2V0CgkwIHBhY2tldHMgd2l0aCBFQ04g RUNUKDEpIGJpdCBzZXQKCTAgc3VjY2Vzc2Z1bCBFQ04gaGFuZHNoYWtlcwoJMCB0aW1lcyBF Q04gcmVkdWNlZCB0aGUgY29uZ2VzdGlvbiB3aW5kb3cKdWRwOgoJNzIgZGF0YWdyYW1zIHJl Y2VpdmVkCgkwIHdpdGggaW5jb21wbGV0ZSBoZWFkZXIKCTAgd2l0aCBiYWQgZGF0YSBsZW5n dGggZmllbGQKCTAgd2l0aCBiYWQgY2hlY2tzdW0KCTAgd2l0aCBubyBjaGVja3N1bQoJMCBk cm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTQxIGJyb2FkY2FzdC9tdWx0aWNhc3QgZGF0YWdy YW1zIHVuZGVsaXZlcmVkCgkwIGRyb3BwZWQgZHVlIHRvIGZ1bGwgc29ja2V0IGJ1ZmZlcnMK CTAgbm90IGZvciBoYXNoZWQgcGNiCgkzMSBkZWxpdmVyZWQKCTMxIGRhdGFncmFtcyBvdXRw dXQKCTAgdGltZXMgbXVsdGljYXN0IHNvdXJjZSBmaWx0ZXIgbWF0Y2hlZAppcDoKCTc2IHRv dGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgYmFkIGhlYWRlciBjaGVja3N1bXMKCTAgd2l0aCBz aXplIHNtYWxsZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5n dGgKCTAgd2l0aCBpcCBsZW5ndGggPiBtYXggaXAgcGFja2V0IHNpemUKCTAgd2l0aCBoZWFk ZXIgbGVuZ3RoIDwgZGF0YSBzaXplCgkwIHdpdGggZGF0YSBsZW5ndGggPCBoZWFkZXIgbGVu Z3RoCgkwIHdpdGggYmFkIG9wdGlvbnMKCTAgd2l0aCBpbmNvcnJlY3QgdmVyc2lvbiBudW1i ZXIKCTAgZnJhZ21lbnRzIHJlY2VpdmVkCgkwIGZyYWdtZW50cyBkcm9wcGVkIChkdXAgb3Ig b3V0IG9mIHNwYWNlKQoJMCBmcmFnbWVudHMgZHJvcHBlZCBhZnRlciB0aW1lb3V0CgkwIHBh Y2tldHMgcmVhc3NlbWJsZWQgb2sKCTcyIHBhY2tldHMgZm9yIHRoaXMgaG9zdAoJMyBwYWNr ZXRzIGZvciB1bmtub3duL3Vuc3VwcG9ydGVkIHByb3RvY29sCgkwIHBhY2tldHMgZm9yd2Fy ZGVkICgwIHBhY2tldHMgZmFzdCBmb3J3YXJkZWQpCgkxIHBhY2tldCBub3QgZm9yd2FyZGFi bGUKCTAgcGFja2V0cyByZWNlaXZlZCBmb3IgdW5rbm93biBtdWx0aWNhc3QgZ3JvdXAKCTAg cmVkaXJlY3RzIHNlbnQKCTMxIHBhY2tldHMgc2VudCBmcm9tIHRoaXMgaG9zdAoJMCBwYWNr ZXRzIHNlbnQgd2l0aCBmYWJyaWNhdGVkIGlwIGhlYWRlcgoJMCBvdXRwdXQgcGFja2V0cyBk cm9wcGVkIGR1ZSB0byBubyBidWZzLCBldGMuCgkwIG91dHB1dCBwYWNrZXRzIGRpc2NhcmRl ZCBkdWUgdG8gbm8gcm91dGUKCTAgb3V0cHV0IGRhdGFncmFtcyBmcmFnbWVudGVkCgkwIGZy YWdtZW50cyBjcmVhdGVkCgkwIGRhdGFncmFtcyB0aGF0IGNhbid0IGJlIGZyYWdtZW50ZWQK CTAgdHVubmVsaW5nIHBhY2tldHMgdGhhdCBjYW4ndCBmaW5kIGdpZgoJMCBkYXRhZ3JhbXMg d2l0aCBiYWQgYWRkcmVzcyBpbiBoZWFkZXIKaWNtcDoKCTAgY2FsbHMgdG8gaWNtcF9lcnJv cgoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBhbiBpY21wIG1lc3Nh Z2UKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMKCTAgbWVzc2FnZXMgbGVzcyB0 aGFuIHRoZSBtaW5pbXVtIGxlbmd0aAoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjaGVja3N1bQoJ MCBtZXNzYWdlcyB3aXRoIGJhZCBsZW5ndGgKCTAgbXVsdGljYXN0IGVjaG8gcmVxdWVzdHMg aWdub3JlZAoJMCBtdWx0aWNhc3QgdGltZXN0YW1wIHJlcXVlc3RzIGlnbm9yZWQKCTAgbWVz c2FnZSByZXNwb25zZXMgZ2VuZXJhdGVkCgkwIGludmFsaWQgcmV0dXJuIGFkZHJlc3NlcwoJ MCBubyByZXR1cm4gcm91dGVzCmlnbXA6CgkzIG1lc3NhZ2VzIHJlY2VpdmVkCgkwIG1lc3Nh Z2VzIHJlY2VpdmVkIHdpdGggdG9vIGZldyBieXRlcwoJMCBtZXNzYWdlcyByZWNlaXZlZCB3 aXRoIHdyb25nIFRUTAoJMCBtZXNzYWdlcyByZWNlaXZlZCB3aXRoIGJhZCBjaGVja3N1bQoJ MCBWMS9WMiBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQKCTEgVjMgbWVtYmVyc2hpcCBx dWVyeSByZWNlaXZlZAoJMCBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQgd2l0aCBpbnZh bGlkIGZpZWxkKHMpCgkxIGdlbmVyYWwgcXVlcnkgcmVjZWl2ZWQKCTAgZ3JvdXAgcXVlcmll cyByZWNlaXZlZAoJMCBncm91cC1zb3VyY2UgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cC1z b3VyY2UgcXVlcmllcyBkcm9wcGVkCgkwIG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZAoJ MCBtZW1iZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlkIGZpZWxkKHMpCgkw IG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZCBmb3IgZ3JvdXBzIHRvIHdoaWNoIHdlIGJl bG9uZwoJMCBWMyByZXBvcnRzIHJlY2VpdmVkIHdpdGhvdXQgUm91dGVyIEFsZXJ0CgkwIG1l bWJlcnNoaXAgcmVwb3J0cyBzZW50CmFycDoKCTIgQVJQIHJlcXVlc3RzIHNlbnQKCTQgQVJQ IHJlcGxpZXMgc2VudAoJNyBBUlAgcmVxdWVzdHMgcmVjZWl2ZWQKCTEgQVJQIHJlcGx5IHJl Y2VpdmVkCgk4IEFSUCBwYWNrZXRzIHJlY2VpdmVkCgkwIHRvdGFsIHBhY2tldHMgZHJvcHBl ZCBkdWUgdG8gbm8gQVJQIGVudHJ5CgkwIEFSUCBlbnRyeXMgdGltZWQgb3V0CgkwIER1cGxp Y2F0ZSBJUHMgc2VlbgppcDY6CgkwIHRvdGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgd2l0aCBz aXplIHNtYWxsZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5n dGgKCTAgd2l0aCBiYWQgb3B0aW9ucwoJMCB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJl cgoJMCBmcmFnbWVudHMgcmVjZWl2ZWQKCTAgZnJhZ21lbnRzIGRyb3BwZWQgKGR1cCBvciBv dXQgb2Ygc3BhY2UpCgkwIGZyYWdtZW50cyBkcm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgZnJh Z21lbnRzIHRoYXQgZXhjZWVkZWQgbGltaXQKCTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJ MCBwYWNrZXRzIGZvciB0aGlzIGhvc3QKCTAgcGFja2V0cyBmb3J3YXJkZWQKCTAgcGFja2V0 cyBub3QgZm9yd2FyZGFibGUKCTAgcmVkaXJlY3RzIHNlbnQKCTAgcGFja2V0cyBzZW50IGZy b20gdGhpcyBob3N0CgkwIHBhY2tldHMgc2VudCB3aXRoIGZhYnJpY2F0ZWQgaXAgaGVhZGVy CgkwIG91dHB1dCBwYWNrZXRzIGRyb3BwZWQgZHVlIHRvIG5vIGJ1ZnMsIGV0Yy4KCTAgb3V0 cHV0IHBhY2tldHMgZGlzY2FyZGVkIGR1ZSB0byBubyByb3V0ZQoJMCBvdXRwdXQgZGF0YWdy YW1zIGZyYWdtZW50ZWQKCTAgZnJhZ21lbnRzIGNyZWF0ZWQKCTAgZGF0YWdyYW1zIHRoYXQg Y2FuJ3QgYmUgZnJhZ21lbnRlZAoJMCBwYWNrZXRzIHRoYXQgdmlvbGF0ZWQgc2NvcGUgcnVs ZXMKCTAgbXVsdGljYXN0IHBhY2tldHMgd2hpY2ggd2UgZG9uJ3Qgam9pbgoJTWJ1ZiBzdGF0 aXN0aWNzOgoJCTAgb25lIG1idWYKCQk2MiBvbmUgZXh0IG1idWYKCQkwIHR3byBvciBtb3Jl IGV4dCBtYnVmCgkwIHBhY2tldHMgd2hvc2UgaGVhZGVycyBhcmUgbm90IGNvbnRpZ3VvdXMK CTAgdHVubmVsaW5nIHBhY2tldHMgdGhhdCBjYW4ndCBmaW5kIGdpZgoJMCBwYWNrZXRzIGRp c2NhcmRlZCBiZWNhdXNlIG9mIHRvbyBtYW55IGhlYWRlcnMKCTAgZmFpbHVyZXMgb2Ygc291 cmNlIGFkZHJlc3Mgc2VsZWN0aW9uCglTb3VyY2UgYWRkcmVzc2VzIHNlbGVjdGlvbiBydWxl IGFwcGxpZWQ6CmljbXA2OgoJMCBjYWxscyB0byBpY21wNl9lcnJvcgoJMCBlcnJvcnMgbm90 IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBhbiBpY21wNiBtZXNzYWdlCgkwIGVycm9ycyBu b3QgZ2VuZXJhdGVkIGJlY2F1c2Ugb2YgcmF0ZSBsaW1pdGF0aW9uCgkwIG1lc3NhZ2VzIHdp dGggYmFkIGNvZGUgZmllbGRzCgkwIG1lc3NhZ2VzIDwgbWluaW11bSBsZW5ndGgKCTAgYmFk IGNoZWNrc3VtcwoJMCBtZXNzYWdlcyB3aXRoIGJhZCBsZW5ndGgKCUhpc3RvZ3JhbSBvZiBl cnJvciBtZXNzYWdlcyB0byBiZSBnZW5lcmF0ZWQ6CgkJMCBubyByb3V0ZQoJCTAgYWRtaW5p c3RyYXRpdmVseSBwcm9oaWJpdGVkCgkJMCBiZXlvbmQgc2NvcGUKCQkwIGFkZHJlc3MgdW5y ZWFjaGFibGUKCQkwIHBvcnQgdW5yZWFjaGFibGUKCQkwIHBhY2tldCB0b28gYmlnCgkJMCB0 aW1lIGV4Y2VlZCB0cmFuc2l0CgkJMCB0aW1lIGV4Y2VlZCByZWFzc2VtYmx5CgkJMCBlcnJv bmVvdXMgaGVhZGVyIGZpZWxkCgkJMCB1bnJlY29nbml6ZWQgbmV4dCBoZWFkZXIKCQkwIHVu cmVjb2duaXplZCBvcHRpb24KCQkwIHJlZGlyZWN0CgkJMCB1bmtub3duCgkwIG1lc3NhZ2Ug cmVzcG9uc2VzIGdlbmVyYXRlZAoJMCBtZXNzYWdlcyB3aXRoIHRvbyBtYW55IE5EIG9wdGlv bnMKCTAgbWVzc2FnZXMgd2l0aCBiYWQgTkQgb3B0aW9ucwoJMCBiYWQgbmVpZ2hib3Igc29s aWNpdGF0aW9uIG1lc3NhZ2VzCgkwIGJhZCBuZWlnaGJvciBhZHZlcnRpc2VtZW50IG1lc3Nh Z2VzCgkwIGJhZCByb3V0ZXIgc29saWNpdGF0aW9uIG1lc3NhZ2VzCgkwIGJhZCByb3V0ZXIg YWR2ZXJ0aXNlbWVudCBtZXNzYWdlcwoJMCBiYWQgcmVkaXJlY3QgbWVzc2FnZXMKCTAgcGF0 aCBNVFUgY2hhbmdlcwpyaXA2OgoJMCBtZXNzYWdlcyByZWNlaXZlZAoJMCBjaGVja3N1bSBj YWxjdWxhdGlvbnMgb24gaW5ib3VuZAoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjaGVja3N1bQoJ MCBtZXNzYWdlcyBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgbXVsdGljYXN0IG1lc3Nh Z2VzIGRyb3BwZWQgZHVlIHRvIG5vIHNvY2tldAoJMCBtZXNzYWdlcyBkcm9wcGVkIGR1ZSB0 byBmdWxsIHNvY2tldCBidWZmZXJzCgkwIGRlbGl2ZXJlZAoJMCBkYXRhZ3JhbXMgb3V0cHV0 CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtbQoKNjUvNjk2Lzc2MSBtYnVmcyBpbiB1 c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwpCjE4NDQ2NzQ0MDczNzA5NTUxNjA1LzQyNy80MTYv MjQyNjgwIG1idWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkK MC80MTYgbWJ1ZitjbHVzdGVycyBvdXQgb2YgcGFja2V0IHNlY29uZGFyeSB6b25lIGluIHVz ZSAoY3VycmVudC9jYWNoZSkKNjQvOS83My8xMjEzMzkgNGsgKHBhZ2Ugc2l6ZSkganVtYm8g Y2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAvMTA3ODU2 IDlrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAv MC8wLzgwODkyIDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90 YWwvbWF4KQoyNTBLLzEwNjRLLzEzMTRLIGJ5dGVzIGFsbG9jYXRlZCB0byBuZXR3b3JrIChj dXJyZW50L2NhY2hlL3RvdGFsKQoyMDkvMC80MDUgcmVxdWVzdHMgZm9yIG1idWZzIGRlbmll ZCAobWJ1ZnMvY2x1c3RlcnMvbWJ1ZitjbHVzdGVycykKMC8wLzAgcmVxdWVzdHMgZm9yIG1i dWZzIGRlbGF5ZWQgKG1idWZzL2NsdXN0ZXJzL21idWYrY2x1c3RlcnMpCjAvMC8wIHJlcXVl c3RzIGZvciBqdW1ibyBjbHVzdGVycyBkZWxheWVkICg0ay85ay8xNmspCjAvMC8wIHJlcXVl c3RzIGZvciBqdW1ibyBjbHVzdGVycyBkZW5pZWQgKDRrLzlrLzE2aykKMCByZXF1ZXN0cyBm b3Igc2ZidWZzIGRlbmllZAowIHJlcXVlc3RzIGZvciBzZmJ1ZnMgZGVsYXllZAowIHJlcXVl c3RzIGZvciBJL08gaW5pdGlhdGVkIGJ5IHNlbmRmaWxlCgotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K bmV0c3RhdCAtaWRXCgpOYW1lICAgICAgTXR1IE5ldHdvcmsgICAgICAgQWRkcmVzcyAgICAg ICAgICAgICAgSXBrdHMgSWVycnMgSWRyb3AgICAgT3BrdHMgT2VycnMgIENvbGwgRHJvcApl bTAqICAgICAxNTAwIDxMaW5rIzE+ICAgICAgZjA6ZGU6ZjE6NDY6MWI6OGMgICAgICAgIDAg ICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKaXduMCogICAgMjI5MCA8 TGluayMyPiAgICAgIDAwOjI0OmQ3OjkxOmI1OjQ0ICAgICAgICAwICAgICAwICAgICAwICAg ICAgIDM4ICAgICAxICAgICAwICAgIDAgCmxvMCAgICAgMTYzODQgPExpbmsjMz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgNiAgICAgMCAgICAgMCAgICAgICAgNiAgICAgMCAg ICAgMCAgICAwIApsbzAgICAgIDE2Mzg0IGxvY2FsaG9zdCAgICAgOjoxICAgICAgICAgICAg ICAgICAgICAgIDAgICAgIC0gICAgIC0gICAgICAgIDAgICAgIC0gICAgIC0gICAgLSAKbG8w ICAgICAxNjM4NCBmZTgwOjoxJWxvMCAgIGZlODA6OjEgICAgICAgICAgICAgICAgICAwICAg ICAtICAgICAtICAgICAgICAwICAgICAtICAgICAtICAgIC0gCmxvMCAgICAgMTYzODQgeW91 ci1uZXQgICAgICBsb2NhbGhvc3QgICAgICAgICAgICAgICAgNiAgICAgLSAgICAgLSAgICAg ICAgNiAgICAgLSAgICAgLSAgICAtIAp3bGFuMCogICAxNTAwIDxMaW5rIzQ+ICAgICAgMDA6 MjQ6ZDc6OTE6YjU6NDQgICAgICAxNDIgICAgIDAgICAgIDAgICAgICAgMzQgICAgIDAgICAg IDAgICAgMCAKd2xhbjAqICAgMTUwMCAxOTIuMTY4LjEzLjAgIG5hY2h0c2NoYXR0ZW4uZnJp ICAgICAgIDI1ICAgICAtICAgICAtICAgICAgIDI1ICAgICAtICAgICAtICAgIC0gCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtYW5yCgpSb3V0aW5nIHRhYmxlcwoKSW50ZXJuZXQ6 CkRlc3RpbmF0aW9uICAgICAgICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAg ICAgIFVzZSAgTmV0aWYgRXhwaXJlCmRlZmF1bHQgICAgICAgICAgICAxOTIuMTY4LjEzLjEg ICAgICAgVUdTICAgICAgICAgMCAgICAgICAxOSAgd2xhbjAKMTI3LjAuMC4xICAgICAgICAg IGxpbmsjMyAgICAgICAgICAgICBVSCAgICAgICAgICAwICAgICAgICA2ICAgIGxvMAoxOTIu MTY4LjEzLjggICAgICAgbGluayM0ICAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAg IDAgICAgbG8wCgpJbnRlcm5ldDY6CkRlc3RpbmF0aW9uICAgICAgICAgICAgICAgICAgICAg ICBHYXRld2F5ICAgICAgICAgICAgICAgICAgICAgICBGbGFncyAgICAgIE5ldGlmIEV4cGly ZQo6Oi85NiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAgICAgICAgICAg ICAgICAgICAgICAgVUdSUyAgICAgICAgbG8wCjo6MSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBsaW5rIzMgICAgICAgICAgICAgICAgICAgICAgICBVSCAgICAgICAgICBsbzAK OjpmZmZmOjAuMC4wLjAvOTYgICAgICAgICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAg ICAgICAgICAgIFVHUlMgICAgICAgIGxvMApmZTgwOjovMTAgICAgICAgICAgICAgICAgICAg ICAgICAgOjoxICAgICAgICAgICAgICAgICAgICAgICAgICAgVUdSUyAgICAgICAgbG8wCmZl ODA6OiVsbzAvNjQgICAgICAgICAgICAgICAgICAgICBsaW5rIzMgICAgICAgICAgICAgICAg ICAgICAgICBVICAgICAgICAgICBsbzAKZmU4MDo6MSVsbzAgICAgICAgICAgICAgICAgICAg ICAgIGxpbmsjMyAgICAgICAgICAgICAgICAgICAgICAgIFVIUyAgICAgICAgIGxvMApmZjAx OjolbG8wLzMyICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAgICAgICAgICAgICAgICAg ICAgICAgVSAgICAgICAgICAgbG8wCmZmMDI6Oi8xNiAgICAgICAgICAgICAgICAgICAgICAg ICA6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICBVR1JTICAgICAgICBsbzAKZmYwMjo6 JWxvMC8zMiAgICAgICAgICAgICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAgICAgICAg ICAgIFUgICAgICAgICAgIGxvMAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0YXQgLWFuQQoK QWN0aXZlIEludGVybmV0IGNvbm5lY3Rpb25zIChpbmNsdWRpbmcgc2VydmVycykKVGNwY2Ig ICAgICAgICAgICBQcm90byBSZWN2LVEgU2VuZC1RIExvY2FsIEFkZHJlc3MgICAgICBGb3Jl aWduIEFkZHJlc3MgICAgKHN0YXRlKQpmZmZmZjgwMDBhMzc4ODAwIHRjcDQgICAgICAgMCAg ICAgIDAgKi42MDAwICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZm ZmY4MDAwYTM3OGMwMCB0Y3A2ICAgICAgIDAgICAgICAwICouNjAwMCAgICAgICAgICAgICAq LiogICAgICAgICAgICAgICAgTElTVEVOCkFjdGl2ZSBVTklYIGRvbWFpbiBzb2NrZXRzCkFk ZHJlc3MgIFR5cGUgICBSZWN2LVEgU2VuZC1RICAgIElub2RlICAgICBDb25uICAgICBSZWZz ICBOZXh0cmVmIEFkZHIKZmZmZmY4MDAwYTI2YTY5MCBzdHJlYW0gICAgICAwICAgICAgMCAg ICAgICAgMCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMApmZmZmZjgwMDBhMjQ4NWEwIHN0 cmVhbSAgICAgIDAgICAgICAwIGZmZmZmODAwMGEzZWY3NjAgICAgICAgIDAgICAgICAgIDAg ICAgICAgIDAgL3RtcC8uWDExLXVuaXgvWDAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0 IC1hTAoKQ3VycmVudCBsaXN0ZW4gcXVldWUgc2l6ZXMgKHFsZW4vaW5jcWxlbi9tYXhxbGVu KQpQcm90byBMaXN0ZW4gICAgICAgICBMb2NhbCBBZGRyZXNzICAgICAgICAgCnRjcDQgIDAv MC8xMjggICAgICAgICoueDExICAgICAgICAgICAgICAgICAgCnRjcDYgIDAvMC8xMjggICAg ICAgICoueDExICAgICAgICAgICAgICAgICAgCnVuaXggIDAvMC8xMjggICAgICAgIC90bXAv LlgxMS11bml4L1gwCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZnN0YXQKCmZzdGF0OiBjYW4ndCBy ZWFkIGZpbGUgMSBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxl IDIgYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA0IGF0IDB4 NzgwMDAwZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDcgYXQgMHgyMDAwMDdmZmZmZmZm ZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA4IGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0 OiBjYW4ndCByZWFkIGZpbGUgMTAgYXQgMHg3ODAwMDBmZmZmCmZzdGF0OiBjYW4ndCByZWFk IGZpbGUgMSBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIg YXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxIGF0IDB4MjAw MDA3ZmZmZmZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMiBhdCAweDQwMDAwMDAwMDFm ZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDQgYXQgMHg3ODAwMDBmZmZmCmZzdGF0OiBj YW4ndCByZWFkIGZpbGUgNyBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVh ZCBmaWxlIDggYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAx MCBhdCAweDc4MDAwMGZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxIGF0IDB4MjAwMDA3 ZmZmZmZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMiBhdCAweDQwMDAwMDAwMDFmZmZm Zgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDQgYXQgMHg3ODAwMDBmZmZmCmZzdGF0OiBjYW4n dCByZWFkIGZpbGUgNyBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBm aWxlIDggYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxMCBh dCAweDc4MDAwMGZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxMyBhdCAweDIwMDAwN2Zm ZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDE0IGF0IDB4NDAwMDAwMDAwMWZmZmZm CmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMTYgYXQgMHg3ODAwMDBmZmZmClVTRVIgICAgIENN RCAgICAgICAgICBQSUQgICBGRCBNT1VOVCAgICAgIElOVU0gTU9ERSAgICAgICAgIFNafERW IFIvVwpyb290ICAgICBYb3JnICAgICAgICAxNDA5IHJvb3QgLyAgICAgICAgICAgICAyIGRy d3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBYb3JnICAgICAgICAxNDA5ICAgd2QgL2hv bWUgICAgNDczNTEwNCBkcnd4ci14ci14ICAgIDE1MzYgIHIKcm9vdCAgICAgWG9yZyAgICAg ICAgMTQwOSB0ZXh0IC8gICAgICAgIDI4MTU3MTggLXItc3IteHIteCAgMTgzMTk2MCAgcgpy b290ICAgICBYb3JnICAgICAgICAxNDA5ICAgIDAgLyAgICAgICAgMzYxMTk4NiAtcnctci0t ci0tICAgMTMzMTIgIHcKcm9vdCAgICAgWG9yZyAgICAgICAgMTQwOSAgICA2KiBpbnRlcm5l dDYgc3RyZWFtIHRjcCBmZmZmZjgwMDBhMzc4YzAwCmZsbyAgICAgIHhpbml0ICAgICAgIDE0 MDggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCmZsbyAgICAg IHhpbml0ICAgICAgIDE0MDggICB3ZCAvaG9tZSAgICA0NzM1MTA0IGRyd3hyLXhyLXggICAg MTUzNiAgcgpmbG8gICAgICB4aW5pdCAgICAgICAxNDA4IHRleHQgLyAgICAgICAgMjgxNjM5 NSAtci14ci14ci14ICAgMTU1NDQgIHIKZmxvICAgICAgeGluaXQgICAgICAgMTQwOCAgICAw IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0KZmxvICAgICAgc2ggICAgICAgICAgMTM5 NSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKZmxvICAgICAg c2ggICAgICAgICAgMTM5NSAgIHdkIC9ob21lICAgIDQ3MzUxMDQgZHJ3eHIteHIteCAgICAx NTM2ICByCmZsbyAgICAgIHNoICAgICAgICAgIDEzOTUgdGV4dCAvICAgICAgICAxMjE5ODkx NSAtci14ci14ci14ICAxNDE2OTYgIHIKZmxvICAgICAgc2ggICAgICAgICAgMTM5NSAgICAw IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0KZmxvICAgICAgc2ggICAgICAgICAgMTM5 NSAgICA2IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0KZmxvICAgICAgbWtzaCAgICAg ICAgMTM5MiByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKZmxv ICAgICAgbWtzaCAgICAgICAgMTM5MiAgIHdkIC9ob21lICAgIDQ3MzUxMDQgZHJ3eHIteHIt eCAgICAxNTM2ICByCmZsbyAgICAgIG1rc2ggICAgICAgIDEzOTIgdGV4dCAvICAgICAgICAy ODE2NDEzIC1yLXhyLXhyLXggIDI3NDU5MiAgcgpmbG8gICAgICBta3NoICAgICAgICAxMzky ICAgIDAgLSAgICAgICAgIC0gICAgICAgICBiYWQgICAgLQpmbG8gICAgICBta3NoICAgICAg ICAxMzkyICAgIDYgLSAgICAgICAgIC0gICAgICAgICBiYWQgICAgLQpmbG8gICAgICBta3No ICAgICAgICAxMzkyICAgMTIgLSAgICAgICAgIC0gICAgICAgICBiYWQgICAgLQpyb290ICAg ICBuZ19xdWV1ZSAgICAgODcyIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg MTAyNCAgcgpyb290ICAgICBuZ19xdWV1ZSAgICAgODcyICAgd2QgLyAgICAgICAgICAgICAy IGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBpbml0ICAgICAgICAgICAxIHJvb3Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBpbml0ICAg ICAgICAgICAxICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpy b290ICAgICBpbml0ICAgICAgICAgICAxIHRleHQgLyAgICAgICAgMTA1OTM3OTQgLXIteHIt eHIteCAgOTM5MzIwICByCnJvb3QgICAgIGtlcm5lbCAgICAgICAgIDAgcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGtlcm5lbCAgICAgICAg IDAgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCgotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KZG1lc2cKCm91cD4gYXQgbmlkIDEgb24gaGRhY2MxCnBjbTE6IDxOVklE SUEgR1QyMXggKEhETUkvRFAgOGNoKT4gYXQgbmlkIDUgb24gaGRhYTEKaGRhY2MyOiA8TlZJ RElBIEdUMjF4IEhEQSBDT0RFQz4gYXQgY2FkIDIgb24gaGRhYzAKaGRhYTI6IDxOVklESUEg R1QyMXggQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMgpwY20yOiA8 TlZJRElBIEdUMjF4IChIRE1JL0RQIDhjaCk+IGF0IG5pZCA1IG9uIGhkYWEyCmhkYWNjMzog PE5WSURJQSBHVDIxeCBIREEgQ09ERUM+IGF0IGNhZCAzIG9uIGhkYWMwCmhkYWEzOiA8TlZJ RElBIEdUMjF4IEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzMKcGNt MzogPE5WSURJQSBHVDIxeCAoSERNSS9EUCA4Y2gpPiBhdCBuaWQgNSBvbiBoZGFhMwpoZGFj YzQ6IDxDb25leGFudCBDWDIwNTg1IEhEQSBDT0RFQz4gYXQgY2FkIDAgb24gaGRhYzEKaGRh YTQ6IDxDb25leGFudCBDWDIwNTg1IEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBv biBoZGFjYzQKcGNtNDogPENvbmV4YW50IENYMjA1ODUgKFJpZ2h0IEFuYWxvZyk+IGF0IG5p ZCAyNSBhbmQgMjcgb24gaGRhYTQKcGNtNTogPENvbmV4YW50IENYMjA1ODUgKEludGVybmFs IEFuYWxvZyk+IGF0IG5pZCAzMSBhbmQgMzUgb24gaGRhYTQKcmFuZG9tOiB1bmJsb2NraW5n IGRldmljZS4KdXNidXMwOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdXNidXMxOiA0 ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEK dWh1YjA6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMxCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIxOiA8 SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzMApzZXMwIGF0IGFoY2llbTAgYnVzIDAgc2NidXM0IHRhcmdldCAwIGx1biAw CnNlczA6IDxBSENJIFNHUElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4w MCBkZXZpY2UKc2VzMDogU0VNQiBTRVMgRGV2aWNlCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBz Y2J1czAgdGFyZ2V0IDAgbHVuIDAKYWRhMDogPFdEQyBXRDMyMDBCRVZULTA4QTIzVDEgMDIu MDFBMDI+IEFUQS04IFNBVEEgMi54IGRldmljZQphZGEwOiBTZXJpYWwgTnVtYmVyIFdELVdY RDFBMTE1NDI3NQphZGEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDgxOTJieXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6 IDMwNTI0NU1CICg2MjUxNDI0NDggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2Mzgz QykKYWRhMDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0CmNkMCBhdCBhaGNpY2gxIGJ1 cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMApjZDA6IDxPcHRpYXJjIERWRCBSVyBBRC03OTMw SCAxLkQxPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCmNkMDogMTUwLjAwME1C L3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURNQTUsIEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTky Ynl0ZXMpCmNkMDogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBS RUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50IC0gdHJheSBjbG9zZWQKTmV0dnNjIGluaXRpYWxp emluZy4uLiBTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIgTGF1bmNo ZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpUaW1lY291bnRlciAiVFNDLWxvdyIgZnJl cXVlbmN5IDEzMzAwMzU1MjQgSHogcXVhbGl0eSAxMDAwClJvb3QgbW91bnQgd2FpdGluZyBm b3I6IHVzYnVzMSB1c2J1czAKdWh1YjE6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1vdmFibGUsIHNlbGYgcG93ZXJl ZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVnZW4xLjI6IDx2ZW5k b3IgMHg4MDg3PiBhdCB1c2J1czEKdWh1YjI6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgw MDIwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMxCnVnZW4w LjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czAKdWh1YjM6IDx2ZW5kb3IgMHg4MDg3IHBy b2R1Y3QgMHgwMDIwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNi dXMwClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMSB1c2J1czAKdWh1YjM6IDYgcG9y dHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBm b3I6IHVzYnVzMSB1c2J1czAKdWh1YjI6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVnZW4wLjM6IDxCcm9hZGNvbSBDb3JwPiBhdCB1c2J1czAKUm9vdCBtb3Vu dCB3YWl0aW5nIGZvcjogdXNidXMwCnVnZW4wLjQ6IDxDaGljb255IEVsZWN0cm9uaWNzIENv LiwgTHRkLj4gYXQgdXNidXMwClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYv YWRhMHAzIFtyd10uLi4KU2V0dGluZyBob3N0dXVpZDogODE5MDU0MGQtMTU1MS1jYjExLWEz NGYtZGUyYjYzMjNhMzFmLgpTZXR0aW5nIGhvc3RpZDogMHhkNzZiOGE3Yi4KdWdlbjAuMzog PEJyb2FkY29tIENvcnA+IGF0IHVzYnVzMCAoZGlzY29ubmVjdGVkKQpFbnRyb3B5IGhhcnZl c3Rpbmc6IGludGVycnVwdHMgZXRoZXJuZXQgcG9pbnRfdG9fcG9pbnQgc3dpLgpTdGFydGlu ZyBmaWxlIHN5c3RlbSBjaGVja3M6Ci9kZXYvYWRhMHAzOiBGSUxFIFNZU1RFTSBDTEVBTjsg U0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWRhMHAzOiBjbGVhbiwgMTYzNjM3MjIgZnJlZSAoNjQ5 OTQgZnJhZ3MsIDIwMzczNDEgYmxvY2tzLCAwLjMlIGZyYWdtZW50YXRpb24pCi9kZXYvYWRh MHA0OiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWRhMHA0OiBj bGVhbiwgMzI2Mjg5NzIgZnJlZSAoMjY2NjggZnJhZ3MsIDQwNzUyODggYmxvY2tzLCAwLjEl IGZyYWdtZW50YXRpb24pCk1vdW50aW5nIGxvY2FsIGZpbGUgc3lzdGVtczouCldyaXRpbmcg ZW50cm9weSBmaWxlOi4KU2V0dGluZyBob3N0bmFtZTogbmFjaHRzY2hhdHRlbi5vcmtsYW4u ZGUuClN0YXJ0aW5nIE5ldHdvcms6IGxvMCBlbTAuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09Q QkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0CglvcHRpb25zPTYw MDAwMzxSWENTVU0sVFhDU1VNLFJYQ1NVTV9JUFY2LFRYQ1NVTV9JUFY2PgoJaW5ldDYgOjox IHByZWZpeGxlbiAxMjggCglpbmV0NiBmZTgwOjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVp ZCAweDMgCglpbmV0IDEyNy4wLjAuMSBuZXRtYXNrIDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9u cz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgplbTA6IGZsYWdzPTg4NDM8VVAsQlJP QURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglv cHRpb25zPTQyMTliPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxB Tl9IV0NTVU0sVFNPNCxXT0xfTUFHSUMsVkxBTl9IV1RTTz4KCWV0aGVyIGYwOmRlOmYxOjQ2 OjFiOjhjCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5L TE9DQUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAwYmFzZVRYIDxmdWxsLWR1 cGxleD4pCglzdGF0dXM6IGFjdGl2ZQpTdGFydGluZyBkZXZkLgprbGRsb2FkOiBjYW4ndCBs b2FkIG5nX3VidDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQprbGRsb2FkOiBjYW4ndCBs b2FkIG5nX3VidDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpTdGFydGluZyBkaGNsaWVu dC4KREhDUFJFUVVFU1Qgb24gZW0wIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CkRIQ1BB Q0sgZnJvbSAxOTIuMTY4LjEzLjEKYm91bmQgdG8gMTkyLjE2OC4xMy4yIC0tIHJlbmV3YWwg aW4gNjA0ODAwIHNlY29uZHMuCmFkZCBuZXQgZmU4MDo6OiBnYXRld2F5IDo6MQphZGQgbmV0 IGZmMDI6OjogZ2F0ZXdheSA6OjEKYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDogZ2F0ZXdheSA6 OjEKYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxCkVMRiBsZGNvbmZpZyBwYXRoOiAv bGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAvdXNyL2xvY2FsL2xpYiAvdXNyL2xvY2Fs L2xpYi9nY2M0OCAvdXNyL2xvY2FsL2xpYi9ncmFwaHZpeiAvdXNyL2xvY2FsL2xpYi9uc3Mg L3Vzci9sb2NhbC9saWIvb3BlbmNvbGxhZGEgL3Vzci9sb2NhbC9saWIvcHRoIC91c3IvbG9j YWwvbGliL3F0NCAvdXNyL2xvY2FsL2xpYi9xdGNyZWF0b3IgL3Vzci9sb2NhbC9sbHZtMzMv bGliIC91c3IvbG9jYWwvbGx2bTM0L2xpYiAvdXNyL2xvY2FsL2xsdm0zNS9saWIKMzItYml0 IGNvbXBhdGliaWxpdHkgbGRjb25maWcgcGF0aDogL3Vzci9saWIzMgpDcmVhdGluZyBhbmQv b3IgdHJpbW1pbmcgbG9nIGZpbGVzLgpTdGFydGluZyBzeXNsb2dkLgpObyBjb3JlIGR1bXBz IGZvdW5kLgpDbGVhcmluZyAvdG1wIChYIHJlbGF0ZWQpLgpSZWNvdmVyaW5nIHZpIGVkaXRv ciBzZXNzaW9uczouClN0YXJ0aW5nIGRidXMuClN0YXJ0aW5nIGxvb2xlcmQuClVwZGF0aW5n IG1vdGQ6LgpNb3VudGluZyBsYXRlIGZpbGUgc3lzdGVtczouClN0YXJ0aW5nIG50cGQuClN0 YXJ0aW5nIHBvd2VyZC4KQ29uZmlndXJpbmcgc3lzY29uczogYmxhbmt0aW1lLgpQZXJmb3Jt aW5nIHNhbml0eSBjaGVjayBvbiBzc2hkIGNvbmZpZ3VyYXRpb24uClN0YXJ0aW5nIHNzaGQu ClN0YXJ0aW5nIHNlbmRtYWlsX3N1Ym1pdC4KU3RhcnRpbmcgc2VuZG1haWxfbXNwX3F1ZXVl LgpTdGFydGluZyBjcm9uLgpzeXNjdGw6IHVua25vd24gb2lkICdjb21wYXQubGludXgub3Ny ZWxlYXNlJyBhdCBsaW5lIDIxOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5ClN0YXJ0aW5n IGRlZmF1bHQgbW91c2VkLgpTdGFydGluZyBiYWNrZ3JvdW5kIGZpbGUgc3lzdGVtIGNoZWNr cyBpbiA2MCBzZWNvbmRzLgoKVHVlIE5vdiAxMSAyMjo0NjowMSBDRVQgMjAxNApOb3YgMTEg MjI6NDg6NDkgbmFjaHRzY2hhdHRlbiBsb2dpbjogUk9PVCBMT0dJTiAocm9vdCkgT04gdHR5 djEKTm92IDExIDIyOjUyOjQ5IG5hY2h0c2NoYXR0ZW4gcmVib290OiByZWJvb3RlZCBieSBy b290Ck5vdiAxMSAyMjo1Mjo0OSBuYWNodHNjaGF0dGVuIHN5c2xvZ2Q6IGV4aXRpbmcgb24g c2lnbmFsIDE1CldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3Mg YHZubHJ1JyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5 c3RlbSBwcm9jZXNzIGBidWZkYWVtb24nIHRvIHN0b3AuLi5kb25lCgpXYWl0aW5nIChtYXgg NjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi5TeW5j aW5nIGRpc2tzLCB2bm9kZXMgcmVtYWluaW5nLi4uNCAyIDIgMSAxIDEgMCAwIGRvbmUKQWxs IGJ1ZmZlcnMgc3luY2VkLgpVcHRpbWU6IDdtMTdzCnVzYnVzMDogQ29udHJvbGxlciBzaHV0 ZG93bgp1aHViMTogYXQgdXNidXMwLCBwb3J0IDEsIGFkZHIgMSAoZGlzY29ubmVjdGVkKQp1 Z2VuMC4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMwIChkaXNjb25uZWN0ZWQpCnVodWIz OiBhdCB1aHViMSwgcG9ydCAxLCBhZGRyIDIgKGRpc2Nvbm5lY3RlZCkKdWdlbjAuNDogPENo aWNvbnkgRWxlY3Ryb25pY3MgQ28uLCBMdGQuPiBhdCB1c2J1czAgKGRpc2Nvbm5lY3RlZCkK dXNidXMwOiBDb250cm9sbGVyIHNodXRkb3duIGNvbXBsZXRlCnVzYnVzMTogQ29udHJvbGxl ciBzaHV0ZG93bgp1aHViMDogYXQgdXNidXMxLCBwb3J0IDEsIGFkZHIgMSAoZGlzY29ubmVj dGVkKQp1Z2VuMS4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMxIChkaXNjb25uZWN0ZWQp CnVodWIyOiBhdCB1aHViMCwgcG9ydCAxLCBhZGRyIDIgKGRpc2Nvbm5lY3RlZCkKdXNidXMx OiBDb250cm9sbGVyIHNodXRkb3duIGNvbXBsZXRlClJlYm9vdGluZy4uLgpjcHVfcmVzZXQ6 IFN0b3BwaW5nIG90aGVyIENQVXMKQ29weXJpZ2h0IChjKSAxOTkyLTIwMTQgVGhlIEZyZWVC U0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4 LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5p dmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlz IGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJl ZUJTRCAxMC4wLVJFTEVBU0UtcDEyICMwOiBUdWUgTm92ICA0IDA1OjA3OjE3IFVUQyAyMDE0 CiAgICByb290QGFtZDY0LWJ1aWxkZXIuZGFlbW9ub2xvZ3kubmV0Oi91c3Ivb2JqL3Vzci9z cmMvc3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDMuMyAodGFncy9S RUxFQVNFXzMzL2ZpbmFsIDE4MzUwMikgMjAxMzA2MTAKQ1BVOiBJbnRlbChSKSBDb3JlKFRN KSBpNSBDUFUgICAgICAgTSA1NjAgIEAgMi42N0dIeiAoMjY2MC4wNy1NSHogSzgtY2xhc3Mg Q1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MjA2NTUgIEZhbWlseSA9 IDB4NiAgTW9kZWwgPSAweDI1ICBTdGVwcGluZyA9IDUKICBGZWF0dXJlcz0weGJmZWJmYmZm PEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIs U1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHgyOWFlM2ZmPFNTRTMsUENMTVVMUURRLERU RVM2NCxNT04sRFNfQ1BMLFZNWCxTTVgsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxQ Q0lELFNTRTQuMSxTU0U0LjIsUE9QQ05ULEFFU05JPgogIEFNRCBGZWF0dXJlcz0weDI4MTAw ODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAg VFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ugc3RhdGlzdGljcwpyZWFsIG1l bW9yeSAgPSA0Mjk0OTY3Mjk2ICg0MDk2IE1CKQphdmFpbCBtZW1vcnkgPSAzOTYyODM0OTQ0 ICgzNzc5IE1CKQpBQ1BJIEFQSUMgVGFibGU6IDxMRU5PVk8gVFAtNkkgICA+CkZyZWVCU0Qv U01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpGcmVlQlNEL1NN UDogMSBwYWNrYWdlKHMpIHggMiBjb3JlKHMpIHggMiBTTVQgdGhyZWFkcwogY3B1MCAoQlNQ KTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJ QyBJRDogIDQKIGNwdTMgKEFQKTogQVBJQyBJRDogIDUKaW9hcGljMDogQ2hhbmdpbmcgQVBJ QyBJRCB0byAxCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9h cmQKa2JkMSBhdCBrYmRtdXgwCnJhbmRvbTogPFNvZnR3YXJlLCBZYXJyb3c+IGluaXRpYWxp emVkCmFjcGkwOiA8TEVOT1ZPIFRQLTZJPiBvbiBtb3RoZXJib2FyZAphY3BpX2VjMDogPEVt YmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDExLCBFQ0RUPiBwb3J0IDB4NjIsMHg2NiBvbiBh Y3BpMAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHJlc2VydmF0aW9uIG9m IDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgYmZm MDAwMDAgKDMpIGZhaWxlZApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJ IENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8QUNQSSBD UFU+IG9uIGFjcGkwCmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0weDQzIGlycSAw IG9uIGFjcGkwClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAwCkV2ZW50IHRpbWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0 eSAxMDAKaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQw MDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA5NTAKRXZlbnQgdGltZXIgIkhQRVQiIGZyZXF1ZW5jeSAx NDMxODE4MCBIeiBxdWFsaXR5IDU1MApFdmVudCB0aW1lciAiSFBFVDEiIGZyZXF1ZW5jeSAx NDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDIiIGZyZXF1ZW5jeSAx NDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDMiIGZyZXF1ZW5jeSAx NDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDQiIGZyZXF1ZW5jeSAx NDMxODE4MCBIeiBxdWFsaXR5IDQ0MAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9y dCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5 IDMyNzY4IEh6IHF1YWxpdHkgMApUaW1lY291bnRlciAiQUNQSS1zYWZlIiBmcmVxdWVuY3kg MzU3OTU0NSBIeiBxdWFsaXR5IDg1MAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAz LjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwCmFjcGlfbGlkMDogPENv bnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVw IEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNw aTAKcGNpMjU1OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2liMTogPEFDUEkgSG9zdC1Q Q0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIxCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRl dmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgp2Z2FwY2kw OiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDIwMDAtMHgyMDdmIG1lbSAweGNj MDAwMDAwLTB4Y2NmZmZmZmYsMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4Y2UwMDAwMDAtMHhj ZmZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCnZnYXBjaTA6IEJvb3Qgdmlk ZW8gZGV2aWNlCmhkYWMwOiA8TlZJRElBICgweDBiZTMpIEhEQSBDb250cm9sbGVyPiBtZW0g MHhjZGVmYzAwMC0weGNkZWZmZmZmIGF0IGRldmljZSAwLjEgb24gcGNpMQpwY2kwOiA8c2lt cGxlIGNvbW1zPiBhdCBkZXZpY2UgMjIuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQp1YXJ0Mjog PDUgU2VyaWVzLzM0MDAgU2VyaWVzIENoaXBzZXQgS1QgQ29udHJvbGxlcj4gcG9ydCAweDE4 MDAtMHgxODA3IG1lbSAweGYyNDI0MDAwLTB4ZjI0MjRmZmYgaXJxIDE3IGF0IGRldmljZSAy Mi4zIG9uIHBjaTAKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9u IDcuMy44PiBwb3J0IDB4MTgyMC0weDE4M2YgbWVtIDB4ZjI0MDAwMDAtMHhmMjQxZmZmZiww eGYyNDI1MDAwLTB4ZjI0MjVmZmYgaXJxIDIwIGF0IGRldmljZSAyNS4wIG9uIHBjaTAKZW0w OiBVc2luZyBhbiBNU0kgaW50ZXJydXB0CmVtMDogRXRoZXJuZXQgYWRkcmVzczogZjA6ZGU6 ZjE6NDY6MWI6OGMKZWhjaTA6IDxJbnRlbCBQQ0ggVVNCIDIuMCBjb250cm9sbGVyIFVTQi1C PiBtZW0gMHhmMjQyODAwMC0weGYyNDI4M2ZmIGlycSAyMyBhdCBkZXZpY2UgMjYuMCBvbiBw Y2kwCnVzYnVzMDogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czAgb24gZWhjaTAKaGRhYzE6IDxJ bnRlbCA1IFNlcmllcy8zNDAwIFNlcmllcyBIREEgQ29udHJvbGxlcj4gbWVtIDB4ZjI0MjAw MDAtMHhmMjQyM2ZmZiBpcnEgMTcgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApwY2liMzogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGlycSAyMCBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDIxIGF0IGRldmljZSAyOC4xIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjQKaXduMDogPEludGVsIENlbnRyaW5vIFVsdGltYXRlLU4gNjMwMD4gbWVtIDB4ZjIw MDAwMDAtMHhmMjAwMWZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kzCnBjaWI1OiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDIwIGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNp MTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CnNkaGNpX3BjaTA6IDxSSUNPSCBTRD4gbWVt IDB4ZjIxMDAwMDAtMHhmMjEwMDBmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxMwpz ZGhjaV9wY2kwOiAxIHNsb3QocykgYWxsb2NhdGVkCnBjaTEzOiA8YmFzZSBwZXJpcGhlcmFs PiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCmVoY2kxOiA8SW50ZWwgUENI IFVTQiAyLjAgY29udHJvbGxlciBVU0ItQT4gbWVtIDB4ZjI0Mjg0MDAtMHhmMjQyODdmZiBp cnEgMTkgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAK dXNidXMxIG9uIGVoY2kxCnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDMwLjAgb24gcGNpMApwY2kxNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjYKaXNhYjA6IDxQ Q0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4g b24gaXNhYjAKYWhjaTA6IDxJbnRlbCA1IFNlcmllcy8zNDAwIFNlcmllcyBBSENJIFNBVEEg Y29udHJvbGxlcj4gcG9ydCAweDE4MTgtMHgxODFmLDB4MTgwYy0weDE4MGYsMHgxODEwLTB4 MTgxNywweDE4MDgtMHgxODBiLDB4MTg0MC0weDE4NWYgbWVtIDB4ZjI0MjcwMDAtMHhmMjQy NzdmZiBpcnEgMTYgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphaGNpMDogQUhDSSB2MS4zMCB3 aXRoIDYgM0dicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2lj aDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAphaGNpY2gxOiA8QUhD SSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTAKYWhjaWNoNDogPEFIQ0kgY2hhbm5l bD4gYXQgY2hhbm5lbCA0IG9uIGFoY2kwCmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNo YW5uZWwgNSBvbiBhaGNpMAphaGNpZW0wOiA8QUhDSSBlbmNsb3N1cmUgbWFuYWdlbWVudCBi cmlkZ2U+IG9uIGFoY2kwCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMx LjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGRhc3A+IGF0IGRldmljZSAzMS42IChu byBkcml2ZXIgYXR0YWNoZWQpCmFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAph dGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBp cnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMApr YmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IDxQUy8yIE1vdXNl PiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBtb2RlbCBH ZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9s IE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24g YWNwaTAKYWNwaV9pYm0wOiA8SUJNIFRoaW5rUGFkIEFDUEkgRXh0cmFzPiBvbiBhY3BpMApv cm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGQwMDAwLTB4ZDBmZmYsMHhkMTAw MC0weGQxZmZmLDB4ZGQwMDAtMHhkZmZmZiwweGUwMDAwLTB4ZWZmZmYgb24gaXNhMApzYzA6 IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYg dmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+ IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKcHBj MDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKZXN0MDogPEVuaGFuY2VkIFNwZWVk U3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MAplc3QxOiA8RW5oYW5jZWQgU3BlZWRT dGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0 ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTIKZXN0MzogPEVuaGFuY2VkIFNwZWVkU3Rl cCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MwpUaW1lY291bnRlcnMgdGljayBldmVyeSAx MC4wMDAgbXNlYwpoZGFjYzA6IDxOVklESUEgR1QyMXggSERBIENPREVDPiBhdCBjYWQgMCBv biBoZGFjMApoZGFhMDogPE5WSURJQSBHVDIxeCBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQg bmlkIDEgb24gaGRhY2MwCnBjbTA6IDxOVklESUEgR1QyMXggKEhETUkvRFAgOGNoKT4gYXQg bmlkIDUgb24gaGRhYTAKaGRhY2MxOiA8TlZJRElBIEdUMjF4IEhEQSBDT0RFQz4gYXQgY2Fk IDEgb24gaGRhYzAKaGRhYTE6IDxOVklESUEgR1QyMXggQXVkaW8gRnVuY3Rpb24gR3JvdXA+ IGF0IG5pZCAxIG9uIGhkYWNjMQpwY20xOiA8TlZJRElBIEdUMjF4IChIRE1JL0RQIDhjaCk+ IGF0IG5pZCA1IG9uIGhkYWExCmhkYWNjMjogPE5WSURJQSBHVDIxeCBIREEgQ09ERUM+IGF0 IGNhZCAyIG9uIGhkYWMwCmhkYWEyOiA8TlZJRElBIEdUMjF4IEF1ZGlvIEZ1bmN0aW9uIEdy b3VwPiBhdCBuaWQgMSBvbiBoZGFjYzIKcGNtMjogPE5WSURJQSBHVDIxeCAoSERNSS9EUCA4 Y2gpPiBhdCBuaWQgNSBvbiBoZGFhMgpoZGFjYzM6IDxOVklESUEgR1QyMXggSERBIENPREVD PiBhdCBjYWQgMyBvbiBoZGFjMApoZGFhMzogPE5WSURJQSBHVDIxeCBBdWRpbyBGdW5jdGlv biBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2MzCnBjbTM6IDxOVklESUEgR1QyMXggKEhETUkv RFAgOGNoKT4gYXQgbmlkIDUgb24gaGRhYTMKaGRhY2M0OiA8Q29uZXhhbnQgQ1gyMDU4NSBI REEgQ09ERUM+IGF0IGNhZCAwIG9uIGhkYWMxCmhkYWE0OiA8Q29uZXhhbnQgQ1gyMDU4NSBB dWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2M0CnBjbTQ6IDxDb25leGFu dCBDWDIwNTg1IChSaWdodCBBbmFsb2cpPiBhdCBuaWQgMjUgYW5kIDI3IG9uIGhkYWE0CnBj bTU6IDxDb25leGFudCBDWDIwNTg1IChJbnRlcm5hbCBBbmFsb2cpPiBhdCBuaWQgMzEgYW5k IDM1IG9uIGhkYWE0CnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuCnVzYnVzMDogNDgwTWJw cyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzMTogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2 Mi4wCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIwOiA8SW50ZWwgRUhDSSByb290 IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2Vu MS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHViMTogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKc2VzMCBhdCBhaGNp ZW0wIGJ1cyAwIHNjYnVzNCB0YXJnZXQgMCBsdW4gMApzZXMwOiA8QUhDSSBTR1BJTyBFbmNs b3N1cmUgMS4wMCAwMDAxPiBTRU1CIFMtRS1TIDIuMDAgZGV2aWNlCnNlczA6IFNFTUIgU0VT IERldmljZQphZGEwIGF0IGFoY2ljaDAgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmFk YTA6IDxXREMgV0QzMjAwQkVWVC0wOEEyM1QxIDAyLjAxQTAyPiBBVEEtOCBTQVRBIDIueCBk ZXZpY2UKYWRhMDogU2VyaWFsIE51bWJlciBXRC1XWEQxQTExNTQyNzUKYWRhMDogMzAwLjAw ME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6 IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiAzMDUyNDVNQiAoNjI1MTQyNDQ4IDUx MiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTA6IFByZXZpb3VzbHkgd2Fz IGtub3duIGFzIGFkNApjZDAgYXQgYWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVu IDAKY2QwOiA8T3B0aWFyYyBEVkQgUlcgQUQtNzkzMEggMS5EMT4gUmVtb3ZhYmxlIENELVJP TSBTQ1NJLTAgZGV2aWNlIApjZDA6IDE1MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAxLngs IFVETUE1LCBBVEFQSSAxMmJ5dGVzLCBQSU8gODE5MmJ5dGVzKQpjZDA6IEF0dGVtcHQgdG8g cXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2Vu dCAtIHRyYXkgY2xvc2VkCk5ldHZzYyBpbml0aWFsaXppbmcuLi4gU01QOiBBUCBDUFUgIzEg TGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMiBMYXVu Y2hlZCEKVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAxMzMwMDM1ODc1IEh6IHF1 YWxpdHkgMTAwMApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEgdXNidXMwClJvb3Qg bW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMSB1c2J1czAKdWh1YjA6IDMgcG9ydHMgd2l0aCAz IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAzIHBvcnRzIHdpdGggMyByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEgdXNidXMw CnVnZW4xLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czEKdWh1YjI6IDx2ZW5kb3IgMHg4 MDg3IHByb2R1Y3QgMHgwMDIwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4g b24gdXNidXMxCnVnZW4wLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czAKdWh1YjM6IDx2 ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgwMDIwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAs IGFkZHIgMj4gb24gdXNidXMwCnVodWIzOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNl bGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVodWIy OiA4IHBvcnRzIHdpdGggOCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuMC4zOiA8QnJv YWRjb20gQ29ycD4gYXQgdXNidXMwClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMAp1 Z2VuMC40OiA8Q2hpY29ueSBFbGVjdHJvbmljcyBDby4sIEx0ZC4+IGF0IHVzYnVzMApUcnlp bmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkYTBwMyBbcnddLi4uCnVnZW4wLjM6 IDxCcm9hZGNvbSBDb3JwPiBhdCB1c2J1czAgKGRpc2Nvbm5lY3RlZCkKU2V0dGluZyBob3N0 dXVpZDogODE5MDU0MGQtMTU1MS1jYjExLWEzNGYtZGUyYjYzMjNhMzFmLgpTZXR0aW5nIGhv c3RpZDogMHhkNzZiOGE3Yi4KRW50cm9weSBoYXJ2ZXN0aW5nOiBpbnRlcnJ1cHRzIGV0aGVy bmV0IHBvaW50X3RvX3BvaW50IHN3aS4KU3RhcnRpbmcgZmlsZSBzeXN0ZW0gY2hlY2tzOgov ZGV2L2FkYTBwMzogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2Fk YTBwMzogY2xlYW4sIDE2MzYzNjU5IGZyZWUgKDY1MDExIGZyYWdzLCAyMDM3MzMxIGJsb2Nr cywgMC4zJSBmcmFnbWVudGF0aW9uKQovZGV2L2FkYTBwNDogRklMRSBTWVNURU0gQ0xFQU47 IFNLSVBQSU5HIENIRUNLUwovZGV2L2FkYTBwNDogY2xlYW4sIDMyNjI4OTcyIGZyZWUgKDI2 NjY4IGZyYWdzLCA0MDc1Mjg4IGJsb2NrcywgMC4xJSBmcmFnbWVudGF0aW9uKQpNb3VudGlu ZyBsb2NhbCBmaWxlIHN5c3RlbXM6LgpXcml0aW5nIGVudHJvcHkgZmlsZTouClNldHRpbmcg aG9zdG5hbWU6IG5hY2h0c2NoYXR0ZW4ub3JrbGFuLmRlLgpTdGFydGluZyBOZXR3b3JrOiBs bzAgZW0wLgpsbzA6IGZsYWdzPTgwNDk8VVAsTE9PUEJBQ0ssUlVOTklORyxNVUxUSUNBU1Q+ IG1ldHJpYyAwIG10dSAxNjM4NAoJb3B0aW9ucz02MDAwMDM8UlhDU1VNLFRYQ1NVTSxSWENT VU1fSVBWNixUWENTVU1fSVBWNj4KCWluZXQ2IDo6MSBwcmVmaXhsZW4gMTI4IAoJaW5ldDYg ZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHgzIAoJaW5ldCAxMjcuMC4wLjEg bmV0bWFzayAweGZmMDAwMDAwIAoJbmQ2IG9wdGlvbnM9MjE8UEVSRk9STU5VRCxBVVRPX0xJ TktMT0NBTD4KZW0wOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgs TVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz00MjE5YjxSWENTVU0sVFhD U1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VNLFRTTzQsV09MX01BR0lD LFZMQU5fSFdUU08+CglldGhlciBmMDpkZTpmMTo0NjoxYjo4YwoJbmQ2IG9wdGlvbnM9Mjk8 UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0 IGF1dG9zZWxlY3QgKDEwMGJhc2VUWCA8ZnVsbC1kdXBsZXg+KQoJc3RhdHVzOiBhY3RpdmUK U3RhcnRpbmcgZGV2ZC4Ka2xkbG9hZDogY2FuJ3QgbG9hZCBuZ191YnQ6IE5vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnkKa2xkbG9hZDogY2FuJ3QgbG9hZCBuZ191YnQ6IE5vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnkKU3RhcnRpbmcgZGhjbGllbnQuCkRIQ1BSRVFVRVNUIG9uIGVtMCB0 byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NwpESENQQUNLIGZyb20gMTkyLjE2OC4xMy4xCmJv dW5kIHRvIDE5Mi4xNjguMTMuMiAtLSByZW5ld2FsIGluIDYwNDgwMCBzZWNvbmRzLgphZGQg bmV0IGZlODA6OjogZ2F0ZXdheSA6OjEKYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxCmFk ZCBuZXQgOjpmZmZmOjAuMC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgOjowLjAuMC4wOiBn YXRld2F5IDo6MQpFTEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNyL2xpYiAvdXNyL2xpYi9j b21wYXQgL3Vzci9sb2NhbC9saWIgL3Vzci9sb2NhbC9saWIvZ2NjNDggL3Vzci9sb2NhbC9s aWIvZ3JhcGh2aXogL3Vzci9sb2NhbC9saWIvbnNzIC91c3IvbG9jYWwvbGliL29wZW5jb2xs YWRhIC91c3IvbG9jYWwvbGliL3B0aCAvdXNyL2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9s aWIvcXRjcmVhdG9yIC91c3IvbG9jYWwvbGx2bTMzL2xpYiAvdXNyL2xvY2FsL2xsdm0zNC9s aWIgL3Vzci9sb2NhbC9sbHZtMzUvbGliCjMyLWJpdCBjb21wYXRpYmlsaXR5IGxkY29uZmln IHBhdGg6IC91c3IvbGliMzIKQ3JlYXRpbmcgYW5kL29yIHRyaW1taW5nIGxvZyBmaWxlcy4K U3RhcnRpbmcgc3lzbG9nZC4KTm8gY29yZSBkdW1wcyBmb3VuZC4KQ2xlYXJpbmcgL3RtcCAo WCByZWxhdGVkKS4KUmVjb3ZlcmluZyB2aSBlZGl0b3Igc2Vzc2lvbnM6LgpTdGFydGluZyBk YnVzLgpTdGFydGluZyBsb29sZXJkLgpVcGRhdGluZyBtb3RkOi4KTW91bnRpbmcgbGF0ZSBm aWxlIHN5c3RlbXM6LgpTdGFydGluZyBudHBkLgpTdGFydGluZyBwb3dlcmQuCkNvbmZpZ3Vy aW5nIHN5c2NvbnM6IGJsYW5rdGltZS4KUGVyZm9ybWluZyBzYW5pdHkgY2hlY2sgb24gc3No ZCBjb25maWd1cmF0aW9uLgpTdGFydGluZyBzc2hkLgpTdGFydGluZyBzZW5kbWFpbF9zdWJt aXQuClN0YXJ0aW5nIHNlbmRtYWlsX21zcF9xdWV1ZS4KU3RhcnRpbmcgY3Jvbi4Kc3lzY3Rs OiB1bmtub3duIG9pZCAnY29tcGF0LmxpbnV4Lm9zcmVsZWFzZScgYXQgbGluZSAyMTogTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpTdGFydGluZyBkZWZhdWx0IG1vdXNlZC4KU3RhcnRp bmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25kcy4KClR1ZSBO b3YgMTEgMjI6NTM6NTAgQ0VUIDIwMTQKTm92IDExIDIyOjUzOjU2IG5hY2h0c2NoYXR0ZW4g bG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYwCktMRCBudmlkaWEua286IGRlcGVu ZHMgb24gbGludXggLSBub3QgYXZhaWxhYmxlIG9yIHZlcnNpb24gbWlzbWF0Y2gKbGlua2Vy X2xvYWRfZmlsZTogVW5zdXBwb3J0ZWQgZmlsZSB0eXBlCk5vdiAxMSAyMzowNTo0MCBuYWNo dHNjaGF0dGVuIHJlYm9vdDogcmVib290ZWQgYnkgcm9vdApOb3YgMTEgMjM6MDU6NDAgbmFj aHRzY2hhdHRlbiBzeXNsb2dkOiBleGl0aW5nIG9uIHNpZ25hbCAxNQpXYWl0aW5nIChtYXgg NjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUK V2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9u JyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBw cm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFp bmluZy4uLjQgMSAyIDAgMCAwIDAgZG9uZQpBbGwgYnVmZmVycyBzeW5jZWQuClVwdGltZTog MTJtMjBzCnVzYnVzMDogQ29udHJvbGxlciBzaHV0ZG93bgp1aHViMDogYXQgdXNidXMwLCBw b3J0IDEsIGFkZHIgMSAoZGlzY29ubmVjdGVkKQp1Z2VuMC4yOiA8dmVuZG9yIDB4ODA4Nz4g YXQgdXNidXMwIChkaXNjb25uZWN0ZWQpCnVodWIzOiBhdCB1aHViMCwgcG9ydCAxLCBhZGRy IDIgKGRpc2Nvbm5lY3RlZCkKdWdlbjAuNDogPENoaWNvbnkgRWxlY3Ryb25pY3MgQ28uLCBM dGQuPiBhdCB1c2J1czAgKGRpc2Nvbm5lY3RlZCkKdXNidXMwOiBDb250cm9sbGVyIHNodXRk b3duIGNvbXBsZXRlCnVzYnVzMTogQ29udHJvbGxlciBzaHV0ZG93bgp1aHViMTogYXQgdXNi dXMxLCBwb3J0IDEsIGFkZHIgMSAoZGlzY29ubmVjdGVkKQp1Z2VuMS4yOiA8dmVuZG9yIDB4 ODA4Nz4gYXQgdXNidXMxIChkaXNjb25uZWN0ZWQpCnVodWIyOiBhdCB1aHViMSwgcG9ydCAx LCBhZGRyIDIgKGRpc2Nvbm5lY3RlZCkKdXNidXMxOiBDb250cm9sbGVyIHNodXRkb3duIGNv bXBsZXRlClJlYm9vdGluZy4uLgpjcHVfcmVzZXQ6IFN0b3BwaW5nIG90aGVyIENQVXMKQ29w eXJpZ2h0IChjKSAxOTkyLTIwMTQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkz LCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBB bGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsg b2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMC4wLVJFTEVBU0UtcDEyICMw OiBUdWUgTm92ICA0IDA1OjA3OjE3IFVUQyAyMDE0CiAgICByb290QGFtZDY0LWJ1aWxkZXIu ZGFlbW9ub2xvZ3kubmV0Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1kNjQKRnJl ZUJTRCBjbGFuZyB2ZXJzaW9uIDMuMyAodGFncy9SRUxFQVNFXzMzL2ZpbmFsIDE4MzUwMikg MjAxMzA2MTAKQ1BVOiBJbnRlbChSKSBDb3JlKFRNKSBpNSBDUFUgICAgICAgTSA1NjAgIEAg Mi42N0dIeiAoMjY2MC4wNi1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5l SW50ZWwiICBJZCA9IDB4MjA2NTUgIEZhbWlseSA9IDB4NiAgTW9kZWwgPSAweDI1ICBTdGVw cGluZyA9IDUKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxV U0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJl czI9MHgyOWFlM2ZmPFNTRTMsUENMTVVMUURRLERURVM2NCxNT04sRFNfQ1BMLFZNWCxTTVgs RVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxQQ0lELFNTRTQuMSxTU0U0LjIsUE9QQ05U LEFFU05JPgogIEFNRCBGZWF0dXJlcz0weDI4MTAwODAwPFNZU0NBTEwsTlgsUkRUU0NQLExN PgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwg cGVyZm9ybWFuY2Ugc3RhdGlzdGljcwpyZWFsIG1lbW9yeSAgPSA0Mjk0OTY3Mjk2ICg0MDk2 IE1CKQphdmFpbCBtZW1vcnkgPSAzOTYyODM0OTQ0ICgzNzc5IE1CKQpBQ1BJIEFQSUMgVGFi bGU6IDxMRU5PVk8gVFAtNkkgICA+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0 ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggMiBjb3Jl KHMpIHggMiBTTVQgdGhyZWFkcwogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQ KTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJQyBJRDogIDQKIGNwdTMgKEFQKTogQVBJ QyBJRDogIDUKaW9hcGljMDogQ2hhbmdpbmcgQVBJQyBJRCB0byAxCmlvYXBpYzAgPFZlcnNp b24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKa2JkMSBhdCBrYmRtdXgwCnJhbmRv bTogPFNvZnR3YXJlLCBZYXJyb3c+IGluaXRpYWxpemVkCmFjcGkwOiA8TEVOT1ZPIFRQLTZJ PiBvbiBtb3RoZXJib2FyZAphY3BpX2VjMDogPEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAw eDExLCBFQ0RUPiBwb3J0IDB4NjIsMHg2NiBvbiBhY3BpMAphY3BpMDogUG93ZXIgQnV0dG9u IChmaXhlZCkKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNw aTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgYmZmMDAwMDAgKDMpIGZhaWxlZApjcHUwOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFD UEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmF0dGltZXIwOiA8 QVQgdGltZXI+IHBvcnQgMHg0MC0weDQzIGlycSAwIG9uIGFjcGkwClRpbWVjb3VudGVyICJp ODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkV2ZW50IHRpbWVyICJpODI1 NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAxMDAKaHBldDA6IDxIaWdoIFByZWNp c2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkw ClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5NTAK RXZlbnQgdGltZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDU1MApF dmVudCB0aW1lciAiSFBFVDEiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApF dmVudCB0aW1lciAiSFBFVDIiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApF dmVudCB0aW1lciAiSFBFVDMiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApF dmVudCB0aW1lciAiSFBFVDQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MAph dHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNw aTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApUaW1l Y291bnRlciAiQUNQSS1zYWZlIiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDg1MAph Y3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDEwMDgt MHgxMDBiIG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+ IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6 IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAKcGNpMjU1OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMApwY2liMTogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4 Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaWIyOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxh eT4gcG9ydCAweDIwMDAtMHgyMDdmIG1lbSAweGNjMDAwMDAwLTB4Y2NmZmZmZmYsMHhkMDAw MDAwMC0weGRmZmZmZmZmLDB4Y2UwMDAwMDAtMHhjZmZmZmZmZiBpcnEgMTYgYXQgZGV2aWNl IDAuMCBvbiBwY2kxCnZnYXBjaTA6IEJvb3QgdmlkZW8gZGV2aWNlCmhkYWMwOiA8TlZJRElB ICgweDBiZTMpIEhEQSBDb250cm9sbGVyPiBtZW0gMHhjZGVmYzAwMC0weGNkZWZmZmZmIGF0 IGRldmljZSAwLjEgb24gcGNpMQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMjIu MCAobm8gZHJpdmVyIGF0dGFjaGVkKQp1YXJ0MjogPDUgU2VyaWVzLzM0MDAgU2VyaWVzIENo aXBzZXQgS1QgQ29udHJvbGxlcj4gcG9ydCAweDE4MDAtMHgxODA3IG1lbSAweGYyNDI0MDAw LTB4ZjI0MjRmZmYgaXJxIDE3IGF0IGRldmljZSAyMi4zIG9uIHBjaTAKZW0wOiA8SW50ZWwo UikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uIDcuMy44PiBwb3J0IDB4MTgyMC0weDE4 M2YgbWVtIDB4ZjI0MDAwMDAtMHhmMjQxZmZmZiwweGYyNDI1MDAwLTB4ZjI0MjVmZmYgaXJx IDIwIGF0IGRldmljZSAyNS4wIG9uIHBjaTAKZW0wOiBVc2luZyBhbiBNU0kgaW50ZXJydXB0 CmVtMDogRXRoZXJuZXQgYWRkcmVzczogZjA6ZGU6ZjE6NDY6MWI6OGMKZWhjaTA6IDxJbnRl bCBQQ0ggVVNCIDIuMCBjb250cm9sbGVyIFVTQi1CPiBtZW0gMHhmMjQyODAwMC0weGYyNDI4 M2ZmIGlycSAyMyBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVzYnVzMDogRUhDSSB2ZXJzaW9u IDEuMAp1c2J1czAgb24gZWhjaTAKaGRhYzE6IDxJbnRlbCA1IFNlcmllcy8zNDAwIFNlcmll cyBIREEgQ29udHJvbGxlcj4gbWVtIDB4ZjI0MjAwMDAtMHhmMjQyM2ZmZiBpcnEgMTcgYXQg ZGV2aWNlIDI3LjAgb24gcGNpMApwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAy MCBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIz CnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDIxIGF0IGRldmljZSAyOC4xIG9u IHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKaXduMDogPEludGVsIENlbnRy aW5vIFVsdGltYXRlLU4gNjMwMD4gbWVtIDB4ZjIwMDAwMDAtMHhmMjAwMWZmZiBpcnEgMTcg YXQgZGV2aWNlIDAuMCBvbiBwY2kzCnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDIwIGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNpMTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWI1CnNkaGNpX3BjaTA6IDxSSUNPSCBTRD4gbWVtIDB4ZjIxMDAwMDAtMHhmMjEwMDBmZiBp cnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxMwpzZGhjaV9wY2kwOiAxIHNsb3QocykgYWxs b2NhdGVkCnBjaTEzOiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMC4xIChubyBkcml2 ZXIgYXR0YWNoZWQpCmVoY2kxOiA8SW50ZWwgUENIIFVTQiAyLjAgY29udHJvbGxlciBVU0It QT4gbWVtIDB4ZjI0Mjg0MDAtMHhmMjQyODdmZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjAgb24g cGNpMAp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMxIG9uIGVoY2kxCnBjaWI2OiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2kxNDogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjYKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNl IDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYWhjaTA6IDxJbnRlbCA1 IFNlcmllcy8zNDAwIFNlcmllcyBBSENJIFNBVEEgY29udHJvbGxlcj4gcG9ydCAweDE4MTgt MHgxODFmLDB4MTgwYy0weDE4MGYsMHgxODEwLTB4MTgxNywweDE4MDgtMHgxODBiLDB4MTg0 MC0weDE4NWYgbWVtIDB4ZjI0MjcwMDAtMHhmMjQyNzdmZiBpcnEgMTYgYXQgZGV2aWNlIDMx LjIgb24gcGNpMAphaGNpMDogQUhDSSB2MS4zMCB3aXRoIDYgM0dicHMgcG9ydHMsIFBvcnQg TXVsdGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNo YW5uZWwgMCBvbiBhaGNpMAphaGNpY2gxOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDEg b24gYWhjaTAKYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9uIGFoY2kw CmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNpMAphaGNpZW0w OiA8QUhDSSBlbmNsb3N1cmUgbWFuYWdlbWVudCBicmlkZ2U+IG9uIGFoY2kwCnBjaTA6IDxz ZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkK cGNpMDogPGRhc3A+IGF0IGRldmljZSAzMS42IChubyBkcml2ZXIgYXR0YWNoZWQpCmFjcGlf dHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJv bGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxB VCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtH SUFOVC1MT0NLRURdCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20w OiBbR0lBTlQtTE9DS0VEXQpwc20wOiBtb2RlbCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmlj ZSBJRCAwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3Bp MAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKYWNwaV9pYm0wOiA8SUJNIFRo aW5rUGFkIEFDUEkgRXh0cmFzPiBvbiBhY3BpMApvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBh dCBpb21lbSAweGQwMDAwLTB4ZDBmZmYsMHhkMTAwMC0weGQxZmZmLDB4ZGQwMDAtMHhkZmZm ZiwweGUwMDAwLTB4ZWZmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxh Z3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9 MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9t ZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBv cnQgcmFuZ2UKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4g b24gY3B1MAplc3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBv biBjcHUxCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTIKZXN0MzogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24g Y3B1MwpUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYwpoZGFjYzA6IDxOVklE SUEgR1QyMXggSERBIENPREVDPiBhdCBjYWQgMCBvbiBoZGFjMApoZGFhMDogPE5WSURJQSBH VDIxeCBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2MwCnBjbTA6IDxO VklESUEgR1QyMXggKEhETUkvRFAgOGNoKT4gYXQgbmlkIDUgb24gaGRhYTAKaGRhY2MxOiA8 TlZJRElBIEdUMjF4IEhEQSBDT0RFQz4gYXQgY2FkIDEgb24gaGRhYzAKaGRhYTE6IDxOVklE SUEgR1QyMXggQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMQpwY20x OiA8TlZJRElBIEdUMjF4IChIRE1JL0RQIDhjaCk+IGF0IG5pZCA1IG9uIGhkYWExCmhkYWNj MjogPE5WSURJQSBHVDIxeCBIREEgQ09ERUM+IGF0IGNhZCAyIG9uIGhkYWMwCmhkYWEyOiA8 TlZJRElBIEdUMjF4IEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzIK cGNtMjogPE5WSURJQSBHVDIxeCAoSERNSS9EUCA4Y2gpPiBhdCBuaWQgNSBvbiBoZGFhMgpo ZGFjYzM6IDxOVklESUEgR1QyMXggSERBIENPREVDPiBhdCBjYWQgMyBvbiBoZGFjMApoZGFh MzogPE5WSURJQSBHVDIxeCBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRh Y2MzCnBjbTM6IDxOVklESUEgR1QyMXggKEhETUkvRFAgOGNoKT4gYXQgbmlkIDUgb24gaGRh YTMKaGRhY2M0OiA8Q29uZXhhbnQgQ1gyMDU4NSBIREEgQ09ERUM+IGF0IGNhZCAwIG9uIGhk YWMxCmhkYWE0OiA8Q29uZXhhbnQgQ1gyMDU4NSBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQg bmlkIDEgb24gaGRhY2M0CnBjbTQ6IDxDb25leGFudCBDWDIwNTg1IChSaWdodCBBbmFsb2cp PiBhdCBuaWQgMjUgYW5kIDI3IG9uIGhkYWE0CnBjbTU6IDxDb25leGFudCBDWDIwNTg1IChJ bnRlcm5hbCBBbmFsb2cpPiBhdCBuaWQgMzEgYW5kIDM1IG9uIGhkYWE0CnJhbmRvbTogdW5i bG9ja2luZyBkZXZpY2UuCnVzYnVzMDogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVz YnVzMTogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxJbnRlbD4gYXQg dXNidXMwCnVodWIwOiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1 aHViMTogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czEKc2VzMCBhdCBhaGNpZW0wIGJ1cyAwIHNjYnVzNCB0YXJnZXQg MCBsdW4gMApzZXMwOiA8QUhDSSBTR1BJTyBFbmNsb3N1cmUgMS4wMCAwMDAxPiBTRU1CIFMt RS1TIDIuMDAgZGV2aWNlCnNlczA6IFNFTUIgU0VTIERldmljZQphZGEwIGF0IGFoY2ljaDAg YnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmFkYTA6IDxXREMgV0QzMjAwQkVWVC0wOEEy M1QxIDAyLjAxQTAyPiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKYWRhMDogU2VyaWFsIE51bWJl ciBXRC1XWEQxQTExNTQyNzUKYWRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIu eCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxl ZAphZGEwOiAzMDUyNDVNQiAoNjI1MTQyNDQ4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1Mv VCAxNjM4M0MpCmFkYTA6IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkNApjZDAgYXQgYWhj aWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8T3B0aWFyYyBEVkQgUlcg QUQtNzkzMEggMS5EMT4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApjZDA6IDE1 MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAxLngsIFVETUE1LCBBVEFQSSAxMmJ5dGVzLCBQ SU8gODE5MmJ5dGVzKQpjZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVk OiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudCAtIHRyYXkgY2xvc2VkCk5ldHZzYyBp bml0aWFsaXppbmcuLi4gU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMy IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMyBMYXVuY2hlZCEKVGltZWNvdW50ZXIgIlRTQy1s b3ciIGZyZXF1ZW5jeSAxMzMwMDMxMTY4IEh6IHF1YWxpdHkgMTAwMApSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxIHVzYnVzMApSb290IG1v dW50IHdhaXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVnZW4wLjI6IDx2ZW5kb3IgMHg4MDg3 PiBhdCB1c2J1czAKdWh1YjI6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgwMDIwLCBjbGFz cyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMwCnVnZW4xLjI6IDx2ZW5k b3IgMHg4MDg3PiBhdCB1c2J1czEKdWh1YjM6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgw MDIwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMxCnVodWIy OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVodWIzOiA4IHBvcnRzIHdpdGggOCByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAp1Z2VuMC4zOiA8QnJvYWRjb20gQ29ycD4gYXQgdXNidXMwClJv b3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMAp1Z2VuMC40OiA8Q2hpY29ueSBFbGVjdHJv bmljcyBDby4sIEx0ZC4+IGF0IHVzYnVzMApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVm czovZGV2L2FkYTBwMyBbcnddLi4uCnVnZW4wLjM6IDxCcm9hZGNvbSBDb3JwPiBhdCB1c2J1 czAgKGRpc2Nvbm5lY3RlZCkKU2V0dGluZyBob3N0dXVpZDogODE5MDU0MGQtMTU1MS1jYjEx LWEzNGYtZGUyYjYzMjNhMzFmLgpTZXR0aW5nIGhvc3RpZDogMHhkNzZiOGE3Yi4KRW50cm9w eSBoYXJ2ZXN0aW5nOiBpbnRlcnJ1cHRzIGV0aGVybmV0IHBvaW50X3RvX3BvaW50IHN3aS4K U3RhcnRpbmcgZmlsZSBzeXN0ZW0gY2hlY2tzOgovZGV2L2FkYTBwMzogRklMRSBTWVNURU0g Q0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2FkYTBwMzogY2xlYW4sIDE2MzYzNzk2IGZy ZWUgKDY1MDEyIGZyYWdzLCAyMDM3MzQ4IGJsb2NrcywgMC4zJSBmcmFnbWVudGF0aW9uKQov ZGV2L2FkYTBwNDogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2Fk YTBwNDogY2xlYW4sIDMyNjI4OTcyIGZyZWUgKDI2NjY4IGZyYWdzLCA0MDc1Mjg4IGJsb2Nr cywgMC4xJSBmcmFnbWVudGF0aW9uKQpNb3VudGluZyBsb2NhbCBmaWxlIHN5c3RlbXM6LgpX cml0aW5nIGVudHJvcHkgZmlsZTouClNldHRpbmcgaG9zdG5hbWU6IG5hY2h0c2NoYXR0ZW4u b3JrbGFuLmRlLgp3bGFuMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjQ6ZDc6OTE6YjU6NDQK U3RhcnRpbmcgd3BhX3N1cHBsaWNhbnQuCml3bjYwMDBmdzogY291bGQgbm90IGxvYWQgZmly bXdhcmUgaW1hZ2UsIGVycm9yIDIKaXduMDogaXduX3JlYWRfZmlybXdhcmU6IGNvdWxkIG5v dCByZWFkIGZpcm13YXJlIGl3bjYwMDBmdwppd24wOiBpd25faW5pdF9sb2NrZWQ6IGNvdWxk IG5vdCByZWFkIGZpcm13YXJlLCBlcnJvciAyMgpTdGFydGluZyBOZXR3b3JrOiBsbzAgZW0w IGl3bjAuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4g bWV0cmljIDAgbXR1IDE2Mzg0CglvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhDU1VNLFJYQ1NV TV9JUFY2LFRYQ1NVTV9JUFY2PgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBm ZTgwOjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDMgCglpbmV0IDEyNy4wLjAuMSBu ZXRtYXNrIDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElO S0xPQ0FMPgplbTA6IGZsYWdzPThjMDI8QlJPQURDQVNULE9BQ1RJVkUsU0lNUExFWCxNVUxU SUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQyMTliPFJYQ1NVTSxUWENTVU0s VkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxXT0xfTUFHSUMsVkxB Tl9IV1RTTz4KCWV0aGVyIGYwOmRlOmYxOjQ2OjFiOjhjCgluZDYgb3B0aW9ucz0yOTxQRVJG T1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CgltZWRpYTogRXRoZXJuZXQgYXV0 b3NlbGVjdAoJc3RhdHVzOiBubyBjYXJyaWVyCml3bjA6IGZsYWdzPTg4MDM8VVAsQlJPQURD QVNULFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMjI5MAoJZXRoZXIgMDA6MjQ6 ZDc6OTE6YjU6NDQKCW5kNiBvcHRpb25zPTIxPFBFUkZPUk1OVUQsQVVUT19MSU5LTE9DQUw+ CgltZWRpYTogSUVFRSA4MDIuMTEgV2lyZWxlc3MgRXRoZXJuZXQgYXV0b3NlbGVjdCBtb2Rl IDExYgoJc3RhdHVzOiBhc3NvY2lhdGVkClN0YXJ0aW5nIGRldmQuClN0YXJ0aW5nIE5ldHdv cms6IGVtMC4KZW0wOiBmbGFncz04YzAyPEJST0FEQ0FTVCxPQUNUSVZFLFNJTVBMRVgsTVVM VElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz00MjE5YjxSWENTVU0sVFhDU1VN LFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VNLFRTTzQsV09MX01BR0lDLFZM QU5fSFdUU08+CglldGhlciBmMDpkZTpmMTo0NjoxYjo4YwoJbmQ2IG9wdGlvbnM9Mjk8UEVS Rk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1 dG9zZWxlY3QKCXN0YXR1czogbm8gY2FycmllcgprbGRsb2FkOiBjYW4ndCBsb2FkIG5nX3Vi dDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQprbGRsb2FkOiBjYW4ndCBsb2FkIG5nX3Vi dDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQphZGQgbmV0IGZlODA6OjogZ2F0ZXdheSA6 OjEKYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxCmFkZCBuZXQgOjpmZmZmOjAuMC4wLjA6 IGdhdGV3YXkgOjoxCmFkZCBuZXQgOjowLjAuMC4wOiBnYXRld2F5IDo6MQpXYWl0aW5nIDMw cyBmb3IgdGhlIGRlZmF1bHQgcm91dGUgaW50ZXJmYWNlOiAuLi4uLihubyBjYXJyaWVyKQpF TEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNyL2xpYiAvdXNyL2xpYi9jb21wYXQgL3Vzci9s b2NhbC9saWIgL3Vzci9sb2NhbC9saWIvZ2NjNDggL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXog L3Vzci9sb2NhbC9saWIvbnNzIC91c3IvbG9jYWwvbGliL29wZW5jb2xsYWRhIC91c3IvbG9j YWwvbGliL3B0aCAvdXNyL2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9saWIvcXRjcmVhdG9y IC91c3IvbG9jYWwvbGx2bTMzL2xpYiAvdXNyL2xvY2FsL2xsdm0zNC9saWIgL3Vzci9sb2Nh bC9sbHZtMzUvbGliCjMyLWJpdCBjb21wYXRpYmlsaXR5IGxkY29uZmlnIHBhdGg6IC91c3Iv bGliMzIKQ3JlYXRpbmcgYW5kL29yIHRyaW1taW5nIGxvZyBmaWxlcy4KU3RhcnRpbmcgc3lz bG9nZC4KTm8gY29yZSBkdW1wcyBmb3VuZC4KQ2xlYXJpbmcgL3RtcCAoWCByZWxhdGVkKS4K UmVjb3ZlcmluZyB2aSBlZGl0b3Igc2Vzc2lvbnM6LgpOb3YgMTEgMjM6MDY6NDUgbmFjaHRz Y2hhdHRlbiB3cGFfc3VwcGxpY2FudFs1ODBdOiBpb2N0bFtTSU9DUzgwMjExLCBvcD0xMDMs IHZhbD0wLCBhcmdfbGVuPTEyOF06IERldmljZSBub3QgY29uZmlndXJlZApTdGFydGluZyBk YnVzLgpTdGFydGluZyBsb29sZXJkLgpVcGRhdGluZyBtb3RkOi4KTW91bnRpbmcgbGF0ZSBm aWxlIHN5c3RlbXM6LgpTdGFydGluZyBudHBkLgpTdGFydGluZyBwb3dlcmQuCkNvbmZpZ3Vy aW5nIHN5c2NvbnM6IGJsYW5rdGltZS4KUGVyZm9ybWluZyBzYW5pdHkgY2hlY2sgb24gc3No ZCBjb25maWd1cmF0aW9uLgpTdGFydGluZyBzc2hkLgpTdGFydGluZyBzZW5kbWFpbF9zdWJt aXQuClN0YXJ0aW5nIHNlbmRtYWlsX21zcF9xdWV1ZS4KU3RhcnRpbmcgY3Jvbi4Kc3lzY3Rs OiB1bmtub3duIG9pZCAnY29tcGF0LmxpbnV4Lm9zcmVsZWFzZScgYXQgbGluZSAyMTogTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpTdGFydGluZyBkZWZhdWx0IG1vdXNlZC4KU3RhcnRp bmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25kcy4KClR1ZSBO b3YgMTEgMjM6MDY6NDcgQ0VUIDIwMTQKTm92IDExIDIzOjA2OjQ3IG5hY2h0c2NoYXR0ZW4g bGFzdCBtZXNzYWdlIHJlcGVhdGVkIDIgdGltZXMKTm92IDExIDIzOjA2OjQ4IG5hY2h0c2No YXR0ZW4gbnRwZF9pbml0cmVzWzEyMzVdOiBob3N0IG5hbWUgbm90IGZvdW5kOiBwdGJ0aW1l MS5wdGIuZGUKTm92IDExIDIzOjA2OjQ4IG5hY2h0c2NoYXR0ZW4gbnRwZF9pbml0cmVzWzEy MzVdOiBob3N0IG5hbWUgbm90IGZvdW5kOiBwdGJ0aW1lMi5wdGIuZGUKTm92IDExIDIzOjA2 OjQ4IG5hY2h0c2NoYXR0ZW4gbnRwZF9pbml0cmVzWzEyMzVdOiBob3N0IG5hbWUgbm90IGZv dW5kOiBwdGJ0aW1lMy5wdGIuZGUKTm92IDExIDIzOjA2OjQ4IG5hY2h0c2NoYXR0ZW4gd3Bh X3N1cHBsaWNhbnRbNTgwXTogaW9jdGxbU0lPQ1M4MDIxMSwgb3A9MTAzLCB2YWw9MCwgYXJn X2xlbj0xMjhdOiBEZXZpY2Ugbm90IGNvbmZpZ3VyZWQKTm92IDExIDIzOjA2OjUzIG5hY2h0 c2NoYXR0ZW4gbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDUgdGltZXMKTm92IDExIDIzOjA2OjU0 IG5hY2h0c2NoYXR0ZW4gbG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYwCk5vdiAx MSAyMzowNjo1NCBuYWNodHNjaGF0dGVuIHdwYV9zdXBwbGljYW50WzU4MF06IGlvY3RsW1NJ T0NTODAyMTEsIG9wPTEwMywgdmFsPTAsIGFyZ19sZW49MTI4XTogRGV2aWNlIG5vdCBjb25m aWd1cmVkCk5vdiAxMSAyMzowNzoxNCBuYWNodHNjaGF0dGVuIGxhc3QgbWVzc2FnZSByZXBl YXRlZCAxOSB0aW1lcwpOb3YgMTEgMjM6MDc6MTUgbmFjaHRzY2hhdHRlbiByZWJvb3Q6IHJl Ym9vdGVkIGJ5IHJvb3QKTm92IDExIDIzOjA3OjE1IG5hY2h0c2NoYXR0ZW4gc3lzbG9nZDog ZXhpdGluZyBvbiBzaWduYWwgMTUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNv bmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2Fp dGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBz dG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi42IDIgMiAwIDEgMSAw IGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpVcHRpbWU6IDFtM3MKdXNidXMwOiBDb250cm9s bGVyIHNodXRkb3duCnVodWIwOiBhdCB1c2J1czAsIHBvcnQgMSwgYWRkciAxIChkaXNjb25u ZWN0ZWQpCnVnZW4wLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czAgKGRpc2Nvbm5lY3Rl ZCkKdWh1YjI6IGF0IHVodWIwLCBwb3J0IDEsIGFkZHIgMiAoZGlzY29ubmVjdGVkKQp1Z2Vu MC40OiA8Q2hpY29ueSBFbGVjdHJvbmljcyBDby4sIEx0ZC4+IGF0IHVzYnVzMCAoZGlzY29u bmVjdGVkKQp1c2J1czA6IENvbnRyb2xsZXIgc2h1dGRvd24gY29tcGxldGUKdXNidXMxOiBD b250cm9sbGVyIHNodXRkb3duCnVodWIxOiBhdCB1c2J1czEsIHBvcnQgMSwgYWRkciAxIChk aXNjb25uZWN0ZWQpCnVnZW4xLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czEgKGRpc2Nv bm5lY3RlZCkKdWh1YjM6IGF0IHVodWIxLCBwb3J0IDEsIGFkZHIgMiAoZGlzY29ubmVjdGVk KQp1c2J1czE6IENvbnRyb2xsZXIgc2h1dGRvd24gY29tcGxldGUKUmVib290aW5nLi4uCmNw dV9yZXNldDogU3RvcHBpbmcgb3RoZXIgQ1BVcwpDb3B5cmlnaHQgKGMpIDE5OTItMjAxNCBU aGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5 ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZy ZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0 aW9uLgpGcmVlQlNEIDEwLjAtUkVMRUFTRS1wMTIgIzA6IFR1ZSBOb3YgIDQgMDU6MDc6MTcg VVRDIDIwMTQKICAgIHJvb3RAYW1kNjQtYnVpbGRlci5kYWVtb25vbG9neS5uZXQ6L3Vzci9v YmovdXNyL3NyYy9zeXMvR0VORVJJQyBhbWQ2NApGcmVlQlNEIGNsYW5nIHZlcnNpb24gMy4z ICh0YWdzL1JFTEVBU0VfMzMvZmluYWwgMTgzNTAyKSAyMDEzMDYxMApDUFU6IEludGVsKFIp IENvcmUoVE0pIGk1IENQVSAgICAgICBNIDU2MCAgQCAyLjY3R0h6ICgyNjYwLjA2LU1IeiBL OC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgyMDY1NSAg RmFtaWx5ID0gMHg2ICBNb2RlbCA9IDB4MjUgIFN0ZXBwaW5nID0gNQogIEZlYXR1cmVzPTB4 YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxN VFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixT U0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDI5YWUzZmY8U1NFMyxQQ0xN VUxRRFEsRFRFUzY0LE1PTixEU19DUEwsVk1YLFNNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQ UixQRENNLFBDSUQsU1NFNC4xLFNTRTQuMixQT1BDTlQsQUVTTkk+CiAgQU1EIEZlYXR1cmVz PTB4MjgxMDA4MDA8U1lTQ0FMTCxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8 TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNz CnJlYWwgbWVtb3J5ICA9IDQyOTQ5NjcyOTYgKDQwOTYgTUIpCmF2YWlsIG1lbW9yeSA9IDM5 NjI4MzQ5NDQgKDM3NzkgTUIpCkFDUEkgQVBJQyBUYWJsZTogPExFTk9WTyBUUC02SSAgID4K RnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCkZy ZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCAyIGNvcmUocykgeCAyIFNNVCB0aHJlYWRzCiBj cHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAo QVApOiBBUElDIElEOiAgNAogY3B1MyAoQVApOiBBUElDIElEOiAgNQppb2FwaWMwOiBDaGFu Z2luZyBBUElDIElEIHRvIDEKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBt b3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKcmFuZG9tOiA8U29mdHdhcmUsIFlhcnJvdz4g aW5pdGlhbGl6ZWQKYWNwaTA6IDxMRU5PVk8gVFAtNkk+IG9uIG1vdGhlcmJvYXJkCmFjcGlf ZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4MTEsIEVDRFQ+IHBvcnQgMHg2Miww eDY2IG9uIGFjcGkwCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogcmVzZXJ2 YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAw MDAwLCBiZmYwMDAwMCAoMykgZmFpbGVkCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1 MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6 IDxBQ1BJIENQVT4gb24gYWNwaTAKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4 NDMgaXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBI eiBxdWFsaXR5IDEwMApocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21l bSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDk1MApFdmVudCB0aW1lciAiSFBFVCIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNTUwCkV2ZW50IHRpbWVyICJIUEVUMSIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUMiIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUMyIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUNCIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNs b2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEgOCBvbiBhY3BpMApFdmVudCB0aW1lciAiUlRDIiBm cmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAwClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZy ZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRp bWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNwaTAKYWNwaV9s aWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNwaTAKYWNwaV9idXR0b24w OiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl PiBvbiBhY3BpMApwY2kyNTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQ SSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEg MTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIy CnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4MjAwMC0weDIwN2Yg bWVtIDB4Y2MwMDAwMDAtMHhjY2ZmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZmZmYsMHhjZTAw MDAwMC0weGNmZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKdmdhcGNpMDog Qm9vdCB2aWRlbyBkZXZpY2UKaGRhYzA6IDxOVklESUEgKDB4MGJlMykgSERBIENvbnRyb2xs ZXI+IG1lbSAweGNkZWZjMDAwLTB4Y2RlZmZmZmYgYXQgZGV2aWNlIDAuMSBvbiBwY2kxCnBj aTA6IDxzaW1wbGUgY29tbXM+IGF0IGRldmljZSAyMi4wIChubyBkcml2ZXIgYXR0YWNoZWQp CnVhcnQyOiA8NSBTZXJpZXMvMzQwMCBTZXJpZXMgQ2hpcHNldCBLVCBDb250cm9sbGVyPiBw b3J0IDB4MTgwMC0weDE4MDcgbWVtIDB4ZjI0MjQwMDAtMHhmMjQyNGZmZiBpcnEgMTcgYXQg ZGV2aWNlIDIyLjMgb24gcGNpMAplbTA6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENv bm5lY3Rpb24gNy4zLjg+IHBvcnQgMHgxODIwLTB4MTgzZiBtZW0gMHhmMjQwMDAwMC0weGYy NDFmZmZmLDB4ZjI0MjUwMDAtMHhmMjQyNWZmZiBpcnEgMjAgYXQgZGV2aWNlIDI1LjAgb24g cGNpMAplbTA6IFVzaW5nIGFuIE1TSSBpbnRlcnJ1cHQKZW0wOiBFdGhlcm5ldCBhZGRyZXNz OiBmMDpkZTpmMTo0NjoxYjo4YwplaGNpMDogPEludGVsIFBDSCBVU0IgMi4wIGNvbnRyb2xs ZXIgVVNCLUI+IG1lbSAweGYyNDI4MDAwLTB4ZjI0MjgzZmYgaXJxIDIzIGF0IGRldmljZSAy Ni4wIG9uIHBjaTAKdXNidXMwOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMCBvbiBlaGNpMApo ZGFjMTogPEludGVsIDUgU2VyaWVzLzM0MDAgU2VyaWVzIEhEQSBDb250cm9sbGVyPiBtZW0g MHhmMjQyMDAwMC0weGYyNDIzZmZmIGlycSAxNyBhdCBkZXZpY2UgMjcuMCBvbiBwY2kwCnBj aWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDIwIGF0IGRldmljZSAyOC4wIG9uIHBj aTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMjEgYXQgZGV2aWNlIDI4LjEgb24gcGNpMApwY2kzOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liNAppd24wOiA8SW50ZWwgQ2VudHJpbm8gVWx0aW1hdGUtTiA2MzAwPiBt ZW0gMHhmMjAwMDAwMC0weGYyMDAxZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTMK cGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMjAgYXQgZGV2aWNlIDI4LjQgb24g cGNpMApwY2kxMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKc2RoY2lfcGNpMDogPFJJQ09I IFNEPiBtZW0gMHhmMjEwMDAwMC0weGYyMTAwMGZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9u IHBjaTEzCnNkaGNpX3BjaTA6IDEgc2xvdChzKSBhbGxvY2F0ZWQKcGNpMTM6IDxiYXNlIHBl cmlwaGVyYWw+IGF0IGRldmljZSAwLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKZWhjaTE6IDxJ bnRlbCBQQ0ggVVNCIDIuMCBjb250cm9sbGVyIFVTQi1BPiBtZW0gMHhmMjQyODQwMC0weGYy NDI4N2ZmIGlycSAxOSBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVzYnVzMTogRUhDSSB2ZXJz aW9uIDEuMAp1c2J1czEgb24gZWhjaTEKcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTE0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgpp c2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJ U0EgYnVzPiBvbiBpc2FiMAphaGNpMDogPEludGVsIDUgU2VyaWVzLzM0MDAgU2VyaWVzIEFI Q0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4MTgxOC0weDE4MWYsMHgxODBjLTB4MTgwZiww eDE4MTAtMHgxODE3LDB4MTgwOC0weDE4MGIsMHgxODQwLTB4MTg1ZiBtZW0gMHhmMjQyNzAw MC0weGYyNDI3N2ZmIGlycSAxNiBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmFoY2kwOiBBSENJ IHYxLjMwIHdpdGggNiAzR2JwcyBwb3J0cywgUG9ydCBNdWx0aXBsaWVyIG5vdCBzdXBwb3J0 ZWQKYWhjaWNoMDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAwIG9uIGFoY2kwCmFoY2lj aDE6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBhaGNpMAphaGNpY2g0OiA8QUhD SSBjaGFubmVsPiBhdCBjaGFubmVsIDQgb24gYWhjaTAKYWhjaWNoNTogPEFIQ0kgY2hhbm5l bD4gYXQgY2hhbm5lbCA1IG9uIGFoY2kwCmFoY2llbTA6IDxBSENJIGVuY2xvc3VyZSBtYW5h Z2VtZW50IGJyaWRnZT4gb24gYWhjaTAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBk ZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8ZGFzcD4gYXQgZGV2aWNl IDMxLjYgKG5vIGRyaXZlciBhdHRhY2hlZCkKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9u IGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2 MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBh dGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogPFBT LzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6 IG1vZGVsIEdlbmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDAKYmF0dGVyeTA6IDxBQ1BJ IENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfYWNhZDA6IDxBQyBBZGFw dGVyPiBvbiBhY3BpMAphY3BpX2libTA6IDxJQk0gVGhpbmtQYWQgQUNQSSBFeHRyYXM+IG9u IGFjcGkwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4ZDAwMDAtMHhkMGZm ZiwweGQxMDAwLTB4ZDFmZmYsMHhkZDAwMC0weGRmZmZmLDB4ZTAwMDAtMHhlZmZmZiBvbiBp c2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDog VkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMg SVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24g aXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQplc3QwOiA8RW5oYW5j ZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCmVzdDE6IDxFbmhhbmNl ZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEKZXN0MjogPEVuaGFuY2Vk IFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Mgplc3QzOiA8RW5oYW5jZWQg U3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzClRpbWVjb3VudGVycyB0aWNr IGV2ZXJ5IDEwLjAwMCBtc2VjCmhkYWNjMDogPE5WSURJQSBHVDIxeCBIREEgQ09ERUM+IGF0 IGNhZCAwIG9uIGhkYWMwCmhkYWEwOiA8TlZJRElBIEdUMjF4IEF1ZGlvIEZ1bmN0aW9uIEdy b3VwPiBhdCBuaWQgMSBvbiBoZGFjYzAKcGNtMDogPE5WSURJQSBHVDIxeCAoSERNSS9EUCA4 Y2gpPiBhdCBuaWQgNSBvbiBoZGFhMApoZGFjYzE6IDxOVklESUEgR1QyMXggSERBIENPREVD PiBhdCBjYWQgMSBvbiBoZGFjMApoZGFhMTogPE5WSURJQSBHVDIxeCBBdWRpbyBGdW5jdGlv biBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2MxCnBjbTE6IDxOVklESUEgR1QyMXggKEhETUkv RFAgOGNoKT4gYXQgbmlkIDUgb24gaGRhYTEKaGRhY2MyOiA8TlZJRElBIEdUMjF4IEhEQSBD T0RFQz4gYXQgY2FkIDIgb24gaGRhYzAKaGRhYTI6IDxOVklESUEgR1QyMXggQXVkaW8gRnVu Y3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMgpwY20yOiA8TlZJRElBIEdUMjF4IChI RE1JL0RQIDhjaCk+IGF0IG5pZCA1IG9uIGhkYWEyCmhkYWNjMzogPE5WSURJQSBHVDIxeCBI REEgQ09ERUM+IGF0IGNhZCAzIG9uIGhkYWMwCmhkYWEzOiA8TlZJRElBIEdUMjF4IEF1ZGlv IEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzMKcGNtMzogPE5WSURJQSBHVDIx eCAoSERNSS9EUCA4Y2gpPiBhdCBuaWQgNSBvbiBoZGFhMwpoZGFjYzQ6IDxDb25leGFudCBD WDIwNTg1IEhEQSBDT0RFQz4gYXQgY2FkIDAgb24gaGRhYzEKaGRhYTQ6IDxDb25leGFudCBD WDIwNTg1IEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzQKcGNtNDog PENvbmV4YW50IENYMjA1ODUgKFJpZ2h0IEFuYWxvZyk+IGF0IG5pZCAyNSBhbmQgMjcgb24g aGRhYTQKcGNtNTogPENvbmV4YW50IENYMjA1ODUgKEludGVybmFsIEFuYWxvZyk+IGF0IG5p ZCAzMSBhbmQgMzUgb24gaGRhYTQKcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KdXNidXMw OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdXNidXMxOiA0ODBNYnBzIEhpZ2ggU3Bl ZWQgVVNCIHYyLjAKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJbnRlbCBF SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwgRUhDSSByb290 IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQpzZXMw IGF0IGFoY2llbTAgYnVzIDAgc2NidXM0IHRhcmdldCAwIGx1biAwCnNlczA6IDxBSENJIFNH UElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4wMCBkZXZpY2UKc2VzMDog U0VNQiBTRVMgRGV2aWNlCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAg bHVuIDAKYWRhMDogPFdEQyBXRDMyMDBCRVZULTA4QTIzVDEgMDIuMDFBMDI+IEFUQS04IFNB VEEgMi54IGRldmljZQphZGEwOiBTZXJpYWwgTnVtYmVyIFdELVdYRDFBMTE1NDI3NQphZGEw OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRl cykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDMwNTI0NU1CICg2MjUx NDI0NDggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMDogUHJldmlv dXNseSB3YXMga25vd24gYXMgYWQ0CmNkMCBhdCBhaGNpY2gxIGJ1cyAwIHNjYnVzMSB0YXJn ZXQgMCBsdW4gMApjZDA6IDxPcHRpYXJjIERWRCBSVyBBRC03OTMwSCAxLkQxPiBSZW1vdmFi bGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCmNkMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChT QVRBIDEueCwgVURNQTUsIEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpCmNkMDogQXR0 ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5v dCBwcmVzZW50IC0gdHJheSBjbG9zZWQKTmV0dnNjIGluaXRpYWxpemluZy4uLiBTTVA6IEFQ IENQVSAjMSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIgTGF1bmNoZWQhClNNUDogQVAgQ1BV ICMzIExhdW5jaGVkIQpUaW1lY291bnRlciAiVFNDLWxvdyIgZnJlcXVlbmN5IDEzMzAwMjk0 MjYgSHogcXVhbGl0eSAxMDAwClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMSB1c2J1 czAKdWh1YjE6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIw OiAzIHBvcnRzIHdpdGggMyByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVnZW4wLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1 c2J1czAKdWh1YjI6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgwMDIwLCBjbGFzcyA5LzAs IHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMwCnVnZW4xLjI6IDx2ZW5kb3IgMHg4 MDg3PiBhdCB1c2J1czEKdWh1YjM6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgwMDIwLCBj bGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMxClJvb3QgbW91bnQg d2FpdGluZyBmb3I6IHVzYnVzMSB1c2J1czAKdWh1YjI6IDYgcG9ydHMgd2l0aCA2IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMSB1c2J1 czAKdWh1YjM6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW4w LjM6IDxCcm9hZGNvbSBDb3JwPiBhdCB1c2J1czAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjog dXNidXMwCnVnZW4wLjQ6IDxDaGljb255IEVsZWN0cm9uaWNzIENvLiwgTHRkLj4gYXQgdXNi dXMwClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWRhMHAzIFtyd10uLi4K dWdlbjAuMzogPEJyb2FkY29tIENvcnA+IGF0IHVzYnVzMCAoZGlzY29ubmVjdGVkKQpTZXR0 aW5nIGhvc3R1dWlkOiA4MTkwNTQwZC0xNTUxLWNiMTEtYTM0Zi1kZTJiNjMyM2EzMWYuClNl dHRpbmcgaG9zdGlkOiAweGQ3NmI4YTdiLgpFbnRyb3B5IGhhcnZlc3Rpbmc6IGludGVycnVw dHMgZXRoZXJuZXQgcG9pbnRfdG9fcG9pbnQgc3dpLgpTdGFydGluZyBmaWxlIHN5c3RlbSBj aGVja3M6Ci9kZXYvYWRhMHAzOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tT Ci9kZXYvYWRhMHAzOiBjbGVhbiwgMTYzNjM3OTUgZnJlZSAoNjUwMTkgZnJhZ3MsIDIwMzcz NDcgYmxvY2tzLCAwLjMlIGZyYWdtZW50YXRpb24pCi9kZXYvYWRhMHA0OiBGSUxFIFNZU1RF TSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWRhMHA0OiBjbGVhbiwgMzI2Mjg5NzIg ZnJlZSAoMjY2NjggZnJhZ3MsIDQwNzUyODggYmxvY2tzLCAwLjElIGZyYWdtZW50YXRpb24p Ck1vdW50aW5nIGxvY2FsIGZpbGUgc3lzdGVtczouCldyaXRpbmcgZW50cm9weSBmaWxlOi4K U2V0dGluZyBob3N0bmFtZTogbmFjaHRzY2hhdHRlbi5vcmtsYW4uZGUuCndsYW4wOiBFdGhl cm5ldCBhZGRyZXNzOiAwMDoyNDpkNzo5MTpiNTo0NApTdGFydGluZyB3cGFfc3VwcGxpY2Fu dC4KaXduNjAwMGZ3OiBjb3VsZCBub3QgbG9hZCBmaXJtd2FyZSBpbWFnZSwgZXJyb3IgMgpp d24wOiBpd25fcmVhZF9maXJtd2FyZTogY291bGQgbm90IHJlYWQgZmlybXdhcmUgaXduNjAw MGZ3Cml3bjA6IGl3bl9pbml0X2xvY2tlZDogY291bGQgbm90IHJlYWQgZmlybXdhcmUsIGVy cm9yIDIyClN0YXJ0aW5nIE5ldHdvcms6IGxvMCBlbTAgaXduMC4KbG8wOiBmbGFncz04MDQ5 PFVQLExPT1BCQUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYzODQKCW9w dGlvbnM9NjAwMDAzPFJYQ1NVTSxUWENTVU0sUlhDU1VNX0lQVjYsVFhDU1VNX0lQVjY+Cglp bmV0NiA6OjEgcHJlZml4bGVuIDEyOCAKCWluZXQ2IGZlODA6OjElbG8wIHByZWZpeGxlbiA2 NCBzY29wZWlkIDB4MyAKCWluZXQgMTI3LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAwMCAKCW5k NiBvcHRpb25zPTIxPFBFUkZPUk1OVUQsQVVUT19MSU5LTE9DQUw+CmVtMDogZmxhZ3M9OGMw MjxCUk9BRENBU1QsT0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1 MDAKCW9wdGlvbnM9NDIxOWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lO RyxWTEFOX0hXQ1NVTSxUU080LFdPTF9NQUdJQyxWTEFOX0hXVFNPPgoJZXRoZXIgZjA6ZGU6 ZjE6NDY6MWI6OGMKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRP X0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0dXM6IG5vIGNh cnJpZXIKaXduMDogZmxhZ3M9ODgwMzxVUCxCUk9BRENBU1QsU0lNUExFWCxNVUxUSUNBU1Q+ IG1ldHJpYyAwIG10dSAyMjkwCglldGhlciAwMDoyNDpkNzo5MTpiNTo0NAoJbmQ2IG9wdGlv bnM9MjE8UEVSRk9STU5VRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBJRUVFIDgwMi4xMSBX aXJlbGVzcyBFdGhlcm5ldCBhdXRvc2VsZWN0IG1vZGUgMTFiCglzdGF0dXM6IGFzc29jaWF0 ZWQKU3RhcnRpbmcgZGV2ZC4KU3RhcnRpbmcgTmV0d29yazogZW0wLgplbTA6IGZsYWdzPThj MDI8QlJPQURDQVNULE9BQ1RJVkUsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAx NTAwCglvcHRpb25zPTQyMTliPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJ TkcsVkxBTl9IV0NTVU0sVFNPNCxXT0xfTUFHSUMsVkxBTl9IV1RTTz4KCWV0aGVyIGYwOmRl OmYxOjQ2OjFiOjhjCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVU T19MSU5LTE9DQUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdAoJc3RhdHVzOiBubyBj YXJyaWVyCmtsZGxvYWQ6IGNhbid0IGxvYWQgbmdfdWJ0OiBObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5CmtsZGxvYWQ6IGNhbid0IGxvYWQgbmdfdWJ0OiBObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5CmFkZCBuZXQgZmU4MDo6OiBnYXRld2F5IDo6MQphZGQgbmV0IGZmMDI6OjogZ2F0 ZXdheSA6OjEKYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDogZ2F0ZXdheSA6OjEKYWRkIG5ldCA6 OjAuMC4wLjA6IGdhdGV3YXkgOjoxCldhaXRpbmcgMzBzIGZvciB0aGUgZGVmYXVsdCByb3V0 ZSBpbnRlcmZhY2U6IC4uLi4uKG5vIGNhcnJpZXIpCkVMRiBsZGNvbmZpZyBwYXRoOiAvbGli IC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAvdXNyL2xvY2FsL2xpYiAvdXNyL2xvY2FsL2xp Yi9nY2M0OCAvdXNyL2xvY2FsL2xpYi9ncmFwaHZpeiAvdXNyL2xvY2FsL2xpYi9uc3MgL3Vz ci9sb2NhbC9saWIvb3BlbmNvbGxhZGEgL3Vzci9sb2NhbC9saWIvcHRoIC91c3IvbG9jYWwv bGliL3F0NCAvdXNyL2xvY2FsL2xpYi9xdGNyZWF0b3IgL3Vzci9sb2NhbC9sbHZtMzMvbGli IC91c3IvbG9jYWwvbGx2bTM0L2xpYiAvdXNyL2xvY2FsL2xsdm0zNS9saWIKMzItYml0IGNv bXBhdGliaWxpdHkgbGRjb25maWcgcGF0aDogL3Vzci9saWIzMgpDcmVhdGluZyBhbmQvb3Ig dHJpbW1pbmcgbG9nIGZpbGVzLgpTdGFydGluZyBzeXNsb2dkLgpObyBjb3JlIGR1bXBzIGZv dW5kLgpDbGVhcmluZyAvdG1wIChYIHJlbGF0ZWQpLgpOb3YgMTEgMjM6MDg6MTkgbmFjaHRz Y2hhdHRlbiB3cGFfc3VwcGxpY2FudFs1NzVdOiBpb2N0bFtTSU9DUzgwMjExLCBvcD0xMDMs IHZhbD0wLCBhcmdfbGVuPTEyOF06IERldmljZSBub3QgY29uZmlndXJlZApSZWNvdmVyaW5n IHZpIGVkaXRvciBzZXNzaW9uczouClN0YXJ0aW5nIGRidXMuClN0YXJ0aW5nIGxvb2xlcmQu ClVwZGF0aW5nIG1vdGQ6LgpNb3VudGluZyBsYXRlIGZpbGUgc3lzdGVtczouClN0YXJ0aW5n IG50cGQuClN0YXJ0aW5nIHBvd2VyZC4KQ29uZmlndXJpbmcgc3lzY29uczogYmxhbmt0aW1l LgpQZXJmb3JtaW5nIHNhbml0eSBjaGVjayBvbiBzc2hkIGNvbmZpZ3VyYXRpb24uClN0YXJ0 aW5nIHNzaGQuClN0YXJ0aW5nIHNlbmRtYWlsX3N1Ym1pdC4KU3RhcnRpbmcgc2VuZG1haWxf bXNwX3F1ZXVlLgpTdGFydGluZyBjcm9uLgpzeXNjdGw6IHVua25vd24gb2lkICdjb21wYXQu bGludXgub3NyZWxlYXNlJyBhdCBsaW5lIDIxOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 ClN0YXJ0aW5nIGRlZmF1bHQgbW91c2VkLgpTdGFydGluZyBiYWNrZ3JvdW5kIGZpbGUgc3lz dGVtIGNoZWNrcyBpbiA2MCBzZWNvbmRzLgoKVHVlIE5vdiAxMSAyMzowODoyMSBDRVQgMjAx NApOb3YgMTEgMjM6MDg6MjEgbmFjaHRzY2hhdHRlbiBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQg MiB0aW1lcwpOb3YgMTEgMjM6MDg6MjIgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIz MF06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUxLnB0Yi5kZQpOb3YgMTEgMjM6MDg6 MjIgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3QgZm91 bmQ6IHB0YnRpbWUyLnB0Yi5kZQpOb3YgMTEgMjM6MDg6MjIgbmFjaHRzY2hhdHRlbiBudHBk X2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUzLnB0Yi5kZQpO b3YgMTEgMjM6MDg6MjIgbmFjaHRzY2hhdHRlbiB3cGFfc3VwcGxpY2FudFs1NzVdOiBpb2N0 bFtTSU9DUzgwMjExLCBvcD0xMDMsIHZhbD0wLCBhcmdfbGVuPTEyOF06IERldmljZSBub3Qg Y29uZmlndXJlZApOb3YgMTEgMjM6MDg6MzggbmFjaHRzY2hhdHRlbiBsYXN0IG1lc3NhZ2Ug cmVwZWF0ZWQgMTUgdGltZXMKTm92IDExIDIzOjA4OjM4IG5hY2h0c2NoYXR0ZW4gbG9naW46 IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYwCk5vdiAxMSAyMzowODozOSBuYWNodHNjaGF0 dGVuIHdwYV9zdXBwbGljYW50WzU3NV06IGlvY3RsW1NJT0NTODAyMTEsIG9wPTEwMywgdmFs PTAsIGFyZ19sZW49MTI4XTogRGV2aWNlIG5vdCBjb25maWd1cmVkCk5vdiAxMSAyMzowOTow MyBuYWNodHNjaGF0dGVuIGxhc3QgbWVzc2FnZSByZXBlYXRlZCAyNCB0aW1lcwpOb3YgMTEg MjM6MDk6MDQgbmFjaHRzY2hhdHRlbiBzaHV0ZG93bjogcmVib290IGJ5IHJvb3Q6IApTdG9w cGluZyBtb3VzZWQuCldhaXRpbmcgZm9yIFBJRFM6IDEyNTkuClN0b3BwaW5nIGNyb24uCldh aXRpbmcgZm9yIFBJRFM6IDEyNDIuClN0b3BwaW5nIHNzaGQuCldhaXRpbmcgZm9yIFBJRFM6 IDEyMzIuCk5vdiAxMSAyMzowOTowNCBuYWNodHNjaGF0dGVuIHdwYV9zdXBwbGljYW50WzU3 NV06IGlvY3RsW1NJT0NTODAyMTEsIG9wPTEwMywgdmFsPTAsIGFyZ19sZW49MTI4XTogRGV2 aWNlIG5vdCBjb25maWd1cmVkClN0b3BwaW5nIHBvd2VyZC4KV2FpdGluZyBmb3IgUElEUzog MTIwNC4KU3RvcHBpbmcgbnRwZC4KV2FpdGluZyBmb3IgUElEUzogMTIwMS4KU3RvcHBpbmcg ZGV2ZC4KV2FpdGluZyBmb3IgUElEUzogODg1LgpXcml0aW5nIGVudHJvcHkgZmlsZTouCi4K VGVybWluYXRlZApOb3YgMTEgMjM6MDk6MDUgbmFjaHRzY2hhdHRlbiBzeXNsb2dkOiBleGl0 aW5nIG9uIHNpZ25hbCAxNQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBw cm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMp IGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5n IChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3Au Li4KU3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjEgMCAxIDAgMCBkb25lCkFs bCBidWZmZXJzIHN5bmNlZC4KVXB0aW1lOiAxbTEwcwp1c2J1czA6IENvbnRyb2xsZXIgc2h1 dGRvd24KdWh1YjA6IGF0IHVzYnVzMCwgcG9ydCAxLCBhZGRyIDEgKGRpc2Nvbm5lY3RlZCkK dWdlbjAuMjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMCAoZGlzY29ubmVjdGVkKQp1aHVi MjogYXQgdWh1YjAsIHBvcnQgMSwgYWRkciAyIChkaXNjb25uZWN0ZWQpCnVnZW4wLjQ6IDxD aGljb255IEVsZWN0cm9uaWNzIENvLiwgTHRkLj4gYXQgdXNidXMwIChkaXNjb25uZWN0ZWQp CnVzYnVzMDogQ29udHJvbGxlciBzaHV0ZG93biBjb21wbGV0ZQp1c2J1czE6IENvbnRyb2xs ZXIgc2h1dGRvd24KdWh1YjE6IGF0IHVzYnVzMSwgcG9ydCAxLCBhZGRyIDEgKGRpc2Nvbm5l Y3RlZCkKdWdlbjEuMjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMSAoZGlzY29ubmVjdGVk KQp1aHViMzogYXQgdWh1YjEsIHBvcnQgMSwgYWRkciAyIChkaXNjb25uZWN0ZWQpCnVzYnVz MTogQ29udHJvbGxlciBzaHV0ZG93biBjb21wbGV0ZQpSZWJvb3RpbmcuLi4KY3B1X3Jlc2V0 OiBTdG9wcGluZyBvdGhlciBDUFVzCkNvcHlyaWdodCAoYykgMTk5Mi0yMDE0IFRoZSBGcmVl QlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4 OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVu aXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBp cyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZy ZWVCU0QgMTAuMC1SRUxFQVNFLXAxMiAjMDogVHVlIE5vdiAgNCAwNTowNzoxNyBVVEMgMjAx NAogICAgcm9vdEBhbWQ2NC1idWlsZGVyLmRhZW1vbm9sb2d5Lm5ldDovdXNyL29iai91c3Iv c3JjL3N5cy9HRU5FUklDIGFtZDY0CkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAzLjMgKHRhZ3Mv UkVMRUFTRV8zMy9maW5hbCAxODM1MDIpIDIwMTMwNjEwCkNQVTogSW50ZWwoUikgQ29yZShU TSkgaTUgQ1BVICAgICAgIE0gNTYwICBAIDIuNjdHSHogKDI2NjAuMDctTUh6IEs4LWNsYXNz IENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDIwNjU1ICBGYW1pbHkg PSAweDYgIE1vZGVsID0gMHgyNSAgU3RlcHBpbmcgPSA1CiAgRmVhdHVyZXM9MHhiZmViZmJm ZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdF LE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0Uy LFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4MjlhZTNmZjxTU0UzLFBDTE1VTFFEUSxE VEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00s UENJRCxTU0U0LjEsU1NFNC4yLFBPUENOVCxBRVNOST4KICBBTUQgRmVhdHVyZXM9MHgyODEw MDgwMDxTWVNDQUxMLE5YLFJEVFNDUCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgog IFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBt ZW1vcnkgID0gNDI5NDk2NzI5NiAoNDA5NiBNQikKYXZhaWwgbWVtb3J5ID0gMzk2MjgzNDk0 NCAoMzc3OSBNQikKQUNQSSBBUElDIFRhYmxlOiA8TEVOT1ZPIFRQLTZJICAgPgpGcmVlQlNE L1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA0IENQVXMKRnJlZUJTRC9T TVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKSB4IDIgU01UIHRocmVhZHMKIGNwdTAgKEJT UCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCiBjcHUyIChBUCk6IEFQ SUMgSUQ6ICA0CiBjcHUzIChBUCk6IEFQSUMgSUQ6ICA1CmlvYXBpYzA6IENoYW5naW5nIEFQ SUMgSUQgdG8gMQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJv YXJkCmtiZDEgYXQga2JkbXV4MApyYW5kb206IDxTb2Z0d2FyZSwgWWFycm93PiBpbml0aWFs aXplZAphY3BpMDogPExFTk9WTyBUUC02ST4gb24gbW90aGVyYm9hcmQKYWNwaV9lYzA6IDxF bWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxMSwgRUNEVD4gcG9ydCAweDYyLDB4NjYgb24g YWNwaTAKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmFjcGkwOiByZXNlcnZhdGlvbiBv ZiAwLCBhMDAwMCAoMykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAsIGJm ZjAwMDAwICgzKSBmYWlsZWQKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxOiA8QUNQ SSBDUFU+IG9uIGFjcGkwCmNwdTI6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MzogPEFDUEkg Q1BVPiBvbiBhY3BpMAphdHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MyBpcnEg MCBvbiBhY3BpMApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1 YWxpdHkgMApFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxp dHkgMTAwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVk MDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5 IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVyICJIUEVUIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA1NTAKRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQyIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQ0IiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBv cnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwCkV2ZW50IHRpbWVyICJSVEMiIGZyZXF1ZW5j eSAzMjc2OCBIeiBxdWFsaXR5IDAKVGltZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVlbmN5 IDM1Nzk1NDUgSHogcXVhbGl0eSA4NTAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQg My41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3BpMAphY3BpX2xpZDA6IDxD b250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRvbjA6IDxTbGVl cCBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFj cGkwCnBjaTI1NTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIEhvc3Qt UENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBk ZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKdmdhcGNp MDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHgyMDAwLTB4MjA3ZiBtZW0gMHhj YzAwMDAwMC0weGNjZmZmZmZmLDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiwweGNlMDAwMDAwLTB4 Y2ZmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMQp2Z2FwY2kwOiBCb290IHZp ZGVvIGRldmljZQpoZGFjMDogPE5WSURJQSAoMHgwYmUzKSBIREEgQ29udHJvbGxlcj4gbWVt IDB4Y2RlZmMwMDAtMHhjZGVmZmZmZiBhdCBkZXZpY2UgMC4xIG9uIHBjaTEKcGNpMDogPHNp bXBsZSBjb21tcz4gYXQgZGV2aWNlIDIyLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWFydDI6 IDw1IFNlcmllcy8zNDAwIFNlcmllcyBDaGlwc2V0IEtUIENvbnRyb2xsZXI+IHBvcnQgMHgx ODAwLTB4MTgwNyBtZW0gMHhmMjQyNDAwMC0weGYyNDI0ZmZmIGlycSAxNyBhdCBkZXZpY2Ug MjIuMyBvbiBwY2kwCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlv biA3LjMuOD4gcG9ydCAweDE4MjAtMHgxODNmIG1lbSAweGYyNDAwMDAwLTB4ZjI0MWZmZmYs MHhmMjQyNTAwMC0weGYyNDI1ZmZmIGlycSAyMCBhdCBkZXZpY2UgMjUuMCBvbiBwY2kwCmVt MDogVXNpbmcgYW4gTVNJIGludGVycnVwdAplbTA6IEV0aGVybmV0IGFkZHJlc3M6IGYwOmRl OmYxOjQ2OjFiOjhjCmVoY2kwOiA8SW50ZWwgUENIIFVTQiAyLjAgY29udHJvbGxlciBVU0It Qj4gbWVtIDB4ZjI0MjgwMDAtMHhmMjQyODNmZiBpcnEgMjMgYXQgZGV2aWNlIDI2LjAgb24g cGNpMAp1c2J1czA6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMwIG9uIGVoY2kwCmhkYWMxOiA8 SW50ZWwgNSBTZXJpZXMvMzQwMCBTZXJpZXMgSERBIENvbnRyb2xsZXI+IG1lbSAweGYyNDIw MDAwLTB4ZjI0MjNmZmYgaXJxIDE3IGF0IGRldmljZSAyNy4wIG9uIHBjaTAKcGNpYjM6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMjAgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2ky OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAyMSBhdCBkZXZpY2UgMjguMSBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI0Cml3bjA6IDxJbnRlbCBDZW50cmlubyBVbHRpbWF0ZS1OIDYzMDA+IG1lbSAweGYy MDAwMDAwLTB4ZjIwMDFmZmYgaXJxIDE3IGF0IGRldmljZSAwLjAgb24gcGNpMwpwY2liNTog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAyMCBhdCBkZXZpY2UgMjguNCBvbiBwY2kwCnBj aTEzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpzZGhjaV9wY2kwOiA8UklDT0ggU0Q+IG1l bSAweGYyMTAwMDAwLTB4ZjIxMDAwZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMTMK c2RoY2lfcGNpMDogMSBzbG90KHMpIGFsbG9jYXRlZApwY2kxMzogPGJhc2UgcGVyaXBoZXJh bD4gYXQgZGV2aWNlIDAuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQplaGNpMTogPEludGVsIFBD SCBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUE+IG1lbSAweGYyNDI4NDAwLTB4ZjI0Mjg3ZmYg aXJxIDE5IGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdXNidXMxOiBFSENJIHZlcnNpb24gMS4w CnVzYnVzMSBvbiBlaGNpMQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzMC4wIG9uIHBjaTAKcGNpMTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CmlzYWIwOiA8 UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+ IG9uIGlzYWIwCmFoY2kwOiA8SW50ZWwgNSBTZXJpZXMvMzQwMCBTZXJpZXMgQUhDSSBTQVRB IGNvbnRyb2xsZXI+IHBvcnQgMHgxODE4LTB4MTgxZiwweDE4MGMtMHgxODBmLDB4MTgxMC0w eDE4MTcsMHgxODA4LTB4MTgwYiwweDE4NDAtMHgxODVmIG1lbSAweGYyNDI3MDAwLTB4ZjI0 Mjc3ZmYgaXJxIDE2IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYWhjaTA6IEFIQ0kgdjEuMzAg d2l0aCA2IDNHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgbm90IHN1cHBvcnRlZAphaGNp Y2gwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTAKYWhjaWNoMTogPEFI Q0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDQ6IDxBSENJIGNoYW5u ZWw+IGF0IGNoYW5uZWwgNCBvbiBhaGNpMAphaGNpY2g1OiA8QUhDSSBjaGFubmVsPiBhdCBj aGFubmVsIDUgb24gYWhjaTAKYWhjaWVtMDogPEFIQ0kgZW5jbG9zdXJlIG1hbmFnZW1lbnQg YnJpZGdlPiBvbiBhaGNpMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAz MS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxkYXNwPiBhdCBkZXZpY2UgMzEuNiAo bm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAK YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQg aXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAK a2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiA8UFMvMiBNb3Vz ZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogbW9kZWwg R2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMApiYXR0ZXJ5MDogPEFDUEkgQ29udHJv bCBNZXRob2QgQmF0dGVyeT4gb24gYWNwaTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9u IGFjcGkwCmFjcGlfaWJtMDogPElCTSBUaGlua1BhZCBBQ1BJIEV4dHJhcz4gb24gYWNwaTAK b3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhkMDAwMC0weGQwZmZmLDB4ZDEw MDAtMHhkMWZmZiwweGRkMDAwLTB4ZGZmZmYsMHhlMDAwMC0weGVmZmZmIG9uIGlzYTAKc2Mw OiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdB PiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCnBw YzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmVzdDA6IDxFbmhhbmNlZCBTcGVl ZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAKZXN0MTogPEVuaGFuY2VkIFNwZWVk U3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MQplc3QyOiA8RW5oYW5jZWQgU3BlZWRT dGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUyCmVzdDM6IDxFbmhhbmNlZCBTcGVlZFN0 ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTMKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkg MTAuMDAwIG1zZWMKaGRhY2MwOiA8TlZJRElBIEdUMjF4IEhEQSBDT0RFQz4gYXQgY2FkIDAg b24gaGRhYzAKaGRhYTA6IDxOVklESUEgR1QyMXggQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0 IG5pZCAxIG9uIGhkYWNjMApwY20wOiA8TlZJRElBIEdUMjF4IChIRE1JL0RQIDhjaCk+IGF0 IG5pZCA1IG9uIGhkYWEwCmhkYWNjMTogPE5WSURJQSBHVDIxeCBIREEgQ09ERUM+IGF0IGNh ZCAxIG9uIGhkYWMwCmhkYWExOiA8TlZJRElBIEdUMjF4IEF1ZGlvIEZ1bmN0aW9uIEdyb3Vw PiBhdCBuaWQgMSBvbiBoZGFjYzEKcGNtMTogPE5WSURJQSBHVDIxeCAoSERNSS9EUCA4Y2gp PiBhdCBuaWQgNSBvbiBoZGFhMQpoZGFjYzI6IDxOVklESUEgR1QyMXggSERBIENPREVDPiBh dCBjYWQgMiBvbiBoZGFjMApoZGFhMjogPE5WSURJQSBHVDIxeCBBdWRpbyBGdW5jdGlvbiBH cm91cD4gYXQgbmlkIDEgb24gaGRhY2MyCnBjbTI6IDxOVklESUEgR1QyMXggKEhETUkvRFAg OGNoKT4gYXQgbmlkIDUgb24gaGRhYTIKaGRhY2MzOiA8TlZJRElBIEdUMjF4IEhEQSBDT0RF Qz4gYXQgY2FkIDMgb24gaGRhYzAKaGRhYTM6IDxOVklESUEgR1QyMXggQXVkaW8gRnVuY3Rp b24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMwpwY20zOiA8TlZJRElBIEdUMjF4IChIRE1J L0RQIDhjaCk+IGF0IG5pZCA1IG9uIGhkYWEzCmhkYWNjNDogPENvbmV4YW50IENYMjA1ODUg SERBIENPREVDPiBhdCBjYWQgMCBvbiBoZGFjMQpoZGFhNDogPENvbmV4YW50IENYMjA1ODUg QXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjNApwY200OiA8Q29uZXhh bnQgQ1gyMDU4NSAoUmlnaHQgQW5hbG9nKT4gYXQgbmlkIDI1IGFuZCAyNyBvbiBoZGFhNApw Y201OiA8Q29uZXhhbnQgQ1gyMDU4NSAoSW50ZXJuYWwgQW5hbG9nKT4gYXQgbmlkIDMxIGFu ZCAzNSBvbiBoZGFhNApyYW5kb206IHVuYmxvY2tpbmcgZGV2aWNlLgp1c2J1czA6IDQ4ME1i cHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czE6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0Ig djIuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIEVIQ0kgcm9v dCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdl bjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBj bGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnNlczAgYXQgYWhj aWVtMCBidXMgMCBzY2J1czQgdGFyZ2V0IDAgbHVuIDAKc2VzMDogPEFIQ0kgU0dQSU8gRW5j bG9zdXJlIDEuMDAgMDAwMT4gU0VNQiBTLUUtUyAyLjAwIGRldmljZQpzZXMwOiBTRU1CIFNF UyBEZXZpY2UKYWRhMCBhdCBhaGNpY2gwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAph ZGEwOiA8V0RDIFdEMzIwMEJFVlQtMDhBMjNUMSAwMi4wMUEwMj4gQVRBLTggU0FUQSAyLngg ZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1iZXIgV0QtV1hEMUExMTU0Mjc1CmFkYTA6IDMwMC4w MDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEw OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMDogMzA1MjQ1TUIgKDYyNTE0MjQ0OCA1 MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGEwOiBQcmV2aW91c2x5IHdh cyBrbm93biBhcyBhZDQKY2QwIGF0IGFoY2ljaDEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1 biAwCmNkMDogPE9wdGlhcmMgRFZEIFJXIEFELTc5MzBIIDEuRDE+IFJlbW92YWJsZSBDRC1S T00gU0NTSS0wIGRldmljZSAKY2QwOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54 LCBVRE1BNSwgQVRBUEkgMTJieXRlcywgUElPIDgxOTJieXRlcykKY2QwOiBBdHRlbXB0IHRv IHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNl bnQgLSB0cmF5IGNsb3NlZApOZXR2c2MgaW5pdGlhbGl6aW5nLi4uIFNNUDogQVAgQ1BVICMx IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMyBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIgTGF1 bmNoZWQhClRpbWVjb3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kgMTMzMDAzNDI0NyBIeiBx dWFsaXR5IDEwMDAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxIHVzYnVzMAp1aHVi MDogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6IDMgcG9y dHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBm b3I6IHVzYnVzMSB1c2J1czAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxIHVzYnVz MAp1Z2VuMS4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMxCnVodWIyOiA8dmVuZG9yIDB4 ODA4NyBwcm9kdWN0IDB4MDAyMCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDI+ IG9uIHVzYnVzMQp1Z2VuMC4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMwCnVodWIzOiA8 dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyMCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjAw LCBhZGRyIDI+IG9uIHVzYnVzMAp1aHViMzogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxIHVzYnVzMAp1aHVi MjogOCBwb3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWdlbjAuMzogPEJy b2FkY29tIENvcnA+IGF0IHVzYnVzMApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czAK dWdlbjAuNDogPENoaWNvbnkgRWxlY3Ryb25pY3MgQ28uLCBMdGQuPiBhdCB1c2J1czAKVHJ5 aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZGEwcDMgW3J3XS4uLgp1Z2VuMC4z OiA8QnJvYWRjb20gQ29ycD4gYXQgdXNidXMwIChkaXNjb25uZWN0ZWQpClNldHRpbmcgaG9z dHV1aWQ6IDgxOTA1NDBkLTE1NTEtY2IxMS1hMzRmLWRlMmI2MzIzYTMxZi4KU2V0dGluZyBo b3N0aWQ6IDB4ZDc2YjhhN2IuCkVudHJvcHkgaGFydmVzdGluZzogaW50ZXJydXB0cyBldGhl cm5ldCBwb2ludF90b19wb2ludCBzd2kuClN0YXJ0aW5nIGZpbGUgc3lzdGVtIGNoZWNrczoK L2Rldi9hZGEwcDM6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9h ZGEwcDM6IGNsZWFuLCAxNjM2Mzc4OCBmcmVlICg2NTAyMCBmcmFncywgMjAzNzM0NiBibG9j a3MsIDAuMyUgZnJhZ21lbnRhdGlvbikKL2Rldi9hZGEwcDQ6IEZJTEUgU1lTVEVNIENMRUFO OyBTS0lQUElORyBDSEVDS1MKL2Rldi9hZGEwcDQ6IGNsZWFuLCAzMjYyODk3MiBmcmVlICgy NjY2OCBmcmFncywgNDA3NTI4OCBibG9ja3MsIDAuMSUgZnJhZ21lbnRhdGlvbikKTW91bnRp bmcgbG9jYWwgZmlsZSBzeXN0ZW1zOi4KV3JpdGluZyBlbnRyb3B5IGZpbGU6LgpTZXR0aW5n IGhvc3RuYW1lOiBuYWNodHNjaGF0dGVuLm9ya2xhbi5kZS4Kd2xhbjA6IEV0aGVybmV0IGFk ZHJlc3M6IDAwOjI0OmQ3OjkxOmI1OjQ0ClN0YXJ0aW5nIHdwYV9zdXBwbGljYW50Lgppd242 MDAwZnc6IGNvdWxkIG5vdCBsb2FkIGZpcm13YXJlIGltYWdlLCBlcnJvciAyCml3bjA6IGl3 bl9yZWFkX2Zpcm13YXJlOiBjb3VsZCBub3QgcmVhZCBmaXJtd2FyZSBpd242MDAwZncKaXdu MDogaXduX2luaXRfbG9ja2VkOiBjb3VsZCBub3QgcmVhZCBmaXJtd2FyZSwgZXJyb3IgMjIK U3RhcnRpbmcgTmV0d29yazogbG8wIGVtMCBpd24wLgpsbzA6IGZsYWdzPTgwNDk8VVAsTE9P UEJBQ0ssUlVOTklORyxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNjM4NAoJb3B0aW9ucz02 MDAwMDM8UlhDU1VNLFRYQ1NVTSxSWENTVU1fSVBWNixUWENTVU1fSVBWNj4KCWluZXQ2IDo6 MSBwcmVmaXhsZW4gMTI4IAoJaW5ldDYgZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3Bl aWQgMHgzIAoJaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAweGZmMDAwMDAwIAoJbmQ2IG9wdGlv bnM9MjE8UEVSRk9STU5VRCxBVVRPX0xJTktMT0NBTD4KZW0wOiBmbGFncz04YzAyPEJST0FE Q0FTVCxPQUNUSVZFLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0 aW9ucz00MjE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5f SFdDU1VNLFRTTzQsV09MX01BR0lDLFZMQU5fSFdUU08+CglldGhlciBmMDpkZTpmMTo0Njox Yjo4YwoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xP Q0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QKCXN0YXR1czogbm8gY2Fycmllcgpp d24wOiBmbGFncz04ODAzPFVQLEJST0FEQ0FTVCxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmlj IDAgbXR1IDIyOTAKCWV0aGVyIDAwOjI0OmQ3OjkxOmI1OjQ0CgluZDYgb3B0aW9ucz0yMTxQ RVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IElFRUUgODAyLjExIFdpcmVsZXNz IEV0aGVybmV0IGF1dG9zZWxlY3QgbW9kZSAxMWIKCXN0YXR1czogYXNzb2NpYXRlZApTdGFy dGluZyBkZXZkLgpTdGFydGluZyBOZXR3b3JrOiBlbTAuCmVtMDogZmxhZ3M9OGMwMjxCUk9B RENBU1QsT0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9w dGlvbnM9NDIxOWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxWTEFO X0hXQ1NVTSxUU080LFdPTF9NQUdJQyxWTEFOX0hXVFNPPgoJZXRoZXIgZjA6ZGU6ZjE6NDY6 MWI6OGMKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktM T0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0dXM6IG5vIGNhcnJpZXIK a2xkbG9hZDogY2FuJ3QgbG9hZCBuZ191YnQ6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkK a2xkbG9hZDogY2FuJ3QgbG9hZCBuZ191YnQ6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkK YWRkIG5ldCBmZTgwOjo6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmYwMjo6OiBnYXRld2F5IDo6 MQphZGQgbmV0IDo6ZmZmZjowLjAuMC4wOiBnYXRld2F5IDo6MQphZGQgbmV0IDo6MC4wLjAu MDogZ2F0ZXdheSA6OjEKV2FpdGluZyAzMHMgZm9yIHRoZSBkZWZhdWx0IHJvdXRlIGludGVy ZmFjZTogLi4uLi4obm8gY2FycmllcikKRUxGIGxkY29uZmlnIHBhdGg6IC9saWIgL3Vzci9s aWIgL3Vzci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGliL2djYzQ4 IC91c3IvbG9jYWwvbGliL2dyYXBodml6IC91c3IvbG9jYWwvbGliL25zcyAvdXNyL2xvY2Fs L2xpYi9vcGVuY29sbGFkYSAvdXNyL2xvY2FsL2xpYi9wdGggL3Vzci9sb2NhbC9saWIvcXQ0 IC91c3IvbG9jYWwvbGliL3F0Y3JlYXRvciAvdXNyL2xvY2FsL2xsdm0zMy9saWIgL3Vzci9s b2NhbC9sbHZtMzQvbGliIC91c3IvbG9jYWwvbGx2bTM1L2xpYgozMi1iaXQgY29tcGF0aWJp bGl0eSBsZGNvbmZpZyBwYXRoOiAvdXNyL2xpYjMyCkNyZWF0aW5nIGFuZC9vciB0cmltbWlu ZyBsb2cgZmlsZXMuClN0YXJ0aW5nIHN5c2xvZ2QuCk5vIGNvcmUgZHVtcHMgZm91bmQuCk5v diAxMSAyMzoxMDowMCBuYWNodHNjaGF0dGVuIHdwYV9zdXBwbGljYW50WzU3NV06IGlvY3Rs W1NJT0NTODAyMTEsIG9wPTEwMywgdmFsPTAsIGFyZ19sZW49MTI4XTogRGV2aWNlIG5vdCBj b25maWd1cmVkCkNsZWFyaW5nIC90bXAgKFggcmVsYXRlZCkuClJlY292ZXJpbmcgdmkgZWRp dG9yIHNlc3Npb25zOi4KU3RhcnRpbmcgZGJ1cy4KU3RhcnRpbmcgbG9vbGVyZC4KVXBkYXRp bmcgbW90ZDouCk1vdW50aW5nIGxhdGUgZmlsZSBzeXN0ZW1zOi4KU3RhcnRpbmcgbnRwZC4K U3RhcnRpbmcgcG93ZXJkLgpDb25maWd1cmluZyBzeXNjb25zOiBibGFua3RpbWUuClBlcmZv cm1pbmcgc2FuaXR5IGNoZWNrIG9uIHNzaGQgY29uZmlndXJhdGlvbi4KU3RhcnRpbmcgc3No ZC4KU3RhcnRpbmcgc2VuZG1haWxfc3VibWl0LgpTdGFydGluZyBzZW5kbWFpbF9tc3BfcXVl dWUuClN0YXJ0aW5nIGNyb24uClN0YXJ0aW5nIGRlZmF1bHQgbW91c2VkLgpTdGFydGluZyBi YWNrZ3JvdW5kIGZpbGUgc3lzdGVtIGNoZWNrcyBpbiA2MCBzZWNvbmRzLgoKVHVlIE5vdiAx MSAyMzoxMDowMiBDRVQgMjAxNApOb3YgMTEgMjM6MTA6MDIgbmFjaHRzY2hhdHRlbiBsYXN0 IG1lc3NhZ2UgcmVwZWF0ZWQgMiB0aW1lcwpOb3YgMTEgMjM6MTA6MDMgbmFjaHRzY2hhdHRl biBudHBkX2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUxLnB0 Yi5kZQpOb3YgMTEgMjM6MTA6MDMgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIzMF06 IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUyLnB0Yi5kZQpOb3YgMTEgMjM6MTA6MDMg bmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3QgZm91bmQ6 IHB0YnRpbWUzLnB0Yi5kZQpOb3YgMTEgMjM6MTA6MDMgbmFjaHRzY2hhdHRlbiB3cGFfc3Vw cGxpY2FudFs1NzVdOiBpb2N0bFtTSU9DUzgwMjExLCBvcD0xMDMsIHZhbD0wLCBhcmdfbGVu PTEyOF06IERldmljZSBub3QgY29uZmlndXJlZApOb3YgMTEgMjM6MTA6MzMgbmFjaHRzY2hh dHRlbiBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgMjkgdGltZXMKTm92IDExIDIzOjEwOjM0IG5h Y2h0c2NoYXR0ZW4gbG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYwCk5vdiAxMSAy MzoxMDozNCBuYWNodHNjaGF0dGVuIHdwYV9zdXBwbGljYW50WzU3NV06IGlvY3RsW1NJT0NT ODAyMTEsIG9wPTEwMywgdmFsPTAsIGFyZ19sZW49MTI4XTogRGV2aWNlIG5vdCBjb25maWd1 cmVkCk5vdiAxMSAyMzoxMTowNCBuYWNodHNjaGF0dGVuIGxhc3QgbWVzc2FnZSByZXBlYXRl ZCAyOSB0aW1lcwpOb3YgMTEgMjM6MTE6MDUgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNb MTIzMF06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUxLnB0Yi5kZQpOb3YgMTEgMjM6 MTE6MDUgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3Qg Zm91bmQ6IHB0YnRpbWUyLnB0Yi5kZQpOb3YgMTEgMjM6MTE6MDUgbmFjaHRzY2hhdHRlbiBu dHBkX2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUzLnB0Yi5k ZQpOb3YgMTEgMjM6MTE6MDUgbmFjaHRzY2hhdHRlbiB3cGFfc3VwcGxpY2FudFs1NzVdOiBp b2N0bFtTSU9DUzgwMjExLCBvcD0xMDMsIHZhbD0wLCBhcmdfbGVuPTEyOF06IERldmljZSBu b3QgY29uZmlndXJlZApOb3YgMTEgMjM6MTE6MzYgbmFjaHRzY2hhdHRlbiBsYXN0IG1lc3Nh Z2UgcmVwZWF0ZWQgMzAgdGltZXMKTm92IDExIDIzOjEzOjA3IG5hY2h0c2NoYXR0ZW4gbGFz dCBtZXNzYWdlIHJlcGVhdGVkIDg5IHRpbWVzCk5vdiAxMSAyMzoxMzowNyBuYWNodHNjaGF0 dGVuIG50cGRfaW5pdHJlc1sxMjMwXTogaG9zdCBuYW1lIG5vdCBmb3VuZDogcHRidGltZTEu cHRiLmRlCk5vdiAxMSAyMzoxMzowNyBuYWNodHNjaGF0dGVuIG50cGRfaW5pdHJlc1sxMjMw XTogaG9zdCBuYW1lIG5vdCBmb3VuZDogcHRidGltZTIucHRiLmRlCk5vdiAxMSAyMzoxMzow NyBuYWNodHNjaGF0dGVuIG50cGRfaW5pdHJlc1sxMjMwXTogaG9zdCBuYW1lIG5vdCBmb3Vu ZDogcHRidGltZTMucHRiLmRlCk5vdiAxMSAyMzoxMzowOCBuYWNodHNjaGF0dGVuIHdwYV9z dXBwbGljYW50WzU3NV06IGlvY3RsW1NJT0NTODAyMTEsIG9wPTEwMywgdmFsPTAsIGFyZ19s ZW49MTI4XTogRGV2aWNlIG5vdCBjb25maWd1cmVkCk5vdiAxMSAyMzoxMzozOSBuYWNodHNj aGF0dGVuIGxhc3QgbWVzc2FnZSByZXBlYXRlZCAzMCB0aW1lcwpOb3YgMTEgMjM6MTU6NDAg bmFjaHRzY2hhdHRlbiBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgMTE5IHRpbWVzCm52aWRpYTA6 IDxOVlMgMzEwME0+IG9uIHZnYXBjaTAKdmdhcGNpMDogY2hpbGQgbnZpZGlhMCByZXF1ZXN0 ZWQgcGNpX2VuYWJsZV9pbwp2Z2FwY2kwOiBjaGlsZCBudmlkaWEwIHJlcXVlc3RlZCBwY2lf ZW5hYmxlX2lvCkFDUEkgV2FybmluZzogXDEzNF9TQl8uUENJMC5QRUdfLlZJRF8uX0RTTTog QXJndW1lbnQgIzQgdHlwZSBtaXNtYXRjaCAtIEZvdW5kIFtCdWZmZXJdLCBBQ1BJIHJlcXVp cmVzIFtQYWNrYWdlXSAoMjAxMzA4MjMvbnNhcmd1bWVudHMtOTcpCkFDUEkgV2FybmluZzog XDEzNF9TQl8uUENJMC5QRUdfLlZJRF8uX0RTTTogQXJndW1lbnQgIzQgdHlwZSBtaXNtYXRj aCAtIEZvdW5kIFtCdWZmZXJdLCBBQ1BJIHJlcXVpcmVzIFtQYWNrYWdlXSAoMjAxMzA4MjMv bnNhcmd1bWVudHMtOTcpCkFDUEkgV2FybmluZzogXDEzNF9TQl8uUENJMC5QRUdfLlZJRF8u X0RTTTogQXJndW1lbnQgIzQgdHlwZSBtaXNtYXRjaCAtIEZvdW5kIFtCdWZmZXJdLCBBQ1BJ IHJlcXVpcmVzIFtQYWNrYWdlXSAoMjAxMzA4MjMvbnNhcmd1bWVudHMtOTcpCkFDUEkgV2Fy bmluZzogXDEzNF9TQl8uUENJMC5QRUdfLlZJRF8uX0RTTTogQXJndW1lbnQgIzQgdHlwZSBt aXNtYXRjaCAtIEZvdW5kIFtCdWZmZXJdLCBBQ1BJIHJlcXVpcmVzIFtQYWNrYWdlXSAoMjAx MzA4MjMvbnNhcmd1bWVudHMtOTcpCkFDUEkgV2FybmluZzogXDEzNF9TQl8uUENJMC5QRUdf LlZJRF8uX0RTTTogQXJndW1lbnQgIzQgdHlwZSBtaXNtYXRjaCAtIEZvdW5kIFtCdWZmZXJd LCBBQ1BJIHJlcXVpcmVzIFtQYWNrYWdlXSAoMjAxMzA4MjMvbnNhcmd1bWVudHMtOTcpCkFD UEkgV2FybmluZzogXDEzNF9TQl8uUENJMC5QRUdfLlZJRF8uX0RTTTogQXJndW1lbnQgIzQg dHlwZSBtaXNtYXRjaCAtIEZvdW5kIFtCdWZmZXJdLCBBQ1BJIHJlcXVpcmVzIFtQYWNrYWdl XSAoMjAxMzA4MjMvbnNhcmd1bWVudHMtOTcpCkFDUEkgV2FybmluZzogXDEzNF9TQl8uUENJ MC5QRUdfLlZJRF8uX0RTTTogQXJndW1lbnQgIzQgdHlwZSBtaXNtYXRjaCAtIEZvdW5kIFtC dWZmZXJdLCBBQ1BJIHJlcXVpcmVzIFtQYWNrYWdlXSAoMjAxMzA4MjMvbnNhcmd1bWVudHMt OTcpCkFDUEkgV2FybmluZzogXDEzNF9TQl8uUENJMC5QRUdfLlZJRF8uX0RTTTogQXJndW1l bnQgIzQgdHlwZSBtaXNtYXRjaCAtIEZvdW5kIFtCdWZmZXJdLCBBQ1BJIHJlcXVpcmVzIFtQ YWNrYWdlXSAoMjAxMzA4MjMvbnNhcmd1bWVudHMtOTcpCkFDUEkgV2FybmluZzogXDEzNF9T Ql8uUENJMC5QRUdfLlZJRF8uX0RTTTogQXJndW1lbnQgIzQgdHlwZSBtaXNtYXRjaCAtIEZv dW5kIFtCdWZmZXJdLCBBQ1BJIHJlcXVpcmVzIFtQYWNrYWdlXSAoMjAxMzA4MjMvbnNhcmd1 bWVudHMtOTcpCk5WUk06IEdQVSBhdCBQQ0k6MDAwMDowMTowMDogR1BVLTI5YTMyMmY0LTc0 YzktMWM5OS0zZGJiLTAwNDgzMzNhZTM0YQpOVlJNOiBYaWQgKFBDSTowMDAwOjAxOjAwKTog NTcsIEZhaWxlZCBzaG1vbyBzZGRyMyBsaW5rIHRyYWluaW5nCk5vdiAxMSAyMzoxNzowOSBu YWNodHNjaGF0dGVuIGxhc3QgbWVzc2FnZSByZXBlYXRlZCA4NiB0aW1lcwpOb3YgMTEgMjM6 MTc6MTAgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3Qg Zm91bmQ6IHB0YnRpbWUxLnB0Yi5kZQpOb3YgMTEgMjM6MTc6MTAgbmFjaHRzY2hhdHRlbiBu dHBkX2luaXRyZXNbMTIzMF06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUyLnB0Yi5k ZQpOb3YgMTEgMjM6MTc6MTAgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIzMF06IGhv c3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUzLnB0Yi5kZQpOb3YgMTEgMjM6MTc6MTAgbmFj aHRzY2hhdHRlbiB3cGFfc3VwcGxpY2FudFs1NzVdOiBpb2N0bFtTSU9DUzgwMjExLCBvcD0x MDMsIHZhbD0wLCBhcmdfbGVuPTEyOF06IERldmljZSBub3QgY29uZmlndXJlZApOb3YgMTEg MjM6MTc6NDEgbmFjaHRzY2hhdHRlbiBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgMjkgdGltZXMK Tm92IDExIDIzOjE5OjQyIG5hY2h0c2NoYXR0ZW4gbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDEx NiB0aW1lcwpOb3YgMTEgMjM6MjU6MTIgbmFjaHRzY2hhdHRlbiBsYXN0IG1lc3NhZ2UgcmVw ZWF0ZWQgMzE3IHRpbWVzCk5vdiAxMSAyMzoyNToxMyBuYWNodHNjaGF0dGVuIG50cGRfaW5p dHJlc1sxMjMwXTogaG9zdCBuYW1lIG5vdCBmb3VuZDogcHRidGltZTEucHRiLmRlCk5vdiAx MSAyMzoyNToxMyBuYWNodHNjaGF0dGVuIG50cGRfaW5pdHJlc1sxMjMwXTogaG9zdCBuYW1l IG5vdCBmb3VuZDogcHRidGltZTIucHRiLmRlCk5vdiAxMSAyMzoyNToxMyBuYWNodHNjaGF0 dGVuIG50cGRfaW5pdHJlc1sxMjMwXTogaG9zdCBuYW1lIG5vdCBmb3VuZDogcHRidGltZTMu cHRiLmRlCk5vdiAxMSAyMzoyNToxMyBuYWNodHNjaGF0dGVuIHdwYV9zdXBwbGljYW50WzU3 NV06IGlvY3RsW1NJT0NTODAyMTEsIG9wPTEwMywgdmFsPTAsIGFyZ19sZW49MTI4XTogRGV2 aWNlIG5vdCBjb25maWd1cmVkCk5vdiAxMSAyMzoyNTo0NSBuYWNodHNjaGF0dGVuIGxhc3Qg bWVzc2FnZSByZXBlYXRlZCAzMCB0aW1lcwpOb3YgMTEgMjM6MjY6MzAgbmFjaHRzY2hhdHRl biBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgNDQgdGltZXMKTm92IDExIDIzOjI2OjMxIG5hY2h0 c2NoYXR0ZW4gc2h1dGRvd246IHJlYm9vdCBieSBmbG86IApTdG9wcGluZyBtb3VzZWQuCldh aXRpbmcgZm9yIFBJRFM6IDEyNTkuClN0b3BwaW5nIGNyb24uCldhaXRpbmcgZm9yIFBJRFM6 IDEyNDIuClN0b3BwaW5nIHNzaGQuCldhaXRpbmcgZm9yIFBJRFM6IDEyMzIuClN0b3BwaW5n IHBvd2VyZC4KV2FpdGluZyBmb3IgUElEUzogMTIwNC4KU3RvcHBpbmcgbnRwZC4KV2FpdGlu ZyBmb3IgUElEUzogMTIwMS4KU3RvcHBpbmcgZGV2ZC4KV2FpdGluZyBmb3IgUElEUzogODg1 LgpXcml0aW5nIGVudHJvcHkgZmlsZTouCi4KVGVybWluYXRlZApOb3YgMTEgMjM6MjY6MzEg bmFjaHRzY2hhdHRlbiBzeXNsb2dkOiBleGl0aW5nIG9uIHNpZ25hbCAxNQpXYWl0aW5nICht YXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRv bmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFl bW9uJyB0byBzdG9wLi4uZG9uZQoKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uU3luY2luZyBkaXNrcywgdm5vZGVzIHJl bWFpbmluZy4uLjUgMiAxIDEgMCAwIGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpVcHRpbWU6 IDE2bTU3cwp1c2J1czA6IENvbnRyb2xsZXIgc2h1dGRvd24KdWh1YjA6IGF0IHVzYnVzMCwg cG9ydCAxLCBhZGRyIDEgKGRpc2Nvbm5lY3RlZCkKdWdlbjAuMjogPHZlbmRvciAweDgwODc+ IGF0IHVzYnVzMCAoZGlzY29ubmVjdGVkKQp1aHViMzogYXQgdWh1YjAsIHBvcnQgMSwgYWRk ciAyIChkaXNjb25uZWN0ZWQpCnVnZW4wLjQ6IDxDaGljb255IEVsZWN0cm9uaWNzIENvLiwg THRkLj4gYXQgdXNidXMwIChkaXNjb25uZWN0ZWQpCnVzYnVzMDogQ29udHJvbGxlciBzaHV0 ZG93biBjb21wbGV0ZQp1c2J1czE6IENvbnRyb2xsZXIgc2h1dGRvd24KdWh1YjE6IGF0IHVz YnVzMSwgcG9ydCAxLCBhZGRyIDEgKGRpc2Nvbm5lY3RlZCkKdWdlbjEuMjogPHZlbmRvciAw eDgwODc+IGF0IHVzYnVzMSAoZGlzY29ubmVjdGVkKQp1aHViMjogYXQgdWh1YjEsIHBvcnQg MSwgYWRkciAyIChkaXNjb25uZWN0ZWQpCnVzYnVzMTogQ29udHJvbGxlciBzaHV0ZG93biBj b21wbGV0ZQpSZWJvb3RpbmcuLi4KY3B1X3Jlc2V0OiBTdG9wcGluZyBvdGhlciBDUFVzCkNv cHlyaWdodCAoYykgMTk5Mi0yMDE0IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5 MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4g QWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJr IG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgMTAuMC1SRUxFQVNFLXA3ICMx OiBGcmkgQXVnICA4IDE0OjQ5OjI5IENFU1QgMjAxNAogICAgcm9vdEBuYWNodHNjaGF0dGVu Lm9ya2xhbi5kZTovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDIGFtZDY0CkZyZWVCU0Qg Y2xhbmcgdmVyc2lvbiAzLjMgKHRhZ3MvUkVMRUFTRV8zMy9maW5hbCAxODM1MDIpIDIwMTMw NjEwCmNhbid0IHJlLXVzZSBhIGxlYWYgKGh3cHN0YXRlX3ZlcmJvc2UpIQptb2R1bGVfcmVn aXN0ZXI6IG1vZHVsZSBjcHUvaWNoc3MgYWxyZWFkeSBleGlzdHMhCk1vZHVsZSBjcHUvaWNo c3MgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNwptb2R1bGVfcmVnaXN0ZXI6IG1vZHVsZSBjcHUv cG93ZXJub3cgYWxyZWFkeSBleGlzdHMhCk1vZHVsZSBjcHUvcG93ZXJub3cgZmFpbGVkIHRv IHJlZ2lzdGVyOiAxNwptb2R1bGVfcmVnaXN0ZXI6IG1vZHVsZSBjcHUvZXN0IGFscmVhZHkg ZXhpc3RzIQpNb2R1bGUgY3B1L2VzdCBmYWlsZWQgdG8gcmVnaXN0ZXI6IDE3Cm1vZHVsZV9y ZWdpc3RlcjogbW9kdWxlIGNwdS9od3BzdGF0ZSBhbHJlYWR5IGV4aXN0cyEKTW9kdWxlIGNw dS9od3BzdGF0ZSBmYWlsZWQgdG8gcmVnaXN0ZXI6IDE3Cm1vZHVsZV9yZWdpc3RlcjogbW9k dWxlIGNwdS9wNHRjYyBhbHJlYWR5IGV4aXN0cyEKTW9kdWxlIGNwdS9wNHRjYyBmYWlsZWQg dG8gcmVnaXN0ZXI6IDE3CkNQVTogSW50ZWwoUikgQ29yZShUTSkgaTUgQ1BVICAgICAgIE0g NTYwICBAIDIuNjdHSHogKDI2NjAuMDYtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAi R2VudWluZUludGVsIiAgSWQgPSAweDIwNjU1ICBGYW1pbHkgPSAweDYgIE1vZGVsID0gMHgy NSAgU3RlcHBpbmcgPSA1CiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0Uz NixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAg RmVhdHVyZXMyPTB4MjlhZTNmZjxTU0UzLFBDTE1VTFFEUSxEVEVTNjQsTU9OLERTX0NQTCxW TVgsU01YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sUENJRCxTU0U0LjEsU1NFNC4y LFBPUENOVCxBRVNOST4KICBBTUQgRmVhdHVyZXM9MHgyODEwMDgwMDxTWVNDQUxMLE5YLFJE VFNDUCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZh cmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5 NiAoNDA5NiBNQikKYXZhaWwgbWVtb3J5ID0gMzk0ODAxOTcxMiAoMzc2NSBNQikKQUNQSSBB UElDIFRhYmxlOiA8TEVOT1ZPIFRQLTZJICAgPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNz b3IgU3lzdGVtIERldGVjdGVkOiA0IENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4 IDIgY29yZShzKSB4IDIgU01UIHRocmVhZHMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBj cHUxIChBUCk6IEFQSUMgSUQ6ICAxCiBjcHUyIChBUCk6IEFQSUMgSUQ6ICA0CiBjcHUzIChB UCk6IEFQSUMgSUQ6ICA1CmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8gMQppb2FwaWMw IDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmtiZDEgYXQga2JkbXV4 MApyYW5kb206IDxTb2Z0d2FyZSwgWWFycm93PiBpbml0aWFsaXplZAphY3BpMDogPExFTk9W TyBUUC02ST4gb24gbW90aGVyYm9hcmQKYWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVy OiBHUEUgMHgxMSwgRUNEVD4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKYWNwaTA6IFBvd2Vy IEJ1dHRvbiAoZml4ZWQpCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykgZmFp bGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAsIGJmZjAwMDAwICgzKSBmYWlsZWQK Y3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNw dTI6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMAphdHRp bWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MyBpcnEgMCBvbiBhY3BpMApUaW1lY291 bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApFdmVudCB0aW1l ciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMTAwCmhwZXQwOiA8SGln aCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBv biBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxp dHkgOTUwCkV2ZW50IHRpbWVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0 eSA1NTAKRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0 eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQyIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0 eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0 eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQ0IiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0 eSA0NDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4 IG9uIGFjcGkwCkV2ZW50IHRpbWVyICJSVEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBxdWFsaXR5 IDAKVGltZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0 eSA4NTAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQg MHgxMDA4LTB4MTAwYiBvbiBhY3BpMAphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQg U3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRvbjA6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkw CnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaTI1NTogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAw eGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2li MjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAK cGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHgyMDAwLTB4MjA3ZiBtZW0gMHhjYzAwMDAwMC0weGNjZmZmZmZm LDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiwweGNlMDAwMDAwLTB4Y2ZmZmZmZmYgaXJxIDE2IGF0 IGRldmljZSAwLjAgb24gcGNpMQpudmlkaWEwOiA8TlZTIDMxMDBNPiBvbiB2Z2FwY2kwCnZn YXBjaTA6IGNoaWxkIG52aWRpYTAgcmVxdWVzdGVkIHBjaV9lbmFibGVfaW8KdmdhcGNpMDog Y2hpbGQgbnZpZGlhMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9pbwp2Z2FwY2kwOiBCb290IHZp ZGVvIGRldmljZQpoZGFjMDogPE5WSURJQSAoMHgwYmUzKSBIREEgQ29udHJvbGxlcj4gbWVt IDB4Y2RlZmMwMDAtMHhjZGVmZmZmZiBhdCBkZXZpY2UgMC4xIG9uIHBjaTEKcGNpMDogPHNp bXBsZSBjb21tcz4gYXQgZGV2aWNlIDIyLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWFydDI6 IDw1IFNlcmllcy8zNDAwIFNlcmllcyBDaGlwc2V0IEtUIENvbnRyb2xsZXI+IHBvcnQgMHgx ODAwLTB4MTgwNyBtZW0gMHhmMjQyNDAwMC0weGYyNDI0ZmZmIGlycSAxNyBhdCBkZXZpY2Ug MjIuMyBvbiBwY2kwCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlv biA3LjMuOD4gcG9ydCAweDE4MjAtMHgxODNmIG1lbSAweGYyNDAwMDAwLTB4ZjI0MWZmZmYs MHhmMjQyNTAwMC0weGYyNDI1ZmZmIGlycSAyMCBhdCBkZXZpY2UgMjUuMCBvbiBwY2kwCmVt MDogVXNpbmcgYW4gTVNJIGludGVycnVwdAplbTA6IEV0aGVybmV0IGFkZHJlc3M6IGYwOmRl OmYxOjQ2OjFiOjhjCmVoY2kwOiA8SW50ZWwgUENIIFVTQiAyLjAgY29udHJvbGxlciBVU0It Qj4gbWVtIDB4ZjI0MjgwMDAtMHhmMjQyODNmZiBpcnEgMjMgYXQgZGV2aWNlIDI2LjAgb24g cGNpMAp1c2J1czA6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMwIG9uIGVoY2kwCmhkYWMxOiA8 SW50ZWwgNSBTZXJpZXMvMzQwMCBTZXJpZXMgSERBIENvbnRyb2xsZXI+IG1lbSAweGYyNDIw MDAwLTB4ZjI0MjNmZmYgaXJxIDE3IGF0IGRldmljZSAyNy4wIG9uIHBjaTAKcGNpYjM6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMjAgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2ky OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAyMSBhdCBkZXZpY2UgMjguMSBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI0Cml3bjA6IDxJbnRlbCBDZW50cmlubyBVbHRpbWF0ZS1OIDYzMDA+IG1lbSAweGYy MDAwMDAwLTB4ZjIwMDFmZmYgaXJxIDE3IGF0IGRldmljZSAwLjAgb24gcGNpMwpwY2liNTog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAyMCBhdCBkZXZpY2UgMjguNCBvbiBwY2kwCnBj aTEzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpzZGhjaV9wY2kwOiA8UklDT0ggU0Q+IG1l bSAweGYyMTAwMDAwLTB4ZjIxMDAwZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMTMK c2RoY2lfcGNpMDogMSBzbG90KHMpIGFsbG9jYXRlZApwY2kxMzogPGJhc2UgcGVyaXBoZXJh bD4gYXQgZGV2aWNlIDAuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQplaGNpMTogPEludGVsIFBD SCBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUE+IG1lbSAweGYyNDI4NDAwLTB4ZjI0Mjg3ZmYg aXJxIDE5IGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdXNidXMxOiBFSENJIHZlcnNpb24gMS4w CnVzYnVzMSBvbiBlaGNpMQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzMC4wIG9uIHBjaTAKcGNpMTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CmlzYWIwOiA8 UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+ IG9uIGlzYWIwCmFoY2kwOiA8SW50ZWwgNSBTZXJpZXMvMzQwMCBTZXJpZXMgQUhDSSBTQVRB IGNvbnRyb2xsZXI+IHBvcnQgMHgxODE4LTB4MTgxZiwweDE4MGMtMHgxODBmLDB4MTgxMC0w eDE4MTcsMHgxODA4LTB4MTgwYiwweDE4NDAtMHgxODVmIG1lbSAweGYyNDI3MDAwLTB4ZjI0 Mjc3ZmYgaXJxIDE2IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYWhjaTA6IEFIQ0kgdjEuMzAg d2l0aCA2IDNHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgbm90IHN1cHBvcnRlZAphaGNp Y2gwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTAKYWhjaWNoMTogPEFI Q0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDQ6IDxBSENJIGNoYW5u ZWw+IGF0IGNoYW5uZWwgNCBvbiBhaGNpMAphaGNpY2g1OiA8QUhDSSBjaGFubmVsPiBhdCBj aGFubmVsIDUgb24gYWhjaTAKYWhjaWVtMDogPEFIQ0kgZW5jbG9zdXJlIG1hbmFnZW1lbnQg YnJpZGdlPiBvbiBhaGNpMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAz MS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxkYXNwPiBhdCBkZXZpY2UgMzEuNiAo bm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAK YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQg aXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAK a2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiA8UFMvMiBNb3Vz ZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogbW9kZWwg R2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMApiYXR0ZXJ5MDogPEFDUEkgQ29udHJv bCBNZXRob2QgQmF0dGVyeT4gb24gYWNwaTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9u IGFjcGkwCmFjcGlfaWJtMDogPElCTSBUaGlua1BhZCBBQ1BJIEV4dHJhcz4gb24gYWNwaTAK b3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhkMDAwMC0weGQwZmZmLDB4ZDEw MDAtMHhkMWZmZiwweGRkMDAwLTB4ZGZmZmYsMHhlMDAwMC0weGVmZmZmIG9uIGlzYTAKc2Mw OiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdB PiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCnBw YzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmNvcmV0ZW1wMDogPENQVSBPbi1E aWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUwCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAg RnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAKY29yZXRlbXAxOiA8Q1BVIE9uLURpZSBUaGVy bWFsIFNlbnNvcnM+IG9uIGNwdTEKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVu Y3kgQ29udHJvbD4gb24gY3B1MQpjb3JldGVtcDI6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vu c29ycz4gb24gY3B1Mgplc3QyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250 cm9sPiBvbiBjcHUyCmNvcmV0ZW1wMzogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBv biBjcHUzCmVzdDM6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTMKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMKaGRhY2MwOiA8TlZJ RElBIEdUMjF4IEhEQSBDT0RFQz4gYXQgY2FkIDAgb24gaGRhYzAKaGRhYTA6IDxOVklESUEg R1QyMXggQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMApwY20wOiA8 TlZJRElBIEdUMjF4IChIRE1JL0RQIDhjaCk+IGF0IG5pZCA1IG9uIGhkYWEwCmhkYWNjMTog PE5WSURJQSBHVDIxeCBIREEgQ09ERUM+IGF0IGNhZCAxIG9uIGhkYWMwCmhkYWExOiA8TlZJ RElBIEdUMjF4IEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzEKcGNt MTogPE5WSURJQSBHVDIxeCAoSERNSS9EUCA4Y2gpPiBhdCBuaWQgNSBvbiBoZGFhMQpoZGFj YzI6IDxOVklESUEgR1QyMXggSERBIENPREVDPiBhdCBjYWQgMiBvbiBoZGFjMApoZGFhMjog PE5WSURJQSBHVDIxeCBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2My CnBjbTI6IDxOVklESUEgR1QyMXggKEhETUkvRFAgOGNoKT4gYXQgbmlkIDUgb24gaGRhYTIK aGRhY2MzOiA8TlZJRElBIEdUMjF4IEhEQSBDT0RFQz4gYXQgY2FkIDMgb24gaGRhYzAKaGRh YTM6IDxOVklESUEgR1QyMXggQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhk YWNjMwpwY20zOiA8TlZJRElBIEdUMjF4IChIRE1JL0RQIDhjaCk+IGF0IG5pZCA1IG9uIGhk YWEzCmhkYWNjNDogPENvbmV4YW50IENYMjA1ODUgSERBIENPREVDPiBhdCBjYWQgMCBvbiBo ZGFjMQpoZGFhNDogPENvbmV4YW50IENYMjA1ODUgQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0 IG5pZCAxIG9uIGhkYWNjNApwY200OiA8Q29uZXhhbnQgQ1gyMDU4NSAoUmlnaHQgQW5hbG9n KT4gYXQgbmlkIDI1IGFuZCAyNyBvbiBoZGFhNApwY201OiA8Q29uZXhhbnQgQ1gyMDU4NSAo SW50ZXJuYWwgQW5hbG9nKT4gYXQgbmlkIDMxIGFuZCAzNSBvbiBoZGFhNApyYW5kb206IHVu YmxvY2tpbmcgZGV2aWNlLgp1c2J1czA6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1 c2J1czE6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMS4xOiA8SW50ZWw+IGF0 IHVzYnVzMQp1aHViMDogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAK dWh1YjE6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMwCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0 IDAgbHVuIDAKYWRhMDogPFdEQyBXRDMyMDBCRVZULTA4QTIzVDEgMDIuMDFBMDI+IEFUQS04 IFNBVEEgMi54IGRldmljZQphZGEwOiBTZXJpYWwgTnVtYmVyIFdELVdYRDFBMTE1NDI3NQph ZGEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJi eXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDMwNTI0NU1CICg2 MjUxNDI0NDggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMDogUHJl dmlvdXNseSB3YXMga25vd24gYXMgYWQ0CnNlczAgYXQgYWhjaWVtMCBidXMgMCBzY2J1czQg dGFyZ2V0IDAgbHVuIDAKc2VzMDogPEFIQ0kgU0dQSU8gRW5jbG9zdXJlIDEuMDAgMDAwMT4g U0VNQiBTLUUtUyAyLjAwIGRldmljZQpzZXMwOiBTRU1CIFNFUyBEZXZpY2UKY2QwIGF0IGFo Y2ljaDEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCmNkMDogPE9wdGlhcmMgRFZEIFJX IEFELTc5MzBIIDEuRDE+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2QwOiAx NTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgQVRBUEkgMTJieXRlcywg UElPIDgxOTJieXRlcykKY2QwOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxl ZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQgLSB0cmF5IGNsb3NlZApOZXR2c2Mg aW5pdGlhbGl6aW5nLi4uIFNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpTTVA6IEFQIENQVSAj MiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClRpbWVjb3VudGVyICJUU0Mt bG93IiBmcmVxdWVuY3kgMTMzMDAzMjQwOSBIeiBxdWFsaXR5IDEwMDAKUm9vdCBtb3VudCB3 YWl0aW5nIGZvcjogdXNidXMxIHVzYnVzMAp1aHViMTogMyBwb3J0cyB3aXRoIDMgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWh1YjA6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMSB1c2J1czAKUm9vdCBt b3VudCB3YWl0aW5nIGZvcjogdXNidXMxIHVzYnVzMAp1Z2VuMC4yOiA8dmVuZG9yIDB4ODA4 Nz4gYXQgdXNidXMwCnVodWIyOiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyMCwgY2xh c3MgOS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDI+IG9uIHVzYnVzMAp1Z2VuMS4yOiA8dmVu ZG9yIDB4ODA4Nz4gYXQgdXNidXMxCnVodWIzOiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4 MDAyMCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDI+IG9uIHVzYnVzMQp1aHVi MjogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3 YWl0aW5nIGZvcjogdXNidXMxIHVzYnVzMAp1aHViMzogOCBwb3J0cyB3aXRoIDggcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWdlbjAuMzogPEJyb2FkY29tIENvcnA+IGF0IHVzYnVzMApS b290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czAKdWdlbjAuNDogPENoaWNvbnkgRWxlY3Ry b25pY3MgQ28uLCBMdGQuPiBhdCB1c2J1czAKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1 ZnM6L2Rldi9hZGEwcDMgW3J3XS4uLgp1Z2VuMC4zOiA8QnJvYWRjb20gQ29ycD4gYXQgdXNi dXMwIChkaXNjb25uZWN0ZWQpClNldHRpbmcgaG9zdHV1aWQ6IDgxOTA1NDBkLTE1NTEtY2Ix MS1hMzRmLWRlMmI2MzIzYTMxZi4KU2V0dGluZyBob3N0aWQ6IDB4ZDc2YjhhN2IuCkVudHJv cHkgaGFydmVzdGluZzogaW50ZXJydXB0cyBldGhlcm5ldCBwb2ludF90b19wb2ludCBzd2ku ClN0YXJ0aW5nIGZpbGUgc3lzdGVtIGNoZWNrczoKL2Rldi9hZGEwcDM6IEZJTEUgU1lTVEVN IENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9hZGEwcDM6IGNsZWFuLCAxNjI4MDAzNSBm cmVlICg2NTE0NyBmcmFncywgMjAyNjg2MSBibG9ja3MsIDAuMyUgZnJhZ21lbnRhdGlvbikK L2Rldi9hZGEwcDQ6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9h ZGEwcDQ6IGNsZWFuLCAzMjYyODk3MiBmcmVlICgyNjY2OCBmcmFncywgNDA3NTI4OCBibG9j a3MsIDAuMSUgZnJhZ21lbnRhdGlvbikKTW91bnRpbmcgbG9jYWwgZmlsZSBzeXN0ZW1zOi4K V3JpdGluZyBlbnRyb3B5IGZpbGU6LgpTZXR0aW5nIGhvc3RuYW1lOiBuYWNodHNjaGF0dGVu Lm9ya2xhbi5kZS4Kd2xhbjA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjI0OmQ3OjkxOmI1OjQ0 ClN0YXJ0aW5nIHdwYV9zdXBwbGljYW50LgpTdGFydGluZyBOZXR3b3JrOiBsbzAgZW0wIGl3 bjAuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0 cmljIDAgbXR1IDE2Mzg0CglvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhDU1VNLFJYQ1NVTV9J UFY2LFRYQ1NVTV9JUFY2PgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBmZTgw OjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDMgCglpbmV0IDEyNy4wLjAuMSBuZXRt YXNrIDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xP Q0FMPgplbTA6IGZsYWdzPThjMDI8QlJPQURDQVNULE9BQ1RJVkUsU0lNUExFWCxNVUxUSUNB U1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQyMTliPFJYQ1NVTSxUWENTVU0sVkxB Tl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxXT0xfTUFHSUMsVkxBTl9I V1RTTz4KCWV0aGVyIGYwOmRlOmYxOjQ2OjFiOjhjCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JN TlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3Nl bGVjdAoJc3RhdHVzOiBubyBjYXJyaWVyCml3bjA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNU LFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAyMjkwCglldGhlciAw MDoyNDpkNzo5MTpiNTo0NAoJbmQ2IG9wdGlvbnM9MjE8UEVSRk9STU5VRCxBVVRPX0xJTktM T0NBTD4KCW1lZGlhOiBJRUVFIDgwMi4xMSBXaXJlbGVzcyBFdGhlcm5ldCBhdXRvc2VsZWN0 IG1vZGUgMTFhCglzdGF0dXM6IGFzc29jaWF0ZWQKU3RhcnRpbmcgZGV2ZC4KU3RhcnRpbmcg TmV0d29yazogZW0wLgplbTA6IGZsYWdzPThjMDI8QlJPQURDQVNULE9BQ1RJVkUsU0lNUExF WCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQyMTliPFJYQ1NVTSxU WENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxXT0xfTUFH SUMsVkxBTl9IV1RTTz4KCWV0aGVyIGYwOmRlOmYxOjQ2OjFiOjhjCgluZDYgb3B0aW9ucz0y OTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CgltZWRpYTogRXRoZXJu ZXQgYXV0b3NlbGVjdAoJc3RhdHVzOiBubyBjYXJyaWVyCmFkZCBuZXQgZmU4MDo6OiBnYXRl d2F5IDo6MQphZGQgbmV0IGZmMDI6OjogZ2F0ZXdheSA6OjEKYWRkIG5ldCA6OmZmZmY6MC4w LjAuMDogZ2F0ZXdheSA6OjEKYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxCldhaXRp bmcgMzBzIGZvciB0aGUgZGVmYXVsdCByb3V0ZSBpbnRlcmZhY2U6IC4uLi4uKG5vIGNhcnJp ZXIpCkVMRiBsZGNvbmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAv dXNyL2xvY2FsL2xpYiAvdXNyL2xvY2FsL2xpYi9nY2M0OCAvdXNyL2xvY2FsL2xpYi9ncmFw aHZpeiAvdXNyL2xvY2FsL2xpYi9uc3MgL3Vzci9sb2NhbC9saWIvb3BlbmNvbGxhZGEgL3Vz ci9sb2NhbC9saWIvcHRoIC91c3IvbG9jYWwvbGliL3F0NCAvdXNyL2xvY2FsL2xpYi9xdGNy ZWF0b3IgL3Vzci9sb2NhbC9sbHZtMzMvbGliIC91c3IvbG9jYWwvbGx2bTM0L2xpYiAvdXNy L2xvY2FsL2xsdm0zNS9saWIKMzItYml0IGNvbXBhdGliaWxpdHkgbGRjb25maWcgcGF0aDog L3Vzci9saWIzMgpDcmVhdGluZyBhbmQvb3IgdHJpbW1pbmcgbG9nIGZpbGVzLgpTdGFydGlu ZyBzeXNsb2dkLgpObyBjb3JlIGR1bXBzIGZvdW5kLgpDbGVhcmluZyAvdG1wIChYIHJlbGF0 ZWQpLgpSZWNvdmVyaW5nIHZpIGVkaXRvciBzZXNzaW9uczouClN0YXJ0aW5nIGRidXMuClN0 YXJ0aW5nIGxvb2xlcmQuClVwZGF0aW5nIG1vdGQ6LgpNb3VudGluZyBsYXRlIGZpbGUgc3lz dGVtczouClN0YXJ0aW5nIG50cGQuClN0YXJ0aW5nIHBvd2VyZC4KQ29uZmlndXJpbmcgc3lz Y29uczogYmxhbmt0aW1lLgpQZXJmb3JtaW5nIHNhbml0eSBjaGVjayBvbiBzc2hkIGNvbmZp Z3VyYXRpb24uClN0YXJ0aW5nIHNzaGQuClN0YXJ0aW5nIHNlbmRtYWlsX3N1Ym1pdC4KU3Rh cnRpbmcgc2VuZG1haWxfbXNwX3F1ZXVlLgpTdGFydGluZyBjcm9uLgpTdGFydGluZyBkZWZh dWx0IG1vdXNlZC4KU3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4g NjAgc2Vjb25kcy4KClR1ZSBOb3YgMTEgMjM6Mjc6MzAgQ0VUIDIwMTQKTm92IDExIDIzOjI3 OjMxIG5hY2h0c2NoYXR0ZW4gbnRwZF9pbml0cmVzWzEyMzldOiBob3N0IG5hbWUgbm90IGZv dW5kOiBwdGJ0aW1lMS5wdGIuZGUKTm92IDExIDIzOjI3OjMxIG5hY2h0c2NoYXR0ZW4gbnRw ZF9pbml0cmVzWzEyMzldOiBob3N0IG5hbWUgbm90IGZvdW5kOiBwdGJ0aW1lMi5wdGIuZGUK Tm92IDExIDIzOjI3OjMxIG5hY2h0c2NoYXR0ZW4gbnRwZF9pbml0cmVzWzEyMzldOiBob3N0 IG5hbWUgbm90IGZvdW5kOiBwdGJ0aW1lMy5wdGIuZGUKTm92IDExIDIzOjI3OjMzIG5hY2h0 c2NoYXR0ZW4gd3BhX3N1cHBsaWNhbnRbNTc5XTogaW9jdGxbU0lPQ1M4MDIxMSwgb3A9MjAs IHZhbD0wLCBhcmdfbGVuPTddOiBDYW4ndCBhc3NpZ24gcmVxdWVzdGVkIGFkZHJlc3MKd2xh bjA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApOb3YgMTEgMjM6Mjc6MzcgbmFjaHRzY2hh dHRlbiBkaGNsaWVudFsxMzQ5XTogc2VuZF9wYWNrZXQ6IE5vIGJ1ZmZlciBzcGFjZSBhdmFp bGFibGUKTm92IDExIDIzOjI3OjQxIG5hY2h0c2NoYXR0ZW4gbG9naW46IFJPT1QgTE9HSU4g KHJvb3QpIE9OIHR0eXYwCk5vdiAxMSAyMzozMToyOSBuYWNodHNjaGF0dGVuIHNodXRkb3du OiByZWJvb3QgYnkgcm9vdDogClN0b3BwaW5nIG1vdXNlZC4KV2FpdGluZyBmb3IgUElEUzog MTI2OC4KU3RvcHBpbmcgY3Jvbi4KV2FpdGluZyBmb3IgUElEUzogMTI1MS4KU3RvcHBpbmcg c3NoZC4KV2FpdGluZyBmb3IgUElEUzogMTI0MS4KU3RvcHBpbmcgcG93ZXJkLgpXYWl0aW5n IGZvciBQSURTOiAxMjEzLgpTdG9wcGluZyBudHBkLgpXYWl0aW5nIGZvciBQSURTOiAxMjEw LgpTdG9wcGluZyBkZXZkLgpXYWl0aW5nIGZvciBQSURTOiA4OTIuCldyaXRpbmcgZW50cm9w eSBmaWxlOi4KLgpUZXJtaW5hdGVkCk5vdiAxMSAyMzozMToyOSBuYWNodHNjaGF0dGVuIHN5 c2xvZ2Q6IGV4aXRpbmcgb24gc2lnbmFsIDE1CndsYW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQg dG8gRE9XTgpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2 bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAg c2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3luY2lu ZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjE0IDcgMCAxIDEgMCAwIGRvbmUKQWxsIGJ1 ZmZlcnMgc3luY2VkLgpVcHRpbWU6IDRtMjdzCnVzYnVzMDogQ29udHJvbGxlciBzaHV0ZG93 bgp1aHViMTogYXQgdXNidXMwLCBwb3J0IDEsIGFkZHIgMSAoZGlzY29ubmVjdGVkKQp1Z2Vu MC4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMwIChkaXNjb25uZWN0ZWQpCnVodWIyOiBh dCB1aHViMSwgcG9ydCAxLCBhZGRyIDIgKGRpc2Nvbm5lY3RlZCkKdWdlbjAuNDogPENoaWNv bnkgRWxlY3Ryb25pY3MgQ28uLCBMdGQuPiBhdCB1c2J1czAgKGRpc2Nvbm5lY3RlZCkKdXNi dXMwOiBDb250cm9sbGVyIHNodXRkb3duIGNvbXBsZXRlCnVzYnVzMTogQ29udHJvbGxlciBz aHV0ZG93bgp1aHViMDogYXQgdXNidXMxLCBwb3J0IDEsIGFkZHIgMSAoZGlzY29ubmVjdGVk KQp1Z2VuMS4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMxIChkaXNjb25uZWN0ZWQpCnVo dWIzOiBhdCB1aHViMCwgcG9ydCAxLCBhZGRyIDIgKGRpc2Nvbm5lY3RlZCkKdXNidXMxOiBD b250cm9sbGVyIHNodXRkb3duIGNvbXBsZXRlClJlYm9vdGluZy4uLgpjcHVfcmVzZXQ6IFN0 b3BwaW5nIG90aGVyIENQVXMKQ29weXJpZ2h0IChjKSAxOTkyLTIwMTQgVGhlIEZyZWVCU0Qg UHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAx OTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVy c2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEg cmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJT RCAxMC4wLVJFTEVBU0UtcDEyICMwOiBUdWUgTm92ICA0IDA1OjA3OjE3IFVUQyAyMDE0CiAg ICByb290QGFtZDY0LWJ1aWxkZXIuZGFlbW9ub2xvZ3kubmV0Oi91c3Ivb2JqL3Vzci9zcmMv c3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDMuMyAodGFncy9SRUxF QVNFXzMzL2ZpbmFsIDE4MzUwMikgMjAxMzA2MTAKY2FuJ3QgcmUtdXNlIGEgbGVhZiAoaHdw c3RhdGVfdmVyYm9zZSkhCm1vZHVsZV9yZWdpc3RlcjogbW9kdWxlIGNwdS9pY2hzcyBhbHJl YWR5IGV4aXN0cyEKTW9kdWxlIGNwdS9pY2hzcyBmYWlsZWQgdG8gcmVnaXN0ZXI6IDE3Cm1v ZHVsZV9yZWdpc3RlcjogbW9kdWxlIGNwdS9wb3dlcm5vdyBhbHJlYWR5IGV4aXN0cyEKTW9k dWxlIGNwdS9wb3dlcm5vdyBmYWlsZWQgdG8gcmVnaXN0ZXI6IDE3Cm1vZHVsZV9yZWdpc3Rl cjogbW9kdWxlIGNwdS9lc3QgYWxyZWFkeSBleGlzdHMhCk1vZHVsZSBjcHUvZXN0IGZhaWxl ZCB0byByZWdpc3RlcjogMTcKbW9kdWxlX3JlZ2lzdGVyOiBtb2R1bGUgY3B1L2h3cHN0YXRl IGFscmVhZHkgZXhpc3RzIQpNb2R1bGUgY3B1L2h3cHN0YXRlIGZhaWxlZCB0byByZWdpc3Rl cjogMTcKbW9kdWxlX3JlZ2lzdGVyOiBtb2R1bGUgY3B1L3A0dGNjIGFscmVhZHkgZXhpc3Rz IQpNb2R1bGUgY3B1L3A0dGNjIGZhaWxlZCB0byByZWdpc3RlcjogMTcKQ1BVOiBJbnRlbChS KSBDb3JlKFRNKSBpNSBDUFUgICAgICAgTSA1NjAgIEAgMi42N0dIeiAoMjY2MC4wNy1NSHog SzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MjA2NTUg IEZhbWlseSA9IDB4NiAgTW9kZWwgPSAweDI1ICBTdGVwcGluZyA9IDUKICBGZWF0dXJlcz0w eGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAs TVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1Is U1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHgyOWFlM2ZmPFNTRTMsUENM TVVMUURRLERURVM2NCxNT04sRFNfQ1BMLFZNWCxTTVgsRVNULFRNMixTU1NFMyxDWDE2LHhU UFIsUERDTSxQQ0lELFNTRTQuMSxTU0U0LjIsUE9QQ05ULEFFU05JPgogIEFNRCBGZWF0dXJl cz0weDI4MTAwODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgx PExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ugc3RhdGlzdGlj cwpyZWFsIG1lbW9yeSAgPSA0Mjk0OTY3Mjk2ICg0MDk2IE1CKQphdmFpbCBtZW1vcnkgPSAz OTQ4MDE5NzEyICgzNzY1IE1CKQpBQ1BJIEFQSUMgVGFibGU6IDxMRU5PVk8gVFAtNkkgICA+ CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpG cmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggMiBjb3JlKHMpIHggMiBTTVQgdGhyZWFkcwog Y3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIg KEFQKTogQVBJQyBJRDogIDQKIGNwdTMgKEFQKTogQVBJQyBJRDogIDUKaW9hcGljMDogQ2hh bmdpbmcgQVBJQyBJRCB0byAxCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24g bW90aGVyYm9hcmQKa2JkMSBhdCBrYmRtdXgwCnJhbmRvbTogPFNvZnR3YXJlLCBZYXJyb3c+ IGluaXRpYWxpemVkCmFjcGkwOiA8TEVOT1ZPIFRQLTZJPiBvbiBtb3RoZXJib2FyZAphY3Bp X2VjMDogPEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDExLCBFQ0RUPiBwb3J0IDB4NjIs MHg2NiBvbiBhY3BpMAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHJlc2Vy dmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEw MDAwMCwgYmZmMDAwMDAgKDMpIGZhaWxlZApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNw dTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUz OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0w eDQzIGlycSAwIG9uIGFjcGkwClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMx ODIgSHogcXVhbGl0eSAwCkV2ZW50IHRpbWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIg SHogcXVhbGl0eSAxMDAKaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9t ZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwClRpbWVjb3VudGVyICJIUEVUIiBm cmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5NTAKRXZlbnQgdGltZXIgIkhQRVQiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDU1MApFdmVudCB0aW1lciAiSFBFVDEiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDIiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDMiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDQiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MAphdHJ0YzA6IDxBVCByZWFsdGltZSBj bG9jaz4gcG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIgIlJUQyIg ZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApUaW1lY291bnRlciAiQUNQSS1zYWZlIiBm cmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDg1MAphY3BpX3RpbWVyMDogPDI0LWJpdCB0 aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwCmFjcGlf bGlkMDogPENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9uIGFjcGkwCmFjcGlfYnV0dG9u MDogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gb24gYWNwaTAKcGNpMjU1OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2liMTogPEFD UEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li Mgp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDIwMDAtMHgyMDdm IG1lbSAweGNjMDAwMDAwLTB4Y2NmZmZmZmYsMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4Y2Uw MDAwMDAtMHhjZmZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCm52aWRpYTA6 IDxOVlMgMzEwME0+IG9uIHZnYXBjaTAKdmdhcGNpMDogY2hpbGQgbnZpZGlhMCByZXF1ZXN0 ZWQgcGNpX2VuYWJsZV9pbwp2Z2FwY2kwOiBjaGlsZCBudmlkaWEwIHJlcXVlc3RlZCBwY2lf ZW5hYmxlX2lvCnZnYXBjaTA6IEJvb3QgdmlkZW8gZGV2aWNlCmhkYWMwOiA8TlZJRElBICgw eDBiZTMpIEhEQSBDb250cm9sbGVyPiBtZW0gMHhjZGVmYzAwMC0weGNkZWZmZmZmIGF0IGRl dmljZSAwLjEgb24gcGNpMQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMjIuMCAo bm8gZHJpdmVyIGF0dGFjaGVkKQp1YXJ0MjogPDUgU2VyaWVzLzM0MDAgU2VyaWVzIENoaXBz ZXQgS1QgQ29udHJvbGxlcj4gcG9ydCAweDE4MDAtMHgxODA3IG1lbSAweGYyNDI0MDAwLTB4 ZjI0MjRmZmYgaXJxIDE3IGF0IGRldmljZSAyMi4zIG9uIHBjaTAKZW0wOiA8SW50ZWwoUikg UFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uIDcuMy44PiBwb3J0IDB4MTgyMC0weDE4M2Yg bWVtIDB4ZjI0MDAwMDAtMHhmMjQxZmZmZiwweGYyNDI1MDAwLTB4ZjI0MjVmZmYgaXJxIDIw IGF0IGRldmljZSAyNS4wIG9uIHBjaTAKZW0wOiBVc2luZyBhbiBNU0kgaW50ZXJydXB0CmVt MDogRXRoZXJuZXQgYWRkcmVzczogZjA6ZGU6ZjE6NDY6MWI6OGMKZWhjaTA6IDxJbnRlbCBQ Q0ggVVNCIDIuMCBjb250cm9sbGVyIFVTQi1CPiBtZW0gMHhmMjQyODAwMC0weGYyNDI4M2Zm IGlycSAyMyBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVzYnVzMDogRUhDSSB2ZXJzaW9uIDEu MAp1c2J1czAgb24gZWhjaTAKaGRhYzE6IDxJbnRlbCA1IFNlcmllcy8zNDAwIFNlcmllcyBI REEgQ29udHJvbGxlcj4gbWVtIDB4ZjI0MjAwMDAtMHhmMjQyM2ZmZiBpcnEgMTcgYXQgZGV2 aWNlIDI3LjAgb24gcGNpMApwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAyMCBh dCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnBj aWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDIxIGF0IGRldmljZSAyOC4xIG9uIHBj aTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKaXduMDogPEludGVsIENlbnRyaW5v IFVsdGltYXRlLU4gNjMwMD4gbWVtIDB4ZjIwMDAwMDAtMHhmMjAwMWZmZiBpcnEgMTcgYXQg ZGV2aWNlIDAuMCBvbiBwY2kzCnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDIw IGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNpMTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1 CnNkaGNpX3BjaTA6IDxSSUNPSCBTRD4gbWVtIDB4ZjIxMDAwMDAtMHhmMjEwMDBmZiBpcnEg MTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxMwpzZGhjaV9wY2kwOiAxIHNsb3QocykgYWxsb2Nh dGVkCnBjaTEzOiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIg YXR0YWNoZWQpCmVoY2kxOiA8SW50ZWwgUENIIFVTQiAyLjAgY29udHJvbGxlciBVU0ItQT4g bWVtIDB4ZjI0Mjg0MDAtMHhmMjQyODdmZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjAgb24gcGNp MAp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMxIG9uIGVoY2kxCnBjaWI2OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2kxNDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjYKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMx LjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYWhjaTA6IDxJbnRlbCA1IFNl cmllcy8zNDAwIFNlcmllcyBBSENJIFNBVEEgY29udHJvbGxlcj4gcG9ydCAweDE4MTgtMHgx ODFmLDB4MTgwYy0weDE4MGYsMHgxODEwLTB4MTgxNywweDE4MDgtMHgxODBiLDB4MTg0MC0w eDE4NWYgbWVtIDB4ZjI0MjcwMDAtMHhmMjQyNzdmZiBpcnEgMTYgYXQgZGV2aWNlIDMxLjIg b24gcGNpMAphaGNpMDogQUhDSSB2MS4zMCB3aXRoIDYgM0dicHMgcG9ydHMsIFBvcnQgTXVs dGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5u ZWwgMCBvbiBhaGNpMAphaGNpY2gxOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24g YWhjaTAKYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9uIGFoY2kwCmFo Y2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNpMAphaGNpZW0wOiA8 QUhDSSBlbmNsb3N1cmUgbWFuYWdlbWVudCBicmlkZ2U+IG9uIGFoY2kwCnBjaTA6IDxzZXJp YWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNp MDogPGRhc3A+IGF0IGRldmljZSAzMS42IChubyBkcml2ZXIgYXR0YWNoZWQpCmFjcGlfdHow OiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxl ciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBL ZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFO VC1MT0NLRURdCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBb R0lBTlQtTE9DS0VEXQpwc20wOiBtb2RlbCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJ RCAwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAph Y3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKYWNwaV9pYm0wOiA8SUJNIFRoaW5r UGFkIEFDUEkgRXh0cmFzPiBvbiBhY3BpMApvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBp b21lbSAweGQwMDAwLTB4ZDBmZmYsMHhkMTAwMC0weGQxZmZmLDB4ZGQwMDAtMHhkZmZmZiww eGUwMDAwLTB4ZWZmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3Mg MHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgz MDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0g MHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQg cmFuZ2UKY29yZXRlbXAwOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTAK ZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MApj b3JldGVtcDE6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1MQplc3QxOiA8 RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCmNvcmV0ZW1w MjogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUyCmVzdDI6IDxFbmhhbmNl ZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTIKY29yZXRlbXAzOiA8Q1BV IE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTMKZXN0MzogPEVuaGFuY2VkIFNwZWVk U3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MwpUaW1lY291bnRlcnMgdGljayBldmVy eSAxMC4wMDAgbXNlYwpoZGFjYzA6IDxOVklESUEgR1QyMXggSERBIENPREVDPiBhdCBjYWQg MCBvbiBoZGFjMApoZGFhMDogPE5WSURJQSBHVDIxeCBBdWRpbyBGdW5jdGlvbiBHcm91cD4g YXQgbmlkIDEgb24gaGRhY2MwCnBjbTA6IDxOVklESUEgR1QyMXggKEhETUkvRFAgOGNoKT4g YXQgbmlkIDUgb24gaGRhYTAKaGRhY2MxOiA8TlZJRElBIEdUMjF4IEhEQSBDT0RFQz4gYXQg Y2FkIDEgb24gaGRhYzAKaGRhYTE6IDxOVklESUEgR1QyMXggQXVkaW8gRnVuY3Rpb24gR3Jv dXA+IGF0IG5pZCAxIG9uIGhkYWNjMQpwY20xOiA8TlZJRElBIEdUMjF4IChIRE1JL0RQIDhj aCk+IGF0IG5pZCA1IG9uIGhkYWExCmhkYWNjMjogPE5WSURJQSBHVDIxeCBIREEgQ09ERUM+ IGF0IGNhZCAyIG9uIGhkYWMwCmhkYWEyOiA8TlZJRElBIEdUMjF4IEF1ZGlvIEZ1bmN0aW9u IEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzIKcGNtMjogPE5WSURJQSBHVDIxeCAoSERNSS9E UCA4Y2gpPiBhdCBuaWQgNSBvbiBoZGFhMgpoZGFjYzM6IDxOVklESUEgR1QyMXggSERBIENP REVDPiBhdCBjYWQgMyBvbiBoZGFjMApoZGFhMzogPE5WSURJQSBHVDIxeCBBdWRpbyBGdW5j dGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2MzCnBjbTM6IDxOVklESUEgR1QyMXggKEhE TUkvRFAgOGNoKT4gYXQgbmlkIDUgb24gaGRhYTMKaGRhY2M0OiA8Q29uZXhhbnQgQ1gyMDU4 NSBIREEgQ09ERUM+IGF0IGNhZCAwIG9uIGhkYWMxCmhkYWE0OiA8Q29uZXhhbnQgQ1gyMDU4 NSBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2M0CnBjbTQ6IDxDb25l eGFudCBDWDIwNTg1IChSaWdodCBBbmFsb2cpPiBhdCBuaWQgMjUgYW5kIDI3IG9uIGhkYWE0 CnBjbTU6IDxDb25leGFudCBDWDIwNTg1IChJbnRlcm5hbCBBbmFsb2cpPiBhdCBuaWQgMzEg YW5kIDM1IG9uIGhkYWE0CnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuCnVzYnVzMDogNDgw TWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzMTogNDgwTWJwcyBIaWdoIFNwZWVkIFVT QiB2Mi4wCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIwOiA8SW50ZWwgRUhDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1 Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHViMTogPEludGVsIEVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKYWRhMCBhdCBh aGNpY2gwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGEwOiA8V0RDIFdEMzIwMEJF VlQtMDhBMjNUMSAwMi4wMUEwMj4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTA6IFNlcmlh bCBOdW1iZXIgV0QtV1hEMUExMTU0Mjc1CmFkYTA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAo U0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEwOiBDb21tYW5kIFF1ZXVlaW5n IGVuYWJsZWQKYWRhMDogMzA1MjQ1TUIgKDYyNTE0MjQ0OCA1MTIgYnl0ZSBzZWN0b3JzOiAx NkggNjNTL1QgMTYzODNDKQphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDQKc2Vz MCBhdCBhaGNpZW0wIGJ1cyAwIHNjYnVzNCB0YXJnZXQgMCBsdW4gMApzZXMwOiA8QUhDSSBT R1BJTyBFbmNsb3N1cmUgMS4wMCAwMDAxPiBTRU1CIFMtRS1TIDIuMDAgZGV2aWNlCnNlczA6 IFNFTUIgU0VTIERldmljZQpjZDAgYXQgYWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAg bHVuIDAKY2QwOiA8T3B0aWFyYyBEVkQgUlcgQUQtNzkzMEggMS5EMT4gUmVtb3ZhYmxlIENE LVJPTSBTQ1NJLTAgZGV2aWNlIApjZDA6IDE1MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAx LngsIFVETUE1LCBBVEFQSSAxMmJ5dGVzLCBQSU8gODE5MmJ5dGVzKQpjZDA6IEF0dGVtcHQg dG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJl c2VudCAtIHRyYXkgY2xvc2VkCk5ldHZzYyBpbml0aWFsaXppbmcuLi4gU01QOiBBUCBDUFUg IzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMyBM YXVuY2hlZCEKVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAxMzMwMDMzMTA3IEh6 IHF1YWxpdHkgMTAwMApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVo dWIwOiAzIHBvcnRzIHdpdGggMyByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMyBw b3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5n IGZvcjogdXNidXMxIHVzYnVzMAp1Z2VuMC4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMw CnVodWIyOiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyMCwgY2xhc3MgOS8wLCByZXYg Mi4wMC8wLjAwLCBhZGRyIDI+IG9uIHVzYnVzMAp1Z2VuMS4yOiA8dmVuZG9yIDB4ODA4Nz4g YXQgdXNidXMxCnVodWIzOiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyMCwgY2xhc3Mg OS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDI+IG9uIHVzYnVzMQpSb290IG1vdW50IHdhaXRp bmcgZm9yOiB1c2J1czEgdXNidXMwCnVodWIyOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEgdXNidXMwCnVo dWIzOiA4IHBvcnRzIHdpdGggOCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuMC4zOiA8 QnJvYWRjb20gQ29ycD4gYXQgdXNidXMwClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVz MAp1Z2VuMC40OiA8Q2hpY29ueSBFbGVjdHJvbmljcyBDby4sIEx0ZC4+IGF0IHVzYnVzMApU cnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkYTBwMyBbcnddLi4uCnVnZW4w LjM6IDxCcm9hZGNvbSBDb3JwPiBhdCB1c2J1czAgKGRpc2Nvbm5lY3RlZCkKU2V0dGluZyBo b3N0dXVpZDogODE5MDU0MGQtMTU1MS1jYjExLWEzNGYtZGUyYjYzMjNhMzFmLgpTZXR0aW5n IGhvc3RpZDogMHhkNzZiOGE3Yi4KRW50cm9weSBoYXJ2ZXN0aW5nOiBpbnRlcnJ1cHRzIGV0 aGVybmV0IHBvaW50X3RvX3BvaW50IHN3aS4KU3RhcnRpbmcgZmlsZSBzeXN0ZW0gY2hlY2tz OgovZGV2L2FkYTBwMzogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2 L2FkYTBwMzogY2xlYW4sIDE2Mjc0NTI0IGZyZWUgKDY1MTQwIGZyYWdzLCAyMDI2MTczIGJs b2NrcywgMC4zJSBmcmFnbWVudGF0aW9uKQovZGV2L2FkYTBwNDogRklMRSBTWVNURU0gQ0xF QU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2FkYTBwNDogY2xlYW4sIDMyNjI4OTcyIGZyZWUg KDI2NjY4IGZyYWdzLCA0MDc1Mjg4IGJsb2NrcywgMC4xJSBmcmFnbWVudGF0aW9uKQpNb3Vu dGluZyBsb2NhbCBmaWxlIHN5c3RlbXM6LgpXcml0aW5nIGVudHJvcHkgZmlsZTouClNldHRp bmcgaG9zdG5hbWU6IG5hY2h0c2NoYXR0ZW4ub3JrbGFuLmRlLgp3bGFuMDogRXRoZXJuZXQg YWRkcmVzczogMDA6MjQ6ZDc6OTE6YjU6NDQKU3RhcnRpbmcgd3BhX3N1cHBsaWNhbnQuClN0 YXJ0aW5nIE5ldHdvcms6IGxvMCBlbTAgaXduMC4KbG8wOiBmbGFncz04MDQ5PFVQLExPT1BC QUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYzODQKCW9wdGlvbnM9NjAw MDAzPFJYQ1NVTSxUWENTVU0sUlhDU1VNX0lQVjYsVFhDU1VNX0lQVjY+CglpbmV0NiA6OjEg cHJlZml4bGVuIDEyOCAKCWluZXQ2IGZlODA6OjElbG8wIHByZWZpeGxlbiA2NCBzY29wZWlk IDB4MyAKCWluZXQgMTI3LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAwMCAKCW5kNiBvcHRpb25z PTIxPFBFUkZPUk1OVUQsQVVUT19MSU5LTE9DQUw+CmVtMDogZmxhZ3M9OGMwMjxCUk9BRENB U1QsT0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlv bnM9NDIxOWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxWTEFOX0hX Q1NVTSxUU080LFdPTF9NQUdJQyxWTEFOX0hXVFNPPgoJZXRoZXIgZjA6ZGU6ZjE6NDY6MWI6 OGMKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NB TD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0dXM6IG5vIGNhcnJpZXIKaXdu MDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4g bWV0cmljIDAgbXR1IDIyOTAKCWV0aGVyIDAwOjI0OmQ3OjkxOmI1OjQ0CgluZDYgb3B0aW9u cz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IElFRUUgODAyLjExIFdp cmVsZXNzIEV0aGVybmV0IGF1dG9zZWxlY3QgbW9kZSAxMWEKCXN0YXR1czogYXNzb2NpYXRl ZApTdGFydGluZyBkZXZkLgpTdGFydGluZyBOZXR3b3JrOiBlbTAuCmVtMDogZmxhZ3M9OGMw MjxCUk9BRENBU1QsT0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1 MDAKCW9wdGlvbnM9NDIxOWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lO RyxWTEFOX0hXQ1NVTSxUU080LFdPTF9NQUdJQyxWTEFOX0hXVFNPPgoJZXRoZXIgZjA6ZGU6 ZjE6NDY6MWI6OGMKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRP X0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0dXM6IG5vIGNh cnJpZXIKYWRkIG5ldCBmZTgwOjo6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmYwMjo6OiBnYXRl d2F5IDo6MQphZGQgbmV0IDo6ZmZmZjowLjAuMC4wOiBnYXRld2F5IDo6MQphZGQgbmV0IDo6 MC4wLjAuMDogZ2F0ZXdheSA6OjEKV2FpdGluZyAzMHMgZm9yIHRoZSBkZWZhdWx0IHJvdXRl IGludGVyZmFjZTogLi4uLi4obm8gY2FycmllcikKRUxGIGxkY29uZmlnIHBhdGg6IC9saWIg L3Vzci9saWIgL3Vzci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGli L2djYzQ4IC91c3IvbG9jYWwvbGliL2dyYXBodml6IC91c3IvbG9jYWwvbGliL25zcyAvdXNy L2xvY2FsL2xpYi9vcGVuY29sbGFkYSAvdXNyL2xvY2FsL2xpYi9wdGggL3Vzci9sb2NhbC9s aWIvcXQ0IC91c3IvbG9jYWwvbGliL3F0Y3JlYXRvciAvdXNyL2xvY2FsL2xsdm0zMy9saWIg L3Vzci9sb2NhbC9sbHZtMzQvbGliIC91c3IvbG9jYWwvbGx2bTM1L2xpYgozMi1iaXQgY29t cGF0aWJpbGl0eSBsZGNvbmZpZyBwYXRoOiAvdXNyL2xpYjMyCkNyZWF0aW5nIGFuZC9vciB0 cmltbWluZyBsb2cgZmlsZXMuClN0YXJ0aW5nIHN5c2xvZ2QuCk5vIGNvcmUgZHVtcHMgZm91 bmQuCkNsZWFyaW5nIC90bXAgKFggcmVsYXRlZCkuClJlY292ZXJpbmcgdmkgZWRpdG9yIHNl c3Npb25zOi4KU3RhcnRpbmcgZGJ1cy4KU3RhcnRpbmcgbG9vbGVyZC4KVXBkYXRpbmcgbW90 ZDouCk1vdW50aW5nIGxhdGUgZmlsZSBzeXN0ZW1zOi4KU3RhcnRpbmcgbnRwZC4KU3RhcnRp bmcgcG93ZXJkLgpDb25maWd1cmluZyBzeXNjb25zOiBibGFua3RpbWUuClBlcmZvcm1pbmcg c2FuaXR5IGNoZWNrIG9uIHNzaGQgY29uZmlndXJhdGlvbi4KU3RhcnRpbmcgc3NoZC4KU3Rh cnRpbmcgc2VuZG1haWxfc3VibWl0LgpTdGFydGluZyBzZW5kbWFpbF9tc3BfcXVldWUuClN0 YXJ0aW5nIGNyb24uClN0YXJ0aW5nIGRlZmF1bHQgbW91c2VkLgpTdGFydGluZyBiYWNrZ3Jv dW5kIGZpbGUgc3lzdGVtIGNoZWNrcyBpbiA2MCBzZWNvbmRzLgoKVHVlIE5vdiAxMSAyMzoz MjoyOCBDRVQgMjAxNApOb3YgMTEgMjM6MzI6MjkgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRy ZXNbMTIzNl06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUxLnB0Yi5kZQpOb3YgMTEg MjM6MzI6MjkgbmFjaHRzY2hhdHRlbiBudHBkX2luaXRyZXNbMTIzNl06IGhvc3QgbmFtZSBu b3QgZm91bmQ6IHB0YnRpbWUyLnB0Yi5kZQpOb3YgMTEgMjM6MzI6MjkgbmFjaHRzY2hhdHRl biBudHBkX2luaXRyZXNbMTIzNl06IGhvc3QgbmFtZSBub3QgZm91bmQ6IHB0YnRpbWUzLnB0 Yi5kZQp3bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCk5vdiAxMSAyMzozMjo0MiBu YWNodHNjaGF0dGVuIGxvZ2luOiBST09UIExPR0lOIChyb290KSBPTiB0dHl2MApBQ1BJIFdh cm5pbmc6IFwxMzRfU0JfLlBDSTAuUEVHXy5WSURfLl9EU006IEFyZ3VtZW50ICM0IHR5cGUg bWlzbWF0Y2ggLSBGb3VuZCBbQnVmZmVyXSwgQUNQSSByZXF1aXJlcyBbUGFja2FnZV0gKDIw MTMwODIzL25zYXJndW1lbnRzLTk3KQpBQ1BJIFdhcm5pbmc6IFwxMzRfU0JfLlBDSTAuUEVH Xy5WSURfLl9EU006IEFyZ3VtZW50ICM0IHR5cGUgbWlzbWF0Y2ggLSBGb3VuZCBbQnVmZmVy XSwgQUNQSSByZXF1aXJlcyBbUGFja2FnZV0gKDIwMTMwODIzL25zYXJndW1lbnRzLTk3KQpB Q1BJIFdhcm5pbmc6IFwxMzRfU0JfLlBDSTAuUEVHXy5WSURfLl9EU006IEFyZ3VtZW50ICM0 IHR5cGUgbWlzbWF0Y2ggLSBGb3VuZCBbQnVmZmVyXSwgQUNQSSByZXF1aXJlcyBbUGFja2Fn ZV0gKDIwMTMwODIzL25zYXJndW1lbnRzLTk3KQpBQ1BJIFdhcm5pbmc6IFwxMzRfU0JfLlBD STAuUEVHXy5WSURfLl9EU006IEFyZ3VtZW50ICM0IHR5cGUgbWlzbWF0Y2ggLSBGb3VuZCBb QnVmZmVyXSwgQUNQSSByZXF1aXJlcyBbUGFja2FnZV0gKDIwMTMwODIzL25zYXJndW1lbnRz LTk3KQpBQ1BJIFdhcm5pbmc6IFwxMzRfU0JfLlBDSTAuUEVHXy5WSURfLl9EU006IEFyZ3Vt ZW50ICM0IHR5cGUgbWlzbWF0Y2ggLSBGb3VuZCBbQnVmZmVyXSwgQUNQSSByZXF1aXJlcyBb UGFja2FnZV0gKDIwMTMwODIzL25zYXJndW1lbnRzLTk3KQpBQ1BJIFdhcm5pbmc6IFwxMzRf U0JfLlBDSTAuUEVHXy5WSURfLl9EU006IEFyZ3VtZW50ICM0IHR5cGUgbWlzbWF0Y2ggLSBG b3VuZCBbQnVmZmVyXSwgQUNQSSByZXF1aXJlcyBbUGFja2FnZV0gKDIwMTMwODIzL25zYXJn dW1lbnRzLTk3KQpBQ1BJIFdhcm5pbmc6IFwxMzRfU0JfLlBDSTAuUEVHXy5WSURfLl9EU006 IEFyZ3VtZW50ICM0IHR5cGUgbWlzbWF0Y2ggLSBGb3VuZCBbQnVmZmVyXSwgQUNQSSByZXF1 aXJlcyBbUGFja2FnZV0gKDIwMTMwODIzL25zYXJndW1lbnRzLTk3KQpBQ1BJIFdhcm5pbmc6 IFwxMzRfU0JfLlBDSTAuUEVHXy5WSURfLl9EU006IEFyZ3VtZW50ICM0IHR5cGUgbWlzbWF0 Y2ggLSBGb3VuZCBbQnVmZmVyXSwgQUNQSSByZXF1aXJlcyBbUGFja2FnZV0gKDIwMTMwODIz L25zYXJndW1lbnRzLTk3KQpBQ1BJIFdhcm5pbmc6IFwxMzRfU0JfLlBDSTAuUEVHXy5WSURf Ll9EU006IEFyZ3VtZW50ICM0IHR5cGUgbWlzbWF0Y2ggLSBGb3VuZCBbQnVmZmVyXSwgQUNQ SSByZXF1aXJlcyBbUGFja2FnZV0gKDIwMTMwODIzL25zYXJndW1lbnRzLTk3KQpOVlJNOiBH UFUgYXQgUENJOjAwMDA6MDE6MDA6IEdQVS0yOWEzMjJmNC03NGM5LTFjOTktM2RiYi0wMDQ4 MzMzYWUzNGEKTlZSTTogWGlkIChQQ0k6MDAwMDowMTowMCk6IDU3LCBGYWlsZWQgc2htb28g c2RkcjMgbGluayB0cmFpbmluZwpOb3YgMTEgMjM6MzM6NTAgbmFjaHRzY2hhdHRlbiBzdTog ZmxvIHRvIHJvb3Qgb24gL2Rldi9wdHMvMApOb3YgMTEgMjM6MzQ6NDAgbmFjaHRzY2hhdHRl biBzaHV0ZG93bjogcmVib290IGJ5IGZsbzogClN0b3BwaW5nIG1vdXNlZC4KV2FpdGluZyBm b3IgUElEUzogMTI2NS4KU3RvcHBpbmcgY3Jvbi4KV2FpdGluZyBmb3IgUElEUzogMTI0OC4K U3RvcHBpbmcgc3NoZC4KV2FpdGluZyBmb3IgUElEUzogMTIzOC4KU3RvcHBpbmcgcG93ZXJk LgpXYWl0aW5nIGZvciBQSURTOiAxMjEwLgpTdG9wcGluZyBudHBkLgpXYWl0aW5nIGZvciBQ SURTOiAxMjA3LgpTdG9wcGluZyBkZXZkLgpXYWl0aW5nIGZvciBQSURTOiA4ODkuCldyaXRp bmcgZW50cm9weSBmaWxlOi4KLgpUZXJtaW5hdGVkCk5vdiAxMSAyMzozNDo0MCBuYWNodHNj aGF0dGVuIHN5c2xvZ2Q6IGV4aXRpbmcgb24gc2lnbmFsIDE1CgoKRmF0YWwgdHJhcCAxMjog cGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDA7IGFwaWMgaWQgPSAw MApmYXVsdCB2aXJ0dWFsIGFkZHJlc3MJPSAweDAKZmF1bHQgY29kZQkJPSBzdXBlcnZpc29y IHJlYWQgaW5zdHJ1Y3Rpb24sIHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRl cgk9IDB4MjA6MHgwCnN0YWNrIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmUwMTE3 ZWQ2N2IwCmZyYW1lIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmUwMDAxMzA1ZmU4 CmNvZGUgc2VnbWVudAkJPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwgdHlwZSAweDFiCgkJ CT0gRFBMIDAsIHByZXMgMSwgbG9uZyAxLCBkZWYzMiAwLCBncmFuIDEKcHJvY2Vzc29yIGVm bGFncwk9IGludGVycnVwdCBlbmFibGVkLCByZXN1bWUsIElPUEwgPSAzCmN1cnJlbnQgcHJv Y2VzcwkJPSAxNDA5IChYb3JnKQp0cmFwIG51bWJlcgkJPSAxMgpwYW5pYzogcGFnZSBmYXVs dApjcHVpZCA9IDAKS0RCOiBzdGFjayBiYWNrdHJhY2U6CiMwIDB4ZmZmZmZmZmY4MDhlN2U5 MCBhdCBrZGJfYmFja3RyYWNlKzB4NjAKIzEgMHhmZmZmZmZmZjgwOGFmOTc1IGF0IHBhbmlj KzB4MTU1CiMyIDB4ZmZmZmZmZmY4MGM4ZTgzMiBhdCB0cmFwX2ZhdGFsKzB4M2EyCiMzIDB4 ZmZmZmZmZmY4MGM4ZWIwOSBhdCB0cmFwX3BmYXVsdCsweDJjOQojNCAweGZmZmZmZmZmODBj OGUyOTYgYXQgdHJhcCsweDVlNgojNSAweGZmZmZmZmZmODBjNzU1MzIgYXQgY2FsbHRyYXAr MHg4ClVwdGltZTogMm0zNXMKRHVtcGluZyAyODIgb3V0IG9mIDM5MTkgTUI6Li42JS4uMTIl Li4yMyUuLjM0JS4uNDYlLi41MSUuLjYzJS4uNzQlLi44NSUuLjkxJQoKLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCmtlcm5lbCBjb25maWcKCm9wdGlvbnMJQ09ORklHX0FVVE9HRU5FUkFURUQKaWRl bnQJR0VORVJJQwptYWNoaW5lCWFtZDY0CmNwdQlIQU1NRVIKbWFrZW9wdGlvbnMJV0lUSF9D VEY9MQptYWtlb3B0aW9ucwlERUJVRz0tZwpvcHRpb25zCVhFTkhWTQpvcHRpb25zCVVTQl9E RUJVRwpvcHRpb25zCUFUSF9FTkFCTEVfMTFOCm9wdGlvbnMJQUhfQVI1NDE2X0lOVEVSUlVQ VF9NSVRJR0FUSU9OCm9wdGlvbnMJQUhfU1VQUE9SVF9BUjU0MTYKb3B0aW9ucwlJRUVFODAy MTFfU1VQUE9SVF9NRVNICm9wdGlvbnMJSUVFRTgwMjExX0FNUERVX0FHRQpvcHRpb25zCUlF RUU4MDIxMV9ERUJVRwpvcHRpb25zCVNDX1BJWEVMX01PREUKb3B0aW9ucwlWRVNBCm9wdGlv bnMJQUhEX1JFR19QUkVUVFlfUFJJTlQKb3B0aW9ucwlBSENfUkVHX1BSRVRUWV9QUklOVApv cHRpb25zCUFUQV9TVEFUSUNfSUQKb3B0aW9ucwlTTVAKb3B0aW9ucwlLREJfVFJBQ0UKb3B0 aW9ucwlLREIKb3B0aW9ucwlJTkNMVURFX0NPTkZJR19GSUxFCm9wdGlvbnMJRERCX0NURgpv cHRpb25zCUtEVFJBQ0VfSE9PS1MKb3B0aW9ucwlLRFRSQUNFX0ZSQU1FCm9wdGlvbnMJTUFD Cm9wdGlvbnMJUFJPQ0RFU0MKb3B0aW9ucwlDQVBBQklMSVRJRVMKb3B0aW9ucwlDQVBBQklM SVRZX01PREUKb3B0aW9ucwlBVURJVApvcHRpb25zCUhXUE1DX0hPT0tTCm9wdGlvbnMJS0JE X0lOU1RBTExfQ0RFVgpvcHRpb25zCVBSSU5URl9CVUZSX1NJWkU9MTI4Cm9wdGlvbnMJX0tQ T1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HCm9wdGlvbnMJU1lTVlNFTQpvcHRpb25zCVNZU1ZN U0cKb3B0aW9ucwlTWVNWU0hNCm9wdGlvbnMJU1RBQ0sKb3B0aW9ucwlLVFJBQ0UKb3B0aW9u cwlTQ1NJX0RFTEFZPTUwMDAKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDcKb3B0aW9ucwlDT01Q QVRfRlJFRUJTRDYKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDUKb3B0aW9ucwlDT01QQVRfRlJF RUJTRDQKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDMyCm9wdGlvbnMJR0VPTV9MQUJFTApvcHRp b25zCUdFT01fUkFJRApvcHRpb25zCUdFT01fUEFSVF9HUFQKb3B0aW9ucwlQU0VVRE9GUwpv cHRpb25zCVBST0NGUwpvcHRpb25zCUNEOTY2MApvcHRpb25zCU1TRE9TRlMKb3B0aW9ucwlO RlNfUk9PVApvcHRpb25zCU5GU0xPQ0tECm9wdGlvbnMJTkZTRApvcHRpb25zCU5GU0NMCm9w dGlvbnMJTURfUk9PVApvcHRpb25zCVFVT1RBCm9wdGlvbnMJVUZTX0dKT1VSTkFMCm9wdGlv bnMJVUZTX0RJUkhBU0gKb3B0aW9ucwlVRlNfQUNMCm9wdGlvbnMJU09GVFVQREFURVMKb3B0 aW9ucwlGRlMKb3B0aW9ucwlTQ1RQCm9wdGlvbnMJVENQX09GRkxPQUQKb3B0aW9ucwlJTkVU NgpvcHRpb25zCUlORVQKb3B0aW9ucwlQUkVFTVBUSU9OCm9wdGlvbnMJU0NIRURfVUxFCm9w dGlvbnMJTkVXX1BDSUIKb3B0aW9ucwlHRU9NX1BBUlRfTUJSCm9wdGlvbnMJR0VPTV9QQVJU X0VCUl9DT01QQVQKb3B0aW9ucwlHRU9NX1BBUlRfRUJSCm9wdGlvbnMJR0VPTV9QQVJUX0JT RApkZXZpY2UJaXNhCmRldmljZQltZW0KZGV2aWNlCWlvCmRldmljZQl1YXJ0X25zODI1MApk ZXZpY2UJY3B1ZnJlcQpkZXZpY2UJYWNwaQpkZXZpY2UJcGNpCmRldmljZQlmZGMKZGV2aWNl CWFoY2kKZGV2aWNlCWF0YQpkZXZpY2UJbXZzCmRldmljZQlzaWlzCmRldmljZQlhaGMKZGV2 aWNlCWFoZApkZXZpY2UJZXNwCmRldmljZQlocHRpb3AKZGV2aWNlCWlzcApkZXZpY2UJbXB0 CmRldmljZQltcHMKZGV2aWNlCXN5bQpkZXZpY2UJdHJtCmRldmljZQlhZHYKZGV2aWNlCWFk dwpkZXZpY2UJYWljCmRldmljZQlidApkZXZpY2UJaXNjaQpkZXZpY2UJc2NidXMKZGV2aWNl CWNoCmRldmljZQlkYQpkZXZpY2UJc2EKZGV2aWNlCWNkCmRldmljZQlwYXNzCmRldmljZQlz ZXMKZGV2aWNlCWFtcgpkZXZpY2UJYXJjbXNyCmRldmljZQljaXNzCmRldmljZQlkcHQKZGV2 aWNlCWhwdG12CmRldmljZQlocHRucgpkZXZpY2UJaHB0cnIKZGV2aWNlCWhwdDI3eHgKZGV2 aWNlCWlpcgpkZXZpY2UJaXBzCmRldmljZQltbHkKZGV2aWNlCXR3YQpkZXZpY2UJdHdzCmRl dmljZQlhYWMKZGV2aWNlCWFhY3AKZGV2aWNlCWFhY3JhaWQKZGV2aWNlCWlkYQpkZXZpY2UJ bWZpCmRldmljZQltbHgKZGV2aWNlCXR3ZQpkZXZpY2UJYXRrYmRjCmRldmljZQlhdGtiZApk ZXZpY2UJcHNtCmRldmljZQlrYmRtdXgKZGV2aWNlCXZnYQpkZXZpY2UJc3BsYXNoCmRldmlj ZQlzYwpkZXZpY2UJYWdwCmRldmljZQljYmIKZGV2aWNlCXBjY2FyZApkZXZpY2UJY2FyZGJ1 cwpkZXZpY2UJdWFydApkZXZpY2UJcHBjCmRldmljZQlwcGJ1cwpkZXZpY2UJbHB0CmRldmlj ZQlwcGkKZGV2aWNlCXB1YwpkZXZpY2UJYnhlCmRldmljZQlkZQpkZXZpY2UJZW0KZGV2aWNl CWlnYgpkZXZpY2UJaXhnYmUKZGV2aWNlCWxlCmRldmljZQl0aQpkZXZpY2UJdHhwCmRldmlj ZQl2eApkZXZpY2UJbWlpYnVzCmRldmljZQlhZQpkZXZpY2UJYWdlCmRldmljZQlhbGMKZGV2 aWNlCWFsZQpkZXZpY2UJYmNlCmRldmljZQliZmUKZGV2aWNlCWJnZQpkZXZpY2UJY2FzCmRl dmljZQlkYwpkZXZpY2UJZXQKZGV2aWNlCWZ4cApkZXZpY2UJZ2VtCmRldmljZQlobWUKZGV2 aWNlCWptZQpkZXZpY2UJbGdlCmRldmljZQltc2sKZGV2aWNlCW5mZQpkZXZpY2UJbmdlCmRl dmljZQlwY24KZGV2aWNlCXJlCmRldmljZQlybApkZXZpY2UJc2YKZGV2aWNlCXNnZQpkZXZp Y2UJc2lzCmRldmljZQlzawpkZXZpY2UJc3RlCmRldmljZQlzdGdlCmRldmljZQl0bApkZXZp Y2UJdHgKZGV2aWNlCXZnZQpkZXZpY2UJdnIKZGV2aWNlCXdiCmRldmljZQl4bApkZXZpY2UJ Y3MKZGV2aWNlCWVkCmRldmljZQlleApkZXZpY2UJZXAKZGV2aWNlCWZlCmRldmljZQlzbgpk ZXZpY2UJeGUKZGV2aWNlCXdsYW4KZGV2aWNlCXdsYW5fd2VwCmRldmljZQl3bGFuX2NjbXAK ZGV2aWNlCXdsYW5fdGtpcApkZXZpY2UJd2xhbl9hbXJyCmRldmljZQlhbgpkZXZpY2UJYXRo CmRldmljZQlhdGhfcGNpCmRldmljZQlhdGhfaGFsCmRldmljZQlhdGhfcmF0ZV9zYW1wbGUK ZGV2aWNlCWlwdwpkZXZpY2UJaXdpCmRldmljZQlpd24KZGV2aWNlCW1hbG8KZGV2aWNlCW13 bApkZXZpY2UJcmFsCmRldmljZQl3aQpkZXZpY2UJd3BpCmRldmljZQlsb29wCmRldmljZQly YW5kb20KZGV2aWNlCXBhZGxvY2tfcm5nCmRldmljZQlyZHJhbmRfcm5nCmRldmljZQlldGhl cgpkZXZpY2UJdmxhbgpkZXZpY2UJdHVuCmRldmljZQltZApkZXZpY2UJZ2lmCmRldmljZQlm YWl0aApkZXZpY2UJZmlybXdhcmUKZGV2aWNlCWJwZgpkZXZpY2UJdWhjaQpkZXZpY2UJb2hj aQpkZXZpY2UJZWhjaQpkZXZpY2UJeGhjaQpkZXZpY2UJdXNiCmRldmljZQl1a2JkCmRldmlj ZQl1bWFzcwpkZXZpY2UJc291bmQKZGV2aWNlCXNuZF9jbWkKZGV2aWNlCXNuZF9jc2EKZGV2 aWNlCXNuZF9lbXUxMGt4CmRldmljZQlzbmRfZXMxMzd4CmRldmljZQlzbmRfaGRhCmRldmlj ZQlzbmRfaWNoCmRldmljZQlzbmRfdmlhODIzMwpkZXZpY2UJbW1jCmRldmljZQltbWNzZApk ZXZpY2UJc2RoY2kKZGV2aWNlCXZpcnRpbwpkZXZpY2UJdmlydGlvX3BjaQpkZXZpY2UJdnRu ZXQKZGV2aWNlCXZpcnRpb19ibGsKZGV2aWNlCXZpcnRpb19zY3NpCmRldmljZQl2aXJ0aW9f YmFsbG9vbgpkZXZpY2UJaHlwZXJ2CmRldmljZQl4ZW5wY2kKZGV2aWNlCXZteAoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCmRkYiBjYXB0dXJlIGJ1ZmZlcgoKZGRiOiBkZGJfY2FwdHVyZToga3Zt X25saXN0Cg== --------------020303030809090808000405 Content-Type: text/plain; charset=UTF-8; name="info" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="info" RHVtcCBoZWFkZXIgZnJvbSBkZXZpY2U6IC9kZXYvYWRhMHAyCiAgQXJjaGl0ZWN0dXJlOiBh bWQ2NAogIEFyY2hpdGVjdHVyZSBWZXJzaW9uOiAxCiAgRHVtcCBMZW5ndGg6IDMxNzQ0CiAg QmxvY2tzaXplOiA1MTIKICBEdW1wdGltZTogVHVlIE5vdiAxNyAwOTo0NDowNSAyMDE1CiAg SG9zdG5hbWU6IG5hY2h0c2NoYXR0ZW4ucHVycGxla3Jha2VuLmNvbQogIE1hZ2ljOiBGcmVl QlNEIFRleHQgRHVtcAogIFZlcnNpb24gU3RyaW5nOiBGcmVlQlNEIDExLjAtQ1VSUkVOVCAj MCByMjkwNzQ0KzcxZjE2MGUobWFzdGVyKTogRnJpIE5vdiAxMyAxODozMjo0OCBDRVQgMjAx NQogICAgcm9vdEBuYWNodHNjaGF0dGVuLnB1cnBsZWtyYWtlbi5jb206L3Vzci9vYmovdXNy L3NyYy9zeXMvR0VORVJJQwogIFBhbmljIFN0cmluZzogYm9ndXMgcmVmY250IDAgb24gbGxl IDB4ZmZmZmY4MDAwM2QzYzgwMAogIER1bXAgUGFyaXR5OiA0MTI2NzY3MTkzCiAgQm91bmRz OiA4CiAgRHVtcCBTdGF0dXM6IGdvb2QK --------------020303030809090808000405-- From owner-freebsd-current@freebsd.org Tue Nov 17 11:04:40 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3F0AA2FE94 for ; Tue, 17 Nov 2015 11:04:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 666421E97; Tue, 17 Nov 2015 11:04:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmww144 with SMTP id w144so20275964wmw.0; Tue, 17 Nov 2015 03:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=+WfF6dzZ7Muh2rQ/GeQaLef2hjMrK0p7+eevM+dPUqM=; b=SK4MohLtj5U9o1gUWftYAafUUTC1jJHHF8fveT2KcWNhaDmkwsmxLfSOlbeJ/FpgKA l0oQC/GvIFA7k/Ea0lhFbd02xmlBA9g39TMpwUSVDWBbMTIyjOIwMHIKkEYUt2Xz3LVu 8kX6Qf/GLwm4e/WH0toHsp6bnmETYtdGqd7ucZj2Xn2Oa2k0Lz0VY/8CR9fyW5miuEmk WkpkinkGpjzjOcAnyd7RjG98Gk5dh/5y4e8jYG9qlvg4QkRQ7oszVEmJx9Yo+I7luFlm KByoVhIOrt39MsQkhthzD6D4RJHP4sWuXDizljQ+F90KmOR1R6zJQ1bdZysW45cNwGkM TOBA== X-Received: by 10.194.95.65 with SMTP id di1mr50147623wjb.134.1447758277665; Tue, 17 Nov 2015 03:04:37 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id n127sm12097864wmf.12.2015.11.17.03.04.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2015 03:04:36 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 17 Nov 2015 12:04:34 +0100 From: Baptiste Daroussin To: NGie Cooper Cc: freebsd-current Current , Bryan Drewery Subject: Re: make installworld failing with locales due to broken symlinks Message-ID: <20151117110433.GC59189@ivaldir.etoilebsd.net> References: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: <94D9C31A-2FDF-4B5C-99AE-847FED0DE859@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 11:04:41 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2015 at 05:57:52PM -0800, NGie Cooper wrote: > Hi, > I run into this error when running `make installworld` with a world inst= alled prior and during the projects/collation merge to head =E2=80=94 reaso= n is that the target for the symlink doesn=E2=80=99t exist. This might be f= allout from recent build changes, or a side effect of the broken symlinks= =E2=80=A6 > Thanks, > -NGie >=20 > install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or dir= ectory > *** Error code 71 >=20 > Stop. > make[5]: stopped in /usr/src/git/share/ctypedef > *** Error code 1 >=20 > Stop. > make[4]: stopped in /usr/src/git/share > *** Error code 1 >=20 > Stop. > make[3]: stopped in /usr/src/git > *** Error code 1 >=20 > Stop. > make[2]: stopped in /usr/src/git > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/src/git > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src/git > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 /usr/share/locale/ca_IT.ISO885= 9-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE > $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > /usr/share/locale/la_LN.ISO8859-1 > $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE` > ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory There is a bug in install(1) basically it tries to follow symlinks when installing a file instead of replacing the symlink with the said file. In the current case the problem is la_LN.ISO8859-1 has been removed before,= so the previous symlink is a dead symlink meaning install(1) fails to open it = and die here is a proposal for a fix: https://reviews.freebsd.org/D4191 Best regards, Bapt --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZLCcEACgkQ8kTtMUmk6EyfWACeMLk0/ftdfS8zYezz1tPRnbqa /u4AoKUPOtYRyos33qEZEgtQ47/Yd6Ll =h/9p -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From owner-freebsd-current@freebsd.org Tue Nov 17 13:35:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33F04A3196F for ; Tue, 17 Nov 2015 13:35:33 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C10DA1DC9; Tue, 17 Nov 2015 13:35:32 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.166] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id 8E619126BB; Tue, 17 Nov 2015 15:35:30 +0200 (EET) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <564AED8B.4080809@freebsd.org> Date: Tue, 17 Nov 2015 15:35:29 +0200 Cc: freebsd-current@freebsd.org Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564AED8B.4080809@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 13:35:33 -0000 > On 17 Nov 2015, at 11:04, Julian Elischer > wrote: >=20 > Personally I would have liked it if in '91 we had followed one very = serious suggestion, > and implemented every user command as a base 'library', and a tcl = wrapper script that gave the external behaviour. then every command = could have been made extensible to output various formats etc. by having = an alternate tcl script to run in that case >> believe it is being pushed by Juniper to make it easier to make = appliances, but I'm not sure I remember correctly. >>I remember that there was a set of slides somewhere that give the = justifications and thinking behind it. Well, I would have loved if that would have come to pass. 24 years of = potential framework development . I guess libxo solves some corner cases very well, such as the problem of = =E2=80=9Chow can we with the least possible effort get information from = OS and display it in www based GUI. Juniper can further help FreeBSD by donating the code of their system = management daemon and their fine granularity permissions system. Most = likely the BSDs could reuse a component like this, given it was battle = tested in Juniper products, even if it would need adaptation and = re-factoring to fit the management needs of a general purpose OS.=20 I am grateful for =E2=80=94libxo, but I would be much more grateful = for a something like a management daemon and a fine granularity = permission system.=20 That would be a substantial contribution.=20 From owner-freebsd-current@freebsd.org Tue Nov 17 14:34:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82987A31764 for ; Tue, 17 Nov 2015 14:34:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 73CC8123B; Tue, 17 Nov 2015 14:34:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 50F8E990; Tue, 17 Nov 2015 14:34:01 +0000 (UTC) Date: Tue, 17 Nov 2015 14:34:00 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1510276266.43.1447770841201.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2134787324.41.1447738491658.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2134787324.41.1447738491658.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1703 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 14:34:01 -0000 FreeBSD_HEAD-tests - Build #1703 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1703/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1703/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1703/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Tue Nov 17 16:04:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7700AA30F62 for ; Tue, 17 Nov 2015 16:04:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4292B19F3 for ; Tue, 17 Nov 2015 16:04:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by ioir85 with SMTP id r85so23134790ioi.1 for ; Tue, 17 Nov 2015 08:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0q+jmYKce+UFqqwod75Cgco/ciuPd6aLV9vnHBkrRUQ=; b=kEpcy/dhzNku7fCtcs01GOF6J6YapNGWSItDEu+y8QeWbhjq/o228SdMM9VO09kUU6 gfoydX7mo8B1+deBch62TS7B9VFkWKbM4kWaDYopNwPhVI1CBLqtYxH3wE1KeDMtjwlJ kuNdyT9xKzqrJHGmaySLkXooYJXVixsum14/q6x+lKhDC7WCdaI2bWHnVaITLzpUUnz1 GcKBpUTobTGdXxz4vhcIowGtNG9HDwzKLV3nAoE/fyYiKmaaFdHtl6xRW3jwBWFmx1Uy vMae/mZsQesX1YU37IkFY9L5TzENtmilA4Z2tKnthAJROk0HgX6q7T1yfKZ7tbsFZe9D qp3w== MIME-Version: 1.0 X-Received: by 10.107.16.144 with SMTP id 16mr46897093ioq.119.1447776275527; Tue, 17 Nov 2015 08:04:35 -0800 (PST) Received: by 10.36.222.198 with HTTP; Tue, 17 Nov 2015 08:04:35 -0800 (PST) In-Reply-To: References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> Date: Tue, 17 Nov 2015 10:04:35 -0600 Message-ID: Subject: Re: CFT: uintmax_t rman From: Justin Hibbits To: Benjamin Kaduk Cc: Warner Losh , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 16:04:36 -0000 On Mon, Nov 16, 2015 at 6:25 PM, Benjamin Kaduk wrote: > On Mon, 16 Nov 2015, Warner Losh wrote: > >> > >> > On Nov 15, 2015, at 9:13 PM, Justin Hibbits wro= te: >> > >> > (Attempted to send this yesterday, but appears it didn't go through. = Apologies if it really did go through). >> > >> > As part of a project getting FreeBSD on the Freescale P5020 SoC, I inc= reased the width of resources, from u_long(32 bits on 32-bit archs, 64 bits= on 64-bit archs) to uintmax_t (currently 64 bits on all archs). I have it= working on PowerPC, but have not tested it on any other architecture, I ha= ve no other systems to test it with, so I need help. This passes a tinderb= ox build. I need this tested on other archs, the more the better, especial= ly i386, including PAE. >> > >> > It should be effectively a no-op on most architectures, especially 64-= bit archs, though there were some checks I found in x86 code clamping addre= ss checks to under 4GB, commented as necessary purely for rman. If this is= n't the case, and we can't yet handle the checks being removed, they can go= in, but that needs testing. It should apply cleanly to recent head. >> >> I like the idea. There=E2=80=99s nothing offensive enough in the diffs t= o comment upon here (though I suppose I could see a few spots one could qui= bble over if one were so inclined). >> >> I wonder, though, why not make its own typedef, even if it is just >> =E2=80=98typedef man_res_t uintmax_t;=E2=80=99 in the rman headers? > > Channeling my inner bde (maybe?), the typedef is probably helpful, but > uintmax_t seems less so. uintmax_t has no guaranteed ABI, so a > fixed-width type like uint64_t seems beter, assuming that uintmax_t is > currently uint64_t everywhere (which I think is the case but did not > verify). > > -Ben I'm not opposed to a typedef for this, bde suggested I just use straight uintmax_t, so it's a good starting point for wider testing. I'm fine with anything as long as it's guaranteed to be the largest integer size (uintmax_t guarantees that, so any typedef of that is sufficient for me). Any name suggestions are appreciated, but what I want more than that right now is testing. Hammer the hell out of this on as wide a variety of platforms as anyone can, to make sure it doesn't break in odd cases. If typedefs are desired, it's no more work than a simple sed plus a single added line. If this breaks anything, that's the bigger problem. - Justin From owner-freebsd-current@freebsd.org Tue Nov 17 16:41:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6A12A31910 for ; Tue, 17 Nov 2015 16:41:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97DFE17E3 for ; Tue, 17 Nov 2015 16:41:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioir85 with SMTP id r85so24406569ioi.1 for ; Tue, 17 Nov 2015 08:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mff3BCGn3QQYKjRbLksI6HCSUNgAFfRXyr0MszcFNfU=; b=KoDEdjlnR691m1kXrJV6hC59FiJfu7V/EPe631UtXTOCJb6kGVFgb2Zwnde2ShRVwD vNQyG5fDDBqfdA6olOk6tjtiYRH/dqvc/0+/tRiqae4PXUltdqm4yVTmq24foeBY8s0P LJx/vrxCubM76Dc07s461ABOmqh+VMUCioFEFpjKBTBL910zh4JT0wzxy9r8ziS5GvFK 9HhYCIqSz4dEby8tdkT+i63Blgz4CmpyzepB4IdnmExlD1PysLH72hNHWxmXS4uG62H0 tEE4yp7qDXYmUEZP8nEw9fc8qfYjMsCIBSInR6drbR1sdTlnIl8M5JjtZPGVmMVDDDpw kqDw== MIME-Version: 1.0 X-Received: by 10.107.11.147 with SMTP id 19mr13032546iol.165.1447778510754; Tue, 17 Nov 2015 08:41:50 -0800 (PST) Received: by 10.36.217.196 with HTTP; Tue, 17 Nov 2015 08:41:50 -0800 (PST) In-Reply-To: References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> Date: Tue, 17 Nov 2015 08:41:50 -0800 Message-ID: Subject: Re: CFT: uintmax_t rman From: Adrian Chadd To: Justin Hibbits Cc: Benjamin Kaduk , Warner Losh , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 16:41:51 -0000 [snip] emulators! emulators emulators emulators emulators emulators! You can emulate x86 (32, 64 bit) on your ppc via qemu-devel. I know that mips, mipsel, mips64, mips64el all work via qemu-system-*. sparc64 is .. coming. I'm not sure about arm, but I know arm64 can run in the emulator fine. So hm, can you automate firing things up in emulators? -adrian From owner-freebsd-current@freebsd.org Tue Nov 17 16:42:43 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49EDCA31B3B for ; Tue, 17 Nov 2015 16:42:43 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0104.outbound.protection.outlook.com [157.56.111.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1A5C197D; Tue, 17 Nov 2015 16:42:42 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from DM2PR0501CA0021.namprd05.prod.outlook.com (10.162.29.159) by BY1PR0501MB1383.namprd05.prod.outlook.com (10.160.107.141) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 16:42:40 +0000 Received: from BL2FFO11OLC007.protection.gbl (2a01:111:f400:7c09::185) by DM2PR0501CA0021.outlook.office365.com (2a01:111:e400:5148::31) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Tue, 17 Nov 2015 16:42:39 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BL2FFO11OLC007.mail.protection.outlook.com (10.173.160.142) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 17 Nov 2015 16:42:39 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 17 Nov 2015 08:42:37 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAHGgYD74260; Tue, 17 Nov 2015 08:42:34 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 287AB580A9; Tue, 17 Nov 2015 08:42:34 -0800 (PST) To: Dan Partelly CC: Julian Elischer , , Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? In-Reply-To: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564AED8B.4080809@freebsd.org> Comments: In-reply-to: Dan Partelly message dated "Tue, 17 Nov 2015 15:35:29 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22654.1447778554.1@chaos> Date: Tue, 17 Nov 2015 08:42:34 -0800 Message-ID: <29711.1447778554@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC007; 1:Xav4UOfJ2vZEkhHaPSFoBETkkFK9+O9GkxsFWE9QV1s8qjaDhdQFzmX/ehemDp5i24GzHlulkSx4+A91fl7BDcwbMoHN5x/HQ4YbfyHHGWP3joMMt/5rBCCBCzUvI+RnFXpikbTV3yJLDpj/7/h3U4KCmrHmLiXRir5QGnW8/HwCeHy1GXzKKl9AU7aoKGWg6xIg4zYHFNF3ZCBb6u4kEDur72cdGiYV1mOv74wQA9PMMEi0FVaTPQ0pH/nEocqVgrcym2TA7DHks1u5XgBhQponKPfZflHT8Fsx/sK2ofNzjPpnC5oyvdRXlBWJ30E63lY/IwhCXbq/PVeJ5j+CnaeIKt09evdYoJFVd7CDPDIQvZ+XuR6yDUIGwSgnSsTS X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(199003)(110136002)(189998001)(107886002)(586003)(69596002)(5001960100002)(19580395003)(50226001)(81156007)(50466002)(97736004)(2950100001)(47776003)(77096005)(23726002)(6806005)(50986999)(19580405001)(92566002)(33716001)(117636001)(57986006)(4001430100002)(97756001)(46406003)(106466001)(87936001)(5008740100001)(76506005)(76176999)(11100500001)(86362001)(5007970100001)(105596002)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1383; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1383; 2:pF7Z1A/1XnGnL6bE7US2Z+KrA1loBKxK+oD1kKSKJ6q/miBVKX2Kgr9ebVk5RuB0zmMJbznqbS0BYU8yEcpowQ+0YZ4clMNcSmoUTNDXmCD3n2iu7A8dCnOVbJEPcaciUa4weB7h2f8ieCUoSy1BvB9NnXKY0TH73SPANsAPEtY=; 3:9Qws7ZstvcZM9l5FOd1XCurdWTxGQJpbmFrfXKQTtZ+s7CRH2e6JQ4U4TQYOGLxTkJ7Rvq98wX8fnI0C4O5OKMV69x35jF0RoFEot00dHhKjZhoyU6sircSBCyqIy2qQYgwatF/hrNBkVkPH+fDBLmhgkG68kN1h0vb8HNccD1s+qT6Kec2fY/bB27sAeAZCsChOvwdR/l55HIfnpBzoOaVFw+37y86BDNLAzfhgVNY=; 25:UxGgY74Cb5pYAm3F1pTrI0VogoI3lXc+a1gOmuDRgNF1GphBuswjdEng0+rwJ0DYjFot9PoSx4YoirXie+YuqR8tfTRis0eOBnG6Tt6h2tGFWQ2GTgohNbGUuKILOArSj7OzcEZaCAtH1BoS8luUzuRHPKO5hOE+lYEgp0WT2XdLBpjqZiGHI5rpfaBdMYznCxu8dC76S6hi9UunSU2wadykhH+xLZu3vYSb8xAuj4sgrDJLFweQXrmir81p6xX3 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1383; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1383; 20:UIs6xckBJH1PR9NC3RAGinAyHg6adxhcJAmBS5axxiA2AMHapc+R4fIO1C/SEKoiG7PBje4LFAtPg6//HJ9dVTMPDkLkQO+IE4IQwcdwH4DjsxWnOEu9tJqVIj2Ni4fuK5tzwJ9DgzHZWwungV6PlllgVSOPCiUTrY7pyI0rKz3/1hUQ60cxMyzl47bViqn/5HWfmdhWF1Ng/UTgVpGNoHswon0F6xmuoF2xWL738n/rMa81jU2cGM9K1C/NkhGfiYwasSthS2EacLh77PRYmDFgunf2t2zagC6sRIwyhpluJx1o3dSZjHPt3pQarriEDDiWSBrhVHEvnv6fGv0XNToAXMSb3ZPmbNmtcl0PeCB2ECnlnw2XdMk3Wika25sjJqNidkBVHIwx1GbzbCRDS+2G9alxLYCN3r7fuJ7XqbzfaInkXYR+hsLSH1VPQoZDnPdyoNQI8IBbjagHparmsnfYdnwPItTeimhGzYUX5Th0ACTKuWiSRyy41oYFXd67; 4:FgEkHbl4mKfOI6MR86+voQuVzDYYbZs1QQDY/+1M7Z3mgnAA9H54AjbhagMU6Ge/YifK8vVo3oSuIPWEsdKGFiub0fpCn3rYUcyxjhvK71MzIvx2dNkHakxXPu342LC6ucPnNn60a0z4JE98vHsaRT6frMDR+xuqx5dr94R4CSzItAeSj2+NFtYJwIfEp/SI/Xo8fZjUS27uidT8PUPdcc61tkMHFvYD30qabK2VF3rp7oYeFrSCafnYUSYwgYhxuegCipg6209JFTjGcxHOXg0f/iYOo9ifNdgFMQlcStU86W5pUR2kgAIxd/TBz8TPayFTeV7Ol0ZaE8icr/2NrRFT7PvzFnNcC+De9SwXjbaybQxUl/+G310bxCEH6cq+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BY1PR0501MB1383; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1383; X-Forefront-PRVS: 07630F72AD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1383; 23:bt4FNP/dYN0t+xbtrYQG7kQxH6y/U9ENmwLw6ho?= =?us-ascii?Q?oxMkCfe3/Ju8u+cjT8uXswfsSha3MV1yDNcC5GDqXGj3ZBGADkZ9tj9PcGUF?= =?us-ascii?Q?Pot9kw53f2pn5sTS7QhqdCwphgebyPnmfLlTBb0Jrm2zFseZcB9u8MLMh30Y?= =?us-ascii?Q?XuZTt73st9hI8KnLWwAofcy98qQ06VInhZ2v9D7LwJF6zksqhAJHdf0GwMwA?= =?us-ascii?Q?QWSo9uImNoRgEw9p+dxbPPsgsRFlVOUBSq5sE49/8sRehwl13eRLfiyzDkBG?= =?us-ascii?Q?2X0vBZ5dfVHuApqqfah2zIe/3MCMF8TaBLid7oS70nVul+JgNfizVY9bL4rn?= =?us-ascii?Q?zGN6YqBgWmuupKgYX4l9LmpQ0N3LgRoDpjjczTSX1Zik1WALWdSd7VH1Ls46?= =?us-ascii?Q?MRxxi/n5PPnhsEWIO2/DH13DNoETaoLHQzSyM9v/XubHu87D2mGytysxMtm+?= =?us-ascii?Q?+B21bPzTvYGseu5o3VinNEl00pyLAETJsZv/c2HYKBZxX2eGxy8BPPVNDNe4?= =?us-ascii?Q?hv/drwgGu6MysfTEKbhHWuJA750mFAf9lnQPK2ioUvmCz0920PeDBpvYSgI9?= =?us-ascii?Q?t50MeEbA/QQ+9aqabw/8wxr9X7vMO0CllkMTfUPU7lMWVtyMfrkZ/NO3LFRT?= =?us-ascii?Q?00Zvkr+AAdwna2u4pxDDMBnTuT18M2F++PNPkKxUIVwvBiEclMwrRdOVbvo4?= =?us-ascii?Q?371/V0NC6ISoiuWE0ezYcjjFhlTOzc7OEg9E459rBmFuZ3InhSX8W6xxcUq7?= =?us-ascii?Q?JRcnRtgRxTS4JPcaGjkSaMzq1jkWQSipbLhSX4VRhsi5Orx6YeZ7m14m/1uJ?= =?us-ascii?Q?Fvv0qUX6fmGsatNNt2LD4eFfcIyfUlyeVjs2wWAU7h4hMDtSGBWpN3voRyw/?= =?us-ascii?Q?0Bch2iV8TI3n1YrAhwQiqTmzj9QSEh6MaoaAXK5pZ474anyqR8W3yhOBUZiy?= =?us-ascii?Q?xaHEcwFEfGg00JMLzVlWV4mQs7hsdT1VXi7ARttyAPRfrKiIkt7ElWRFxjqu?= =?us-ascii?Q?Cq2V00vbRNj9hY+2+QwZPFLzCLOTqcnk0GlJNC0cJ5yFvzDQ0ruJqjjJBtQk?= =?us-ascii?Q?dK2YD9u8tCrF9doI30mGoIPmOqJME2M5ebUCC6q4pRtvglrWs0g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1383; 5:3mgJY7jlst3gECDIuDFgELtgt515JrAxQUFIrjN1hGMykAN5ZCLSMDQLjEQ4QEwYxib6/4lHf5cfVDHBxsgP3/pQ1HSWTaBgTCLwwolqbz4ZLKZmuPUVc2SEUpWezjkb6SZY76xELbQeRUitJ+2gEg==; 24:rPkEYSHFhUGEgf/23DWmqABYyYp1d1tdWoVOwtsgXI2NEBuF8QsZNYQ7x39RXtAwj0CRxv70/dfDnw1Ykp3UZcY7sWWK3UuIgiBzFCJGJ5E=; 20:6VyoaGhsqij+c2SxpQ4esGD8vA6MhDq59qaq+a3f2wGHw0TXyYKuVP603/adZYBaayk7dfAtHeSMxaukXXrmig== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2015 16:42:39.7904 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1383 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 16:42:43 -0000 Dan Partelly wrote: > Juniper can further help FreeBSD by donating the code of their > system management daemon and their fine granularity permissions At the cost of i18n etc? The Junos UI is totally data driven, syntax is verified term by term (since depending on your permissions some terms simply do not exist for you). Such a model cannot be successfully translated to other languages where the order of verbs and nouns differ for example. Everything I've read on the topic suggests that messages must be translated on at least phrase if not sentence granularity for reasonable results, and that just doesn't fit our UI. Thus enhancement requests for i18n are politely rejected. From owner-freebsd-current@freebsd.org Tue Nov 17 16:42:57 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA9F5A31B53 for ; Tue, 17 Nov 2015 16:42:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A82941A15 for ; Tue, 17 Nov 2015 16:42:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcph11 with SMTP id ph11so82808979igc.1 for ; Tue, 17 Nov 2015 08:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+Eng0U2t74RjxzVMA6WTpaRqWOcO1II+wg5B9g71GKE=; b=JDo5WVGtXyBKJcsm8fZk74z/JJyEOnoPQO53655+DmUhNv0q2AQqC+l1Fx/2DXd6Pm Bd3v+VaSzejDfKyuHsecpi7HTDLMctfBvQJ7xqqFPECP0QKcX3yJf0jzUdvYYiHsIY5o LAUtdNF/CqfkDnnQkEWfPaBDVR8lp3TE8AdqJajLW3yl8Acn47TaFPhteXznKEccPGfU GroFQrSQtu8iiYOPD95RQfpwx4elnp3vSHSgOrTqA5+sZg5on53VFVkdIL/Xfeu7kSZR dMpSz25N9aTK9qZMRvn6yMA8V/W/RXWJSR1ao3/CSSgP4vetBNDZoTS3wT2twmsZNmFF 47Sg== MIME-Version: 1.0 X-Received: by 10.50.62.104 with SMTP id x8mr2754829igr.22.1447778577037; Tue, 17 Nov 2015 08:42:57 -0800 (PST) Received: by 10.36.217.196 with HTTP; Tue, 17 Nov 2015 08:42:56 -0800 (PST) In-Reply-To: <564AF74A.2090700@snakeoilproductions.net> References: <564AF74A.2090700@snakeoilproductions.net> Date: Tue, 17 Nov 2015 08:42:56 -0800 Message-ID: Subject: Re: Panic while waiting on wlan0 From: Adrian Chadd To: Florian Limberger Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 16:42:57 -0000 hiya! try updating to head as of today. Some callout issues were fixed. Thanks! -a On 17 November 2015 at 01:45, Florian Limberger wrote: > Hi, > > I am running -CURRENT on my Lenovo T410 notebook since nearly a year now = and > am now experiencing my first reliable occuring panic. Since I am interes= ted > into getting more involved, I want not only to give a report on this, but > ask for directions on how I can help to fix the issue. > > The crash occurs on bad wifi reception, either on startup, if =E2=80=9Cwa= iting 30s > for default interface=E2=80=9D is not interrupted, or at a later point if= the > wpa_supplicant is not able to establish a connection (mostly due to a wro= ng > passphrase, which is not the case if the wifi reception is better). > Core.txt and the dump info are attached. > > I am using git commit 71f160e0193fee45242bebeff7f1282846e83d2c. > > Best regards, > > > florian > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Tue Nov 17 16:57:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B540A31E85 for ; Tue, 17 Nov 2015 16:57:00 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 269E814A8 for ; Tue, 17 Nov 2015 16:57:00 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by iouu10 with SMTP id u10so25345059iou.0 for ; Tue, 17 Nov 2015 08:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2tZ8ffqmWghVzHI5gtNne/K1dnapykw1V3WYPIZ8niw=; b=FaADB61bB0o3FxmidPLGFS+tE40nc+WXiS2dWWoINlUkOTlBIa5Y1PWSpOofCqVYjC ovJRQOqm6Y4tjf6ASkeGciCDWBcA9MkO5F+DyfPNOiWJutf0LN3f3xJX2GrQzkV/RiNo Wb3WP6dQ/TxiFc426aOz6Ep7Vu2s9wCsMzhd/L1MTdY7QtYDRsPUIkZDxxSBvdi/+tup 1Jv4gjQ076EBLC2ekbmykYM8T4/EhYsKxCDASI5EDE7CtV6F2wTPX540et+awNBl+D4V 5jzCcN4QNeEfgflp/Cw6Q9ARjL+rdcgj9rJ/D7oB27e0cuVMzI8PBzuN8LC5sUfQl9PB NGHQ== MIME-Version: 1.0 X-Received: by 10.107.4.70 with SMTP id 67mr28285480ioe.13.1447779419698; Tue, 17 Nov 2015 08:56:59 -0800 (PST) Received: by 10.36.222.198 with HTTP; Tue, 17 Nov 2015 08:56:59 -0800 (PST) In-Reply-To: References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> Date: Tue, 17 Nov 2015 10:56:59 -0600 Message-ID: Subject: Re: CFT: uintmax_t rman From: Justin Hibbits To: Adrian Chadd Cc: Benjamin Kaduk , Warner Losh , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 16:57:00 -0000 On Tue, Nov 17, 2015 at 10:41 AM, Adrian Chadd wrote: > [snip] > > emulators! emulators emulators emulators emulators emulators! > > You can emulate x86 (32, 64 bit) on your ppc via qemu-devel. > I know that mips, mipsel, mips64, mips64el all work via qemu-system-*. > sparc64 is .. coming. > I'm not sure about arm, but I know arm64 can run in the emulator fine. > > So hm, can you automate firing things up in emulators? > > > > -adrian Can I build a full bootable image for every arch without root privileges? There's no way that I'm going to build every architecture on my 10 year old dual core machine (where I have root), it'll take forever, so my only other option is to use the cluster, where I of course don't have root privileges. If I can type 'make universeimages' as non-root, then, sure, I'll take the time to boot test every target that'll boot in qemu. Otherwise, I don't have the time to do it, and that's where crowdtesting is advantageous. - Justin From owner-freebsd-current@freebsd.org Tue Nov 17 17:16:07 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C8A8A312E1 for ; Tue, 17 Nov 2015 17:16:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00D341EBE for ; Tue, 17 Nov 2015 17:16:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgea14 with SMTP id a14so10066931qge.0 for ; Tue, 17 Nov 2015 09:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dwMTm7ilNHU18MVCWw7JkBcKai/z+H9vtf4zu8hjFLI=; b=fD1y605XtmPd/n8+8YeHplH6vbYnBzaFO3yeicPKVzQ9krNXiJfeB7rRBL7Fjt0u6Q A770xbjpK6fi4oolc13JKaNylgw+Vmm/uFknAD/HMNP40KZlFPrmHnSPLQWJRLZVcHlK 6hscCIorKAj4e1mOhCgjujnSCkkrfne1KI4m9qwxh+QhaE8PpJoQkZbYpccCqcQ+3pGl 8LvY2uZBTot0NCRaMNUFreePNzbWgZKK3lFKOAgckm6cmHWGpCB4R2XXqdeH22gnKdgw POlESZ2HPYI88EDlsxOvr14mpq4RpC3+5LAjQ/Z6Vr12N6KA5hV2ProtLmKsaMuefObZ wgDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dwMTm7ilNHU18MVCWw7JkBcKai/z+H9vtf4zu8hjFLI=; b=BRBsdqlwqKXeqBUIW9kjTP8EqOO/W5MFYjsG9sdhgNigxGmYgsRjihf0Mqin0mG0A4 MDK+ffxS73tpR8lujhPl1QTUfXv8MKTMT5aEhkBHlY38Vri+CXXOlVrn+8OT9y/Icf6B xzcUk6i24o1hO7AYRgoD4gDt0pY0tqSPbIEUQbqrbUoNyHgFXGqIa7Nksi6kYnFSuGGH 3/hGsegdWzskjmIqKVgqyU74dIxqfvCDW1h34/x07irVoBIupXaNJ8cx5q11WHr+a9s3 xHu8VWGW0YsfCs1oKKw1zG2IS+7iCs1F/rvVWpiBAWUDJK5oTtbddEx3FZH5LlnupVNt xjJg== X-Gm-Message-State: ALoCoQnkaXvqwk6oys25HklYri1LZtKj8GguZE7o18NdnqbIfDanR1JrOfBHB1gOTc8z8/smLWK3 MIME-Version: 1.0 X-Received: by 10.140.41.210 with SMTP id z76mr42839592qgz.81.1447780565976; Tue, 17 Nov 2015 09:16:05 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Tue, 17 Nov 2015 09:16:05 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:8c5e:4a2a:5cfd:2bc3] In-Reply-To: References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> Date: Tue, 17 Nov 2015 10:16:05 -0700 X-Google-Sender-Auth: T7eo4H6n7zAO4Cs_V65E2n4i7QU Message-ID: Subject: Re: CFT: uintmax_t rman From: Warner Losh To: Justin Hibbits Cc: Adrian Chadd , Benjamin Kaduk , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 17:16:07 -0000 On Tue, Nov 17, 2015 at 9:56 AM, Justin Hibbits wrote: > On Tue, Nov 17, 2015 at 10:41 AM, Adrian Chadd > wrote: > > [snip] > > > > emulators! emulators emulators emulators emulators emulators! > > > > You can emulate x86 (32, 64 bit) on your ppc via qemu-devel. > > I know that mips, mipsel, mips64, mips64el all work via qemu-system-*. > > sparc64 is .. coming. > > I'm not sure about arm, but I know arm64 can run in the emulator fine. > > > > So hm, can you automate firing things up in emulators? > > > > > > > > -adrian > > Can I build a full bootable image for every arch without root > privileges? There's no way that I'm going to build every architecture > on my 10 year old dual core machine (where I have root), it'll take > forever, so my only other option is to use the cluster, where I of > course don't have root privileges. > > If I can type 'make universeimages' as non-root, then, sure, I'll take > the time to boot test every target that'll boot in qemu. Otherwise, I > don't have the time to do it, and that's where crowdtesting is > advantageous. > One can build a bootable image without root. However, it is currently poorly scripted at best. I have some changes to nanobsd that moves it in that direction, but I don't have config files for all the platforms, just the ones that I have on my desk right now :) I tend to agree that crowd-testing is a must here. You can run make universe w/o root permissions. But looking at the diffs, the only thing that makes this change at all risky is its scope. The change itself looks to be good and mostly mechanical. Warner From owner-freebsd-current@freebsd.org Tue Nov 17 17:36:46 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96215A317EE for ; Tue, 17 Nov 2015 17:36:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8793F1B6A; Tue, 17 Nov 2015 17:36:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8ED39A12; Tue, 17 Nov 2015 17:36:46 +0000 (UTC) Date: Tue, 17 Nov 2015 17:36:45 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <512656898.45.1447781806402.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1510276266.43.1447770841201.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1510276266.43.1447770841201.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1704 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 17:36:46 -0000 FreeBSD_HEAD-tests - Build #1704 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Tue Nov 17 18:00:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B86CA31E01 for ; Tue, 17 Nov 2015 18:00:59 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0135.outbound.protection.outlook.com [157.56.110.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A283E1604 for ; Tue, 17 Nov 2015 18:00:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BY2PR05CA037.namprd05.prod.outlook.com (10.141.250.27) by BY2PR05MB064.namprd05.prod.outlook.com (10.242.34.152) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 17 Nov 2015 18:00:49 +0000 Received: from BY2FFO11FD038.protection.gbl (207.46.163.236) by BY2PR05CA037.outlook.office365.com (10.141.250.27) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Tue, 17 Nov 2015 18:00:49 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 17 Nov 2015 18:00:48 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 17 Nov 2015 10:00:48 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAHI0UD51526; Tue, 17 Nov 2015 10:00:38 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 9AB51580A9; Tue, 17 Nov 2015 10:00:30 -0800 (PST) To: Dan Partelly CC: Adrian Chadd , freebsd-current , Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? In-Reply-To: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <26127.1447610752@chaos> <18325.1447711377@chaos> Comments: In-reply-to: Dan Partelly message dated "Tue, 17 Nov 2015 08:29:28 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19048.1447783230.1@chaos> Date: Tue, 17 Nov 2015 10:00:30 -0800 Message-ID: <4366.1447783230@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD038; 1:jEUwATnM5ZJnKuAupmyrkUYW432H71XSEAjgUoYatdKpfIEoPA4hI/7NjjuEOVMgAEUKG6pnrIiub/HLWj6TGtnKePzYWrv28MGieOGku0xUE2uJ2O3Y8k42MS2CSslK0Uwhs6NH4fMf5z8Yw2BVNg1hhkICke2sD9AO3FqqRNZBh0TSYMkh+ODarJW05eVbw0c1t2o5leqe3p0H6F1GU4zfrvvAb2bps7Jvvv4mUCgj+nGqkowupQeFFa88pBdX1Qvi+8azFoP+TprV+m/XFu9MB0EM/O+hgrYu/Ss/GMyZnejT/IlCUrJABNP3iiaLrROEiRBRWcDEn6yjXeHXLXxDATk7ZCejifaAiIWycmR7hWcmN+gLWVulg0fsZP/p X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(24454002)(6806005)(97736004)(76506005)(50466002)(69596002)(586003)(77096005)(2950100001)(97756001)(93886004)(86362001)(57986006)(19580395003)(76176999)(19580405001)(21840400001)(5007970100001)(50226001)(110136002)(33716001)(107886002)(87936001)(50986999)(4001430100002)(11100500001)(189998001)(23726002)(92566002)(5001960100002)(106466001)(117636001)(5008740100001)(105596002)(47776003)(81156007)(5001920100001)(46406003)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB064; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB064; 2:MvIFwlsuYdoFBrerzaGGlAh3kyIC+x3RC61kWh4XWba39e3izglI3WDJLqyiHZC9CumBFSkP7hcDvZ8Qhe7YxXYg9vBdal2S6cRI8uZPwMNyip3Zc9bK8JGLUtO3S/NOtvU6fEgSZtvomY+G78f9zFXN9o86v7BUglriEmm+DuY=; 3:pr42duL1/krcJtFi3fMlROAx0oQbdkcNIN1CmPU4eQhUrVjN3id/fB1Exe6yrN8at1jUnQULt7LgfAKqorc2IIkoIuaD4zn/Kw7s5onD9pHMSIS7SKejb/v6flYIZwO0xThSffzXU8fU/Ga50B6xTtx+LltkVLjBcl3kPbfMZTkdspzf8q7hBYqaTvDnUyoHcEmn5JyNRoKdB8tdQreNn2oKnrNRJgBBRIAD8r8IFBI=; 25:5Ibinph9uPEwkpz6yBbwoJVRgEF1PKmqwaryto0MS+80vzpBeeV5wDOriIvgnyEt5P20z6Y/2qPP1Qip2Kzyp3ElBDuYa5Mn2NziCL60WtqekxATIEZZGEQfFuoR/oNQUxk9eBQEK1xXnjERQZ2mOCZYBgjEiXrzIVqrx+h+KODZO6j5vZQP3SNcaTZvtKCxYtUP71Eb0TpJltGHZlhYk7iHXOT8vwTsAQMi3t5oX5i7w3UqbrlOZZyAmZfqWbwPzaV1RHs1hxj4FEyJ9groIA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB064; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB064; 20:Ne/yIq7CQYi65nQWT+8py8a5hQcDX/iYUkp+/hdhNykAA1J+6J9A53qwSmfZDCyaRnlJLZ8COJZFGXWe7w5psxTwgiiX049q6rWoR8pon6yS4B+c4NNcxOXbiinBTa8HRyx1Fw4tlW3ENlhbNUkbV62lwz8/QI5aOCFDHwtn1ooAXBYymLe89VQOs1d4qL9RbThZIw+jz2zii8qntPphT3rLepVCHwlXIjMinfO9DFubl9xFo++qXFAPqYUcLHs3TXU/AJ8d0jnS518AO3+YhvZLMp7M08rm4bsAywAEmEQPxGJT7GfCLDHpFOO2PMaZSF7MU0obrhwBDvdX1mXihvOHd0FVzRiSWTbBI6v9g7Y+ZyTeLq7vxEcb1xb4eVOz0odYoi3cLrb3oijvHKdrjkgvJmm83CWO2s3/fiF80fRiyacmJtQMTP8+R6dxWGMm72h6Q1iQaVQBMdjPaFgZ5xl1QXy9ReF2lkC4QflQ4I8XsWyBwp6n61EYypwU+LvA; 4:37FvQSggIvAQi3GaMZx2mmrmmmMqwEZEjmVrA/1yUgmJnqxxvONpVRqTbkL0mIOIfv0dd/QqW8Snz+Zzuwk2DD0kXCKf7PkzfwXTG6hGwGo1yM7QtXIetpLHYqbVXdAF0KvM2G+Cw9IhCj7bXBiEj4957dW3k4At9E4zWmeUY53msfTGUu8tVk+R3fSMmMHlIVeSntnJxTyaUqwvbNYvzRbjg5b0d1VF3MzXbZuW6BYxJnobGAIsAeGZpNfqXR7ofblttBOwBjJvjnZn7dbWFqitTGnxLHRpEZl4qp67LazG1z02jUlkyOITjh47AnP6qKutMnTqyOIdOHaZ5MkrOFTHlFQcQ1ugmjrTl3u5PWrduSSFLAKA5lRMFK6/1/iz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BY2PR05MB064; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB064; X-Forefront-PRVS: 07630F72AD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB064; 23:VFQXR69iO+IojgyxNvgmnNEodfOMxY9SUJycPzBLQU?= =?us-ascii?Q?4sm5bEIuQtJ1ntdBlZvpGv8F117RpyG8zZNXdd8MmujNR6pYNUgNpg1cHIMN?= =?us-ascii?Q?uC24jGnybQ6xRfCTCehQE4Qg/w7mliRO73iKAUXRkkJO/kcKZdTOfmKSu6uK?= =?us-ascii?Q?Dv9/AvxgDNlgJl0CnHET12ykjCNL7zumVpvwpxGRsUS2BJ6KgHHSUQhgZaYc?= =?us-ascii?Q?bSipwkboxLT4JnxWxVcy7znH25EhPtmEUpd2f3W3n8qOifzCTCYcTOESWfq+?= =?us-ascii?Q?rZUeTtnwL0bZRhr65Ry4qKNINITUdS3bveDscK36hWQn00g8GHmQ7PXMBSMa?= =?us-ascii?Q?MDlX/okfgZgKQZxpG/TIbUBe2fQUHVFiAtZpIaDEFFKhrE8ULudxl3PjBNvq?= =?us-ascii?Q?xAMvAisEOMdRrHx5R5s8Yf6qV7gXaF9QJXx2PM9FVxO5nRgt7u6j30nkI/P1?= =?us-ascii?Q?yAVmh9rwV9oD1DCxIQwDFArYpk0vjWZm7RE101j7AMToAsW1tAcB789+4zSK?= =?us-ascii?Q?8rWfG6HRHfUiLk1wrHwiXpGoI85CX8AR6n6jK4p0Ezj3kLRdL8Btuav6iNQ4?= =?us-ascii?Q?nnWmSv6ULlPRRa1UgKwbvXt5HNWbi4CsUc1++RKOAEFJ4MutO9egRa5I7jsf?= =?us-ascii?Q?9xph3XGK97HUBoTCHf8q0YuX30SzFRCQsJw72IOnusWjJXsQi57gx67hRfZT?= =?us-ascii?Q?HkutSOrEaOckviLWxNhplLW/w8m9CYiNRqPaGq5hlBtBi+Wf2cPXYyteB/Vh?= =?us-ascii?Q?wu/dmJuhEc5HoQmG0gYqVhSoMPHKrZe2wgyG+wTgRdPFLT7P+/Fzz0S0hmnB?= =?us-ascii?Q?jBB0DsAbTtKU/0oi0glukHbDhyPpiVsOjDvQYW8AVHc0mZqWiRlhCgpy7Ytc?= =?us-ascii?Q?nGHtKr/YXDCO+F4VZ5MMWDbE6/XwMPgExZwhrjbqBLbo7e+RrpMAYwUV2OtK?= =?us-ascii?Q?pVbmpjbt+BWvTqoTT4Z/71ifk2R9IYXJGTZzshRZxgA2MezhOIvQJHSPNc+C?= =?us-ascii?Q?KanDHLloceTt2EyazXOc3Vqg6Gu4sycV/B/809O+QythVilC5ZUl0l+ltG54?= =?us-ascii?Q?jTInuvypiSTAxYFb228yh2NhM5/IXN1LPy5y3/6HrDM2SadVZfMldL/CZ+ni?= =?us-ascii?Q?NYvKLcMR0Wif0eXjLADp/FbqRiUcM1WFixhtwNugCq9kgTVGFAasjkzNWBpt?= =?us-ascii?Q?2vRvPJlInB76Y=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB064; 5:hJLHz9BKpXSyNcGZ/FupClSOWRXrApeKUWICZOxOZpsVro4brkaXfABD+iGemx1A73i9iQ0QKTu8AQA47KZLbiI74RY9vNM5al1rTMKARhXVh+Bw3Mbbe+kfi2n9W4C8JUHnooQuAlqDxzY6FfHxWQ==; 24:3vFKuhqa+Uc5euMEzO5a+QXIfY0RBm1HHJ3SoUObbv3VQ2u6THCRUwoV8xJBfGVR5m55YHEaArDK/SS9Hf7XZ6LcV06KeL2VVw8voLqDF4w=; 20:CMZCq3zLzmVoQUq6vEnU5n2fdBd1by8rejdW/OIyR7VX+QbvFaZs70xBoiQz10as7itGpPTuMDNucuxyYATl7w== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2015 18:00:48.8084 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB064 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 18:00:59 -0000 Dan Partelly wrote: > Management daemon with fine grained permission, extremely > useful. Would Juniper consider donating to FreeBSD under a BSD license > portions of this code, the MGD, which could be reused in FreeBSD ? A Right now I suspect the answer to that might be "no". We know we have competitors who would dearly like that ;-) From owner-freebsd-current@freebsd.org Tue Nov 17 19:34:34 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 961E7A31131 for ; Tue, 17 Nov 2015 19:34:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B714164D; Tue, 17 Nov 2015 19:34:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmdw130 with SMTP id w130so169754818wmd.0; Tue, 17 Nov 2015 11:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Mp1ItW3lBYpExY54dZrfumBiGgFWhwnUQqHViXp342U=; b=aKlggANq6t7+R4BzNN16k+47Ze3OTK8fAMpqpReFEtHcXnbcfY96d3jq2qGTLPcj18 bV7rkZe1WzzaCl6zIuD/Nigp06MApT9yTXhK3Z4JjImHDJcctF4zXGnpSd4OwrPQIqru lOkliBCW1SognrQ6XyxReZDm6jbkXOR7N7waHtddchp9rDa0sqByIHYetdOvvR2mn6ci fjiEE7n+v8YGqPGwmPO0/swG6QveHFiRRbZnhRwlf4P52qRvXWQQZZKRG+4iH99cFOBJ id69cknJXXw+twJgQY0V3ecY5Pxs5cqfkEhevnpHDHaJlkLZZUF+fuHs7ebAbWDch2yM j2EA== X-Received: by 10.194.119.162 with SMTP id kv2mr44212830wjb.62.1447788871753; Tue, 17 Nov 2015 11:34:31 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id v196sm14966853wmv.10.2015.11.17.11.34.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2015 11:34:30 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 17 Nov 2015 20:34:29 +0100 From: Baptiste Daroussin To: jenkins-admin@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Re: FreeBSD_HEAD-tests - Build #1704 - Still Unstable Message-ID: <20151117193427.GA76612@ivaldir.etoilebsd.net> References: <1510276266.43.1447770841201.JavaMail.jenkins@jenkins-9.freebsd.org> <512656898.45.1447781806402.JavaMail.jenkins@jenkins-9.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <512656898.45.1447781806402.JavaMail.jenkins@jenkins-9.freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 19:34:34 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 17, 2015 at 05:36:45PM +0000, jenkins-admin@FreeBSD.org wrote: > FreeBSD_HEAD-tests - Build #1704 - Still Unstable: >=20 > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/170= 4/ > Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/= changes > Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704/c= onsole >=20 > Change summaries: >=20 > No changes >=20 >=20 > The failed test cases: >=20 > 1 tests failed. > FAILED: test-report.xml. >=20 > Error Message: >=20 Can someone fix that? or at least show which test is giving unicode in the output? Bapt --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZLgUMACgkQ8kTtMUmk6EywAQCguQY8VQYCTuSLv7Y03S2icIff aRoAoIqXbUIi7NIqYOjzX95HGkosW8TV =/Sq+ -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@freebsd.org Tue Nov 17 20:03:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75EFBA3192F for ; Tue, 17 Nov 2015 20:03:05 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: from FreeBSD.cs.nctu.edu.tw (freebsd2.cs.nctu.edu.tw [140.113.17.206]) by mx1.freebsd.org (Postfix) with ESMTP id 603C31BF0; Tue, 17 Nov 2015 20:03:03 +0000 (UTC) (envelope-from lwhsu@FreeBSD.cs.nctu.edu.tw) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id 8E6EC220F; Wed, 18 Nov 2015 04:00:55 +0800 (CST) Date: Wed, 18 Nov 2015 04:00:55 +0800 From: Li-Wen Hsu To: Baptiste Daroussin Cc: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: FreeBSD_HEAD-tests - Build #1704 - Still Unstable Message-ID: <20151117200055.GA55478@FreeBSD.cs.nctu.edu.tw> References: <1510276266.43.1447770841201.JavaMail.jenkins@jenkins-9.freebsd.org> <512656898.45.1447781806402.JavaMail.jenkins@jenkins-9.freebsd.org> <20151117193427.GA76612@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20151117193427.GA76612@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 20:03:05 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 17, 2015 at 20:34:29 +0100, Baptiste Daroussin wrote: > On Tue, Nov 17, 2015 at 05:36:45PM +0000, jenkins-admin@FreeBSD.org wrote: > > FreeBSD_HEAD-tests - Build #1704 - Still Unstable: > >=20 > > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1= 704/ > > Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/170= 4/changes > > Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1704= /console > >=20 > > Change summaries: > >=20 > > No changes > >=20 > >=20 > > The failed test cases: > >=20 > > 1 tests failed. > > FAILED: test-report.xml. > >=20 > > Error Message: > >=20 > Can someone fix that? or at least show which test is giving unicode in the > output? Just did a quick look into this: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1704/testReport/test-rep= ort/xml/_init_/ """ org.dom4j.DocumentException: Error on line 52159 of document file:///builds= /FreeBSD_HEAD-tests/test-report.xml : An invalid XML character (Unicode: 0x= 1) was found in the element content of the document. Nested exception: An i= nvalid XML character (Unicode: 0x1) was found in the element content of the= document. """ And this is the case output contains invalid XML character: """ Test case metadata ------------------ allowed_architectures is empty allowed_platforms is empty description =3D crypt(3) salt consistency checks has_cleanup =3D false required_configs is empty required_disk_space =3D 0 required_files is empty required_memory =3D 0 required_programs is empty required_user is empty timeout =3D 300 Original stderr --------------- *** Expected check failure: Old-style/bad inputs fail on FreeBSD: /builds/F= reeBSD_HEAD/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:140: Test 22 ^A^BUZ= oIyj/Hy/c !=3D ^A^Bwyd0KZo65Jo *** Expected check failure: Old-style/bad inputs fail on FreeBSD: /builds/F= reeBSD_HEAD/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:140: Test 23 a_Av8a= wQ0AsR6 !=3D a_C10Dk/ExaG. *** Expected check failure: Old-style/bad inputs fail on FreeBSD: /builds/F= reeBSD_HEAD/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:140: Test 24 ~=E2= =96=92UZoIyj/Hy/c !=3D ~=E2=96=92.5OTsRVjwLo """ There is an issue and a PR for kyua for this: https://github.com/jmmv/kyua/issues/136 https://github.com/jmmv/kyua/pull/148 Escape these characters is a way, or we might make our test cases always produce printable characters in outputs, however that might be impossible (who knows when test fails would happen?). Or, don't know if there is a method to embedded these bytes into a valid XML. Li-Wen --=20 Li-Wen Hsu http://lwhsu.org --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJWS4d2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDdENTNGNjUyMTUzMzVCNzA5NDNGODQ2 NzI3RTc3Qzg4NjJCNjU2AAoJEGcn53yIYrZWOmQP/igRzks4RgM7fVsEDztBdlub EBrLHUsNqmpv/vCs2CyJGB9vYwofXM2Hrqe2r4AU3/yoNtvbWQ3zueruu0ukUvIf Mz9WurzADxLAV05hl5I1xHl0tkKz7nHWKwymk0nMXP8tmh8bASD+H/9VtBmKhWjg aTnigHBGsbED09uKdtgerbhXygxijq4b3UBlxAJWEEFoMJCSlGv3LRS04qojcIBn k3PmSjJQgFqXBmUHHNumdG+QJ0Gn5FP/f874fdXWRhhQLGc4d22qdZ6bQa28k/CS pEiSxZrKKKAZGOaGLCksltmjma1fofu8USAUOs/vzcchueBiEn8Y9r9OWE0dabhp 0hSguQ8Ne0rkiikWiU03I3XuyHNuAdSRq+UQZLcilQa4hu11cN0k3mN1AWlzmQQ+ 6SHWgTJ6T7I4Xy7fBrpYaE6OutbkFUQbdzXGnBF+0i1Ez21cyzPihgc22PNEc3zW Uq3ks0bw7bSdydblZD2tmyhLjmwnusSoSAu4HXX/xsNfDPGmUAhsd/v98IQXHv1w A9kxX+RMAeZ1aaZ9RE10Q51wQDnm26q7/Q3gHe9xO5Ozj68kd76b2JN8hBQmDLr0 hzOQuPTW/8koNX001SE6tlS6BtQ7QqRdk27/O/NSOUr9SMhHz8E/ijaiELl0EVf1 CLHuoTU5NHOLxXDI1lw3 =WPYx -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-current@freebsd.org Tue Nov 17 20:15:40 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4ECFA31C52 for ; Tue, 17 Nov 2015 20:15:40 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 907251165 for ; Tue, 17 Nov 2015 20:15:40 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 5E282129F0; Tue, 17 Nov 2015 22:15:33 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2015 22:15:48 +0200 From: dan_partelly To: "Simon J. Gerraty" Cc: Adrian Chadd , freebsd-current Subject: Re: libXO-ification - Why - and is it a symptom of deeper =?UTF-8?Q?issues=3F?= In-Reply-To: <4366.1447783230@chaos> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <26127.1447610752@chaos> <18325.1447711377@chaos> <4366.1447783230@chaos> Message-ID: <493d20153ce0cb1b6d8731b70e4d41f0@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 20:15:40 -0000 Software wise, your biggest competitive advantage is using a re-branded BSD operating system. On a more serious note, surely I understand and support this position. The BSD license stays for true freedom, unlike the GNU beer . But we would never be sure that your company would say no, unless someone asks. SO I asked here on this list.What do you say Simon, would you please relay to Juniper decision factors my plea to open source your rights management system back in the BSD source code pool? Then we would know for sure if the answer is yes of no. Answer which of course will be respected of the BSD community. On Tue, 17 Nov 2015 10:00:30 -0800, "Simon J. Gerraty" wrote: > Dan Partelly wrote: >> Management daemon with fine grained permission, extremely >> useful. Would Juniper consider donating to FreeBSD under a BSD license >> portions of this code, the MGD, which could be reused in FreeBSD ? A > > Right now I suspect the answer to that might be "no". > We know we have competitors who would dearly like that ;-) > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Nov 17 20:43:50 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 566ECA3139D for ; Tue, 17 Nov 2015 20:43:50 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3D73511F1 for ; Tue, 17 Nov 2015 20:43:50 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3C88EA3139C; Tue, 17 Nov 2015 20:43:50 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C231A3139B for ; Tue, 17 Nov 2015 20:43:50 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 283AF11F0 for ; Tue, 17 Nov 2015 20:43:50 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id 93406125EE1 for ; Tue, 17 Nov 2015 12:43:43 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id 7BF5F125EBA for ; Tue, 17 Nov 2015 12:43:43 -0800 (PST) Subject: Re: LOR in mpr(4) To: current@freebsd.org References: <5644D014.4080601@nomadlogic.org> From: Pete Wright Message-ID: <564B917E.4000205@nomadlogic.org> Date: Tue, 17 Nov 2015 12:43:42 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5644D014.4080601@nomadlogic.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 20:43:50 -0000 On 11/12/15 09:44, Pete Wright wrote: > Hi All, > Just wanted a sanity check before filing a PR. I am running r290688 and > am seeing a LOR being triggered in the mpr(4) device: > > $ uname -ar > FreeBSD srd0013 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r290688: Wed Nov 11 > 21:28:26 PST 2015 root@srd0013:/usr/obj/usr/src/sys/GENERIC amd64 > > > lock order reversal: > 1st 0xfffff8000d26bc60 CAM device lock (CAM device lock) @ > /usr/src/sys/cam/cam_xpt.c:784 > 2nd 0xfffffe00012811c0 MPR lock (MPR lock) @ > /usr/src/sys/cam/cam_xpt.c:2620 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe04608ee890 > witness_checkorder() at witness_checkorder+0xe79/frame 0xfffffe04608ee910 > __mtx_lock_flags() at __mtx_lock_flags+0xa4/frame 0xfffffe04608ee960 > xpt_action_default() at xpt_action_default+0xb6c/frame 0xfffffe04608ee9b0 > scsi_scan_bus() at scsi_scan_bus+0x1d5/frame 0xfffffe04608eea20 > xpt_scanner_thread() at xpt_scanner_thread+0x15c/frame 0xfffffe04608eea70 > fork_exit() at fork_exit+0x84/frame 0xfffffe04608eeab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe04608eeab0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > FWIW I filed the following PR as I can still reproduce this on boot: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204614 cheers, -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-current@freebsd.org Tue Nov 17 20:57:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76265A31723 for ; Tue, 17 Nov 2015 20:57:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 673161B89; Tue, 17 Nov 2015 20:57:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8D39AA85; Tue, 17 Nov 2015 20:57:00 +0000 (UTC) Date: Tue, 17 Nov 2015 20:56:59 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2048472407.47.1447793819659.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <512656898.45.1447781806402.JavaMail.jenkins@jenkins-9.freebsd.org> References: <512656898.45.1447781806402.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1705 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 20:57:01 -0000 FreeBSD_HEAD-tests - Build #1705 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1705/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1705/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1705/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Tue Nov 17 22:11:41 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33005A31946 for ; Tue, 17 Nov 2015 22:11:41 +0000 (UTC) (envelope-from ben.lavery@hashbang0.com) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08AB917B7 for ; Tue, 17 Nov 2015 22:11:40 +0000 (UTC) (envelope-from ben.lavery@hashbang0.com) Received: from [192.168.1.103] (89.207.208.46.dyn.plus.net [46.208.207.89]) by mx.zohomail.com with SMTPS id 1447798288341710.8523805897398; Tue, 17 Nov 2015 14:11:28 -0800 (PST) Subject: Re: Panic while waiting on wlan0 To: adrian.chadd@gmail.com, Florian Limberger References: <564AF74A.2090700@snakeoilproductions.net> Cc: freebsd-current From: Ben Lavery X-Enigmail-Draft-Status: N1110 Message-ID: <564BA60C.6040601@hashbang0.com> Date: Tue, 17 Nov 2015 22:11:24 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 22:11:41 -0000 Evening all, I had a very similar issue when I installed SVN r290768 on my T440 on Monday, upped the laptop to r290927 that evening and everything was cool again - didn't have a chance to post about it at the time, and it looks like Adrian had already caught it :) Regards, Ben On 11/17/15 16:42, Adrian Chadd wrote: > hiya! > > try updating to head as of today. Some callout issues were fixed. > > Thanks! > > > -a > > > On 17 November 2015 at 01:45, Florian Limberger > wrote: >> Hi, >> >> I am running -CURRENT on my Lenovo T410 notebook since nearly a year now and >> am now experiencing my first reliable occuring panic. Since I am interested >> into getting more involved, I want not only to give a report on this, but >> ask for directions on how I can help to fix the issue. >> >> The crash occurs on bad wifi reception, either on startup, if “waiting 30s >> for default interface” is not interrupted, or at a later point if the >> wpa_supplicant is not able to establish a connection (mostly due to a wrong >> passphrase, which is not the case if the wifi reception is better). >> Core.txt and the dump info are attached. >> >> I am using git commit 71f160e0193fee45242bebeff7f1282846e83d2c. >> >> Best regards, >> >> >> florian >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Nov 17 22:25:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D77AA31D92 for ; Tue, 17 Nov 2015 22:25:36 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C84401FF9; Tue, 17 Nov 2015 22:25:34 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.101] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id EEE2B1F844; Wed, 18 Nov 2015 00:25:33 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <29711.1447778554@chaos> Date: Wed, 18 Nov 2015 00:25:32 +0200 Cc: Julian Elischer , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <61FE0B8E-37C3-4654-90BC-7A4F2EB3FFDB@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564AED8B.4080809@freebsd.org> <29711.1447778554@chaos> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 22:25:36 -0000 It=E2=80=99s not about the fronted. That would have to be replaced most = likely=20 The most useful part IMO is the permission engine itself, and maybe some=20= other parts too but without insight into implementation I am not able to=20= judge that. =20 You could IPC key value-data into the security engine describing = arbitrary commands, , have the request validated, user right checked, then passed to a = command execution=20 system (and I use the command term very loosely, I do not refers to a utility) =20 > On 17 Nov 2015, at 18:42, Simon J. Gerraty wrote: >=20 > Dan Partelly wrote: >> Juniper can further help FreeBSD by donating the code of their >> system management daemon and their fine granularity permissions >=20 > At the cost of i18n etc? > The Junos UI is totally data driven, syntax is verified term by term > (since depending on your permissions some terms simply do not exist = for > you). Such a model cannot be successfully translated to other > languages where the order of verbs and nouns differ for example. >=20 > Everything I've read on the topic suggests that messages must be > translated on at least phrase if not sentence granularity for = reasonable > results, and that just doesn't fit our UI. > Thus enhancement requests for i18n are politely rejected. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Nov 17 23:49:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E9E9A31CED for ; Tue, 17 Nov 2015 23:49:47 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8741E63; Tue, 17 Nov 2015 23:49:47 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 610EEB10; Tue, 17 Nov 2015 23:49:47 +0000 (UTC) Date: Tue, 17 Nov 2015 23:49:46 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <733972201.49.1447804187191.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2048472407.47.1447793819659.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2048472407.47.1447793819659.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1706 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:49:47 -0000 FreeBSD_HEAD-tests - Build #1706 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1706/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1706/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1706/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Wed Nov 18 05:37:41 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9006DA318F4 for ; Wed, 18 Nov 2015 05:37:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 80A6D11A4; Wed, 18 Nov 2015 05:37:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E38EBC11; Wed, 18 Nov 2015 05:37:41 +0000 (UTC) Date: Wed, 18 Nov 2015 05:37:41 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <2092728285.55.1447825061726.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <733972201.49.1447804187191.JavaMail.jenkins@jenkins-9.freebsd.org> References: <733972201.49.1447804187191.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1707 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 05:37:41 -0000 FreeBSD_HEAD-tests - Build #1707 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1707/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1707/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1707/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Wed Nov 18 08:34:07 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A067BA2F489 for ; Wed, 18 Nov 2015 08:34:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 91D7E10FC; Wed, 18 Nov 2015 08:34:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 89CC6C82; Wed, 18 Nov 2015 08:34:07 +0000 (UTC) Date: Wed, 18 Nov 2015 08:34:07 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1210473100.57.1447835647415.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2092728285.55.1447825061726.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2092728285.55.1447825061726.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1708 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 08:34:07 -0000 FreeBSD_HEAD-tests - Build #1708 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1708/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1708/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1708/console Change summaries: No changes The failed test cases: 1 tests failed. FAILED: test-report.xml. Error Message: From owner-freebsd-current@freebsd.org Wed Nov 18 16:08:18 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAE6BA2BD3E for ; Wed, 18 Nov 2015 16:08:18 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 99A0E1C04 for ; Wed, 18 Nov 2015 16:08:18 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id 97CDAA2BD3C; Wed, 18 Nov 2015 16:08:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97333A2BD3A; Wed, 18 Nov 2015 16:08:18 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BA211C03; Wed, 18 Nov 2015 16:08:17 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id tAIG53lo003284 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Nov 2015 11:05:03 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id tAIG53oX003283; Wed, 18 Nov 2015 11:05:03 -0500 (EST) (envelope-from ken) Date: Wed, 18 Nov 2015 11:05:03 -0500 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Subject: Re: async pass(4) patches available Message-ID: <20151118160503.GA3095@mithlond.kdm.org> References: <20150330222358.GA46342@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <20150330222358.GA46342@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Wed, 18 Nov 2015 11:05:03 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 16:08:18 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have updated the asynchronous pass(4) changes, and fixed a number of bugs in camdd(8). The new patches are here: FreeBSD/head as of SVN revision 290970: http://people.freebsd.org/~ken/async_pass.head.20151117.1.txt FreeBSD stable/10 as of SVN revision 290899: http://people.freebsd.org/~ken/async_pass.stable10.20151117.1.txt And a description / draft commit message, this time updated to include all the files that have changed: http://people.freebsd.org/~ken/async_pass_commitmsg.20151118.txt I have also attached the description to this email. At this point I think I've fixed enough bugs and it is stable enough to go into the tree. That will allow others to more easily use the code and add enhancements. Ken On Mon, Mar 30, 2015 at 16:23:58 -0600, Kenneth D. Merry wrote: > > I have put patches to add an asynchronous interface to the pass(4) driver > and add a new camdd(8) utility here: > > FreeBSD/head as of SVN revision 280857: > > http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt > > FreeBSD stable/10 as of SVN revision 280856: > > http://people.freebsd.org/~ken/async_pass.stable_10.20150330.1.txt > > And the description / draft commit message: > > http://people.freebsd.org/~ken/async_pass_commitmsg.20150330.txt > > I have also attached the description and draft commit message to this > email. > > The asynchronous changes to the pass(4) driver allow queueing and fetching > CAM CCBs via two new ioctls. Notification of completed I/O can come via > kqueue(2), poll(2), select(2), etc. > > The camdd(8) utility is intended as a simple data transfer utility, > benchmark, and an in-tree example of how to use the asynchronous pass(4) > interface. > > camdd(8) is still a work in progress. It needs to be cleaned up a bit and > streamlined. > > There is one known arrival and departure bug with the pass(4) driver > changes. We've reproduced it with our tests at Spectra, but I haven't yet > tracked it down. > > There are many more arrival and departure bugs in FreeBSD/head, however. > We have fixed quite a few in our local tree, but the test (called devad2) > that triggers all of the problems uses the asynchronous pass(4) interface. > So this is a prerequisite for fixing/verifying those bugs. > > Comments and testing are welcome! As I said, camdd(8) in particular is a > work in progress. It could use some cleanup and there are some more useful > features that could be added there. > > Part of the reason for camdd(8) was as a test facility for the new > interface. But, it also serves as a useful demonstration of the > asynchronous pass(4) functionality, given that the original application > that used the API doesn't make sense to go into FreeBSD. (It is > Spectra-specific, and not generally useful.) > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG > Add asynchronous command support to the pass(4) driver, and the new > camdd(8) utility. > > CCBs may be queued to the driver via the new CAMIOQUEUE ioctl, and > completed CCBs may be retrieved via the CAMIOGET ioctl. User > processes can use poll(2) or kevent(2) to get notification when > I/O has completed. > > While the existing CAMIOCOMMAND blocking ioctl interface only > supports user virtual data pointers in a CCB (generally only > one per CCB), the new CAMIOQUEUE ioctl supports user virtual and > physical address pointers, as well as user virtual and physical > scatter/gather lists. This allows user applications to have more > flexibility in their data handling operations. > > Kernel memory for data transferred via the queued interface is > allocated from the zone allocator in MAXPHYS sized chunks, and user > data is copied in and out. This is likely faster than the > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > configurations with many processors (there are more TLB shootdowns > caused by the mapping/unmapping operation) but may not be as fast > as running with unmapped I/O. > > The new memory handling model for user requests also allows > applications to send CCBs with request sizes that are larger than > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > size listed by the SIM driver in the maxio field in the Path > Inquiry (XPT_PATH_INQ) CCB. > > There are some things things would be good to add: > > 1. Come up with a way to do unmapped I/O on multiple buffers. > Currently the unmapped I/O interface operates on a struct bio, > which includes only one address and length. It would be nice > to be able to send an unmapped scatter/gather list down to > busdma. This would allow eliminating the copy we currently do > for data. > > 2. Add an ioctl to list currently outstanding CCBs in the various > queues. > > 3. Add an ioctl to cancel a request, or use the XPT_ABORT CCB to do > that. > > 4. Test physical address support. Virtual pointers and scatter > gather lists have been tested, but I have not yet tested > physical addresses or scatter/gather lists. > > 5. Investigate multiple queue support. At the moment there is one > queue of commands per pass(4) device. If multiple processes > open the device, they will submit I/O into the same queue and > get events for the same completions. This is probably the right > model for most applications, but it would be good to make sure > that there is not really a case for multiple queues before > pushing this code upstream. > > Also, add a new utility, camdd(8) that uses the asynchronous pass(4) > driver interface. > > This utility is intended to be a basic data transfer/copy utility, > a simple benchmark utility, and an example of how to use the > asynchronous pass(4) interface. > > It can copy data to and from pass(4) devices using any target queue > depth, starting offset and blocksize for the input and ouptut devices. > It currently only supports SCSI devices, but could be easily extended > to support ATA devices. > > It can also copy data to and from regular files, block devices, tape > devices, pipes, stdin, and stdout. It does not support queueing > multiple commands to any of those targets, since it uses the standard > read(2)/write(2)/writev(2)/readv(2) system calls. > > The I/O is done by two threads, one for the reader and one for the > writer. The reader thread sends completed read requests to the > writer thread in strictly sequential order, even if they complete > out of order. That could be modified later on for random I/O patterns > or slightly out of order I/O. > > camdd(8) uses kqueue(2)/kevent(2) to get I/O compeltion events from > the pass(4) driver and also to send request notifications internally. > > For pass(4) devcies, camdd(8) uses a single buffer (CAM_DATA_VADDR) > per CAM CCB on the reading side, and a scatter/gather list > (CAM_DATA_SG) on the writing side. In addition to testing both > interfaces, this makes any potential reblocking of I/O easier. No > data is copied between the reader and the writer, but rather the > reader's buffers are split into multiple I/O requests or combined > into a single I/O request depending on the input and output blocksize. > > For the file I/O path, camdd(8) also uses a single buffer (read(2), > write(2), pread(2) or pwrite(2)) on reads, and a scatter/gather list > (readv(2), writev(2), preadv(2), pwritev(2)) on writes. > > Things that would be nice to do for camdd(8) eventually: > > 1. Add support for I/O pattern generation. Patterns like all > zeros, all ones, LBA-based patterns, random patterns, etc. Right > Now you can always use /dev/zero, /dev/random, etc. > > 2. Add support for a "sink" mode, so we do only reads with no > writes. Right now, you can use /dev/null. > > 3. Add support for automatic queue depth probing, so that we can > figure out the right queue depth on the input and output side > for maximum throughput. At the moment it defaults to 6. > > 4. Add support for SATA device passthrough I/O. > > 5. Add support for random LBAs and/or lengths on the input and > side. > > 6. Track average per-I/O latency and busy time. The busy time > and latency could also feed in to the automatic queue depth > determination. > > sys/cam/scsi/scsi_pass.h: > Define two new ioctls, CAMIOQUEUE and CAMIOGET, that queue > and fetch asynchronous CAM CCBs respectively. > > Although these ioctls do not have a declared argument, they > both take a union ccb pointer. If we declare a size here, > the ioctl code in sys/kern/sys_generic.c will malloc and free > a buffer for either the CCB or the CCB pointer (depending on > how it is declared). Since we have to keep a copy of the > CCB (which is fairly large) anyway, having the ioctl malloc > and free a CCB for each call is wasteful. > > sys/cam/scsi/scsi_pass.c: > Add asynchronous CCB support. > > Add two new ioctls, CAMIOQUEUE and CAMIOGET. > > CAMIOQUEUE adds a CCB to the incoming queue. The CCB is > executed immediately (and moved to the active queue) if it > is an immediate CCB, but otherwise it will be executed > in passstart() when a CCB is available from the transport layer. > > When CCBs are completed (because they are immediate or > passdone() if they are queued), they are put on the done > queue. > > If we get the final close on the device before all pending > I/O is complete, all active I/O is moved to the abandoned > queue and we increment the peripheral reference count so > that the peripheral driver instance doesn't go away before > all pending I/O is done. > > The new passcreatezone() function is called on the first > call to the CAMIOQUEUE ioctl on a given device to allocate > the UMA zones for I/O requests and S/G list buffers. This > may be good to move off to a taskqueue at some point. > The new passmemsetup() function allocates memory and > scatter/gather lists to hold the user's data, and copies > in any data that needs to be written. For virtual pointers > (CAM_DATA_VADDR), the kernel buffer is malloced from the > new pass(4) driver malloc bucket. For virtual > scatter/gather lists (CAM_DATA_SG), buffers are allocated > from a new per-pass(9) UMA zone in MAXPHYS-sized chunks. > Physical pointers are passed in unchanged. We have support > for up to 16 scatter/gather segments (for the user and > kernel S/G lists) in the default struct pass_io_req, so > requests with longer S/G lists require an extra kernel malloc. > > The new passcopysglist() function copies a user scatter/gather > list to a kernel scatter/gather list. The number of elements > in each list may be different, but (obviously) the amount of data > stored has to be identical. > > The new passmemdone() function copies data out for the > CAM_DATA_VADDR and CAM_DATA_SG cases. > > The new passiocleanup() function restores data pointers in > user CCBs and frees memory. > > Add new functions to support kqueue(2)/kevent(2): > > passreadfilt() tells kevent whether or not the done > queue is empty. > > passkqfilter() adds a knote to our list. > > passreadfiltdetach() removes a knote from our list. > > Add a new function, passpoll(), for poll(2)/select(2) > to use. > > Add devstat(9) support for the queued CCB path. > > usr.sbin/camdd/Makefile: > Add a makefile for camdd(8). > > usr.sbin/camdd/camdd.8: > Man page for camdd(8). > > usr.sbin/camdd/camdd.c: > The new camdd(8) utility. > -- Kenneth Merry ken@FreeBSD.ORG --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="async_pass_commitmsg.20151118.txt" Add asynchronous command support to the pass(4) driver, and the new camdd(8) utility. CCBs may be queued to the driver via the new CAMIOQUEUE ioctl, and completed CCBs may be retrieved via the CAMIOGET ioctl. User processes can use poll(2) or kevent(2) to get notification when I/O has completed. While the existing CAMIOCOMMAND blocking ioctl interface only supports user virtual data pointers in a CCB (generally only one per CCB), the new CAMIOQUEUE ioctl supports user virtual and physical address pointers, as well as user virtual and physical scatter/gather lists. This allows user applications to have more flexibility in their data handling operations. Kernel memory for data transferred via the queued interface is allocated from the zone allocator in MAXPHYS sized chunks, and user data is copied in and out. This is likely faster than the vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in configurations with many processors (there are more TLB shootdowns caused by the mapping/unmapping operation) but may not be as fast as running with unmapped I/O. The new memory handling model for user requests also allows applications to send CCBs with request sizes that are larger than MAXPHYS. The pass(4) driver now limits queued requests to the I/O size listed by the SIM driver in the maxio field in the Path Inquiry (XPT_PATH_INQ) CCB. There are some things things would be good to add: 1. Come up with a way to do unmapped I/O on multiple buffers. Currently the unmapped I/O interface operates on a struct bio, which includes only one address and length. It would be nice to be able to send an unmapped scatter/gather list down to busdma. This would allow eliminating the copy we currently do for data. 2. Add an ioctl to list currently outstanding CCBs in the various queues. 3. Add an ioctl to cancel a request, or use the XPT_ABORT CCB to do that. 4. Test physical address support. Virtual pointers and scatter gather lists have been tested, but I have not yet tested physical addresses or scatter/gather lists. 5. Investigate multiple queue support. At the moment there is one queue of commands per pass(4) device. If multiple processes open the device, they will submit I/O into the same queue and get events for the same completions. This is probably the right model for most applications, but it would be good to make sure that there is not really a case for multiple queues before pushing this code upstream. Also, add a new utility, camdd(8) that uses the asynchronous pass(4) driver interface. This utility is intended to be a basic data transfer/copy utility, a simple benchmark utility, and an example of how to use the asynchronous pass(4) interface. It can copy data to and from pass(4) devices using any target queue depth, starting offset and blocksize for the input and ouptut devices. It currently only supports SCSI devices, but could be easily extended to support ATA devices. It can also copy data to and from regular files, block devices, tape devices, pipes, stdin, and stdout. It does not support queueing multiple commands to any of those targets, since it uses the standard read(2)/write(2)/writev(2)/readv(2) system calls. The I/O is done by two threads, one for the reader and one for the writer. The reader thread sends completed read requests to the writer thread in strictly sequential order, even if they complete out of order. That could be modified later on for random I/O patterns or slightly out of order I/O. camdd(8) uses kqueue(2)/kevent(2) to get I/O completion events from the pass(4) driver and also to send request notifications internally. For pass(4) devcies, camdd(8) uses a single buffer (CAM_DATA_VADDR) per CAM CCB on the reading side, and a scatter/gather list (CAM_DATA_SG) on the writing side. In addition to testing both interfaces, this makes any potential reblocking of I/O easier. No data is copied between the reader and the writer, but rather the reader's buffers are split into multiple I/O requests or combined into a single I/O request depending on the input and output blocksize. For the file I/O path, camdd(8) also uses a single buffer (read(2), write(2), pread(2) or pwrite(2)) on reads, and a scatter/gather list (readv(2), writev(2), preadv(2), pwritev(2)) on writes. Things that would be nice to do for camdd(8) eventually: 1. Add support for I/O pattern generation. Patterns like all zeros, all ones, LBA-based patterns, random patterns, etc. Right Now you can always use /dev/zero, /dev/random, etc. 2. Add support for a "sink" mode, so we do only reads with no writes. Right now, you can use /dev/null. 3. Add support for automatic queue depth probing, so that we can figure out the right queue depth on the input and output side for maximum throughput. At the moment it defaults to 6. 4. Add support for SATA device passthrough I/O. 5. Add support for random LBAs and/or lengths on the input and side. 6. Track average per-I/O latency and busy time. The busy time and latency could also feed in to the automatic queue depth determination. sys/cam/scsi/scsi_pass.h: Define two new ioctls, CAMIOQUEUE and CAMIOGET, that queue and fetch asynchronous CAM CCBs respectively. Although these ioctls do not have a declared argument, they both take a union ccb pointer. If we declare a size here, the ioctl code in sys/kern/sys_generic.c will malloc and free a buffer for either the CCB or the CCB pointer (depending on how it is declared). Since we have to keep a copy of the CCB (which is fairly large) anyway, having the ioctl malloc and free a CCB for each call is wasteful. sys/cam/scsi/scsi_pass.c: Add asynchronous CCB support. Add two new ioctls, CAMIOQUEUE and CAMIOGET. CAMIOQUEUE adds a CCB to the incoming queue. The CCB is executed immediately (and moved to the active queue) if it is an immediate CCB, but otherwise it will be executed in passstart() when a CCB is available from the transport layer. When CCBs are completed (because they are immediate or passdone() if they are queued), they are put on the done queue. If we get the final close on the device before all pending I/O is complete, all active I/O is moved to the abandoned queue and we increment the peripheral reference count so that the peripheral driver instance doesn't go away before all pending I/O is done. The new passcreatezone() function is called on the first call to the CAMIOQUEUE ioctl on a given device to allocate the UMA zones for I/O requests and S/G list buffers. This may be good to move off to a taskqueue at some point. The new passmemsetup() function allocates memory and scatter/gather lists to hold the user's data, and copies in any data that needs to be written. For virtual pointers (CAM_DATA_VADDR), the kernel buffer is malloced from the new pass(4) driver malloc bucket. For virtual scatter/gather lists (CAM_DATA_SG), buffers are allocated from a new per-pass(9) UMA zone in MAXPHYS-sized chunks. Physical pointers are passed in unchanged. We have support for up to 16 scatter/gather segments (for the user and kernel S/G lists) in the default struct pass_io_req, so requests with longer S/G lists require an extra kernel malloc. The new passcopysglist() function copies a user scatter/gather list to a kernel scatter/gather list. The number of elements in each list may be different, but (obviously) the amount of data stored has to be identical. The new passmemdone() function copies data out for the CAM_DATA_VADDR and CAM_DATA_SG cases. The new passiocleanup() function restores data pointers in user CCBs and frees memory. Add new functions to support kqueue(2)/kevent(2): passreadfilt() tells kevent whether or not the done queue is empty. passkqfilter() adds a knote to our list. passreadfiltdetach() removes a knote from our list. Add a new function, passpoll(), for poll(2)/select(2) to use. Add devstat(9) support for the queued CCB path. sys/cam/ata/ata_da.c: Add support for the BIO_VLIST bio type. sys/cam/cam_ccb.h: Add a new enumeration for the xflags field in the CCB header. (This doesn't change the CCB header, just adds an enumeration to use.) sys/cam/cam_xpt.c: Add a new function, xpt_setup_ccb_flags(), that allows specifying CCB flags. sys/cam/cam_xpt.h: Add a prototype for xpt_setup_ccb_flags(). sys/cam/scsi/scsi_da.c: Add support for BIO_VLIST. sys/dev/md/md.c: Add BIO_VLIST support to md(4). sys/geom/geom_disk.c: sys/kern/subr_bus_dma.c: Change _bus_dmamap_load_vlist() to take a starting offset and length. Add a new function, _bus_dmamap_load_pages(), that will load a list of physical pages starting at an offset. Update _bus_dmamap_load_bio() to allow loading BIO_VLIST bios. Allow unmapped I/O to start at an offset. sys/kern/subr_uio.c: Add two new functions, physcopyin_vlist() and physcopyout_vlist(). sys/sys/bio.h: Add a new bio flag, BIO_VLIST. sys/sys/uio.h: Add prototypes for physcopyin_vlist() and physcopyout_vlist(). share/man/man4/pass.4: Document the CAMIOQUEUE and CAMIOGET ioctls. usr.sbin/Makefile: Add camdd. usr.sbin/camdd/Makefile: Add a makefile for camdd(8). usr.sbin/camdd/camdd.8: Man page for camdd(8). usr.sbin/camdd/camdd.c: The new camdd(8) utility. --pWyiEgJYm5f9v55/-- From owner-freebsd-current@freebsd.org Wed Nov 18 17:13:12 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D32DA32E9F for ; Wed, 18 Nov 2015 17:13:12 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 50ED4194D for ; Wed, 18 Nov 2015 17:13:12 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id 513A2A32E9D; Wed, 18 Nov 2015 17:13:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 373C1A32E9C; Wed, 18 Nov 2015 17:13:12 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BC5C194B; Wed, 18 Nov 2015 17:13:11 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id tAIHD97A004267 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Nov 2015 12:13:09 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id tAIHD9fw004266; Wed, 18 Nov 2015 12:13:09 -0500 (EST) (envelope-from ken) Date: Wed, 18 Nov 2015 12:13:09 -0500 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Subject: CAM Shingled Disk support patches available Message-ID: <20151118171309.GA3564@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Wed, 18 Nov 2015 12:13:09 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:13:12 -0000 I have work in progress patches to add SMR (Shingled Magnetic Recording) support to CAM and GEOM here: FreeBSD/head as of SVN revision 290997: https://people.freebsd.org/~ken/cam_smr.head.20151117.1.txt FreeBSD stable/10 as of SVN revision 290995: https://people.freebsd.org/~ken/cam_smr.stable10.20151117.1.txt This includes support for Host Managed, Host Aware and Drive Managed SMR drives that are either SCSI (ZBC) or ATA (ZAC) attached via a SAS controller. This does not include support for SMR ATA drives attched via an ATA controller. Also, I have not yet figured out how to properly detect a Host Managed ATA drive, so this code won't do that. The big drive vendors are moving to SMR for at least some of their drives. The primary challenge with SMR is that it requires writing a relatively large zone sequentially starting at the beginning of the zone. The usual zone size is 256MB. It is conceptually almost like having a 256MB sector size. We (Spectra Logic) are working on ZFS changes that will use this CAM and GEOM infrastructure to make ZFS play well with SMR drives. Those changes aren't yet done. The patches linked above include: o A new 'camcontrol zone' command that allows displaying and managing drive zones via SCSI/ATA passthrough. o A new zonectl(8) utility that uses the new DIOCZONECMD ioctl to display and manage zones via the da(4) (and later ada(4)) driver. o Changes to diskinfo -v to display the zone mode of a drive. o A new disk zone API, sys/sys/disk_zone.h. o A new bio type, BIO_ZONE, and modifications to GEOM to support it. This new bio will allow filesystems to query zone support in a drive and manage zoned drives. o Extensive modifications to the da(4) driver to handle probing SCSI and SATA behind SAS SMR drives. o Additional CAM CDB building functions for zone commands. The current issues that need to be addressed are: o The da(4) driver now has 6 additional probe states, 5 of which are needed for probing ATA drives behind SAS controllers. I have not yet added support for BIO_ZONE bios to ada(4), but it will be very similar to the da(4) driver version. The ATA probe code needs to be pulled out of the da(4) driver and changed into a form that will allow it to work for either the ada(4) or da(4) driver. Otherwise we'll have a fair amount of code duplication between the two drivers. o There is a reasonable amount of code duplication between 'camcontrol zone' and zonectl(8). This was done for speed / expediency's sake, but it may be possible to make more of the code common there. o In order to add the new BIO_ZONE bio command, I had to change the bio_cmd field in struct bio from a uint8_t to a uint16_t. This will cause binary compatibility problems with any 3rd party loadable modules. Advice on how to handle this would be welcome. o In the process of developing these changes, I discovered that the dxfer_len paramter for scsi_ata_pass_16() was too small (uint16_t, and it needed to be uint32_t). I increased it, but that will potentially cause a binary incompatibility problem with any existing applications that use the current API via libcam. Advice on how to handle that would be welcome. If you look through the code, you'll notice that the disk_zone.h API is separate from the SCSI and ATA APIs. The intent is to allow filesystems and other consumers of the API to just talk to the disk zone API without dealing with the SCSI and ATA specifics. Another reason behind all of this is that even though the SCSI ZBC and ATA ZAC specs were developed in concert, and are intended to be functionally identical, they are still SCSI and ATA. As usual, SCSI is big endian and ATA is little endian. So to present a common API to the filesystem, we give all of the zone data back in native byte order, regardless of the underlying device protocol. Another thing to note is the extensive use of ATA passthrough in the da(4) driver. This is necessary because the SCSI SAT (SCSI to ATA Translation) specification has not yet caught up with translating SCSI zone commands (ZBC) to ATA zone commands (ZAC). So, until the spec is updated and LSI and other vendors update their SCSI to ATA translation layers, we'll have to use the ATA version of the commands when talking to ATA drives via SAS controllers. I have only tested the code so far with Seagate SATA Drive Managed and Host Aware drives. I would appreciate testing with any drives. (And testing to make sure that the patches don't cause problems with existing hardware.) Right now, all you can really do is manage the zones manually using camcontrol(8) or zonectl(8). Automatic management will come with the ZFS changes. (Or changes to other filesysems if people want to do it.) If you have a SATA Host Aware drive, in theory camcontrol(8) should allow you to manage the drive if you have it attached to a SATA controller. Here is an example of some of the commands. Get general zoning information: [root@sm4u-1 ~]# zonectl -c params -d /dev/da21 Zone Mode: Host Aware Command support: Report Zones, Open, Close, Finish, Reset Write Pointer Unrestricted Read in Sequential Write Required Zone (URSWRZ): No Optimal Number of Open Sequential Write Preferred Zones: 128 Optimal Number of Non-Sequentially Written Sequential Write Preferred Zones: 8 Maximum Number of Open Sequential Write Required Zones: Unlimited Look at information from the da(4) driver: [root@sm4u-1 ~]# sysctl kern.cam.da.21 kern.cam.da.21.delete_method: NONE kern.cam.da.21.delete_max: 1081344 kern.cam.da.21.minimum_cmd_size: 6 kern.cam.da.21.sort_io_queue: -1 kern.cam.da.21.zone_mode: Host Aware kern.cam.da.21.zone_support: Report Zones, Open, Close, Finish, Reset Write Pointer kern.cam.da.21.optimal_seq_zones: 128 kern.cam.da.21.optimal_nonseq_zones: 8 kern.cam.da.21.max_seq_zones: 4294967295 kern.cam.da.21.error_inject: 0 Display all of the zones with zonectl(8): [root@sm4u-1 ~]# zonectl -d /dev/da21 -c rz 29809 zones, Maximum LBA 0x3a3812aaf (15628053167) Zone lengths and types may vary Start LBA Length WP LBA Zone Type Condition Sequential Reset 0, 524288, 0x80000, Conventional, NWP, Sequential, No Reset Needed 0x80000, 524288, 0x100000, Conventional, NWP, Sequential, No Reset Needed 0x100000, 524288, 0x180000, Conventional, NWP, Sequential, No Reset Needed 0x180000, 524288, 0x200000, Conventional, NWP, Sequential, No Reset Needed 0x200000, 524288, 0x280000, Conventional, NWP, Sequential, No Reset Needed 0x280000, 524288, 0x300000, Conventional, NWP, Sequential, No Reset Needed 0x300000, 524288, 0x380000, Conventional, NWP, Sequential, No Reset Needed 0x380000, 524288, 0x400000, Conventional, NWP, Sequential, No Reset Needed 0x400000, 524288, 0x480000, Conventional, NWP, Sequential, No Reset Needed 0x480000, 524288, 0x500000, Conventional, NWP, Sequential, No Reset Needed 0x500000, 524288, 0x580000, Conventional, NWP, Sequential, No Reset Needed 0x580000, 524288, 0x600000, Conventional, NWP, Sequential, No Reset Needed 0x600000, 524288, 0x680000, Conventional, NWP, Sequential, No Reset Needed 0x680000, 524288, 0x700000, Conventional, NWP, Sequential, No Reset Needed 0x700000, 524288, 0x780000, Conventional, NWP, Sequential, No Reset Needed [ ... ] 0x1f00000, 524288, 0x1f80000, Conventional, NWP, Sequential, No Reset Needed 0x1f80000, 524288, 0x2000000, Conventional, NWP, Sequential, No Reset Needed 0x2000000, 524288, 0x2080000, Seq Preferred, Full, Sequential, No Reset Needed 0x2080000, 524288, 0x2100000, Seq Preferred, Full, Sequential, No Reset Needed 0x2100000, 524288, 0x2180000, Seq Preferred, Full, Sequential, No Reset Needed 0x2180000, 524288, 0x2200000, Seq Preferred, Full, Sequential, No Reset Needed 0x2200000, 524288, 0x2280000, Seq Preferred, Full, Sequential, No Reset Needed 0x2280000, 524288, 0x2300000, Seq Preferred, Full, Sequential, No Reset Needed [ ... ] Use camcontrol zone to reset the write pointer for the first shingled zone listed above: [root@sm4u-1 ~]# camcontrol zone da21 -v -c rwp -l 0x2000000 Use camcontrol zone to ask the drive to report empty zones: [root@sm4u-1 ~]# camcontrol zone da21 -v -c rz -o empty 1 zones, Maximum LBA 0x3a3812aaf (15628053167) Zone lengths and types may vary Start LBA Length WP LBA Zone Type Condition Sequential Reset 0x2000000, 524288, 0x2000000, Seq Preferred, Empty, Sequential, No Reset Needed Get information on a Host Aware drive: root@sm4u-1 ~]# diskinfo -v da21 da21 512 # sectorsize 8001563222016 # mediasize in bytes (7.3T) 15628053168 # mediasize in sectors 4096 # stripesize 0 # stripeoffset 972801 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Z84008NY # Disk ident. enc@5003048001f311fd/elmtype@array_device/slot@22 # Physical path Host Aware # Zone Mode Get information on a drive managed drive: [root@sm4u-1 ~]# diskinfo -v da20 da20 512 # sectorsize 8001563222016 # mediasize in bytes (7.3T) 15628053168 # mediasize in sectors 4096 # stripesize 0 # stripeoffset 972801 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Z8405938 # Disk ident. enc@5003048001f311fd/elmtype@array_device/slot@21 # Physical path Drive Managed # Zone Mode Get information on a non-zoned drive: [root@sm4u-1 ~]# diskinfo -v da4 da4 512 # sectorsize 100030242816 # mediasize in bytes (93G) 195371568 # mediasize in sectors 0 # stripesize 0 # stripeoffset 12161 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. 124903574F36 # Disk ident. enc@5003048001f311fd/elmtype@array_device/slot@5 # Physical path Not Zoned # Zone Mode Testing and comments are welcome. Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Wed Nov 18 17:24:23 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80E90A3107D for ; Wed, 18 Nov 2015 17:24:23 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 733721DA4; Wed, 18 Nov 2015 17:24:23 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D016CE46; Wed, 18 Nov 2015 17:24:22 +0000 (UTC) Date: Wed, 18 Nov 2015 17:24:22 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <443805109.59.1447867462557.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1710 - Successful MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:24:23 -0000 FreeBSD_HEAD-tests - Build #1710 - Successful: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1710/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1710/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1710/console Change summaries: No changes From owner-freebsd-current@freebsd.org Wed Nov 18 19:32:57 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D917A32C1A for ; Wed, 18 Nov 2015 19:32:57 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25B631CE8; Wed, 18 Nov 2015 19:32:56 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id F25676E005D; Wed, 18 Nov 2015 20:32:53 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id tAIJWrAo080480; Wed, 18 Nov 2015 20:32:53 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id tAIJWrUo080343; Wed, 18 Nov 2015 20:32:53 +0100 (CET) (envelope-from lars) Date: Wed, 18 Nov 2015 20:32:53 +0100 From: Lars Engels To: Allan Jude Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? Message-ID: <20151118193252.GE27296@e-new.0x20.net> Mail-Followup-To: Lars Engels , Allan Jude , Garrett Cooper , freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> <5648CBA1.9010300@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="588wvpgrYaEESfyK" Content-Disposition: inline In-Reply-To: <5648CBA1.9010300@freebsd.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 19:32:57 -0000 --588wvpgrYaEESfyK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2015 at 01:14:57PM -0500, Allan Jude wrote: > You can setup an atexit() call to call xo_finish automatically when the > program exits. The original changes to uptime had a few other issues, > which I fixed. >=20 Is there a list of tools that can already output via libxo? Neither "uptime -h", nor its manpage or "apropros libxo" doesn't reveal anything. --588wvpgrYaEESfyK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJWTNJkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tUncH/RdKmJSpzyyw05tS1In5jiyN TwJ7HaVcCqXvdKPYIp/c4qDWmsn16rwSgwvb6CxVsFzqc8iBBOSKwNTb2fm27CTy PuKiDBL7WNPCvdxbNBTQMRJLHqbgjqQGvmrFsrcnpwntMHrJeFHL0fdfXa/EovTk 92uOMC2dxg5ynGPXp5+xD5woCVJ27TblC/ec87CS2eTeZsnyxWmMT3UV7ULSMVNI /gv0yzHC6FaIVmI3uyKWD2PtuLNO6VSWJo9jjBQS6/pNRjzzz8zaDBGupCe5banp 87ciOJKV7y6+HFsyi4nTiDCpXtYOtMA9b8Cs0TWHUaeV86anM4U3czECDJvB2tk= =kf+q -----END PGP SIGNATURE----- --588wvpgrYaEESfyK-- From owner-freebsd-current@freebsd.org Wed Nov 18 20:46:34 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D198CA3298E for ; Wed, 18 Nov 2015 20:46:34 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56AC41127; Wed, 18 Nov 2015 20:46:34 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by lbbsy6 with SMTP id sy6so31758403lbb.2; Wed, 18 Nov 2015 12:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=lP4nlWK4Z1pFJtgw9xQwG+5iyEmFGmckXNQHARkCr7Q=; b=ERhkebR5JNIeOo/jdDxA9iAftvArjnq4IugoiXzfZfu3o28olJQ0yQ6t8Q1koig4Hf m5T7JCAb5lZ5PM1DurBkbPd9Iyz05lXIvOP/vK6jlHQpCKJ9iPr14AxFmX9qlzMy1fll SIOzIEBYfzIjpnf5AM+Pe9vQi8q+5Eu7NBOoHruUXqCJSc4PSlYR5IISsrMZJ6+FtLQ9 vkQYEt89g9OnXtXTnWhZ3xRusMEc/fZiiIjsAfZoD+6S7ft4qA9LVs9CEdgbnjhiYck8 xiYy02KKqA38d9bpHBMkF+q86ty9yfqTikEKLjeDIMzq19gr6AS8lWdOBHF2ba72DTyj Z7Iw== MIME-Version: 1.0 X-Received: by 10.112.136.136 with SMTP id qa8mr1657631lbb.14.1447879592227; Wed, 18 Nov 2015 12:46:32 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.78.3 with HTTP; Wed, 18 Nov 2015 12:46:32 -0800 (PST) In-Reply-To: <20151118193252.GE27296@e-new.0x20.net> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> <5648CBA1.9010300@freebsd.org> <20151118193252.GE27296@e-new.0x20.net> Date: Wed, 18 Nov 2015 12:46:32 -0800 X-Google-Sender-Auth: dON2socThVUPPFHrPuzjN68ekwA Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Luigi Rizzo To: Lars Engels , Allan Jude , Garrett Cooper , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:46:34 -0000 On Wed, Nov 18, 2015 at 11:32 AM, Lars Engels wrote: > On Sun, Nov 15, 2015 at 01:14:57PM -0500, Allan Jude wrote: >> You can setup an atexit() call to call xo_finish automatically when the >> program exits. The original changes to uptime had a few other issues, >> which I fixed. >> > > Is there a list of tools that can already output via libxo? Neither > "uptime -h", nor its manpage or "apropros libxo" doesn't reveal > anything. i was going to suggest doing ldd on the binaries or a grep on the Makefile but the latter returns a surprisingly low number of matches. > grep lxo */*/Makefile* rescue/rescue/Makefile:CRUNCH_LIBS+= -lcrypt -ledit -ljail -lkvm -ll -ltermcapw -lutil -lxo tools/bsdbox/Makefile:CRUNCH_SHLIBS+= -lc -lutil -lcrypt -lxo -lgpio perhaps cheers luigi From owner-freebsd-current@freebsd.org Wed Nov 18 21:56:42 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BBCAA32642 for ; Wed, 18 Nov 2015 21:56:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32789138C; Wed, 18 Nov 2015 21:56:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by igbxm8 with SMTP id xm8so49551685igb.1; Wed, 18 Nov 2015 13:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=b9S2+Fb3jQwl3rguuddsyAEu7fSiBvEXElndsJ1OvYw=; b=N398yksG3vn95AMFEVPNCinHUL7TqKt+CzHrLNmCN/7ZWz7dCp8GyZwVatL6Tr3cQ3 qDOybri8skGwdCMIstz8pqpgR6oisICZ6nhszCrMWU8GMDU3bmlAKDzuWbSYuIUdcYvq ONo31C3Q0C8RWy2N3/uIdosfmDnA5dX3cBQmuSsZ+YGIMNvekPI17gluuz6dp7pcZRst OEODO6x4bHewqnJtS1wOEMnprm1nb3xdRd5LXd3qhQGY3Y6tFNDmnHtDGgPDgyp56KCE GhhJIOc0pCm7ped4luRaJS3a60q2CtuNdh1YS/+8Sx8sO4VF3UCRgt1FUkTAabOLKuQJ xJdA== X-Received: by 10.50.43.131 with SMTP id w3mr5191817igl.33.1447883801568; Wed, 18 Nov 2015 13:56:41 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.169.85 with HTTP; Wed, 18 Nov 2015 13:56:21 -0800 (PST) In-Reply-To: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> <5648CBA1.9010300@freebsd.org> <20151118193252.GE27296@e-new.0x20.net> From: Ed Maste Date: Wed, 18 Nov 2015 16:56:21 -0500 X-Google-Sender-Auth: hbvDnKQoJc5jl3h4JMUAkxhmO9o Message-ID: Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Luigi Rizzo Cc: Lars Engels , Allan Jude , Garrett Cooper , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 21:56:42 -0000 On 18 November 2015 at 15:46, Luigi Rizzo wrote: > i was going to suggest doing ldd on the binaries or a grep on the > Makefile but the latter returns a surprisingly low number > of matches. That's because it's usually added via LIBADD=xo. My grep turns up these: bin/df, bin/ls, bin/ps, sbin/savecore, usr.bin/iscsictl, usr.bin/netstat, usr.bin/procstat, usr.bin/w, usr.bin/wc, usr.bin/xo From owner-freebsd-current@freebsd.org Wed Nov 18 22:40:37 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C99DA3209D for ; Wed, 18 Nov 2015 22:40:37 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id BD6A312B5; Wed, 18 Nov 2015 22:40:36 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.102] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id AF1EB15B44; Thu, 19 Nov 2015 00:40:28 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: Date: Thu, 19 Nov 2015 00:40:26 +0200 Cc: Luigi Rizzo , Lars Engels , Allan Jude , Garrett Cooper , freebsd-current Content-Transfer-Encoding: 7bit Message-Id: <671D0626-85BF-450F-A5A2-B6750EF2C940@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> <5648CBA1.9010300@freebsd.org> <20151118193252.GE27296@e-new.0x20.net> To: Ed Maste X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 22:40:37 -0000 add /usr.bin/uptime > On 18 Nov 2015, at 23:56, Ed Maste wrote: > > On 18 November 2015 at 15:46, Luigi Rizzo wrote: >> i was going to suggest doing ldd on the binaries or a grep on the >> Makefile but the latter returns a surprisingly low number >> of matches. > > That's because it's usually added via LIBADD=xo. > > My grep turns up these: bin/df, bin/ls, bin/ps, sbin/savecore, > usr.bin/iscsictl, usr.bin/netstat, usr.bin/procstat, usr.bin/w, > usr.bin/wc, usr.bin/xo > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Nov 19 03:16:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD618A302BF; Thu, 19 Nov 2015 03:16:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 91D8D1142; Thu, 19 Nov 2015 03:16:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 61B6D110B; Thu, 19 Nov 2015 03:16:41 +0000 (UTC) Date: Thu, 19 Nov 2015 03:16:27 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: emaste@FreeBSD.org, nwhitehorn@FreeBSD.org, imp@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1232220697.63.1447902993359.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1696 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 03:16:49 -0000 FreeBSD_HEAD_i386 - Build #1696 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1696/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1696/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1696/console Change summaries: 291053 by imp: Fix mips CPUTYPE so that we can pass it through to gcc. Keep old CPUTYPEs around for compatibility. Also include a list of typical values for FreeBSD. # Split out from other changes in D4155 Differential Revision: https://reviews.freebsd.org/D4155 291052 by emaste: Remove clauses 3 and 4 from makefs newfs_extern.h Obtained from: NetBSD 291049 by imp: Mark the mostly redundant kernels that just pull in something from _BASE as NO_UNIVERSE Differential Revision: https://reviews.freebsd.org/D4200 291048 by nwhitehorn: The Linux kexec boot loader doesn't need a font built in to it. This got copied-and-pasted from the PS3 loader. The end of the build log: Started by an SCM change Building remotely on kyua6.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_i386 Updating svn://svnmir.freebsd.org/base/head at revision '2015-11-19T03:14:57.615 +0000' U share/mk/bsd.cpu.mk U usr.sbin/makefs/ffs/newfs_extern.h U sys/mips/conf/ALFA_HORNET_UB U sys/mips/conf/AP121 U sys/mips/conf/AP135 U sys/mips/conf/AP143 U sys/mips/conf/AP91 U sys/mips/conf/AP93 U sys/mips/conf/AP94 U sys/mips/conf/AP96 U sys/mips/conf/BERI_DE4_MDROOT U sys/mips/conf/BERI_DE4_SDROOT U sys/mips/conf/BERI_SIM_MDROOT U sys/mips/conf/BERI_SIM_SDROOT U sys/mips/conf/BERI_SIM_VIRTIO U sys/mips/conf/CARAMBOLA2 U sys/mips/conf/DB120 U sys/mips/conf/DIR-655A1 U sys/mips/conf/DIR-825B1 U sys/mips/conf/DIR-825C1 U sys/mips/conf/ENH200 U sys/mips/conf/ONIONOMEGA U sys/mips/conf/PB47 U sys/mips/conf/PICOSTATION_M2HP U sys/mips/conf/ROUTERSTATION U sys/mips/conf/ROUTERSTATION_MFS U sys/mips/conf/RSPRO U sys/mips/conf/RSPRO_MFS U sys/mips/conf/TL-ARCHERC7V2 U sys/mips/conf/TL-WDR4300 U sys/mips/conf/TL-WR1043NDv2 U sys/mips/conf/TL-WR740Nv4 U sys/mips/conf/TP-MR3020 U sys/mips/conf/TP-WN1043ND U sys/mips/conf/WZR-300HP U sys/mips/conf/WZR-HPAG300H U sys/boot/powerpc/kboot/Makefile At revision 291053 No emails were triggered. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson364663044554686658.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 jail: "FreeBSD_HEAD_i386" not found + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_i386/usr/src umount: FreeBSD_HEAD_i386/usr/src: statfs: No such file or directory umount: FreeBSD_HEAD_i386/usr/src: unknown file system + true + sudo umount FreeBSD_HEAD_i386/dev umount: FreeBSD_HEAD_i386/dev: statfs: No such file or directory umount: FreeBSD_HEAD_i386/dev: unknown file system + true + sudo rm -fr FreeBSD_HEAD_i386 + sudo chflags -R noschg FreeBSD_HEAD_i386 chflags: FreeBSD_HEAD_i386: No such file or directory + true + sudo rm -fr FreeBSD_HEAD_i386 [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson784282526845870411.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo env: env: + /usr/bin/env BUILD_NUMBER=1696 HUDSON_SERVER_COOKIE=0657dbe3541f1b1a JOB_NAME=FreeBSD_HEAD_i386 LOGNAME=jenkins JAVA_HOME=/usr/local/openjdk8 SVN_URL=svn://svnmir.freebsd.org/base/head BUILDER_JAIL_IP=2610:1c1:1:607c::106:1 jname=FreeBSD_HEAD_i386 JENKINS_URL=https://jenkins.FreeBSD.org/ JENKINS_HOME=/usr/local/jenkins PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin HUDSON_HOME=/usr/local/jenkins OLDPWD=/ BUILD_ID=1696 BUILDER_NETIF=igb0 JENKINS_SERVER_COOKIE=0657dbe3541f1b1a PWD=/jenkins/workspace/FreeBSD_HEAD_i386 BUILD_TAG=jenkins-FreeBSD_HEAD_i386-1696 NODE_LABELS=jailer kyua6.nyi.freebsd.org BUILD_DISPLAY_NAME=#1696 HOME=/jenkins USER=jenkins BUILD_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1696/ SVN_URL_1=svn://svnmir.freebsd.org/base/head SVN_REVISION=291053 SVN_REVISION_1=291053 BUILDER_JAIL_IP6=2610:1c1:1:607c::105:1 JOB_URL=https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/ SHELL=/bin/sh HUDSON_URL=https://jenkins.FreeBSD.org/ HUDSON_COOKIE=c25d3d26-e023-48a4-b90b-e7f1f48c0320 BUILDER_RESOLV_CONF=nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n WORKSPACE=/jenkins/workspace/FreeBSD_HEAD_i386 NODE_NAME=kyua6.nyi.freebsd.org EXECUTOR_NUMBER=0 + echo 'setup jail FreeBSD_HEAD_i386' setup jail FreeBSD_HEAD_i386 + fetch -m http://ftp.freebsd.org:/pub/FreeBSD/snapshots/i386/i386/11.0-CURRENT/base.txz + mkdir FreeBSD_HEAD_i386 + cd FreeBSD_HEAD_i386 + sudo tar Jxf ../base.txz + cd - + sudo mount -t devfs devfs FreeBSD_HEAD_i386/dev + sudo devfs -m FreeBSD_HEAD_i386/dev rule -s 4 applyset + sudo mount -t nullfs src FreeBSD_HEAD_i386/usr/src + printf 'nameserver 2610:1c1:1:6002::100\nnameserver 2610:1c1:1:6002::200\n' + sudo tee FreeBSD_HEAD_i386/etc/resolv.conf nameserver 2610:1c1:1:6002::100 nameserver 2610:1c1:1:6002::200 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 alias + sudo jail -c persist 'name=FreeBSD_HEAD_i386' 'path=FreeBSD_HEAD_i386' 'host.hostname=FreeBSD_HEAD_i386.jail.ci.FreeBSD.org' 'ip6.addr=2610:1c1:1:607c::106:1' 'ip4=disable' allow.chflags + echo 'setup build environment' setup build environment + echo 'build environment:' build environment: + sudo jexec FreeBSD_HEAD_i386 sh -c 'uname -a' FreeBSD FreeBSD_HEAD_i386.jail.ci.FreeBSD.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r288681: Mon Oct 5 01:40:11 UTC 2015 peter@build-11.freebsd.org:/usr/obj/usr/src/sys/CLUSTER11 i386 + sudo pkg -j FreeBSD_HEAD_i386 info -q [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson502553122098190919.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'start build in FreeBSD_HEAD_i386' start build in FreeBSD_HEAD_i386 + sudo jexec FreeBSD_HEAD_i386 sh -c 'cd /usr/src && make -DNO_CLEAN -j 4 buildworld' make: "/usr/src/share/mk/bsd.cpu.mk" line 137: warning: extra elif make: "/usr/src/share/mk/bsd.cpu.mk" line 0: 1 open conditional make: Fatal errors encountered -- cannot continue make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson1109724657258216801.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 rm: FreeBSD_HEAD_i386/sbin/init: Operation not permitted rm: FreeBSD_HEAD_i386/sbin: Directory not empty rm: FreeBSD_HEAD_i386/libexec/ld-elf.so.1: Operation not permitted rm: FreeBSD_HEAD_i386/libexec: Directory not empty rm: FreeBSD_HEAD_i386/usr/bin/ypchpass: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/su: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/chpass: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/passwd: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/chfn: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/chsh: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/opiepasswd: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/ypchsh: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/login: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/crontab: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/yppasswd: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/opieinfo: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin/ypchfn: Operation not permitted rm: FreeBSD_HEAD_i386/usr/bin: Directory not empty rm: FreeBSD_HEAD_i386/usr/lib/librt.so.1: Operation not permitted rm: FreeBSD_HEAD_i386/usr/lib: Directory not empty rm: FreeBSD_HEAD_i386/usr: Directory not empty rm: FreeBSD_HEAD_i386/lib/libthr.so.3: Operation not permitted rm: FreeBSD_HEAD_i386/lib/libcrypt.so.5: Operation not permitted rm: FreeBSD_HEAD_i386/lib/libc.so.7: Operation not permitted rm: FreeBSD_HEAD_i386/lib: Directory not empty rm: FreeBSD_HEAD_i386: Directory not empty + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Thu Nov 19 03:29:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D433A30880 for ; Thu, 19 Nov 2015 03:29:59 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC991A62; Thu, 19 Nov 2015 03:29:59 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A462C110C; Thu, 19 Nov 2015 03:29:59 +0000 (UTC) Date: Thu, 19 Nov 2015 03:29:57 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: emaste@FreeBSD.org, ngie@FreeBSD.org, nwhitehorn@FreeBSD.org, imp@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <53418481.65.1447903799485.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD - Build #3553 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 03:29:59 -0000 FreeBSD_HEAD - Build #3553 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3553/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3553/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3553/console Change summaries: 291053 by imp: Fix mips CPUTYPE so that we can pass it through to gcc. Keep old CPUTYPEs around for compatibility. Also include a list of typical values for FreeBSD. # Split out from other changes in D4155 Differential Revision: https://reviews.freebsd.org/D4155 291052 by emaste: Remove clauses 3 and 4 from makefs newfs_extern.h Obtained from: NetBSD 291049 by imp: Mark the mostly redundant kernels that just pull in something from _BASE as NO_UNIVERSE Differential Revision: https://reviews.freebsd.org/D4200 291048 by nwhitehorn: The Linux kexec boot loader doesn't need a font built in to it. This got copied-and-pasted from the PS3 loader. 291047 by ngie: Don't leak work if __mlx4_register_vlan(..) fails in mlx4_master_immediate_activate_vlan_qos(..) MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D4203 Submitted by: Miles Olrich Sponsored by: EMC / Isilon Storage Division 291046 by bdrewery: FAST_DEPEND: Similar to r290629, do always depend on headers if 'make depend' has not ran yet. This fixes building objects directly, or skipping 'make depend', not generating required headers first. This case did work without FAST_DEPEND so there's no reason it should not work here as well. An example of this can be seen building in gnu/usr.bin/binutils/libbfd without running 'make depend' first to generate config.h. Sponsored by: EMC / Isilon Storage Division MFC after: 3 weeks X-MFC-With: r290433 The end of the build log: Started by an SCM change Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace /builds/FreeBSD_HEAD Updating svn://svnmir.freebsd.org/base/head at revision '2015-11-19T03:28:55.812 +0000' U share/mk/bsd.cpu.mk U share/mk/bsd.lib.mk U usr.sbin/makefs/ffs/newfs_extern.h U sys/mips/conf/ALFA_HORNET_UB U sys/mips/conf/AP121 U sys/mips/conf/AP135 U sys/mips/conf/AP143 U sys/mips/conf/AP91 U sys/mips/conf/AP93 U sys/mips/conf/AP94 U sys/mips/conf/AP96 U sys/mips/conf/BERI_DE4_MDROOT U sys/mips/conf/BERI_DE4_SDROOT U sys/mips/conf/BERI_SIM_MDROOT U sys/mips/conf/BERI_SIM_SDROOT U sys/mips/conf/BERI_SIM_VIRTIO U sys/mips/conf/CARAMBOLA2 U sys/mips/conf/DB120 U sys/mips/conf/DIR-655A1 U sys/mips/conf/DIR-825B1 U sys/mips/conf/DIR-825C1 U sys/mips/conf/ENH200 U sys/mips/conf/ONIONOMEGA U sys/mips/conf/PB47 U sys/mips/conf/PICOSTATION_M2HP U sys/mips/conf/ROUTERSTATION U sys/mips/conf/ROUTERSTATION_MFS U sys/mips/conf/RSPRO U sys/mips/conf/RSPRO_MFS U sys/mips/conf/TL-ARCHERC7V2 U sys/mips/conf/TL-WDR4300 U sys/mips/conf/TL-WR1043NDv2 U sys/mips/conf/TL-WR740Nv4 U sys/mips/conf/TP-MR3020 U sys/mips/conf/TP-WN1043ND U sys/mips/conf/WZR-300HP U sys/mips/conf/WZR-HPAG300H U sys/boot/powerpc/kboot/Makefile U sys/ofed/drivers/net/mlx4/cmd.c At revision 291053 No emails were triggered. [FreeBSD_HEAD] $ /bin/sh -xe /tmp/hudson291961450126846788.sh + /vm/freebsd-ci/scripts/build/build1.sh + [ -z /builds/FreeBSD_HEAD ] + export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj + mkdir -p /builds/FreeBSD_HEAD/obj + echo -e WITH_FAST_DEPEND=yes + cat + set +x -------------------------------------------------------------- >>> /builds/FreeBSD_HEAD/make.conf contains: + cat /builds/FreeBSD_HEAD/make.conf # Put make.conf entries here WITH_FAST_DEPEND=yes + set +x -------------------------------------------------------------- + make -j 4 buildworld __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf --- buildworld --- make[1]: "/builds/FreeBSD_HEAD/share/mk/bsd.cpu.mk" line 137: warning: extra elif make[1]: "/builds/FreeBSD_HEAD/share/mk/bsd.cpu.mk" line 0: 1 open conditional make[1]: Fatal errors encountered -- cannot continue make[1]: stopped in /builds/FreeBSD_HEAD *** [buildworld] Error code 1 make: stopped in /builds/FreeBSD_HEAD 1 error make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Thu Nov 19 06:36:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46613A32234; Thu, 19 Nov 2015 06:36:19 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2E31517E0; Thu, 19 Nov 2015 06:36:19 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6FA8F1189; Thu, 19 Nov 2015 06:36:19 +0000 (UTC) Date: Thu, 19 Nov 2015 06:36:17 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jhibbits@FreeBSD.org, imp@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1693112476.69.1447914979390.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1232220697.63.1447902993359.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1232220697.63.1447902993359.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1697 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 06:36:19 -0000 FreeBSD_HEAD_i386 - Build #1697 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1697/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1697/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1697/console Change summaries: 291056 by jhibbits: Revert r291009 until rman changes go in. Pointy-hat to: jhibbits 291055 by imp: Fix missing endif. From owner-freebsd-current@freebsd.org Thu Nov 19 07:34:57 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 859FFA32DBB for ; Thu, 19 Nov 2015 07:34:57 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC771ECD; Thu, 19 Nov 2015 07:34:56 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.166] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id 658BE32CF; Thu, 19 Nov 2015 09:34:55 +0200 (EET) From: Dan Partelly Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: DDB patches Date: Thu, 19 Nov 2015 09:34:55 +0200 Message-Id: Cc: pfg@freebsd.org, Adrian Chadd To: freebsd-current Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 07:34:57 -0000 Hey Pedro, some times ago you got some DDB patches from me in which I added = relational ops support from it. The patch was a bit clobbered,=20 but last I know you cleaned it up and put it somewhere on freebsd.org = (prolly your page) up for review.=20 Could you or Adrian review the patch set , and if it is OK potentially = proceed with a commit ? Or if it is not ok for a commit , please advice = on a follow up.=20 Thanks you guys .= From owner-freebsd-current@freebsd.org Thu Nov 19 07:50:35 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0650A331B7 for ; Thu, 19 Nov 2015 07:50:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AE1F414A0; Thu, 19 Nov 2015 07:50:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1D3FD11B1; Thu, 19 Nov 2015 07:50:36 +0000 (UTC) Date: Thu, 19 Nov 2015 07:50:33 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jhibbits@FreeBSD.org, markj@FreeBSD.org, imp@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <149303222.73.1447919436087.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <53418481.65.1447903799485.JavaMail.jenkins@jenkins-9.freebsd.org> References: <53418481.65.1447903799485.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD - Build #3554 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 07:50:35 -0000 FreeBSD_HEAD - Build #3554 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3554/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3554/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3554/console Change summaries: 291060 by markj: Remove a commented-out debug print. MFC after: 1 week 291059 by markj: Add support for a configurable output channel to witness(4). This is useful in environments where system configuration is performed by automated interaction with the system console, since unexpected witness output makes such automation difficult. With this change, the new debug.witness.output_channel sysctl allows one to specify that witness output is to be printed to the kernel log (using log(9)) rather than the console. Reviewed by: cem, jhb MFC after: 2 weeks Relnotes: yes Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D4183 291058 by markj: Add vlog(9). Reviewed by: cem, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D4183 291057 by markj: Fix a bug in the amd64 dtrace_getarg() implementation: when unwinding the stack, take into account the copy of rsi pushed between the breakpoint trapframe and the dtrace_invop frame. Prior to r287644, this was covered by the fact that sizeof(struct amd64_frame) was 24 rather than 16. Reported by: smh 291056 by jhibbits: Revert r291009 until rman changes go in. Pointy-hat to: jhibbits 291055 by imp: Fix missing endif. From owner-freebsd-current@freebsd.org Thu Nov 19 09:17:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 890F5A32677 for ; Thu, 19 Nov 2015 09:17:05 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 496FF1868 for ; Thu, 19 Nov 2015 09:17:04 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: (qmail 58277 invoked by uid 99); 19 Nov 2015 09:17:04 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Nov 2015 09:17:04 +0000 Received: from [192.168.0.103] (unknown [181.55.232.163]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 67DF31A0338; Thu, 19 Nov 2015 09:17:02 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: DDB patches From: Pedro Giffuni In-Reply-To: Date: Thu, 19 Nov 2015 04:17:00 -0500 Cc: freebsd-current , Adrian Chadd Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dan Partelly X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 09:17:05 -0000 Hello; > Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly = ha scritto: >=20 > Hey Pedro, >=20 > some times ago you got some DDB patches from me in which I added = relational ops support from it. The patch was a bit clobbered,=20 > but last I know you cleaned it up and put it somewhere on freebsd.org = (prolly your page) up for review.=20 >=20 It=E2=80=99s here: https://people.freebsd.org/~pfg/patches/ddb.patch I haven=E2=80=99t tested it though. > Could you or Adrian review the patch set , and if it is OK potentially = proceed with a commit ? Or if it is not ok for a commit , please advice = on a follow up.=20 >=20 I am having hardware issues so I won=E2=80=99t be able to do much in a = while. Perhaps you should review it and submit it as a PR. Pedro. From owner-freebsd-current@freebsd.org Thu Nov 19 09:57:02 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2688A330AC for ; Thu, 19 Nov 2015 09:57:02 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6AA1FD0; Thu, 19 Nov 2015 09:57:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.166] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id 5F39415B44; Thu, 19 Nov 2015 11:57:00 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: DDB patches From: Dan Partelly In-Reply-To: Date: Thu, 19 Nov 2015 11:57:00 +0200 Cc: freebsd-current , Pedro Giffuni Content-Transfer-Encoding: quoted-printable Message-Id: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> References: To: Adrian Chadd X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 09:57:02 -0000 Hey Pedro, Thanks a lot , mate.=20 I=E2=80=99m reluctant to put it up as a PR, since some PR are = outstanding for years. =20 Adrian, since Pedro has issue with hardware, could you try the patch and give a = resolution on it ? I reviewed it mentally (no FreeBSD atm machine on = which I could actually patch the kernel) and apart style changes it = looks OK . Physically i can test it again fro a couple of days. Getting = this reviewed & tested / committed or rejected would give me an idea on = how things actually work around here. This is actual code which you can = commit or reject not commentaries only like in the thread regarding the = binary code reuse. =20 [qute from libxo thread ] >>It's all fine and good making technical decisions based on drawings = and handwaving and philosophizing, but at some point someone has to do >>the code. >>The reason is simple - someone offered to do the work and push it = through. This isn't a commercial thing where we get to make project = >>decisions and allocate resources - the juniper folk came up with a = solution that Once I see how things work around here once someone wrote the code, = and get this done one way or another , we could proceed to the = libification of ifconfig, should you so desire, and you believe we can = all benefit from it.=20 Dan > On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >=20 > Hello; >=20 >> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly = ha scritto: >>=20 >> Hey Pedro, >>=20 >> some times ago you got some DDB patches from me in which I added = relational ops support from it. The patch was a bit clobbered,=20 >> but last I know you cleaned it up and put it somewhere on freebsd.org = (prolly your page) up for review.=20 >>=20 >=20 > It=E2=80=99s here: > https://people.freebsd.org/~pfg/patches/ddb.patch >=20 > I haven=E2=80=99t tested it though. >=20 >> Could you or Adrian review the patch set , and if it is OK = potentially proceed with a commit ? Or if it is not ok for a commit , = please advice on a follow up.=20 >>=20 >=20 > I am having hardware issues so I won=E2=80=99t be able to do much in a = while. > Perhaps you should review it and submit it as a PR. >=20 > Pedro. >=20 From owner-freebsd-current@freebsd.org Thu Nov 19 13:45:08 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC76FA31C66 for ; Thu, 19 Nov 2015 13:45:08 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 665FF1C40 for ; Thu, 19 Nov 2015 13:45:08 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 54331153408; Thu, 19 Nov 2015 14:45:02 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il5y5oKo4IVp; Thu, 19 Nov 2015 14:44:33 +0100 (CET) Received: from [192.168.101.176] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 6A77C15340A; Thu, 19 Nov 2015 14:44:33 +0100 (CET) Subject: Re: DDB patches To: Dan Partelly References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> Cc: freebsd-current From: Willem Jan Withagen Message-ID: <564DD241.9020801@digiware.nl> Date: Thu, 19 Nov 2015 14:44:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 13:45:09 -0000 On 19-11-2015 10:57, Dan Partelly wrote: > Hey Pedro, > > Thanks a lot , mate. > > I’m reluctant to put it up as a PR, since some PR are outstanding for > years. What a strange argument.... Some PR's are fixed within hours/days.... Letting it linger in your mailbox after mental evaluation is not going to do anybody any good. As far as I understand is the PR database also the collective memory of things on/for/by/near/around the FreeBSD source code. People are explicitly asked to fill a PR so the issue at hand is not forgotten. So not submitting a PR for an issue sound real strange to my ears. But then again that's me. --WjW > Adrian, > > since Pedro has issue with hardware, could you try the patch and give > a resolution on it ? I reviewed it mentally (no FreeBSD atm machine > on which I could actually patch the kernel) and apart style changes > it looks OK . Physically i can test it again fro a couple of days. > Getting this reviewed & tested / committed or rejected would give me > an idea on how things actually work around here. This is actual code > which you can commit or reject not commentaries only like in the > thread regarding the binary code reuse. > > > [qute from libxo thread ] >>> It's all fine and good making technical decisions based on >>> drawings and handwaving and philosophizing, but at some point >>> someone has to do the code. The reason is simple - someone >>> offered to do the work and push it through. This isn't a >>> commercial thing where we get to make project >>decisions and >>> allocate resources - the juniper folk came up with a solution >>> that > > Once I see how things work around here once someone wrote the code, > and get this done one way or another , we could proceed to the > libification of ifconfig, should you so desire, and you believe we > can all benefit from it. > > > Dan > > > >> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: > >> >> Hello; >> >>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly >>> ha scritto: >>> >>> Hey Pedro, >>> >>> some times ago you got some DDB patches from me in which I added >>> relational ops support from it. The patch was a bit clobbered, >>> but last I know you cleaned it up and put it somewhere on >>> freebsd.org (prolly your page) up for review. >>> >> >> It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch >> >> I haven’t tested it though. >> >>> Could you or Adrian review the patch set , and if it is OK >>> potentially proceed with a commit ? Or if it is not ok for a >>> commit , please advice on a follow up. >>> >> >> I am having hardware issues so I won’t be able to do much in a >> while. Perhaps you should review it and submit it as a PR. >> >> Pedro. >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current To > unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Nov 19 13:53:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 776B1A31E44 for ; Thu, 19 Nov 2015 13:53:52 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 12045105F for ; Thu, 19 Nov 2015 13:53:51 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.166] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id 7A54A1181B; Thu, 19 Nov 2015 15:53:49 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: DDB patches From: Dan Partelly In-Reply-To: <564DD241.9020801@digiware.nl> Date: Thu, 19 Nov 2015 15:53:49 +0200 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <564DD241.9020801@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 13:53:52 -0000 > So not submitting a PR for an issue sound real strange to my ears. It is NOT a patch for an issue, bug, anything on those lines at all.=20 It adds new features to DDB. Specifically it adds relational=20 operators.=20 Since it doesn't solve any problems, I don't see why it should be added=20= to a problem database which is used for bug reports.=20 But then again, it may be just me. Dan > On 19 Nov 2015, at 15:44, Willem Jan Withagen wrote: >=20 > On 19-11-2015 10:57, Dan Partelly wrote: >> Hey Pedro, >>=20 >> Thanks a lot , mate. >>=20 >> I=E2=80=99m reluctant to put it up as a PR, since some PR are = outstanding for >> years. >=20 > What a strange argument.... >=20 > Some PR's are fixed within hours/days.... > Letting it linger in your mailbox after mental evaluation is not going > to do anybody any good. >=20 > As far as I understand is the PR database also the collective memory = of > things on/for/by/near/around the FreeBSD source code. People are > explicitly asked to fill a PR so the issue at hand is not forgotten. >=20 > So not submitting a PR for an issue sound real strange to my ears. >=20 > But then again that's me. >=20 > --WjW >=20 >=20 >> Adrian, >>=20 >> since Pedro has issue with hardware, could you try the patch and give >> a resolution on it ? I reviewed it mentally (no FreeBSD atm machine >> on which I could actually patch the kernel) and apart style changes >> it looks OK . Physically i can test it again fro a couple of days. >> Getting this reviewed & tested / committed or rejected would give me >> an idea on how things actually work around here. This is actual code >> which you can commit or reject not commentaries only like in the >> thread regarding the binary code reuse. >>=20 >>=20 >> [qute from libxo thread ] >>>> It's all fine and good making technical decisions based on >>>> drawings and handwaving and philosophizing, but at some point >>>> someone has to do the code. The reason is simple - someone >>>> offered to do the work and push it through. This isn't a >>>> commercial thing where we get to make project >>decisions and >>>> allocate resources - the juniper folk came up with a solution >>>> that >>=20 >> Once I see how things work around here once someone wrote the code, >> and get this done one way or another , we could proceed to the >> libification of ifconfig, should you so desire, and you believe we >> can all benefit from it. >>=20 >>=20 >> Dan >>=20 >>=20 >>=20 >>> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >>=20 >>>=20 >>> Hello; >>>=20 >>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly >>>> ha scritto: >>>>=20 >>>> Hey Pedro, >>>>=20 >>>> some times ago you got some DDB patches from me in which I added >>>> relational ops support from it. The patch was a bit clobbered,=20 >>>> but last I know you cleaned it up and put it somewhere on >>>> freebsd.org (prolly your page) up for review. >>>>=20 >>>=20 >>> It=E2=80=99s here: https://people.freebsd.org/~pfg/patches/ddb.patch >>>=20 >>> I haven=E2=80=99t tested it though. >>>=20 >>>> Could you or Adrian review the patch set , and if it is OK >>>> potentially proceed with a commit ? Or if it is not ok for a >>>> commit , please advice on a follow up. >>>>=20 >>>=20 >>> I am having hardware issues so I won=E2=80=99t be able to do much in = a >>> while. Perhaps you should review it and submit it as a PR. >>>=20 >>> Pedro. >>>=20 >>=20 >> _______________________________________________=20 >> freebsd-current@freebsd.org mailing list=20 >> https://lists.freebsd.org/mailman/listinfo/freebsd-current To >> unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >>=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Nov 19 14:10:50 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E06D7A322C0 for ; Thu, 19 Nov 2015 14:10:50 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 721A71945 for ; Thu, 19 Nov 2015 14:10:50 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 621A4153413; Thu, 19 Nov 2015 15:10:41 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al8DQ3yToVQm; Thu, 19 Nov 2015 15:10:31 +0100 (CET) Received: from [192.168.101.176] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 06EF6153416; Thu, 19 Nov 2015 15:10:31 +0100 (CET) Subject: Re: DDB patches To: Dan Partelly References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <564DD241.9020801@digiware.nl> Cc: freebsd-current From: Willem Jan Withagen Message-ID: <564DD856.6030007@digiware.nl> Date: Thu, 19 Nov 2015 15:10:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 14:10:51 -0000 On 19-11-2015 14:53, Dan Partelly wrote: >> So not submitting a PR for an issue sound real strange to my ears. > > > It is NOT a patch for an issue, bug, anything on those lines at all. > It adds new features to DDB. Specifically it adds relational > operators. > > Since it doesn't solve any problems, I don't see why it should be added > to a problem database which is used for bug reports. > Unlike what you suggest here, I see lots of issues in Bugzilla which exactly what you describe: enhancements on already available tools. I've even submitted a few myself. An alternative for this might be submission to Phabricator if you'd like a more reviewing type of evaluation. --WjW > But then again, it may be just me. > > Dan > > > >> On 19 Nov 2015, at 15:44, Willem Jan Withagen wrote: >> >> On 19-11-2015 10:57, Dan Partelly wrote: >>> Hey Pedro, >>> >>> Thanks a lot , mate. >>> >>> I’m reluctant to put it up as a PR, since some PR are outstanding for >>> years. >> >> What a strange argument.... >> >> Some PR's are fixed within hours/days.... >> Letting it linger in your mailbox after mental evaluation is not going >> to do anybody any good. >> >> As far as I understand is the PR database also the collective memory of >> things on/for/by/near/around the FreeBSD source code. People are >> explicitly asked to fill a PR so the issue at hand is not forgotten. >> >> So not submitting a PR for an issue sound real strange to my ears. >> >> But then again that's me. >> >> --WjW >> >> >>> Adrian, >>> >>> since Pedro has issue with hardware, could you try the patch and give >>> a resolution on it ? I reviewed it mentally (no FreeBSD atm machine >>> on which I could actually patch the kernel) and apart style changes >>> it looks OK . Physically i can test it again fro a couple of days. >>> Getting this reviewed & tested / committed or rejected would give me >>> an idea on how things actually work around here. This is actual code >>> which you can commit or reject not commentaries only like in the >>> thread regarding the binary code reuse. >>> >>> >>> [qute from libxo thread ] >>>>> It's all fine and good making technical decisions based on >>>>> drawings and handwaving and philosophizing, but at some point >>>>> someone has to do the code. The reason is simple - someone >>>>> offered to do the work and push it through. This isn't a >>>>> commercial thing where we get to make project >>decisions and >>>>> allocate resources - the juniper folk came up with a solution >>>>> that >>> >>> Once I see how things work around here once someone wrote the code, >>> and get this done one way or another , we could proceed to the >>> libification of ifconfig, should you so desire, and you believe we >>> can all benefit from it. >>> >>> >>> Dan >>> >>> >>> >>>> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >>> >>>> >>>> Hello; >>>> >>>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly >>>>> ha scritto: >>>>> >>>>> Hey Pedro, >>>>> >>>>> some times ago you got some DDB patches from me in which I added >>>>> relational ops support from it. The patch was a bit clobbered, >>>>> but last I know you cleaned it up and put it somewhere on >>>>> freebsd.org (prolly your page) up for review. >>>>> >>>> >>>> It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch >>>> >>>> I haven’t tested it though. >>>> >>>>> Could you or Adrian review the patch set , and if it is OK >>>>> potentially proceed with a commit ? Or if it is not ok for a >>>>> commit , please advice on a follow up. >>>>> >>>> >>>> I am having hardware issues so I won’t be able to do much in a >>>> while. Perhaps you should review it and submit it as a PR. >>>> >>>> Pedro. >>>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To >>> unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Nov 19 14:29:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E124A3261E for ; Thu, 19 Nov 2015 14:29:44 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C2AF912C5 for ; Thu, 19 Nov 2015 14:29:43 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.166] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id EC81115703; Thu, 19 Nov 2015 16:29:39 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: DDB patches From: Dan Partelly In-Reply-To: <564DD856.6030007@digiware.nl> Date: Thu, 19 Nov 2015 16:29:39 +0200 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <78FDD0DE-5CA0-44AB-B46C-9C95E4F8DA5B@rdsor.ro> References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <564DD241.9020801@digiware.nl> <564DD856.6030007@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 14:29:44 -0000 > Unlike what you suggest here, I see lots of issues in Bugzilla which > exactly what you describe: enhancements on already available tools. > I've even submitted a few myself. Thats great Willem.=20 But no matter what you find odd or not, I am simply following what Ive = read on some=20 page on freebsd.org that one of the ways of contributing is by = submitting code=20 on the mailing-lists , where =E2=80=9Csomebody will happily pick up = changes=E2=80=9D.=20 So, if you continue to find this odd, please take it up with the = web-masters on=20 freebsd.org to update the resources regarding contributing to the = project.=20 > On 19 Nov 2015, at 16:10, Willem Jan Withagen wrote: >=20 > On 19-11-2015 14:53, Dan Partelly wrote: >>> So not submitting a PR for an issue sound real strange to my ears. >>=20 >>=20 >> It is NOT a patch for an issue, bug, anything on those lines at all.=20= >> It adds new features to DDB. Specifically it adds relational=20 >> operators.=20 >>=20 >> Since it doesn't solve any problems, I don't see why it should be = added=20 >> to a problem database which is used for bug reports.=20 >>=20 >=20 > Unlike what you suggest here, I see lots of issues in Bugzilla which > exactly what you describe: enhancements on already available tools. > I've even submitted a few myself. >=20 > An alternative for this might be submission to Phabricator if you'd = like > a more reviewing type of evaluation. >=20 > --WjW >=20 >> But then again, it may be just me. >>=20 >> Dan >>=20 >>=20 >>=20 >>> On 19 Nov 2015, at 15:44, Willem Jan Withagen = wrote: >>>=20 >>> On 19-11-2015 10:57, Dan Partelly wrote: >>>> Hey Pedro, >>>>=20 >>>> Thanks a lot , mate. >>>>=20 >>>> I=E2=80=99m reluctant to put it up as a PR, since some PR are = outstanding for >>>> years. >>>=20 >>> What a strange argument.... >>>=20 >>> Some PR's are fixed within hours/days.... >>> Letting it linger in your mailbox after mental evaluation is not = going >>> to do anybody any good. >>>=20 >>> As far as I understand is the PR database also the collective memory = of >>> things on/for/by/near/around the FreeBSD source code. People are >>> explicitly asked to fill a PR so the issue at hand is not forgotten. >>>=20 >>> So not submitting a PR for an issue sound real strange to my ears. >>>=20 >>> But then again that's me. >>>=20 >>> --WjW >>>=20 >>>=20 >>>> Adrian, >>>>=20 >>>> since Pedro has issue with hardware, could you try the patch and = give >>>> a resolution on it ? I reviewed it mentally (no FreeBSD atm machine >>>> on which I could actually patch the kernel) and apart style = changes >>>> it looks OK . Physically i can test it again fro a couple of days. >>>> Getting this reviewed & tested / committed or rejected would give = me >>>> an idea on how things actually work around here. This is actual = code >>>> which you can commit or reject not commentaries only like in the >>>> thread regarding the binary code reuse. >>>>=20 >>>>=20 >>>> [qute from libxo thread ] >>>>>> It's all fine and good making technical decisions based on >>>>>> drawings and handwaving and philosophizing, but at some point >>>>>> someone has to do the code. The reason is simple - someone >>>>>> offered to do the work and push it through. This isn't a >>>>>> commercial thing where we get to make project >>decisions and >>>>>> allocate resources - the juniper folk came up with a solution >>>>>> that >>>>=20 >>>> Once I see how things work around here once someone wrote the = code, >>>> and get this done one way or another , we could proceed to the >>>> libification of ifconfig, should you so desire, and you believe we >>>> can all benefit from it. >>>>=20 >>>>=20 >>>> Dan >>>>=20 >>>>=20 >>>>=20 >>>>> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >>>>=20 >>>>>=20 >>>>> Hello; >>>>>=20 >>>>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly >>>>>> ha scritto: >>>>>>=20 >>>>>> Hey Pedro, >>>>>>=20 >>>>>> some times ago you got some DDB patches from me in which I added >>>>>> relational ops support from it. The patch was a bit clobbered,=20 >>>>>> but last I know you cleaned it up and put it somewhere on >>>>>> freebsd.org (prolly your page) up for review. >>>>>>=20 >>>>>=20 >>>>> It=E2=80=99s here: = https://people.freebsd.org/~pfg/patches/ddb.patch >>>>>=20 >>>>> I haven=E2=80=99t tested it though. >>>>>=20 >>>>>> Could you or Adrian review the patch set , and if it is OK >>>>>> potentially proceed with a commit ? Or if it is not ok for a >>>>>> commit , please advice on a follow up. >>>>>>=20 >>>>>=20 >>>>> I am having hardware issues so I won=E2=80=99t be able to do much = in a >>>>> while. Perhaps you should review it and submit it as a PR. >>>>>=20 >>>>> Pedro. >>>>>=20 >>>>=20 >>>> _______________________________________________=20 >>>> freebsd-current@freebsd.org mailing list=20 >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To >>>> unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 >=20 From owner-freebsd-current@freebsd.org Thu Nov 19 14:37:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91C1BA32789; Thu, 19 Nov 2015 14:37:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 78A0417FC; Thu, 19 Nov 2015 14:37:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 63D6F12B9; Thu, 19 Nov 2015 14:37:47 +0000 (UTC) Date: Thu, 19 Nov 2015 14:37:42 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: hselasky@FreeBSD.org, smh@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1254712315.77.1447943867120.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <244831630.75.1447932092765.JavaMail.jenkins@jenkins-9.freebsd.org> References: <244831630.75.1447932092765.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1701 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 14:37:49 -0000 FreeBSD_HEAD_i386 - Build #1701 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1701/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1701/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1701/console Change summaries: 291072 by hselasky: Add the mlx5 and mlx5en modules to the i386 and amd64 kernel builds by default and add a manual page for mlx5en. The mlx5 module contains shared code for both infiniband and ethernet. The mlx5en module contains specific code for ethernet functionality only. A mlx5ib module is in the works for infiniband support. Supported hardware: - ConnectX-4: 10/20/25/40/50/56/100Gb/s speeds. - ConnectX-4 LX: 10/25/40/50Gb/s speeds (low power consumption) Refer to the mlx5en(4) manual page for a comprehensive list. The team porting the mlx5 driver(s) to FreeBSD: - Hans Petter Selasky - Oded Shanoon - Meny Yossefi - Shany Michaely - Shahar Klein - Daria Genzel - Mark Bloch Differential Revision: https://reviews.freebsd.org/D4163 Submitted by: Mark Block Sponsored by: Mellanox Technologies Reviewed by: gnn @ MFC after: 3 days 291071 by smh: Fix zfs(8) set options Fix zfs(8) not formatting due to wrong macro (Oc) in the syntax for the new zfs set multiple dataset properties option. PR: 204631 Submitted by: Thomas Eberhardt Sponsored by: Multiplay From owner-freebsd-current@freebsd.org Thu Nov 19 15:04:40 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A43BBA32D06 for ; Thu, 19 Nov 2015 15:04:40 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6206F1259 for ; Thu, 19 Nov 2015 15:04:40 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by ioir85 with SMTP id r85so91623141ioi.1 for ; Thu, 19 Nov 2015 07:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BjlRMw6ml3kVoFhCvVfqA/x10gHMmDVfqC5eydzYbh8=; b=KVibywDeg2KRlwZuZJm5ZTffd7Ix9R2LgdFi4PoWxmnMG8rZWfIbKOwix2iCyPj+vr LkoLZOZk+rafigq7R2RZEH5AUqwFvrIXm+QLHs074s743DPI109bEa4/5E2clBIr0RNe Hup+hA16o2AE4ooPOaEQutGJZTaZ3gjRgoKNdYzgInDt+lT0KvCAhg4/rMWBlY25iu4F pvoe5G0jhMSoxc005s0H0YOT8iCMoxK9N+nrVgzmvk/kjkaFcvgtKOCYbx83gyEHlRBt s++F7xWiZwSQtbDHB5KPrts3ZAAnBYuHXtlra0Q9p5y20WMgOYJJ04tJRDhWjEVxHFVi tUpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BjlRMw6ml3kVoFhCvVfqA/x10gHMmDVfqC5eydzYbh8=; b=FR5JWD2O/cL5Oc/Ok8ppjc6ozgDSPQSCsx3jj3G1EOLqAc92kk9gtcjCGgXfEfbVsG rfnKMJdWaCYy25KSpddNHM9QSOvjL5hri5BnSb4x3oJGykMzXb9QJ2gOPheYdrh7TePB zR2IpDOQPJI0UPLjpXb7meLhVrzwqzbIhDmNrxXOk6E7vUTJA5at0485VVv/xeQI7KRo 9/1UcllFWBhAPoJotWnEDaDd8ao4plUIkOnFQJAdRVrqpMV5+4Rhxx0Ow5ESHBJhKf8E bzg8qFOtrRV2xjna+17R4NhM7giW0gcqz8dAL+ONtvhsZCadBvTRP8eL8ymdeWFQoaCQ XgOw== MIME-Version: 1.0 X-Received: by 10.107.4.70 with SMTP id 67mr9039477ioe.13.1447945479435; Thu, 19 Nov 2015 07:04:39 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.36.222.198 with HTTP; Thu, 19 Nov 2015 07:04:39 -0800 (PST) In-Reply-To: <78FDD0DE-5CA0-44AB-B46C-9C95E4F8DA5B@rdsor.ro> References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <564DD241.9020801@digiware.nl> <564DD856.6030007@digiware.nl> <78FDD0DE-5CA0-44AB-B46C-9C95E4F8DA5B@rdsor.ro> Date: Thu, 19 Nov 2015 09:04:39 -0600 X-Google-Sender-Auth: zhJeLm0Mlc6bK29wQw_SjQVeyLQ Message-ID: Subject: Re: DDB patches From: Justin Hibbits To: Dan Partelly Cc: Willem Jan Withagen , freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:04:40 -0000 On Thu, Nov 19, 2015 at 8:29 AM, Dan Partelly wrote= : >> Unlike what you suggest here, I see lots of issues in Bugzilla which >> exactly what you describe: enhancements on already available tools. >> I've even submitted a few myself. > > Thats great Willem. > > But no matter what you find odd or not, I am simply following what Ive re= ad on some > page on freebsd.org that one of the ways of contributing is by submitting= code > on the mailing-lists , where =E2=80=9Csomebody will happily pick up chang= es=E2=80=9D. > > So, if you continue to find this odd, please take it up with the web-mast= ers on > freebsd.org to update the resources regarding contributing to the project= . Dan, I think a lot of people tend to use the 'one-two punch' of both PR and mailing list. Mailing list to flesh it out and discuss the idea, and the PR when it's ready to go in. I've done a very cursory review of your patch, and it looks pretty good. Unfortunately, my time is booked for more projects than I really have time for, so I'd be unable to test it. If you submit it as a PR in bugzilla, at the very least the patch won't get lost when someone else comes looking for the feature, and more likely it'll get picked up by someone rather quickly or in the next triage phase (some people like to do bug triaging periodically, where things like this get their basic testing and commit). When you said it's not a patch for an issue/bug/etc, one could say the bug is that the patch isn't already in the tree :) . - Justin From owner-freebsd-current@freebsd.org Thu Nov 19 15:09:03 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EA6AA32E2B for ; Thu, 19 Nov 2015 15:09:03 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id EC13314D0 for ; Thu, 19 Nov 2015 15:09:02 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: (qmail 27992 invoked by uid 99); 19 Nov 2015 15:09:01 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Nov 2015 15:09:01 +0000 Received: from [192.168.0.103] (unknown [181.55.232.163]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 21C151A0338; Thu, 19 Nov 2015 15:09:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: DDB patches From: Pedro Giffuni In-Reply-To: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> Date: Thu, 19 Nov 2015 10:08:57 -0500 Cc: Adrian Chadd , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> To: Dan Partelly X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:09:03 -0000 > Il giorno 19/nov/2015, alle ore 04:57, Dan Partelly = ha scritto: >=20 > Hey Pedro, >=20 > Thanks a lot , mate.=20 >=20 > I=E2=80=99m reluctant to put it up as a PR, since some PR are = outstanding for years. =20 >=20 Well, that=E2=80=99s the way the project works: you cannot really depend = on me, or anyone else keeping old patches around. If you want a record of your submission bugzilla is the place to keep it. And of course there is no = guarantee anyone will look at it but your chances are much better in bugzilla than in a mailinglist. > Adrian, >=20 > since Pedro has issue with hardware, could you try the patch and give = a resolution on it ? I reviewed it mentally (no FreeBSD atm machine on = which I could actually patch the kernel) and apart style changes it = looks OK . Physically i can test it again fro a couple of days. Mental reviews don=E2=80=99t count much: if you are not running FreeBSD = and standing behind your patch the chances of being taking seriously are slim. > Getting this reviewed & tested / committed or rejected would give me = an idea on how things actually work around here. This is actual code = which you can commit or reject not commentaries only like in the thread = regarding the binary code reuse. =20 >=20 >=20 I recall you stated the patch was =E2=80=9Cnot ready=E2=80=9D when you = posted it. I haven=E2=80=99t really done anything to say it is ready. Unless someone else finds time to do = real testing it won=E2=80=99t happen. Adrian tends to do some particularly valuable contributions to the = project. I would prefer if he spends his time on more important tasks. > [qute from libxo thread ] >>> It's all fine and good making technical decisions based on drawings = and handwaving and philosophizing, but at some point someone has to do >>> the code. >>> The reason is simple - someone offered to do the work and push it = through. This isn't a commercial thing where we get to make project = >>decisions and allocate resources - the juniper folk came up with a = solution that >=20 > Once I see how things work around here once someone wrote the code, = and get this done one way or another , we could proceed to the = libification of ifconfig, should you so desire, and you believe we can = all benefit from it.=20 >=20 Wrong approach. You can=E2=80=99t really blackmail someone into taking = your changes. Things work like this: - You discuss your idea and try to get some consensus in the = lists/IRC/conferences. - You *write* a specific proof of concept and get it discussed. - You finish your prototype. - Your work gets rejected until you get something some committer is = willing to support. - When there are no objections and a committer feels like it, your work = gets committed, which doesn=E2=80=99t necessarily mean it will stay. - You are expected to maintain it. Libxo already went through this process. We are particularly NOT interested in code where the original = contributor will walk away as soon as he/she receives criticism or has plans that do not match = ours. If this is not your ideal workflow =E2=80=A6 fork your own BSD, a lot of = intelligent people do just that. Pedro. >=20 > Dan >=20 >=20 >=20 >> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >=20 >>=20 >> Hello; >>=20 >>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly = ha scritto: >>>=20 >>> Hey Pedro, >>>=20 >>> some times ago you got some DDB patches from me in which I added = relational ops support from it. The patch was a bit clobbered,=20 >>> but last I know you cleaned it up and put it somewhere on = freebsd.org (prolly your page) up for review.=20 >>>=20 >>=20 >> It=E2=80=99s here: >> https://people.freebsd.org/~pfg/patches/ddb.patch >>=20 >> I haven=E2=80=99t tested it though. >>=20 >>> Could you or Adrian review the patch set , and if it is OK = potentially proceed with a commit ? Or if it is not ok for a commit , = please advice on a follow up.=20 >>>=20 >>=20 >> I am having hardware issues so I won=E2=80=99t be able to do much in = a while. >> Perhaps you should review it and submit it as a PR. >>=20 >> Pedro. >>=20 >=20 From owner-freebsd-current@freebsd.org Thu Nov 19 15:33:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFC61A33407 for ; Thu, 19 Nov 2015 15:33:11 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 413C915FF; Thu, 19 Nov 2015 15:33:11 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id B9FBB120FD; Thu, 19 Nov 2015 17:33:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 19 Nov 2015 17:33:21 +0200 From: dan_partelly To: Pedro Giffuni Cc: Adrian Chadd , freebsd-current Subject: Re: DDB patches In-Reply-To: References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:33:11 -0000 Hi Pedro, Sure, no worries , I am grateful for all you did, couldn't ask for more. I have yet no idea how the projects works, but in the thread in which I questioned the wisdom of having utilities in base spitting out JSON -- instead of properly libyifing some utilities -- Adrian has stated something which I perceived to be on the line "everybody talks, noone codes". So I expressed my willingness to participate to libifing some utilities from base, but , understandingly I hope, I want to see how this process goes with code which already existed , before investing time in created new code So once again, I thank you ! On Thu, 19 Nov 2015 10:08:57 -0500, Pedro Giffuni wrote: >> Il giorno 19/nov/2015, alle ore 04:57, Dan Partelly >> ha scritto: >> >> Hey Pedro, >> >> Thanks a lot , mate. >> >> I’m reluctant to put it up as a PR, since some PR are outstanding for >> years. >> > > Well, that’s the way the project works: you cannot really depend on me, or > anyone else keeping old patches around. If you want a record of your > submission bugzilla is the place to keep it. And of course there is no > guarantee > anyone will look at it but your chances are much better in bugzilla than > in a mailinglist. > > > >> Adrian, >> >> since Pedro has issue with hardware, could you try the patch and give a >> resolution on it ? I reviewed it mentally (no FreeBSD atm machine on >> which I could actually patch the kernel) and apart style changes it >> looks OK . Physically i can test it again fro a couple of days. > > Mental reviews don’t count much: if you are not running FreeBSD and > standing > behind your patch the chances of being taking seriously are slim. > > >> Getting this reviewed & tested / committed or rejected would give me an >> idea on how things actually work around here. This is actual code which >> you can commit or reject not commentaries only like in the thread >> regarding the binary code reuse. >> >> > > I recall you stated the patch was “not ready” when you posted it. I > haven’t really > done anything to say it is ready. Unless someone else finds time to do real > testing it won’t happen. > > Adrian tends to do some particularly valuable contributions to the > project. I > would prefer if he spends his time on more important tasks. > >> [qute from libxo thread ] >>>> It's all fine and good making technical decisions based on drawings >>>> and handwaving and philosophizing, but at some point someone has to do >>>> the code. >>>> The reason is simple - someone offered to do the work and push it >>>> through. This isn't a commercial thing where we get to make project >>>> >>decisions and allocate resources - the juniper folk came up with a >>>> solution that >> >> Once I see how things work around here once someone wrote the code, >> and get this done one way or another , we could proceed to the >> libification of ifconfig, should you so desire, and you believe we can >> all benefit from it. >> > > Wrong approach. You can’t really blackmail someone into taking your > changes. > > Things work like this: > > - You discuss your idea and try to get some consensus in the > lists/IRC/conferences. > - You *write* a specific proof of concept and get it discussed. > - You finish your prototype. > - Your work gets rejected until you get something some committer is > willing to support. > - When there are no objections and a committer feels like it, your work > gets committed, > which doesn’t necessarily mean it will stay. > - You are expected to maintain it. > > Libxo already went through this process. > > We are particularly NOT interested in code where the original contributor > will walk > away as soon as he/she receives criticism or has plans that do not match > ours. > If this is not your ideal workflow … fork your own BSD, a lot of > intelligent > people do just that. > > Pedro. > >> >> Dan >> >> >> >>> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >> >>> >>> Hello; >>> >>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly >>>> ha scritto: >>>> >>>> Hey Pedro, >>>> >>>> some times ago you got some DDB patches from me in which I added >>>> relational ops support from it. The patch was a bit clobbered, >>>> but last I know you cleaned it up and put it somewhere on freebsd.org >>>> (prolly your page) up for review. >>>> >>> >>> It’s here: >>> https://people.freebsd.org/~pfg/patches/ddb.patch >>> >>> I haven’t tested it though. >>> >>>> Could you or Adrian review the patch set , and if it is OK potentially >>>> proceed with a commit ? Or if it is not ok for a commit , please advice >>>> on a follow up. >>>> >>> >>> I am having hardware issues so I won’t be able to do much in a while. >>> Perhaps you should review it and submit it as a PR. >>> >>> Pedro. >>> >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Nov 19 16:04:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 567E9A33847 for ; Thu, 19 Nov 2015 16:04:36 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCBA71254 for ; Thu, 19 Nov 2015 16:04:35 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id A831D153408; Thu, 19 Nov 2015 17:04:31 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9a_xfssFmKf; Thu, 19 Nov 2015 17:04:20 +0100 (CET) Received: from [192.168.101.176] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id ED6C0153401; Thu, 19 Nov 2015 17:04:19 +0100 (CET) Subject: Re: DDB patches To: Dan Partelly References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <564DD241.9020801@digiware.nl> <564DD856.6030007@digiware.nl> <78FDD0DE-5CA0-44AB-B46C-9C95E4F8DA5B@rdsor.ro> Cc: freebsd-current From: Willem Jan Withagen Message-ID: <564DF303.4090909@digiware.nl> Date: Thu, 19 Nov 2015 17:04:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <78FDD0DE-5CA0-44AB-B46C-9C95E4F8DA5B@rdsor.ro> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 16:04:36 -0000 On 19-11-2015 15:29, Dan Partelly wrote: >> Unlike what you suggest here, I see lots of issues in Bugzilla which >> exactly what you describe: enhancements on already available tools. >> I've even submitted a few myself. > > Thats great Willem. > > But no matter what you find odd or not, I am simply following what Ive read on some > page on freebsd.org that one of the ways of contributing is by submitting code > on the mailing-lists , where “somebody will happily pick up changes”. > > So, if you continue to find this odd, please take it up with the web-masters on > freebsd.org to update the resources regarding contributing to the project. I have to admit that you have read more of the freebsd.org website than that I have.... Most of the time I lurk on the lists here. Probably since the 1.0 incarnation of FreeBSD. And what I tried to explain, was that the bugtracker is used for more than just bugs. I've learnt that from several responses on the lists. I also saw that Justin picked up with a functional answers on your patch, so I'll go back into lurking mode. --WjW > > > >> On 19 Nov 2015, at 16:10, Willem Jan Withagen wrote: >> >> On 19-11-2015 14:53, Dan Partelly wrote: >>>> So not submitting a PR for an issue sound real strange to my ears. >>> >>> >>> It is NOT a patch for an issue, bug, anything on those lines at all. >>> It adds new features to DDB. Specifically it adds relational >>> operators. >>> >>> Since it doesn't solve any problems, I don't see why it should be added >>> to a problem database which is used for bug reports. >>> >> >> Unlike what you suggest here, I see lots of issues in Bugzilla which >> exactly what you describe: enhancements on already available tools. >> I've even submitted a few myself. >> >> An alternative for this might be submission to Phabricator if you'd like >> a more reviewing type of evaluation. >> >> --WjW >> >>> But then again, it may be just me. >>> >>> Dan >>> >>> >>> >>>> On 19 Nov 2015, at 15:44, Willem Jan Withagen wrote: >>>> >>>> On 19-11-2015 10:57, Dan Partelly wrote: >>>>> Hey Pedro, >>>>> >>>>> Thanks a lot , mate. >>>>> >>>>> I’m reluctant to put it up as a PR, since some PR are outstanding for >>>>> years. >>>> >>>> What a strange argument.... >>>> >>>> Some PR's are fixed within hours/days.... >>>> Letting it linger in your mailbox after mental evaluation is not going >>>> to do anybody any good. >>>> >>>> As far as I understand is the PR database also the collective memory of >>>> things on/for/by/near/around the FreeBSD source code. People are >>>> explicitly asked to fill a PR so the issue at hand is not forgotten. >>>> >>>> So not submitting a PR for an issue sound real strange to my ears. >>>> >>>> But then again that's me. >>>> >>>> --WjW >>>> >>>> >>>>> Adrian, >>>>> >>>>> since Pedro has issue with hardware, could you try the patch and give >>>>> a resolution on it ? I reviewed it mentally (no FreeBSD atm machine >>>>> on which I could actually patch the kernel) and apart style changes >>>>> it looks OK . Physically i can test it again fro a couple of days. >>>>> Getting this reviewed & tested / committed or rejected would give me >>>>> an idea on how things actually work around here. This is actual code >>>>> which you can commit or reject not commentaries only like in the >>>>> thread regarding the binary code reuse. >>>>> >>>>> >>>>> [qute from libxo thread ] >>>>>>> It's all fine and good making technical decisions based on >>>>>>> drawings and handwaving and philosophizing, but at some point >>>>>>> someone has to do the code. The reason is simple - someone >>>>>>> offered to do the work and push it through. This isn't a >>>>>>> commercial thing where we get to make project >>decisions and >>>>>>> allocate resources - the juniper folk came up with a solution >>>>>>> that >>>>> >>>>> Once I see how things work around here once someone wrote the code, >>>>> and get this done one way or another , we could proceed to the >>>>> libification of ifconfig, should you so desire, and you believe we >>>>> can all benefit from it. >>>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >>>>> >>>>>> >>>>>> Hello; >>>>>> >>>>>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly >>>>>>> ha scritto: >>>>>>> >>>>>>> Hey Pedro, >>>>>>> >>>>>>> some times ago you got some DDB patches from me in which I added >>>>>>> relational ops support from it. The patch was a bit clobbered, >>>>>>> but last I know you cleaned it up and put it somewhere on >>>>>>> freebsd.org (prolly your page) up for review. >>>>>>> >>>>>> >>>>>> It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch >>>>>> >>>>>> I haven’t tested it though. >>>>>> >>>>>>> Could you or Adrian review the patch set , and if it is OK >>>>>>> potentially proceed with a commit ? Or if it is not ok for a >>>>>>> commit , please advice on a follow up. >>>>>>> >>>>>> >>>>>> I am having hardware issues so I won’t be able to do much in a >>>>>> while. Perhaps you should review it and submit it as a PR. >>>>>> >>>>>> Pedro. >>>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To >>>>> unsubscribe, send any mail to >>>>> "freebsd-current-unsubscribe@freebsd.org" >>>>> >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> > From owner-freebsd-current@freebsd.org Thu Nov 19 17:13:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27C8EA32787 for ; Thu, 19 Nov 2015 17:13:15 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E8721B7C for ; Thu, 19 Nov 2015 17:13:14 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.208] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id D54FC1928D7; Thu, 19 Nov 2015 17:13:07 +0000 (UTC) To: freebsd-current From: Sean Bruno Subject: sys/modules "make clean" seems broken again X-Enigmail-Draft-Status: N1210 Message-ID: <564E0322.8050308@freebsd.org> Date: Thu, 19 Nov 2015 09:13:06 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 17:13:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I thought I fixed this a year or two ago, but now a "make clean" in sys/modules seems to leave bus_if.h device_if.h and pci_if.h in the directory. Should I just add these to the clean targets? Index: kmod.mk =================================================================== - --- kmod.mk (revision 290770) +++ kmod.mk (working copy) @@ -425,6 +425,10 @@ ${SYSDIR}/${MACHINE}/${MACHINE}/genassym.c .endif +.if !empty(SRCS:M${_i}pci_if.h) +CLEANFILES+= ${_i}pci_if.h ${_i}device_if.h ${_i}bus_if.h +.endif + lint: ${SRCS} ${LINT} ${LINTKERNFLAGS} ${CFLAGS:M-[DILU]*} ${.ALLSRC:M*.c} sean bcc -- imp@ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWTgMbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5ketYIAKTynLglAjsGrfuES7ibF40p n9hcbKGTDX9w3EUDNtL2Eho8WdZnuJ1gP4EtkHIQegeFPl156nt26jg6THYSFFiO oFFxAwR7f7S/S6+AjP7CMvdISxKPgmx0h8TEMIG0jatYPtH529WAM5plvD/GBJ1d pWBiqkTYnzmzaKz5cUXthHL2cEcerw4imakLj7lKGWw+W5kpQNbzrcqhCdYxCz3v s19ccxQtBrLE3aufvIGErjS28qa38AIYAd52EdTlObDK61f9H0S+O85DexAyMcEE e1dURWI/X/s13PQvZ7Cq/6nKVjqCUKUFe3sU/qvMCTm3jgS/7Gip5oK/BVix2R4= =k8Iw -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Thu Nov 19 18:48:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4358A3391E for ; Thu, 19 Nov 2015 18:48:10 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89C0E184A; Thu, 19 Nov 2015 18:48:10 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [192.168.9.61] (62-2-145-226.static.cablecom.ch [62.2.145.226]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 8BD6EB050C8; Thu, 19 Nov 2015 19:39:45 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: buildincludes: don't know how to make libelf.h etc. From: Franco Fichtner In-Reply-To: <56413887.5010302@FreeBSD.org> Date: Thu, 19 Nov 2015 19:39:44 +0100 Cc: freebsd-current Content-Transfer-Encoding: 7bit Message-Id: <06677E8E-98E3-4E4F-BF59-64187802BBA7@lastsummer.de> References: <7D199C04-0ECD-4F58-9A16-C36B51389CB1@lastsummer.de> <56413887.5010302@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3096.5) X-Virus-Scanned: clamav-milter 0.98.7 at host64.kissl.de X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 18:48:10 -0000 Hi Bryan, Apologies for the delay. Yes, this is still happening. This is the script I'm using with some trampoline things in a makefile and a common.sh script. It works on releng/10.1 and releng/10.2 without modification: https://github.com/opnsense/tools/blob/master/build/base.sh In any of the 11-CURRENT revisions of the last two weeks I've ran into this issue for buildworld, but not for buildkernel. If I run this command sequence in a shell directly, 11-CURRENT builds fine. My latest step was filtering the environment while calling buildworld and I've had no issues. While it's true that the environment is polluted with variables for various build steps, it feels like a regression, because that wasn't needed on 10.x at all. I've double-checked by running the unfiltered script again and it runs into the same issues as described in the original message. What is the stance regarding environment poisoning and the source tree build framework? Is this a best effort setup or does identifying the bad env variables matter? I can probably chase them down if needed. > On 10 Nov 2015, at 1:21 AM, Bryan Drewery wrote: > > What exact release of 10.1 are you on? The release, or somewhere in head > during the 10.1 lifecycle? 10.1-RELEASE-p24 > What revision were you trying to build? Any of the HEAD revisions of the last two weeks, sorry for not being more specific here, but this wasn't related to any specific code churn. > What do you have in /etc/make.conf and /etc/src.conf? https://github.com/opnsense/tools/blob/master/config/latest/make.conf https://github.com/opnsense/tools/blob/master/config/latest/src.conf > What exact command did you run? See above. > Can you provide a full buildworld log please? Only if really needed. Cheers, Franco From owner-freebsd-current@freebsd.org Thu Nov 19 18:52:14 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C6F1A33A70 for ; Thu, 19 Nov 2015 18:52:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 454E91B68; Thu, 19 Nov 2015 18:52:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 3F6C71CE9; Thu, 19 Nov 2015 18:52:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id EF1CA17231; Thu, 19 Nov 2015 18:52:13 +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 YxnU3IKW9H_n; Thu, 19 Nov 2015 18:52:11 +0000 (UTC) Subject: Re: buildincludes: don't know how to make libelf.h etc. DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 25C4C1722B To: Franco Fichtner References: <7D199C04-0ECD-4F58-9A16-C36B51389CB1@lastsummer.de> <56413887.5010302@FreeBSD.org> <06677E8E-98E3-4E4F-BF59-64187802BBA7@lastsummer.de> Cc: freebsd-current From: Bryan Drewery Organization: FreeBSD Message-ID: <564E1A5A.3030105@FreeBSD.org> Date: Thu, 19 Nov 2015 10:52:10 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <06677E8E-98E3-4E4F-BF59-64187802BBA7@lastsummer.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 18:52:14 -0000 On 11/19/15 10:39 AM, Franco Fichtner wrote: > Hi Bryan, > > Apologies for the delay. Yes, this is still happening. > > This is the script I'm using with some trampoline things in > a makefile and a common.sh script. It works on releng/10.1 and > releng/10.2 without modification: > > https://github.com/opnsense/tools/blob/master/build/base.sh > > In any of the 11-CURRENT revisions of the last two weeks I've > ran into this issue for buildworld, but not for buildkernel. > > If I run this command sequence in a shell directly, 11-CURRENT > builds fine. > > My latest step was filtering the environment while calling > buildworld and I've had no issues. While it's true that the > environment is polluted with variables for various build > steps, it feels like a regression, because that wasn't needed > on 10.x at all. > > I've double-checked by running the unfiltered script again > and it runs into the same issues as described in the original > message. > > What is the stance regarding environment poisoning and the > source tree build framework? Is this a best effort setup > or does identifying the bad env variables matter? I can > probably chase them down if needed. > >> On 10 Nov 2015, at 1:21 AM, Bryan Drewery wrote: >> >> What exact release of 10.1 are you on? The release, or somewhere in head >> during the 10.1 lifecycle? > > 10.1-RELEASE-p24 > >> What revision were you trying to build? > > Any of the HEAD revisions of the last two weeks, sorry for > not being more specific here, but this wasn't related to any > specific code churn. > >> What do you have in /etc/make.conf and /etc/src.conf? > > https://github.com/opnsense/tools/blob/master/config/latest/make.conf > https://github.com/opnsense/tools/blob/master/config/latest/src.conf > >> What exact command did you run? > > See above. > >> Can you provide a full buildworld log please? Nothing sticks out as a problem in the above. Do you have unknown files in your checkout? Can you check with 'git status' or 'svn status' ? > > Only if really needed. > I think it will be needed. Feel free to send me it off list. > > Cheers, > Franco > -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Thu Nov 19 18:57:25 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1D00A33B0C for ; Thu, 19 Nov 2015 18:57:25 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A7E001D42 for ; Thu, 19 Nov 2015 18:57:25 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: by mailman.ysv.freebsd.org (Postfix) id A7ACCA33B0A; Thu, 19 Nov 2015 18:57:25 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A71D3A33B09; Thu, 19 Nov 2015 18:57:25 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [199.15.120.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 844041D41; Thu, 19 Nov 2015 18:57:25 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 3p1qlt0342zJC; Thu, 19 Nov 2015 12:48:42 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3p1qls2gcLz2LF; Thu, 19 Nov 2015 12:48:41 -0600 (CST) Date: Thu, 19 Nov 2015 12:48:41 -0600 From: "Matthew D. Fuller" To: "Kenneth D. Merry" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20151119184841.GM30248@over-yonder.net> References: <20151118171309.GA3564@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151118171309.GA3564@mithlond.kdm.org> X-Editor: vi X-OS: FreeBSD X-Virus-Scanned: clamav-milter 0.98.7 at mail.tarragon.infocus-llc.com X-Virus-Status: Clean User-Agent: Mutt/1.5.24-fullermd.4 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 18:57:25 -0000 On Wed, Nov 18, 2015 at 12:13:09PM -0500 I heard the voice of Kenneth D. Merry, and lo! it spake thus: > > Testing and comments are welcome. GELI does explicit handling of each BIO type, so will need to be updated to pass it through (possibly in the form of inverting the default handling?) or it'll just EOPNOTSUPP it, whether the underlying layer does or not. I wouldn't be surprised if there were other geom layers that did similar things. Not meant to be read as some kind of "you need to"; just a comment on a possible [lack of] impact. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@freebsd.org Thu Nov 19 19:01:27 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21B93A33CDF for ; Thu, 19 Nov 2015 19:01:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAA201FFD; Thu, 19 Nov 2015 19:01:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by obdgf3 with SMTP id gf3so68704197obd.3; Thu, 19 Nov 2015 11:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h1rH12XTRcDG6keWsfljEWeq1mQGwSIowruZvc+XQLA=; b=QnHsb3KC0IKEnCJkGIU7yyZkJNOiaC2+j4r+ajKgGSKTL9crJO6j0oa7akB2IbbPoe QxGHXtDwiF/Oj1FJYfGK65LzzYwjVCHutMPVNBiagwVgx+AJe5LE+05RwGlCxmWRVnlM 4y1R3Yk97RvsfOGeCGA5dbS6WU9KxiFWHJtaPvpdU/l8Xezp4PUbV3QfT3A6tIZGCO56 wWAkWQqpLdMJuUaFetfP9OjC4EqjS3EXyqida8L0GkXB+QR8PZOCf+ANCI4O0ywIitDE ibbrC+CUDk7bO3wi/ZJAN47nuc2T/JgGBLwuP/XcfNQKLRny0glx4s8dLuL4Axztees0 SVYg== MIME-Version: 1.0 X-Received: by 10.60.159.230 with SMTP id xf6mr2937673oeb.43.1447959686257; Thu, 19 Nov 2015 11:01:26 -0800 (PST) Received: by 10.202.107.11 with HTTP; Thu, 19 Nov 2015 11:01:26 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Nov 2015 11:01:26 -0800 Message-ID: Subject: Re: DDB patches From: Adrian Chadd To: Pedro Giffuni Cc: Dan Partelly , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 19:01:27 -0000 [snip snip snippety snip] Hi Dan! Yeah, turns out trying to get a bunch of burnt out, time-poor developers with commit bits to commit stuff will typically end up with (a) things getting neglected, or (b) getting you a commit bit. :) Please grab the patch from pedro (which I reviewed, and it looks fine at a first pass) and dump it into reviews.freebsd.org. You'll have to create an account first. That way we can solicit some further reviews/comments before I just commit it. :) -a From owner-freebsd-current@freebsd.org Thu Nov 19 19:16:35 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4A7FA33FDD for ; Thu, 19 Nov 2015 19:16:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 809D219FE; Thu, 19 Nov 2015 19:16:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9191DB9C1; Thu, 19 Nov 2015 14:16:34 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Sean Bruno , 'Warner Losh' Subject: Re: sys/modules "make clean" seems broken again Date: Thu, 19 Nov 2015 10:12:58 -0800 Message-ID: <3514235.7QMnNNElsE@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <564E0322.8050308@freebsd.org> References: <564E0322.8050308@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 19 Nov 2015 14:16:34 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 19:16:35 -0000 On Thursday, November 19, 2015 09:13:06 AM Sean Bruno wrote: > I thought I fixed this a year or two ago, but now a "make clean" in > sys/modules seems to leave bus_if.h device_if.h and pci_if.h in the > directory. > > Should I just add these to the clean targets? Blame Warner as his MFILES changes broke this. In particular, see r287263 which turned off cleaning these up. I'm not sure what that broke that caused it to be disabled. Your change is a gross hack though. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Nov 19 20:29:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E98F7A33F5F for ; Thu, 19 Nov 2015 20:29:51 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CD9D61230 for ; Thu, 19 Nov 2015 20:29:51 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id CA8A2A33F5D; Thu, 19 Nov 2015 20:29:51 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C90F9A33F5C; Thu, 19 Nov 2015 20:29:51 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86D98122F; Thu, 19 Nov 2015 20:29:50 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id tAJKTgtl025275 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Nov 2015 15:29:43 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id tAJKTgHD025274; Thu, 19 Nov 2015 15:29:42 -0500 (EST) (envelope-from ken) Date: Thu, 19 Nov 2015 15:29:42 -0500 From: "Kenneth D. Merry" To: "Matthew D. Fuller" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20151119202942.GA25213@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20151119184841.GM30248@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151119184841.GM30248@over-yonder.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Thu, 19 Nov 2015 15:29:43 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 20:29:52 -0000 On Thu, Nov 19, 2015 at 12:48:41 -0600, Matthew D. Fuller wrote: > On Wed, Nov 18, 2015 at 12:13:09PM -0500 I heard the voice of > Kenneth D. Merry, and lo! it spake thus: > > > > Testing and comments are welcome. > > GELI does explicit handling of each BIO type, so will need to be > updated to pass it through (possibly in the form of inverting the > default handling?) or it'll just EOPNOTSUPP it, whether the underlying > layer does or not. I wouldn't be surprised if there were other geom > layers that did similar things. > > Not meant to be read as some kind of "you need to"; just a comment on > a possible [lack of] impact. You're correct. For GEOM classes like GELI that don't change the layout on disk, passing the BIO_ZONE bio through would be the right thing to do. For those that change the layout (i.e. the lba you write on the virtual disk doesn't match what goes down to the physical disk), like graid or gstripe, I think all we really need to do is just make sure they return EOPNOTSUPP. If someone wants to modify that code to handle shingled disks, they can certainly do that. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Thu Nov 19 20:42:35 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7B80A334AC for ; Thu, 19 Nov 2015 20:42:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 92E311C3D for ; Thu, 19 Nov 2015 20:42:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 91414A334AB; Thu, 19 Nov 2015 20:42:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7710EA334AA for ; Thu, 19 Nov 2015 20:42:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 051871C3C; Thu, 19 Nov 2015 20:42:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p57BB9322.dip0.t-ipconnect.de [87.187.147.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 691B283E402; Thu, 19 Nov 2015 21:42:01 +0100 (CET) Received: from localhost (Titan.Leidinger.net [192.168.1.17]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id 820652061; Thu, 19 Nov 2015 21:41:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1447965718; bh=sps7rfDFjO40FlGnDQIrEXqt2F/TvGkXuftHipNQYPA=; h=Date:From:To:Subject:In-Reply-To:References; b=Xypl69IxfNbb+kyyDFMv2UgGfq1VPhRJEtiPa71ua6v475AnpipRjibY2PHOYif2E cShbXo1nqlQh+/Ku4skJC4pXuHNQZY6TixOKl8g7h1Uz+uveeVE+uSWqbDwBGtxSm3 O6iTMetouzPA/FTSkr8jlkUcuPHwmnh7JE5DAScO47b2/4EsW6ibH1FrCHbfsnzUyy qyGxHJLht5BEsHdOCnLt7PY5fD4QzFhTuoKNDtIWzzZ5LZiK0a6sHpP2RtGMhsidsH hTLBbo3vhnWm+hbhOs0ZF0afWFNYqUUVpPgmG06H8f2M7m8Q4OfrOr9O9Vq3ywbHDF YsRIr3NLGxeIQ== Date: Thu, 19 Nov 2015 21:42:00 +0100 From: Alexander Leidinger To: sbruno@FreeBSD.org, current@FreeBSD.org Subject: This igb change makes my igb not working anymore - Re: regression in igb/clang? Message-ID: <20151119214200.000066be@Leidinger.net> In-Reply-To: <20151111114532.000011fd@Leidinger.net> References: <20151111114532.000011fd@Leidinger.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 691B283E402.A104C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1448570523.63052@dRykM2UHD4KWgZcn21/4Kw X-EBL-Spam-Status: No X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 20:42:35 -0000 On Wed, 11 Nov 2015 11:45:32 +0100 Alexander Leidinger wrote: > Hi, > > I' updated a system with -current as of r287323 (end August) to > r290633 (yesterday). > > Result: no network connection (not even ping) on igb. > Ping internally (local addresses) works, anything outgoing/incoming > doesn't. And this is the function which causes it: e1000_rx_fifo_flush_82575(&adapter->hw); If I comment it out in if_igb.c, the network card works again. Full quote below for the PCI ID of my card in case it helps for fixing the issue. Bye, Alexander. > I disabled HW support (tso4, lro, rxcsum, txcsum): doesn't help. > > Did I miss some known defect/workaround? > > Anything I should test/provide besides what is below? > > The igb device is a: > ---snip--- > igb0@pci0:1:0:0: class=0x020000 card=0x34e28086 chip=0x10a78086 > rev=0x02 hdr=0x00 ---snip--- > > My src.conf: > ---snip--- > WITH_IDEA=yes > WITHOUT_PROFILE=yes > CFLAGS+=-DFTP_COMBINE_CWDS > MALLOC_PRODUCTION=yes > LOADER_FIREWIRE_SUPPORT=yes > #WITH_FAST_DEPEND=yes > ---snip--- > > My buildworld related config in make.conf: > ---snip--- > CFLAGS+= -O2 -pipe > COPTFLAGS= -O2 -pipe > #CPUTYPE?=core2 > #WITH_CCACHE_BUILD=yes > #.if (!empty(.CURDIR:M/usr/src*) > || !empty(.CURDIR:M/usr/obj*)|| !empty(.CURDIR:M/space/system/usr_obj*)) > #.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc) > #CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} > #CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} #.endif > #.endif > ---snip--- > > The commented out parts were active initially, but then I commented > them out, cleaned out /usr/obj (rm -r) and rebuild/reinstall to make > sure it's not due to them (CPUTYPE commented out due to the fact that > there's a new compiler, and I use zsh and there was a commit talking > about zsh and CPUTYPE workaround). > > Bye, > Alexander. > -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0xC773696B3BAC17DC http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0xC773696B3BAC17DC From owner-freebsd-current@freebsd.org Thu Nov 19 21:08:34 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7117A33BD3 for ; Thu, 19 Nov 2015 21:08:34 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD45B1334; Thu, 19 Nov 2015 21:08:34 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.38] (unknown [104.254.64.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 805AC1928D7; Thu, 19 Nov 2015 21:08:32 +0000 (UTC) Subject: Re: sys/modules "make clean" seems broken again To: John Baldwin , freebsd-current@freebsd.org References: <564E0322.8050308@freebsd.org> <3514235.7QMnNNElsE@ralph.baldwin.cx> Cc: 'Warner Losh' From: Sean Bruno Message-ID: <564E3A50.40600@freebsd.org> Date: Thu, 19 Nov 2015 13:08:32 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <3514235.7QMnNNElsE@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 21:08:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/19/15 10:12, John Baldwin wrote: > On Thursday, November 19, 2015 09:13:06 AM Sean Bruno wrote: >> I thought I fixed this a year or two ago, but now a "make clean" >> in sys/modules seems to leave bus_if.h device_if.h and pci_if.h >> in the directory. >> >> Should I just add these to the clean targets? > > Blame Warner as his MFILES changes broke this. In particular, see > r287263 which turned off cleaning these up. I'm not sure what that > broke that caused it to be disabled. > > Your change is a gross hack though. > Definitely. Just committing that would be pretty bad. There's similar code above it that I used as a template for this change. I'm not sure that its any less gross ... :-( sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWTjpQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k5AsH/2z3H/jFttevRnWKKP9C4DUM qkZKz3KjvQHDmlGXjPsfsAJQO7ngsoleGnFCFipRzk2ICmhfJQFcKYeSyUJVvRiO 91MkcQHEzmy4bOdLNbAKj5b9R/WtFwOdY3HwPyiI1tnxRTovnT2gJ5Qg0u6oNFdw RAFMrn9hMMYxcHRGjJyfOdXP0fYpb752oAlJR1cL3lpsh6MqZfqhDCZShimnveht R71BTUqQu3X4YdeXt4CRWFqwGchQD0J0T/wFp0JqA5oM2uK1JxenHqz/5mNzuQol X8xjrhN/Bh5sLK+QFsdBcmlbQ6aEsy7Dq8Abm7tWz46TCO1qcp1SgU+7Ny1+9eY= =f5LD -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Thu Nov 19 23:42:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 689A9A32CEB for ; Thu, 19 Nov 2015 23:42:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E1941F43 for ; Thu, 19 Nov 2015 23:42:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgeb1 with SMTP id b1so62775574qge.1 for ; Thu, 19 Nov 2015 15:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Z3czZC8dDRYylBILYvSVrhTohokGoHlc+IC/sZpUzj0=; b=hR5rNLbW61xFjcyXR+Utrta1CvspUd6xfOEHGCpRfSa+0v/gFmbiSWUuz4St4PG76H /HOyXhQfgHKDHjHR9H9pTJMQT1EFzccsI2XguJ8AxQLteIADgnY09BhN95iIb+sDE9v0 SDuwLiRgqs7a0LW705eZgZzAmwv9YmKj99j1yGw0aPdukN3ng/etaLaD1+PnwhrGVjei rGvqFAHKTxZY/WgN6YHj8nn54oCdusehqW7H4bbBhVDswEyhMHAc08n5XD8GMXBoaWJ2 2xBBDty9Domfba90rFVQzz7eCX5ynV0iIRKhBKNIH+8IBNOWGAor/UCn3YlRUouGqA+/ 0i4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z3czZC8dDRYylBILYvSVrhTohokGoHlc+IC/sZpUzj0=; b=YKUKn6y+hiEXSYqcxjn2mGsp6EqPl4dywpZbZ5crsvzjko5fbSzrLf/MF6zu7EbeLN Lo2DAZXS/aloGffPEDwnpY0WjA4BA3/jtHdBtabWIXKpTLy8MmRhY6WJwKwGcF40W4sN N+j8V7upI9O7K7fBhjavNs6rpSPeZE9k/WvIv8LyX7qWsS+/TY+ReVZpytb6bmznic6g tt7CFKLUKjQH2ccgbYPUaVs72bfqro+9uEohBMvqt7EP35BflpXZEsgwyUd37JrmkHdw MZBhYtEjctHmYDVYfo672yYpuWuqZ7AJLtezDRWFQNYAOTwSZa+2J7Rr+vQNw8a/g9+c R6Vg== X-Gm-Message-State: ALoCoQkvryE30i1qC0mye7leKmjPhjEBDG5xJH00ROXC03WD0sJBQC1phL/M+etIIsAwcIA/qdwa MIME-Version: 1.0 X-Received: by 10.140.221.145 with SMTP id r139mr10679469qhb.94.1447976570782; Thu, 19 Nov 2015 15:42:50 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Thu, 19 Nov 2015 15:42:50 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <3514235.7QMnNNElsE@ralph.baldwin.cx> References: <564E0322.8050308@freebsd.org> <3514235.7QMnNNElsE@ralph.baldwin.cx> Date: Thu, 19 Nov 2015 16:42:50 -0700 X-Google-Sender-Auth: 0EkQlZYM8k45rS0zbFViOtTM2JY Message-ID: Subject: Re: sys/modules "make clean" seems broken again From: Warner Losh To: John Baldwin Cc: FreeBSD Current , Sean Bruno Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 23:42:52 -0000 On Thu, Nov 19, 2015 at 11:12 AM, John Baldwin wrote: > On Thursday, November 19, 2015 09:13:06 AM Sean Bruno wrote: > > I thought I fixed this a year or two ago, but now a "make clean" in > > sys/modules seems to leave bus_if.h device_if.h and pci_if.h in the > > directory. > > > > Should I just add these to the clean targets? > > Blame Warner as his MFILES changes broke this. In particular, see r287263 > which turned off cleaning these up. I'm not sure what that broke that > caused it to be disabled. > > Your change is a gross hack though. > Yes. The reason I had to break it was that there were a few files named _if.c and _if.h in the tree that would get deleted when make clean was run in the modules. I'll take another run at fixing this. Sean's "fix" is a horrible hack. Warner From owner-freebsd-current@freebsd.org Fri Nov 20 01:01:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E355A33DDC for ; Fri, 20 Nov 2015 01:01:38 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7E133125B for ; Fri, 20 Nov 2015 01:01:38 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7D9CEA33DDB; Fri, 20 Nov 2015 01:01:38 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C363A33DDA for ; Fri, 20 Nov 2015 01:01:38 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 341AD1259; Fri, 20 Nov 2015 01:01:38 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: by qkas77 with SMTP id s77so32149024qka.0; Thu, 19 Nov 2015 17:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=0PLfcyjD5/L1E/s+vtGqG7K3l4TVNKUPNrXnzg+V59w=; b=WWlcV0rNB3IcKjbpb30WTOWgTSZJa9JSLI1bBiBlmGDrtmE/8FZ/4NX8W7ZF3IMd1L As42Ph7cyDiTyVVIo7GrG//aEWka1lHPbpbw72Oa+gAAhoMTIt37hHeKA3SUBaFm+XWM zuIcc2MG4UwEOsSPeykoqqkPLIqI2zSDTUdDMxmSOAIIxVjamgC9FvZ6nwJkAPLDAjWG sYP04E2iFDSy+JmJYCu2s/B1OBx/6/YuM4BNzlXHy8twOrE/orLQVKGv7f9wZ/Z34fFo HtC2M0gKJ4O6RiSSbBuuDndXdE+pOLjFyGrYNiTuHVVxNf62Al1ZvHw7rkk28/DjOsN5 agbw== X-Received: by 10.55.76.22 with SMTP id z22mr10186341qka.89.1447981297007; Thu, 19 Nov 2015 17:01:37 -0800 (PST) MIME-Version: 1.0 References: <20151111114532.000011fd@Leidinger.net> <20151119214200.000066be@Leidinger.net> In-Reply-To: <20151119214200.000066be@Leidinger.net> From: Eric Joyner Date: Fri, 20 Nov 2015 01:01:27 +0000 Message-ID: Subject: Re: This igb change makes my igb not working anymore - Re: regression in igb/clang? To: Alexander Leidinger , sbruno@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 01:01:38 -0000 Are you using IPv6? On Thu, Nov 19, 2015 at 12:42 PM Alexander Leidinger < Alexander@leidinger.net> wrote: > On Wed, 11 Nov 2015 11:45:32 +0100 > Alexander Leidinger wrote: > > > Hi, > > > > I' updated a system with -current as of r287323 (end August) to > > r290633 (yesterday). > > > > Result: no network connection (not even ping) on igb. > > Ping internally (local addresses) works, anything outgoing/incoming > > doesn't. > > And this is the function which causes it: > e1000_rx_fifo_flush_82575(&adapter->hw); > > If I comment it out in if_igb.c, the network card works again. > > Full quote below for the PCI ID of my card in case it helps for fixing > the issue. > > Bye, > Alexander. > > > I disabled HW support (tso4, lro, rxcsum, txcsum): doesn't help. > > > > Did I miss some known defect/workaround? > > > > Anything I should test/provide besides what is below? > > > > The igb device is a: > > ---snip--- > > igb0@pci0:1:0:0: class=0x020000 card=0x34e28086 chip=0x10a78086 > > rev=0x02 hdr=0x00 ---snip--- > > > > My src.conf: > > ---snip--- > > WITH_IDEA=yes > > WITHOUT_PROFILE=yes > > CFLAGS+=-DFTP_COMBINE_CWDS > > MALLOC_PRODUCTION=yes > > LOADER_FIREWIRE_SUPPORT=yes > > #WITH_FAST_DEPEND=yes > > ---snip--- > > > > My buildworld related config in make.conf: > > ---snip--- > > CFLAGS+= -O2 -pipe > > COPTFLAGS= -O2 -pipe > > #CPUTYPE?=core2 > > #WITH_CCACHE_BUILD=yes > > #.if (!empty(.CURDIR:M/usr/src*) > > || !empty(.CURDIR:M/usr/obj*)|| !empty(.CURDIR:M/space/system/usr_obj*)) > > #.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc) > > #CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} > > #CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} #.endif > > #.endif > > ---snip--- > > > > The commented out parts were active initially, but then I commented > > them out, cleaned out /usr/obj (rm -r) and rebuild/reinstall to make > > sure it's not due to them (CPUTYPE commented out due to the fact that > > there's a new compiler, and I use zsh and there was a commit talking > > about zsh and CPUTYPE workaround). > > > > Bye, > > Alexander. > > > > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0xC773696B3BAC17DC > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0xC773696B3BAC17DC > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Fri Nov 20 06:23:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 758E5A328EA for ; Fri, 20 Nov 2015 06:23:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4D85C1EA9 for ; Fri, 20 Nov 2015 06:23:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 4A449A328E9; Fri, 20 Nov 2015 06:23:00 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48E3CA328E7 for ; Fri, 20 Nov 2015 06:23:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C10071EA7; Fri, 20 Nov 2015 06:22:59 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p57BB9CE1.dip0.t-ipconnect.de [87.187.156.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 255B183E493; Fri, 20 Nov 2015 07:21:57 +0100 (CET) Received: from [192.168.1.22] (unknown [192.168.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id 0B5DE2097; Fri, 20 Nov 2015 07:21:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1448000514; bh=NWo5y3cnllWSK9j0OiARgp1uS53gsUuHfL30CNt5yKo=; h=From:To:Date:In-Reply-To:References:Subject; b=nAdJC8iiZjf/kIf4xexjz1hAWYAhVQ2dm4N+k8zBcqOUwfoC3tb63Sz0Yl9wG198s eN8cZeA23cHAqMThNLUZzWbBY8HtykBNxvTGQeE2zJBV56w/7+nPvlpiwuxcElZDkd Ct95Zu67DIVgx/qYGF0o1vux5hgun+Fd2dFGyAJPsvpFtN5UMuWw8QDvz6njRwYmEs LyzCFyQGBZURNY9rMPt41eWZe4F3STcogCgSsFft66/Jt+DANltswGC0iBYZDL+Blj UNzQI0KliJjWRptqvoLg9sqXDX0MrcMpVZ0ZvwHpOkbdc5p6v6SE2I7x0M0ZnDTn/O IYvyUMWJDccJA== From: Alexander Leidinger To: Eric Joyner , , Date: Fri, 20 Nov 2015 07:21:55 +0100 Message-ID: <151238e6bb8.27da.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> In-Reply-To: References: <20151111114532.000011fd@Leidinger.net> <20151119214200.000066be@Leidinger.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.14 (build: 22000040) Subject: Re: This igb change makes my igb not working anymore - Re: regression in igb/clang? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 255B183E493.ACC43 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1448605321.98562@ZlYAUQxpozDSy5pPwSbJtQ X-EBL-Spam-Status: No X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 06:23:00 -0000 Dual stack. Ping was on ipv4, no answer. Without the line I get the answer. I have not tried a ping6. -- Send from a mobile device, please forgive brevity and misspelling. Gesendet mit AquaMail fr Android http://www.aqua-mail.com Am 20. November 2015 02:07:11 schrieb Eric Joyner : > Are you using IPv6? > > On Thu, Nov 19, 2015 at 12:42 PM Alexander Leidinger < > Alexander@leidinger.net> wrote: > >> On Wed, 11 Nov 2015 11:45:32 +0100 >> Alexander Leidinger wrote: >> >> > Hi, >> > >> > I' updated a system with -current as of r287323 (end August) to >> > r290633 (yesterday). >> > >> > Result: no network connection (not even ping) on igb. >> > Ping internally (local addresses) works, anything outgoing/incoming >> > doesn't. >> >> And this is the function which causes it: >> e1000_rx_fifo_flush_82575(&adapter->hw); >> >> If I comment it out in if_igb.c, the network card works again. >> >> Full quote below for the PCI ID of my card in case it helps for fixing >> the issue. >> >> Bye, >> Alexander. >> >> > I disabled HW support (tso4, lro, rxcsum, txcsum): doesn't help. >> > >> > Did I miss some known defect/workaround? >> > >> > Anything I should test/provide besides what is below? >> > >> > The igb device is a: >> > ---snip--- >> > igb0@pci0:1:0:0: class=0x020000 card=0x34e28086 chip=0x10a78086 >> > rev=0x02 hdr=0x00 ---snip--- >> > >> > My src.conf: >> > ---snip--- >> > WITH_IDEA=yes >> > WITHOUT_PROFILE=yes >> > CFLAGS+=-DFTP_COMBINE_CWDS >> > MALLOC_PRODUCTION=yes >> > LOADER_FIREWIRE_SUPPORT=yes >> > #WITH_FAST_DEPEND=yes >> > ---snip--- >> > >> > My buildworld related config in make.conf: >> > ---snip--- >> > CFLAGS+= -O2 -pipe >> > COPTFLAGS= -O2 -pipe >> > #CPUTYPE?=core2 >> > #WITH_CCACHE_BUILD=yes >> > #.if (!empty(.CURDIR:M/usr/src*) >> > || !empty(.CURDIR:M/usr/obj*)|| !empty(.CURDIR:M/space/system/usr_obj*)) >> > #.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc) >> > #CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} >> > #CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} #.endif >> > #.endif >> > ---snip--- >> > >> > The commented out parts were active initially, but then I commented >> > them out, cleaned out /usr/obj (rm -r) and rebuild/reinstall to make >> > sure it's not due to them (CPUTYPE commented out due to the fact that >> > there's a new compiler, and I use zsh and there was a commit talking >> > about zsh and CPUTYPE workaround). >> > >> > Bye, >> > Alexander. >> > >> >> >> -- >> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0xC773696B3BAC17DC >> http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0xC773696B3BAC17DC >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> From owner-freebsd-current@freebsd.org Fri Nov 20 08:06:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0C71A33F1D for ; Fri, 20 Nov 2015 08:06:05 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CAFC11D9 for ; Fri, 20 Nov 2015 08:06:05 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by wmvv187 with SMTP id v187so60278794wmv.1 for ; Fri, 20 Nov 2015 00:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=qO6x6Tpm0w9t13KXTZ5CC36kp58lF3YECLO8QfUn8OE=; b=HyNg+V6Kj0akLU4/c05GtoNyKiDc7dx+laR4BXtp+Ti3HdKoc2V9b9BDeKAUB3nkXQ MSTEDjU/0L48Q24GuljyM1oP1dSwnX5lAzKw0/M7foNmURpv5tw+nezG09hHscq5wXL0 aCD0gg7mWO/8EYnmq2MMA3LlUBP1/hd8RxLIHxt3Sibj7GEsAEdbZBtwFRj7VZ8FRAcI OdYCott1B1dGJSRvCp+Zrf27JVEN4sPp4PUBX28Km+xRaJDwlbtk5SBgeW10Uqsv0fBN 3Z5gtwAPIyrVJvBARkBEcZvHiOKS291tAA1K2xAO1QBtpIwQoQ8Kw4D0Dv9h9c0uE1jv BBcw== X-Received: by 10.194.75.202 with SMTP id e10mr14674437wjw.160.1448006763576; Fri, 20 Nov 2015 00:06:03 -0800 (PST) Received: from laptop.minsk.domain (minsk.nivalnetwork.com. [86.57.144.74]) by smtp.gmail.com with ESMTPSA id t5sm1587475wmt.1.2015.11.20.00.06.02 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 00:06:02 -0800 (PST) Date: Fri, 20 Nov 2015 11:05:56 +0300 From: "Sergey V. Dyatko" To: Subject: /bin/ls formatting broken for non-C(?) locales Message-ID: <20151120110556.6e20a71f@laptop.minsk.domain> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 08:06:05 -0000 Hi, subj. http://i.imgur.com/F9QO29l.png it is on head@r290573: WTR: env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=ru_RU.UTF-8 ls -la /usr/ports/databases/ env LC_ALL=C ls -la /usr/ports/databases/ works fine also on old stable/10 (r286868) as I can see 'month' field length 3 symbols -- wbr, tiger From owner-freebsd-current@freebsd.org Fri Nov 20 10:42:58 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F37DA33CBB for ; Fri, 20 Nov 2015 10:42:58 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BE641C40 for ; Fri, 20 Nov 2015 10:42:58 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmdw130 with SMTP id w130so14365311wmd.0 for ; Fri, 20 Nov 2015 02:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=lWOajhDfS2Ir+2tFljo+Srktev/SQCTUOyFdEzw/Y1E=; b=xVS/+wfciodwGXCYhfJUVjOdHASm7MxfzCCKYTksKyh8g4dfiOaa40M70ekBcEEn/S BN75izxOV8/y/qeEP6GYs1kokPCwi7tw1cAr/V7rYvXGZcfR4MyetGiFpKY5uj3yMt6j sV+7NGv5abcFtlRK81BCYi4bLIhDUs1u5Ls0wotyvzZJQhaj0/5sZf+6NWwWjwacoBQD c0ePN9SJh9klvhh4zDe/mUQmVYT3WZwIM7ZT6wjT28ZSA4e+Wk76u+wtPaMtGlOJWSwg WcjrkjYG5WPxENJJh9E7Auiz6neYPad1NTFamNP/hbkpKVOCXESfGsUzy4kDsrll4hVm IkQw== X-Received: by 10.28.176.70 with SMTP id z67mr1633970wme.5.1448016176386; Fri, 20 Nov 2015 02:42:56 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id b84sm2151819wmh.15.2015.11.20.02.42.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 02:42:55 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 20 Nov 2015 11:42:53 +0100 From: Baptiste Daroussin To: "Sergey V. Dyatko" Cc: freebsd-current@freebsd.org Subject: Re: /bin/ls formatting broken for non-C(?) locales Message-ID: <20151120104253.GA21071@ivaldir.etoilebsd.net> References: <20151120110556.6e20a71f@laptop.minsk.domain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20151120110556.6e20a71f@laptop.minsk.domain> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 10:42:58 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote: > Hi, >=20 > subj. http://i.imgur.com/F9QO29l.png > it is on head@r290573: > WTR: > env LC_ALL=3Duk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=3Dru_= RU.UTF-8 > ls -la /usr/ports/databases/ >=20 > env LC_ALL=3DC ls -la /usr/ports/databases/ works fine > also on old stable/10 (r286868) as I can see 'month' field length 3 symb= ols=20 >=20 Thanks for reporting, I can reproduce the issue with some other locales. The thing is there seems to be no standard for abbreviated length. Formerly we = had a 3 character lenght for abbreviated month. We now use CLDR which seems to follow the abbreviated rules from IBM: "Each string must be of equal length and contain 5 characters or less" There are 2 possible fixes: either always pad those in the locale definition which seems wrong or modify ls so that it by itself pads properly. Neither posix nor ISO-14652 defines the length of the abbreviated form padding in the locales themself would be wrong so I do propose to pad in th= e ls command. And padding with 5 characters. Best regards, Bapt --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZO+SwACgkQ8kTtMUmk6EyDdACffb0iUN7MzdUYaPLp/fnV7wt6 1RgAoLMOy2DucpqAOZ0T9gR4s4OX8zKf =XeX9 -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-current@freebsd.org Fri Nov 20 11:02:17 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0A22A330A7 for ; Fri, 20 Nov 2015 11:02:17 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33C7B145A for ; Fri, 20 Nov 2015 11:02:17 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmec201 with SMTP id c201so16204996wme.1 for ; Fri, 20 Nov 2015 03:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=iCJwZTM7LtB9hv5T9+JXxxjFlkeSvcyvO+eUm/50mv4=; b=yyc+jMWZ/w7vt9XR2g71ssGMIB7CoR2hIUR4hlI3DcIQyVZZMFT8JCQk6n6cE1KM5k WyVGvqta8kXcsVxLV6RlP5fGI/bsr/OvBEOYxLfwbXm4Km6FO0v+6D3+kYDyXXXTd+YT B0cI/8dg4gpX/FzCtp53ezPfvRAXdJ0pvxzuGQR9uvLBrRm2xFKgTCjTjwJuLES+FRLD zYGIP8tiI8MxtzKdP3WKI64EWkAtkXIe4M1AfQYh14weYZzOtZ7zx3LpFox4pHA07/KH jLA4yb0V/epoKjPT+2BqUPrYA/gnAGZG4sEfE0R9PQN6tDxHO+iK92q1AvfoQ5FOjCEx GNHg== X-Received: by 10.194.243.170 with SMTP id wz10mr15855925wjc.80.1448017335525; Fri, 20 Nov 2015 03:02:15 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id u134sm2249877wmd.0.2015.11.20.03.02.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 03:02:14 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 20 Nov 2015 12:02:13 +0100 From: Baptiste Daroussin To: "Sergey V. Dyatko" Cc: freebsd-current@freebsd.org Subject: Re: /bin/ls formatting broken for non-C(?) locales Message-ID: <20151120110212.GB21071@ivaldir.etoilebsd.net> References: <20151120110556.6e20a71f@laptop.minsk.domain> <20151120104253.GA21071@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline In-Reply-To: <20151120104253.GA21071@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 11:02:17 -0000 --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 20, 2015 at 11:42:53AM +0100, Baptiste Daroussin wrote: > On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote: > > Hi, > >=20 > > subj. http://i.imgur.com/F9QO29l.png > > it is on head@r290573: > > WTR: > > env LC_ALL=3Duk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=3Dr= u_RU.UTF-8 > > ls -la /usr/ports/databases/ > >=20 > > env LC_ALL=3DC ls -la /usr/ports/databases/ works fine > > also on old stable/10 (r286868) as I can see 'month' field length 3 sy= mbols=20 > >=20 > Thanks for reporting, I can reproduce the issue with some other locales. = The > thing is there seems to be no standard for abbreviated length. Formerly w= e had a > 3 character lenght for abbreviated month. >=20 > We now use CLDR which seems to follow the abbreviated rules from IBM: > "Each string must be of equal length and contain 5 characters or less" >=20 > There are 2 possible fixes: either always pad those in the locale definit= ion > which seems wrong or modify ls so that it by itself pads properly. >=20 > Neither posix nor ISO-14652 defines the length of the abbreviated form >=20 > padding in the locales themself would be wrong so I do propose to pad in = the ls > command. And padding with 5 characters. >=20 > Best regards, > Bapt For the record glibc/linux had the same problem: https://sourceware.org/bugzilla/show_bug.cgi?id=3D9859 "fixed" in coreutils (gnu ls) the way I propose to do for us http://git.savannah.gnu.org/gitweb/?p=3Dcoreutils.git;a=3Dcommit;h=3D612b64= 7dd16d5abc03b295abe42d8b4a0fe660f7 Best regards, Bapt --NDin8bjvE/0mNLFQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZO/bQACgkQ8kTtMUmk6EwBzQCgqKq9Vgcao47r3hMs2/Ud1vsT hdMAnRRdTyvlDDE1RBaU6PFw3qtVKmTa =Dhfh -----END PGP SIGNATURE----- --NDin8bjvE/0mNLFQ-- From owner-freebsd-current@freebsd.org Fri Nov 20 12:23:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02394A3269F for ; Fri, 20 Nov 2015 12:23:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95D591EE7; Fri, 20 Nov 2015 12:23:55 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 790843592E1; Fri, 20 Nov 2015 13:23:52 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 661A328494; Fri, 20 Nov 2015 13:23:52 +0100 (CET) Date: Fri, 20 Nov 2015 13:23:52 +0100 From: Jilles Tjoelker To: Baptiste Daroussin Cc: "Sergey V. Dyatko" , freebsd-current@freebsd.org Subject: Re: /bin/ls formatting broken for non-C(?) locales Message-ID: <20151120122352.GA5751@stack.nl> References: <20151120110556.6e20a71f@laptop.minsk.domain> <20151120104253.GA21071@ivaldir.etoilebsd.net> <20151120110212.GB21071@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151120110212.GB21071@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 12:23:56 -0000 On Fri, Nov 20, 2015 at 12:02:13PM +0100, Baptiste Daroussin wrote: > On Fri, Nov 20, 2015 at 11:42:53AM +0100, Baptiste Daroussin wrote: > > On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote: > > > subj. http://i.imgur.com/F9QO29l.png > > > it is on head@r290573: > > > WTR: > > > env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=ru_RU.UTF-8 > > > ls -la /usr/ports/databases/ > > > env LC_ALL=C ls -la /usr/ports/databases/ works fine > > > also on old stable/10 (r286868) as I can see 'month' field length 3 symbols > > Thanks for reporting, I can reproduce the issue with some other > > locales. The thing is there seems to be no standard for abbreviated > > length. Formerly we had a 3 character lenght for abbreviated month. > > We now use CLDR which seems to follow the abbreviated rules from IBM: > > "Each string must be of equal length and contain 5 characters or less" > > There are 2 possible fixes: either always pad those in the locale > > definition which seems wrong or modify ls so that it by itself pads > > properly. > > Neither posix nor ISO-14652 defines the length of the abbreviated form > > padding in the locales themself would be wrong so I do propose to > > pad in the ls command. And padding with 5 characters. > For the record glibc/linux had the same problem: > https://sourceware.org/bugzilla/show_bug.cgi?id=9859 > "fixed" in coreutils (gnu ls) the way I propose to do for us > http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=612b647dd16d5abc03b295abe42d8b4a0fe660f7 Coreutils fixed it slightly better: it calculates the maximum width of the abbreviated month names and pads to that (with a maximum of 5). In particular, this ensures that the output does not change for locales that have 3-character abbreviations, such as the POSIX locale. I think this is valuable. They also keep the list of month names from this calculation and they say this speeds up ls noticeably compared to having strftime() expand %b for every file. -- Jilles Tjoelker From owner-freebsd-current@freebsd.org Fri Nov 20 12:25:13 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEA40A32703 for ; Fri, 20 Nov 2015 12:25:13 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F8DC1032; Fri, 20 Nov 2015 12:25:12 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id tAKCPAI9029970 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2015 12:25:11 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: libXO-ification - tangent on JSON choices From: David Chisnall In-Reply-To: <20151116210410.7FD2D19E9@freefall.freebsd.org> Date: Fri, 20 Nov 2015 12:25:04 +0000 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151116210410.7FD2D19E9@freefall.freebsd.org> To: Garance A Drosehn X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 12:25:13 -0000 On 16 Nov 2015, at 21:04, Garance A Drosehn wrote: >=20 > First let me say that I wish I had more time to contribute to the = project, > but I seem to be caught in variety of long drawn-out hassles in = real-life. > Otherwise I would already know the answer to this question: >=20 > Is there some specification for what JSON is created by the various = FBSD > utilities? I did not see any discussion of that in the earlier = threads > on this. I don't mean "what is syntatically correct JSON?", I mean = some > kind of guidelines of what property-names would be used across = commands, > and what values should be for those properties. There is not, currently. Until 11.0 is branched, it should be = considered to be in flux, but after that then we are going to provide = backwards compatibility (i.e. you can add fields to the JSON, but you = can=E2=80=99t remove them). Before this point, it would be good to have = some consensus of on what properties should be common and what each = should be providing, and regression tests for the JSON (the XML is = isomorphic to the JSON, so probably doesn=E2=80=99t need testing = separately). If you want to provide a first draft of some recommendations, they would = be very welcome, David From owner-freebsd-current@freebsd.org Fri Nov 20 13:54:13 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F91AA339A7 for ; Fri, 20 Nov 2015 13:54:13 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C35451D49; Fri, 20 Nov 2015 13:54:12 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.166] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id 6F7A6CA3E2; Fri, 20 Nov 2015 15:54:05 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: DDB patches From: Dan Partelly In-Reply-To: Date: Fri, 20 Nov 2015 15:54:05 +0200 Cc: Adrian Chadd , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <8FCD1760-FD2C-4C08-837A-A2ADD2581FC3@rdsor.ro> References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> To: Pedro Giffuni X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 13:54:13 -0000 Hi Pedro, I think you confuse blackmailing with something much simpler and = pragmatic.=20 One needs to asses how things work in your project for real before = investing=20 too much time.=20 Adrian was contemplating the fact that none writes code, so I had some = code at the hand with with I can see how things work around here. You want it, good.=20= You don't want it, its also good. You want to trash it=E2=80=A6 also = good.=20 Its all the same to me. This process is aimed to give me an idea , if = your workflow=20 works for me. =20 =20 > you discuss your idea and try to get some consensus in the = lists/IRC/conferences. I am not particularly interested in promoting ideas and gathering = consensus. I am not a=20 politician. I happen to believe that translating some utilities from the = base to libraries=20 is a very valuable addition to the project. Id rather spend time with = my familty and walk around the city in nature with my GSD dog than embarking on some twisted = political campaign.=20 > We are particularly NOT interested in code where the original = contributor will walk > away as soon as he/she receives criticism or has plans that do not = match ours. Undeerstandable.=20 >=20 > Libxo already went through this process. >=20 >> Libxo already went through this process. It did, aint it ? And I seen what kind of =E2=80=9Cconsensus=E2=80=9D = the xoification of base=20 caused. Apparently, adopted for no better reason than =E2=80=9Csomeone = wrote code=E2=80=9D . > If this is not your ideal workflow =E2=80=A6 fork your own BSD, a lot = of intelligent > people do just that. Not the best thing one can do=E2=80=A6 but I guess to each his own.=20 >>=20 >=20 > Wrong approach. You can=E2=80=99t really blackmail someone into taking = your changes. >=20 > Things work like this: >=20 > - You discuss your idea and try to get some consensus in the = lists/IRC/conferences. > - You *write* a specific proof of concept and get it discussed. > - You finish your prototype. > - Your work gets rejected until you get something some committer is = willing to support. > - When there are no objections and a committer feels like it, your = work gets committed, > which doesn=E2=80=99t necessarily mean it will stay. > - You are expected to maintain it. >=20 > Libxo already went through this process. >=20 > We are particularly NOT interested in code where the original = contributor will walk > away as soon as he/she receives criticism or has plans that do not = match ours. > If this is not your ideal workflow =E2=80=A6 fork your own BSD, a lot = of intelligent > people do just that. >=20 > Pedro. >=20 >>=20 >> Dan >>=20 >>=20 >>=20 >>> On 19 Nov 2015, at 11:17, Pedro Giffuni wrote: >>=20 >>>=20 >>> Hello; >>>=20 >>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly = ha scritto: >>>>=20 >>>> Hey Pedro, >>>>=20 >>>> some times ago you got some DDB patches from me in which I added = relational ops support from it. The patch was a bit clobbered,=20 >>>> but last I know you cleaned it up and put it somewhere on = freebsd.org (prolly your page) up for review.=20 >>>>=20 >>>=20 >>> It=E2=80=99s here: >>> https://people.freebsd.org/~pfg/patches/ddb.patch >>>=20 >>> I haven=E2=80=99t tested it though. >>>=20 >>>> Could you or Adrian review the patch set , and if it is OK = potentially proceed with a commit ? Or if it is not ok for a commit , = please advice on a follow up.=20 >>>>=20 >>>=20 >>> I am having hardware issues so I won=E2=80=99t be able to do much in = a while. >>> Perhaps you should review it and submit it as a PR. >>>=20 >>> Pedro. >>>=20 >>=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Nov 20 14:01:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D3D6A33AFD for ; Fri, 20 Nov 2015 14:01:44 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB3DB1036; Fri, 20 Nov 2015 14:01:43 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 065E66DF91B; Fri, 20 Nov 2015 15:01:40 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id tAKE1d3O028012; Fri, 20 Nov 2015 15:01:39 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id tAKE1btj024656; Fri, 20 Nov 2015 15:01:37 +0100 (CET) (envelope-from lars) Date: Fri, 20 Nov 2015 15:01:37 +0100 From: Lars Engels To: Ed Maste Cc: Luigi Rizzo , Allan Jude , Garrett Cooper , freebsd-current Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? Message-ID: <20151120140137.GG27296@e-new.0x20.net> Mail-Followup-To: Lars Engels , Ed Maste , Luigi Rizzo , Allan Jude , Garrett Cooper , freebsd-current References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C964.2020405@freebsd.org> <2DF061E9-2541-4B10-9744-C49C515FF672@gmail.com> <5648CBA1.9010300@freebsd.org> <20151118193252.GE27296@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6L4qsSZ7qhfB8xIa" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 14:01:44 -0000 --6L4qsSZ7qhfB8xIa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 18, 2015 at 04:56:21PM -0500, Ed Maste wrote: > On 18 November 2015 at 15:46, Luigi Rizzo wrote: > > i was going to suggest doing ldd on the binaries or a grep on the > > Makefile but the latter returns a surprisingly low number > > of matches. >=20 > That's because it's usually added via LIBADD=3Dxo. >=20 > My grep turns up these: bin/df, bin/ls, bin/ps, sbin/savecore, > usr.bin/iscsictl, usr.bin/netstat, usr.bin/procstat, usr.bin/w, > usr.bin/wc, usr.bin/xo Thanks! Unfortenately only a part of them mention --libxo in its manpage. --6L4qsSZ7qhfB8xIa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJWTyfBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tCl4IAILqQjDmhZmkPSBDzKvq+pzr YUoMRelX5w7aE6+a/bBjX2a4DxhT/BmndRN/yy2hBX3wNVfG9z+IcfG3SuAeJsXp 5I6tu6pvGMHORgwr7uNpH21z3EVesEjdMYrrPHY9CYHnDrhNIAGG8azphXvfHJrp 9dTPtqOTa/+qOgMY+Q3kul3Wd3+NXkq0UmY33wb9v0+ahYmO/OWc3crsHsmBHhtb ESelfnbC7hBDxWMknB7QGBlZ4McsQIDUAinhNHZ5ziRWnNaqh/iCiJ4pkvx184l0 Zs+Aqlz979Y58rWTfvk74DrcGNXEmjW6Y32edUG7xYxXfdZWnDjWu4hyzoPeMMg= =86FZ -----END PGP SIGNATURE----- --6L4qsSZ7qhfB8xIa-- From owner-freebsd-current@freebsd.org Fri Nov 20 15:58:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1B2EA31298 for ; Fri, 20 Nov 2015 15:58:36 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 719211316 for ; Fri, 20 Nov 2015 15:58:36 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1448034989; bh=UdhkwkydGRkqc03nR/HzORF3xSRlPjP8+3gOnRY+bl8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=Lk5fq75YOntAe/rA8SUVzLp+kcgT8+UnaAg5Z+Yq0fdbmH0CsZA8UlBwVKAWpXVfplkZrO92kSJn6pcP8sHHoaOGrgTtA6QNT2WRKMsLYOxe1Zf36luh4HfoOEtzmeY6CkxAsFQkQoeEDgFZEttJIctZfVal2FQuRd27Qtt2pBiI2hoI9UpR6cxGw0UzWBq+86pEklrQuEmgHGgUjOwcgw+J1WL+iwD3Eezp56ojTEyBWSYnw7lvMhFFmZ1Qk5MPxN5OlfZEhaaGE9HspZqNaXiEJiraMpIVoQMBEJpkOSXPugRlbPq8DZ0YY5NLhAdCl+f1bVepvj1VQBjoYdJQcg== Received: from [98.139.170.180] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2015 15:56:29 -0000 Received: from [98.139.213.9] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2015 15:56:29 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 20 Nov 2015 15:56:29 -0000 X-Yahoo-Newman-Id: 663113.1006.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: AlTJX6EVM1krBqevFjIr.vCjwf5w95ZfdhD5FjqzhwclAv8 FKcfpuBq8yT2nWOGEAvFiqlsEgZ4YSvThCLMWCFxsORJW_5WRw1U29zGUBwN bVesE3YxRyHXOLzp9E2FGY0IUWFiZABbgJw4EE3Dw1WUfPWyhBH.uyrY2j5B rRW3pvug9NxbJF20MvY5k6XoTJN30K6iE.nihQwxl3BRFV2H_eM2LC8P0KBR b1eg6SLUhUECUj6iEBb7xvze5Pt1roYd.NxlRyJTzqTFWPz8SFZNOWL4FP_1 J9SGXM_R0mQAC9pfx2J.I9CqL.NtZzO5.jz5g9N6sAf8F4DCizDZaFXotOQy 3e_N6gdBPp0PT2ATkAZHyQiv2Ozl8hIxiUho6IusHz.xnRTIwwKNTE97zC.F iypeUGO23.r29d_H657nTz__Vu5UmjbCpevKO4H1bhBTOj3mV07zB6R8k5pT 2DJnZM5yladtqJ8.9P2LxybUk97ci_fThzm6afGsl5B3E3X1UMaOJ_5N8iJ6 q04FGeHAbAYDt2kczp5wfZ0BMOMJsef.n X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: DDB patches To: Dan Partelly References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <8FCD1760-FD2C-4C08-837A-A2ADD2581FC3@rdsor.ro> Cc: Adrian Chadd , freebsd-current From: Pedro Giffuni Message-ID: <564F42AC.4050404@FreeBSD.org> Date: Fri, 20 Nov 2015 10:56:28 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8FCD1760-FD2C-4C08-837A-A2ADD2581FC3@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 15:58:36 -0000 On 11/20/15 08:54, Dan Partelly wrote: > Hi Pedro, > > I think you confuse blackmailing with something much simpler and pragmatic. > One needs to asses how things work in your project for real before investing > too much time. > A template for blackmailing is usually in the form: "I will do this (usually involving saving the world and/or your evidently miserable life) but first you will have to do this (unrelated) thing to see that you are worthy." > Adrian was contemplating the fact that none writes code, so I had some code at the > hand with with I can see how things work around here. You want it, good. > You don't want it, its also good. I don't know about the (new) libxo discussion, but the ddb thing is unrelated to such discussion, and when I first looked at it it was not in good shape. You want to trash it… also good. > Its all the same to me. This process is aimed to give me an idea , if your workflow > works for me. > In my experience it is always easier for new contributors to adapt to the community than to re-shape it. You can try.. but there will likely be pain. > >> you discuss your idea and try to get some consensus in the lists/IRC/conferences. > > I am not particularly interested in promoting ideas and gathering consensus. I am not a > politician. I happen to believe that translating some utilities from the base to libraries > is a very valuable addition to the project. Id rather spend time with my familty and walk > around the city in nature with my GSD dog than embarking on some twisted political > campaign. > >> We are particularly NOT interested in code where the original contributor will walk >> away as soon as he/she receives criticism or has plans that do not match ours. > > Undeerstandable. > >> >> Libxo already went through this process. >> > > >>> Libxo already went through this process. > > It did, aint it ? And I seen what kind of “consensus” the xoification of base > caused. Apparently, adopted for no better reason than “someone wrote code” . > There was a GSoC that did a different implementation but libxo was specifically made for FreeBSD after a long discussion. That doesn't mean everyone is happy with it or that it is perfect but it went in through an open process. The process, call it politics or consensus or community building, is important in any opensource effort that aims to be sustainable. These days github makes it pretty easy for anyone to play with their new ideas to the limit. When I mean you can fork your own BSD, I mean it. You can experiment on your own without waiting on us to decide: eventually we may decide to bring it in ... Pedro. From owner-freebsd-current@freebsd.org Fri Nov 20 16:28:07 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCFACA31AAA for ; Fri, 20 Nov 2015 16:28:06 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C876317E5; Fri, 20 Nov 2015 16:28:05 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.101] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 335EA23286; Fri, 20 Nov 2015 18:28:04 +0200 (EET) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: DDB patches From: Dan Partelly In-Reply-To: <564F42AC.4050404@FreeBSD.org> Date: Fri, 20 Nov 2015 18:28:03 +0200 Cc: Adrian Chadd , freebsd-current Message-Id: <3E6A6B32-1339-4466-81BA-4A74377D062C@rdsor.ro> References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <8FCD1760-FD2C-4C08-837A-A2ADD2581FC3@rdsor.ro> <564F42AC.4050404@FreeBSD.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 16:28:07 -0000 > A template for blackmailing is usually in the form: >=20 > "I will do this (usually involving saving the world and/or your > evidently miserable life) but first you will have to do this > (unrelated) thing to see that you are worthy.=E2=80=9D It is interesting how much you dwell on this. I just told you what = reasons=20 I have to take this path, and that it doesn't include the intent to = blackmail=20 anyone. I want to experience the process with already existing code,=20 before contemplating more in the future. Is this: 1. So hard to understand ? 2. Wrong in the eyes of god, or something ? Leaving aside saving the world, and / or miserable lives , damsels in = distress and other=20 fantasies, you will just have to accept what I said, instead of = insisting you know better what is in my head.=20 > . You can try.. but there will likely > be pain. You see this from a very interesting angle. I am not trying to change = you or your community.=20 No sane person would do that, knowing how powerful social forces are. = Do you really think I would embark on such a fool=E2=80=99s errand ? I told you, I like to = spend time with walking with my dog :P=20 What I am trying to determine where to position myself.=20 > That doesn't mean everyone is happy with it or that it is perfect > but it went in through an open process.=20 Ill take your word for it. But in my opinion the result of this open = process is that: 1. A distasteful solution was adopted into the base.=20 2. Still people think that it was adopted only because someone had the = code (Juniper) 3. While others seems to think Junpier ppl pushed it (Im not saying they = did,=20 but you can certainly push something pressing the correct political = buttons. > You can experiment on your own without waiting on us to decide: > eventually we may decide to bring it in =E2=80=A6 You tell me nothing new, but thank you. > On 20 Nov 2015, at 17:56, Pedro Giffuni wrote: >=20 >=20 >=20 > On 11/20/15 08:54, Dan Partelly wrote: >> Hi Pedro, >>=20 >> I think you confuse blackmailing with something much simpler and = pragmatic. >> One needs to asses how things work in your project for real before = investing >> too much time. >>=20 >=20 > A template for blackmailing is usually in the form: >=20 > "I will do this (usually involving saving the world and/or your > evidently miserable life) but first you will have to do this > (unrelated) thing to see that you are worthy." >=20 >> Adrian was contemplating the fact that none writes code, so I had = some code at the >> hand with with I can see how things work around here. You want it, = good. >> You don't want it, its also good. >=20 > I don't know about the (new) libxo discussion, but the ddb thing is = unrelated to such discussion, and when I first looked at it it was > not in good shape. >=20 > You want to trash it=E2=80=A6 also good. >> Its all the same to me. This process is aimed to give me an idea , = if your workflow >> works for me. >>=20 >=20 > In my experience it is always easier for new contributors to adapt to > the community than to re-shape it. You can try.. but there will likely > be pain. >=20 >=20 >>=20 >>> you discuss your idea and try to get some consensus in the = lists/IRC/conferences. >>=20 >> I am not particularly interested in promoting ideas and gathering = consensus. I am not a >> politician. I happen to believe that translating some utilities from = the base to libraries >> is a very valuable addition to the project. Id rather spend time = with my familty and walk >> around the city in nature with my GSD dog than embarking on some = twisted political >> campaign. >>=20 >>> We are particularly NOT interested in code where the original = contributor will walk >>> away as soon as he/she receives criticism or has plans that do not = match ours. >>=20 >> Undeerstandable. >>=20 >>>=20 >>> Libxo already went through this process. >>>=20 >>=20 >>=20 >>>> Libxo already went through this process. >>=20 >> It did, aint it ? And I seen what kind of =E2=80=9Cconsensus=E2=80=9D = the xoification of base >> caused. Apparently, adopted for no better reason than =E2=80=9Csomeone = wrote code=E2=80=9D . >>=20 >=20 >=20 > There was a GSoC that did a different implementation but libxo was > specifically made for FreeBSD after a long discussion. >=20 > That doesn't mean everyone is happy with it or that it is perfect > but it went in through an open process. The process, call it politics > or consensus or community building, is important in any opensource > effort that aims to be sustainable. >=20 > These days github makes it pretty easy for anyone to play with their > new ideas to the limit. When I mean you can fork your own BSD, I > mean it. You can experiment on your own without waiting on us to = decide: > eventually we may decide to bring it in ... >=20 > Pedro. From owner-freebsd-current@freebsd.org Fri Nov 20 18:26:03 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C37AA347F4 for ; Fri, 20 Nov 2015 18:26:03 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm39-vm5.bullet.mail.bf1.yahoo.com (nm39-vm5.bullet.mail.bf1.yahoo.com [72.30.239.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 087911AD5 for ; Fri, 20 Nov 2015 18:26:02 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1448043849; bh=7/RZiGFe5Yx0hijSUerEPiK+sVocQ9J/mU5RVW6X/go=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=ChVN9OWUnJLE0/+UOdmAhV0FEHiSMvtUDbXdTN3YSY18kJgZ17+mMi2zFros/dVk5kGsEINR8QCEHMQLonTTf+OVusd0NgqPsPI1NdQaISSGHYGLKp9N3GD6H08obo5oYBcMACjdDGvVmiVRjS/q4N2eO5YxQKNEeqYpHDGV7986IDmxWes5IlaRoMUFqd+IQ6GivM3Fm6XlM02oGX0CZ6NbsMSqleySKViwzXir0puklZ5nqmnYI7A9MceNFDmFHMY+FYfUuAIFC+/ZUEEgcY31FjrRyFSCkJT7wd8aqwtltVUuIrjSYEQt1sOGhhz1mL2kHjINSwN8Xf51B0QmLw== Received: from [98.139.170.182] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2015 18:24:09 -0000 Received: from [98.139.211.196] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2015 18:24:09 -0000 Received: from [127.0.0.1] by smtp205.mail.bf1.yahoo.com with NNFMP; 20 Nov 2015 18:24:09 -0000 X-Yahoo-Newman-Id: 63694.82298.bm@smtp205.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: v51EMJgVM1kjI0Q9_oPC0cQlsF6QT.k7P0.COBzEW7yeU28 sj9ZSsWSN6mUlIDTy_P_BPzCcS.aD2feKfghHrppLuGf8Cgl2t.4oJEx1tSl NZD8buHU3w6Kdozr5k07OAr4DJo857U1PZ1cfyAC5eizh0.dM46K6QmXfu_V jx4LRggBmZFqPUKKMBweJOtPNmHkck5WRHPv_GFA_MGVMIPFEOE7tfZ5D4Wo QR9czdPTrEMtU70Kx8Rfsbue_LKWeF1bRtduFFIjUh48aRLbg5SvmNCmUryv 6DNos8rRhBPxMThptIeCDqqkTrWiRo.y.FO3cfg_ojhhuRyKn28i1mI7yMpY GHS72acCUPZvKv1R7szBdRmQWU0I1ta3qCtRgwbQMVmsQpccLDXrj7zs5nHS 4QYfrhKbhoeqpaDSAY.uSDSF9TTpoPu1_AVzJ3kzj55pIpXo4SLIJ5RWn0Gc xQkBtWp.Xx1OMawYHTKrqvVScxogYFgRQQ0J0Sntwn2M79L94CtfBjO0PbgT .2YAJSY67cweTKM.M8oZ_6c6V7x.S7bro X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: DDB patches To: Dan Partelly References: <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <8FCD1760-FD2C-4C08-837A-A2ADD2581FC3@rdsor.ro> <564F42AC.4050404@FreeBSD.org> <3E6A6B32-1339-4466-81BA-4A74377D062C@rdsor.ro> Cc: Adrian Chadd , freebsd-current From: Pedro Giffuni Organization: FreeBSD Project Message-ID: <564F6546.3070100@FreeBSD.org> Date: Fri, 20 Nov 2015 13:24:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <3E6A6B32-1339-4466-81BA-4A74377D062C@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 18:26:03 -0000 On 11/20/2015 11:28 AM, Dan Partelly wrote: >> A template for blackmailing is usually in the form: >> >> "I will do this (usually involving saving the world and/or your >> evidently miserable life) but first you will have to do this >> (unrelated) thing to see that you are worthy.” > > It is interesting how much you dwell on this. Ugh ... yeah ... I am wondering exactly how I got into this. > I just told you what reasons > I have to take this path, and that it doesn't include the intent to > blackmail > anyone. I want to experience the process with already existing code, > before contemplating more in the future. And that's fine with me ... let's leave it at that. Have fun, that's what FreeBSD is about, Pedro. From owner-freebsd-current@freebsd.org Fri Nov 20 22:41:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72110A34C23 for ; Fri, 20 Nov 2015 22:41:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5EAE114CE for ; Fri, 20 Nov 2015 22:41:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5B682A34C21; Fri, 20 Nov 2015 22:41:11 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AE0AA34C20; Fri, 20 Nov 2015 22:41:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 38BF514CA; Fri, 20 Nov 2015 22:41:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id tAKMf1KS086433; Fri, 20 Nov 2015 14:41:05 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201511202241.tAKMf1KS086433@gw.catspoiler.org> Date: Fri, 20 Nov 2015 14:41:01 -0800 (PST) From: Don Lewis Subject: Re: CAM Shingled Disk support patches available To: ken@FreeBSD.ORG cc: fullermd@over-yonder.net, current@freebsd.org, scsi@freebsd.org In-Reply-To: <20151119202942.GA25213@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 22:41:11 -0000 On 19 Nov, Kenneth D. Merry wrote: > On Thu, Nov 19, 2015 at 12:48:41 -0600, Matthew D. Fuller wrote: >> On Wed, Nov 18, 2015 at 12:13:09PM -0500 I heard the voice of >> Kenneth D. Merry, and lo! it spake thus: >> > >> > Testing and comments are welcome. >> >> GELI does explicit handling of each BIO type, so will need to be >> updated to pass it through (possibly in the form of inverting the >> default handling?) or it'll just EOPNOTSUPP it, whether the underlying >> layer does or not. I wouldn't be surprised if there were other geom >> layers that did similar things. >> >> Not meant to be read as some kind of "you need to"; just a comment on >> a possible [lack of] impact. > > You're correct. For GEOM classes like GELI that don't change the layout on > disk, passing the BIO_ZONE bio through would be the right thing to do. > > For those that change the layout (i.e. the lba you write on the virtual > disk doesn't match what goes down to the physical disk), like graid or partitioning or > gstripe, I think all we really need to do is just make sure they return > EOPNOTSUPP. If someone wants to modify that code to handle shingled disks, > they can certainly do that. > > Ken From owner-freebsd-current@freebsd.org Fri Nov 20 23:36:57 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 783E0A337EC; Fri, 20 Nov 2015 23:36:57 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F27B411F6; Fri, 20 Nov 2015 23:36:56 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by lffu14 with SMTP id u14so78627930lff.1; Fri, 20 Nov 2015 15:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NJtpiahb9P1+y1b0QYFrpUEFxoE9/ipyXTNuYXdRCY4=; b=Du9GDhdji3oJnNhPWXexN5kNuZaVAgETQk1H6c/+aMbA8++3L7jq7+aIFJr6by/UGn a4E8uoVTZcfQU6X0Az7NMn9OD5Sfmtr7PzIzLCsASpbp+ym7hOt7IVitmSjCCfbcR5r5 DfmAuCR66Q4Hw3Rz/wlHaCIUfXrPGK6RpECI+PtoOfcn1F8hd401Q9PjFsHDGqL2nrie L717Z6E2KiYfDW6htruYbqpomirP/nfSWsum0nzj+VZ0YL0uMPkeGgCE+JtLW6V4Djpi JaR2qb9PiMEx34GlhO+kV5SY54VxNciHVGlXK5kX67KTNnCOR2EhmvHT5hX39D0p4cET udjg== MIME-Version: 1.0 X-Received: by 10.25.1.205 with SMTP id 196mr5740504lfb.21.1448062614915; Fri, 20 Nov 2015 15:36:54 -0800 (PST) Received: by 10.112.219.9 with HTTP; Fri, 20 Nov 2015 15:36:54 -0800 (PST) In-Reply-To: <56437EE6.7080802@mu.org> References: <563EAAB8.5020702@freebsd.org> <56437EE6.7080802@mu.org> Date: Fri, 20 Nov 2015 15:36:54 -0800 Message-ID: Subject: Re: FYI: SVN to GIT converter currently broken, github is falling behind From: NGie Cooper To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Cc: "freebsd-git@freebsd.org" , FreeBSD-Current , "git-admin@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 23:36:57 -0000 Hi Ulrich, This might be one of the reasons why the git converter was broken recently: https://reviews.reviewboard.org/r/7617/diff (it seems that svn is now reporting "nonexistent" for new files instead of "Revision 0"). It broke rbt with svn 1.9 :(... Thanks! -NGie From owner-freebsd-current@freebsd.org Sat Nov 21 00:35:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2784DA2E80E for ; Sat, 21 Nov 2015 00:35:47 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADA031195 for ; Sat, 21 Nov 2015 00:35:46 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmec201 with SMTP id c201so93481733wme.0 for ; Fri, 20 Nov 2015 16:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wnmIvwmfy7boHa0Zc6UFFLkQsSU+7pNqozB7YT8hzZw=; b=waPd8K8HD4OLpDfJqoQQwiv7MGhHvI4MFEBs/7f8OFpkO5gDV8zB2pKlMorfoJwRaC w87oRPeoMD/rAj6kR+pAxhr9ncw4QeiRNFqecKw28PxDgLA/TnacpFtdMiNL2du8MHAB ZkdfdI4sd+mCZs2Zc8V9fEVKqlrKzp03FcsCOItpxiQ4zd/qj39P1qnvFsHj1kn4QGiX AMyMJM4JRPGrfNB8kMwg2W1CuKgrRFeVwke/7YagOrhxsRAZD+NuY70QV7bWBa0RjY+m sPhRWkf8irZZNV9YWbo6LdilLU8S0uStD+gS4P0EdWgQ6i+bD+o5k3pOwfb1+KnuUZWz i64g== X-Received: by 10.194.79.72 with SMTP id h8mr19212540wjx.136.1448066144122; Fri, 20 Nov 2015 16:35:44 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id c13sm1726097wmd.14.2015.11.20.16.35.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 16:35:43 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 21 Nov 2015 01:35:41 +0100 From: Baptiste Daroussin To: Jilles Tjoelker Cc: "Sergey V. Dyatko" , freebsd-current@freebsd.org Subject: Re: /bin/ls formatting broken for non-C(?) locales Message-ID: <20151121003541.GF21071@ivaldir.etoilebsd.net> References: <20151120110556.6e20a71f@laptop.minsk.domain> <20151120104253.GA21071@ivaldir.etoilebsd.net> <20151120110212.GB21071@ivaldir.etoilebsd.net> <20151120122352.GA5751@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XIiC+We3v3zHqZ6Z" Content-Disposition: inline In-Reply-To: <20151120122352.GA5751@stack.nl> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 00:35:47 -0000 --XIiC+We3v3zHqZ6Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 20, 2015 at 01:23:52PM +0100, Jilles Tjoelker wrote: > On Fri, Nov 20, 2015 at 12:02:13PM +0100, Baptiste Daroussin wrote: > > On Fri, Nov 20, 2015 at 11:42:53AM +0100, Baptiste Daroussin wrote: > > > On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote: > > > > subj. http://i.imgur.com/F9QO29l.png > > > > it is on head@r290573: > > > > WTR: > > > > env LC_ALL=3Duk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL= =3Dru_RU.UTF-8 > > > > ls -la /usr/ports/databases/ >=20 > > > > env LC_ALL=3DC ls -la /usr/ports/databases/ works fine > > > > also on old stable/10 (r286868) as I can see 'month' field length = 3 symbols=20 >=20 > > > Thanks for reporting, I can reproduce the issue with some other > > > locales. The thing is there seems to be no standard for abbreviated > > > length. Formerly we had a 3 character lenght for abbreviated month. >=20 > > > We now use CLDR which seems to follow the abbreviated rules from IBM: > > > "Each string must be of equal length and contain 5 characters or less" >=20 > > > There are 2 possible fixes: either always pad those in the locale > > > definition which seems wrong or modify ls so that it by itself pads > > > properly. >=20 > > > Neither posix nor ISO-14652 defines the length of the abbreviated form >=20 > > > padding in the locales themself would be wrong so I do propose to > > > pad in the ls command. And padding with 5 characters. >=20 > > For the record glibc/linux had the same problem: > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D9859 >=20 > > "fixed" in coreutils (gnu ls) the way I propose to do for us > > http://git.savannah.gnu.org/gitweb/?p=3Dcoreutils.git;a=3Dcommit;h=3D61= 2b647dd16d5abc03b295abe42d8b4a0fe660f7 >=20 > Coreutils fixed it slightly better: it calculates the maximum width of > the abbreviated month names and pads to that (with a maximum of 5). In > particular, this ensures that the output does not change for locales > that have 3-character abbreviations, such as the POSIX locale. I think > this is valuable. >=20 > They also keep the list of month names from this calculation and they > say this speeds up ls noticeably compared to having strftime() expand %b > for every file. Here is what I do propose (sorry for the ugly pad_to_col name, if one has b= etter please share :D https://reviews.freebsd.org/D4239 Best regards, Bapt --XIiC+We3v3zHqZ6Z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZPvF0ACgkQ8kTtMUmk6Ex2lQCbBT6irike5A4NGCDAt4aLmR6W lwoAniJw4ESDV4OI5gZd+E4y+HdTRrT8 =AXP7 -----END PGP SIGNATURE----- --XIiC+We3v3zHqZ6Z-- From owner-freebsd-current@freebsd.org Sat Nov 21 00:45:40 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3646A2EA58 for ; Sat, 21 Nov 2015 00:45:40 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42FEC1805 for ; Sat, 21 Nov 2015 00:45:40 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbblt2 with SMTP id lt2so71064556lbb.3 for ; Fri, 20 Nov 2015 16:45:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=rk97DBrRyVKlFfC7Ux1GHq7ifDkr0O8+pK+MiJjAMe8=; b=hwyaLJPpGXi4yT26hGjHpBhYi/2b6lI0EM5WiSF39QUYrmVmAf2XmiWCTITB5n9715 zA0TLv+mpOYhcnSF41gqf1/VAfX3XDlBrgPWMjV9BmibPHKoDOSXWcVlkhY4Zudt13lx usTDRT9mL9iiT5nkAKJo4NpQegTErA0tGPO0MhJPdwoD2Ya7PbyGVqDrj7z35Y9ltvNn 73IBF34Zbr55CXSfIEGUmr0qfohgs9i3rKIvGpLLJppqPGv9FCyi2625ZBXwm4bf4hdq rYZYCi+DhlYp1Vi8mmqefoyzkF8Q/IKj4IHr6VR7aDuWQBmL2SkJZj43rBNCMGdKngpE oFOw== X-Gm-Message-State: ALoCoQnmz4szdgZ3NYauRsXqY2wy5awr4trQpOz8E2edUoZK6NvBrUaI3LECCTi53y58uhiPLKfS X-Received: by 10.112.218.42 with SMTP id pd10mr6792910lbc.114.1448066732019; Fri, 20 Nov 2015 16:45:32 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id a190sm241393lfa.32.2015.11.20.16.45.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 16:45:31 -0800 (PST) Subject: Re: /bin/ls formatting broken for non-C(?) locales To: Baptiste Daroussin , Jilles Tjoelker References: <20151120110556.6e20a71f@laptop.minsk.domain> <20151120104253.GA21071@ivaldir.etoilebsd.net> <20151120110212.GB21071@ivaldir.etoilebsd.net> <20151120122352.GA5751@stack.nl> <20151121003541.GF21071@ivaldir.etoilebsd.net> Cc: "Sergey V. Dyatko" , freebsd-current@freebsd.org From: Andrey Chernov Message-ID: <564FBEA9.7070100@freebsd.org> Date: Sat, 21 Nov 2015 03:45:29 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151121003541.GF21071@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HLEcicowW6IpmU1691fBLNoGGDVGawjHs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 00:45:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HLEcicowW6IpmU1691fBLNoGGDVGawjHs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21.11.2015 3:35, Baptiste Daroussin wrote: > Here is what I do propose (sorry for the ugly pad_to_col name, if one h= as better > please share :D >=20 > https://reviews.freebsd.org/D4239 The whole function is ugly, not only its name. Please no hardcoded constants assuming some internal encoding knowledge, they are wrong for non-UTF-8 encodings in any case, use wide chars instead. BTW, the same 3 chars restriction is in tar, cpio, pax, lots of ftp clients, i.e. where 'ls' emulated. --=20 http://ache.vniz.net/ --HLEcicowW6IpmU1691fBLNoGGDVGawjHs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWT76qAAoJEKUckv0MjfbKy0kH/1o5ZA4XwStZo5VY/U6BiEYo 1afEKSF+IdJTv9lG8tKjPN9YwlIt0cLLVT48UeIAIeYIYV4hwEgTLJ3JNb3RiZmz hxyG3wPrAtEN2AsCGCOGq6DqX4tWphpL42/N97u15cZyRgPUUifg7iKyFV8Dhwnv ZLIYq8X0SCGEm4pNHgQQXegRqs971WdwyQSOLbrmW2WsubAYGBc1bIckAopNJvQK CVOEBSpScidblTBNFTEYG+3iXV5QWR7dcJ/Pp4lTAhbPkaMIasahl7uZ26+bhuHL pYxAV4ijkR6Qdwd8fgv3DJmZ7d6Lu1Kcxy4W84Em5+XPju1BgQ84Pnj+tQkSMq4= =eCbV -----END PGP SIGNATURE----- --HLEcicowW6IpmU1691fBLNoGGDVGawjHs-- From owner-freebsd-current@freebsd.org Sat Nov 21 01:57:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0270A32777 for ; Sat, 21 Nov 2015 01:57:56 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33F9911CD; Sat, 21 Nov 2015 01:57:56 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmvv187 with SMTP id v187so94689478wmv.1; Fri, 20 Nov 2015 17:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=x8VqDsKXQGnCunXzhlmrtQXWwXI6d3gxJBSQYuhM/5c=; b=TAjqDGOV2oLJLAG5lietbevfLasmLCWjc7pMUFHMhW9E3dDHWYU3ASecBEoVaqQXga jkBZuSDTlEG/82gVrEJyj11CLzT0NngtKbbmroH+ORUaKOMitu5v8TfZE3OxOnuhtQLV t5Je3EbezU2d5ABV7nOUXk2ko5tBAI3xzgx740zMOBPZH0C5fGoJNpmL6eyWY2dTrvIq /lGvFQQC/c+mQ2pie2n8T8rw488zLk1NHrs2Cm2f/gnpnMsAZn4GN859rMGvEV4BQst6 73pZJPJ4yE9YGKK+DKYn5FKDfabmhLpzSIlUkgMjB7nVGDKRrDmqMiarqONVD0FMQizP 7aBA== X-Received: by 10.28.215.211 with SMTP id o202mr2874355wmg.85.1448071073883; Fri, 20 Nov 2015 17:57:53 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id lv4sm1902999wjb.43.2015.11.20.17.57.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 17:57:52 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 21 Nov 2015 02:57:51 +0100 From: Baptiste Daroussin To: Andrey Chernov Cc: Jilles Tjoelker , "Sergey V. Dyatko" , freebsd-current@freebsd.org Subject: Re: /bin/ls formatting broken for non-C(?) locales Message-ID: <20151121015750.GG21071@ivaldir.etoilebsd.net> References: <20151120110556.6e20a71f@laptop.minsk.domain> <20151120104253.GA21071@ivaldir.etoilebsd.net> <20151120110212.GB21071@ivaldir.etoilebsd.net> <20151120122352.GA5751@stack.nl> <20151121003541.GF21071@ivaldir.etoilebsd.net> <564FBEA9.7070100@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XRI2XbIfl/05pQwm" Content-Disposition: inline In-Reply-To: <564FBEA9.7070100@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 01:57:56 -0000 --XRI2XbIfl/05pQwm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 21, 2015 at 03:45:29AM +0300, Andrey Chernov wrote: > On 21.11.2015 3:35, Baptiste Daroussin wrote: >=20 > > Here is what I do propose (sorry for the ugly pad_to_col name, if one h= as better > > please share :D > >=20 > > https://reviews.freebsd.org/D4239 >=20 > The whole function is ugly, not only its name. Please no hardcoded > constants assuming some internal encoding knowledge, they are wrong for > non-UTF-8 encodings in any case, use wide chars instead. >=20 > BTW, the same 3 chars restriction is in tar, cpio, pax, lots of ftp > clients, i.e. where 'ls' emulated. >=20 Updated to use wide char functions. tested with ru_RU.UTF-8 and ru_RU.KOI8-= R, fr_FR.UTF-8, ja_JP.eucJP and some chinese locales. Concerning tar and cpio, I can probably push the same thing into bsdtar (wh= ich will fix the same issue they also have on linux), ftp is safe, pax is not a= nd could probably be fixed as well. FYI on linux only ls has been fixed. gnutar uses a different format for its output. Bapt --XRI2XbIfl/05pQwm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZPz54ACgkQ8kTtMUmk6EwMTQCeNqfmdFtXf7+cB7Kx7XPxO6ZZ nNoAoJFJL5NLcwkQoXkvo8/lTZaRCdOH =u3F3 -----END PGP SIGNATURE----- --XRI2XbIfl/05pQwm-- From owner-freebsd-current@freebsd.org Sat Nov 21 10:10:02 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79C01A3372B for ; Sat, 21 Nov 2015 10:10:02 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4262E18E7 for ; Sat, 21 Nov 2015 10:10:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id A9E651F178 for ; Sat, 21 Nov 2015 12:10:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Sat, 21 Nov 2015 12:10:08 +0200 From: dan_partelly To: Subject: libxofication of FreeBSD kernel =?UTF-8?Q?=3F=20=32=30=31=35=30?= =?UTF-8?Q?=36DevSummit?= Message-ID: <9dc407161866b3db3135433da3a25b10@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 10:10:02 -0000 Hi all, At the following URL: https://wiki.freebsd.org/201506DevSummit/libxo the listed agenda of libxo working group include the following topic of discussion: ---- Discussion: libxo in the kernel. ----------------- Can someone please explain exactly what happens here ? Who pushed this agenda , regarding libxo in kernel, and what was discussed ? For me it is worrisome that such a topic of discussion even exists. It is my opinion that engineers should strive to simplify a kernel, even reduce their size in LOC where possible, not adding complexity, especially totally unjustified complexity. But I would like to hear the whole story before passing judgment on the issue. Dan From owner-freebsd-current@freebsd.org Sat Nov 21 11:53:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C5E8A349AF for ; Sat, 21 Nov 2015 11:53:44 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3518D130E for ; Sat, 21 Nov 2015 11:53:43 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a06jc-0009TO-Lb for freebsd-current@freebsd.org; Sat, 21 Nov 2015 12:53:40 +0100 Subject: Re: EFI and i915kms questions To: freebsd-current@freebsd.org References: <54B18FFE-063F-4F62-9343-28FDE68EE358@pcbsd.org> From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Message-ID: <56505B3F.2070403@dumbbell.fr> Date: Sat, 21 Nov 2015 12:53:35 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <54B18FFE-063F-4F62-9343-28FDE68EE358@pcbsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7FH34O52gOavfdeJHmnikcqPvBS0kxr7Q" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 11:53:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7FH34O52gOavfdeJHmnikcqPvBS0kxr7Q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/11/2015 18:15, Joe Maloney wrote: > Hello, Hi! > Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and=20 > recent 11 CURRENT the resolution no longer sets properly when using > UEFI boot. It now boots with a 640x480 resolution, and kldload > i915kms results in a black screen. I have not been able to grab a > debug log, or crash dump even with all of the debugging features > turned on. I cannot ssh into the laptop when this panic occurs, and > the screen is black so I can=E2=80=99t really see what happened. I=E2=80= =99m curious > if there is anything else I can do besides enabling dumpdev or > kldload -v i915kms > output.txt that doesn=E2=80=99t give me any detail= =2E > Nothing shows up in /var/crash or whatever the directory was. You could try to set debug.debugger_on_panic=3D0 in /etc/sysctl.conf. It often helps to at least get core dumps when the crash happens in a video driver. --=20 Jean-S=C3=A9bastien P=C3=A9dron --7FH34O52gOavfdeJHmnikcqPvBS0kxr7Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWUFtEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMlWQP+waGtwv8rtwR60N20YvoKiC/ yyv1RgulYqJDVZixVeZf29LbZU7Z8h1KvkhN8ryHXHgmrEMzFzFG+KTi9RtXZQlh 24zvEuaNRlTGyR/vDIW/+H72hNkZO+FXucIxx+i+Aa1A9yyfjpm5X7jqGLrK/DdO ZpLT3Cz1AYJpVk5zWB6oVF3iHeAQENwcAbe7SiLgBAE2WVnXWTX4WQQsnvvBTC9y 4vWVsFHh96clyvYtZRWIkNpHFigRUvMtIjEDdEXCJV0K/jPsW7OVYJxk18KsdAig T5d/i0LbkXHcdsZYsJ23UGYhVmS/5L4JYqZwdtKAAJ9BVtlxqj1ARw0pb2bdKudt blA2zdRHVzOrxsS7ilVPywjmVEQwiP/lKKWezAJ9yrSneAI26uXbN8JTC9dbBytS jCQK8ZwlfQ7xAhMvSRB10MOGvF/pGAGBvy6QdPt+EKCCww561Y/zuGgOpkkqTHYd Ae+CSJZrmzXC68hjtR1sVGImUSyx8BcMi+4xMpnKeZTe1Qp06g/L11lfH911lSxI 5MgS30TBzRVSYSOMWM9204rWaQa5bguxRZiKL75PmDxloSz62LtneytX/LE22ZnS bt/p0cNa5UFkHd+qRc9MUULOwodDPDHVTVoLCcjWtcCKYN9K6DHlXbkOxUZ5WaT4 Xg3zrhBtdlsAMylEsZS+ =b8S3 -----END PGP SIGNATURE----- --7FH34O52gOavfdeJHmnikcqPvBS0kxr7Q-- From owner-freebsd-current@freebsd.org Sat Nov 21 12:18:45 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28E30A3260F for ; Sat, 21 Nov 2015 12:18:45 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D61A8111E for ; Sat, 21 Nov 2015 12:18:44 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by ykfs79 with SMTP id s79so194948788ykf.1 for ; Sat, 21 Nov 2015 04:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CkgVnGctylgXQ8EKiArvzM8tCeZHUP03Ofos/6KTPEY=; b=IMgdRpAqhUmGfayqXxt8vrQEUrfweQx6e7hf4sD/VXvjflIp/HgJ2WJ+XzRflNWVpd 1IYE9dk9KQE7W3ameqRWDjd4OXK24mJzIBK8MA4ZU60vxOfKWknCIzHXSd4v+c/z/i2+ q2itvqttiny1sLteFxSwbarC5xnOhrW1P3OSNBQokASSJcbfID+UjRp8GID2ygAM3Gx2 u2sLqKICF91vMqPnt342OmOr9/awmJCN5qvtzWphtGaqW0/7o8ZHh4WkvoQwh4KxPtj2 LcR6fJ1qSUAq7bew9MiiV4HsI4NXUcLH6OFDq6EvG9VtiAJDvvF83ct1scG7M7TYuEUV NIhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CkgVnGctylgXQ8EKiArvzM8tCeZHUP03Ofos/6KTPEY=; b=iFHPOSM7YeF3KP5yEChibSbFasDPBvh+8aMGoOlIjEw47/U4zayuhQHMygXZcSNhb/ fUFyncGLhHBlll07CUvwxW1wzHRZnR92JQpTnkCH1fmP4N23qf88JOY0yh+Grd3vpsFL roVsZWp4AzTBDfryoeNeQ8Bk/uYz3iCHQlK3HEyF3Na+QJxgEEA0gRC+XiMCvO8DwfgW vAReX1Gw9goZNfEC7AlHdV08PRyimAM0rjXVNbJNhH0SKqSLt+tDOxqIB4bIdDpO05Ws uk5MgjPqgiyxSbzQW4g+2dO6jPT7RrH2XmdGzaUeWgAKLCSBGJzhSGmV9mbHjN7cOwK6 UUsQ== X-Gm-Message-State: ALoCoQltdJDS1b9Zb4rd0tmqwEIPqXD0gVzbTFr9lYtmb9taxa0hu8T5XPq4ZrNpRpV7aNiFTOQw MIME-Version: 1.0 X-Received: by 10.129.56.7 with SMTP id f7mr18684348ywa.52.1448108323641; Sat, 21 Nov 2015 04:18:43 -0800 (PST) Received: by 10.129.91.197 with HTTP; Sat, 21 Nov 2015 04:18:43 -0800 (PST) In-Reply-To: <20151121003541.GF21071@ivaldir.etoilebsd.net> References: <20151120110556.6e20a71f@laptop.minsk.domain> <20151120104253.GA21071@ivaldir.etoilebsd.net> <20151120110212.GB21071@ivaldir.etoilebsd.net> <20151120122352.GA5751@stack.nl> <20151121003541.GF21071@ivaldir.etoilebsd.net> Date: Sat, 21 Nov 2015 13:18:43 +0100 Message-ID: Subject: Re: /bin/ls formatting broken for non-C(?) locales From: Ed Schouten To: Baptiste Daroussin Cc: Jilles Tjoelker , "Sergey V. Dyatko" , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 12:18:45 -0000 Hi Baptiste, I suppose you should use the wcswidth() function somewhere to compute the visible width of the month name. Some characters may be double-width, others may have no effective width at all. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Sat Nov 21 20:57:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9DCFA34AB1 for ; Sat, 21 Nov 2015 20:57:59 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5ED7B1B3D for ; Sat, 21 Nov 2015 20:57:59 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lbbkw15 with SMTP id kw15so78589954lbb.0 for ; Sat, 21 Nov 2015 12:57:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=M3hadn13ySyTW19sMXOmDibk2bCGgioo16M7zF2ecmY=; b=KIh6vEtGaAlt2yqwc7TyYcYvkJu+YoGAaj06+heY+/5al+i8FKmx2Bg+srgAJ5k8oq UNs7kJbWbWx2J9Zqd2EXHd7zoYYGZpBu3uSopghEj8DP6u3KD3d0zc+we8QQqzPKg0cy akLKaBfEbdtI4ReUAnzL2Q9OVf9cAYuygY++h4G45OCB+8rupVLZF8w1MwJwe3YZsP8B 8AbsNCRE572wg5FhSBqgaITtVYTOHJupgBnQ/888kNahkA0beWjc/frP0WmLceHrK0IE zuVFLEcxoz4NAdb5YYSeMJuCn9iiujtGkLRNRbDu0+McXfa+E/rY8+tBoJgr5qYbE7SF EMSw== X-Gm-Message-State: ALoCoQkaed2Pt9NHJDBG9x6uakACnDeFjw+XEDu8cXiuePjMhdHRO+HBvZS2jPGOoaviTBs7T8SX X-Received: by 10.112.99.4 with SMTP id em4mr8005226lbb.87.1448139471214; Sat, 21 Nov 2015 12:57:51 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id l128sm789373lfe.27.2015.11.21.12.57.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Nov 2015 12:57:50 -0800 (PST) Subject: Re: /bin/ls formatting broken for non-C(?) locales To: Ed Schouten , Baptiste Daroussin References: <20151120110556.6e20a71f@laptop.minsk.domain> <20151120104253.GA21071@ivaldir.etoilebsd.net> <20151120110212.GB21071@ivaldir.etoilebsd.net> <20151120122352.GA5751@stack.nl> <20151121003541.GF21071@ivaldir.etoilebsd.net> Cc: Jilles Tjoelker , "Sergey V. Dyatko" , FreeBSD Current From: Andrey Chernov Message-ID: <5650DACA.2090501@freebsd.org> Date: Sat, 21 Nov 2015 23:57:46 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 20:57:59 -0000 On 21.11.2015 15:18, Ed Schouten wrote: > Hi Baptiste, > > I suppose you should use the wcswidth() function somewhere to compute > the visible width of the month name. Some characters may be > double-width, others may have no effective width at all. > I agree. Checking error return of wide chars functions with some fallback will be good too. -- http://ache.vniz.net/