From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 03:18:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A573676; Sun, 14 Jul 2013 03:18:12 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 44A3591; Sun, 14 Jul 2013 03:18:11 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r6E3I7EI007822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Jul 2013 22:18:07 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sat, 13 Jul 2013 22:18:07 -0500 From: "Teske, Devin" To: Mark Felder Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAUuIAgAA53QA= Date: Sun, 14 Jul 2013 03:18:06 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> In-Reply-To: <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <1B4CECD849B49245B27E503B1B42CEAA@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-13_08:2013-07-12,2013-07-13,1970-01-01 signatures=0 Cc: Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 03:18:12 -0000 On Jul 13, 2013, at 4:51 PM, Mark Felder wrote: > On Sat, Jul 13, 2013, at 13:54, Teske, Devin wrote: >>=20 >>=20 >> If FTP access (or any of the other remote access methods) are going away >> for HEAD pkg access, I'll need to know so I can make the appropriate >> changes in the HEAD branch of bsdconfig. >>=20 >=20 > It's simpler than you think. The new pkg uses libfetch. You can have > your PACAKGESITE be file:// ftp:// http:// https:// ...=20 >=20 In bsdconfig (as one might expect), before a user installs a package, he or= she is presented with a list of packages with descriptions (and perhaps ot= her limited information). ASIDE: For efficiency, I will actually need three things: (1) a list of all= packages (2) their descriptions and (3) their run-time dependencies. NOTE: I'll need run-time dependencies so that as they're checking boxes in = the UI, I can update accordingly (has nothing to do with how the dependenci= es are handled when the packages get installed; I'll let pkg handle that wh= en it comes time, but for the UI and for the "review" screen, I want the us= er to be informed and I can do that more efficiently if I have a master-lis= t and don't have to make continuous queries). That being said, I was planning on doing a "pkg rquery" to get that master = list of [minimally] 3-pieces of information. What protocol does that "rquery" run on? What would one have to do to set u= p their own server that can accept an "rquery"? (our customers don't have I= nternet access) Last but not least... Can you do an "rquery" on a local repository? (say, one that has been mount= ed via NFS or some other media, local or otherwise but looking like a local= filesystem once-mounted). What would be required to get a local repository= like that going? > I do suspect that HTTP_PROXY support is probably not available as I > recall seeing a post where someone was asking about that getting > implemented for fetch. I'll have to research that again, though. Thanks. Keep me up to date on that. Neither sysinstall nor bsdinstall really give HTTP_PROXY access much though= t (they support it, but only minimally). They just construct a raw HTTP hea= der with the FTP URL and send that directly to the proxy. One cute thing it= does (when initializing the connection) is test for Squid and if-so, appen= ds ";type=3Di" to the URL (to force binary download versus ascii). No support for proxy-server authentication (however user/pass authenticatio= n for the FTP server is passed through to the proxy-server). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 03:33:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1CABA850; Sun, 14 Jul 2013 03:33:11 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 67508FD; Sun, 14 Jul 2013 03:33:10 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id eg20so8740677lab.33 for ; Sat, 13 Jul 2013 20:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lelTgTcRhI92McwAfZNbP1301lKWhlI7mrgwyW8Oou4=; b=UBEFa3QxYIHhwmw3CWmQbo32932T1a3GGeD/vichiiW0F9KJlkaGPfsXaI/kWeLg/g A3w8eSKfcCglfCW7NgnKiCJ3ubBuq1QeXmo3cJ8aRCqYRuQkQmSYaWFcTDllW440umhl bgsBMUO6QzZAwVL48U6CdfqRadEnZxdnQRQqUh9KD0p5rbl5KieC1IfgkV6hRwWLZEvq 08ms5CtoGfb06fB+wtmWeAYqXyR0xImzQQZuBq8xe4O4LFhPwNOTVIbLgGT+htIpl1kw NitPIiBMHoZIsruRkHUTBYmTe6cOeYrKusOw1PgrBmXXuwZ95KxJ2R9kFVKdaZ18tKGt asGw== MIME-Version: 1.0 X-Received: by 10.152.4.65 with SMTP id i1mr22301421lai.21.1373772789259; Sat, 13 Jul 2013 20:33:09 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.149.38 with HTTP; Sat, 13 Jul 2013 20:33:09 -0700 (PDT) In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> Date: Sat, 13 Jul 2013 20:33:09 -0700 X-Google-Sender-Auth: UCxFI1mDO-TpcPiidtUsVnKIkgI Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Craig Rodrigues To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mark Felder , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 03:33:11 -0000 On Sat, Jul 13, 2013 at 8:18 PM, Teske, Devin wrote: > > Can you do an "rquery" on a local repository? (say, one that has been > mounted via NFS or some other media, local or otherwise but looking like a > local filesystem once-mounted). What would be required to get a local > repository like that going? > > (1) Install the port: ports-mgmgt/poudriere , and follow the instructions at: https://fossil.etoilebsd.net/poudriere/ (2) Build your own repository of packages (3) Make that repository available in a local file system or NFS I believe that "pkg" and "poudriere" address pretty much all the questions you have been asking, so you just need to set up the environment so that you can do experiments to integrate it with bsdconfig. PC-BSD and DragonFlyBSD have switched to using "pkg", so it is quite well tested. Baptiste and the rest of the pkgng and poudriere team have put a lot of effort and thought into this, and I believe you will be pleased with the results once you migrate over to these tools. -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 04:24:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90D63C79 for ; Sun, 14 Jul 2013 04:24:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 478231D1 for ; Sun, 14 Jul 2013 04:24:02 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id oz10so9199303veb.19 for ; Sat, 13 Jul 2013 21:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=66hDC4Dtcb37BEcZECj6bBODwEgL8WrGLmnL/oyC1Hw=; b=MY6xxzexXkGw1JHtbD0+bmQcx2Fsi6vhU7GffGlYvsCtzlEheegp4EZX2q34QgvJqK CzOVFedvOjCkT5d9cecXmaLZjg7T2elqzST+9NAetdAZfDuK7+06jFXUhcLQG6wM3E0N 8dbowu0HljRpExNmrjODTSTEIDxcCnYEiqhUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=66hDC4Dtcb37BEcZECj6bBODwEgL8WrGLmnL/oyC1Hw=; b=pAhGxXAlm1T8tlwXS9xmiCVo9sKZknyN0rjbU24vw2jho4SbWO4ndr6Mkt8m8Q7B9e ujXZ+5hnLjbVhx8F6W2ZeEsisnzLHle5mY1RS3t8xNHh8sbzohDKIlqT0zp0m6nZDykK zNV1YWdzQ6G221AbPTPYjTMTU191M9W6piPKUoc39r/V8ZwHyvZM+G0nbklmfMqlufVI KnHrJrpzomjg26VIjLqXuFVaG69WJ9ruDdoyjbRbVJrlJgwmegbh3gFO8HvEyOmIegGI aJohGWNRalKltkw94QBi/ekpMpvH8lRsCbEaorCtbdOjCwu11Jji4+pm63/NqPtmsX+p nb4A== MIME-Version: 1.0 X-Received: by 10.220.47.131 with SMTP id n3mr27176434vcf.7.1373775841253; Sat, 13 Jul 2013 21:24:01 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Sat, 13 Jul 2013 21:24:01 -0700 (PDT) In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> Date: Sat, 13 Jul 2013 21:24:01 -0700 Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Peter Wemm To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlE0K4FjJhGSwNvhJFFqwj6mnYCx8jn90J9zJnPy/8uq+ULUzDF0/CMPA3JUmvUTQ5MowzX Cc: Baptiste Daroussin , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 04:24:02 -0000 On Sat, Jul 13, 2013 at 11:54 AM, Teske, Devin wrote: > So yes... I'm asking... in a HEAD world, what is the "officially supported" method of acquisition? This has been answered elsewhere, but to be absolutely clear: * 10.0 will ship with pkgng format packages. * pkgng will be configured to pull via http from project infrastructure by default. * The project will not be providing pkg_install format packages via any method for 10.x. This doesn't stop third parties building and providing them unofficially but my understanding is that they won't be on any project operated freebsd.org sites. Footnote... *.cc.freebsd.org are generally project operated sites. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 04:25:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DDFB7D90 for ; Sun, 14 Jul 2013 04:25:13 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4991E6 for ; Sun, 14 Jul 2013 04:25:13 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id ht10so8564445vcb.18 for ; Sat, 13 Jul 2013 21:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pFScGlwVULzgPVKhgvpLPd7ZNA64XkG9zI+Knc/yTpE=; b=PjVi/TYvNbB8L/HomhNXTc+7+eMgg0I5CUydIV3NVKYdy0Kie5uaRpAaZpsIttPZng liPtJ2RI2kw3yIfBl+Ax7WiIhvtdq6z6Re+0zc9dEwTq+2Wo/e5jf9a2IOaaqvzO9J79 Nf53kyVSqe/jQ14A0fLDmCDh+OVeC0RFLijQ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pFScGlwVULzgPVKhgvpLPd7ZNA64XkG9zI+Knc/yTpE=; b=Waq+1egbPAteVT4sXJBhCnEmFSpWRpIBVjQVo45yNe1HkfzK/Cm5rJB7PtuV7LMhPB PXa+lrkXPy5jQ9rKHVmBubdsn2WLeRXaKoYTHj0WEHyb2rXSln7v4hVjQEupHVt3AfId HQvoIplMSZFZHdMncByS/ddehn6TeFRyo2yWpGULOCQ2cRy8x/CMMkx6az6dnBgc5anW oJDkgccC4BLJNNOH8l8LatljjFrF/JWji4EAbfwB2V2eaA4WynfdopXx2/5wtOZCMYBl 9LqHfsNIMO9IVCi47sOCBU/WAsfqiR/HdDDoCpd0IrB53JtVfMxRYmDGdipT7pJmY9S2 6blg== MIME-Version: 1.0 X-Received: by 10.220.123.195 with SMTP id q3mr26525151vcr.64.1373775913144; Sat, 13 Jul 2013 21:25:13 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Sat, 13 Jul 2013 21:25:13 -0700 (PDT) In-Reply-To: References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> Date: Sat, 13 Jul 2013 21:25:13 -0700 Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Peter Wemm To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn07TEtU1NjSFm9Fu+A8RXrSlDcMFgd4IXjWMe30FMYlfbliS6ufZYyQOAC4Xh75Z6BWkoV Cc: Baptiste Daroussin , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 04:25:13 -0000 On Sat, Jul 13, 2013 at 9:24 PM, Peter Wemm wrote: > Footnote... *.cc.freebsd.org are generally project operated sites. .. gah.. generally *NOT* project operated sites. They're third party / regional / local. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 05:48:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9625F46E; Sun, 14 Jul 2013 05:48:37 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 62B7A3D2; Sun, 14 Jul 2013 05:48:36 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r6E5maQx032561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 00:48:36 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 00:48:36 -0500 From: "Teske, Devin" To: Peter Wemm Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAnyqAgAAXnwA= Date: Sun, 14 Jul 2013 05:48:34 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC4E0D@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9F8C873402ADEA4C92A3C8D570D0545F@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Baptiste Daroussin , Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 05:48:37 -0000 On Jul 13, 2013, at 9:24 PM, Peter Wemm wrote: > On Sat, Jul 13, 2013 at 11:54 AM, Teske, Devin > wrote: >=20 >> So yes... I'm asking... in a HEAD world, what is the "officially support= ed" method of acquisition? >=20 > This has been answered elsewhere, but to be absolutely clear: >=20 > * 10.0 will ship with pkgng format packages. >=20 Ok. Respectfully not what I was inquiring about. > * pkgng will be configured to pull via http from project > infrastructure by default. >=20 Thanks. Good to know. So when you don't define PACKAGESITE, it defaults to = HTTP. How about rquery? What protocol does that use? and what does it talk to? > * The project will not be providing pkg_install format packages via > any method for 10.x. >=20 Yes, I know this from previous announcements (not the topic at-hand; respec= tfully). > This doesn't stop third parties building and providing them > unofficially but my understanding is that they won't be on any project > operated freebsd.org sites. >=20 Question: Where can I learn more about the actual format of what's in the n= ew tarballs? This is going to be important not for bsdconfig, but $work (we= have our own build platform; I'm going to have to rewrite it from masterin= g PLIST files to mastering YAML MANIFEST files and I want to know all the g= ritty details). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 05:54:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CC7305C6; Sun, 14 Jul 2013 05:54:55 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9269C5E3; Sun, 14 Jul 2013 05:54:55 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id r6E5sqS7015391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 00:54:52 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 00:54:52 -0500 From: "Teske, Devin" To: Craig Rodrigues Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAUuIAgAA53QCAAAQ1gIAAJ5eA Date: Sun, 14 Jul 2013 05:54:51 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mark Felder , Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 05:54:55 -0000 On Jul 13, 2013, at 8:33 PM, Craig Rodrigues wrote: On Sat, Jul 13, 2013 at 8:18 PM, Teske, Devin > wrote: Can you do an "rquery" on a local repository? (say, one that has been mount= ed via NFS or some other media, local or otherwise but looking like a local= filesystem once-mounted). What would be required to get a local repository= like that going? (1) Install the port: ports-mgmgt/poudriere , and follow the instructions= at: https://fossil.etoilebsd.net/poudriere/ (2) Build your own repository of packages I assume that poudiere builds packages from ports. That's not how we build package repositories here (and would expect that th= ere are many more like us). We expect to start with an empty directory, go grab packages that we want (= one by one) from FTP. Then put those tarballs into a directory. There's no = additional step because we download the INDEX file to the repository too. L= ocal repository is built. Is it reasonable to assume that this is still possible? We don't want to ha= ve to set up poudriere or build our own packages for packages that were alr= eady built at the time of release. (we don't track anything except security= releng branches). (3) Make that repository available in a local file system or NFS That's what we want. I believe that "pkg" and "poudriere" address pretty much all the questions = you have been asking, so you just need to set up the environment so that you can do experiments t= o integrate it with bsdconfig. But I want bsdconfig to work with local repositories without having poudrie= re. PC-BSD and DragonFlyBSD have switched to using "pkg", so it is quite well t= ested. Cool. Baptiste and the rest of the pkgng and poudriere team have put a lot of eff= ort and thought into this, and I believe you will be pleased with the results once you migrate over to= these tools. I think so too. But right now a *lot* of unanswered questions. -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 06:45:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BC79B28; Sun, 14 Jul 2013 06:45:58 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 487A0765; Sun, 14 Jul 2013 06:45:57 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r6E6juw7006136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 01:45:57 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 01:45:56 -0500 From: "Teske, Devin" To: Garrett Wollman Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOgFlREhI/XtjETUan8/QjEhM8pplkDrOA Date: Sun, 14 Jul 2013 06:45:54 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC5019@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> In-Reply-To: <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <90DC4C6200470542BC36BF0A8E654C72@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 06:45:58 -0000 On Jul 13, 2013, at 11:13 PM, Garrett Wollman wrote: > In article <20130714054840$7f8f@grapevine.csail.mit.edu>, > dteske@freebsd.org writes: >=20 >> How about rquery? What protocol does that use? and what does it talk to? >=20 > It accesses the sqlite database in /var/db/pkg that was previously > retrieved from the remote repository. >=20 This "previously retrieved" has me worried. One of the things that you could do with sysinstall was: 1. Browse packages (nothing else) 2. Exit sysinstall And your system is completely unmodified and the mirror your chose is forgo= tten. Now from what you explained of pkg, I'm worried that for bsdconfig: 1. Browse packages (nothing else) 2. Exit bsdconfig and now because the "pkg rquery" has staged a db, future "pkg" commands are= now influenced. In which case, I think I would best off downloading the sqlite db to a temp= orary location and pointing pkg at it (if that's possible). Because I'm not= sure that I want adhoc browsing in bsdconfig to change the default mirror = (but maybe that's desired? I'm not sure). >> Question: Where can I learn more about the actual format of what's in >> the new tarballs? This is going to be important not for bsdconfig, but >> $work (we have our own build platform; I'm going to have to rewrite it >> from mastering PLIST files to mastering YAML MANIFEST files and I want >> to know all the gritty details). >=20 > You really shouldn't know about the actual format of the tarballs; > your time would be better spent learning the new "pkg create", "pkg > register", and "pkg repo" commands. Depending on your needs, you > might want to write to the libpkg API instead. >=20 That won't work for us. You're not going to like the answer, but it does mean that things like "pkg= create", "pkg register" and "pkg repo" won't work for us. Because FreeBSD packages are just tar-balls, I created a build-system that = allows us to master and re-master them on *any* platform with nothing more = than "make" and a few standard UNIX utilities such as "awk" and etc. This m= akes it extremely convenient for developers and integrators. You can feel f= ree to check out the build tree on Mac OS X, make some changes to a file, c= heck them in, build the package, throw it in the repos, and all from the co= mfort of your own OS. Yes, it flies in the face of "dog-fooding", but the value-add that it bring= s to the table is quite tangible w/respect to our workflow. So the format is still something I want to know quite well. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 07:29:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A4DC4E30; Sun, 14 Jul 2013 07:29:53 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6EAED824; Sun, 14 Jul 2013 07:29:52 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r6E7TqFE030210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 02:29:52 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 02:29:51 -0500 From: "Teske, Devin" To: Garrett Wollman Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOgGCkEhI/XtjETUan8/QjEhM8pplkGukA Date: Sun, 14 Jul 2013 07:29:50 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> In-Reply-To: <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <881282E540AE6644A297F2197E8FFAFD@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 07:29:53 -0000 On Jul 14, 2013, at 12:06 AM, Garrett Wollman wrote: > In article <20130714064601$3ce5@grapevine.csail.mit.edu>, > dteske@freebsd.org writes: >=20 >>> [I wrote:] >>> It accesses the sqlite database in /var/db/pkg that was previously >>> retrieved from the remote repository. >=20 >> Now from what you explained of pkg, I'm worried that for bsdconfig: >>=20 >> 1. Browse packages (nothing else) >> 2. Exit bsdconfig >>=20 >> and now because the "pkg rquery" has staged a db, future "pkg" commands >> are now influenced. >=20 > Only if you update /usr/local/etc/pkg.conf to set a permanent > PACKAGESITE. Otherwise, it will notice that the remote repo catalog > you have isn't for your currently selected remote repo, and use that > instead. >=20 >>> You really shouldn't know about the actual format of the tarballs; >>> your time would be better spent learning the new "pkg create", "pkg >>> register", and "pkg repo" commands. Depending on your needs, you >>> might want to write to the libpkg API instead. >=20 >> That won't work for us. >>=20 >> You're not going to like the answer, but it does mean that things like >> "pkg create", "pkg register" and "pkg repo" won't work for us. >=20 > Congratulations for building your entire workflow around a horrible > kluge straight out of 1993. Prejudice much? > FreeBSD, however, is moving on. Moving from tarballs to tarballs, yep... moving along nicely. > (And > it's long past time!) I love your enthusiastic embrace. > Your developers will just have to deal. You're making the wrong argument. Bringing in a new package system doesn't help developers or integrators. It= doesn't matter if you switch "pkg_create" with "pkg_create". Developers li= ke being able to go into a build tree and say "make" and end-up with a pack= age. How that build tree does it should be "sufficiently advanced enough to be i= ndistinguishable from magic." Your answer implies that this infrastructure is unnecessary, when I can ind= eed tell you that even if it is not divulged to me what goes into a package= , I'll still end up ripping it open and creating my own build platform that= doesn't depend on platform-specific tools. And when the day comes that FreeBSD uses something other than tarballs, the= n I'll then force the developers to build the packages on the platform usin= g said tools; but until then, why pigeon-hole the process of building a pac= kage into one OS when developers could care less whether their "make" uses = pkg_create, pkg, rpm, dpkg, or what else? To give you an idea as to just how helpful this is... Imagine the following hierarchy: src/pkgbase/depend/mystuff/script1 src/pkgbase/depend/mystuff/textfile1 src/pkgbase/depend/mystuff/sourcefile.c src/pkgbase/depend/mystuff/Makefile You are a developer. You want to ship a package that contains "script1", "t= extfile1", and "binary1" (which is compiled by saying "make" to turn "sourc= efile.c" into "binary1") You want to ship 8 types of packages: FreeBSD-4.11 FreeBSD-8.1 (i386) FreeBSD-8.1 (amd64) RedHat EL 4 RedHat EL 6 (i386) RedHat EL 6 (x86_64) Debian Wheezy Debian Wheezy 64-bit This is where my framework comes in-handy... cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff make # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and built = the .tgz cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff make # it pulled the necessary bits from the "depend" dir and built .tbz cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff make # pulled in "depend" and made .rpm cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff make # pulled in "depend" and made .rpm etc. Of course, *any* time the depend tree has binaries in it... you have to fir= st do a make in there on the platform you want to ship the binary for, and = then do "make depend" in the platform-specific tree to pull in the binaries= . Once you've done that, you don't have to muck with the depend tree again = unless there are changes there. So, I assume that your prejudice remarks are because you haven't either see= n (a) such a platform or (b) such a need for said platform. Yeah, I could rewrite the freebsd-specific logic to use "pkg create", but l= et me tell you... When you have to touch a file that needs to get shipped out to multiple pla= tforms... It's damned nice to be able to build the FreeBSD packages under RedHat *BEC= AUSE* the redhat RPMs can't be built under anything else (building an RPM o= n FreeBSD and attempting to install it on RedHat results in an error messag= e similar to "this is an rpm for FreeBSD; go away"). Whereas FreeBSD will never balk about a package built on another platform. It's a huge time-saving measure... not having to jump over to each/every un= ique platform to package things up *IF/WHEN* you know that there are no bin= aries in the package *or* you've already checked the pre-compiled binaries = into the arch-specific hierarchy. > Or you > can maintain the old cruft for your business -- just don't expect > anyone else to use it, or even want to. >=20 I have no intention of making old-world packages... but I also have no inte= ntion of using "pkg create". --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 09:06:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DFA858EB; Sun, 14 Jul 2013 09:06:51 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 5C137A3A; Sun, 14 Jul 2013 09:06:51 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id r6E95QEr024120 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 10:05:26 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk r6E95QEr024120 Authentication-Results: smtp.infracaninophile.co.uk/r6E95QEr024120; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy) Message-ID: <51E269CD.8030603@FreeBSD.org> Date: Sun, 14 Jul 2013 10:05:17 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ROIXFAASMNHNHKAJFHBI" X-Virus-Scanned: clamav-milter 0.97.8 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_FAIL, SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Mark Felder , "freebsd-current@freebsd.org" , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 09:06:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ROIXFAASMNHNHKAJFHBI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14/07/2013 04:18, Teske, Devin wrote: > ASIDE: For efficiency, I will actually need three things: (1) a list > of all packages (2) their descriptions and (3) their run-time dependenc= ies. That would be the repository catalogue, which you can download by 'pkg update' (or it will happen automatically before pkg operations.) Or, more precisely, the repository /catalogues/ for each of the package repositories enabled in pkg.conf > NOTE: I'll need run-time dependencies so that as they're checking > boxes in the UI, I can update accordingly (has nothing to do with how > the dependencies are handled when the packages get installed; I'll let > pkg handle that when it comes time, but for the UI and for the "review"= > screen, I want the user to be informed and I can do that more > efficiently if I have a master-list and don't have to make continuous > queries). In 1.1 the repository catalogue is just the collection of all the YAML format metadata from all the packages in the repository, plus optional cryptographic signatures. While you could try and parse that directly, there's little point in re-inventing that wheel -- pkg will load the catalogue data into a sqlite database, and it provides 'pkg search' or 'pkg rquery' specifically for searching catalogue data. ('pkg rquery' is aimed at scripting use, 'pkg search' is more for interactive use.) > That being said, I was planning on doing a "pkg rquery" to get that > master list of [minimally] 3-pieces of information. Something like: pkg rquery -a '%n-%v %o\n%e\n%dn-%dv %do\n---\n' > What protocol does that "rquery" run on? What would one have to do > to set up their own server that can accept an "rquery"? (our customers > don't have Internet access) It's built around SQL queries against the sqlite database built from the repository catalogues. Once you've got the repo catalgoue, it doesn't need network access to just query the data. > Last but not least... >=20 > Can you do an "rquery" on a local repository? (say, one that has > been mounted via NFS or some other media, local or otherwise but lookin= g like > a local filesystem once-mounted). What would be required to get a local= > repository like that going? You can certainly build a local repository -- essentially you just assemble a set of packages in some sort of directory heirarchy, and then just run 'pkg repo' to create the catalogue. You can then access the repo by any of the protocols supported by libfetch -- which includes file://, suitable for a repo on a local or NFS mounted directory. Beyond what libfetch provides, you can also use ssh://. You'ld usually use poudriere or similar to build your own set of packages to populate your private repository, but there's nothing to stop you eg. mirroring some selection of packages from a public package repository and building your private repo from them. Or configuring your systems to use a local package repository /and/ a public repository. See pkg-repository(5). >> I do suspect that HTTP_PROXY support is probably not available as I >> recall seeing a post where someone was asking about that getting >> implemented for fetch. I'll have to research that again, though. > Thanks. Keep me up to date on that. pkg will use the proxing capabilities of libfetch -- so it will abide by any HTTP_PROXY or FTP_PROXY or any of a number of other environment variables as described in fetch(3). You can use the PKG_ENV setting in pkg.conf(5) to set the environment use by pkg commands. > Neither sysinstall nor bsdinstall really give HTTP_PROXY access much > thought (they support it, but only minimally). They just construct a > raw HTTP header with the FTP URL and send that directly to the proxy. > One cute thing it does (when initializing the connection) is test for > Squid and if-so, appends ";type=3Di" to the URL (to force binary > download versus ascii). Everything that pkg downloads is currently in the form of an xz(1) compressed tar archive[*] so definitely needs to downloaded in binary mod= e. [*] Even in some cases where the tarball contains only one file, which is a bit of a nonsense, but not hugely so. That may well be changed in future versions. > No support for proxy-server authentication (however user/pass > authentication for the FTP server is passed through to the > proxy-server). pkg uses libfetch's proxy auth support. You can also authenticate access to a repository via FTP or HTTP or HTTPS by encoding a username and password in the repository URL in the usual way. For access over SSH, use any of the authentication mechanisms provided by the ssh server -- use of ssh-agent(1) and key-based auth is recommended, to avoid having to type in passphrases repeatedly. I think if you pkgng-ify a test system and have a play with the capabilities pkg(8) provides (and maybe poudriere(8) too), you will be pleased, maybe even pleasantly surprised, by what it can do. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey ------enig2ROIXFAASMNHNHKAJFHBI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHiadUACgkQ8Mjk52CukIzV/gCePa/XNq6hY75R08tDNIzdspC0 hDAAn0OMG9xQ/uwPXP73iVfxLGnwYHGC =33Ny -----END PGP SIGNATURE----- ------enig2ROIXFAASMNHNHKAJFHBI-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 09:12:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19440AD6; Sun, 14 Jul 2013 09:12:49 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id C299CA6D; Sun, 14 Jul 2013 09:12:48 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r6E9CkII030336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 04:12:46 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 04:12:46 -0500 From: "Teske, Devin" To: Peter Wemm Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAnyqAgABM5IA= Date: Sun, 14 Jul 2013 09:12:45 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC52BE@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C2EC6096DC72941BC495ADEEE8D02C5@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Baptiste Daroussin , Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 09:12:49 -0000 On Jul 13, 2013, at 9:24 PM, Peter Wemm wrote: > On Sat, Jul 13, 2013 at 11:54 AM, Teske, Devin > wrote: >=20 >> So yes... I'm asking... in a HEAD world, what is the "officially support= ed" method of acquisition? >=20 > * pkgng will be configured to pull via http from project > infrastructure by default. So is this the right _first step_ patch for HEAD bsdconfig? NOTE: Based on feedback, this will be the list of what official pkg infrast= ructure we want to support from the base. The selection would be communicat= ed to pkg via $PACKAGESITE. Index: head/usr.sbin/bsdconfig/share/media/http.subr =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/usr.sbin/bsdconfig/share/media/http.subr (revision 253333) +++ head/usr.sbin/bsdconfig/share/media/http.subr (working copy) @@ -77,7 +77,9 @@ f_dialog_menu_media_http() f_dialog_title_restore local prompt=3D"$msg_please_select_the_site_closest_to_you_or_other" local menu_list=3D" - 'URL' '$msg_specify_some_other_http_site' + '$msg_main_site' 'http.freebsd.org' + 'URL' '$msg_specify_some_other_http_site' + 'IPv6 $msg_main_site' 'http.freebsd.org' " # END-QUOTE local hline=3D"$msg_select_a_site_thats_close" =20 Index: head/usr.sbin/bsdconfig/share/media/ftp.subr =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/usr.sbin/bsdconfig/share/media/ftp.subr (revision 253333) +++ head/usr.sbin/bsdconfig/share/media/ftp.subr (working copy) @@ -73,157 +73,7 @@ f_dialog_menu_media_ftp() f_dialog_title_restore local prompt=3D"$msg_please_select_the_site_closest_to_you_or_other" local menu_list=3D" - '$msg_main_site' 'ftp.freebsd.org' - 'URL' '$msg_specify_some_other_ftp_site' - '$msg_snapshots_server_japan' - 'snapshots.jp.freebsd.org' - '$msg_snapshots_server_sweden' - 'snapshots.se.freebsd.org' - 'IPv6 $msg_main_site' 'ftp.freebsd.org' - ' IPv6 $msg_ireland' 'ftp3.ie.freebsd.org' - ' IPv6 $msg_israel' 'ftp.il.freebsd.org' - ' IPv6 $msg_japan' 'ftp2.jp.freebsd.org' - ' IPv6 $msg_usa' 'ftp4.us.freebsd.org' - ' IPv6 $msg_turkey' 'ftp2.tr.freebsd.org' - '$msg_primary' 'ftp1.freebsd.org' - ' $msg_primary #2' 'ftp2.freebsd.org' - ' $msg_primary #3' 'ftp3.freebsd.org' - ' $msg_primary #4' 'ftp4.freebsd.org' - ' $msg_primary #5' 'ftp5.freebsd.org' - ' $msg_primary #6' 'ftp6.freebsd.org' - ' $msg_primary #7' 'ftp7.freebsd.org' - ' $msg_primary #8' 'ftp8.freebsd.org' - ' $msg_primary #9' 'ftp9.freebsd.org' - ' $msg_primary #10' 'ftp10.freebsd.org' - ' $msg_primary #11' 'ftp11.freebsd.org' - ' $msg_primary #12' 'ftp12.freebsd.org' - ' $msg_primary #13' 'ftp13.freebsd.org' - ' $msg_primary #14' 'ftp14.freebsd.org' - '$msg_argentina' 'ftp.ar.freebsd.org' - '$msg_australia' 'ftp.au.freebsd.org' - ' $msg_australia #2' 'ftp2.au.freebsd.org' - ' $msg_australia #3' 'ftp3.au.freebsd.org' - '$msg_austria' 'ftp.at.freebsd.org' - ' $msg_austria #2' 'ftp2.at.freebsd.org' - '$msg_brazil' 'ftp.br.freebsd.org' - ' $msg_brazil #2' 'ftp2.br.freebsd.org' - ' $msg_brazil #3' 'ftp3.br.freebsd.org' - ' $msg_brazil #4' 'ftp4.br.freebsd.org' - ' $msg_brazil #5' 'ftp5.br.freebsd.org' - ' $msg_brazil #6' 'ftp6.br.freebsd.org' - ' $msg_brazil #7' 'ftp7.br.freebsd.org' - '$msg_canada' 'ftp.ca.freebsd.org' - '$msg_china' 'ftp.cn.freebsd.org' - ' $msg_china #2' 'ftp2.cn.freebsd.org' - '$msg_croatia' 'ftp.hr.freebsd.org' - '$msg_czech_republic' 'ftp.cz.freebsd.org' - '$msg_denmark' 'ftp.dk.freebsd.org' - ' $msg_denmark #2' 'ftp2.dk.freebsd.org' - '$msg_estonia' 'ftp.ee.freebsd.org' - '$msg_finland' 'ftp.fi.freebsd.org' - '$msg_france' 'ftp.fr.freebsd.org' - ' $msg_france #2' 'ftp2.fr.freebsd.org' - ' $msg_france #3' 'ftp3.fr.freebsd.org' - ' $msg_france #5' 'ftp5.fr.freebsd.org' - ' $msg_france #6' 'ftp6.fr.freebsd.org' - ' $msg_france #8' 'ftp8.fr.freebsd.org' - '$msg_germany' 'ftp.de.freebsd.org' - ' $msg_germany #2' 'ftp2.de.freebsd.org' - ' $msg_germany #3' 'ftp3.de.freebsd.org' - ' $msg_germany #4' 'ftp4.de.freebsd.org' - ' $msg_germany #5' 'ftp5.de.freebsd.org' - ' $msg_germany #6' 'ftp6.de.freebsd.org' - ' $msg_germany #7' 'ftp7.de.freebsd.org' - ' $msg_germany #8' 'ftp8.de.freebsd.org' - '$msg_greece' 'ftp.gr.freebsd.org' - ' $msg_greece #2' 'ftp2.gr.freebsd.org' - '$msg_hungary' 'ftp.hu.freebsd.org' - '$msg_iceland' 'ftp.is.freebsd.org' - '$msg_ireland' 'ftp.ie.freebsd.org' - ' $msg_ireland #2' 'ftp2.ie.freebsd.org' - ' $msg_ireland #3' 'ftp3.ie.freebsd.org' - '$msg_israel' 'ftp.il.freebsd.org' - '$msg_italy' 'ftp.it.freebsd.org' - '$msg_japan' 'ftp.jp.freebsd.org' - ' $msg_japan #2' 'ftp2.jp.freebsd.org' - ' $msg_japan #3' 'ftp3.jp.freebsd.org' - ' $msg_japan #4' 'ftp4.jp.freebsd.org' - ' $msg_japan #5' 'ftp5.jp.freebsd.org' - ' $msg_japan #6' 'ftp6.jp.freebsd.org' - ' $msg_japan #7' 'ftp7.jp.freebsd.org' - ' $msg_japan #8' 'ftp8.jp.freebsd.org' - ' $msg_japan #9' 'ftp9.jp.freebsd.org' - '$msg_korea' 'ftp.kr.freebsd.org' - ' $msg_korea #2' 'ftp2.kr.freebsd.org' - '$msg_lithuania' 'ftp.lt.freebsd.org' - '$msg_netherlands' 'ftp.nl.freebsd.org' - ' $msg_netherlands #2' 'ftp2.nl.freebsd.org' - '$msg_norway' 'ftp.no.freebsd.org' - ' $msg_norway #3' 'ftp3.no.freebsd.org' - '$msg_poland' 'ftp.pl.freebsd.org' - ' $msg_poland #2' 'ftp2.pl.freebsd.org' - ' $msg_poland #5' 'ftp5.pl.freebsd.org' - '$msg_portugal' 'ftp.pt.freebsd.org' - ' $msg_portugal #2' 'ftp2.pt.freebsd.org' - ' $msg_portugal #4' 'ftp4.pt.freebsd.org' - '$msg_romania' 'ftp.ro.freebsd.org' - '$msg_russia' 'ftp.ru.freebsd.org' - ' $msg_russia #2' 'ftp2.ru.freebsd.org' - ' $msg_russia #3' 'ftp3.ru.freebsd.org' - ' $msg_russia #4' 'ftp4.ru.freebsd.org' - '$msg_singapore' 'ftp.sg.freebsd.org' - '$msg_slovak_republic' 'ftp.sk.freebsd.org' - '$msg_slovenia' 'ftp.si.freebsd.org' - ' $msg_slovenia #2' 'ftp2.si.freebsd.org' - '$msg_south_africa' 'ftp.za.freebsd.org' - ' $msg_south_africa #2' 'ftp2.za.freebsd.org' - ' $msg_south_africa #3' 'ftp3.za.freebsd.org' - ' $msg_south_africa #4' 'ftp4.za.freebsd.org' - '$msg_spain' 'ftp.es.freebsd.org' - ' $msg_spain #2' 'ftp2.es.freebsd.org' - ' $msg_spain #3' 'ftp3.es.freebsd.org' - '$msg_sweden' 'ftp.se.freebsd.org' - ' $msg_sweden #2' 'ftp2.se.freebsd.org' - ' $msg_sweden #3' 'ftp3.se.freebsd.org' - ' $msg_sweden #4' 'ftp4.se.freebsd.org' - ' $msg_sweden #5' 'ftp5.se.freebsd.org' - '$msg_switzerland' 'ftp.ch.freebsd.org' - ' $msg_switzerland #2' 'ftp2.ch.freebsd.org' - '$msg_taiwan' 'ftp.tw.freebsd.org' - ' $msg_taiwan #2' 'ftp2.tw.freebsd.org' - ' $msg_taiwan #3' 'ftp3.tw.freebsd.org' - ' $msg_taiwan #4' 'ftp4.tw.freebsd.org' - ' $msg_taiwan #6' 'ftp6.tw.freebsd.org' - ' $msg_taiwan #11' 'ftp11.tw.freebsd.org' - '$msg_turkey' 'ftp.tr.freebsd.org' - ' $msg_turkey #2' 'ftp2.tr.freebsd.org' - '$msg_uk' 'ftp.uk.freebsd.org' - ' $msg_uk #2' 'ftp2.uk.freebsd.org' - ' $msg_uk #3' 'ftp3.uk.freebsd.org' - ' $msg_uk #4' 'ftp4.uk.freebsd.org' - ' $msg_uk #5' 'ftp5.uk.freebsd.org' - ' $msg_uk #6' 'ftp6.uk.freebsd.org' - '$msg_ukraine' 'ftp.ua.freebsd.org' - ' $msg_ukraine #2' 'ftp2.ua.freebsd.org' - ' $msg_ukraine #5' 'ftp5.ua.freebsd.org' - ' $msg_ukraine #6' 'ftp6.ua.freebsd.org' - ' $msg_ukraine #7' 'ftp7.ua.freebsd.org' - ' $msg_ukraine #8' 'ftp8.ua.freebsd.org' - '$msg_usa #1' 'ftp1.us.freebsd.org' - ' $msg_usa #2' 'ftp2.us.freebsd.org' - ' $msg_usa #3' 'ftp3.us.freebsd.org' - ' $msg_usa #4' 'ftp4.us.freebsd.org' - ' $msg_usa #5' 'ftp5.us.freebsd.org' - ' $msg_usa #6' 'ftp6.us.freebsd.org' - ' $msg_usa #7' 'ftp7.us.freebsd.org' - ' $msg_usa #8' 'ftp8.us.freebsd.org' - ' $msg_usa #9' 'ftp9.us.freebsd.org' - ' $msg_usa #10' 'ftp10.us.freebsd.org' - ' $msg_usa #11' 'ftp11.us.freebsd.org' - ' $msg_usa #12' 'ftp12.us.freebsd.org' - ' $msg_usa #13' 'ftp13.us.freebsd.org' - ' $msg_usa #14' 'ftp14.us.freebsd.org' - ' $msg_usa #15' 'ftp15.us.freebsd.org' + 'URL' '$msg_specify_some_other_ftp_site' " # END-QUOTE local hline=3D"$msg_select_a_site_thats_close" =20 --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 09:31:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4C3ECD13; Sun, 14 Jul 2013 09:31:06 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id AD953AE0; Sun, 14 Jul 2013 09:31:05 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id r6E9V0JH024497 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 10:31:00 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk r6E9V0JH024497 Authentication-Results: smtp.infracaninophile.co.uk/r6E9V0JH024497; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy) Message-ID: <51E26FD3.4020208@FreeBSD.org> Date: Sun, 14 Jul 2013 10:30:59 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E0D@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC4E0D@ltcfiswmsgmb21> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2UXUFXREROJBCALBTEAXG" X-Virus-Scanned: clamav-milter 0.97.8 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_FAIL, SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Baptiste Daroussin , "Teske, Devin" , Peter Wemm , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 09:31:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UXUFXREROJBCALBTEAXG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14/07/2013 06:48, Teske, Devin wrote: > Question: Where can I learn more about the actual format of what's in > the new tarballs? This is going to be important not for bsdconfig, > but $work (we have our own build platform; I'm going to have to > rewrite it from mastering PLIST files to mastering YAML MANIFEST > files and I want to know all the gritty details). We do need a pkg-manifest(5) man page, which can double as a pkg-tarball(5) page since the manifest file is where most of the interesting bits are. A pkg tarball is a compressed tar archive like so: lucid-nonsense:...cache/pkg/All:% tar -tvf pkg-1.1.4.txz -rw-r--r-- 0 root wheel 530 Jan 1 1970 +COMPACT_MANIFEST -rw-r--r-- 0 root wheel 6385 Jan 1 1970 +MANIFEST -rw-r--r-- 0 root wheel 17567 Jan 1 1970 +MTREE_DIRS -r--r--r-- 0 root wheel 19453 Jul 7 12:26 /usr/local/etc/bash_completion.d/_pkg.bash -r-xr-xr-x 0 root wheel 629 Jul 7 12:26 /usr/local/etc/periodic/daily/400.status-pkg -r-xr-xr-x 0 root wheel 823 Jul 7 12:26 /usr/local/etc/periodic/daily/411.pkg-backup -r-xr-xr-x 0 root wheel 678 Jul 7 12:26 /usr/local/etc/periodic/daily/490.status-pkg-changes -r-xr-xr-x 0 root wheel 2558 Jul 7 12:26 /usr/local/etc/periodic/security/410.pkg-audit -r-xr-xr-x 0 root wheel 611 Jul 7 12:26 /usr/local/etc/periodic/security/460.pkg-checksum -r--r--r-- 0 root wheel 839 Jul 7 12:26 /usr/local/etc/pkg.conf.sample -r--r--r-- 0 root wheel 43432 Jul 7 12:26 /usr/local/include/pkg.h -r--r--r-- 0 root wheel 727558 Jul 7 12:26 /usr/local/lib/libpkg.a lrwxr-xr-x 0 root wheel 0 Jul 7 12:26 /usr/local/lib/libpkg.so -> libpkg.so.1 -r--r--r-- 0 root wheel 1227064 Jul 7 12:26 /usr/local/lib/libpkg.so.= 1 -rw-r--r-- 0 root wheel 187 Jul 7 12:26 /usr/local/libdata/pkgconfig/pkg.pc [... etc ...] There must at least be a +MANIFEST -- other meta data files are optional. +COMPACT_MANIFEST is a subset of the full +MANIFEST. They're both YAML documents. +COMPACT_MANIFEST looks like this, for example: --- name: pkg version: 1.1.4 origin: ports-mgmt/pkg comment: New generation package manager arch: freebsd:9:x86:64 www: http://wiki.freebsd.org/pkgng maintainer: portmgr@FreeBSD.org prefix: /usr/local licenselogic: single licenses: - BSD flatsize: 6311507 desc: | New Generation package management tool for FreeBSD WWW: http://wiki.freebsd.org/pkgng categories: - ports-mgmt shlibs_required: - libpkg.so.1 shlibs_provided: - libpkg.so.1 message: | If you are upgrading from the old package format, first run: # pkg2ng +MTREE_DIRS is a compatibility thing with the old pkg_tools. It's not needed in general as +MANIFEST can provide all that meta data itself. It isn't going to be deprecated for at least as long as the ports tree continues to support pkg_tools though. Beyond that, the rest of the pkg tarball just contains a tar archive of all the files, directories, sym-links etc to be installed by the package. Note that pkg(8) has no problem with creating an empty directory for a package, unlike pkg_tools. Now, while you can grovel through the details of pkg tarballs and internal data formats like this, be aware: the format of the manifest and the details of the meta-data included in the pkg-tarballs is subject to change without warning as we develop pkg(8) further. We only promise API stability through the pkg(8) commands or for the libpkg.so library functions; reports of breakage from usage outside those APIs will receive little sympathy. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey ------enig2UXUFXREROJBCALBTEAXG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHib9MACgkQ8Mjk52CukIyf4ACdGb7Oik3jYlO2kx0prlCpHx2T twIAnjhOaHxL6G1se3F9ilhUTALQftXE =qweq -----END PGP SIGNATURE----- ------enig2UXUFXREROJBCALBTEAXG-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 10:12:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D3AA242; Sun, 14 Jul 2013 10:12:21 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5006FBE2; Sun, 14 Jul 2013 10:12:21 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r6EACKRK021768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 05:12:20 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 05:12:19 -0500 From: "Teske, Devin" To: Matthew Seaman Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAnyqAgAAXnwCAAD4lgIAAC4sA Date: Sun, 14 Jul 2013 10:12:19 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC547A@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E0D@ltcfiswmsgmb21> <51E26FD3.4020208@FreeBSD.org> In-Reply-To: <51E26FD3.4020208@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2BC6EED7240B1440985D4D176E20F3BB@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Baptiste Daroussin , Devin Teske , "current@FreeBSD.org" , Peter Wemm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 10:12:21 -0000 On Jul 14, 2013, at 2:30 AM, Matthew Seaman wrote: > On 14/07/2013 06:48, Teske, Devin wrote: >> Question: Where can I learn more about the actual format of what's in >> the new tarballs? This is going to be important not for bsdconfig, >> but $work (we have our own build platform; I'm going to have to >> rewrite it from mastering PLIST files to mastering YAML MANIFEST >> files and I want to know all the gritty details). >=20 > We do need a pkg-manifest(5) man page, which can double as a > pkg-tarball(5) page since the manifest file is where most of the > interesting bits are. >=20 > A pkg tarball is a compressed tar archive like so: >=20 > lucid-nonsense:...cache/pkg/All:% tar -tvf pkg-1.1.4.txz > -rw-r--r-- 0 root wheel 530 Jan 1 1970 +COMPACT_MANIFEST > -rw-r--r-- 0 root wheel 6385 Jan 1 1970 +MANIFEST > -rw-r--r-- 0 root wheel 17567 Jan 1 1970 +MTREE_DIRS > -r--r--r-- 0 root wheel 19453 Jul 7 12:26 > /usr/local/etc/bash_completion.d/_pkg.bash > -r-xr-xr-x 0 root wheel 629 Jul 7 12:26 > /usr/local/etc/periodic/daily/400.status-pkg > -r-xr-xr-x 0 root wheel 823 Jul 7 12:26 > /usr/local/etc/periodic/daily/411.pkg-backup > -r-xr-xr-x 0 root wheel 678 Jul 7 12:26 > /usr/local/etc/periodic/daily/490.status-pkg-changes > -r-xr-xr-x 0 root wheel 2558 Jul 7 12:26 > /usr/local/etc/periodic/security/410.pkg-audit > -r-xr-xr-x 0 root wheel 611 Jul 7 12:26 > /usr/local/etc/periodic/security/460.pkg-checksum > -r--r--r-- 0 root wheel 839 Jul 7 12:26 > /usr/local/etc/pkg.conf.sample > -r--r--r-- 0 root wheel 43432 Jul 7 12:26 /usr/local/include/pkg.h > -r--r--r-- 0 root wheel 727558 Jul 7 12:26 /usr/local/lib/libpkg.a > lrwxr-xr-x 0 root wheel 0 Jul 7 12:26 /usr/local/lib/libpkg.so > -> libpkg.so.1 > -r--r--r-- 0 root wheel 1227064 Jul 7 12:26 /usr/local/lib/libpkg.so.1 > -rw-r--r-- 0 root wheel 187 Jul 7 12:26 > /usr/local/libdata/pkgconfig/pkg.pc > [... etc ...] >=20 Interesting. I notice that (while looking ahead to see a prefix: of /usr/lo= cal in the +MANIFEST), the tarball itself has files that include /usr/local= in their path. Does pkg handle packages where the prefix (in +MANIFEST) is "/usr/local" _b= ut_ "tar tf" of the unxz'd tarball is _not_ "/usr/local"? (e.g. pkg_install= style) or is this the new way going forward? > There must at least be a +MANIFEST -- other meta data files are > optional. +COMPACT_MANIFEST is a subset of the full +MANIFEST. They're > both YAML documents. +COMPACT_MANIFEST looks like this, for example: >=20 > --- > name: pkg > version: 1.1.4 > origin: ports-mgmt/pkg > comment: New generation package manager > arch: freebsd:9:x86:64 > www: https://urldefense.proofpoint.com/v1/url?u=3Dhttp://wiki.freebsd.org= /pkgng&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJ= jg%3D%3D%0A&m=3DLPoff3ddLDoHE30AU6R5vgBklqxsjVAosXGjJop6uO4%3D%0A&s=3D30b27= cf33d7e594144fc38f20bc75d84464788e715f7fc82b2495f813fd4be2d > maintainer: portmgr@FreeBSD.org > prefix: /usr/local > licenselogic: single > licenses: > - BSD > flatsize: 6311507 > desc: | > New Generation package management tool for FreeBSD >=20 > WWW: http://wiki.freebsd.org/pkgng > categories: > - ports-mgmt > shlibs_required: > - libpkg.so.1 > shlibs_provided: > - libpkg.so.1 > message: | > If you are upgrading from the old package format, first run: >=20 > # pkg2ng >=20 Nice. Very nice. > +MTREE_DIRS is a compatibility thing with the old pkg_tools. It's not > needed in general as +MANIFEST can provide all that meta data itself. > It isn't going to be deprecated for at least as long as the ports tree > continues to support pkg_tools though. >=20 > Beyond that, the rest of the pkg tarball just contains a tar archive of > all the files, directories, sym-links etc to be installed by the > package. Note that pkg(8) has no problem with creating an empty > directory for a package, unlike pkg_tools. >=20 Excellent! > Now, while you can grovel through the details of pkg tarballs and > internal data formats like this, be aware: the format of the manifest > and the details of the meta-data included in the pkg-tarballs is subject > to change without warning as we develop pkg(8) further. We only promise > API stability through the pkg(8) commands or for the libpkg.so library > functions; reports of breakage from usage outside those APIs will > receive little sympathy. >=20 Understood. So just to give you a better idea of how we manage packages here. We've realized that if you want to package for FreeBSD (in 9 and older), yo= u could get by alright if you knew how to create a +CONTENTS file from scra= tch. For RedHat, it's the SPECFILE. And now for FreeBSD 10, it looks an awf= ul lot like a SPECFILE (they are both in-fact YAML). So rather than teach the people here how to use tools, I taught them what I= think is more important... how to manage +CONTENTS, SPECFILE, and now up-a= nd-coming, +MANIFEST. However, I'd be lying if I said I taught them *all* the gory details. In re= ality, for +CONTENTS they edit a PLIST which is essentially +CONTENTS witho= ut the "@comment MD5:" entries. For SPECFILE, they manage the full thing ex= cept there's a small section that is the standard RPM bootstrap that is lab= eled as "do not touch". >From what you posted of +COMPACT_MANIFEST was nice, except it lacks the lis= t of files. The basic principle here is that if you have to maintain a list of files, a= nd that list ends up being compiled into a +MANIFEST, why not just teach yo= ur peers how to read/write/maintain +MANIFEST files (in version control of = course) so that there are never any mysteries as to how the package perform= s. I know this sounds screwy... but (as with our other YAML files), it's reall= y nice because (as is the case with SPECFILE), we version-control things as= -close to the end-product as possible (take for example the case of "pre-in= stall" or "post-install" et cetera scripts -- I'm sure a tool like "pkg cre= ate" or "pkg_create" or other could do a good job of assembling the pieces = into the +MANIFEST, but then it's not being version-controlled as closely. Before this workflow, mistakes were rampant and there wasn't much hope of w= rangling the "oops, forgot to touch the PLIST" or "oops, forgot to update t= he post-install script" mistakes. I see a nice bright future in re-working my "pkgbase" to be able to supplan= t metadata into a revision-controlled +MANIFEST. Ideally, I don't want them to have to be burdened with maintaining both a += MANIFEST and +COMPACT_MANIFEST, so it seems most logical to generate one fr= om the other (the latter being the revision-controlled copy sans-meta-data;= the meta-data is added at "make" time before then running validations and = generating the tarball). The problem of breakage to the system by API changes is less important, bec= ause we track security releng branches and use binaries so changes are very= slow to creep in. But since *can* use a different framework for each/every= major release branch, we can track API changes quite easily. I'm aware that only slow moving dinosaurs like us are interested in such ba= ckward-thinking mechanics... but this stuff really works for us, and I'm ce= rtain that digesting +MANIFEST will be very beneficial to our growth. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 10:34:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2DF4730 for ; Sun, 14 Jul 2013 10:34:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id BD287C71 for ; Sun, 14 Jul 2013 10:34:49 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro2so10392061pbb.41 for ; Sun, 14 Jul 2013 03:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=KW/rHodNdZwhnv5qp11dSspTJ3gr2bveRy3lpmeu1R4=; b=GsAmmACBBe9gHv6avikVUSqWKmq+5pRJ7L1r/0mLnoXvsmpUqzeJaSej+bMNaGQ25k EYe25RGN0tMeunxnDw+/mQ6Wnsn9QwP9ImSX/qnXYo+rM0W+n+B3gBFhIkQK/b2ijmQr HHe3PuR5n2Hrhy6+Ib/jID2cDnUS2W5kiKeEBKUZ+JeaeCmwejSFAyh8XC0LkYWQ1Kks NtP8SVeRu0p5juuQ+2gaCKOF3vsQlJiiETDXbBNReo6pkwXhukYudO7/1VgI9QzMZ+Wi T90FDGZrSCZzCLkTfKZSdl0kTawr0B/zVB++ufAiyDlj3pFf2skQOU9rMgr4PIAckGJe WJaQ== X-Received: by 10.68.96.229 with SMTP id dv5mr28740713pbb.89.1373798089582; Sun, 14 Jul 2013 03:34:49 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id br1sm54997234pbb.4.2013.07.14.03.34.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 03:34:48 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 14 Jul 2013 19:34:44 +0900 From: Yonghyeon PYUN Date: Sun, 14 Jul 2013 19:34:44 +0900 To: Denis D Subject: Re: msk0 watchdog timeout and interrupt storm Message-ID: <20130714103444.GB1105@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 10:34:50 -0000 On Sat, Jul 13, 2013 at 01:39:06PM +0200, Denis D wrote: > > If you use dual-boot, please try "cold-boot" it. Other OS may have > > > > put the PHY into weird state. Cold-boot shall make firmware restore > > > > its PHY configuration. > > > > > > > > > > Hello pyunyh, > > > > > when i really understand the word coldbootkorrekt,it means, that i have to shutdown my pc. > And start it (during he was off) and boot into FreeBSD. > > > > > My PC was off for 9 hours because of work, but still the same "watchdog timeout" error. Did you completely remove power-cord and wait 1 ~ 2 min. before boot? There are many Yukon II variants and each controller seems to require special handling to work-around silicon bugs. And your controller has a Audio Video Bridging (AVB) feature which may or may not need a special handling in TX/RX path. At least it may need to initialize or disable QoS specific feature of controller, I guess. Unfortunately errata or detailed programming information is not available to open source developers. Interrupt storm seems to indicate one of important event was not properly handled in driver. Not sure what it is. > > > > > Maybe some other solutions? Sorry, have no further idea at this moment. I hoped cold-boot shall put controller into compatible mode but it seems it does not. I'll let you know if I happen to find a clue. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 06:13:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F3C2794; Sun, 14 Jul 2013 06:13:57 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id B933F65B; Sun, 14 Jul 2013 06:13:56 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r6E6DsTS002017; Sun, 14 Jul 2013 02:13:54 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r6E6Dsov002016; Sun, 14 Jul 2013 02:13:54 -0400 (EDT) (envelope-from wollman) Date: Sun, 14 Jul 2013 02:13:54 -0400 (EDT) From: Garrett Wollman Message-Id: <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> To: dteske@freebsd.org Subject: Re: [HEADSUP] No more pkg_install on HEAD by default X-Newsgroups: mit.lcs.mail.freebsd-current In-Reply-To: <20130714054840$7f8f@grapevine.csail.mit.edu> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 14 Jul 2013 02:13:55 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,LOTS_OF_MONEY autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 14 Jul 2013 11:22:20 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 06:13:57 -0000 In article <20130714054840$7f8f@grapevine.csail.mit.edu>, dteske@freebsd.org writes: >How about rquery? What protocol does that use? and what does it talk to? It accesses the sqlite database in /var/db/pkg that was previously retrieved from the remote repository. >Question: Where can I learn more about the actual format of what's in >the new tarballs? This is going to be important not for bsdconfig, but >$work (we have our own build platform; I'm going to have to rewrite it >from mastering PLIST files to mastering YAML MANIFEST files and I want >to know all the gritty details). You really shouldn't know about the actual format of the tarballs; your time would be better spent learning the new "pkg create", "pkg register", and "pkg repo" commands. Depending on your needs, you might want to write to the libpkg API instead. -GAWollman From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 11:25:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 54D74D8F; Sun, 14 Jul 2013 11:25:35 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id B66B2D8B; Sun, 14 Jul 2013 11:25:34 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id r6EBPNiu026095 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 12:25:23 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk r6EBPNiu026095 Authentication-Results: smtp.infracaninophile.co.uk/r6EBPNiu026095; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy) Message-ID: <51E28A99.5000904@FreeBSD.org> Date: Sun, 14 Jul 2013 12:25:13 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E0D@ltcfiswmsgmb21> <51E26FD3.4020208@FreeBSD.org> <13CA24D6AB415D428143D44749F57D7201FC547A@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC547A@ltcfiswmsgmb21> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2SGGEWPOMTGXFIDTLLKGF" X-Virus-Scanned: clamav-milter 0.97.8 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_FAIL, SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Baptiste Daroussin , "Teske, Devin" , Peter Wemm , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 11:25:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SGGEWPOMTGXFIDTLLKGF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14/07/2013 11:12, Teske, Devin wrote: > Interesting. I notice that (while looking ahead to see a prefix: of > /usr/local in the +MANIFEST), the tarball itself has files that include= > /usr/local in their path. Yes -- we consider the $PREFIX to be 'baked into' the package at compile time. You can relocate a package to some extent at installation time -- so for instance you can install into a jail or chroot from outside it -- but the software would expect all the files to be arranged as shown in the package at runtime. > Does pkg handle packages where the prefix (in +MANIFEST) is > "/usr/local" _but_ "tar tf" of the unxz'd tarball is _not_ "/usr/local"= ? > (e.g. pkg_install style) or is this the new way going forward? No -- it always wants a fully qualified path there. > So just to give you a better idea of how we manage packages here. >=20 > We've realized that if you want to package for FreeBSD (in 9 and > older), you could get by alright if you knew how to create a > +CONTENTS file from scratch. For RedHat, it's the SPECFILE. And now > for FreeBSD 10, it looks an awful lot like a SPECFILE (they are both > in-fact YAML). >=20 > So rather than teach the people here how to use tools, I taught them > what I think is more important... how to manage +CONTENTS, SPECFILE, > and now up-and-coming, +MANIFEST. >=20 > However, I'd be lying if I said I taught them *all* the gory details. > In reality, for +CONTENTS they edit a PLIST which is essentially > +CONTENTS without the "@comment MD5:" entries. For SPECFILE, they > manage the full thing except there's a small section that is the > standard RPM bootstrap that is labeled as "do not touch". >=20 > From what you posted of +COMPACT_MANIFEST was nice, except it lacks > the list of files. There's actually two lists: files and directories. The principle difference being that the files list contains SHA256 checksums of each file. (Although the files list does also contain sym-links etc, which don't have a checksum). There are other data in the full manifest but not in the compact one -- pre- and post- installation or deinstallation scripts are the most important bits not yet mentioned. > The basic principle here is that if you have to maintain a list of > files, and that list ends up being compiled into a +MANIFEST, why not > just teach your peers how to read/write/maintain +MANIFEST files (in > version control of course) so that there are never any mysteries as > to how the package performs. >=20 > I know this sounds screwy... but (as with our other YAML files), it's > really nice because (as is the case with SPECFILE), we > version-control things as-close to the end-product as possible (take > for example the case of "pre-install" or "post-install" et cetera > scripts -- I'm sure a tool like "pkg create" or "pkg_create" or other > could do a good job of assembling the pieces into the +MANIFEST, but > then it's not being version-controlled as closely. Actually, 'pkg create' basically takes the manifest and uses it to build the package. It has a special mode to combine data as presented during ports compilation into a manifest -- again, this is a compatibility thing. If the ports didn't have to support pkg_tools still we could generate package metadata more directly in the format needed by the manifest. > Before this workflow, mistakes were rampant and there wasn't much > hope of wrangling the "oops, forgot to touch the PLIST" or "oops, > forgot to update the post-install script" mistakes. >=20 > I see a nice bright future in re-working my "pkgbase" to be able to > supplant metadata into a revision-controlled +MANIFEST. >=20 > Ideally, I don't want them to have to be burdened with maintaining > both a +MANIFEST and +COMPACT_MANIFEST, so it seems most logical to > generate one from the other (the latter being the revision-controlled > copy sans-meta-data; the meta-data is added at "make" time before > then running validations and generating the tarball). Internally, the +COMPACT_MANIFEST is generated from the +MANIFEST -- probably best to think in terms of dividing the manifest into sections, some of which (lists of files, install scripts) your dev people would actively modify, some of which can be automatically generated by pkg(8) (shlib provides/requires tracking[*]) and the rest as static boilerplate you can just paste together as required to create a manifest. [*] Actually, this is automatically generated at the time the package is assembled into a tarball. You don't need to fill in that section of the manifest eplicitly. > The problem of breakage to the system by API changes is less > important, because we track security releng branches and use binaries > so changes are very slow to creep in. But since *can* use a different > framework for each/every major release branch, we can track API > changes quite easily. Ah. Remember that pkg(8) isn't part of the base system and is developed on a timetable independent of the timetable used by FreeBSD itself. When we release a new version of pkg, it would be applied simultaneously on all branches and supported releases. Of course, if you have your own private repository system you can control the version of pkg supplied by = it. > I'm aware that only slow moving dinosaurs like us are interested in > such backward-thinking mechanics... but this stuff really works for > us, and I'm certain that digesting +MANIFEST will be very beneficial > to our growth. One of our aims when developing pkg(8) has been to make it possible to have as much or as little interaction with the official FreeBSD package building clusters as you want. You could use official packages exclusively; or you could create a repo containing just the software packages crucial to you with local customizations, and install the rest from the official repos; or you can build everything yourself. Finally, it should be possible for companies or software projects to release just their own software in pkg(8) format, and for an administrator to select that for installation on their system rather than the default version (if any) from ports. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey ------enig2SGGEWPOMTGXFIDTLLKGF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHiiqIACgkQ8Mjk52CukIynrACdHRBC50/4JNsl1eVdpzZcZi3b UaAAnjvKmaZ2bSKzxC6vtkZY4nqU0HVd =GSQd -----END PGP SIGNATURE----- ------enig2SGGEWPOMTGXFIDTLLKGF-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 07:06:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D370D65; Sun, 14 Jul 2013 07:06:22 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id D35937C5; Sun, 14 Jul 2013 07:06:21 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r6E76K2E002960; Sun, 14 Jul 2013 03:06:20 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r6E76Kg0002959; Sun, 14 Jul 2013 03:06:20 -0400 (EDT) (envelope-from wollman) Date: Sun, 14 Jul 2013 03:06:20 -0400 (EDT) From: Garrett Wollman Message-Id: <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> To: dteske@freebsd.org Subject: Re: [HEADSUP] No more pkg_install on HEAD by default In-Reply-To: <20130714064601$3ce5@grapevine.csail.mit.edu> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 14 Jul 2013 03:06:20 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,LOTS_OF_MONEY autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 14 Jul 2013 11:33:19 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 07:06:22 -0000 In article <20130714064601$3ce5@grapevine.csail.mit.edu>, dteske@freebsd.org writes: >> [I wrote:] >> It accesses the sqlite database in /var/db/pkg that was previously >> retrieved from the remote repository. >Now from what you explained of pkg, I'm worried that for bsdconfig: > >1. Browse packages (nothing else) >2. Exit bsdconfig > >and now because the "pkg rquery" has staged a db, future "pkg" commands >are now influenced. Only if you update /usr/local/etc/pkg.conf to set a permanent PACKAGESITE. Otherwise, it will notice that the remote repo catalog you have isn't for your currently selected remote repo, and use that instead. >> You really shouldn't know about the actual format of the tarballs; >> your time would be better spent learning the new "pkg create", "pkg >> register", and "pkg repo" commands. Depending on your needs, you >> might want to write to the libpkg API instead. >That won't work for us. > >You're not going to like the answer, but it does mean that things like >"pkg create", "pkg register" and "pkg repo" won't work for us. Congratulations for building your entire workflow around a horrible kluge straight out of 1993. FreeBSD, however, is moving on. (And it's long past time!) Your developers will just have to deal. Or you can maintain the old cruft for your business -- just don't expect anyone else to use it, or even want to. -GAWollman From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 15:52:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D87F059D for ; Sun, 14 Jul 2013 15:52:51 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 75A8A6EF for ; Sun, 14 Jul 2013 15:52:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id DF5702A832A8 for ; Sun, 14 Jul 2013 17:52:42 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXUBeS1Tr1eq for ; Sun, 14 Jul 2013 17:52:42 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id AC4E02A83282 for ; Sun, 14 Jul 2013 17:52:41 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UyObF-0000Rh-P5 for current@freebsd.org; Sun, 14 Jul 2013 17:52:37 +0200 To: current@freebsd.org Subject: Ports with daemons on uninstall... From: "Ian FREISLICH" X-Attribution: BOFH Date: Sun, 14 Jul 2013 17:52:37 +0200 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 15:52:51 -0000 Hi I have to ask if there's a standard for the way ports should handle their daemons when the port is uninstalled. I've encountered 3 varients of ports behaviour on uninstall: 1. Do nothing 2. Stop the daemon 3. Ask if the daemon should be stopped #1 closely followed by #3 are the least irritating when it comes to portupgrade because you can at least have the service running while upgrading. At least with #3 the upgrade gets paused until the propmpt is answered and you're then aware that some service will go away immediately so you can be prepared to restart it. #2 is extremely irritating because upgrading with portupgrade etc kills the service. For instance isc-dhcpd* does this which means that for some time, dhcp may be unavailable. It could be less irritating if it would automatically start the service, but that can have its own problems. Does the project have a preferred method for handling running daenmons on uninstall? I know that Linux will even start daemons on install. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 16:16:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 80AC69D2 for ; Sun, 14 Jul 2013 16:16:00 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by mx1.freebsd.org (Postfix) with ESMTP id 17C237E5 for ; Sun, 14 Jul 2013 16:15:59 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id h10so7306182eaj.29 for ; Sun, 14 Jul 2013 09:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ISGO2GFvdlpwE/VE4NBDUZnwksJK4ASI2icJgnWDS/8=; b=B/UHajU/GY8BOO5DFMtpdNTDh5o8eqPp0x5Kdvc4kVubpuYhyf63pvx8yw6B4onTDj JPn16TEU+AUhkqc/9PCuwvuFdKnje+fPqC+H5iZggkg5O1bfe5oBeQkO37Lxklj/RbPB WSSv0/UhAM+x23NTOoOSlFTAV9jxWUvLU4/ISmljpI3i09RnqpiR/EE3YefFXBrurZCT 5Tc1AflIlj8xFmUL5g91T3bdAVSIkMCDFxzG486z5n3tn2RRI++1cF3Eg1tjHjE8SMxZ eTZiWBQrTYvJteSIuSii7pPHEC9NurrHZMFlA3tcDdPpBe9fSRog8RZf3XtAz7IxEXCy rTbw== X-Received: by 10.15.24.129 with SMTP id j1mr55748615eeu.17.1373818559011; Sun, 14 Jul 2013 09:15:59 -0700 (PDT) Received: from phenom.cordula.ws (p5DDDA70D.dip0.t-ipconnect.de. [93.221.167.13]) by mx.google.com with ESMTPSA id b7sm95616513eef.16.2013.07.14.09.15.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 09:15:58 -0700 (PDT) Message-ID: <51E2CEB8.80909@cordula.ws> Date: Sun, 14 Jul 2013 18:15:52 +0200 From: cpghost User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130711 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: lost my r2xxxxx subversion id in uname & kern.version References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkNIqinIvhmixG0+71TpfzNbXC3DrytGDRP5L6l2hCol2crVHD+f9vUVdXFrAbCxF7V9LU+ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 16:16:00 -0000 On 07/13/13 03:03, Dan Mack wrote: > I'm not sure exactly when but recently I've lost the subversion id > from kern.version and hence uname and motd. > > Subsequent fresh rebuilds from source don't bring it back even after > wiping out the tree. > > Today it looks like this: > > root@olive:~ # uname -a > FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri > Jul 12 19:38:24 CDT 2013 > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 > root@olive:~ # sysctl kern.version > kern.version: FreeBSD 10.0-CURRENT #0: Fri Jul 12 19:38:24 CDT 2013 > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN > > Previously it would have '#0 r253307' in it's place. > > This only happened on 1 of 3 build machines. There was an update to subversion recently (1.7.x to 1.8.y). If you updated the /usr/src tree with the new subversion (i.e. svn upgrade; svn update), and then transferred that tree to another machine that contains a non-upgraded subversion client, if you build the tree there, you'll miss the r###### in uname. Upgrade your subversion client on the target machine, and, optionally, run 'svn upgrade' on the source tree, then rebuild and reinstall. uname -a should show r###### again. > dan -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 16:42:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9CAB527F for ; Sun, 14 Jul 2013 16:42:04 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 764AB8BF for ; Sun, 14 Jul 2013 16:42:04 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so24129647ieb.38 for ; Sun, 14 Jul 2013 09:42:04 -0700 (PDT) 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=k1Rkkv/oSqcCqVlK8jw8Ik3vlDlkvnA6Ah/dZ3BeDd0=; b=m2EvFCPfz9ajK0DbYGDMHy7SIbIG8nNaaOD3E5y8NDObT4ZLo4kVN0fI7AAF0PpMbm B8ctFi3zGenNLoUmu7FyfKtbn3BDlti5wvkCK1G9mw/iyk1Hnfp7R1VDwgfHOhTrmN6K Er/zdA0/qJFqkRDl6nV77t1V3DiU/UxSEFAEKUyKVOtZYztjucfF9JsMGbsRWZysQs1H fkPW4Gxfiw0oUN/s6u3BXiZKZ62hCkdm3BEgXcRZi/6MrpBuo1FAjfHtEq1NMLQ0JTLy TLED2wFMgmpgEP0vr7xF63qRqcOvlB7ZeiiBjsVmOj+v0VR2eCufyMS2u066xdzG7rKy xA1A== MIME-Version: 1.0 X-Received: by 10.43.67.73 with SMTP id xt9mr16006650icb.99.1373820124163; Sun, 14 Jul 2013 09:42:04 -0700 (PDT) Received: by 10.50.221.179 with HTTP; Sun, 14 Jul 2013 09:42:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Jul 2013 11:42:04 -0500 Message-ID: Subject: Re: Ports with daemons on uninstall... From: Scot Hetzel To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 16:42:04 -0000 On Sun, Jul 14, 2013 at 10:52 AM, Ian FREISLICH wrote: > Hi > > I have to ask if there's a standard for the way ports should handle > their daemons when the port is uninstalled. > > I've encountered 3 varients of ports behaviour on uninstall: > > 1. Do nothing > 2. Stop the daemon > 3. Ask if the daemon should be stopped > > #1 closely followed by #3 are the least irritating when it comes > to portupgrade because you can at least have the service running > while upgrading. At least with #3 the upgrade gets paused until > the propmpt is answered and you're then aware that some service > will go away immediately so you can be prepared to restart it. > > #2 is extremely irritating because upgrading with portupgrade etc > kills the service. For instance isc-dhcpd* does this which means > that for some time, dhcp may be unavailable. It could be less > irritating if it would automatically start the service, but that > can have its own problems. > > Does the project have a preferred method for handling running > daenmons on uninstall? I know that Linux will even start daemons > on install. > Personally, I prefer that when uninstalling a port, that the daemon gets stopped. But if you are upgrading a port, then you will want the daemon to be re-started. This should be possible with the new pkg tools, but I don't know if it is implemented: pkg install isc-dhcpd42-server - pkg installs the port doesn't start service - admin starts service with /usr/local/etc/rc.d/isc-dhcpd start pkg upgrade isc-dhcp42-server - pkg checks the repository and finds a new version and asks if you want it installed - pkg checks if the service(s) is running, saves the status for later - pkg uninstalls the old port - pkg installs the new port - pkg checks the saved status to see if it needs to restart the service(s) pkg uninstall isc-dhcpd42-server - pkg uninstalls the port and stops the service if running -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 16:52:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0ED259A; Sun, 14 Jul 2013 16:52:40 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B52A2925; Sun, 14 Jul 2013 16:52:40 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r6EGqRvN005046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 11:52:27 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 11:52:26 -0500 From: "Teske, Devin" To: Chris Rees Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOgGCkEhI/XtjETUan8/QjEhM8pplkGukAgAB+HwCAAB8QgA== Date: Sun, 14 Jul 2013 16:52:26 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> In-Reply-To: <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <0239E054A3543B45B7FB637C12DF9712@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Devin Teske , Garrett Wollman , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 16:52:41 -0000 On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: > On 14 Jul 2013, at 08:29, Teske, Devin wrote: >>=20 >> To give you an idea as to just how helpful this is... >>=20 >> Imagine the following hierarchy: >>=20 >> src/pkgbase/depend/mystuff/script1 >> src/pkgbase/depend/mystuff/textfile1 >> src/pkgbase/depend/mystuff/sourcefile.c >> src/pkgbase/depend/mystuff/Makefile >>=20 >> You are a developer. You want to ship a package that contains "script1",= "textfile1", and "binary1" (which is compiled by saying "make" to turn "so= urcefile.c" into "binary1") >>=20 >> You want to ship 8 types of packages: >>=20 >> FreeBSD-4.11 >> FreeBSD-8.1 (i386) >> FreeBSD-8.1 (amd64) >> RedHat EL 4 >> RedHat EL 6 (i386) >> RedHat EL 6 (x86_64) >> Debian Wheezy >> Debian Wheezy 64-bit >>=20 >> This is where my framework comes in-handy... >>=20 >> cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff >> make >> # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and bui= lt the .tgz >>=20 >> cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff >> make >> # it pulled the necessary bits from the "depend" dir and built .tbz >>=20 >> cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff >> make >> # pulled in "depend" and made .rpm >>=20 >> cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff >> make >> # pulled in "depend" and made .rpm >>=20 >> etc. >>=20 >> Of course, *any* time the depend tree has binaries in it... you have to = first do a make in there on the platform you want to ship the binary for, a= nd then do "make depend" in the platform-specific tree to pull in the binar= ies. Once you've done that, you don't have to muck with the depend tree aga= in unless there are changes there. >>=20 >> So, I assume that your prejudice remarks are because you haven't either = seen (a) such a platform or (b) such a need for said platform. >>=20 >> Yeah, I could rewrite the freebsd-specific logic to use "pkg create", bu= t let me tell you... >>=20 >> When you have to touch a file that needs to get shipped out to multiple = platforms... >>=20 >> It's damned nice to be able to build the FreeBSD packages under RedHat *= BECAUSE* the redhat RPMs can't be built under anything else (building an RP= M on FreeBSD and attempting to install it on RedHat results in an error mes= sage similar to "this is an rpm for FreeBSD; go away"). >>=20 >> Whereas FreeBSD will never balk about a package built on another platfor= m. >>=20 >> It's a huge time-saving measure... not having to jump over to each/every= unique platform to package things up *IF/WHEN* you know that there are no = binaries in the package *or* you've already checked the pre-compiled binari= es into the arch-specific hierarchy. >>=20 >>=20 >>=20 >>=20 >>> Or you >>> can maintain the old cruft for your business -- just don't expect >>> anyone else to use it, or even want to. >>>=20 >>=20 >>=20 >> I have no intention of making old-world packages... but I also have no i= ntention of using "pkg create". >=20 > You still haven't really explained at all why you can't use libpkg. If i= t doesn't run on Debian (not tried), it's got to be easier to port it than = rewrite a hacked version, hasn't it??? At least then you'll also be contri= buting back. >=20 Simple, really. Let's take RPM for example. The RPM package format has been ported to other= platforms. But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install it= on RedHat. This is because the RPM format records the platform that you "build" your R= PM on (not the binaries, just the RPM) *into* said RPM. This actually adds a requirement to the RPM production that the RPMs be pro= duced on the platform that they will be installed-to. Currently, no such restriction exists for the building of FreeBSD packages = (within our system). This would have been true if we had ported pkg_create = (and may continue to be true if we ported pkg and its ilk), but let's say f= or the sake of argument that the future of "pkg" looks bright and it gets p= orted to all sorts of systems (ported in a fashion similar to RPM) *and* we= find one day that the +MANIFEST starts containing a target-platform (resul= ting in refusal to install a *.txz package because it was rolled on a diffe= rent platform. In that case, we'd then prefer to by-pass the tools and use our own method = of creating the tar-ball to lift such a restriction. ASIDE: If I knew how to force rpmbuild into creating androgynous packages f= or other architectures, I'd be doing that to life the restriction there too= , but I haven't figured out that. Basically... within our "pkgbase" tree, we like the branch within the tree = to dictate how a package is built... not what platform you're on. The goal = being that we can run a single package-build host that builds all of our pa= ckages from a single platform. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 18:50:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47D16EF; Sun, 14 Jul 2013 18:50:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by mx1.freebsd.org (Postfix) with ESMTP id A92DDDAE; Sun, 14 Jul 2013 18:50:51 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id c11so9484472wgh.25 for ; Sun, 14 Jul 2013 11:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rEMtkD2+uQa2qHleGUJe9hgWejD8mTNX9mCHmwjAtGg=; b=cEzzPCsuHN815OaZbIhc/GzF6AdtjMY2UAqLis89FoCST3mZkzEFTeKL0FbuZm5YqU Ee4Wnz5IvWgzW6mzjGkJ0AOom+H5715Og+24lAahVg5GuFNxLIxh5dU0fRKGGrvZ2X1S SlejZmZpLRvim4/1/xPlNU0Y802sxYIB8hhrfm7VTYjLLcKNx0jf1OrA6Bn1xf94FL0h eneC7Pm41ZCcO/PgIGdaVjAPXdGjuz+Y9dKxNYDMWFJeKL6LKVBYAYclH9bNSGei30HV yPtBTXpu+gEJmeDKF5xP1o2IBUnc+0C+Usqmgl2FqFaU6Zd8MlVzDNkazJZPAkBKzKpj rmww== MIME-Version: 1.0 X-Received: by 10.180.82.196 with SMTP id k4mr6909652wiy.0.1373827850604; Sun, 14 Jul 2013 11:50:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 14 Jul 2013 11:50:50 -0700 (PDT) In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> Date: Sun, 14 Jul 2013 11:50:50 -0700 X-Google-Sender-Auth: BOGo47ChSdnpezy3uOqhoI38xT0 Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Adrian Chadd To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Rees , "freebsd-current@freebsd.org" , Garrett Wollman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 18:50:52 -0000 ... I bet you could do that. I bet you could build the rpm inside a linux jail and have the relevant uname bits overridden in the right way. -adrian On 14 July 2013 09:52, Teske, Devin wrote: > > On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: > >> On 14 Jul 2013, at 08:29, Teske, Devin wrote: >>> >>> To give you an idea as to just how helpful this is... >>> >>> Imagine the following hierarchy: >>> >>> src/pkgbase/depend/mystuff/script1 >>> src/pkgbase/depend/mystuff/textfile1 >>> src/pkgbase/depend/mystuff/sourcefile.c >>> src/pkgbase/depend/mystuff/Makefile >>> >>> You are a developer. You want to ship a package that contains "script1"= , "textfile1", and "binary1" (which is compiled by saying "make" to turn "s= ourcefile.c" into "binary1") >>> >>> You want to ship 8 types of packages: >>> >>> FreeBSD-4.11 >>> FreeBSD-8.1 (i386) >>> FreeBSD-8.1 (amd64) >>> RedHat EL 4 >>> RedHat EL 6 (i386) >>> RedHat EL 6 (x86_64) >>> Debian Wheezy >>> Debian Wheezy 64-bit >>> >>> This is where my framework comes in-handy... >>> >>> cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff >>> make >>> # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and bu= ilt the .tgz >>> >>> cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff >>> make >>> # it pulled the necessary bits from the "depend" dir and built .tbz >>> >>> cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff >>> make >>> # pulled in "depend" and made .rpm >>> >>> cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff >>> make >>> # pulled in "depend" and made .rpm >>> >>> etc. >>> >>> Of course, *any* time the depend tree has binaries in it... you have to= first do a make in there on the platform you want to ship the binary for, = and then do "make depend" in the platform-specific tree to pull in the bina= ries. Once you've done that, you don't have to muck with the depend tree ag= ain unless there are changes there. >>> >>> So, I assume that your prejudice remarks are because you haven't either= seen (a) such a platform or (b) such a need for said platform. >>> >>> Yeah, I could rewrite the freebsd-specific logic to use "pkg create", b= ut let me tell you... >>> >>> When you have to touch a file that needs to get shipped out to multiple= platforms... >>> >>> It's damned nice to be able to build the FreeBSD packages under RedHat = *BECAUSE* the redhat RPMs can't be built under anything else (building an R= PM on FreeBSD and attempting to install it on RedHat results in an error me= ssage similar to "this is an rpm for FreeBSD; go away"). >>> >>> Whereas FreeBSD will never balk about a package built on another platfo= rm. >>> >>> It's a huge time-saving measure... not having to jump over to each/ever= y unique platform to package things up *IF/WHEN* you know that there are no= binaries in the package *or* you've already checked the pre-compiled binar= ies into the arch-specific hierarchy. >>> >>> >>> >>> >>>> Or you >>>> can maintain the old cruft for your business -- just don't expect >>>> anyone else to use it, or even want to. >>>> >>> >>> >>> I have no intention of making old-world packages... but I also have no = intention of using "pkg create". >> >> You still haven't really explained at all why you can't use libpkg. If = it doesn't run on Debian (not tried), it's got to be easier to port it than= rewrite a hacked version, hasn't it??? At least then you'll also be contr= ibuting back. >> > > Simple, really. > > Let's take RPM for example. The RPM package format has been ported to oth= er platforms. > > But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install = it on RedHat. > > This is because the RPM format records the platform that you "build" your= RPM on (not the binaries, just the RPM) *into* said RPM. > > This actually adds a requirement to the RPM production that the RPMs be p= roduced on the platform that they will be installed-to. > > Currently, no such restriction exists for the building of FreeBSD package= s (within our system). This would have been true if we had ported pkg_creat= e (and may continue to be true if we ported pkg and its ilk), but let's say= for the sake of argument that the future of "pkg" looks bright and it gets= ported to all sorts of systems (ported in a fashion similar to RPM) *and* = we find one day that the +MANIFEST starts containing a target-platform (res= ulting in refusal to install a *.txz package because it was rolled on a dif= ferent platform. > > In that case, we'd then prefer to by-pass the tools and use our own metho= d of creating the tar-ball to lift such a restriction. > > ASIDE: If I knew how to force rpmbuild into creating androgynous packages= for other architectures, I'd be doing that to life the restriction there t= oo, but I haven't figured out that. > > Basically... within our "pkgbase" tree, we like the branch within the tre= e to dictate how a package is built... not what platform you're on. The goa= l being that we can run a single package-build host that builds all of our = packages from a single platform. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or confident= ial. If you are not the intended recipient, please: (i) delete the message = and all copies; (ii) do not disclose, distribute or use the message in any = manner; and (iii) notify the sender immediately. In addition, please be awa= re that any message addressed to our domain is subject to archiving and rev= iew by persons other than the intended recipient. Thank you. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Jul 14 19:17:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E467855C for ; Sun, 14 Jul 2013 19:17:26 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id AE3ABE99 for ; Sun, 14 Jul 2013 19:17:26 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 0A52B35931A; Sun, 14 Jul 2013 21:17:26 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id D7AC228494; Sun, 14 Jul 2013 21:17:25 +0200 (CEST) Date: Sun, 14 Jul 2013 21:17:25 +0200 From: Jilles Tjoelker To: Ian FREISLICH Subject: Re: Ports with daemons on uninstall... Message-ID: <20130714191725.GA30708@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 19:17:27 -0000 On Sun, Jul 14, 2013 at 05:52:37PM +0200, Ian FREISLICH wrote: > I have to ask if there's a standard for the way ports should handle > their daemons when the port is uninstalled. > I've encountered 3 varients of ports behaviour on uninstall: > 1. Do nothing > 2. Stop the daemon > 3. Ask if the daemon should be stopped > #1 closely followed by #3 are the least irritating when it comes > to portupgrade because you can at least have the service running > while upgrading. At least with #3 the upgrade gets paused until > the propmpt is answered and you're then aware that some service > will go away immediately so you can be prepared to restart it. > #2 is extremely irritating because upgrading with portupgrade etc > kills the service. For instance isc-dhcpd* does this which means > that for some time, dhcp may be unavailable. It could be less > irritating if it would automatically start the service, but that > can have its own problems. > Does the project have a preferred method for handling running > daenmons on uninstall? I know that Linux will even start daemons > on install. I think that almost all of this per-port code should be removed with pkgng. The HANDLE_RC_SCRIPTS pkg.conf option will stop/start the rc.d script during deinstallation/installation. By default, services are left running. Stopping the service on deinstall but not starting it again on install seems like a particularly bad idea. Apart from the annoyance of the restarts, automatic stopping and starting is probably the best policy for having things "just work". Some daemons will crash or otherwise stop being useful when their files have been deleted or replaced, and the new rc.d script might be unable to stop the old daemon. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 15:01:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4D744D69; Sun, 14 Jul 2013 15:01:53 +0000 (UTC) (envelope-from crees@bayofrum.net) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by mx1.freebsd.org (Postfix) with ESMTP id AE60C38A; Sun, 14 Jul 2013 15:01:52 +0000 (UTC) X-Trace: 739672869/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/Talk_Talk_Customer/2.102.104.150/None/crees@bayofrum.net X-SBRS: None X-RemoteIP: 2.102.104.150 X-IP-MAIL-FROM: crees@bayofrum.net X-SMTP-AUTH: bayofrum@uwclub.net X-MUA: Apple Mail (2.1085) X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4SAA684lECZmiW/2dsb2JhbABagwZEwgkGgQAXdIIjAQEFOhwjEAsOCi45HgaIJ7YEjzEzBy6CXW0DnWyEEocrgxM7 X-IronPort-AV: E=Sophos;i="4.89,663,1367967600"; d="scan'208";a="739672869" X-IP-Direction: OUT Received: from host-2-102-104-150.as13285.net (HELO pegasus.bayofrum.net) ([2.102.104.150]) by smtp.pipex.tiscali.co.uk with ESMTP; 14 Jul 2013 16:01:37 +0100 Received: from zeus.bayofrum.net (zeus.bayofrum.net [192.168.1.151]) by pegasus.bayofrum.net (Postfix) with ESMTPA id 531902EC44; Sun, 14 Jul 2013 16:01:15 +0100 (BST) References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Message-Id: <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> Content-Transfer-Encoding: quoted-printable From: Chris Rees Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Date: Sun, 14 Jul 2013 16:01:14 +0100 To: Devin Teske X-Mailer: Apple Mail (2.1085) X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: 531902EC44.A9D91 X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@bayofrum.net X-Spam-Status: No X-Mailman-Approved-At: Sun, 14 Jul 2013 21:08:09 +0000 Cc: "freebsd-current@freebsd.org" , Garrett Wollman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 15:01:53 -0000 On 14 Jul 2013, at 08:29, Teske, Devin wrote: >=20 > To give you an idea as to just how helpful this is... >=20 > Imagine the following hierarchy: >=20 > src/pkgbase/depend/mystuff/script1 > src/pkgbase/depend/mystuff/textfile1 > src/pkgbase/depend/mystuff/sourcefile.c > src/pkgbase/depend/mystuff/Makefile >=20 > You are a developer. You want to ship a package that contains "script1", = "textfile1", and "binary1" (which is compiled by saying "make" to turn "sou= rcefile.c" into "binary1") >=20 > You want to ship 8 types of packages: >=20 > FreeBSD-4.11 > FreeBSD-8.1 (i386) > FreeBSD-8.1 (amd64) > RedHat EL 4 > RedHat EL 6 (i386) > RedHat EL 6 (x86_64) > Debian Wheezy > Debian Wheezy 64-bit >=20 > This is where my framework comes in-handy... >=20 > cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff > make > # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and buil= t the .tgz >=20 > cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff > make > # it pulled the necessary bits from the "depend" dir and built .tbz >=20 > cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff > make > # pulled in "depend" and made .rpm >=20 > cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff > make > # pulled in "depend" and made .rpm >=20 > etc. >=20 > Of course, *any* time the depend tree has binaries in it... you have to f= irst do a make in there on the platform you want to ship the binary for, an= d then do "make depend" in the platform-specific tree to pull in the binari= es. Once you've done that, you don't have to muck with the depend tree agai= n unless there are changes there. >=20 > So, I assume that your prejudice remarks are because you haven't either s= een (a) such a platform or (b) such a need for said platform. >=20 > Yeah, I could rewrite the freebsd-specific logic to use "pkg create", but= let me tell you... >=20 > When you have to touch a file that needs to get shipped out to multiple p= latforms... >=20 > It's damned nice to be able to build the FreeBSD packages under RedHat *B= ECAUSE* the redhat RPMs can't be built under anything else (building an RPM= on FreeBSD and attempting to install it on RedHat results in an error mess= age similar to "this is an rpm for FreeBSD; go away"). >=20 > Whereas FreeBSD will never balk about a package built on another platform. >=20 > It's a huge time-saving measure... not having to jump over to each/every = unique platform to package things up *IF/WHEN* you know that there are no b= inaries in the package *or* you've already checked the pre-compiled binarie= s into the arch-specific hierarchy. >=20 >=20 >=20 >=20 >> Or you >> can maintain the old cruft for your business -- just don't expect >> anyone else to use it, or even want to. >>=20 >=20 >=20 > I have no intention of making old-world packages... but I also have no in= tention of using "pkg create". You still haven't really explained at all why you can't use libpkg. If it = doesn't run on Debian (not tried), it's got to be easier to port it than re= write a hacked version, hasn't it??? At least then you'll also be contribu= ting back. Chris --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 19:49:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B56B5ABD for ; Sun, 14 Jul 2013 19:49:38 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 783D0104 for ; Sun, 14 Jul 2013 19:49:38 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r6EJnaC5009320; Sun, 14 Jul 2013 15:49:36 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r6EJnZPp009319; Sun, 14 Jul 2013 15:49:35 -0400 (EDT) (envelope-from wollman) Date: Sun, 14 Jul 2013 15:49:35 -0400 (EDT) From: Garrett Wollman Message-Id: <201307141949.r6EJnZPp009319@hergotha.csail.mit.edu> To: jilles@stack.nl Subject: Re: Ports with daemons on uninstall... In-Reply-To: <20130714191725.GA30708@stack.nl> References: Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 14 Jul 2013 15:49:36 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 14 Jul 2013 21:08:26 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 19:49:38 -0000 In article <20130714191725.GA30708@stack.nl>, jilles@stack.nl writes: >Apart from the annoyance of the restarts, automatic stopping and >starting is probably the best policy for having things "just work". Some >daemons will crash or otherwise stop being useful when their files have >been deleted or replaced, and the new rc.d script might be unable to >stop the old daemon. Strongly agreed -- and it's what other operating systems do, either by policy or by convention. -GAWollman From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 22:43:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CF9D1732; Sun, 14 Jul 2013 22:43:27 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by mx1.freebsd.org (Postfix) with ESMTP id 267B738F; Sun, 14 Jul 2013 22:43:26 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id d10so8928603lbj.14 for ; Sun, 14 Jul 2013 15:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=k8R2XgQ+F8d9H8NCZBKD3+oH2kKAmPhE+T7487HOYfY=; b=fpdFhK9y8ZFqsWhJxH7GoSyE5CLYN5xVMHiDrHJpdgIWk7ROcWTQ77cX/4Efi4Zbjx heAy38zUYW/48wJC64i2WvUbjdkoNrjeKgykycYWm1770Bv//DbabCyA3XKHwPjmMUxs mkQvcYrr+jh5C3YJ1bV/jOzkE20r1s93ZPWdAG57WIHHU2tRYD/4ciGWg9Ic8xSfYrhI bykTc6Bxyh9KYx8eAKWRRyc+DFI4RTrSNAZFruP8G5qx95l3aaE/p+KF9263Zgcm8NAb uF0MopZXOvPiQ5961i5njKzvyYVQsdcWcfADNncnB32DdS5YlTG1ELMZmuXUmFxGI+MP bE3g== MIME-Version: 1.0 X-Received: by 10.112.172.35 with SMTP id az3mr22754813lbc.66.1373841805960; Sun, 14 Jul 2013 15:43:25 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.149.38 with HTTP; Sun, 14 Jul 2013 15:43:25 -0700 (PDT) In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> Date: Sun, 14 Jul 2013 15:43:25 -0700 X-Google-Sender-Auth: w_O8MxWFMBJejyPBvbYR5-oUTsY Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Craig Rodrigues To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mark Felder , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 22:43:28 -0000 On Sat, Jul 13, 2013 at 10:54 PM, Teske, Devin wrote: > > > I assume that poudiere builds packages from ports. > Yes. > > That's not how we build package repositories here (and would expect that > there are many more like us). > How do you build packages if you are not using FreeBSD ports? Do you have your own Makefiles which resemble FreeBSD ports, or are you doing something completely different? > > We expect to start with an empty directory, go grab packages that we > want (one by one) from FTP. Then put those tarballs into a directory. > There's no additional step because we download the INDEX file to the > repository too. Local repository is built. > What FTP site are you grabbing packages from, the FreeBSD ftp site (or mirrors) or one of your own? How are you generating the INDEX file? Do you append to the INDEX file for every package which you sucessfully download from FTP, or are you downloading a previously generated INDEX file? What does your local repository of packages consist of if you are not using FreeBSD ports? > > > > But I want bsdconfig to work with local repositories without having > poudriere. > > You don't have to use poudriere to build a package repository. It is just an optional tool that is there for you to try out, and it works quite well when building a package repository based off of FreeBSD ports. If you don't want to use it, you don't have to. > > > I think so too. But right now a *lot* of unanswered questions. > > Possibly, but I think that you are supporting a workflow that people on this mailing list don't fully understand. If you could send out a separate e-mail describing exactly what your workflow is, step-by-step, that might help you get better answers to your questions. The FreeBSD ports team has been migrating to pkgng for the past few years, so a lot of people understand the FreeBSD ports/packages workflow. because it has been discussed for a few years on multiple mailing lists, and at various BSD conferences like BSDCan. Some of the confusion with others on this list is that you are working on a tool called "bsdconfig" and committing it into FreeBSD-CURRENT, but the workflow you are trying to support is slightly different than what the FreeBSD ports/packages teams have been supporting and adapting their tools and workflow towards. I think that if you better describe your workflow in a separate e-mail, then folks can better recommend how to adapt bsdconfig to the new pkg tools. You may need to be open to using things like libpkg inside bsdconfig, if that is the best solution for bsdconfig inside FreeBSD. I agree with you that having a pkgng transition document on the wiki would be useful for systems integrators. I know that many people build products based on FreeBSD and leverage the pkg_XXX tools for building their own products. I have done this myself in the past. Clarifying the transition path for system integrators would be very helpful. Maybe you can help write the transition doc, since you have the perspective? -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 23:26:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6BCA1E2D for ; Sun, 14 Jul 2013 23:26:23 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id AE7CC7B9 for ; Sun, 14 Jul 2013 23:26:22 +0000 (UTC) Received: (qmail 92232 invoked by uid 89); 14 Jul 2013 23:24:24 -0000 Received: from unknown (HELO ?192.168.1.201?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 14 Jul 2013 23:24:24 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Rainer Duffner In-Reply-To: Date: Mon, 15 Jul 2013 01:24:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> To: Craig Rodrigues X-Mailer: Apple Mail (2.1508) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 23:26:23 -0000 Am 15.07.2013 um 00:43 schrieb Craig Rodrigues : > On Sat, Jul 13, 2013 at 10:54 PM, Teske, Devin = wrote: >=20 >>=20 >>=20 >> I assume that poudiere builds packages from ports. >>=20 >=20 > Yes. >=20 >=20 >>=20 >> That's not how we build package repositories here (and would expect = that >> there are many more like us). >>=20 >=20 > How do you build packages if you are not using FreeBSD ports? =20 If I understand him correctly, he uses packages built elsewhere and = re-packages them into his own format? http://druidbsd.sourceforge.net/download.shtml#pkgbase I don't really see any value in this. At some point, his scripts etc. = have to be packaged anyway? It should not be a problem running one server/VM for each system.= From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 01:08:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E339222; Mon, 15 Jul 2013 01:08:13 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 4E961C7D; Mon, 15 Jul 2013 01:08:13 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r6F183Sv027545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 20:08:03 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 20:08:02 -0500 From: "Teske, Devin" To: Adrian Chadd Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOgGCkEhI/XtjETUan8/QjEhM8pplkGukAgAB+HwCAAB8QgIAAIRYAgABpYoA= Date: Mon, 15 Jul 2013 01:08:01 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC61A8@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5B2CFC1C7F28BB4F9D5EB9C07ACA02DD@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_07:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Chris Rees , Devin Teske , Garrett Wollman , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:08:13 -0000 On Jul 14, 2013, at 11:50 AM, Adrian Chadd wrote: > ... I bet you could do that. I bet you could build the rpm inside a > linux jail and have the relevant uname bits overridden in the right > way. >=20 There's an idea. --=20 Devin > On 14 July 2013 09:52, Teske, Devin wrote: >>=20 >> On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: >>=20 >>> On 14 Jul 2013, at 08:29, Teske, Devin wrote: >>>>=20 >>>> To give you an idea as to just how helpful this is... >>>>=20 >>>> Imagine the following hierarchy: >>>>=20 >>>> src/pkgbase/depend/mystuff/script1 >>>> src/pkgbase/depend/mystuff/textfile1 >>>> src/pkgbase/depend/mystuff/sourcefile.c >>>> src/pkgbase/depend/mystuff/Makefile >>>>=20 >>>> You are a developer. You want to ship a package that contains "script1= ", "textfile1", and "binary1" (which is compiled by saying "make" to turn "= sourcefile.c" into "binary1") >>>>=20 >>>> You want to ship 8 types of packages: >>>>=20 >>>> FreeBSD-4.11 >>>> FreeBSD-8.1 (i386) >>>> FreeBSD-8.1 (amd64) >>>> RedHat EL 4 >>>> RedHat EL 6 (i386) >>>> RedHat EL 6 (x86_64) >>>> Debian Wheezy >>>> Debian Wheezy 64-bit >>>>=20 >>>> This is where my framework comes in-handy... >>>>=20 >>>> cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff >>>> make >>>> # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and b= uilt the .tgz >>>>=20 >>>> cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff >>>> make >>>> # it pulled the necessary bits from the "depend" dir and built .tbz >>>>=20 >>>> cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff >>>> make >>>> # pulled in "depend" and made .rpm >>>>=20 >>>> cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff >>>> make >>>> # pulled in "depend" and made .rpm >>>>=20 >>>> etc. >>>>=20 >>>> Of course, *any* time the depend tree has binaries in it... you have t= o first do a make in there on the platform you want to ship the binary for,= and then do "make depend" in the platform-specific tree to pull in the bin= aries. Once you've done that, you don't have to muck with the depend tree a= gain unless there are changes there. >>>>=20 >>>> So, I assume that your prejudice remarks are because you haven't eithe= r seen (a) such a platform or (b) such a need for said platform. >>>>=20 >>>> Yeah, I could rewrite the freebsd-specific logic to use "pkg create", = but let me tell you... >>>>=20 >>>> When you have to touch a file that needs to get shipped out to multipl= e platforms... >>>>=20 >>>> It's damned nice to be able to build the FreeBSD packages under RedHat= *BECAUSE* the redhat RPMs can't be built under anything else (building an = RPM on FreeBSD and attempting to install it on RedHat results in an error m= essage similar to "this is an rpm for FreeBSD; go away"). >>>>=20 >>>> Whereas FreeBSD will never balk about a package built on another platf= orm. >>>>=20 >>>> It's a huge time-saving measure... not having to jump over to each/eve= ry unique platform to package things up *IF/WHEN* you know that there are n= o binaries in the package *or* you've already checked the pre-compiled bina= ries into the arch-specific hierarchy. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Or you >>>>> can maintain the old cruft for your business -- just don't expect >>>>> anyone else to use it, or even want to. >>>>>=20 >>>>=20 >>>>=20 >>>> I have no intention of making old-world packages... but I also have no= intention of using "pkg create". >>>=20 >>> You still haven't really explained at all why you can't use libpkg. If= it doesn't run on Debian (not tried), it's got to be easier to port it tha= n rewrite a hacked version, hasn't it??? At least then you'll also be cont= ributing back. >>>=20 >>=20 >> Simple, really. >>=20 >> Let's take RPM for example. The RPM package format has been ported to ot= her platforms. >>=20 >> But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install= it on RedHat. >>=20 >> This is because the RPM format records the platform that you "build" you= r RPM on (not the binaries, just the RPM) *into* said RPM. >>=20 >> This actually adds a requirement to the RPM production that the RPMs be = produced on the platform that they will be installed-to. >>=20 >> Currently, no such restriction exists for the building of FreeBSD packag= es (within our system). This would have been true if we had ported pkg_crea= te (and may continue to be true if we ported pkg and its ilk), but let's sa= y for the sake of argument that the future of "pkg" looks bright and it get= s ported to all sorts of systems (ported in a fashion similar to RPM) *and*= we find one day that the +MANIFEST starts containing a target-platform (re= sulting in refusal to install a *.txz package because it was rolled on a di= fferent platform. >>=20 >> In that case, we'd then prefer to by-pass the tools and use our own meth= od of creating the tar-ball to lift such a restriction. >>=20 >> ASIDE: If I knew how to force rpmbuild into creating androgynous package= s for other architectures, I'd be doing that to life the restriction there = too, but I haven't figured out that. >>=20 >> Basically... within our "pkgbase" tree, we like the branch within the tr= ee to dictate how a package is built... not what platform you're on. The go= al being that we can run a single package-build host that builds all of our= packages from a single platform. >> -- >> Devin >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/ma= ilman/listinfo/freebsd-current&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3D= Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3D%2FFBYMopr3kmkYeXlwxBrUhJ1pMA6Fg3Fe= ekZ9VXWlQY%3D%0A&s=3D1db27aa85bccd5d393060e70ae8587478ba99da599264ca6515a66= 7c6acfccdd >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 01:15:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E362464; Mon, 15 Jul 2013 01:15:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by mx1.freebsd.org (Postfix) with ESMTP id B1EB6D25; Mon, 15 Jul 2013 01:15:10 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id z11so9780903wgg.22 for ; Sun, 14 Jul 2013 18:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n6aAe7N7n9H0gOd4ueQGU+ntxALhVGQMu7si4imMsdw=; b=opMhcbO6aJtJfmaCzQbJfFk6VnObd2tKt6cV2qO3v5WGquhceLKZSBtdo/rWkQ1SXA rRUW/7GRbB/PfywYrkhtgAtKzmCEn62Mq8J0WiNnzVHGKRkxwz/OaBN29CAEccChmEWG zbZGFZ2yVcxpR86s1DBUGKEfTh1CbbWqgEu2qUC+AEwnq/DFz983wi5IqPBLhBCFKbaO 1aD9/g2DrD7k0j31MyOiYy/kIcN3VC9rqSNLAaAXyj8F02IWOFGPYlvOar8gOUK1Na2H ykeBuhFTDBJ/RrH06zTRlnHT81cYzKPQHPwXHvIKWiKrtxasxsqyp3c9TNfSO48an/rA lOAw== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr30706910wjb.0.1373850909610; Sun, 14 Jul 2013 18:15:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 14 Jul 2013 18:15:09 -0700 (PDT) In-Reply-To: References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> Date: Sun, 14 Jul 2013 18:15:09 -0700 X-Google-Sender-Auth: Lad0l-20pDYZz5hwlVdzFsxqTVM Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Adrian Chadd To: Rainer Duffner Content-Type: text/plain; charset=ISO-8859-1 Cc: Craig Rodrigues , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 01:15:11 -0000 Guys, Devin runs a _lot_ of FreeBSD stuff at his work. If anything we as a community should be making his life easier, not act like he's just clueless and doing it wrong. -adrian On 14 July 2013 16:24, Rainer Duffner wrote: > > Am 15.07.2013 um 00:43 schrieb Craig Rodrigues : > >> On Sat, Jul 13, 2013 at 10:54 PM, Teske, Devin wrote: >> >>> >>> >>> I assume that poudiere builds packages from ports. >>> >> >> Yes. >> >> >>> >>> That's not how we build package repositories here (and would expect that >>> there are many more like us). >>> >> >> How do you build packages if you are not using FreeBSD ports? > > > > If I understand him correctly, he uses packages built elsewhere and re-packages them into his own format? > http://druidbsd.sourceforge.net/download.shtml#pkgbase > > I don't really see any value in this. At some point, his scripts etc. have to be packaged anyway? > It should not be a problem running one server/VM for each system. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 01:48:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A3FD2B47 for ; Mon, 15 Jul 2013 01:48:50 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id E4B09E62 for ; Mon, 15 Jul 2013 01:48:49 +0000 (UTC) Received: (qmail 95946 invoked by uid 89); 15 Jul 2013 01:48:48 -0000 Received: from unknown (HELO ?192.168.1.201?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 15 Jul 2013 01:48:48 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Rainer Duffner In-Reply-To: Date: Mon, 15 Jul 2013 03:48:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BCC2D98-3EDC-4F7C-A992-C88B8BE073EF@ultra-secure.de> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 01:48:50 -0000 Am 15.07.2013 um 03:15 schrieb Adrian Chadd : > Guys, >=20 > Devin runs a _lot_ of FreeBSD stuff at his work. Doubtlessly. It wouldn't make sense on a small scale. I assume, his system pre-dates most of the stuff nowadays filed under = the "dev-ops" moniker (chef, puppet=85). Probably also has (had) less overhead ;-) From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 02:12:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2460CFAD; Mon, 15 Jul 2013 02:12:10 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B2507F02; Mon, 15 Jul 2013 02:12:09 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r6F2C6h2018429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 21:12:06 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 21:12:06 -0500 From: "Teske, Devin" To: Craig Rodrigues Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAUuIAgAA53QCAAAQ1gIAAJ5eAgAEZyoCAADpMAA== Date: Mon, 15 Jul 2013 02:12:05 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC658E@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-15_01:2013-07-12,2013-07-15,1970-01-01 signatures=0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mark Felder , Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:12:10 -0000 On Jul 14, 2013, at 3:43 PM, Craig Rodrigues wrote: On Sat, Jul 13, 2013 at 10:54 PM, Teske, Devin > wrote: I assume that poudiere builds packages from ports. Yes. That's not how we build package repositories here (and would expect that th= ere are many more like us). How do you build packages if you are not using FreeBSD ports? Two spectrums... When developer A says he needs xerces, I go to: (for an active release, such as 8.4 or 9.1) ftp://ftp.freebsd.org/pub/FreeBSD/releases/{arch}/X.Y-RELEASE/packages/All<= ftp://ftp.freebsd.org/pub/FreeBSD/releases/%7Barch%7D/X.Y-RELEASE/packages/= All> (for an in-active release, such as 8.1 or 9.0) ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/{arch}/X.Y-R= ELEASE/packages/All Meanwhile, when either developer B or integrator A says "I have software X = that I want to package", we use "pkgbase" to build the FreeBSD package, the= RedHat RPM, etc. Do you have your own Makefiles which resemble FreeBSD ports, or are you doing something completely different? That's essentially what pkgbase is. Except instead of building makefiles th= at build the 3rd-party software, we rely on the 3rd-party compilation proce= ss to produce the binaries and have a configuration file (pkgbase.conf) whi= ch describes the vendor layout. The vendor layout can be anything and do anything and prepare anything. But= the pkgbase.conf says "fileA" in the vendor layout goes to "src/fileA" (wh= ere "src/" looks exactly like the un-packed tar-ball, *minus* +CONTENTS -- = which is generated from PLIST when you say "make"). Since we're using CVS, people that are familiar with CVS would think it's q= uite cute that it does a "cvs admin -ko" on files that are pulled from the = vendor branch (resulting in keyword expansion to retain its vendor location= -- so if a problem happens in the field, we know that the file that should= be edited -- based on its keyword expansion -- is over in the vendor "depe= nd" tree which, upon modification, will cause a cascading rebuild of packag= es for releases we actively maintain [through a sliding window]). So it's very similar to ports, but we need the mechanism of being able to (= for the benefit of developer A/B and integrator A above) freeze the softwar= e distribution of software X. The ports tree manages that through a collection of centrally located distf= iles (which acts as a fall-back for when vendor distfiles dry up). But that= method doesn't work so well for us because when we find a bug we often fix= it ourselves in our own local branch and then communicate the fix back the= vendor (leaving it up to them to incorporate it). The next time around on = our migration to a new release, *if* we have made a local patch, producing = a custom version, *and* the vendor has not taken a patch, we'll _first_ re-= evaluate the new version with a documented test-case or (if that fails) we'= ll keep the patch in-place. The ports tree moves too fast for us. And many times we find a bug, we end = up performing cost/benefit analysis only to find that we can live with the = bug *if* the problem has been fixed already. In rare cases, we'll merge a s= ingle patch from a future revision to get things going. But we *won't* just= blindly take a new version simply because it fixes a bug (as it may introd= uce new bugs -- unwinding many man-hours of many testers and developers att= empting to lead up to a release of a wholly contained full-working software= entity). I hope this helps to explain a little more about how we take FreeBSD releas= es, vet them, and them blast them out to thousands of machines over many cu= stomers after many months of testing. Now to say that we don't use ports would be a lie. Sometimes a developer as= ks for a package that is not available on the release we're shipping. This = happened recently. So I went into the ports tree, built the package on 8.1 = (which had 99% binary packages from 8.1-RELEASE -- see above URLs) and then= I said "make package" and threw it in the repository. ASIDE: For diligence, "make describe" iirc generates my INDEX entry to appe= nd. We expect to start with an empty directory, go grab packages that we want (= one by one) from FTP. Then put those tarballs into a directory. There's no = additional step because we download the INDEX file to the repository too. L= ocal repository is built. What FTP site are you grabbing packages from, the FreeBSD ftp site (or mirr= ors) or one of your own? We grab from either ftp.f.o or ftp-archive.f.o and plop into an NFS-based r= epo (which has a structure mirroring that of the ftp{,-archive}.f.o structu= re). How are you generating the INDEX file? Well, since we prefer to ship 100% with the packages that were cut with X.Y= -RELEASE, the INDEX file that's up on the ftp.f.o site does fine (except wh= en we have to inject things from ports -- for example, when developer A nee= ds software X which isn't available on X.Y for the binary release packages = -- in-which case we have "make describe"). However, as previously mentioned= , the tool that mass-installs the architecture (and release) specific packa= ges out of the repo was written by a different developer (before I came to = this company) and *it* doesn't care about INDEX. Do you append to the INDEX file for every package which you sucessfully d= ownload from FTP, or are you downloading a previously generated INDEX file? The latter (except for rare cases that I want a newly-injected port package= to be browsable/usable by sysinstall -- which uses INDEX). What does your local repository of packages consist of if you are not using FreeBSD ports? The goal each release that we cycle through is indeed to wipe the local rep= ository completely clean of any/all packages that we ourselves do not autho= r/maintain. But it just doesn't happen. As previously mentioned, when we start to track a new FreeBSD release for d= evelopment/testing purposes [in our labs], we start with binary release pac= kages. When we find that a package (either a trusty one that we've known and loved= for over a dozen years; OR a new one that we're still feeling out) doesn't= operate quite right, here's what we do... We slurp it into pkgbase (it has a method for doing this; requires only a "= ./unpack.sh -o bad_package.tbz" -- which not only unpacks the tarball, but = puts it in the specific origin sub-directory, reverses the +CONTENTS file i= nto a PLIST, and assembles the Makefile system into the unpacked directory = so that you could, if so-desired, go in and say "make" and get the exact sa= me product as what you unpacked; after you say "unpack" you then go in and = say "make import" and it imports it into the revision control system -- CVS= for us). Once slurped-in, we then tack-on a "_1" to the version in the PLIST file, g= o fix the problem, commit both the fix and the bumped version back to CVS. = Then we say "make tag" and it tags the files with the version specified in = the PLIST, and then finally... "make" which produces the *fixed* "bad_packa= ge.tbz" which can then be put into the repository. We then go tack-on "_1" = to the version that is specified in the arch-specific config for our tool, = and that architecture now installs (and will update-to) the fixed package. Packages break. We choose to deal with it silently within our own release c= ycle. If we notice that something silly hasn't been fixed in the time it to= ok us to jump to the next release, we often release our fix for it (because= obviously nobody else came up with a better fix). But, more-oft than not, = what happens is that the breakage was a silly thing and somebody fixed it r= ight away (but we couldn't take that fix because it was post-release and we= couldn't take the risk of bringing in other things). ASIDE: Even if we did= take the fix from above, we'd have to have our own local system *like* wha= t I'm describing so that we can maintain accurate audit-history for our cli= ents that demand a break-fix mentality rather than a break-upgrade mentalit= y. But I want bsdconfig to work with local repositories without having poudrie= re. You don't have to use poudriere to build a package repository. It is just = an optional tool that is there for you to try out, and it works quite well when building a package repository based off of FreeBSD ports. If you don't want to use it, you do= n't have to. I was *quite* sad when oldports.org went away (not tha= t I used it much, as I could always check out historical revisions of the p= ort Makefiles, etc.). It offered a very simple service... download a tarbal= l of a snapshot of any port for any given revision. For poudriere (or ports for that matter) to work for something like $work, = it would have to accommodate inordinate durations of being frozen *and* wor= k well with a static versioning system. And as I was typing that, I think I realized a way to do it... Each release of FreeBSD comes with a "ports.tgz" distribution. Would I be w= rong in assuming that this essentially represents the very snapshot-in-time= of the ports tree in-which the binary release packages were built? I think I've heard others mention that this is not always guaranteed to be. That aside, I'm not so sure that it would be that beneficial to build the p= ackages ourselves when we so-rarely (and prefer not-to) have the need to re= master packages. In other words, we like leveraging the time someone else t= ook to compile the packages. I think so too. But right now a *lot* of unanswered questions. Possibly, but I think that you are supporting a workflow that people on thi= s mailing list don't fully understand. If you could send out a separate e-mail describing exactly what your workflow is, step-by-step, that might help you= get better answers to your questions. Ok, that's a good idea. Hopefully people haven't [already] muddled the two = topics of bsdconfig and the separate topic of my workflow @ $work (which re= quires me to understand the nitty gritty details of +MANIFEST). As you say, I should really spin the latter off into a thread of its own (I= gave the disclaimer at the beginning that the former was a side-"thing", b= ut it seems to have taken over this thread which was supposed to be "hey, l= et's go pkg on bsdconfig"). This thread should stay specific to "pkg_install is dead, long live pkg -- = dteske needs help answering some questions about pkg for bsdconfig integrat= ion with it". Questions still "out-there" in the thread in that arena are: What are the mirrors (actual addresses) -- one post in this thread asks "he= y, is this the right _first-step_" in which I proceed to shift away from FT= P and toward HTTP (removing all the swedish, japanese, etc. FTP mirrors and= adding at-a-minimum an IPv4 and IPv6 master HTTP mirror). What's the most efficient way (in a UI) to display a list of packages (we'v= e covered rquery; we've covered how rquery works; but I'm thinking to mysel= f... if an "rquery" requires an "update", could I perhaps have the UI someh= ow present something better than a "waiting for pkg update" box -- e.g., if= I go fetch the DB and put it where pkg expects it, I could give progress b= ars, transfer speeds, completion time, etc. etc. in dialog style). The FreeBSD ports team has been migrating to pkgng for the past few years, so a lot of people understand the FreeBSD ports/pac= kages workflow. because it has been discussed for a few years on multiple mailing lists, and at various BSD conferences like BSDCan. Indeed. However, I'm looking to create the UI for pkgng, and we're bound to= run into areas of discussion that haven't been discussed. I know that some have worked on UIs for pkgng, but those UIs have enjoyed a= level of integration that I cannot. All the suggestions to use libpkg are = not that helpful because the code is not in C. Some of the confusion with others on this list is that you are working on a tool called "bsdconfig" and committing it into FreeBSD-CURRENT, but the workflow you are trying to support is slightly different than what the FreeBSD ports/packages teams have been supporting and adapting their tools and workflow towards. The topic of my own personal quest to understand +MANIFEST and the tarball = contents is entirely separate from the bsdconfig topic. How we ended up dow= n this road is by-way of ignoring the sign posted, which said (as a pre-qua= lifier to the text that introduced this subject) "This is going to be impor= tant not for bsdconfig, but $work" (highlight "not for bsdconfig"). Here is the original quote (which garnered flame, but folks like Matthew Se= aman took me seriously and -- through it should have been pushed to a new t= hread -- was answering this little foot-note which I had at the bottom of m= y July 13th, 10:48P PDT response in this thread): (begin quote) On Jul 13, 2013, at 10:48 PM, Teske, Devin wrote: Question: Where can I learn more about the actual format of what's in the n= ew tarballs? This is going to be important not for bsdconfig, but $work (we= have our own build platform; I'm going to have to rewrite it from masterin= g PLIST files to mastering YAML MANIFEST files and I want to know all the g= ritty details). (end quote) So just to clear things up... [again] bsdconfig needs to blaze the trail on building a UI around pkg. My own personal quest to understand +MANIFEST so I can update my "pkgbase" = (which is like ports)... ... not related to bsdconfig. I think that if you better describe your workflow in a separate e-mail, then folks can better recommend how to adapt bsdconfig to the new pkg tools. ... You may need to be open to using things like libpkg inside bsdconfig, if that is the best solution for bsdco= nfig inside FreeBSD. Not C. I agree with you that having a pkgng transition document on the wiki would be useful for systems integrators. That was actually one of my original points is all. And the very first repl= y was about ... "8/9 packages?" My response to "pkg_install is dead, long live pkg" (paraphrasing) was actu= ally just about wanting a transition document (of which I would then digest= in my integration of bsdconfig). However, I was more than happy to turn th= e thread into a "let's get bsdconfig updated" thread. I know that many people build products based on FreeBSD and leverage the pkg_XXX tools for building their own products. I have done this myself in the past. Clarifying the transition path for system integrators would be very helpful. I'm still trying to figure out how our eccentricities here @ work can trans= late back. pkgbase solves our problems (in a nut-shell) because we're slow = and we need something that allows us to dance around problems without worry= ing about what the out-side world is doing. When we come up for air, we ral= ly around the latest software, and then go back under water and don't see t= he light of day until we've delivered a solid product. It almost seems like *everybody* else wants to do the opposite. Which is wh= enever they hit a problem, go immediately to the ports three, update, and s= ee if the problem goes away. Unfortunately, with over a million lines of so= urce-code in our product and touching everything from kernel source to user= -land _and_ running on 3 classes of hardware (server, workstation, and pede= stal), __AND__ interfacing with USB devices, high-end SCSI scanners, and ma= ny custom pieces of hardware... ... when we do come up for air in-between major releases, we have zero time= to waste in regression testing. Maybe you can help write the transition doc, since you have the perspective? I think that when bsdconfig has been updated to work with pkg... that would= be an *excellent* time for me to jump in on a doc-writing event. It will b= e fresh in my mind *and* we can go through subversion revision history to s= ee exactly what was changed (for example, the communicated list of mirrors = would be worth documenting in a Wiki alone, imho). -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 05:52:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A62AAC3F for ; Mon, 15 Jul 2013 05:52:56 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4229FC for ; Mon, 15 Jul 2013 05:52:55 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.norma.com [192.168.7.159]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r6F5YjJO005656 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 15 Jul 2013 11:34:45 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <51E389F5.8080501@norma.perm.ru> Date: Mon, 15 Jul 2013 11:34:45 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130709 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: panic: no init Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 15 Jul 2013 11:34:46 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 05:52:56 -0000 Hi. I'm using FreeBSD as a desktop. When updating from r251990 to a higher revision (both GENERIC kernels) I got 'panic: no init' message after mountroot (I'm using zfs, seems like mountroot was successful). Nothing changed in my configuration, so I have totally no clue. Right now I'm running r251990 kernel on a newer world. How can I get rid of this panic and run newer kernel ? Thanks. Eugene. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 05:57:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77995D84 for ; Mon, 15 Jul 2013 05:57:06 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 10D4BA29 for ; Mon, 15 Jul 2013 05:57:05 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id j14so7414885eak.36 for ; Sun, 14 Jul 2013 22:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=tA5Ou7akQPT3pBgVt78lE2cATtGujzs6nNbzd3bGqOY=; b=C879CZreAshOx9zH5sTjWV2X3EpIXMbq73cTDOU2Taagp4TZTJZPkmlWl1HyXugF6K NnZIph1qZmXZ1V75kStLDrBlJakMuIcVLY6Pko3tmQTWSbyDo4CAEFxMe4/M6LRazSmh U/20yqjFdAf3c+Y5NkqcBXyTtQKjZsbGE8xBF/SlVcVVCJq4LRoXSNdjISJjEIfB472A ZbeCA8xNZys0Yswyvt/4PJ02wcI9GFrw0m9rqvF3kqqbLiim6dRBVQWEF11XoxCAc74t fBdfyOtAOn17zG8xGoh8psiplCOtaV9gghtfiWblD5hf7C5k9iu4PR372JBLaGLhgdEr LJbg== X-Received: by 10.15.98.3 with SMTP id bi3mr55534713eeb.124.1373867825212; Sun, 14 Jul 2013 22:57:05 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id b7sm99759286eef.16.2013.07.14.22.57.04 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 22:57:04 -0700 (PDT) Date: Mon, 15 Jul 2013 08:56:57 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Subject: Re: lost my r2xxxxx subversion id in uname & kern.version Message-ID: <20130715085657.795d4109@laptop.minsk.domain> In-Reply-To: <51E2CEB8.80909@cordula.ws> References: <51E2CEB8.80909@cordula.ws> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.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.14 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, 15 Jul 2013 05:57:06 -0000 On Sun, 14 Jul 2013 18:15:52 +0200 cpghost wrote: > On 07/13/13 03:03, Dan Mack wrote: > > I'm not sure exactly when but recently I've lost the subversion id > > from kern.version and hence uname and motd. > > > > Subsequent fresh rebuilds from source don't bring it back even after > > wiping out the tree. > > > > Today it looks like this: > > > > root@olive:~ # uname -a > > FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri > > Jul 12 19:38:24 CDT 2013 > > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 > > root@olive:~ # sysctl kern.version > > kern.version: FreeBSD 10.0-CURRENT #0: Fri Jul 12 19:38:24 CDT 2013 > > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN > > > > Previously it would have '#0 r253307' in it's place. > > > > This only happened on 1 of 3 build machines. > > There was an update to subversion recently (1.7.x to 1.8.y). > If you updated the /usr/src tree with the new subversion > (i.e. svn upgrade; svn update), and then transferred that tree > to another machine that contains a non-upgraded subversion > client, if you build the tree there, you'll miss the r###### in > uname. > > Upgrade your subversion client on the target machine, and, > optionally, run 'svn upgrade' on the source tree, then rebuild > and reinstall. uname -a should show r###### again. > > > dan > svnlite was imported into base system. And newvers.sh use svnliteversion (1.8.x). svn upgrade /usr/src should help > -cpghost. > -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 06:07:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7801C15B; Mon, 15 Jul 2013 06:07:20 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id DBF51A7C; Mon, 15 Jul 2013 06:07:19 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id a15so7567755eae.40 for ; Sun, 14 Jul 2013 23:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=TAOFzIDk068yceVHnP/NEbYhLotK3z6GE32xVLu2hfw=; b=CCmziEB/PBgiGsoH7RuWH0Nl8hUYzEkj/VzcN5V+Nsv5X8xBQtq9GXyh0dNtBR1gEl fjXCK04KMj+p/moQtDm1nG9LLa/iLYJkbGJ3CTu9Wnl3a6SKukeLP5Z69xyBt+zZ8R8B A7fyv9afxYEzciozK8aEMoGakQGBAasf7feUKTAtY1ZVX6I5y9zjcvBqgk7x38qW4hzW ShBx0eCtCG5odOjiuGU9odLQeNBNOF/SpWTJK1IW2Rv/JQ6YKnrRhnBIN0YrlfZlsExw ecKjYxRcNHdzvI2RdENDTiLAOQDj4ES65oFehR+6+SKYcOwT7q+bCJedgvS6KItH9fbq KEUA== X-Received: by 10.14.53.75 with SMTP id f51mr57635351eec.30.1373868438905; Sun, 14 Jul 2013 23:07:18 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id a4sm99958149eez.0.2013.07.14.23.07.18 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 23:07:18 -0700 (PDT) Date: Mon, 15 Jul 2013 09:07:11 +0300 From: "Sergey V. Dyatko" To: gjb@freebsd.org, freebsd-current@freebsd.org Subject: Re: lost my r2xxxxx subversion id in uname & kern.version Message-ID: <20130715090711.730c39d8@laptop.minsk.domain> In-Reply-To: <51E2CEB8.80909@cordula.ws> References: <51E2CEB8.80909@cordula.ws> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.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.14 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, 15 Jul 2013 06:07:20 -0000 On Sun, 14 Jul 2013 18:15:52 +0200 cpghost wrote: > On 07/13/13 03:03, Dan Mack wrote: > > I'm not sure exactly when but recently I've lost the subversion id > > from kern.version and hence uname and motd. > > > > Subsequent fresh rebuilds from source don't bring it back even after > > wiping out the tree. > > > > Today it looks like this: > > > > root@olive:~ # uname -a > > FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri > > Jul 12 19:38:24 CDT 2013 > > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 > > root@olive:~ # sysctl kern.version > > kern.version: FreeBSD 10.0-CURRENT #0: Fri Jul 12 19:38:24 CDT 2013 > > root@olive.example.com:/usr/obj/usr/src/sys/MACKGEN > > > > Previously it would have '#0 r253307' in it's place. > > > > This only happened on 1 of 3 build machines. > > There was an update to subversion recently (1.7.x to 1.8.y). > If you updated the /usr/src tree with the new subversion > (i.e. svn upgrade; svn update), and then transferred that tree > to another machine that contains a non-upgraded subversion > client, if you build the tree there, you'll miss the r###### in > uname. > > Upgrade your subversion client on the target machine, and, > optionally, run 'svn upgrade' on the source tree, then rebuild > and reinstall. uname -a should show r###### again. > > > dan > > -cpghost. > 2 gjb@: That is a case, when we have 1.7.x checkout and _possible_ subversion17 installed. We was talking few weeks ago about that. (efnet@tigerby) -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 06:23:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8FC8851E; Mon, 15 Jul 2013 06:23:14 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id C628BB1D; Mon, 15 Jul 2013 06:23:13 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b12so9809763wgh.19 for ; Sun, 14 Jul 2013 23:23:12 -0700 (PDT) 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=eiqeEL1FYiHrOkpFUeKowqZOFDXZkjxNG/Bdvn0WcDs=; b=VhXJjONoB8Q9et0GUZXbyK5/jU6ggjGju+g00y0ULbNO3gO+lli1KW23Qv/eDH7MNt IFOWhx3EvMW95I+KWVqGa9TlbaDUUkJZ++7YLwrJzn0eLMvBo1CRk2tnY9MdeQkzBee+ ugJFwKILfedJXJdiNkue/WXjN0zEoIz4dKSrsKUSEz6bZ/kPRpDjLGmJ7k6rBfIFZqPI imul2ZXfBzQm2xNYc7iUW0qaz6oYWhcJy9twaxavKnIYThybcEbwa4MKfr9M/edB1GJ4 Tw/w1q3tA+ogAdC8MpAl3dUI3IopJ6AqfaFmhQ+8CSLNUjSPHo6Ty1N8cD5a+k1ltBXO z3aA== X-Received: by 10.194.75.201 with SMTP id e9mr29856916wjw.20.1373869392197; Sun, 14 Jul 2013 23:23:12 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id ev19sm18565133wid.2.2013.07.14.23.23.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 23:23:11 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 15 Jul 2013 08:23:08 +0200 From: Baptiste Daroussin To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130715062308.GE1516@ithaqua.etoilebsd.net> References: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E0D@ltcfiswmsgmb21> <51E26FD3.4020208@FreeBSD.org> <13CA24D6AB415D428143D44749F57D7201FC547A@ltcfiswmsgmb21> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC547A@ltcfiswmsgmb21> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Matthew Seaman , "current@FreeBSD.org" , Peter Wemm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 06:23:14 -0000 --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 14, 2013 at 10:12:19AM +0000, Teske, Devin wrote: >=20 > On Jul 14, 2013, at 2:30 AM, Matthew Seaman wrote: >=20 > > On 14/07/2013 06:48, Teske, Devin wrote: > >> Question: Where can I learn more about the actual format of what's in > >> the new tarballs? This is going to be important not for bsdconfig, > >> but $work (we have our own build platform; I'm going to have to > >> rewrite it from mastering PLIST files to mastering YAML MANIFEST > >> files and I want to know all the gritty details). > >=20 > > We do need a pkg-manifest(5) man page, which can double as a > > pkg-tarball(5) page since the manifest file is where most of the > > interesting bits are. > >=20 > > A pkg tarball is a compressed tar archive like so: > >=20 > > lucid-nonsense:...cache/pkg/All:% tar -tvf pkg-1.1.4.txz > > -rw-r--r-- 0 root wheel 530 Jan 1 1970 +COMPACT_MANIFEST > > -rw-r--r-- 0 root wheel 6385 Jan 1 1970 +MANIFEST > > -rw-r--r-- 0 root wheel 17567 Jan 1 1970 +MTREE_DIRS > > -r--r--r-- 0 root wheel 19453 Jul 7 12:26 > > /usr/local/etc/bash_completion.d/_pkg.bash > > -r-xr-xr-x 0 root wheel 629 Jul 7 12:26 > > /usr/local/etc/periodic/daily/400.status-pkg > > -r-xr-xr-x 0 root wheel 823 Jul 7 12:26 > > /usr/local/etc/periodic/daily/411.pkg-backup > > -r-xr-xr-x 0 root wheel 678 Jul 7 12:26 > > /usr/local/etc/periodic/daily/490.status-pkg-changes > > -r-xr-xr-x 0 root wheel 2558 Jul 7 12:26 > > /usr/local/etc/periodic/security/410.pkg-audit > > -r-xr-xr-x 0 root wheel 611 Jul 7 12:26 > > /usr/local/etc/periodic/security/460.pkg-checksum > > -r--r--r-- 0 root wheel 839 Jul 7 12:26 > > /usr/local/etc/pkg.conf.sample > > -r--r--r-- 0 root wheel 43432 Jul 7 12:26 /usr/local/include/pkg.h > > -r--r--r-- 0 root wheel 727558 Jul 7 12:26 /usr/local/lib/libpkg.a > > lrwxr-xr-x 0 root wheel 0 Jul 7 12:26 /usr/local/lib/libpkg.so > > -> libpkg.so.1 > > -r--r--r-- 0 root wheel 1227064 Jul 7 12:26 /usr/local/lib/libpkg.s= o.1 > > -rw-r--r-- 0 root wheel 187 Jul 7 12:26 > > /usr/local/libdata/pkgconfig/pkg.pc > > [... etc ...] > >=20 >=20 > Interesting. I notice that (while looking ahead to see a prefix: of /usr/= local in the +MANIFEST), the tarball itself has files that include /usr/loc= al in their path. >=20 > Does pkg handle packages where the prefix (in +MANIFEST) is "/usr/local" = _but_ "tar tf" of the unxz'd tarball is _not_ "/usr/local"? (e.g. pkg_insta= ll style) or is this the new way going forward? >=20 >=20 >=20 > > There must at least be a +MANIFEST -- other meta data files are > > optional. +COMPACT_MANIFEST is a subset of the full +MANIFEST. They're > > both YAML documents. +COMPACT_MANIFEST looks like this, for example: > >=20 > > --- > > name: pkg > > version: 1.1.4 > > origin: ports-mgmt/pkg > > comment: New generation package manager > > arch: freebsd:9:x86:64 > > www: https://urldefense.proofpoint.com/v1/url?u=3Dhttp://wiki.freebsd.o= rg/pkgng&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2Fss= HJjg%3D%3D%0A&m=3DLPoff3ddLDoHE30AU6R5vgBklqxsjVAosXGjJop6uO4%3D%0A&s=3D30b= 27cf33d7e594144fc38f20bc75d84464788e715f7fc82b2495f813fd4be2d > > maintainer: portmgr@FreeBSD.org > > prefix: /usr/local > > licenselogic: single > > licenses: > > - BSD > > flatsize: 6311507 > > desc: | > > New Generation package management tool for FreeBSD > >=20 > > WWW: http://wiki.freebsd.org/pkgng > > categories: > > - ports-mgmt > > shlibs_required: > > - libpkg.so.1 > > shlibs_provided: > > - libpkg.so.1 > > message: | > > If you are upgrading from the old package format, first run: > >=20 > > # pkg2ng > >=20 >=20 > Nice. Very nice. >=20 >=20 >=20 > > +MTREE_DIRS is a compatibility thing with the old pkg_tools. It's not > > needed in general as +MANIFEST can provide all that meta data itself. > > It isn't going to be deprecated for at least as long as the ports tree > > continues to support pkg_tools though. > >=20 > > Beyond that, the rest of the pkg tarball just contains a tar archive of > > all the files, directories, sym-links etc to be installed by the > > package. Note that pkg(8) has no problem with creating an empty > > directory for a package, unlike pkg_tools. > >=20 >=20 > Excellent! >=20 >=20 > > Now, while you can grovel through the details of pkg tarballs and > > internal data formats like this, be aware: the format of the manifest > > and the details of the meta-data included in the pkg-tarballs is subject > > to change without warning as we develop pkg(8) further. We only promise > > API stability through the pkg(8) commands or for the libpkg.so library > > functions; reports of breakage from usage outside those APIs will > > receive little sympathy. > >=20 >=20 > Understood. >=20 > So just to give you a better idea of how we manage packages here. >=20 > We've realized that if you want to package for FreeBSD (in 9 and older), = you could get by alright if you knew how to create a +CONTENTS file from sc= ratch. For RedHat, it's the SPECFILE. And now for FreeBSD 10, it looks an a= wful lot like a SPECFILE (they are both in-fact YAML). The only thing you need if you really want to package is a small subset of = the manifest written in YAML: Have a look at what the ports tree do to create the minimalistic manifest a= nd what form it has and you will see how easy it is. It is so awful and complicated that there are already a load of custom scri= pts to create packages with pkg without using the ports tree. As an example: https://github.com/z0nt/pkg , but there is way more. I for example wrote in the past a plugin for pkg to be able to parse and USE RPM's specfiles as an input for pkg. >=20 > So rather than teach the people here how to use tools, I taught them what= I think is more important... how to manage +CONTENTS, SPECFILE, and now up= -and-coming, +MANIFEST. The problem is that you compare 2 things that cannot be compared, SPECFILE = is the equivalent of pkg + the ports tree. In fact specfiles are the equivalent of a given "port" !!! Are you writing = rpm files directly by hand? there is no SPECFILE inside RPM but rather a header container metadata in binary format and a body which is a cpio.(gz,bz2,xz). You are not creating the RPM file directly but rather create a SPECFILE, the equivalent on FreeBSD is to create a port!!! the +MANIFEST as used to be the +CONTENTS are the equivalent of the RPM metadata. We wrote them in YAML so = that they are easy to debug and that we can use third party well used and tested parsers instead of writting our own. >=20 > However, I'd be lying if I said I taught them *all* the gory details. In = reality, for +CONTENTS they edit a PLIST which is essentially +CONTENTS wit= hout the "@comment MD5:" entries. For SPECFILE, they manage the full thing = except there's a small section that is the standard RPM bootstrap that is l= abeled as "do not touch". >=20 > From what you posted of +COMPACT_MANIFEST was nice, except it lacks the l= ist of files. >=20 > The basic principle here is that if you have to maintain a list of files,= and that list ends up being compiled into a +MANIFEST, why not just teach = your peers how to read/write/maintain +MANIFEST files (in version control o= f course) so that there are never any mysteries as to how the package perfo= rms. Have a closer look at pkg create, you will see that we are still able to us= e the plist or +CONTENTS as a possible input for pkg create, it is even the main = way to create packages. Once again, the main and most important requirement to build packages was t= o be compatible with the ports tree, and the ports tree is using plist/+CONTENTS. and pkg2ng does only works by using the +CONTENTS. >=20 > I know this sounds screwy... but (as with our other YAML files), it's rea= lly nice because (as is the case with SPECFILE), we version-control things = as-close to the end-product as possible (take for example the case of "pre-= install" or "post-install" et cetera scripts -- I'm sure a tool like "pkg c= reate" or "pkg_create" or other could do a good job of assembling the piece= s into the +MANIFEST, but then it's not being version-controlled as closely. You can keep what you have already done. Once again pkg does not have the equivalent of the SPECFILE because we have= the ports tree! so we do not need to provide a custom package building system. We could, as it is really easy, but we do not need so it is not there yet, = as said earlier I already wrote a pkg plugin that is able to build packages fr= om a RPM specfile, I also modified archlinux's makepkg to be able to output pkgn= g files. I did the same on slackare, etc. Here the limitation is not technical at al= l. Bapt --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHjlUwACgkQ8kTtMUmk6Ew9UACggBbNenoJv7wzsrk3sTnaH6nu 4osAnjmGCuSJWFKVktv5ZnRPPWi2nTmj =QPsZ -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 06:28:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F9CF661; Mon, 15 Jul 2013 06:28:03 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by mx1.freebsd.org (Postfix) with ESMTP id CEECFB4D; Mon, 15 Jul 2013 06:28:02 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id k10so2446856wiv.5 for ; Sun, 14 Jul 2013 23:28:02 -0700 (PDT) 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=1kwP8c2k/4Z/WEwSrEVuliRkbGqICl8LZp6O6j8h8mw=; b=yaInu298mcYGUNQr4Iv/1jFpmFIfjO8fkoooDb8u1xVn0lEPOes4UTdhaGJlFLZBK5 xOqw5TKK01C49FHDOwX7bxLCx7xM2lV1xafjTX67zVef7snnOO+rO61iAJW1GceNTSv8 h+E7mPL/nZYmkU2T57EcQwKDshpDoqJKTmveoW2pbHJvDgSARU7WtwowajsqyLMWlZCq /nO27wnEuEh2lZ9Y23VNvDfXZI5CKIODa5nzb6hJsiih4RlJdxzvaTIhpB05QKWI5F43 ILg2BMf6eFT8G94fd9zNpz7/MB0KUqp68ABoVsSmjeymor6ue9pQQMFPmUPF5aTYjw3Y WQKQ== X-Received: by 10.194.93.74 with SMTP id cs10mr31131777wjb.9.1373869681953; Sun, 14 Jul 2013 23:28:01 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id h8sm18591904wie.1.2013.07.14.23.28.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 23:28:01 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 15 Jul 2013 08:27:59 +0200 From: Baptiste Daroussin To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130715062759.GF1516@ithaqua.etoilebsd.net> References: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HCdXmnRlPgeNBad2" Content-Disposition: inline In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-current@freebsd.org" , Garrett Wollman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 06:28:03 -0000 --HCdXmnRlPgeNBad2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 14, 2013 at 07:29:50AM +0000, Teske, Devin wrote: >=20 > > Or you > > can maintain the old cruft for your business -- just don't expect > > anyone else to use it, or even want to. > >=20 >=20 >=20 > I have no intention of making old-world packages... but I also have no in= tention of using "pkg create". So you are taking as an exemple rpm but with RPM you do want to use what th= ey do provide, aka rpmbuild but with pkgng you want to manually handwrite the pac= kages because we haven't hidden the format behind opaque names and format. You know in that case you should probably create your own RPM without RPM j= ust write by hand the header and happened the cpio to it, in that case you will= end up having the same at what you are trying to do with pkg. Bapt --HCdXmnRlPgeNBad2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHjlm8ACgkQ8kTtMUmk6EzFEQCeMdI9X/PKDdiwYRLe8UMB+US+ S7QAnjTxS3sW81IG0pfYMiTR3f/fP4OE =gBBe -----END PGP SIGNATURE----- --HCdXmnRlPgeNBad2-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 06:33:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E569C90F; Mon, 15 Jul 2013 06:33:43 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 4E567B88; Mon, 15 Jul 2013 06:33:43 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id l18so9649128wgh.2 for ; Sun, 14 Jul 2013 23:33:42 -0700 (PDT) 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=KMjL5y84vLtDViaE/Zqn4XS4G7WvFCh6k6zMo3jy2fk=; b=w8vqCw/7v6MAwdtfR7L8cbjn+BdTc8QNQFqMLgOIV26anTXfiSxci4rJE/AYK/sE/N CGUNPcrhURgYcsfLYzH0E45flbOimwfKNeCsB9CBXumXZYWoGwYtZQ+EGw+BQl4Vqodn sibySkzHgyVIS/CCF2Nf+PZowq34Q7jyx87YzuuwZkZ/rl5+ROxXe273OM7ecr5QVl12 WLb8G2iEpqgxWiR2NQD+61sPhMFfnXfrlIVdNQxC4Z7IwXGft7UZMMFbSs8Aqy6VQm4k pSkW1/J6qw2mi09TPI3E03S975Zxvy/aSAJH2se5ce7nZL8wvHoaxSParKDufHzoHVkh dYZw== X-Received: by 10.180.74.232 with SMTP id x8mr7752455wiv.48.1373870022358; Sun, 14 Jul 2013 23:33:42 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id iz8sm18093302wic.3.2013.07.14.23.33.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 23:33:41 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 15 Jul 2013 08:33:39 +0200 From: Baptiste Daroussin To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130715063339.GG1516@ithaqua.etoilebsd.net> References: <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nqkreNcslJAfgyzk" Content-Disposition: inline In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Chris Rees , "freebsd-current@freebsd.org" , Garrett Wollman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 06:33:44 -0000 --nqkreNcslJAfgyzk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 14, 2013 at 04:52:26PM +0000, Teske, Devin wrote: >=20 > On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: >=20 > > On 14 Jul 2013, at 08:29, Teske, Devin wrote: > >>=20 >=20 > Simple, really. >=20 > Let's take RPM for example. The RPM package format has been ported to oth= er platforms. So does pkgng ported on Linux, OS X, dragonfly, NetBSD... >=20 > But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install = it on RedHat. Yes you can, I do it at work all the time, on FreeBSD I do create AIX rpms = and RedHat rpms. >=20 > This is because the RPM format records the platform that you "build" your= RPM on (not the binaries, just the RPM) *into* said RPM. So does pkgng. >=20 > This actually adds a requirement to the RPM production that the RPMs be p= roduced on the platform that they will be installed-to. No. >=20 > Currently, no such restriction exists for the building of FreeBSD package= s (within our system). This would have been true if we had ported pkg_creat= e (and may continue to be true if we ported pkg and its ilk), but let's say= for the sake of argument that the future of "pkg" looks bright and it gets= ported to all sorts of systems (ported in a fashion similar to RPM) *and* = we find one day that the +MANIFEST starts containing a target-platform (res= ulting in refusal to install a *.txz package because it was rolled on a dif= ferent platform. Thank for describing the exact situation pkg is right now. >=20 > In that case, we'd then prefer to by-pass the tools and use our own metho= d of creating the tar-ball to lift such a restriction. The restriction you are speaking about does not exists. >=20 > ASIDE: If I knew how to force rpmbuild into creating androgynous packages= for other architectures, I'd be doing that to life the restriction there t= oo, but I haven't figured out that. >=20 > Basically... within our "pkgbase" tree, we like the branch within the tre= e to dictate how a package is built... not what platform you're on. The goa= l being that we can run a single package-build host that builds all of our = packages from a single platform. You can do it with pkgng just easily, as well as you can do it with rpm. Bapt --nqkreNcslJAfgyzk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHjl8MACgkQ8kTtMUmk6ExGPwCeL2zL58KJo1nZLNUpgam1nEeg yc8An3JN+3qqgXp8d4wA5rA1hfw76S4j =LWHv -----END PGP SIGNATURE----- --nqkreNcslJAfgyzk-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 06:38:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18AF8A90 for ; Mon, 15 Jul 2013 06:38:23 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id A0759BBB for ; Mon, 15 Jul 2013 06:38:22 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id ey16so2461602wid.3 for ; Sun, 14 Jul 2013 23:38:21 -0700 (PDT) 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=0SgOeskL1RMHaDIVAR+DUFslslTID3qiD/7mKYeRPtg=; b=uk9xiiiu/Vq16LDhFnwJdwUVhbKIvfaqJkZXkMeaDNT2Z4Xms+19P2ldGyrBTDlo8L /Pci8kB04MAR4VCeUydBtNVdGKP3+7PR5a2ijWUpd8WpI9LDU3b/erAGyRW9V6JO0zU7 GvyIWPTwEAcfzoPaZdsX38Vb5CH3tm5EU4M+TpBaxRrG8YHHaEElUSvZyWpAO2+EHjU3 aMGbIzJ78A3grIjDRc4TClugCT0ydSXm0DVTUy5oLO0VEPRcjUqy7FAS4E+qLbWZauUh 2JfXoIDvZFhrPT2Byq7E+Ne8wP6drVxmBjNNXKhLJZt9ToHZpatydCF/I0tbpfxbtpDk OjqA== X-Received: by 10.194.48.49 with SMTP id i17mr31659102wjn.55.1373870301861; Sun, 14 Jul 2013 23:38:21 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id u7sm12831948wiw.9.2013.07.14.23.38.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 23:38:21 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 15 Jul 2013 08:38:19 +0200 From: Baptiste Daroussin To: Mark Felder Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130715063818.GH1516@ithaqua.etoilebsd.net> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JI+G0+mN8WmwPnOn" Content-Disposition: inline In-Reply-To: <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 06:38:23 -0000 --JI+G0+mN8WmwPnOn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 13, 2013 at 06:51:00PM -0500, Mark Felder wrote: > On Sat, Jul 13, 2013, at 13:54, Teske, Devin wrote: > >=20 > >=20 > > If FTP access (or any of the other remote access methods) are going away > > for HEAD pkg access, I'll need to know so I can make the appropriate > > changes in the HEAD branch of bsdconfig. > > >=20 > It's simpler than you think. The new pkg uses libfetch. You can have > your PACAKGESITE be file:// ftp:// http:// https:// ...=20 >=20 > I do suspect that HTTP_PROXY support is probably not available as I > recall seeing a post where someone was asking about that getting > implemented for fetch. I'll have to research that again, though. Yes pkgng do support proxies, because libfetch do support them. pkgng also support ssh:// regards, Bapt --JI+G0+mN8WmwPnOn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHjmNoACgkQ8kTtMUmk6EwsRQCfeG2g+7KDXYdcBlSHbJXbpMMU YlwAoK454hrF+dXgKzjEktJmf166hCuw =d3M5 -----END PGP SIGNATURE----- --JI+G0+mN8WmwPnOn-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 06:42:09 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB35BCAE; Mon, 15 Jul 2013 06:42:09 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEACBE8; Mon, 15 Jul 2013 06:42:09 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id ey16so2494492wid.5 for ; Sun, 14 Jul 2013 23:42:08 -0700 (PDT) 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=2Gajk0VGddSm6ghHUu9jv6labrAncZXOva8d/tZpoZ8=; b=TLAqNEd8fmfklBpTAyAUEWUs0JfbxPjYlikSjXQ1dfU7FP6CdQvB212T64XQRSXIzs 66mTvaCzschlXe/NUzuA8RiycZnxlGcfahlZOtkzSOhTJi76DOZqtfhLI4EfRhDqsj2S YtioO+MEUtudzHKvBY4DTD/n3yKu5OZl4vORXa2qXdHBSX/P+wu8psR6yn2DVIDXvbgs RdjQ2u4JfTMI2L9TNCqdpkRG8Wg4N6XiLk5eSd8F7gU3z0zjCn+SgMtfD6TQLu/wgoG+ CiAXC0qZqe5cPJpdFjm4HJvYOGBCGar5Dw0W3z7wtU+zpdKRxz7Ogm8gV+qXcR3KuXlf iemw== X-Received: by 10.180.81.169 with SMTP id b9mr7769991wiy.40.1373870528389; Sun, 14 Jul 2013 23:42:08 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id fd3sm18599049wic.10.2013.07.14.23.42.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 23:42:07 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 15 Jul 2013 08:42:05 +0200 From: Baptiste Daroussin To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130715064205.GI1516@ithaqua.etoilebsd.net> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TA4f0niHM6tHt3xR" Content-Disposition: inline In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 06:42:09 -0000 --TA4f0niHM6tHt3xR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: > On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: >=20 > > Hi, > >=20 > > I have just committed (r253305) a change the make pkg_install not being= built > > and installed by default on HEAD. > >=20 > > If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes = in your > > src.conf(5) >=20 > I think while a good move, we need to allow a window of development to re= -work other HEAD components. >=20 > It might also be worth developing a lint-tool to make sure we get every l= ast instance (both from C code and sh code) within our base before we motio= n to cut a release with this change. >=20 > I for one am effected and will have to change things. >=20 > Can you point us at a guide (or even better, a Wiki) that can smooth the = process? I have already pointed you to such resources a couple of time before you st= arted working on the package management part of bsdconfig. May I remember you tha= t at this time I have recommanded you to directly work on the pkgng version? I h= ave also explained you 2 or 3 times at least what is a catalog in pkgng how it = works what pkg query and pkg rquery will give you as a script writter. Bapt --TA4f0niHM6tHt3xR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHjmb0ACgkQ8kTtMUmk6EyAvwCgoe1T3r1IRzRzaJTIki5T+j2M sp8AoJXrJIU+T8aMJDwEwEkirYwNcQMo =fulL -----END PGP SIGNATURE----- --TA4f0niHM6tHt3xR-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 07:31:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D84E290F; Mon, 15 Jul 2013 07:31:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFBFD6B; Mon, 15 Jul 2013 07:31:20 +0000 (UTC) Received: from Julian-MBP3.local (124-169-54-70.dyn.iinet.net.au [124.169.54.70]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r6F7V3IF049997 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 00:31:05 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51E3A531.6070206@freebsd.org> Date: Mon, 15 Jul 2013 15:30:57 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Craig Rodrigues Subject: Re: [HEADSUP] No more pkg_install on HEAD by default References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Felder , Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 07:31:20 -0000 On 7/15/13 6:43 AM, Craig Rodrigues wrote: > On Sat, Jul 13, 2013 at 10:54 PM, Teske, Devin wrote: > >> >> I assume that poudiere builds packages from ports. >> > Yes. > > >> That's not how we build package repositories here (and would expect that >> there are many more like us). >> > How do you build packages if you are not using FreeBSD ports? Do you have > your own Makefiles which resemble FreeBSD ports, > or are you doing something completely different? > > >> We expect to start with an empty directory, go grab packages that we >> want (one by one) from FTP. Then put those tarballs into a directory. >> There's no additional step because we download the INDEX file to the >> repository too. Local repository is built. >> > What FTP site are you grabbing packages from, the FreeBSD ftp site (or > mirrors) or one of your own? > How are you generating the INDEX file? Do you append to the INDEX file for > every package which you sucessfully download from FTP, > or are you downloading a previously generated INDEX file? What does your > local repository of packages consist of if you are > not using FreeBSD ports? > > >> >> >> But I want bsdconfig to work with local repositories without having >> poudriere. >> >> > You don't have to use poudriere to build a package repository. It is just > an optional tool that > is there for you to try out, and it works quite well when building a package > repository based off of FreeBSD ports. If you don't want to use it, you > don't have to. > > > >> >> I think so too. But right now a *lot* of unanswered questions. >> >> > Possibly, but I think that you are supporting a workflow that people on > this mailing list > don't fully understand. If you could send out a separate e-mail > describing exactly what your workflow is, step-by-step, that might help you > get better answers > to your questions. The FreeBSD ports team has been migrating to pkgng > for the past few years, so a lot of people understand the FreeBSD > ports/packages workflow. > because it has been discussed for a few years on multiple mailing lists, and > at various BSD conferences like BSDCan. What's so difficult to understand? He has a local cache, populated "as needed" from the binary packages released with the FreeBSD release, from the freebsd ftp site.. (He can as a supliment also add versions compiled by himself in the case of security fixes etc. but that isn't required for 99% of the packages. BSDinstall wants dependency information (currently availabele from the INDEX files) to display to the user what he will get) > > Some of the confusion with others on this list is that you are working on > a tool called "bsdconfig" and committing it into FreeBSD-CURRENT, > but the workflow you are trying to support is slightly different than what > the FreeBSD ports/packages teams have been supporting and adapting > their tools and workflow towards. > > I think that if you better describe your workflow in a separate e-mail, > then folks can better recommend how to adapt bsdconfig > to the new pkg tools. You may need to be open to using > things like libpkg inside bsdconfig, if that is the best solution for > bsdconfig inside FreeBSD. > > I agree with you that having a pkgng transition document on the wiki > would be useful for systems integrators. I know that many > people build products based on FreeBSD and leverage the pkg_XXX tools > for building their own products. I have done this myself in the past. > Clarifying the transition path for system integrators would be very helpful. > Maybe you can help write the transition doc, since you have the perspective? > > -- > Craig > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 07:40:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A246CE61; Mon, 15 Jul 2013 07:40:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 566AEDE5; Mon, 15 Jul 2013 07:40:40 +0000 (UTC) Received: from Julian-MBP3.local (124-169-54-70.dyn.iinet.net.au [124.169.54.70]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r6F7eUPh050052 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 00:40:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51E3A768.8030101@freebsd.org> Date: Mon, 15 Jul 2013 15:40:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Devin Teske Subject: Re: [HEADSUP] No more pkg_install on HEAD by default References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <13CA24D6AB415D428143D44749F57D7201FC48D7@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E7E@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC658E@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC658E@ltcfiswmsgmb21> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , Mark Felder , "freebsd-current@freebsd.org" , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 07:40:40 -0000 On 7/15/13 10:12 AM, Teske, Devin wrote: > On Jul 14, 2013, at 3:43 PM, Craig Rodrigues wrote: > > On Sat, Jul 13, 2013 at 10:54 PM, Teske, Devin > wrote: > > > I assume that poudiere builds packages from ports. > > Yes. > > > That's not how we build package repositories here (and would expect that there are many more like us). > > How do you build packages if you are not using FreeBSD ports? > > Two spectrums... > > When developer A says he needs xerces, I go to: > > (for an active release, such as 8.4 or 9.1) > ftp://ftp.freebsd.org/pub/FreeBSD/releases/{arch}/X.Y-RELEASE/packages/All > > (for an in-active release, such as 8.1 or 9.0) > ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/{arch}/X.Y-RELEASE/packages/All > > Meanwhile, when either developer B or integrator A says "I have software X that I want to package", we use "pkgbase" to build the FreeBSD package, the RedHat RPM, etc. > > Before you dismiss Devin's case as "corner case" I will point out to you that: 1/your pay checks are probably just one or two steps removed from his system, (almost anywhere in the world) 2/ that he is handling both FreeBSD packages AND Redhat packages , and that 3/ The last time I looked his systems were handling an amount of money per year that had 12 '0' s in it. It's probably way bigger now. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 08:22:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BC37D51; Mon, 15 Jul 2013 08:22:35 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF8C301; Mon, 15 Jul 2013 08:22:35 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id eh20so13655034obb.11 for ; Mon, 15 Jul 2013 01:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ML8mAzaKGXcprMpE7d1tdzoudWm8DIWX5xVyIVDXURU=; b=WqyYllFGaaEefXlaxxyBzv5etUPyEnKiqT8qZzSZzGKA5rE0W1eIylPf8s9IekK9UX H4ka2/MPVss/wII/UeCtvR3RMHs/gjZ6WsfHmYB1gpBXBQVHlFRszEcjsZ4cOX6Mwgik Cvfau2xTEnRdkOPTJV7LN5z/wwhKm20HUdmLqMX8J0quNvSxVrvV156RXkaQDomcggFa G712OtpCI0UJfelXiG04x/ombMOlIV7hW2FDxdi3Skql0A3BU7zuUiBN5lw+Bq9jddRK UFv0NDRcNcxAtN2UIOQMp9Z4lredplgLX16bCGL9E/ndeoyMq3SjdREJMVWGEhqnKZdk cP1g== MIME-Version: 1.0 X-Received: by 10.60.45.103 with SMTP id l7mr42631717oem.25.1373876554838; Mon, 15 Jul 2013 01:22:34 -0700 (PDT) Sender: uspoerlein@gmail.com Received: by 10.76.9.5 with HTTP; Mon, 15 Jul 2013 01:22:34 -0700 (PDT) In-Reply-To: <51E0775F.3070805@FreeBSD.org> References: <20130712205446.GB2198@acme.spoerlein.net> <51E0775F.3070805@FreeBSD.org> Date: Mon, 15 Jul 2013 10:22:34 +0200 X-Google-Sender-Auth: m98gkfofsgl8cgG7I17VMUAikaY Message-ID: Subject: Re: Sound lag over HDMI From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 08:22:35 -0000 2013/7/12 Alexander Motin : > On 12.07.2013 23:54, Ulrich Sp=C3=B6rlein wrote: >> >> I'm trying to setup XBMC on a -CURRENT box with an IvyBridge CPU and >> GPU. While testing playback via mplayer on a LG TV over HDMI, I noticed >> that sound is lagging video by about 100-200ms or so. When I switch to >> using the jack outputs powered by some Realtek chip, audio is perfectly >> fine. >> >> Is HDMI lag a known problem? Can this be fixed? >> >> root@coyote:~# dmesg | egrep vgapci\|pcm >> vgapci0: port 0x3000-0x303f mem >> 0xe0000000-0xe03fffff,0xc0000000-0xdfffffff irq 16 at device 2.0 on pci0 >> agp0: on vgapci0 >> pcm0: at nid 20 and 24 on hdaa0 >> pcm1: at nid 30 and 31 on hdaa0 >> pcm2: at nid 6 on hdaa1 >> pcm3: at nid 7 on hdaa1 >> drmn0: on vgapci0 > > > I don't know what to say. I am now using HDMI audio from NVIDIA card to > quite old external 5.1 receiver with XBMC every day, and I haven't notice= d > lags. Before that I've also successfully used SPDIF connection for the lo= ng > time. Though I've never specially tested it somehow other then watching > movies. :) If you have some good testing methodology -- please, welcome t= o > share. By the HDA driver HDMI is handled exactly the same way as analog > output from the point of data buffering, so I would not expect there majo= r > differences. > > You may try to experiment with hw.snd.latency sysctl to tune buffering in > kernel to see whether it affect the result. > > Also you may compare delays when doing AC3/DTS pass-through with case of > software decoding and discrete (multichannel) PCM playback. > > The only potentially related effect I have noticed is that my receiver ea= ts > first second or about that of playback stream. It makes short sounds like > GUI event notifications inaudible sometimes. I guess that could be made t= o > restore audio sync after some unavoidable startup delay, but that is only= my > guess. Hmm, weird. I've rebooted the machine (it was up more than 30d before I eve= r started up Xorg or any sound-using application), and maybe that fixed some contigmalloc issues or something, because I can no longer reproduce the problem. I've had problems like this on an old laptop, where if I didn't start X11 within 24h of rebooting, it wouldn't start up. This system is using ZFS of course, so unless you take memory early on, ZFS will have eaten it :) Anyway, thanks for your suggestions and I can confirm everything's fine. Af= ter fixing the /dev/dri/card0 permission problem, even XBMC works like a charm on this system. Cheers, Uli From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 09:16:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD890172 for ; Mon, 15 Jul 2013 09:16:41 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) by mx1.freebsd.org (Postfix) with ESMTP id 62785A63 for ; Mon, 15 Jul 2013 09:16:40 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.norma.com [192.168.7.159]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r6F9GbsC027461 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 15 Jul 2013 15:16:37 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <51E3BDF5.7030602@norma.perm.ru> Date: Mon, 15 Jul 2013 15:16:37 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130709 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 References: <51CFDC86.2040506@FreeBSD.org> <20130630111836.GB22492@dft-labs.eu> <20130701231011.GA1406@garage.freebsd.pl> In-Reply-To: <20130701231011.GA1406@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 15 Jul 2013 15:16:37 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 09:16:41 -0000 Hi. On 02.07.2013 05:10, Pawel Jakub Dawidek wrote: > On Sun, Jun 30, 2013 at 01:18:36PM +0200, Mateusz Guzik wrote: >> >> Turns out the bug is quite funny ;) >> >> Try this: >> diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c >> index 5d8e814..7a4db04 100644 >> --- a/sys/kern/uipc_usrreq.c >> +++ b/sys/kern/uipc_usrreq.c >> @@ -1764,8 +1764,8 @@ unp_externalize(struct mbuf *control, struct mbuf **controlp, int flags) >> } >> for (i = 0; i < newfds; i++, fdp++) { >> fde = &fdesc->fd_ofiles[*fdp]; >> - fde->fde_file = fdep[0]->fde_file; >> - filecaps_move(&fdep[0]->fde_caps, >> + fde->fde_file = fdep[i]->fde_file; >> + filecaps_move(&fdep[i]->fde_caps, >> &fde->fde_caps); >> if ((flags & MSG_CMSG_CLOEXEC) != 0) >> fde->fde_flags |= UF_EXCLOSE; > Thanks for tracking it down before I had time to get to it! > The change looks good. > Guys, if this is working, why it's not commited to HEAD ? I'm still hitting this bug on r251990 and later ones. Thanks. Eugene. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 09:22:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8BF35C6 for ; Mon, 15 Jul 2013 09:22:28 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) by mx1.freebsd.org (Postfix) with ESMTP id 40C1BACE for ; Mon, 15 Jul 2013 09:22:27 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.norma.com [192.168.7.159]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r6F9MPXP027998 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 15 Jul 2013 15:22:25 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <51E3BF51.6090905@norma.perm.ru> Date: Mon, 15 Jul 2013 15:22:25 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130709 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 References: <51CFDC86.2040506@FreeBSD.org> <20130630111836.GB22492@dft-labs.eu> <20130701231011.GA1406@garage.freebsd.pl> <51E3BDF5.7030602@norma.perm.ru> In-Reply-To: <51E3BDF5.7030602@norma.perm.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 15 Jul 2013 15:22:25 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 09:22:28 -0000 Hi. On 15.07.2013 15:16, Eugene M. Zheganin wrote: > > Guys, if this is working, why it's not commited to HEAD ? I'm still > hitting this bug on r251990 and later ones. > I'm terribly sorry, I should read the revisions more carefully. Eugene. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 09:25:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6AE07715 for ; Mon, 15 Jul 2013 09:25:44 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 03194AFB for ; Mon, 15 Jul 2013 09:25:43 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id c10so2604622wiw.17 for ; Mon, 15 Jul 2013 02:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=64Hb3/3QTviP+OBXBE+nzHHl3aeOQnA6c8M3C+LEfic=; b=c9N42/2HcPMR/SvXsIlwSoGMEE8LgdXL5PSniAFiu0acDXqH2BNQ6VeYv73RP0V72J BJKYC4bBVZnAE4A/Ji8BzUtz3gd3lfRpTvExxce6ySQPKLsRWy5v+gEQYK1EQnFn0894 VwDrmOELNBseLxtlTWlQK94k3ddhfna8Pt3+L/RNy+X5bptk4yu567qfFPV/y6BV8ppR l9WaaGzPfjz6wfJimouWGlgjkQHrQdm8tGebewoGJNdP4FrNNK7usqJQTbUSihwA5uoL rKnn7zRh5m1pnkSO/YfiFxQN+kvTgD40qQ+75B59Bt4UToiyAbeli3q+N245BdlJNnBm Cbgg== X-Received: by 10.194.103.226 with SMTP id fz2mr30803009wjb.75.1373880343030; Mon, 15 Jul 2013 02:25:43 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id s19sm19490481wik.11.2013.07.15.02.25.40 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 15 Jul 2013 02:25:41 -0700 (PDT) Date: Mon, 15 Jul 2013 11:25:37 +0200 From: Mateusz Guzik To: "Eugene M. Zheganin" Subject: Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 Message-ID: <20130715092537.GA22424@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , "Eugene M. Zheganin" , freebsd-current@freebsd.org References: <51CFDC86.2040506@FreeBSD.org> <20130630111836.GB22492@dft-labs.eu> <20130701231011.GA1406@garage.freebsd.pl> <51E3BDF5.7030602@norma.perm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51E3BDF5.7030602@norma.perm.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 09:25:44 -0000 On Mon, Jul 15, 2013 at 03:16:37PM +0600, Eugene M. Zheganin wrote: > Hi. > > On 02.07.2013 05:10, Pawel Jakub Dawidek wrote: > > On Sun, Jun 30, 2013 at 01:18:36PM +0200, Mateusz Guzik wrote: > >> > >> Turns out the bug is quite funny ;) > >> > >> Try this: > >> diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c > >> index 5d8e814..7a4db04 100644 > >> --- a/sys/kern/uipc_usrreq.c > >> +++ b/sys/kern/uipc_usrreq.c > >> @@ -1764,8 +1764,8 @@ unp_externalize(struct mbuf *control, struct mbuf **controlp, int flags) > >> } > >> for (i = 0; i < newfds; i++, fdp++) { > >> fde = &fdesc->fd_ofiles[*fdp]; > >> - fde->fde_file = fdep[0]->fde_file; > >> - filecaps_move(&fdep[0]->fde_caps, > >> + fde->fde_file = fdep[i]->fde_file; > >> + filecaps_move(&fdep[i]->fde_caps, > >> &fde->fde_caps); > >> if ((flags & MSG_CMSG_CLOEXEC) != 0) > >> fde->fde_flags |= UF_EXCLOSE; > > Thanks for tracking it down before I had time to get to it! > > The change looks good. > > > Guys, if this is working, why it's not commited to HEAD ? I'm still > hitting this bug on r251990 and later ones. > The patch was committed in r252502. Is that kernel crashing for you? If so, can you show backtrace? -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 13:34:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D019785F for ; Mon, 15 Jul 2013 13:34:12 +0000 (UTC) (envelope-from feld@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A92AAAF6 for ; Mon, 15 Jul 2013 13:34:12 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B355320ECD for ; Mon, 15 Jul 2013 09:34:05 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Mon, 15 Jul 2013 09:34:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=QvFGX7BTZIy/yr9VRu13b+Jtn2Y=; b=NCV aIbdUo/CN8xuScZth6gyKcsfhxKs+BZz1D+mxd1Dq9XQ0X2gb/hPYrGSl2CAf3bc v9BzlkLNgbHoWJwDE/wZKdLhuJYVS6AE+bpH3/IGiGKGq9cp1yMUhj02wu+8kxhM FfTBxwXURkEUIREv4yIVMbMnicEdQiA6X2/0e5Jo= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 97D56B00003; Mon, 15 Jul 2013 09:34:05 -0400 (EDT) Message-Id: <1373895245.27518.140661255822389.195BA409@webmail.messagingengine.com> X-Sasl-Enc: DXab8geLWsrFoWyJAeaJ+zKoggKqRLUSqjC2ELz/UhD8 1373895245 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-bdcdd1cb In-Reply-To: <201307141949.r6EJnZPp009319@hergotha.csail.mit.edu> References: <201307141949.r6EJnZPp009319@hergotha.csail.mit.edu> Subject: Re: Ports with daemons on uninstall... Date: Mon, 15 Jul 2013 08:34:05 -0500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 13:34:12 -0000 On Sun, Jul 14, 2013, at 14:49, Garrett Wollman wrote: > > Strongly agreed -- and it's what other operating systems do, either by > policy or by convention. > As long as this behavior only happens during pkg installs and never with ports, I'm OK. The worst is when a coworker forgets that the mysql port stops the daemon and my coworker upgrades with portmaster... the daemon is off the entire time mysql slowly compiles... From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 13:44:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B876A68 for ; Mon, 15 Jul 2013 13:44:12 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 038E3B68 for ; Mon, 15 Jul 2013 13:44:11 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hj3so2877765wib.0 for ; Mon, 15 Jul 2013 06:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=k92F43j/878PxckyIqwWCwnqe34qtPjQ3AYN6IsM6sE=; b=Hz8u/N6GO5x+YSWRnwaLKGuK40xJHm8IqSIGwQJo8Ho0N0ToAKElhYnhpsmB2VVRjP M1w0f9lyyvYfxux5JiawhD0YWucLwn4FS2UYBPQRi25NNiVGVhwqhF0HjB9+RnnUB9kZ m18uIges74ab+H8l54TCHo9VKM1+K+nC0hbDIZ4z6bZ5coTNCCHFaIkOeurfSXGS6irL wWounkmDmTX1iXPcBEpr8yXjYqYJj/Rk52vUiKHAYURjHbwATq7tZGFuX9ic6MpdfGPb wbhuCoxLgHry5M9MknL4PszC5qe5LYH/28Iu8R3pN50JEOOQfdwVn00Z3+T4NwjMzLil 3dAA== X-Received: by 10.194.82.97 with SMTP id h1mr31481364wjy.95.1373895851196; Mon, 15 Jul 2013 06:44:11 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPSA id i1sm21028142wiz.6.2013.07.15.06.44.09 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 15 Jul 2013 06:44:10 -0700 (PDT) Date: Mon, 15 Jul 2013 14:44:08 +0100 From: RW To: freebsd-current@freebsd.org Subject: Re: Ports with daemons on uninstall... Message-ID: <20130715144408.6af32858@gumby.homeunix.com> In-Reply-To: <1373895245.27518.140661255822389.195BA409@webmail.messagingengine.com> References: <201307141949.r6EJnZPp009319@hergotha.csail.mit.edu> <1373895245.27518.140661255822389.195BA409@webmail.messagingengine.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd10.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.14 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, 15 Jul 2013 13:44:12 -0000 On Mon, 15 Jul 2013 08:34:05 -0500 Mark Felder wrote: > On Sun, Jul 14, 2013, at 14:49, Garrett Wollman wrote: > > > > Strongly agreed -- and it's what other operating systems do, either > > by policy or by convention. > > > > As long as this behavior only happens during pkg installs and never > with ports, I'm OK. The worst is when a coworker forgets that the > mysql port stops the daemon and my coworker upgrades with > portmaster... the daemon is off the entire time mysql slowly > compiles... Is that really correct? I would expect the deinstall to be done after the build has completed successfully. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 13:46:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31318CAA for ; Mon, 15 Jul 2013 13:46:38 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id E8B57B94 for ; Mon, 15 Jul 2013 13:46:37 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Uyj6f-0001KR-Pt for freebsd-current@freebsd.org; Mon, 15 Jul 2013 15:46:25 +0200 Received: from cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com ([86.21.186.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jul 2013 15:46:25 +0200 Received: from walterhurry by cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jul 2013 15:46:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Walter Hurry Subject: Re: Ports with daemons on uninstall... Date: Mon, 15 Jul 2013 13:46:03 +0000 (UTC) Lines: 11 Message-ID: References: <201307141949.r6EJnZPp009319@ hergotha.csail.mit.edu> <1373895245.27518.140661255822389.195BA409@webmail. messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 13:46:38 -0000 On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote: > As long as this behavior only happens during pkg installs and never with > ports, I'm OK. The worst is when a coworker forgets that the mysql port > stops the daemon and my coworker upgrades with portmaster... the daemon > is off the entire time mysql slowly compiles... I'm not familiar with portmaster, since I use portupgrade. That does the build first, then the deinstall old/install new. Seems a sensible approach anyway, in case the build fails. Doesn't portmaster work similarly? From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 13:56:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3E4978 for ; Mon, 15 Jul 2013 13:56:54 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id B7678C16 for ; Mon, 15 Jul 2013 13:56:54 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 0698B6A6000; Mon, 15 Jul 2013 15:56:53 +0200 (CEST) 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 r6FDuqlW018164; Mon, 15 Jul 2013 15:56:52 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id r6FDuqc2016970; Mon, 15 Jul 2013 15:56:52 +0200 (CEST) (envelope-from lars) Date: Mon, 15 Jul 2013 15:56:52 +0200 From: Lars Engels To: Walter Hurry Subject: Re: Ports with daemons on uninstall... Message-ID: <20130715135652.GR88288@e-new.0x20.net> References: <201307141949.r6EJnZPp009319@hergotha.csail.mit.edu> <1373895245.27518.140661255822389.195BA409@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sAMF9MHkXj43A5i+" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.4-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 13:56:55 -0000 --sAMF9MHkXj43A5i+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 01:46:03PM +0000, Walter Hurry wrote: > On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote: >=20 > > As long as this behavior only happens during pkg installs and never with > > ports, I'm OK. The worst is when a coworker forgets that the mysql port > > stops the daemon and my coworker upgrades with portmaster... the daemon > > is off the entire time mysql slowly compiles... >=20 > I'm not familiar with portmaster, since I use portupgrade. That does the= =20 > build first, then the deinstall old/install new. Seems a sensible=20 > approach anyway, in case the build fails. Doesn't portmaster work=20 > similarly? Yes. PM builds, creates a backup package, deinstalls the old packages, installs the new one. --sAMF9MHkXj43A5i+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHj/6QACgkQKc512sD3afjB6wCguim1pd/eSzM8BlpPH6vQiPah zC0AnRVG2O8LVEzBLl4WXS+Rkag4pB/y =iQ38 -----END PGP SIGNATURE----- --sAMF9MHkXj43A5i+-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 14:01:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D52C23C; Mon, 15 Jul 2013 14:01:28 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id BFAD8C50; Mon, 15 Jul 2013 14:01:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id 6CBE92A832AF; Mon, 15 Jul 2013 16:01:24 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF1lOne9zxAW; Mon, 15 Jul 2013 16:01:23 +0200 (SAST) Received: from clue.co.za (41-135-71-48.dsl.mweb.co.za [41.135.71.48]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 9DCAC2A83265; Mon, 15 Jul 2013 16:01:23 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UyjL7-00012X-W2; Mon, 15 Jul 2013 16:01:22 +0200 To: current@freebsd.org Subject: r253351 implicit definition of 'critical_exit'. From: "Ian FREISLICH" X-Attribution: BOFH Date: Mon, 15 Jul 2013 16:01:21 +0200 Message-Id: Cc: ae@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 14:01:28 -0000 Hi Recent change: ----- # svn log ./sys/sys/sf_buf.h |less ------------------------------------------------------------------------ r253351 | ae | 2013-07-15 08:16:57 +0200 (Mon, 15 Jul 2013) | 6 lines Introduce new structure sfstat for collecting sendfile's statistics and remove corresponding fields from struct mbstat. Use PCPU counters and SFSTAT_INC() macro for update these statistics. ----- Includes sys/counter.h in sys/sf_buf.h. sys/counter.h uses macros defined in sys/systm.h resulting in implicit definitions of critical_exit and others and then errors in conflicting types for critical_exit later when sys/system.h is includd _after_ sys/sf_buf.h in sys/i386/i386/uio_machdep.c. I haven't checked amd64 yet, but this patch fixes the build: Index: /usr/src/sys/i386/i386/uio_machdep.c =================================================================== --- /usr/src/sys/i386/i386/uio_machdep.c (revision 253361) +++ /usr/src/sys/i386/i386/uio_machdep.c (working copy) @@ -44,8 +44,8 @@ #include #include #include +#include #include -#include #include #include However, sys/system.h coul equally be included in sys/sf_buf.h before sys/counter.h. I don't know which is the correct fix. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 14:13:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CC2D1540; Mon, 15 Jul 2013 14:13:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A21F5CDA; Mon, 15 Jul 2013 14:13:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6FEDfNY098482; Mon, 15 Jul 2013 10:13:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6FEDfBT098467; Mon, 15 Jul 2013 14:13:41 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Jul 2013 14:13:41 GMT Message-Id: <201307151413.r6FEDfBT098467@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:13:48 -0000 TB --- 2013-07-15 10:40:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-15 10:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-15 10:40:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-15 10:40:20 - cleaning the object tree TB --- 2013-07-15 10:40:20 - /usr/local/bin/svn stat /src TB --- 2013-07-15 10:40:25 - At svn revision 253358 TB --- 2013-07-15 10:40:26 - building world TB --- 2013-07-15 10:40:26 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 10:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 10:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 10:40:26 - SRCCONF=/dev/null TB --- 2013-07-15 10:40:26 - TARGET=i386 TB --- 2013-07-15 10:40:26 - TARGET_ARCH=i386 TB --- 2013-07-15 10:40:26 - TZ=UTC TB --- 2013-07-15 10:40:26 - __MAKE_CONF=/dev/null TB --- 2013-07-15 10:40:26 - cd /src TB --- 2013-07-15 10:40:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 15 10:40:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 15 13:53:20 UTC 2013 TB --- 2013-07-15 13:53:20 - generating LINT kernel config TB --- 2013-07-15 13:53:20 - cd /src/sys/i386/conf TB --- 2013-07-15 13:53:20 - /usr/bin/make -B LINT TB --- 2013-07-15 13:53:20 - cd /src/sys/i386/conf TB --- 2013-07-15 13:53:20 - /usr/sbin/config -m LINT TB --- 2013-07-15 13:53:20 - building LINT kernel TB --- 2013-07-15 13:53:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 13:53:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 13:53:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 13:53:20 - SRCCONF=/dev/null TB --- 2013-07-15 13:53:20 - TARGET=i386 TB --- 2013-07-15 13:53:20 - TARGET_ARCH=i386 TB --- 2013-07-15 13:53:20 - TZ=UTC TB --- 2013-07-15 13:53:20 - __MAKE_CONF=/dev/null TB --- 2013-07-15 13:53:20 - cd /src TB --- 2013-07-15 13:53:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 15 13:53:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/i386/i386/uio_machdep.c:48: /src/sys/sys/systm.h:190:6: error: conflicting types for 'critical_exit' void critical_exit(void); ^ ./machine/counter.h:172:3: note: previous implicit declaration is here critical_exit(); ^ 4 errors generated. *** Error code 1 Stop. make: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-15 14:13:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-15 14:13:41 - ERROR: failed to build LINT kernel TB --- 2013-07-15 14:13:41 - 10280.59 user 1830.15 system 12800.34 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 14:23:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 62F38982 for ; Mon, 15 Jul 2013 14:23:23 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 001E0D93 for ; Mon, 15 Jul 2013 14:23:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id AAEEF2A83304; Mon, 15 Jul 2013 16:23:21 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmG76Fo3WCx4; Mon, 15 Jul 2013 16:23:21 +0200 (SAST) Received: from clue.co.za (41-135-71-48.dsl.mweb.co.za [41.135.71.48]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id D1B6E2A83303; Mon, 15 Jul 2013 16:23:20 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UyjgO-000175-0o; Mon, 15 Jul 2013 16:23:20 +0200 To: Walter Hurry From: Ian FREISLICH Subject: Re: Ports with daemons on uninstall... In-Reply-To: References: <201307141949.r6EJnZPp009319@ hergotha.csail.mit.edu> <1373895245.27518.140661255822389.195BA409@webmail. messagingengine.com> X-Attribution: BOFH Date: Mon, 15 Jul 2013 16:23:20 +0200 Message-Id: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 14:23:23 -0000 Walter Hurry wrote: > On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote: > > > As long as this behavior only happens during pkg installs and never with > > ports, I'm OK. The worst is when a coworker forgets that the mysql port > > stops the daemon and my coworker upgrades with portmaster... the daemon > > is off the entire time mysql slowly compiles... > > I'm not familiar with portmaster, since I use portupgrade. That does the > build first, then the deinstall old/install new. Seems a sensible > approach anyway, in case the build fails. Doesn't portmaster work > similarly? Try doing a 'portupgrade -f isc-dhcp41-server' and watch it leave dhcpd not running. I eventually made the following change so that it wouldn't leave my system in a broken state: /usr/ports/net/isc-dhcp41-server # make clean ===> Cleaning for isc-dhcp41-server-4.1.e_7,2 [fw2.smmt] /usr/ports/net/isc-dhcp41-server # svn diff Index: pkg-plist =================================================================== --- pkg-plist (revision 323024) +++ pkg-plist (working copy) @@ -1,6 +1,4 @@ @comment $FreeBSD$ -@unexec %D/etc/rc.d/isc-dhcpd forcestop 2>/dev/null || true -%%IPV6%%@unexec %D/etc/rc.d/isc-dhcpd6 forcestop 2>/dev/null || true @unexec if cmp -s %D/etc/dhcpd.conf.sample %D/etc/dhcpd.conf; then rm -f %D/etc/dhcpd.conf; fi etc/dhcpd.conf.sample @exec if [ ! -f %D/etc/dhcpd.conf ] ; then cp -p %D/%F %B/dhcpd.conf; fi I don't mind it stopping the daemon, but if it's going to automatically stop it, it should automatically start it too. It's also not consistent - random sample of two: exim and quagga just leave the daemon running. I'm just asking if there's a stated project guideline for what should happen because at the moment it's hard to know what to expect. Maybe its as simple as an install exec that does a 'service foo start'. If it's a first install it will fail because foo_enable="yes" won't be set in /etc/rc.conf. Personally, I'd rather that the package management system ports,pkg,etc doesn't take liberties with my running daemons. If I want to kill them off, I'll kill them off, but there have been several times where I've left uninstalled things running while the system was in flux during an upgrade. It was nice to be able to do that. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 14:56:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CBADF835; Mon, 15 Jul 2013 14:56:48 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id 4242DF3; Mon, 15 Jul 2013 14:56:48 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ey16so2971805wid.10 for ; Mon, 15 Jul 2013 07:56:46 -0700 (PDT) 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=ecgDsXW7/38c4+fMtfdThkcC8bpv/QY2RHmjTsL23Lk=; b=b6Zs4ijNT5VJPNWG2rlC4lUVz00BjdMzLc272OfbkCp4cWbL8UeILGeFR5k70EctUV nuYbTZopgom65laAFxxWAi3I7vnZNqxKzvrr01HTZNmuO64DOUv8urwweYLc0d7eEO3U KzialqR3plMD/XZv28PiguXE+ih0zVuVOiwcnBYAR+VH2OQikGZf6tNpSZv0Vi7ROtUx mZLPJIVxe3i5i8ScHAwaEvga3rqa0opxdnvEv1GiAuh2GKeDmbX7oyEczH12GhLejeWa BW5nnPKCUOnurFvqWF76jDKBoOWU6vQa1CsxjdJcWVj7iE9FEl8cTdY+EnFyV0hblT21 bUlw== MIME-Version: 1.0 X-Received: by 10.180.13.5 with SMTP id d5mr9095017wic.56.1373900206725; Mon, 15 Jul 2013 07:56:46 -0700 (PDT) Received: by 10.216.82.70 with HTTP; Mon, 15 Jul 2013 07:56:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 18:56:46 +0400 Message-ID: Subject: Re: r253351 implicit definition of 'critical_exit'. From: Sergey Kandaurov To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Cc: ae@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 14:56:48 -0000 On 15 July 2013 18:01, Ian FREISLICH wrote: > Hi > > Recent change: > ----- > # svn log ./sys/sys/sf_buf.h |less > ------------------------------------------------------------------------ > r253351 | ae | 2013-07-15 08:16:57 +0200 (Mon, 15 Jul 2013) | 6 lines > > Introduce new structure sfstat for collecting sendfile's statistics > and remove corresponding fields from struct mbstat. Use PCPU counters > and SFSTAT_INC() macro for update these statistics. > ----- > > Includes sys/counter.h in sys/sf_buf.h. sys/counter.h uses macros > defined in sys/systm.h resulting in implicit definitions of > critical_exit and others and then errors in conflicting types for > critical_exit later when sys/system.h is includd _after_ sys/sf_buf.h > in sys/i386/i386/uio_machdep.c. > > I haven't checked amd64 yet, but this patch fixes the build: > > Index: /usr/src/sys/i386/i386/uio_machdep.c > =================================================================== > --- /usr/src/sys/i386/i386/uio_machdep.c (revision 253361) > +++ /usr/src/sys/i386/i386/uio_machdep.c (working copy) > @@ -44,8 +44,8 @@ > #include > #include > #include > +#include > #include > -#include > #include > > #include > > However, sys/system.h coul equally be included in sys/sf_buf.h > before sys/counter.h. I don't know which is the correct fix. AFAIK, this is because systm.h isn't properly sorted here (also in amd64 and probably others). It should go right after sys/param.h. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 14:57:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2261A3D for ; Mon, 15 Jul 2013 14:57:28 +0000 (UTC) (envelope-from feld@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 794A910C for ; Mon, 15 Jul 2013 14:57:28 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 129D1212C9 for ; Mon, 15 Jul 2013 10:57:27 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Mon, 15 Jul 2013 10:57:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=bDNfXjUSfo3mi2sGgex7iuzyeIk=; b=EHQ myprPMvIP8gMAkRmJGHXgK3XZPZln83J1wjX+VoAiOUaUCeu6Iz1svhOGwbeGZj8 5k7hW4yByZzhb3yltEnvSii6tohpJWRp6mEdolGsNes1J8xGeKamHTGZeASOHPLV XtCyqb+GTfGKPBABkQyfF+g9EMy6xZAjBviud3D0= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id EB6E6B00003; Mon, 15 Jul 2013 10:57:26 -0400 (EDT) Message-Id: <1373900246.23916.140661255858745.1BA622A0@webmail.messagingengine.com> X-Sasl-Enc: /nePLMVrEpH81ZIJ3s/evZ1+/XXaHB2w8QXlVVBjT0uT 1373900246 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-bdcdd1cb In-Reply-To: <20130715144408.6af32858@gumby.homeunix.com> References: <201307141949.r6EJnZPp009319@hergotha.csail.mit.edu> <1373895245.27518.140661255822389.195BA409@webmail.messagingengine.com> <20130715144408.6af32858@gumby.homeunix.com> Subject: Re: Ports with daemons on uninstall... Date: Mon, 15 Jul 2013 09:57:26 -0500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 14:57:28 -0000 On Mon, Jul 15, 2013, at 8:44, RW wrote: > > Is that really correct? I would expect the deinstall to be done after > the build has completed successfully. > That might not be accurate with a current portmaster, but we used to have that happen all too frequently. I just checked the plist and it has @stopdaemon mysql-server, so I'm guessing portmaster would run that too prematurely. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:06:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 880E5C16; Mon, 15 Jul 2013 16:06:52 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id A605477F; Mon, 15 Jul 2013 16:06:51 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FG6o8Q029293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 11:06:50 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Mon, 15 Jul 2013 11:06:49 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAnyqAgAAXnwCAAD4lgIAAC4sAgAFSTgCAAKMTAA== Date: Mon, 15 Jul 2013 16:06:48 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC7331@ltcfiswmsgmb21> References: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC4E0D@ltcfiswmsgmb21> <51E26FD3.4020208@FreeBSD.org> <13CA24D6AB415D428143D44749F57D7201FC547A@ltcfiswmsgmb21> <20130715062308.GE1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715062308.GE1516@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-15_04:2013-07-15,2013-07-15,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Devin Teske , Matthew Seaman , "current@FreeBSD.org" , Peter Wemm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:06:52 -0000 On Jul 14, 2013, at 11:23 PM, Baptiste Daroussin wrote: On Sun, Jul 14, 2013 at 10:12:19AM +0000, Teske, Devin wrote: On Jul 14, 2013, at 2:30 AM, Matthew Seaman wrote: On 14/07/2013 06:48, Teske, Devin wrote: Question: Where can I learn more about the actual format of what's in the new tarballs? This is going to be important not for bsdconfig, but $work (we have our own build platform; I'm going to have to rewrite it from mastering PLIST files to mastering YAML MANIFEST files and I want to know all the gritty details). We do need a pkg-manifest(5) man page, which can double as a pkg-tarball(5) page since the manifest file is where most of the interesting bits are. A pkg tarball is a compressed tar archive like so: lucid-nonsense:...cache/pkg/All:% tar -tvf pkg-1.1.4.txz -rw-r--r-- 0 root wheel 530 Jan 1 1970 +COMPACT_MANIFEST -rw-r--r-- 0 root wheel 6385 Jan 1 1970 +MANIFEST -rw-r--r-- 0 root wheel 17567 Jan 1 1970 +MTREE_DIRS -r--r--r-- 0 root wheel 19453 Jul 7 12:26 /usr/local/etc/bash_completion.d/_pkg.bash -r-xr-xr-x 0 root wheel 629 Jul 7 12:26 /usr/local/etc/periodic/daily/400.status-pkg -r-xr-xr-x 0 root wheel 823 Jul 7 12:26 /usr/local/etc/periodic/daily/411.pkg-backup -r-xr-xr-x 0 root wheel 678 Jul 7 12:26 /usr/local/etc/periodic/daily/490.status-pkg-changes -r-xr-xr-x 0 root wheel 2558 Jul 7 12:26 /usr/local/etc/periodic/security/410.pkg-audit -r-xr-xr-x 0 root wheel 611 Jul 7 12:26 /usr/local/etc/periodic/security/460.pkg-checksum -r--r--r-- 0 root wheel 839 Jul 7 12:26 /usr/local/etc/pkg.conf.sample -r--r--r-- 0 root wheel 43432 Jul 7 12:26 /usr/local/include/pkg.h -r--r--r-- 0 root wheel 727558 Jul 7 12:26 /usr/local/lib/libpkg.a lrwxr-xr-x 0 root wheel 0 Jul 7 12:26 /usr/local/lib/libpkg.so -> libpkg.so.1 -r--r--r-- 0 root wheel 1227064 Jul 7 12:26 /usr/local/lib/libpkg.so.1 -rw-r--r-- 0 root wheel 187 Jul 7 12:26 /usr/local/libdata/pkgconfig/pkg.pc [... etc ...] Interesting. I notice that (while looking ahead to see a prefix: of /usr/lo= cal in the +MANIFEST), the tarball itself has files that include /usr/local= in their path. Does pkg handle packages where the prefix (in +MANIFEST) is "/usr/local" _b= ut_ "tar tf" of the unxz'd tarball is _not_ "/usr/local"? (e.g. pkg_install= style) or is this the new way going forward? There must at least be a +MANIFEST -- other meta data files are optional. +COMPACT_MANIFEST is a subset of the full +MANIFEST. They're both YAML documents. +COMPACT_MANIFEST looks like this, for example: --- name: pkg version: 1.1.4 origin: ports-mgmt/pkg comment: New generation package manager arch: freebsd:9:x86:64 www: https://urldefense.proofpoint.com/v1/url?u=3Dhttp://wiki.freebsd.org/p= kgng&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg= %3D%3D%0A&m=3DLPoff3ddLDoHE30AU6R5vgBklqxsjVAosXGjJop6uO4%3D%0A&s=3D30b27cf= 33d7e594144fc38f20bc75d84464788e715f7fc82b2495f813fd4be2d maintainer: portmgr@FreeBSD.org prefix: /usr/local licenselogic: single licenses: - BSD flatsize: 6311507 desc: | New Generation package management tool for FreeBSD WWW: https://urldefense.proofpoint.com/v1/url?u=3Dhttp://wiki.freebsd.org/p= kgng&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg= %3D%3D%0A&m=3DcLKrok7Cl%2BjTLEB024lmmMXfxb1fKAOZvvxLV8RjU%2FU%3D%0A&s=3Dcef= 93a5fe98a3fa0fbc9df3e0d11c9bbeaee44290306834ddef30f2ba925446c categories: - ports-mgmt shlibs_required: - libpkg.so.1 shlibs_provided: - libpkg.so.1 message: | If you are upgrading from the old package format, first run: # pkg2ng Nice. Very nice. +MTREE_DIRS is a compatibility thing with the old pkg_tools. It's not needed in general as +MANIFEST can provide all that meta data itself. It isn't going to be deprecated for at least as long as the ports tree continues to support pkg_tools though. Beyond that, the rest of the pkg tarball just contains a tar archive of all the files, directories, sym-links etc to be installed by the package. Note that pkg(8) has no problem with creating an empty directory for a package, unlike pkg_tools. Excellent! Now, while you can grovel through the details of pkg tarballs and internal data formats like this, be aware: the format of the manifest and the details of the meta-data included in the pkg-tarballs is subject to change without warning as we develop pkg(8) further. We only promise API stability through the pkg(8) commands or for the libpkg.so library functions; reports of breakage from usage outside those APIs will receive little sympathy. Understood. So just to give you a better idea of how we manage packages here. We've realized that if you want to package for FreeBSD (in 9 and older), yo= u could get by alright if you knew how to create a +CONTENTS file from scra= tch. For RedHat, it's the SPECFILE. And now for FreeBSD 10, it looks an awf= ul lot like a SPECFILE (they are both in-fact YAML). The only thing you need if you really want to package is a small subset of = the manifest written in YAML: Have a look at what the ports tree do to create the minimalistic manifest a= nd what form it has and you will see how easy it is. It is so awful and complicated that there are already a load of custom scri= pts to create packages with pkg without using the ports tree. As an example: https://urldefense.proofpoint.com/v1/url?u=3Dhttps://github.com/z0nt/pkg&k= =3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D= %0A&m=3DcLKrok7Cl%2BjTLEB024lmmMXfxb1fKAOZvvxLV8RjU%2FU%3D%0A&s=3Dfa25d4b17= 9a2b815c1bffab49adb850f44a6437f175aa93dd159887652935258 , but there is way = more. I for example wrote in the past a plugin for pkg to be able to parse and USE RPM's specfiles as an input for pkg. Cool. Wonder if anyone will end up using that. It does sound rather neat fo= r (perhaps) people more RedHat centric that may want to re-use the same SPE= CFILE of their RPM to produce a pkgng file. So rather than teach the people here how to use tools, I taught them what I= think is more important... how to manage +CONTENTS, SPECFILE, and now up-a= nd-coming, +MANIFEST. The problem is that you compare 2 things that cannot be compared, In normal light, yes... but when actually, we've essentially wiped the exis= tence and knowledge of "source RPMs" from our minds as our build system imb= ues us with that luxury (the luxury of never needing a source RPM, never pr= oducing one, and never even thinking about one -- we go from SPECFILE direc= tly to binary RPM and when we need to modify a binary RPM, we take a templa= te SPECFILE and populate it with the metadata extracted from the rpm file i= tself (using "rpm" utility to extract said metadata). SPECFILE is the equivalent of pkg + the ports tree. In normal case, yes... in our case no. Every single SPECFILE in our build s= ystem uses the exact same assembly procedure to produce [directly] a binary= RPM. In fact specfiles are the equivalent of a given "port" !!! Are you writing = rpm files directly by hand? there is no SPECFILE inside RPM but rather a header container metadata in binary format and a body which is a cpio.(gz,bz2,xz). Correct, a binary RPM does not contain a SPECFILE. But, every piece of data= that goes into the SPECFILE is contained in metadata extractable with "rpm= -q -p RPMFILE --qf FORMAT" (iirc). This is how we turn a binary RPM into a build-directory with a SPECFILE tha= t -- when we say "make" -- produces the same binary RPM file with-or-withou= t any/all changes to the flat [unpacked] hierarchy: http://druidbsd.cvs.sf.net/viewvc/druidbsd/pkgbase/redhat/unpack.sh?revisio= n=3D1.1&content-type=3Dtext%2Fplain You can take a look at an example SPECFILE that's been generated from a bin= ary RPM using the above script: http://druidbsd.cvs.sf.net/viewvc/druidbsd/pkgbase/redhat/rhel6-x86/System_= Environment/Daemons/sup/SPECFILE?revision=3D1.1&view=3Dmarkup NOTE: In the case of the above URL, it turned out that the "sup" package wa= sn't available for RedHat EL 6 -- so we slurped in some other simple packag= e and replaced its guts with that of a sup package compiled specifically fo= r RedHat EL 6 (with fixes). But the SPECFILE starts its life as a template for each/every unpack of a b= inary RPM (see below): http://druidbsd.cvs.sf.net/viewvc/druidbsd/pkgbase/redhat/Mk/template.spec?= revision=3D1.1&view=3Dmarkup You are not creating the RPM file directly but rather create a SPECFILE, the equivalent on FreeBSD is to create a port!!! Incorrect; as you can see from the above, we *do* treat SPECFILE as a PLIST= (aka +CONTENTS). We do build the RPM from the SPECFILE. You're absolutely right that the SPECFILE *normally* contains logic on how = to turn a vendor software X (in source form) into [first] a "source" RPM an= d then a "binary" RPM. But we've taken all that logic out of the SPECFILE a= nd turned it into a dumb thing that just goes direct to binary RPM. the +MANIFEST as used to be the +CONTENTS are the equivalent of the RPM metadata. Right -- we use "rpm"'s --queryformat parameter to extract the metadata. We wrote them in YAML so that they are easy to debug and that we can use third party well used and tested parsers instead of writting our own. I'm very thankful that the compiled pkgng package isn't as opaque as RPM. I= think it's a good thing for transparency. I also like that you're porting = your tools. pkgng has indeed a bright future and you've been making great c= hoices. (and there is no "but" -- just wanted to say "thank you") I hope you don't see my dissection attempt as a way to subvert what you're = doing. Quite the opposite, I'm dissecting so that I can learn in an effort = to integrate. However, I'd be lying if I said I taught them *all* the gory details. In re= ality, for +CONTENTS they edit a PLIST which is essentially +CONTENTS witho= ut the "@comment MD5:" entries. For SPECFILE, they manage the full thing ex= cept there's a small section that is the standard RPM bootstrap that is lab= eled as "do not touch". >From what you posted of +COMPACT_MANIFEST was nice, except it lacks the lis= t of files. The basic principle here is that if you have to maintain a list of files, a= nd that list ends up being compiled into a +MANIFEST, why not just teach yo= ur peers how to read/write/maintain +MANIFEST files (in version control of = course) so that there are never any mysteries as to how the package perform= s. Have a closer look at pkg create, you will see that we are still able to us= e the plist or +CONTENTS as a possible input for pkg create, it is even the main = way to create packages. Ooo, nice. That will smooth migration (however, we it will be a while befor= e we get onto 10.x+ so we've got some time -- meaning, I might favor a rout= e that is legacy free.. agree?) Once again, the main and most important requirement to build packages was t= o be compatible with the ports tree, and the ports tree is using plist/+CONTENTS. and pkg2ng does only works by using the +CONTENTS. I know this sounds screwy... but (as with our other YAML files), it's reall= y nice because (as is the case with SPECFILE), we version-control things as= -close to the end-product as possible (take for example the case of "pre-in= stall" or "post-install" et cetera scripts -- I'm sure a tool like "pkg cre= ate" or "pkg_create" or other could do a good job of assembling the pieces = into the +MANIFEST, but then it's not being version-controlled as closely. You can keep what you have already done. Once again pkg does not have the equivalent of the SPECFILE because we have= the ports tree! In Linux, rpmbuild will take a SPECFILE in the manner you mention (acting a= s the pre-cursor to the SRPM), but it will also take a SPECFILE to build a = binary RPM (and in that last manner, the SPECFILE is not like the ports-tre= e as it expects binaries, not source, to build the cpio-ball). In the manner we're using SPECFILE (the latter manner), it *is* like a PLIS= T or a MANIFEST. so we do not need to provide a custom package building system. We could, as it is really easy, but we do not need so it is not there yet, = as said earlier I already wrote a pkg plugin that is able to build packages fr= om a RPM specfile, I also modified archlinux's makepkg to be able to output pkgn= g files. I did the same on slackare, etc. Here the limitation is not technical at al= l. That's really nice and encouraging. As I do-say... it's remarkable and the = future of pkgng looks bright ;D -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:23:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BCFFE68; Mon, 15 Jul 2013 16:23:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id CFCBC832; Mon, 15 Jul 2013 16:23:44 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id k14so16155984oag.12 for ; Mon, 15 Jul 2013 09:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BNWx5wfVMHGa3vk6z9GeG9hiobRFtkXmi0q7yJVeX98=; b=HYLoP6u1LoDNVWcqL+tOQBKqM7BApItS5OMTWvxXngJx2r9T+88osJ2Bg0T+20lms8 Mto/wPKdWhtvoGc4k5GVye4GlJV5fPeXwqvRRNfp2Uxr0i1JqFOtAO1Q9xiUGlNn2OaE TYkbLTo2O4LTP8DpyK3VQutiAZy8kUFG+ifWhioHWc/xThqBDjK+0RQoQ5eK8T74UsoL flDMgKTMtkX4QTJoS8fSjzPNKAXdDTLD16Irb3girOt6qGwipogGv2RhIVhM+hO60wJ3 tD2Ft4yMA5j/qlqdRT/+gz+QGt+Vc+VASKdLiMg4DY/cfN8X9hQLzy0yKPs8qtdn+qDN Ezsg== MIME-Version: 1.0 X-Received: by 10.182.50.200 with SMTP id e8mr44583248obo.35.1373905424348; Mon, 15 Jul 2013 09:23:44 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Mon, 15 Jul 2013 09:23:44 -0700 (PDT) In-Reply-To: <1373900246.23916.140661255858745.1BA622A0@webmail.messagingengine.com> References: <201307141949.r6EJnZPp009319@hergotha.csail.mit.edu> <1373895245.27518.140661255822389.195BA409@webmail.messagingengine.com> <20130715144408.6af32858@gumby.homeunix.com> <1373900246.23916.140661255858745.1BA622A0@webmail.messagingengine.com> Date: Mon, 15 Jul 2013 09:23:44 -0700 X-Google-Sender-Auth: eAAN1kaOQRDNm9GJK8z0QNTfn-Y Message-ID: Subject: Re: Ports with daemons on uninstall... From: Kevin Oberman To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 16:23:45 -0000 On Mon, Jul 15, 2013 at 7:57 AM, Mark Felder wrote: > On Mon, Jul 15, 2013, at 8:44, RW wrote: > > > > Is that really correct? I would expect the deinstall to be done after > > the build has completed successfully. > > > > That might not be accurate with a current portmaster, but we used to > have that happen all too frequently. I just checked the plist and it has > @stopdaemon mysql-server, so I'm guessing portmaster would run that too > prematurely. > The reality is that some ports take a LONG time to just install, especially when libtool is involved. I want the old daemon running until the old one is installed. Then either the make or I can restart the daemon which results in a downtime of about two or three seconds. Stopping before the new version is installed guarantees a much longer outage. Yes, I also see some possible nasty races in a few cases, not most would be fine. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:27:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00392FEF; Mon, 15 Jul 2013 16:27:20 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B7CD7879; Mon, 15 Jul 2013 16:27:20 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FGRKFt027095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 11:27:20 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Mon, 15 Jul 2013 11:27:19 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOgGCkEhI/XtjETUan8/QjEhM8pplkGukAgAGBDYCAAKd0gA== Date: Mon, 15 Jul 2013 16:27:19 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC7489@ltcfiswmsgmb21> References: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <20130715062759.GF1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715062759.GF1516@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-15_04:2013-07-15,2013-07-15,1970-01-01 signatures=0 Cc: Devin Teske , Garrett Wollman , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:27:21 -0000 On Jul 14, 2013, at 11:27 PM, Baptiste Daroussin wrote: > On Sun, Jul 14, 2013 at 07:29:50AM +0000, Teske, Devin wrote: >>=20 >>> Or you >>> can maintain the old cruft for your business -- just don't expect >>> anyone else to use it, or even want to. >>>=20 >>=20 >>=20 >> I have no intention of making old-world packages... but I also have no i= ntention of using "pkg create". >=20 > So you are taking as an exemple rpm but with RPM you do want to use what = they do > provide, aka rpmbuild but with pkgng you want to manually handwrite the p= ackages > because we haven't hidden the format behind opaque names and format. >=20 Close... I use rpmbuild because I haven't figured out how to subvert it to = create cpio-balls for rpm(8). I know how to extract the contents of binary = rpm's using rpm2cpio and I know how to extract the meta data and supplant i= t into a template SPECFILE using rpm -q -p file.rpm --qf "queryformat" ... = but I haven't spent enough time with rpm's to know how to master them witho= ut rpmbuild. The best I've done is learn how to use ".rpmmacros" to make rp= mbuild behave in a sane manner that is conducive to (a) building the archiv= e out of the current directory (including all temporary files, etc.) and (b= ) working on source-controlled checkouts. However, even if I did figure out the cpio-ball/metadata format, it is quit= e convenient to have rpmbuild do the work -- which unfortunately introduces= the constraint that you have to generate the archive on the system for whi= ch it will be installed (something you eluded that is inconclusive -- I'll = cover that in a reply to that-reply directly). The convenience however is not because the tool does everything I need it t= o do, but the convenience comes from the translation of YAML into metadata.= It doesn't appear that this will be necessary with pkgng packages, just as= it wasn't necessary for pkg_install packages. To be more clear,... because tools like pkg_create and "pkg create" take a = file-in, add data to it, and then (the most important part) put a modified = form into the archive (which quite-closely resembles the original), it is t= hen possible to imagine that: (1) there's value in learning both the input format and the output format s= o that you can validate packages, fix broken packages, etc. ASIDE: For example... a binary release package ends up with incorrect depen= dencies encoded within its +CONTENTS file -- I can slurp the package into o= ur "pkgbase", adjust the PLIST (generated from +CONTENTS), and produce a fi= xed package in mere moments (and I didn't have to wake anybody in the middl= e of the night, ask that FTP mirrors be updated, balk at the core team -- n= one of that... the problem was solved and in the next release we hope for t= he best that the dependency chain isn't busted for the same binary package = within the set of "X.Y-RELEASE" packages). (2) there's value in writing a shell-script method to translate the input f= ormat into the output format from a system of makefiles calling said shell = scripts out of a revision-controlled checkout ASIDE: This one should be obvious. If you can assemble a package using noth= ing but shell scripts (and mostly awk, ls, find, cp, mkdir, ln, cvs, make, = md5/sha256/sha512/openssl, and etc.), then you don't have to port the "port= " system (our "port" system being called "pkgbase" -- and working to "keep = you stable" rather than "keep you up-to-date"). > You know in that case you should probably create your own RPM without RPM= just > write by hand the header and happened the cpio to it, in that case you wi= ll end > up having the same at what you are trying to do with pkg. >=20 It's a good idea... except one thing... the YAML SPECFILE (minus the elemen= ts that are specific to the `-bb' process of rpmbuild) get completely chang= ed in the process. Doing this would require a YAML parser + metadata encode= r process-pair. Whereas for FreeBSD it's YAML-in, YAML-out. So I don't need= a YAML-parser, just a line-parser and light YAML-encoder -- which could be= fixed-strings, doesn't have to be complex... e.g., awk). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:45:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A0BF9D20; Mon, 15 Jul 2013 16:45:45 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABDEA2A; Mon, 15 Jul 2013 16:45:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FGjfrL021181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 11:45:41 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Mon, 15 Jul 2013 11:45:41 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOgGCkEhI/XtjETUan8/QjEhM8pplkGukAgAB+HwCAAB8QgIAA5XOAgACq/oA= Date: Mon, 15 Jul 2013 16:45:40 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC7550@ltcfiswmsgmb21> References: <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> <20130715063339.GG1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715063339.GG1516@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-15_04:2013-07-15,2013-07-15,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , Devin Teske , Garrett Wollman , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:45:45 -0000 On Jul 14, 2013, at 11:33 PM, Baptiste Daroussin wrote: On Sun, Jul 14, 2013 at 04:52:26PM +0000, Teske, Devin wrote: On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: On 14 Jul 2013, at 08:29, Teske, Devin wrote: Simple, really. Let's take RPM for example. The RPM package format has been ported to other= platforms. So does pkgng ported on Linux, OS X, dragonfly, NetBSD... Sweet! (bright future!) But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install it= on RedHat. Yes you can, I do it at work all the time, on FreeBSD I do create AIX rpms = and RedHat rpms. What version of RedHat? Worked on RedHat EL4 using rpm3, but in-practice -- attempts to recreate th= at workflow on RedHat EL6 using rpm4 have failed. Please see a copy/paste of the output of when we build an RPM on FreeBSD-8.= 1 and try to install it on RedHat Enterprise Linux 6: http://pastebin.com/zpzjxP2T Spoiler: "package {X} is intended for a freebsd operating system" (not inst= alled) This is because the RPM format records the platform that you "build" your R= PM on (not the binaries, just the RPM) *into* said RPM. So does pkgng. Good to know. This actually adds a requirement to the RPM production that the RPMs be pro= duced on the platform that they will be installed-to. No. Yes. See pastebin link above. Currently, no such restriction exists for the building of FreeBSD packages = (within our system). This would have been true if we had ported pkg_create = (and may continue to be true if we ported pkg and its ilk), but let's say f= or the sake of argument that the future of "pkg" looks bright and it gets p= orted to all sorts of systems (ported in a fashion similar to RPM) *and* we= find one day that the +MANIFEST starts containing a target-platform (resul= ting in refusal to install a *.txz package because it was rolled on a diffe= rent platform. Thank for describing the exact situation pkg is right now. Glad to help ;D (not so happy about the target platform being recorded -- is there an overr= ide? setting UNAME_{a,r,etc.}?) In that case, we'd then prefer to by-pass the tools and use our own method = of creating the tar-ball to lift such a restriction. The restriction you are speaking about does not exists. See pastebin link above. ASIDE: If I knew how to force rpmbuild into creating androgynous packages f= or other architectures, I'd be doing that to life the restriction there too= , but I haven't figured out that. Basically... within our "pkgbase" tree, we like the branch within the tree = to dictate how a package is built... not what platform you're on. The goal = being that we can run a single package-build host that builds all of our pa= ckages from a single platform. You can do it with pkgng just easily, as well as you can do it with rpm. W/respect to RPM, see pastebin link above. -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:47:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 91F0EE4D; Mon, 15 Jul 2013 16:47:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6860DA48; Mon, 15 Jul 2013 16:47:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6FGliNb017457; Mon, 15 Jul 2013 12:47:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6FGldi6016858; Mon, 15 Jul 2013 16:47:39 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Jul 2013 16:47:39 GMT Message-Id: <201307151647.r6FGldi6016858@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:47:45 -0000 TB --- 2013-07-15 15:46:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-15 15:46:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-15 15:46:26 - starting HEAD tinderbox run for mips/mips TB --- 2013-07-15 15:46:26 - cleaning the object tree TB --- 2013-07-15 15:46:26 - /usr/local/bin/svn stat /src TB --- 2013-07-15 15:46:30 - At svn revision 253358 TB --- 2013-07-15 15:46:31 - building world TB --- 2013-07-15 15:46:31 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 15:46:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 15:46:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 15:46:31 - SRCCONF=/dev/null TB --- 2013-07-15 15:46:31 - TARGET=mips TB --- 2013-07-15 15:46:31 - TARGET_ARCH=mips TB --- 2013-07-15 15:46:31 - TZ=UTC TB --- 2013-07-15 15:46:31 - __MAKE_CONF=/dev/null TB --- 2013-07-15 15:46:31 - cd /src TB --- 2013-07-15 15:46:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 15 15:46:38 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 15 16:44:50 UTC 2013 TB --- 2013-07-15 16:44:50 - cd /src/sys/mips/conf TB --- 2013-07-15 16:44:50 - /usr/sbin/config -m ADM5120 TB --- 2013-07-15 16:44:50 - skipping ADM5120 kernel TB --- 2013-07-15 16:44:50 - cd /src/sys/mips/conf TB --- 2013-07-15 16:44:50 - /usr/sbin/config -m ALCHEMY TB --- 2013-07-15 16:44:50 - skipping ALCHEMY kernel TB --- 2013-07-15 16:44:50 - cd /src/sys/mips/conf TB --- 2013-07-15 16:44:50 - /usr/sbin/config -m AP121 TB --- 2013-07-15 16:44:50 - building AP121 kernel TB --- 2013-07-15 16:44:50 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 16:44:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 16:44:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 16:44:50 - SRCCONF=/dev/null TB --- 2013-07-15 16:44:50 - TARGET=mips TB --- 2013-07-15 16:44:50 - TARGET_ARCH=mips TB --- 2013-07-15 16:44:50 - TZ=UTC TB --- 2013-07-15 16:44:50 - __MAKE_CONF=/dev/null TB --- 2013-07-15 16:44:50 - cd /src TB --- 2013-07-15 16:44:50 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Mon Jul 15 16:44:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ./machine/counter.h:91: warning: implicit declaration of function 'critical_exit' ./machine/counter.h:91: warning: nested extern declaration of 'critical_exit' [-Wnested-externs] In file included from /src/sys/mips/mips/uio_machdep.c:47: /src/sys/sys/systm.h: At top level: /src/sys/sys/systm.h:189: warning: conflicting types for 'critical_enter' ./machine/counter.h:89: warning: previous implicit declaration of 'critical_enter' was here /src/sys/sys/systm.h:190: warning: conflicting types for 'critical_exit' ./machine/counter.h:91: warning: previous implicit declaration of 'critical_exit' was here *** Error code 1 Stop. make: stopped in /obj/mips.mips/src/sys/AP121 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-15 16:47:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-15 16:47:39 - ERROR: failed to build AP121 kernel TB --- 2013-07-15 16:47:39 - 2753.59 user 584.79 system 3672.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:48:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F002F99; Mon, 15 Jul 2013 16:48:44 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 445D1A5F; Mon, 15 Jul 2013 16:48:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FGmdVt025759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 11:48:41 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Mon, 15 Jul 2013 11:48:19 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAUuIAgAIEI4CAAKptAA== Date: Mon, 15 Jul 2013 16:48:18 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC7581@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <20130715063818.GH1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715063818.GH1516@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <6969159408FB074BB52DC908A8E04AE7@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-15_04:2013-07-15,2013-07-15,1970-01-01 signatures=0 Cc: Mark Felder , Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:48:44 -0000 On Jul 14, 2013, at 11:38 PM, Baptiste Daroussin wrote: > On Sat, Jul 13, 2013 at 06:51:00PM -0500, Mark Felder wrote: >> On Sat, Jul 13, 2013, at 13:54, Teske, Devin wrote: >>>=20 >>>=20 >>> If FTP access (or any of the other remote access methods) are going away >>> for HEAD pkg access, I'll need to know so I can make the appropriate >>> changes in the HEAD branch of bsdconfig. >>>=20 >>=20 >> It's simpler than you think. The new pkg uses libfetch. You can have >> your PACAKGESITE be file:// ftp:// http:// https:// ...=20 >>=20 >> I do suspect that HTTP_PROXY support is probably not available as I >> recall seeing a post where someone was asking about that getting >> implemented for fetch. I'll have to research that again, though. >=20 > Yes pkgng do support proxies, because libfetch do support them. >=20 I think Mark was saying that libfetch doesn't yet support http proxy. However, I've often done: env http_proxy=3Duser:pass@host:port fetch this-thing or that-thing So I'm not sure if Mark was implying that this doesn't yet work with PACKAG= ESITE because you need a way of passing the additional env? (talk of a PKG_= ENV iirc)? > pkgng also support ssh:// >=20 That's cool ;D --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:48:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F002F99; Mon, 15 Jul 2013 16:48:44 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 445D1A5F; Mon, 15 Jul 2013 16:48:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FGmdVt025759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 11:48:41 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Mon, 15 Jul 2013 11:48:19 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgIAAUuIAgAIEI4CAAKptAA== Date: Mon, 15 Jul 2013 16:48:18 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC7581@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <20130715063818.GH1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715063818.GH1516@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <6969159408FB074BB52DC908A8E04AE7@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-15_04:2013-07-15,2013-07-15,1970-01-01 signatures=0 Cc: Mark Felder , Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:48:44 -0000 On Jul 14, 2013, at 11:38 PM, Baptiste Daroussin wrote: > On Sat, Jul 13, 2013 at 06:51:00PM -0500, Mark Felder wrote: >> On Sat, Jul 13, 2013, at 13:54, Teske, Devin wrote: >>>=20 >>>=20 >>> If FTP access (or any of the other remote access methods) are going away >>> for HEAD pkg access, I'll need to know so I can make the appropriate >>> changes in the HEAD branch of bsdconfig. >>>=20 >>=20 >> It's simpler than you think. The new pkg uses libfetch. You can have >> your PACAKGESITE be file:// ftp:// http:// https:// ...=20 >>=20 >> I do suspect that HTTP_PROXY support is probably not available as I >> recall seeing a post where someone was asking about that getting >> implemented for fetch. I'll have to research that again, though. >=20 > Yes pkgng do support proxies, because libfetch do support them. >=20 I think Mark was saying that libfetch doesn't yet support http proxy. However, I've often done: env http_proxy=3Duser:pass@host:port fetch this-thing or that-thing So I'm not sure if Mark was implying that this doesn't yet work with PACKAG= ESITE because you need a way of passing the additional env? (talk of a PKG_= ENV iirc)? > pkgng also support ssh:// >=20 That's cool ;D --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:52:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D227A2AE for ; Mon, 15 Jul 2013 16:52:27 +0000 (UTC) (envelope-from feld@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A65A0AB4 for ; Mon, 15 Jul 2013 16:52:27 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 91A4D2100A for ; Mon, 15 Jul 2013 12:52:26 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Mon, 15 Jul 2013 12:52:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=/Fn3FCm5R1EQnb94hRs8O+9FXl0=; b=CYL 8DlgCBXJgd/Zjw96ojDyVddJSRA2qGf3LH5iRTUcOlinlB55ymXF7qTrejL6uy8m MJ7Qm/CTF7+ZYNCrxJ8wAiiRTARRVkboGVu0flpeiga/dN6b2uOvJGn4HzF/4Ja8 RcCzlT9oZRtVhlGPApvzZgcRvJbeolGBGy46tSpw= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 74EE8B00003; Mon, 15 Jul 2013 12:52:26 -0400 (EDT) Message-Id: <1373907146.30703.140661255908393.318A8B62@webmail.messagingengine.com> X-Sasl-Enc: 8Hi4eoCaZiPczmZLOI7kjnnqEJqOEhdKKI5ELI2+q1KZ 1373907146 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-bdcdd1cb In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC7581@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <20130715063818.GH1516@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC7581@ltcfiswmsgmb21> Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Date: Mon, 15 Jul 2013 11:52:26 -0500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 16:52:27 -0000 On Mon, 15 Jul 2013 11:48:18 -0500, Teske, Devin wrote: > I think Mark was saying that libfetch doesn't yet support http proxy. Now that I've googled, I was referring to this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=180253 I thought it was complete missing functionality, not just that bug. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 17:02:09 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11CCF5A2; Mon, 15 Jul 2013 17:02:09 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id CFCB0B3C; Mon, 15 Jul 2013 17:02:08 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FH21pu001110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 12:02:01 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Mon, 15 Jul 2013 12:02:01 -0500 From: "Teske, Devin" To: Baptiste Daroussin Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgAOXJoCAAK00AA== Date: Mon, 15 Jul 2013 17:02:00 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC766F@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130715064205.GI1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715064205.GI1516@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-15_04:2013-07-15,2013-07-15,1970-01-01 signatures=0 Cc: Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:02:09 -0000 On Jul 14, 2013, at 11:42 PM, Baptiste Daroussin wrote: > On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: >> On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: >>=20 >>> Hi, >>>=20 >>> I have just committed (r253305) a change the make pkg_install not being= built >>> and installed by default on HEAD. >>>=20 >>> If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes = in your >>> src.conf(5) >>=20 >> I think while a good move, we need to allow a window of development to r= e-work other HEAD components. >>=20 >> It might also be worth developing a lint-tool to make sure we get every = last instance (both from C code and sh code) within our base before we moti= on to cut a release with this change. >>=20 >> I for one am effected and will have to change things. >>=20 >> Can you point us at a guide (or even better, a Wiki) that can smooth the= process? >=20 > I have already pointed you to such resources a couple of time before you = started > working on the package management part of bsdconfig. Respectfully... look at the reply-text. I didn't mention bsdconfig. I was a= sking in-general for others. I think we're all in agreement that a transiti= on Wiki does not exist. I'm not upset that the conversation was turned into= a bsdconfig-specific one (on the contrary, elated)... but for the very rea= son that you had already given me pointers in the past, I did not come righ= t out and say "hey, could you re-tell me everything you told me before beca= use I've forgotten most of it?" but instead I pointed out that we don't hav= e a transition Wiki. So I do supremely apologize if I ask a question that you already answered i= n the past. My excuse is that you pointed me to such resources almost 10 months ago. An= d for that entire 10 months, I'd been working on the package management par= t of bsdconfig. I *just* got my head above water and then it was announced = that pkg_install is going away, and what perfect timing -- having just fini= shed the pkg_install-based framework for which I plan to base the pkgng int= egration. > May I remember you that at > this time I have recommanded you to directly work on the pkgng version? This comment doesn't seem to be related to any of the reply-text above it. = I'll assume it's tainted by the other messages in this thread. For bsdconfi= g, let me just re-iterate... + bsdconfig is the tool to replace "sysinstall configPackages". + It will not do anything "weird" or "strange" or "out of place" ** + It will try to be an example as well as a re-usable and extendable tool (and on the back of those last two comments, again, bsdconfig pkgng integra= tion is not associated with any funky handling of package MANIFEST files or= any black-magic voodoo that I do at $work with "pkgbase"). ** Unless a UI enhancement can be made by subverting a decidedly non-UI too= l to provide more feedback than simply blocking on an opaque process. > I have > also explained you 2 or 3 times at least what is a catalog in pkgng how i= t works > what pkg query and pkg rquery will give you as a script writter. >=20 Again, apologies if I ask a question that *seems* like it's been asked befo= re. And it would be a lie for me to say I've forgotten *everything* from our pr= ior conversations. However, I may repeat some questions as it was almost 10= months ago that I was last looking at pkgng (getting "bsdconfig packages" = done for 9.2-R was a *lot* of work and it depleted my brain of pretty much = everything else for that entire time -- except for $work of course, but eve= ry night for 10 months, 7 days a week, I ate, drank, slept, and smoked "bsd= config packages"). If I could recount something from our conversations from 10 months ago... I= would say that you and I agreed that I needed to get the framework done an= d that I could best do that unencumbered if it were pkg_install based. Well= that's been done (it was a hell of a lot of work, but I got it done). I'm saying that one sole request (to get the framework ready for pkgng) is = now done and we need to reconvene to take the next step. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 17:47:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2ACD9DC7; Mon, 15 Jul 2013 17:47:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 011B1D48; Mon, 15 Jul 2013 17:47:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6FHlak6077751; Mon, 15 Jul 2013 13:47:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6FHlamf077750; Mon, 15 Jul 2013 17:47:36 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Jul 2013 17:47:36 GMT Message-Id: <201307151747.r6FHlamf077750@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:47:37 -0000 TB --- 2013-07-15 14:13:41 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-15 14:13:41 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-15 14:13:41 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-07-15 14:13:41 - cleaning the object tree TB --- 2013-07-15 14:13:41 - /usr/local/bin/svn stat /src TB --- 2013-07-15 14:13:59 - At svn revision 253358 TB --- 2013-07-15 14:14:00 - building world TB --- 2013-07-15 14:14:00 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 14:14:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 14:14:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 14:14:00 - SRCCONF=/dev/null TB --- 2013-07-15 14:14:00 - TARGET=pc98 TB --- 2013-07-15 14:14:00 - TARGET_ARCH=i386 TB --- 2013-07-15 14:14:00 - TZ=UTC TB --- 2013-07-15 14:14:00 - __MAKE_CONF=/dev/null TB --- 2013-07-15 14:14:00 - cd /src TB --- 2013-07-15 14:14:00 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 15 14:14:08 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 15 17:32:08 UTC 2013 TB --- 2013-07-15 17:32:08 - generating LINT kernel config TB --- 2013-07-15 17:32:08 - cd /src/sys/pc98/conf TB --- 2013-07-15 17:32:08 - /usr/bin/make -B LINT TB --- 2013-07-15 17:32:08 - cd /src/sys/pc98/conf TB --- 2013-07-15 17:32:08 - /usr/sbin/config -m LINT TB --- 2013-07-15 17:32:08 - building LINT kernel TB --- 2013-07-15 17:32:08 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 17:32:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 17:32:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 17:32:08 - SRCCONF=/dev/null TB --- 2013-07-15 17:32:08 - TARGET=pc98 TB --- 2013-07-15 17:32:08 - TARGET_ARCH=i386 TB --- 2013-07-15 17:32:08 - TZ=UTC TB --- 2013-07-15 17:32:08 - __MAKE_CONF=/dev/null TB --- 2013-07-15 17:32:08 - cd /src TB --- 2013-07-15 17:32:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 15 17:32:08 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/i386/i386/uio_machdep.c:48: /src/sys/sys/systm.h:190:6: error: conflicting types for 'critical_exit' void critical_exit(void); ^ ./i386/counter.h:172:3: note: previous implicit declaration is here critical_exit(); ^ 4 errors generated. *** Error code 1 Stop. make: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-15 17:47:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-15 17:47:36 - ERROR: failed to build LINT kernel TB --- 2013-07-15 17:47:36 - 10332.23 user 1540.18 system 12834.47 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 18:52:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 278D9FA0; Mon, 15 Jul 2013 18:52:33 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3EFB1; Mon, 15 Jul 2013 18:52:31 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r6FIqItd009046; Mon, 15 Jul 2013 13:52:18 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id r6FIqIv9009045; Mon, 15 Jul 2013 13:52:18 -0500 (CDT) (envelope-from brooks) Date: Mon, 15 Jul 2013 13:52:18 -0500 From: Brooks Davis To: Martin Wilke Subject: Re: errors building 9-STABLE on recent HEAD Message-ID: <20130715185218.GB78845@lor.one-eyed-alien.net> References: <20130624201149.GB70873@lor.one-eyed-alien.net> <1A835C0A-9A00-49B9-948C-CF69631CA2B7@bsdhash.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <1A835C0A-9A00-49B9-948C-CF69631CA2B7@bsdhash.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brooks Davis , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 18:52:33 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After not working for quite some time, I was able to build 9-STABLE last week. I'm not sure if something changed in the branch or if the new current I'd updated to fixed it. -- Brooks On Sat, Jul 13, 2013 at 11:07:04PM +0800, Martin Wilke wrote: > Hi, >=20 > I see exactly the same error on pointyhat too, did you find any work arou= nd for that? >=20 > On Jun 25, 2013, at 4:11 AM, Brooks Davis wrote: >=20 > > I recently upgraded my main buildbox from an ancient 9.0-STABLE snapshot > > to head and I've run into an issue building 9-STABLE on it. Initally > > this was broken by the switch to bmake, but Simon committed a work > > around that and using the fmake port also works around it. Now I'm > > seeing a strange error in yacc generated code. I say strange because > > yacc is correctly being bootstrapped so we're using the expected version > > and not the one in HEAD. > >=20 > > Does anyone have any insight into this issue? > >=20 > > cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=3D64 -I. -I/home/bed22/src-9/g= nu/usr.bin/binutils/ld -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbf= d -I/home/bed22/obj/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd -I/h= ome/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/includ= e -DTARGET=3D\"x86_64-unknown-freebsd\" -DDEFAULT_EMULATION=3D\"elf_x86_64_= fbsd\" -DSCRIPTDIR=3D\"/usr/libdata\" -DBFD_VERSION_STRING=3D\""2.17.50 [Fr= eeBSD] 2007-07-03"\" -DBINDIR=3D\"/usr/bin\" -DTARGET_SYSTEM_ROOT=3D\"\" -D= TOOLBINDIR=3D\"//usr/bin/libexec\" -D_GNU_SOURCE -I/home/bed22/src-9/gnu/us= r.bin/binutils/ld/../../../../contrib/binutils/ld -I/home/bed22/src-9/gnu/u= sr.bin/binutils/ld/../../../../contrib/binutils/bfd -std=3Dgnu99 -fstack-pr= otector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-param= eter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitia= lized -Wno-pointer-sign -c ldlex.c > > cc1: warnings being treated as errors > > : In function 'yy_get_next_buffer': > > :3229: warning: passing argument 2 of 'yy_input' from > > incompatible pointer type > > *** [ldlex.o] Error code 1 > >=20 > > Stop in /home/bed22/src-9/gnu/usr.bin/binutils/ld. > > *** [all] Error code 1 > >=20 > > Thanks, > > Brooks >=20 > +-----------------oOO--(_)--OOo-------------------------+ > With best Regards, > Martin Wilke (miwi_(at)_FreeBSD.org) >=20 > Mess with the Best, Die like the Rest >=20 >=20 --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFR5EThXY6L6fI4GtQRAmlfAKDoi9Ja+VDRSj1WxoDGVRDkywdFLQCgg0FL /Dxc4FPwUypfDfMy3TOjHvw= =vx33 -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 19:21:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 57676CDD; Mon, 15 Jul 2013 19:21:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED4E29D; Mon, 15 Jul 2013 19:21:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6FJLQbF001779; Mon, 15 Jul 2013 15:21:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6FJLQHD001778; Mon, 15 Jul 2013 19:21:26 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Jul 2013 19:21:26 GMT Message-Id: <201307151921.r6FJLQHD001778@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:21:27 -0000 TB --- 2013-07-15 18:03:38 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-15 18:03:38 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-15 18:03:38 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-15 18:03:38 - cleaning the object tree TB --- 2013-07-15 18:03:38 - /usr/local/bin/svn stat /src TB --- 2013-07-15 18:03:41 - At svn revision 253358 TB --- 2013-07-15 18:03:42 - building world TB --- 2013-07-15 18:03:42 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 18:03:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 18:03:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 18:03:42 - SRCCONF=/dev/null TB --- 2013-07-15 18:03:42 - TARGET=sparc64 TB --- 2013-07-15 18:03:42 - TARGET_ARCH=sparc64 TB --- 2013-07-15 18:03:42 - TZ=UTC TB --- 2013-07-15 18:03:42 - __MAKE_CONF=/dev/null TB --- 2013-07-15 18:03:42 - cd /src TB --- 2013-07-15 18:03:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 15 18:03:49 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 15 19:07:39 UTC 2013 TB --- 2013-07-15 19:07:39 - generating LINT kernel config TB --- 2013-07-15 19:07:39 - cd /src/sys/sparc64/conf TB --- 2013-07-15 19:07:39 - /usr/bin/make -B LINT TB --- 2013-07-15 19:07:39 - cd /src/sys/sparc64/conf TB --- 2013-07-15 19:07:39 - /usr/sbin/config -m LINT TB --- 2013-07-15 19:07:39 - building LINT kernel TB --- 2013-07-15 19:07:39 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 19:07:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 19:07:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 19:07:39 - SRCCONF=/dev/null TB --- 2013-07-15 19:07:39 - TARGET=sparc64 TB --- 2013-07-15 19:07:39 - TARGET_ARCH=sparc64 TB --- 2013-07-15 19:07:39 - TZ=UTC TB --- 2013-07-15 19:07:39 - __MAKE_CONF=/dev/null TB --- 2013-07-15 19:07:39 - cd /src TB --- 2013-07-15 19:07:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 15 19:07:39 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ./machine/counter.h:90: warning: implicit declaration of function 'critical_exit' ./machine/counter.h:90: warning: nested extern declaration of 'critical_exit' [-Wnested-externs] In file included from /src/sys/sparc64/sparc64/uio_machdep.c:47: /src/sys/sys/systm.h: At top level: /src/sys/sys/systm.h:189: warning: conflicting types for 'critical_enter' ./machine/counter.h:88: warning: previous implicit declaration of 'critical_enter' was here /src/sys/sys/systm.h:190: warning: conflicting types for 'critical_exit' ./machine/counter.h:90: warning: previous implicit declaration of 'critical_exit' was here *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-15 19:21:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-15 19:21:26 - ERROR: failed to build LINT kernel TB --- 2013-07-15 19:21:26 - 3925.11 user 645.98 system 4668.13 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 19:41:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BB963F3; Mon, 15 Jul 2013 19:41:42 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id A29F55E2; Mon, 15 Jul 2013 19:41:41 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id a15so8006290eae.26 for ; Mon, 15 Jul 2013 12:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UFIFRouyvoJZHlCqhqIivRA7Z0tqFTvkIl00iXFjnK8=; b=0nfw6v26bK4HOMfx8DLYPQDlar8Rk49YKrdgMnkyEDUWHhVch/M2LqhbIwow3Fclne OujcnLvpyDrRK+ke8MOwC/sD2o/J8ciqzTIWHs1WZdiP5xunRua7CWeCznIsAtcCDSi/ 9CquaWfPgSGt7CV9OIjgo+wLdoA2i4w0+Ln+B4OPXy07mMVU1Vk0b61abMIHBYuu5/h+ PBnTF3UgkaKmMr/U/B3OEwhAPdpet03pI+Jrc97zFUZX5MCiB5mnxxGk0m5LyvKL2dD+ QOtK7FPa0BtzsswbSKQzo0c9FJ23+cWU0vM+Fx+xegn+2XWjW9fXmmWXJflvZkWu9riI VkUA== MIME-Version: 1.0 X-Received: by 10.14.216.73 with SMTP id f49mr60078871eep.119.1373917299999; Mon, 15 Jul 2013 12:41:39 -0700 (PDT) Received: by 10.223.61.130 with HTTP; Mon, 15 Jul 2013 12:41:39 -0700 (PDT) In-Reply-To: <201306190832.r5J8WZFE082135@elf.torek.net> References: <201306190832.r5J8WZFE082135@elf.torek.net> Date: Mon, 15 Jul 2013 12:41:39 -0700 Message-ID: Subject: Re: expanding past 1 TB on amd64 From: Alan Cox To: Chris Torek , neel@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:41:42 -0000 On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek wrote: > In src/sys/amd64/include/vmparam.h is this handy map: > > * 0x0000000000000000 - 0x00007fffffffffff user map > * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) > * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB > slot) > * 0xffff804020101000 - 0xfffffdffffffffff unused > * 0xfffffe0000000000 - 0xfffffeffffffffff 1TB direct map > * 0xffffff0000000000 - 0xffffff7fffffffff unused > * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map > > showing that the system can deal with at most 1 TB of address space > (because of the direct map), using at most half of that for kernel > memory (less, really, due to the inevitable VM fragmentation). > > New boards are coming soonish that will have the ability to go > past that (24 DIMMs of 64 GB each = 1.5 TB). Or, if some crazy > people :-) might want to use a most of a 768 GB board (24 DIMMs of > 32 GB each, possible today although the price is kind of > staggering) as wired-down kernel memory, the 512 GB VM area is > already a problem. > > I have not wrapped my head around the amd64 pmap code but figured > I'd ask: what might need to change to support larger spaces? > Obviously NKPML4E in amd64/include/pmap.h, for the kernel start > address; and NDMPML4E for the direct map. It looks like this > would adjust KERNBASE and the direct map appropriately. But would > that suffice, or have I missed something? > > For that matter, if these are changed to make space for future > expansion, what would be a good expansion size? Perhaps multiply > the sizes by 16? (If memory doubles roughly every 18 months, > that should give room for at least 5 years.) > > Chris, Neel, The actual data that I've seen shows that DIMMs are doubling in size at about half that pace, about every three years. For example, see http://users.ece.cmu.edu/~omutlu/pub/mutlu_memory-scaling_imw13_invited-talk.pdfslide #8. So, I think that a factor of 16 is a lot more than we'll need in the next five years. I would suggest configuring the kernel virtual address space for 4 TB. Once you go beyond 512 GB, 4 TB is the net "plateau" in terms of address translation cost. At 4 TB all of the PML4 entries for the kernel virtual address space will reside in the same L2 cache line, so a page table walk on a TLB miss for an instruction fetch will effectively prefetch the PML4 entry for the kernel heap and vice versa. Also, I don't know if this is immediately relevant to the patch, but the reason that the direct map is currently twice the size of the kernel virtual address space is that the largest machine (in terms of physical memory) that we were running on a couple of years ago had a sparse physical address space. Specifically, we needed to have a direct map spanning 1 TB in order to support 256 GB of RAM on that machine. This may, for example, become an issue if you try to autosize the direct map based upon the amount of DRAM. Alan From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 21:56:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 19F4EDE7; Mon, 15 Jul 2013 21:56:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E60F2D22; Mon, 15 Jul 2013 21:56:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6FLuTeB067737; Mon, 15 Jul 2013 17:56:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6FLuTK2067736; Mon, 15 Jul 2013 21:56:29 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Jul 2013 21:56:29 GMT Message-Id: <201307152156.r6FLuTK2067736@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:56:33 -0000 TB --- 2013-07-15 21:10:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-15 21:10:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-15 21:10:17 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-15 21:10:17 - cleaning the object tree TB --- 2013-07-15 21:10:17 - /usr/local/bin/svn stat /src TB --- 2013-07-15 21:10:21 - At svn revision 253371 TB --- 2013-07-15 21:10:22 - building world TB --- 2013-07-15 21:10:22 - CROSS_BUILD_TESTING=YES TB --- 2013-07-15 21:10:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-15 21:10:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-15 21:10:22 - SRCCONF=/dev/null TB --- 2013-07-15 21:10:22 - TARGET=arm TB --- 2013-07-15 21:10:22 - TARGET_ARCH=armv6 TB --- 2013-07-15 21:10:22 - TZ=UTC TB --- 2013-07-15 21:10:22 - __MAKE_CONF=/dev/null TB --- 2013-07-15 21:10:22 - cd /src TB --- 2013-07-15 21:10:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 15 21:10:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen -I. -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.armv6/src/tmp\" -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ScoreboardHazardRecognizer.cpp -o ScoreboardHazardRecognizer.o c++ -O2 -pipe -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen -I. -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.armv6/src/tmp\" -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShadowStackGC.cpp -o ShadowStackGC.o c++ -O2 -pipe -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen -I. -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.armv6/src/tmp\" -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShrinkWrapping.cpp -o ShrinkWrapping.o /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShrinkWrapping.cpp: In member function 'bool llvm::PEI::calcRestorePlacements(llvm::MachineBasicBlock*, llvm::SmallVector&, llvm::DenseMap, llvm::DenseMapInfo >&)': /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShrinkWrapping.cpp:740: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. make: stopped in /src/lib/clang/libllvmcodegen *** Error code 1 Stop. make: stopped in /src/lib/clang *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-15 21:56:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-15 21:56:29 - ERROR: failed to build world TB --- 2013-07-15 21:56:29 - 2441.67 user 221.18 system 2771.31 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 01:44:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1CDF3EB5; Tue, 16 Jul 2013 01:44:04 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id C084F765; Tue, 16 Jul 2013 01:44:03 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wc20so128981obb.4 for ; Mon, 15 Jul 2013 18:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=eiU0bHWt2PPCjM/f+XHAGONCb7ChhI/9TwJD/Gh0hHc=; b=g+wwmm2u5iOxvdmqubZhGD8TRdKg+iqd0w6wGLi0Fafcq7s2cfuT1C1CLJkObkHX8j QQRpox7WcciSYk/Jz1D0b+HcklzIzG8xoWUH68Fg8jYv0B2wPw7i47NZGDLZhDVdpDmd +bgHpBL2WqvHEYPjjBAaL7+4uNtIxabmD0HcU9xi50snWwL2t5gfn4841T6oMh9gKfOw qlnhPmE6O9nIyHewnR0UA1T3fmMBt293aBoSmHCpvoGu28ZDPLIOSLlzIzvoa2UmMibs gvMRxyhrZa0tKVnbOueagKJCtIXxt9DpmDG9ZSmKtKPz143HGkj+LCXWQClb4W0llE7+ Gkkw== MIME-Version: 1.0 X-Received: by 10.182.134.229 with SMTP id pn5mr45889080obb.9.1373939043000; Mon, 15 Jul 2013 18:44:03 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.27.101 with HTTP; Mon, 15 Jul 2013 18:44:02 -0700 (PDT) Date: Tue, 16 Jul 2013 02:44:02 +0100 X-Google-Sender-Auth: wu2nkY5cC1bAM12UNUjwBy24gyY Message-ID: Subject: FreeBSD Quarterly Status Report, April-June, 2013 From: Gabor Pali To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 01:44:04 -0000 FreeBSD Quarterly Status Report, April-June 2013 Introduction This report covers FreeBSD-related projects between April and June, 2013. This is the second of four reports planned for 2013. The last three months have been very active for the FreeBSD developer community, including events such as BSDCan and the FreeBSD Developer Summit collocated with it (covered in a separate report, see the BSDCan Developer Summit Special) and BSD-Day 2013. It has also seen improvements from the top to the bottom of the FreeBSD system. Desktop users will be pleased to note work on improving the state of AMD GPUs and making the console interaction with kernel mode setting -- required for recent xorg drivers -- cleaner and from continued work to make binary packages easier to use. Developers will note continued improvements to our toolchain, with a new debugger being prepared for integration. Server users will benefit from various improvements to virtualization support and scalability in the kernel. Of course, the FreeBSD system is nothing without applications to run atop it, and this quarter has seen some tireless work by members of the ports team to ensure that users have a wide choice of desktop and development environments, with highlights from the GNOME, KDE, Xfce, and Haskell teams in this report. Thanks to all the reporters for the excellent work! This report contains 33 entries and we hope you enjoy reading it. The deadline for submissions covering between July and September, 2013 is October 7th, 2013. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Postmaster Team * FreeBSD Release Engineering Team * FreeBSD Security Team Projects * PC-BSD * Virtual Private Systems Kernel * AMD GPU Kernel Mode-setting Support * Improved TCP SYN Cookies * Multi-threaded Pagedaemon * Native iSCSI Stack * Newcons Reboot * Realtek RTL8188CU/RTL8192CU USB Wireless Driver * SDIO Driver * V4L2 Update in the Linuxulator * Wireless Networking Improvements * Xen Support Improvements * ZFS TRIM and Enhanced BIO_DELETE Support Architectures * Intel IOMMU (VT-d, DMAR) Support * Superpages for ARMv7 Userland Programs * bsdconfig(8) and sysrc(8) * bsnmpd(1) Support in hastd(8) * Capsicum * LLDB Debugger Port Ports * FreeBSD Haskell Ports * GNOME/FreeBSD * KDE/FreeBSD * Xfce/FreeBSD * xorg on FreeBSD Documentation * Upgrading the Documentation Set to DocBook 5.0 Events * BSD-Day 2013 Google Summer of Code * New Capsicum Features * Qt and GTK+ Frontends for pkg(8) Miscellaneous * The FreeBSD Foundation __________________________________________________________________ AMD GPU Kernel Mode-setting Support URL: https://wiki.freebsd.org/AMD_GPU Contact: Jean-S=C3=A9bastien P=C3=A9dron Contact: Konstantin Belousov Due to non-FreeBSD-related activities from April to end of June, the project progressed slowly: * Some important problems in TTM were fixed and several others are being worked out. Applications affected by these bugs are non-linear video editing software (which do not use Xv to preview the video) or "screen" of VirtualBox, for instance. * Regarding the locking issue with OpenGL, no work has been done yet. glxgears works but some modern desktop environments or WebGL demos hang. Once TTM bugs described above are fixed, this is the next target. * Patches to Mesa to make it build out-of-the-box were submitted upstream. As of writing, some were committed but not all of them. Additionally, as result of a joint work with Jonathan Gray (of OpenBSD), Mesa should work on FreeBSD, OpenBSD, and hopefully on other BSD flavors without additional patches. Several users tested the driver. Andriy Gapon, Jonathan Gray, and Mark Kettenis (of OpenBSD) submitted patches. kyzh kindly donated several discrete cards from different series. A big thanks to all those contributors! The driver is still not stable enough for a wider call for testers. Open tasks: 1. Write instructions for the wiki to explain how to test the driver. __________________________________________________________________ BSD-Day 2013 URL: http://bsdday.eu/2013 URL: http://www.youtube.com/playlist?list=3DPLJJHfhjb5TOjB-sHRwJBGWd8XA7= nc1gk_ URL: https://picasaweb.google.com/116452848880746560170/BSDDay2013?authk= ey=3DGv1sRgCNvIoMWoxNTRYw Contact: G=C3=A1bor P=C3=A1li The BSD-Day is a now recurring excuse for BSD developers and users to meet up in person, share some beers and talk about what they are working on these days. There was a detour this year to visit the beautiful city of Naples of Italy, the home of pizza. Fortunately, the event has again gained support from numerous and generous sponsors, such as The FreeBSD Foundation, the EMC Corporation, iXsystems, FreeBSDMall, BSD Magazine, and many others which enabled us to cover the costs of travel and accommodation for the speakers. We are really grateful for this. Similarly to the previous years, the whole event started with a dinner in the downtown (somewhere around the Irish Pub) on Friday which suddenly turned into a do-it-yourself pizza-fest. Then it was followed by the Saturday event at the Institute of Biostructures and Bioimaging. There we had a lot of attendees for the associated BSDA exam in the morning -- 8 persons. The event itself had many interesting topics as well, for example moving MCLinker into the BSD world, organization and culture of the FreeBSD Project, the new callout(9) framework, building and testing ports with Poudriere and Tinderbox, FreeBSD in the embedded space, or building reliable VPN networks with OpenBSD. See the links in the report for more. __________________________________________________________________ bsdconfig(8) and sysrc(8) URL: http://druidbsd.sourceforge.net/ Contact: Devin Teske New utilities have been introduced in FreeBSD base system: bsdconfig(8) and sysrc(8). bsdconfig(8) is a replacement for the post-install abilities of deprecated sysinstall(8), while sysrc(8) is a robust utility for managing rc.conf(5) from the command line without a text editor. __________________________________________________________________ bsnmpd(1) Support in hastd(8) Contact: Mikolaj Golub A hastd(8) module for bsnmpd(1) has been committed to FreeBSD head and merged to the stable/8 and stable/9 branches recently. This module makes it possible to monitor and manage hastd(8) via the SNMP protocol. __________________________________________________________________ Capsicum URL: http://www.cl.cam.ac.uk/research/security/capsicum/ URL: https://lists.cam.ac.uk/mailman/listinfo/cl-capsicum-discuss Contact: Pawel Jakub Dawidek Contact: Capsicum Mailing List Capsicum, a lightweight OS capability and sandboxing framework, is being actively worked on. In the last few months the following tasks have been completed: * Committed Capsicum overhaul to FreeBSD head (r247602). This allows to use capability rights in more places, simplifies kernel code and implements ability to limit ioctl(2) and fcntl(2) system calls. * hastd(8) is now using Capsicum for sandboxing, as whitelisting ioctls is possible (r248297). * auditdistd(8) is now using Capsicum for sandboxing, as it is now possible to setup append-only restriction on file descriptor (available in Perforce). * Implemented connectat(2) and bindat(2) system calls for UNIX domain sockets that are allowed in capability mode (r247667). * Implemented chflagsat(2) system call (r248599). * Revised the Casper daemon for application capabilities. * Implemented libcapsicum for application capabilities. * Implemented various Casper services to be able to use more functionality within a sandbox: system.dns, system.pwd, system.grp, system.random, system.filesystem, system.socket, system.sysctl. * Implemented Capsicum sandboxing for kdump(1) (from r251073 to r251167). The version in Perforce also supports sandboxing for the -r flag, using Casper services. * Implemented Capsicum sandboxing for dhclient(8) (from r252612 to r252697). * Implemented Capsicum sandboxing for tcpdump(8) (available in Perforce). * Implemented Capsicum sandboxing for libmagic(3) (available in Perforce). * Implemented the libnv library for name/value pairs handling in the hope of wider adaptation across FreeBSD. For Capsicum-based sandboxing in the FreeBSD base system, the commits referenced above and the provided code aim to serve as examples. We would like to see more FreeBSD tools to be sandboxed -- every tool that can parse data from untrusted sources, for example. This requires deep understanding of how the tool in question works, not necessarily only Capsicum. This work is being sponsored by The FreeBSD Foundation. Open tasks: 1. Get involved, make the Internet finally(!) a secure place. Contact us at the cl-capsicum-discuss mailing list, where we can provide guidelines on how to do sandboxing properly. The fame is there, waiting. __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team In the second quarter of 2013, the Core Team approved a new Security Officer, Dag-Erling Sm=C3=B8rgrav and his deputy, Xin Li. The Core Team acknowledges Simon Nielsen, the outgoing Security Officer, for his work in the role. Peter Wemm took the lead on the reorganization and administration of the FreeBSD cluster, and with the Core Team's approval, Glen Barber and Ryan Steinmetz were welcomed to the cluster administration team. Based on the recommendation and experiences of Martin Wilke, the Core Team also supported establishing a liaison role between port managers and release engineers in order to improve their communication, especially for preparing releases. The Core Team welcomes Bryan Drewery to this role. Following up on the request from Eitan Adler, the Core Team agreed to remove CVS from the base system, which was soon followed by importing a lightweight version of Subversion tools, implemented by Peter Wemm. There were src commit bits issued for 3 new developers and 1 existing committer received extension in this quarter. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.freebsd.org/Haskell URL: https://github.com/freebsd-haskell/ports/ URL: http://haskell.inf.elte.hu/packages/ Contact: G=C3=A1bor P=C3=A1li Contact: Ashish SHUKLA We are proud to announce that the FreeBSD Haskell Team has updated the Haskell Platform to 2013.2.0.0, GHC to 7.6.3, as well as updated existing ports to their latest stable versions. In this update, we provided experimental support for LLVM-based code generation (disabled by default) to Haskell ports. We also added a number of new ports, which brings their count in the FreeBSD Ports Collection to 402, and now Haskell ports play nicer with portmaster(8)-based upgrades. In cooperation with Konstantin Belousov and Dimitry Andric, we have managed to unbreak the build of GHC on 32-bit 10.x systems, so we have packages for 10.x again. However, it turned out that this bug (in thread signal delivery) can also affect the building process for other platforms as well, which explains some of the strange build breakages our users experienced in the past. We have also learned that there is ongoing work in the GHC upstream which will allow us to provide support for building with Clang natively once GHC 7.8 becomes part of the Haskell Platform. Open tasks: 1. Test experimental Clang/LLVM code generation support to enable it by default. 2. Commit pending Haskell ports to the ports tree. 3. Port more (popular) Cabal packages. __________________________________________________________________ FreeBSD Postmaster Team Contact: FreeBSD Postmaster Team In the second quarter of 2013, the FreeBSD Postmaster Team has implemented the following items that may be interest of the general public: * With help from clusteradm, found that unbound (the resolver used on mx1 and mx2) is configured to perform DNSSEC validation which implies that if a signed zone fails validation, unbound refuses to use the information. This had caused one person to be unable to exchange email with FreeBSD.org until the zone signatures were refreshed. * Created the freebsd-dtrace mailing list, requested by George Neville-Neil. * Resurrected the freebsd-testing mailing list, requested by Garrett Cooper. * Created the freebsd-tex mailing list, requested by Hiroki Sato. * In response to another comment that our message rejection message was unclear in the case that greylisting was the reason, re-worded that message. * Augmented the allowable MIME types for secteam with the following to permit sending encrypted messages: + application/pgp-encrypted + application/pkcs7-encrypted + application/x-pkcs7-encrypted + multipart/encrypted * Began replacing freebsd-mozilla with freebsd-gecko. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/8.4R/errata.html URL: http://www.freebsd.org/releases/9.2R/schedule.html Contact: FreeBSD Release Engineering Team The FreeBSD 8.4-RELEASE cycle completed on June 7, 2013, approximately two months behind the original schedule. Please be sure to read the Errata Notices for any post-release issues discovered after 8.4-RELEASE. The FreeBSD 9.2-RELEASE process will begin July 6, 2013. Unless any critical issues arise, FreeBSD 9.2-RELEASE is expected to be available late August or early September. Users tracking the FreeBSD 9.X branch are encouraged to test the -BETA and -RC builds whenever possible, and provide feedback and report issues to the freebsd-stable mailing list. __________________________________________________________________ FreeBSD Security Team Contact: FreeBSD Security Team On April 15th Dag-Erling Sm=C3=B8rgrav and Xin Li took over as security officers for the FreeBSD Project, and the team welcomed Qing Li back to the team in June. This report briefly summarizes the work of the Security Team from April until the end of June. The Security Team has released the following advisories: * FreeBSD-SA-13:05.nfsserver: Insufficient input validation in the NFS server (nfsd(8)), reported by Adam Nowacki. * FreeBSD-SA-13:06.mmap: Privilege escalation via mmap(), reported by Konstantin Belousov. The Security Team has contributed to the following errata notices: * FreeBSD-EN-13:02.vtnet: Frames are not properly forwarded to vtnet(4) when two or more MAC addresses are configured on QEMU 1.4.0 and later in 8.4-RELEASE, reported by Julian Stecklina. * FreeBSD-EN-13:01.fxp: Initialization of fxp(4) network interfaces results in an infinite loop with dhclient(8) in 8.4-RELEASE, reported by Michael L. Squires. Per the request of Baptiste Daroussin, the Security Team has also reviewed the source code of Poudriere, the port build and test system which is planned to be used for producing pkg(8) ("new-style") packages on the FreeBSD cluster. __________________________________________________________________ GNOME/FreeBSD URL: http://www.FreeBSD.org/gnome/ Contact: FreeBSD GNOME Team The GNOME 3.6 work is moving along slowly but steadily. Almost all the GNOME 3 desktop ports were updated to their corresponding 3.6 versions. A big challenge was taken by getting the webkit-gtk3 port updated to 2.0.3. Currently programs using webkit-gtk3 crash on launch. It is hard to find the causes as the debug build of webkit-gtk either runs out of memory or disk space on the developement system used. Open tasks: 1. Update the FreeBSD GNOME website with recent changes in the ports tree, add new items in preparation for GNOME 3 and Mate, etc. 2. Merge Glib 2.36, GTK+ 3.8 and related ports back to the Ports Collection. 3. Continue work on GNOME 3.6, fix bugs and write code for missing features. 4. Complete the port of MATE. __________________________________________________________________ Improved TCP SYN Cookies URL: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D28838+0+current/free= bsd-net URL: http://people.freebsd.org/~andre/syncookie-20130708.diff Contact: Andre Oppermann We have had a SYN cookie implementation for quite some time now but it has some limitations with current realities for window scaling and SACK encoding the in the few available bits. This patch updates and improves SYN cookies mainly by: 1. Encoding of MSS, WSCALE (window scaling) and SACK into the ISN (initial sequence number) without the use of timestamp bits. 2. Switching to the very fast and cryptographically strong SipHash-2-4 hash MAC algorithm to protect the SYN cookie against forgery. The common parameters used on TCP sessions have changed quite a bit since SYN cookies were invented some 17 years ago. Today we have a lot more bandwidth which makes use of window scaling almost mandatory. Also SACK has become standard as it makes recovering from packet loss much more efficient. The original SYN cookies method only stored an indexed MSS value in the cookie. This obviously is not sufficient any more and breaks in the presence of WSCALE. WSCALE information is only exchanged during SYN and SYN-ACK. If we cannot keep track of it then we severely underestimate the available send or receive window, compounded with the fact that with large window scaling the window size information on the TCP segment header would be even lower numerically. A number of years back, SYN cookies were extended to store the additional state in the TCP timestamp fields, if available on a connection. It has been adopted by Linux as well. While timestamps are common among the BSD, Linux and other Unix systems, Windows never enabled them by default, thus they are not present for the vast majority of clients seen on the Internet. The new improvement in this patch moves all necessary information into the ISN again, removing the need for timestamps. Both the MSS and send WSCALE are stored in 3 bit indexed form together with a single bit for SACK. While we cannot represent all possible MSS and WSCALE values in only 3 bits each (both are 16-bit fields in the TCP header), it turns out that is not actually necessary. These improvements allow one to run with SYN cookies only on Internet-facing servers. However while SYN cookies are calculated and sent all the time, they are only used when the syn cache overflows due to attacks or overload. In that case though, you can rest assured that no significant degradation in TCP connection setup happens any more and that even Windows clients can make use of window scaling and SACK. Open tasks: 1. Additional testing on busy servers. __________________________________________________________________ Intel IOMMU (VT-d, DMAR) Support URL: http://www.intel.com/content/www/us/en/intelligent-systems/intel-te= chnology/vt-directed-io-spec.html URL: http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014368.htm= l URL: http://people.freebsd.org/~kib/misc/dmar.1.patch Contact: Konstantin Belousov Intel VT-d is a set of extensions that were originally designed to allow virtualizing devices. It allows safe access to physical devices from virtual machines and can also be used for better isolation and performance increases. A VT-d driver was developed that implements the busdma(9) interface using the DMA Remap units (DMARs) found in current Intel chipsets. The driver provides reliability and security improvements for the system by facilitating restricted access to main memory from busmastering devices. It also eliminates bounce buffering (copying) by allocating remapped regions that satisfy a device's access limitations. With additional work to define a suitable interface the VT-d driver will also provide PCI pass-through functionality for hypervisors. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Implement workarounds for chipset errata. 2. Commit to HEAD after additional testing. 3. Rebalance MSI/MSI-X using interrupt remapping unit, also required for x2APIC use on big machines. 4. Integrate with the Intel GPU MMU and handle Ironlake and SandyBridge errata for the GFXVTd unit. 5. Provide an interface for VMM (hypervisors). 6. Consider implementing a driver for AMD's IOMMU. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The KDE/FreeBSD Team has continued to improve the experience of KDE software and Qt under FreeBSD. During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC: 4.10.2, 4.10.3, 4.10.4 * Qt: 5.0.2 (area51) * PyQt: 4.10.2; QScintilla 2.7.2; SIP: 4.14.7 * KDevelop: 4.5.1 * Calligra: 2.6.2 * CMake: 2.8.11.1 * Digikam (and KIPI-plugins): 3.1.0, 3.2.0 * KDE Telepathy: 0.6.0, 0.6.1 As a result -- according to PortScout -- kde@ has 473 ports (up from 431), of which 98.73% are up-to-date (up from 93.5%). iXsystems Inc. continues to provided a machine for the team to build packages and to test updates. iXsystems Inc. has been providing the KDE/FreeBSD Team with support for quite a long time and we are very grateful for that. This quarter, we would also like to thank Steve Wills (swills@) for providing access to another machine so that we can do our work even faster. While a great deal of the team's efforts are focused towards packaging released code, we also take a proactive stand in making sure future versions of the software we port is also going to work well on FreeBSD. This involves being in close contact with upstream, raising awareness of FreeBSD as an active project and also sending actual patches that most of the time benefit many other operating systems besides FreeBSD itself. In this regard, we have been dedicating a lot of time making sure both clang and libc++ are fully supported in KDE and Qt. Not only has this resulted in many patches being sent to these projects, but the exposure to these large code bases have been beneficial to the Clang-on-FreeBSD project as well. Dimitry Andric (dim@) has been of great help as a point of contact for all the issues we have faced. As usual, the team is always looking for more testers and porters so please contact us and visit our home page. It would be especially useful to have more helping hands on tasks such as getting rid of the dependency on the defunct HAL project and providing integration with KDE's Bluedevil Bluetooth interface. Open tasks: 1. Update out-of-date ports, see PortScout for a list. 2. Work on KDE 4.11 and Qt 5. 3. Make sure the whole KDE stack (including Qt) builds and works correctly with clang and libc++. 4. Remove the dependency on HAL. __________________________________________________________________ LLDB Debugger Port URL: https://wiki.freebsd.org/lldb Contact: Ed Maste LLDB is the the debugger project in the LLVM family. It supports the Mac OS X, Linux, and FreeBSD platforms, but the latter has recently suffered under a lack of maintenance. After cleaning bit rot in LLDB's FreeBSD support, it again builds and can be used for basic debugging of single-threaded applications. The test suite also runs to completion, although it experiences a large number of failures. Ed Maste has been granted an LLDB commit bit, and is now committing ongoing bug fixes and development directly to the upstream repository. There is a significant amount of work still to be done, with one goal being the incorporation of lldb into the base system. This project is sponsored by DARPA/AFRL in collaboration with SRI International and the University of Cambridge. Open tasks: 1. Add support for multithreaded processes. 2. Fix watchpoints. 3. Add support for remote debuging (gdbserver / debugserver). 4. Add support for core files. 5. Add support for kernel debugging. 6. Verify i386 and ARM architectures. 7. Implement MIPS target support. 8. Verify cross-debugging. 9. Investigate and fix test suite failures. 10. Prepare lldb for incorporation into the base system. __________________________________________________________________ Multi-threaded Pagedaemon URL: http://people.freebsd.org/~kib/misc/pagedaemon-numa.1.patch Contact: Konstantin Belousov This project aims to improve scalability of the virtual memory subsystem. Based on a prototype change from Jeff Roberson, per-domain page queues and per-domain pagedaemon working threads have been implemented to enable this. At the moment, the domains coincide with the NUMA proximity domains, but this is not neccessary and could be improved with further separation to allow more parallelism in the pagedaemon. The patch is relatively simple, with the most delicate parts being the page laundry and OOM logic, which requires coordination between all pagedaemon threads to prevent false triggering. Testing on diverse workloads and on real multi-socket machines is required. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Debug on multi-domain NUMA machine. 2. Test, get review and commit. __________________________________________________________________ Native iSCSI Stack URL: https://wiki.freebsd.org/Native%20iSCSI%20target Contact: Edward Tomasz Napiera=C5=82a The native kernel iSCSI target and initiator project progressed well over the April to June period. The primary focus was to introduce support for iSER (iSCSI over RDMA) in both the initiator and the target. Prerequisite for this was merging some common parts together and implementing a workaround for the lack of iSER support in userspace. Apart from that, there were a myriad of smaller improvements. Such as creating more user-friendly administration utilities, for example iscsictl(8) which displays SCSI device nodes for each iSCSI session. This frees the user from getting the same information through camcontrol(8). There are also improvements in logging and manual pages. Once the iSER support becomes stable, the work will focus on performance optimizations. The plan is to commit both the new initiator and target in August to allow shipping them in 10.0. The project will continue with implementing support for software iWARP stack (useful mostly for testing and development), SCSI passthrough and various other improvements. This project is being sponsored by The FreeBSD Foundation. Open tasks: 1. Performance optimization. 2. Merge to FreeBSD head. __________________________________________________________________ New Capsicum Features URL: https://wiki.freebsd.org/SummerOfCode2013/CapsicumFeatures Contact: Mariusz Zaborski Contact: Pawel Jakub Dawidek Capsicum is a lightweight OS capability and sandboxing framework implemented in FreeBSD. This is still a new technology, so there is a lot of space for improvements. Thanks to the Google Summer of Code program and Pawel Jakub Dawidek for volunteering as mentor, Mariusz will have the chance to work on this project in the summer. The work on sandboxing the rwho(1) and rwhod(8) utilities was completed recently. There is also a plan to implement two new modules for Casper. Casper is a daemon to provide services for applications using Capsicum's capability mode. Some experimentation with implementing two new capability rights is in progress, so is porting one more program to use the existing features of the Capsicum framework. Open tasks: 1. system.unix -- a Casper module provides connect and listen on Unix domain socket. 2. system.udp -- a Casper module enabling connect, listen, send, and receive of UDP packets. 3. Implementing sandboxing for fetch(1). 4. Introduce new capability rights: CAP_SEND_RIGHTS and CAP_RECV_RIGHTS. __________________________________________________________________ Newcons Reboot Contact: Aleksandr Rybalko The purpose of the Newcons project is to provide a new interface for console and video output to graphic devices. This will allow simple drivers access the console and terminal mode early, and framebuffer access for xorg. Drivers will not need embedded font bitmaps, color maps, or mouse cursor bitmaps, as the whole infrastructure will be provided by the vt(4) Newcons driver. As the project includes Kernel Mode Setting (KMS) integration, one of the goals is support for modern Xorg releases, allowing the kernel to switch back to virtual terminal mode after graphics mode or resolution used with xorg changes. There are a lot of changes involved in the project. Main tasks include: * Core functionality (almost done). * Mouse support. * KMS (kernel mode setting) support. * USB keyboard support. * Splash screen support (partially working). * Driver support. * vidcontrol(1) support. The first deliverables of the project, including moused(8), ukbd(4), and KMS support are expected to arrive around the middle or end of August 2013. The whole project is expected to complete in November 2013. This project is being sponsored by The FreeBSD Foundation. Many thanks to Ed Schouten who started Newcons project and did most of the work. Open tasks: 1. Provide different flavors of hardware for testing the implementation. Do not hesitate to volunteer when a call for testing is announced. __________________________________________________________________ PC-BSD URL: http://www.pcbsd.org Contact: Kris Moore Progress on moving PC-BSD & TrueOS to a "rolling release" is happening quickly. We have implemented our own package repository, fully based on pkg(8), which is updated twice monthly, and are now hosting dedicated freebsd-update(8) systems. In addition to the 9.1-RELEASE ISO images, we have begun to create a 9-STABLE branch as well, using freebsd-update(8) to push out the latest world and kernel binaries on a monthly basis. We are currently working on an implementation of ZFS Boot Environments for desktops and servers. These users to install updates or experimental versions in separate ZFS clones and select the one to run at boot time, providing an easy way of testing upgrades before deployment. __________________________________________________________________ Qt and GTK+ Frontends for pkg(8) URL: https://wiki.freebsd.org/SummerOfCode2013/pkgQtGtk Contact: Justin Muniz Contact: Eitan Adler This project is part of Google Summer of Code. Work has only just begun, and the code is in its infancy. The Subversion repository holds experimental code that is actively being developed. Development should be concluded before the end of September, and the project will enter the maintenance phase of its life cycle. Open tasks: 1. Work with Matt Windsor to create a pkg(8) backend for PackageKit. 2. Extend PackageKit's Qt frontend to offer more functionality through pkg(8). 3. Extend PackageKit's GKT+ frontend to offer more functionality through pkg(8). __________________________________________________________________ Realtek RTL8188CU/RTL8192CU USB Wireless Driver Contact: Rui Paulo Contact: Kevin Lo The urtwn(4) driver was imported from OpenBSD. This is a driver for very small Realtek USB WiFi cards which are pretty inexpensive and can do 802.11n at the maximum theoretical speed of 150 Mbps. They make a good addition to embedded systems such as the Raspberry Pi and the BeagleBone. The driver requires firmware that is available in the FreeBSD Ports Collection (net/urtwn-firmware-kmod). Note that 802.11n is not yet supported. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/kibab-dplug Contact: Ilya Bakulin SDIO is an interface designed as an extension for the existing SD card standard, to allow connecting different peripherals to the host with the standard SD controller. Peripherals currently sold at the general market include WLAN/BT modules, cameras, fingerprint readers, barcode scanners. The driver is implemented as an extension to the existing MMC bus, adding a lot of new SDIO-specific bus methods. Getting information about the card works, including querying all the supported I/O functions. Simple byte transfers and multi-byte reads work. A prototype of the driver for Marvell SDIO WLAN/BT module is also being developed, using the existing Linux driver as a reference. Open tasks: 1. Extend MMC bus interface with more SDIO-specific bus methods to allow child drivers to perform multi-byte in/out transfers. 2. Write firmware loading code for the prototype of the WLAN driver. Further work on the WLAN driver should probably be done as a separate project. 3. Implement detach path. It has not been tested yet because the DreamPlug hardware available does not have an external SDIO-capable slot. __________________________________________________________________ Superpages for ARMv7 URL: http://static.usenix.org/events/osdi02/tech/full_papers/navarro/nav= arro.pdf URL: https://wiki.freebsd.org/ARMSuperpages URL: https://github.com/semihalf-bodek-zbigniew/freebsd-arm-superpages.g= it Contact: Zbigniew Bodek Contact: Grzegorz Bernacki Contact: Rafa=C5=82 Jaworowski The ARM architecture is becoming more and more prevalent, with increasing usage beyond the mobile and embedded space. Among the more interesting industry trends emerging in the recent months, there has been the concept of "ARM server". Some top-tier companies, e.g. Dell and HP, have already started to develop such systems. Key to success of FreeBSD in these new areas is dealing with the sophisticated features of the platform, for example adding support for superpages. The objective of this project is to enable FreeBSD/arm to utilize superpages which would allow efficient use of TLB translations (by enlarging TLB coverage), leading to improved performance in many applications and scalability. This is intended to work on ARMv7-based processors, however compatibility with ARMv6 will be preserved. The following steps have been made since the last status report: * Implement pmap_copy() to support fork() system calls. * Support for multiple page sizes. * Implement superpage creation, promotion, demotion, and eviction mechanisms. * Implement PV entry management for superpages. * Partially integrate code to the head branch. Next steps: * Test and benchmark. * Complete integration into FreeBSD head. This project is jointly sponsored by The FreeBSD Foundation and Semihalf. Open tasks: 1. Start utilizing superpages on ARMv6/v7. 2. Find bugs and debug. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ Contact: Deb Goodkin We started the quarter with our "Raise a Million -- Spend a Million" Spring Fundraiser. This was the first of three major fundraisers scheduled for the year. We were pleased to have raised $365,291 by the end of the campaign -- May 31. Last year, by the same time, we had raised only $56,196. We have started this year off with a much better fundraising strategy. We want to send a big thank you to everyone out there that has made a donation in 2013. Your early donations have made a significant impact on our fundraising endeavors so far this year. Some things we accomplished this last quarter are: * Attended BSDCan in Ottawa, Texas LinuxFest in Austin, SouthEast LinuxFest in Charlotte, and ICANN 46 meeting in Beijing. * We were a Gold Sponsor for BSDCan 2013 and sponsored 7 developers to attend the conference. * We signed up to be a Platinum Sponsor for EuroBSDCon 2013. * We sponsored 1 developer to attend OpenHelp. * Recognized Mark Linimon, Simon L. B. Nielsen, Bjoern A. Zeeb, and Ken Smith, at BSDCan, for their significant contributions to FreeBSD. We also recognized Dan Langille for his tireless effort of putting on BSDCan for 10 years. * We sponsored the developer and vendor summits at BSDCan, with 100 and 30 attendees respectively. * We sponsored BSD-Day 2013 that was held in Naples, Italy on April 6. * We held our annual board meeting in Ottawa. * We sponsored the following projects: Capsicum, ARM Superpages, iSCSI, Page Queue Locking, Input/Output Memory Management Unit, Documentation project infrastructure, and writing white papers. * We hired Edward Tomasz Napieral/a as the second member of our technical staff to work on FreeBSD projects full-time. * We hired Ed Maste as Director of Project Development. * With our continued support of building out the FreeBSD infrastructure, we purchased high-end servers for the Sentex Lab to be used with the latest 40 Gbps Ethernet cards from Chelsio to do performance testing and analysis, smaller servers for firewalls for NYI and ISC, and cables to connect our Juniper switches together into a bigger Juniper switch we purchased for NYI. __________________________________________________________________ Upgrading the Documentation Set to DocBook 5.0 Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n The Documentation Project has been using old versions of markup standards until recently when we switched to a real XML toolchain and DocBook 4.5. However, we still depend on obsolete technologies -- DSSSL and Jade. DocBook 5.0 provides cleaner markup and some nice new features. The objective of this project is to upgrade the documentation set to DocBook 5.0 and to find a way to properly render our sources without using DSSSL, since the DSSSL stylesheets are discontinued and cannot render DocBook 5.0. The documentation sources have already been successfully transformed to DocBook 5.0 and updates to the rendering process are under development. The common opinion among FreeBSD developers is that Java is a heavy dependency that should be avoided. This has suggested the transformation of DocBook sources to TeX and use TeX as a rendering backend. There are two ways to do this; the sources can be transformed either directly or through the XSL FO output generated by the stylesheets provided for the DocBook Project. The latter approach has been chosen as a preferred way since it better fits the existing documentation infrastructure and provides easier customization. This project is generously funded by The FreeBSD Foundation. Open tasks: 1. Finish the implementation of the rendering process. 2. Integrate the rendering solution into the infrastructure. 3. Merge back changes to head. __________________________________________________________________ V4L2 Update in the Linuxulator Contact: Alexander Leidinger The V4L2 support in the linuxulator was updated in FreeBSD head. This lets Skype v4 display video. Open tasks: 1. Find out why audio in Skype v4 stops working after some calls. __________________________________________________________________ Virtual Private Systems URL: http://www.7he.at/freebsd/vps/ URL: http://svnweb.freebsd.org/base/projects/vps/ Contact: Klaus Ohrhallinger VPS for FreeBSD is an OS-level based virtualization implementation that supports advanced features like live migration. It has been recently imported into the Project's Subversion repository as a project branch. The code is currently of alpha quality. Open tasks: 1. Test with many different guest setups/applications. All feedback is highly appreciated. __________________________________________________________________ Wireless Networking Improvements Contact: Adrian Chadd Recently the FreeBSD wireless networking stack has received updates in the following areas: * Improved transmit locking in net80211(4) to eliminate a whole class of subtle race conditions leading to out-of-order packets being handed to the driver. * Spectral scan (FFT) information is now available for the AR9280, AR9285, AR9287 series NICs. * Added support for AR93xx, AR94xx, AR95xx NICs -- hostap, adhoc and station modes have been tested, including 3x3 stream support for the those NICs where appropriate. * Implemented ps-poll handling in hostap mode. This was required for correct behaviour with stations that implement aggressive power save. * Added AR933x SoC support -- including all on-board peripherals -- the 8devices.com Carambola-2 board is now fully supported and will run FreeBSD from NOR flash. __________________________________________________________________ Xen Support Improvements URL: http://xenbits.xen.org/gitweb/?p=3Dpeople/royger/freebsd.git;a=3Dsu= mmary Contact: Justin T. Gibbs Contact: Will Andrews Contact: Andre Oppermann Contact: Roger Pau Monn=C3=A9 FreeBSD Xen HVM can be further improved by using more PV interfaces inside a HVM guest. So far the following items have been completed: * Update Xen interface files. (Merged into head) * Add support for the vector callback injection mechanism. This replaces the PCI interrupt and provides a per-cpu callback, which was not possible when using the PCI interrupt. * Rework event channel implementation and use the same code paths for both PV and PVHVM. * Implement PV one-shot event timers and timecounters. * Implement PV IPIs. * Live migration support for PV timers and PV IPIs. With this changes, FreeBSD will have a complete PVHVM port, this will also set the ground for a future PVH port (when PVH support is merged into Xen). PVHVM allows a virtual machine that boots as a native guest to be able to take full advantage of paravirtualized drivers, giving a performance improvement in most I/O related tasks. PVH allows a guest to take advantage of hardware assistance for memory management, but uses fully paravirtualized events and boot procedure, which brings two significant advantages beyond performance. The first is that domain 0 does not have to run a QEMU instance for emulated boot for PVH guests, which is a common reason for hosting providers to charge more for Windows and other HVM guests. The second is that PVH domains can be used as domain 0, without requiring different pmap (memory management) code from the conventional kernel. This will allow us to ship a single kernel binary supporting bare metal hardware, running as a Xen unprivileged guest, and eventually as Xen domain 0. Further improvements on blkfront and netfront have also been commited: * Fix netfront crash when detaching an interface. * Enable netfront to specify a maximum TSO length limiting the segment chain to what the Xen host side can handle after defragmentation. * Add barriers and flush support to blkfront. Netfront changes have been merged to stable branches, blkfront changes are only in head. Open tasks: 1. Merge remaining changes into head. __________________________________________________________________ Xfce/FreeBSD URL: https://wiki.freebsd.org/Xfce Contact: FreeBSD Xfce Team The FreeBSD Xfce Team has updated its ports to the latest stable releases, especially: * Core (mostly bugfixes and translation updates): * deskutils/xfce4-tumbler (0.1.29) * x11-wm/xfce4-panel (4.10.1) * sysutils/xfce4-settings (4.10.1) * x11-wm/xfce4-session (4.10.1) * sysutils/garcon (0.2.1) * x11/libxfce4util (4.10.1) * x11-wm/xfce4-wm (4.10.1) Applications: * multimedia/xfce4-parole (0.5.1) * www/midori (0.5.2) * deskutils/xfce4-notifyd (0.2.4) * misc/xfce4-appfinder (4.10.1) * x11/xfce4-terminal (0.6.2) * x11-fm/thunar (1.6.3) Panel plugins: * deskutils/xfce4-xkb-plugin (0.5.6) * textproc/xfce4-dict-plugin (0.7.0) * x11-clocks/xfce4-timer-plugin (1.5.0) * x11/xfce4-embed-plugin (new) Thunar plugins: * audio/thunar-media-tags-plugin (0.2.1) * archivers/thunar-archive-plugin (0.3.1) x11/xfce4-embed-plugin can integrate any application window into the Xfce panel. A new plugin is also available which monitors and displays earthquakes, it is called xfce4-equake-plugin. Open tasks: 1. Fix CPU issue with textproc/xfce4-dict-plugin (bug #10103). 2. Investigate why midori-gtk3 crashes too often. (The port is finished, but some libraries are not present by default in ports tree). 3. Fix x11-themes/gtk-xfce-engine with Gtk+ >=3D3.6. __________________________________________________________________ xorg on FreeBSD URL: http://wiki.freebsd.org/Xorg URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: Contact: Niclas Zeising Contact: Koop Mast During the beginning of this quarter, work focused on making the xorg update as robust and stable as possible in preparation for the merge to ports. As a part of this, ports exp-runs were performed to find and resolve regressions and other issues. Once this was completed, xorg was updated to version 7.7 on May 25, after more than a year of hard work. After the update, work immediately shifted to focus on updating and patching xorg client libraries, since numerous security issues had been identified in those. Unfortunately, this took a little longer than anticipated, but all fixes were comitted eventually. There has also been work on making the new xorg distribution the default for FreeBSD 9.1 and later. A patch was sent out and tested with good results, but this is currently postponed because switching virtual terminals is not working with the KMS driver. Currently, work is focusing on keeping xorg drivers and libraries up to date. Instead of making big updates every year or less, minor updates to some libraries, applications and drivers happen fairly regularly. Focus is also starting to shift towards newer versions of MESA and xorg-server, but this is still very experimental. Open tasks: 1. Continue the porting effort of recent versions of MESA. This is ongoing work, but integrating this into the development repo is hard work. Once this is completed, and KMS support for ATI is more mature, more testing can be done. 2. Port Wayland. The future of graphical environments in open source operating system seems to be Wayland. This needs to be ported to FreeBSD so that a wider audience can test it, and so that it eventually can be integrated into the ports tree, perhaps as a replacement for the current xorg. 3. Look into replacements for HAL. HAL is used for hot-plugging of devices, but it has been long abandoned by Linux. A replacement, perhaps built on top of devd(8), would be nice to have. This work should be coordinated with the FreeBSD GNOME and KDE teams. __________________________________________________________________ ZFS TRIM and Enhanced BIO_DELETE Support Contact: Pawel Jakub Dawidek Contact: Steven Hartland As of the end of June, FreeBSD's ZFS implementation now includes TRIM support in head, stable/9, and stable/8 branches. This allows ZFS to help maintain high performance on flash-based devices such as SSD's even under high-load conditions. When creating new pools and adding new devices to existing pools it first performs a full-device level TRIM to help ensure optimum starting performance. This behaviour can be overridden by setting the vfs.zfs.vdev.trim_on_init sysctl variable to 0 if for example the disks are new or have already been secure erased, which can also now be done using camcontrol(8) security actions. In order to support TRIM, the kernel requires the underlying device driver supports BIO_DELETE. This is currently mapped through to hardware methods such as ATA TRIM and SCSI UNMAP, which are commonly supported by SSDs via CAM. In order to increase the supported hardware base, CAM's SCSI layer was also enhanced to allow ATA TRIM via SATL ATA Passthrough to be used in addition to the existing UNMAP and WS methods. This allows SATA disks attached to SCSI controllers with CAM based drivers such as mps(4) and mpt(4) to provide delete support. Stats for ZFS TRIM can be monitored by looking at the sysctl variables under kstat.zfs.misc.zio_trim in addition to live GEOM delete stats via the gstat -d command. This project was sponsored by Multiplay and implemented by Pawel Jakub Dawidek. __________________________________________________________________ From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 03:28:00 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C264524B; Tue, 16 Jul 2013 03:28:00 +0000 (UTC) (envelope-from wenheping@gmail.com) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 78581B94; Tue, 16 Jul 2013 03:28:00 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so110492qej.23 for ; Mon, 15 Jul 2013 20:27:59 -0700 (PDT) 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=RpYBStDE+CRgU+9oZ2YiUx8Cf8j6ocp9TfyRoVeOjjo=; b=v2WJQSbsdr568Qki0veJ0jORV8GWdZvKgcpa9A+oHvQKSUuY0Hm9cNTe4f+k8ANzuS k9WkrJXfzy9iYFSf5VG6UI6sWP+j7JIW5Q7kAg/2GIwnSPiQlP/PbVchWv7emznwbYaV 7xuAGjaqie3mqF26bz4qogKcTQZrdx40pMetLqKf41hOcAibBJjO6WjE2GDPmgEEshti 67Plf6mc9Wjb6eVsX12ADkp1eATa8U6YYahzmf3x6BCFJIoNj94ZJGTkcF+BXbHl1K5m yFuX3O6q4wRWXNtYll894lDrmSNov0xhHTNaljd1AiAuhz/Hj2GA60ybvJM4w+SkNXLh cN5A== MIME-Version: 1.0 X-Received: by 10.224.65.202 with SMTP id k10mr492907qai.69.1373945279432; Mon, 15 Jul 2013 20:27:59 -0700 (PDT) Received: by 10.49.14.106 with HTTP; Mon, 15 Jul 2013 20:27:59 -0700 (PDT) In-Reply-To: <20130715185218.GB78845@lor.one-eyed-alien.net> References: <20130624201149.GB70873@lor.one-eyed-alien.net> <1A835C0A-9A00-49B9-948C-CF69631CA2B7@bsdhash.org> <20130715185218.GB78845@lor.one-eyed-alien.net> Date: Tue, 16 Jul 2013 11:27:59 +0800 Message-ID: Subject: Re: errors building 9-STABLE on recent HEAD From: wen heping To: Brooks Davis Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Martin Wilke , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 03:28:00 -0000 I build 9-STABLE on head today, while failed many times last month. wen 2013/7/16 Brooks Davis > After not working for quite some time, I was able to build 9-STABLE last > week. I'm not sure if something changed in the branch or if the new > current I'd updated to fixed it. > > -- Brooks > > On Sat, Jul 13, 2013 at 11:07:04PM +0800, Martin Wilke wrote: > > Hi, > > > > I see exactly the same error on pointyhat too, did you find any work > around for that? > > > > On Jun 25, 2013, at 4:11 AM, Brooks Davis wrote: > > > > > I recently upgraded my main buildbox from an ancient 9.0-STABLE > snapshot > > > to head and I've run into an issue building 9-STABLE on it. Initally > > > this was broken by the switch to bmake, but Simon committed a work > > > around that and using the fmake port also works around it. Now I'm > > > seeing a strange error in yacc generated code. I say strange because > > > yacc is correctly being bootstrapped so we're using the expected > version > > > and not the one in HEAD. > > > > > > Does anyone have any insight into this issue? > > > > > > cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. > -I/home/bed22/src-9/gnu/usr.bin/binutils/ld > -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd > -I/home/bed22/obj/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd > -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include > -DTARGET=\"x86_64-unknown-freebsd\" -DDEFAULT_EMULATION=\"elf_x86_64_fbsd\" > -DSCRIPTDIR=\"/usr/libdata\" -DBFD_VERSION_STRING=\""2.17.50 [FreeBSD] > 2007-07-03"\" -DBINDIR=\"/usr/bin\" -DTARGET_SYSTEM_ROOT=\"\" > -DTOOLBINDIR=\"//usr/bin/libexec\" -D_GNU_SOURCE > -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld > -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd > -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c ldlex.c > > > cc1: warnings being treated as errors > > > : In function 'yy_get_next_buffer': > > > :3229: warning: passing argument 2 of 'yy_input' from > > > incompatible pointer type > > > *** [ldlex.o] Error code 1 > > > > > > Stop in /home/bed22/src-9/gnu/usr.bin/binutils/ld. > > > *** [all] Error code 1 > > > > > > Thanks, > > > Brooks > > > > +-----------------oOO--(_)--OOo-------------------------+ > > With best Regards, > > Martin Wilke (miwi_(at)_FreeBSD.org) > > > > Mess with the Best, Die like the Rest > > > > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 03:42:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 791ED413; Tue, 16 Jul 2013 03:42:05 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id E8E14BFE; Tue, 16 Jul 2013 03:42:04 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b47so74617eek.35 for ; Mon, 15 Jul 2013 20:42:04 -0700 (PDT) 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=C4Qn9y7aizbHG0SJC+fWjbK7lwok17UaKhGCsC6BboQ=; b=mw90irNleTpMW78erBCyjzESRT9Y2P6jJgMoPcB0jz3fkntDxCU4xgsnsxqvVTJUGO muOA6YqDH9zki7Sqp3spLZxNSuw7qKmWEpcTCyMXRbeIn47jeNDIAvYYB73awV71c7y2 5gGIRa4g+mfzZ68rxdNTBbjFqaKz8Wo91MUOufyAVRHlwsqkkwoB/HOfm5y40Jmh+7AA JhYfUrD5IGfNhL0zuYOUm0xJnS/ViuQLR9VExVH+zlKKqPJNTIOHYCnOzXeh0BBrYHX+ fe5DNjBSeJisFr9ZHeNqhKeG1d6gjKdvVu+9+HEVQxz977LOARwv/bMABxcjjoFQXjM8 szWQ== MIME-Version: 1.0 X-Received: by 10.15.31.9 with SMTP id x9mr61617282eeu.103.1373946124076; Mon, 15 Jul 2013 20:42:04 -0700 (PDT) Received: by 10.14.119.203 with HTTP; Mon, 15 Jul 2013 20:42:04 -0700 (PDT) In-Reply-To: References: <20130624201149.GB70873@lor.one-eyed-alien.net> <1A835C0A-9A00-49B9-948C-CF69631CA2B7@bsdhash.org> <20130715185218.GB78845@lor.one-eyed-alien.net> Date: Mon, 15 Jul 2013 20:42:04 -0700 Message-ID: Subject: Re: errors building 9-STABLE on recent HEAD From: hiren panchasara To: wen heping Content-Type: text/plain; charset=UTF-8 Cc: Martin Wilke , Brooks Davis , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 03:42:05 -0000 On Mon, Jul 15, 2013 at 8:27 PM, wen heping wrote: > I build 9-STABLE on head today, while failed many times last month. There were some intermittent issues but *recent* stable/9 should build fine on *recent* head. If not, please report the errors and have sjg@ look at them. Thanks, Hiren > > wen > > > 2013/7/16 Brooks Davis > >> After not working for quite some time, I was able to build 9-STABLE last >> week. I'm not sure if something changed in the branch or if the new >> current I'd updated to fixed it. >> >> -- Brooks >> >> On Sat, Jul 13, 2013 at 11:07:04PM +0800, Martin Wilke wrote: >> > Hi, >> > >> > I see exactly the same error on pointyhat too, did you find any work >> around for that? >> > >> > On Jun 25, 2013, at 4:11 AM, Brooks Davis wrote: >> > >> > > I recently upgraded my main buildbox from an ancient 9.0-STABLE >> snapshot >> > > to head and I've run into an issue building 9-STABLE on it. Initally >> > > this was broken by the switch to bmake, but Simon committed a work >> > > around that and using the fmake port also works around it. Now I'm >> > > seeing a strange error in yacc generated code. I say strange because >> > > yacc is correctly being bootstrapped so we're using the expected >> version >> > > and not the one in HEAD. >> > > >> > > Does anyone have any insight into this issue? >> > > >> > > cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. >> -I/home/bed22/src-9/gnu/usr.bin/binutils/ld >> -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd >> -I/home/bed22/obj/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd >> -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include >> -DTARGET=\"x86_64-unknown-freebsd\" -DDEFAULT_EMULATION=\"elf_x86_64_fbsd\" >> -DSCRIPTDIR=\"/usr/libdata\" -DBFD_VERSION_STRING=\""2.17.50 [FreeBSD] >> 2007-07-03"\" -DBINDIR=\"/usr/bin\" -DTARGET_SYSTEM_ROOT=\"\" >> -DTOOLBINDIR=\"//usr/bin/libexec\" -D_GNU_SOURCE >> -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld >> -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd >> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k >> -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c ldlex.c >> > > cc1: warnings being treated as errors >> > > : In function 'yy_get_next_buffer': >> > > :3229: warning: passing argument 2 of 'yy_input' from >> > > incompatible pointer type >> > > *** [ldlex.o] Error code 1 >> > > >> > > Stop in /home/bed22/src-9/gnu/usr.bin/binutils/ld. >> > > *** [all] Error code 1 >> > > >> > > Thanks, >> > > Brooks >> > >> > +-----------------oOO--(_)--OOo-------------------------+ >> > With best Regards, >> > Martin Wilke (miwi_(at)_FreeBSD.org) >> > >> > Mess with the Best, Die like the Rest >> > >> > >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Jul 16 09:27:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F05D448C; Tue, 16 Jul 2013 09:27:34 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id B292B9CD; Tue, 16 Jul 2013 09:27:34 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 129836A6000; Tue, 16 Jul 2013 11:27:33 +0200 (CEST) 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 r6G9RWn7018295; Tue, 16 Jul 2013 11:27:32 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id r6G9RWsw017255; Tue, 16 Jul 2013 11:27:32 +0200 (CEST) (envelope-from lars) Date: Tue, 16 Jul 2013 11:27:32 +0200 From: Lars Engels To: Mark Felder Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <20130716092732.GS88288@e-new.0x20.net> References: <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <1373759460.29471.140661255344697.6A5745F8@webmail.messagingengine.com> <20130715063818.GH1516@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC7581@ltcfiswmsgmb21> <1373907146.30703.140661255908393.318A8B62@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Quuk9VARBQ1cqX8e" Content-Disposition: inline In-Reply-To: <1373907146.30703.140661255908393.318A8B62@webmail.messagingengine.com> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.4-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 09:27:35 -0000 --Quuk9VARBQ1cqX8e Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 11:52:26AM -0500, Mark Felder wrote: > On Mon, 15 Jul 2013 11:48:18 -0500, Teske, Devin > wrote: > > I think Mark was saying that libfetch doesn't yet support http proxy. >=20 > Now that I've googled, I was referring to this PR > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D180253 >=20 > I thought it was complete missing functionality, not just that bug. libfetch supports proxies even with authentication using HTTP_PROXY_AUTH environment variable --Quuk9VARBQ1cqX8e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHlEgQACgkQKc512sD3afgaRQCfbYJ9zD+l2L79MEPbWs8iLhmX BiAAn3xayKW6bOk/JY/0SOYBukKlBzi8 =/HWr -----END PGP SIGNATURE----- --Quuk9VARBQ1cqX8e-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 10:42:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09DD32B4 for ; Tue, 16 Jul 2013 10:42:08 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id C08F3CE1 for ; Tue, 16 Jul 2013 10:42:07 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1Uz2Og-000C4X-4O ; Tue, 16 Jul 2013 13:22:18 +0300 Date: Tue, 16 Jul 2013 13:22:18 +0300 From: Vitalij Satanivskij To: Vitalij Satanivskij Subject: Re: USB Keyboard not worked on current (r251681) Message-ID: <20130716102218.GA46142@hell.ukr.net> References: <20130614085022.GA75871@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614085022.GA75871@hell.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 10:42:08 -0000 Just some update 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r253358: Mon Jul 15 15:03:06 EEST 2013 USB keyboard's still not working (liteon controler on logitech keyboard) Have no idea how to realy locate problem. Maybe some one can help? Vitalij Satanivskij wrote: VS> Hello VS> VS> There is system - VS> VS> CPU: Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz (2400.05-MHz K8-class CPU) VS> real memory = 137438953472 (131072 MB) VS> avail memory = 132517056512 (126378 MB) VS> VS> motherboard - X9DR3-F VS> VS> Keyboard is VS> VS> Logitech, identified as VS> VS> ugen1.2: at usbus1 VS> ukbd0: on usbus1 VS> kbd2 at ukbd0 VS> kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 VS> VS> VS> Messages from dmesg (with "-v" in boot.conf ) VS> VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM VS> Jan 1 03:21:31 fmst-test kernel: Root mount waiting for: usbus1 usbus0 VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test last message repeated 4 times VS> Jan 1 03:21:31 fmst-test kernel: Root mount waiting for: usbus1 usbus0 VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test last message repeated 8 times VS> VS> and at the end - VS> VS> Jan 1 03:21:31 fmst-test last message repeated 2 times VS> Jan 1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM VS> Jan 1 03:21:31 fmst-test kernel: ugen0.2: at usbus0 (disconnected) VS> Jan 1 03:21:31 fmst-test kernel: uhub_reattach_port: could not allocate new device VS> Jan 1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup default USB transfer VS> Jan 1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM VS> Jan 1 03:21:31 fmst-test kernel: ugen1.2: at usbus1 (disconnected) VS> Jan 1 03:21:31 fmst-test kernel: uhub_reattach_port: could not allocate new device VS> VS> VS> VS> I see thread's about same problem early, but patch alredy in head and no changes. VS> VS> What and how can i debug to see where is problem? VS> VS> VS> _______________________________________________ VS> freebsd-current@freebsd.org mailing list VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current VS> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 11:12:45 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7FB498C8; Tue, 16 Jul 2013 11:12:45 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB35E14; Tue, 16 Jul 2013 11:12:45 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id AFCC52C64; Tue, 16 Jul 2013 13:12:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([91.204.91.44]) by mail.wasikowski.net (scan.wasikowski.net [91.204.91.44]) (amavisd-new, port 10026) with ESMTP id C7B2mxyDmsUI; Tue, 16 Jul 2013 13:12:41 +0200 (CEST) Received: from [192.168.138.150] (83-144-115-210.static.chello.pl [83.144.115.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.wasikowski.net (Postfix) with ESMTPSA id 4700F2C61; Tue, 16 Jul 2013 13:12:41 +0200 (CEST) Message-ID: <51E52AA8.3010109@wasikowski.net> Date: Tue, 16 Jul 2013 13:12:40 +0200 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hiroki Sato Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <20130712.135621.1408565802386368060.hrs@allbsd.org> <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net> <20130712.160358.1330135778606339435.hrs@allbsd.org> In-Reply-To: <20130712.160358.1330135778606339435.hrs@allbsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, trashcan@odo.in-berlin.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 11:12:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W dniu 2013-07-12 09:03, Hiroki Sato pisze: > Please let me know if the existing configurations and/or the new > formats do not work. The following is a summary of the supported > rc.conf variables, FYI: > > Hiroki Sato wrote in > <201306200229.r5K2TnfR085621@svn.freebsd.org>: > [...] What is the current, non deprecated way, to configure IP addresses in rc.conf? Let's say for a dual stack, multi IP box I need to set: 10.0.0.66/28 and 10.0.0.67-78 as aliases and fdda:5cc1:23:4::1/48 and fdda:5cc1:23:4::2-f as aliases What is the best way to accomplish it? - -- best regards, Lukasz Wasikowski -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHlKqQACgkQXlaUxx+udUUtnwCfc74UJLDPnCjec+v8TP0d8ceV Pz4AnA6Nd5rwO5HL/LYdaJiPmBC1ENxC =bzG8 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 14:08:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2D237506 for ; Tue, 16 Jul 2013 14:08:07 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id F3E2E926 for ; Tue, 16 Jul 2013 14:08:06 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r6GE84QG061816 for ; Tue, 16 Jul 2013 10:08:05 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at mail.pix.net Message-ID: <51E553C4.9000207@pix.net> Date: Tue, 16 Jul 2013 10:08:04 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: expanding past 1 TB on amd64 References: In-Reply-To: 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.14 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, 16 Jul 2013 14:08:07 -0000 > On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek wrote: > >> In src/sys/amd64/include/vmparam.h is this handy map: >> >> * 0x0000000000000000 - 0x00007fffffffffff user map >> * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) >> * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB >> slot) >> * 0xffff804020101000 - 0xfffffdffffffffff unused >> * 0xfffffe0000000000 - 0xfffffeffffffffff 1TB direct map >> * 0xffffff0000000000 - 0xffffff7fffffffff unused >> * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map >> >> showing that the system can deal with at most 1 TB of address space >> (because of the direct map), using at most half of that for kernel >> memory (less, really, due to the inevitable VM fragmentation). >> >> New boards are coming soonish that will have the ability to go >> past that (24 DIMMs of 64 GB each = 1.5 TB). Or, if some crazy >> people :-) might want to use a most of a 768 GB board (24 DIMMs of >> 32 GB each, possible today although the price is kind of >> staggering) as wired-down kernel memory, the 512 GB VM area is >> already a problem. >> >> I have not wrapped my head around the amd64 pmap code but figured >> I'd ask: what might need to change to support larger spaces? >> Obviously NKPML4E in amd64/include/pmap.h, for the kernel start >> address; and NDMPML4E for the direct map. It looks like this >> would adjust KERNBASE and the direct map appropriately. But would >> that suffice, or have I missed something? >> >> For that matter, if these are changed to make space for future >> expansion, what would be a good expansion size? Perhaps multiply >> the sizes by 16? (If memory doubles roughly every 18 months, >> that should give room for at least 5 years.) >> >> > Chris, Neel, > > The actual data that I've seen shows that DIMMs are doubling in size at > about half that pace, about every three years. For example, see > http://users.ece.cmu.edu/~omutlu/pub/mutlu_memory-scaling_imw13_invited-talk.pdfslide > #8. So, I think that a factor of 16 is a lot more than we'll need in > the next five years. I would suggest configuring the kernel virtual > address space for 4 TB. Once you go beyond 512 GB, 4 TB is the net > "plateau" in terms of address translation cost. At 4 TB all of the PML4 > entries for the kernel virtual address space will reside in the same L2 > cache line, so a page table walk on a TLB miss for an instruction fetch > will effectively prefetch the PML4 entry for the kernel heap and vice versa. The largest commodity motherboards that are shipping today support 24 DIMMs, at a max size of 32GB per DIMM. That's 768GB, right now. (So FreeBSD is already "out of bits" in terms of supporting current shipping hardware.) The Haswell line of CPUs is widely reported to support DIMMs twice as large, and it's due in September. That would make the systems of late 2013 hold up to 1536GB of memory. Using your figure of doubling in 3 years, we'll see 3072GB systems by ~2016. And in ~2019, we'll see 6TB systems, and need to finally expand to using more than a single cache line to hold all the PML4 entries. Of course, that's speculating furiously about two generations out, and assumes keeping the current memory architecture / board design constraints. -Kurt From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 19:33:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97BF6C55; Tue, 16 Jul 2013 19:33:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 79B0ACF2; Tue, 16 Jul 2013 19:33:39 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA15503; Tue, 16 Jul 2013 22:33:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UzB0D-000Lxa-CR; Tue, 16 Jul 2013 22:33:37 +0300 Message-ID: <51E59FD9.4020103@FreeBSD.org> Date: Tue, 16 Jul 2013 22:32:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd , freebsd-fs@FreeBSD.org Subject: Re: Deadlock in nullfs/zfs somewhere References: <51DCFEDA.1090901@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 19:33:40 -0000 on 10/07/2013 19:50 Adrian Chadd said the following: > On 9 July 2013 23:27, Andriy Gapon wrote: >> on 09/07/2013 16:03 Adrian Chadd said the following: >>> Does anyone have any ideas as to what's going on? >> >> Please provide output of 'thread apply all bt' from kgdb, then perhaps someone >> might be able to tell. > > Done - http://people.freebsd.org/~adrian/ath/20130710-vm0-zfs-hang.txt vmcore.0 was useless for some reason - an interesting address was not accessible. vmcore.1 seems to be very similar and is actually useful. This problem looks like an interesting deadlock involving ZFS and VFS and vnode shortage. The most obvious things are that many threads could not allocate a new vnode and are waiting in getnewvnode_reserve and also many threads are stuck waiting on vnode locks held by the former threads. In effect, they all wait for vnlru, which in turn is stuck in zfs_freebsd_reclaim on z_teardown_lock. That lock is held by a thread doing a rollback ioctl. And that thread waits for zfs sync thread to actually perform the rollback. The sync thread waits on zfs quiesce thread to declare the current transaction group as quiesced. The quiesce thread, obviously, waits for all operations running in the current transaction group to complete. Some of those operations are e.g. VOP_CREATE -> zfs_create. They already started a zfs transaction (as a part of the current transaction group) and they execute zfs_mknode which needs a new vnode. So these threads are waiting for a new vnode and do not let the current transaction group become quiesced. GOTO beginning. Compressing the above description to the extreme, it boils down to: ZFS needs a new vnode from vnlru and is waiting on it, while vnlru has to wait on ZFS. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 19:40:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4F3ADEEC; Tue, 16 Jul 2013 19:40:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8F2D66; Tue, 16 Jul 2013 19:40:36 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hj3so1109517wib.12 for ; Tue, 16 Jul 2013 12:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=e4g4eB7EyD1Iooh4RReiuCMqz0WX8xTsz/RvmJVnyr4=; b=e9lvg/uR8ueYsWfKdCrYICdjf0cFt5NYEhsrzeH4PnXcbiYDJgFg25ONdoVSIBl+OU +ElnQ6nDnyTTCw6BEo6jyXhhXdmonxZcNh0FZ9C3YkfWaoNmE5aqwY+NiRNWOHFmxnjc x5lf20441lW/dagqWFajN7+lRYP/JBmN3bYA9P6lUEdX+YVe49BgSLPD6uq1nuGKnWRj RXAcgkJAbwZVTV86cW066V+f/A1++abFIvKrcCy9DcXFPfm/zSekwsbRzjmTzM6+vG0v mJ+0Kau6ID9NaeIlMzHubZTUnxGlX1neIrC972dPWlCnFcELVbtQMeiXhJRcLDkNTZpb ZxlA== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr2286284wik.30.1374003635341; Tue, 16 Jul 2013 12:40:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Tue, 16 Jul 2013 12:40:35 -0700 (PDT) In-Reply-To: <51E59FD9.4020103@FreeBSD.org> References: <51DCFEDA.1090901@FreeBSD.org> <51E59FD9.4020103@FreeBSD.org> Date: Tue, 16 Jul 2013 12:40:35 -0700 X-Google-Sender-Auth: GCnD91X04MXzJpmn1mauhv_YnNw Message-ID: Subject: Re: Deadlock in nullfs/zfs somewhere From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 19:40:37 -0000 On 16 July 2013 12:32, Andriy Gapon wrote: > vmcore.0 was useless for some reason - an interesting address was not accessible. Eek. > vmcore.1 seems to be very similar and is actually useful. Oh good. > This problem looks like an interesting deadlock involving ZFS and VFS and vnode > shortage. > The most obvious things are that many threads could not allocate a new vnode and > are waiting in getnewvnode_reserve and also many threads are stuck waiting on > vnode locks held by the former threads. > In effect, they all wait for vnlru, which in turn is stuck in > zfs_freebsd_reclaim on z_teardown_lock. > That lock is held by a thread doing a rollback ioctl. > And that thread waits for zfs sync thread to actually perform the rollback. > The sync thread waits on zfs quiesce thread to declare the current transaction > group as quiesced. > The quiesce thread, obviously, waits for all operations running in the current > transaction group to complete. > Some of those operations are e.g. VOP_CREATE -> zfs_create. They already > started a zfs transaction (as a part of the current transaction group) and they > execute zfs_mknode which needs a new vnode. So these threads are waiting for a > new vnode and do not let the current transaction group become quiesced. > GOTO beginning. > > Compressing the above description to the extreme, it boils down to: ZFS needs a > new vnode from vnlru and is waiting on it, while vnlru has to wait on ZFS. :( So it's a deadlock. Ok, so what's next? -adrian From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 20:48:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8963220D for ; Tue, 16 Jul 2013 20:48:48 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4F67DC0 for ; Tue, 16 Jul 2013 20:48:48 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 46F8FE3F07A for ; Tue, 16 Jul 2013 22:48:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50O+Wx8sGjie for ; Tue, 16 Jul 2013 22:48:38 +0200 (CEST) Received: from [10.10.10.107] (unknown [83.223.1.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 26ACFE3F079 for ; Tue, 16 Jul 2013 22:48:38 +0200 (CEST) From: Joel Dahl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Lenovo x220 - hangs on shutdown Message-Id: Date: Tue, 16 Jul 2013 22:48:35 +0200 To: current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 20:48:48 -0000 Hi, Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now = it hangs when I do a shutdown from an xterm. The screen just goes black = and the fan never spins down. It doesn't respond to ping. It didn't do this while I was running a current from mid-June. Any specific revision I should try to back out before I start a time = consuming binary search? // Joel= From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 21:12:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F11786B for ; Tue, 16 Jul 2013 21:12:45 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 979001F0 for ; Tue, 16 Jul 2013 21:12:44 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id k10so641667eaj.25 for ; Tue, 16 Jul 2013 14:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=77GV+4nhQG3iAh/xcm+EZN7W1AcrarNdTAvUNyn4u2I=; b=olyNyW2STGIBu9frTQhqp33lPw4NvTr0ey5i5tGiRhiQIjD2LUrUgAW7wxgmE4eNHx aJ8YVx8zHec7cDTofUs2jD7XU06wGouKrIgaTHnimRtUxSyXIsb2G3Yo2OcUOIqjRwBm zBbIoi/aai86x/IYQNebzaq9DQVXNA9XGVqPUnaf5456PYL/+3AO0Vw8mI35rnA3XKcg dHYfu+Hyk3YXznuvDBjIsilmF/pA/PNhwA0ox9MYeljI1ZKKsFuQxskjz5H2QD/W/Gaj LyMuGH7iB0q//xgF75CtEYWh7Abvs/gZ7OD2jNGXhYE04UR568iapXiMOu8kNI//KCNG bXPQ== MIME-Version: 1.0 X-Received: by 10.14.219.6 with SMTP id l6mr2755028eep.152.1374009162887; Tue, 16 Jul 2013 14:12:42 -0700 (PDT) Received: by 10.223.61.130 with HTTP; Tue, 16 Jul 2013 14:12:42 -0700 (PDT) In-Reply-To: <51E553C4.9000207@pix.net> References: <51E553C4.9000207@pix.net> Date: Tue, 16 Jul 2013 14:12:42 -0700 Message-ID: Subject: Re: expanding past 1 TB on amd64 From: Alan Cox To: Kurt Lidl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:12:45 -0000 On Tue, Jul 16, 2013 at 7:08 AM, Kurt Lidl wrote: > On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek >> wrote: >> >> In src/sys/amd64/include/vmparam.**h is this handy map: >>> >>> * 0x0000000000000000 - 0x00007fffffffffff user map >>> * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) >>> * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB >>> slot) >>> * 0xffff804020101000 - 0xfffffdffffffffff unused >>> * 0xfffffe0000000000 - 0xfffffeffffffffff 1TB direct map >>> * 0xffffff0000000000 - 0xffffff7fffffffff unused >>> * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map >>> >>> showing that the system can deal with at most 1 TB of address space >>> (because of the direct map), using at most half of that for kernel >>> memory (less, really, due to the inevitable VM fragmentation). >>> >>> New boards are coming soonish that will have the ability to go >>> past that (24 DIMMs of 64 GB each = 1.5 TB). Or, if some crazy >>> people :-) might want to use a most of a 768 GB board (24 DIMMs of >>> 32 GB each, possible today although the price is kind of >>> staggering) as wired-down kernel memory, the 512 GB VM area is >>> already a problem. >>> >>> I have not wrapped my head around the amd64 pmap code but figured >>> I'd ask: what might need to change to support larger spaces? >>> Obviously NKPML4E in amd64/include/pmap.h, for the kernel start >>> address; and NDMPML4E for the direct map. It looks like this >>> would adjust KERNBASE and the direct map appropriately. But would >>> that suffice, or have I missed something? >>> >>> For that matter, if these are changed to make space for future >>> expansion, what would be a good expansion size? Perhaps multiply >>> the sizes by 16? (If memory doubles roughly every 18 months, >>> that should give room for at least 5 years.) >>> >>> >>> Chris, Neel, >> >> The actual data that I've seen shows that DIMMs are doubling in size at >> about half that pace, about every three years. For example, see >> http://users.ece.cmu.edu/~**omutlu/pub/mutlu_memory-** >> scaling_imw13_invited-talk.**pdfslide >> #8. So, I think that a factor of 16 is a lot more than we'll need in >> the next five years. I would suggest configuring the kernel virtual >> address space for 4 TB. Once you go beyond 512 GB, 4 TB is the net >> "plateau" in terms of address translation cost. At 4 TB all of the PML4 >> entries for the kernel virtual address space will reside in the same L2 >> cache line, so a page table walk on a TLB miss for an instruction fetch >> will effectively prefetch the PML4 entry for the kernel heap and vice >> versa. >> > > The largest commodity motherboards that are shipping today support > 24 DIMMs, at a max size of 32GB per DIMM. That's 768GB, right now. > (So FreeBSD is already "out of bits" in terms of supporting current > shipping hardware.) Actually, this scenario with 768 GB of RAM on amd64 as it is today is analogous to the typical 32-bit i386 machine, where the amount of RAM has long exceeded the default 1 GB size of the kernel virtual address space. In theory, we could currently handle up to 1 TB of RAM, but the kernel virtual address space would only be 512 GB. ... The Haswell line of CPUs is widely reported to > support DIMMs twice as large, and it's due in September. That would > make the systems of late 2013 hold up to 1536GB of memory. > > Using your figure of doubling in 3 years, we'll see 3072GB systems by > ~2016. And in ~2019, we'll see 6TB systems, and need to finally expand > to using more than a single cache line to hold all the PML4 entries. > > Yes, this is a reasonable prognostication. Alan > Of course, that's speculating furiously about two generations out, and > assumes keeping the current memory architecture / board design > constraints. > > -Kurt > > > ______________________________**_________________ > freebsd-current@freebsd.org mailing list > http://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 Jul 16 23:12:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A0614FB; Tue, 16 Jul 2013 23:12:46 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 25AB6823; Tue, 16 Jul 2013 23:12:45 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r6GMxDHd040350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 00:59:13 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r6GMx6K6090096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 00:59:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r6GMx6cD093364; Wed, 17 Jul 2013 00:59:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r6GMx6SS093363; Wed, 17 Jul 2013 00:59:06 +0200 (CEST) (envelope-from ticso) Date: Wed, 17 Jul 2013 00:59:06 +0200 From: Bernd Walter To: alc@freebsd.org Subject: Max mmap space (was: expanding past 1 TB on amd64) Message-ID: <20130716225906.GT76364@cicely7.cicely.de> References: <51E553C4.9000207@pix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 23:12:46 -0000 On Tue, Jul 16, 2013 at 02:12:42PM -0700, Alan Cox wrote: > On Tue, Jul 16, 2013 at 7:08 AM, Kurt Lidl wrote: > > > On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek > >> wrote: > >> > >> In src/sys/amd64/include/vmparam.**h is this handy map: > >>> > >>> * 0x0000000000000000 - 0x00007fffffffffff user map > >>> * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) > >>> * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB > >>> slot) > >>> * 0xffff804020101000 - 0xfffffdffffffffff unused > >>> * 0xfffffe0000000000 - 0xfffffeffffffffff 1TB direct map > >>> * 0xffffff0000000000 - 0xffffff7fffffffff unused > >>> * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map > >> > >> The actual data that I've seen shows that DIMMs are doubling in size at > >> about half that pace, about every three years. For example, see > >> http://users.ece.cmu.edu/~**omutlu/pub/mutlu_memory-** > >> scaling_imw13_invited-talk.**pdfslide > >> #8. So, I think that a factor of 16 is a lot more than we'll need in > >> the next five years. I would suggest configuring the kernel virtual > >> address space for 4 TB. Once you go beyond 512 GB, 4 TB is the net > >> "plateau" in terms of address translation cost. At 4 TB all of the PML4 > >> entries for the kernel virtual address space will reside in the same L2 > >> cache line, so a page table walk on a TLB miss for an instruction fetch > >> will effectively prefetch the PML4 entry for the kernel heap and vice > >> versa. > >> > > > > The largest commodity motherboards that are shipping today support > > 24 DIMMs, at a max size of 32GB per DIMM. That's 768GB, right now. > > (So FreeBSD is already "out of bits" in terms of supporting current > > shipping hardware.) > > > > Actually, this scenario with 768 GB of RAM on amd64 as it is today is > analogous to the typical 32-bit i386 machine, where the amount of RAM has > long exceeded the default 1 GB size of the kernel virtual address space. > In theory, we could currently handle up to 1 TB of RAM, but the kernel > virtual address space would only be 512 GB. Talking about virtual address space. I plan to permanently mmap serveral nGB sized files (all together 6-8TB) into a single process address space. Actually I see the user map is 128TB, so I shouldn't get into trouble by doing this and also have lot of additional space left to avoid problems because of fragmentation. The system has 192G physical memory, so mapping tables have enough space. Is there anything else to worry about? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 06:49:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F3C7DC7 for ; Wed, 17 Jul 2013 06:49:03 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) by mx1.freebsd.org (Postfix) with ESMTP id 2B79A8FA for ; Wed, 17 Jul 2013 06:49:03 +0000 (UTC) Received: from chombo.houseloki.net (montesse-2-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:19b9::2]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 7918EE6040 for ; Tue, 16 Jul 2013 23:49:02 -0700 (PDT) Received: from [IPv6:fc00:970::31b9:e310:4bb:8f61] (unknown [IPv6:fc00:970::31b9:e310:4bb:8f61]) by chombo.houseloki.net (Postfix) with ESMTPSA id E80F0C51 for ; Tue, 16 Jul 2013 23:49:00 -0700 (PDT) Message-ID: <51E63E59.6040709@bluerosetech.com> Date: Tue, 16 Jul 2013 23:48:57 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current Subject: Re: expanding past 1 TB on amd64 References: <51E553C4.9000207@pix.net> In-Reply-To: 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.14 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, 17 Jul 2013 06:49:03 -0000 On 7/16/2013 2:12 PM, Alan Cox wrote: > ... The Haswell line of CPUs is widely reported to >> support DIMMs twice as large, and it's due in September. That would >> make the systems of late 2013 hold up to 1536GB of memory. I'd point you at stuff like the Supermicro X8BQ6 series of mainboards. QP E5-8800 systems with 1 TB of memory have been around since 2011. From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 07:17:02 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6316486 for ; Wed, 17 Jul 2013 07:17:02 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) by mx1.freebsd.org (Postfix) with ESMTP id 75FEAA2D for ; Wed, 17 Jul 2013 07:17:02 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 8D046BD936; Wed, 17 Jul 2013 07:16:55 +0000 (UTC) Date: Wed, 17 Jul 2013 09:16:55 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Subject: core.txt.N not created anymore on panic Message-ID: <20130717071655.GE4484@caravan.chchile.org> Mail-Followup-To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 07:17:02 -0000 Hi, Early May I set ddb_enable="YES" (crashinfo_enable="YES" by default). Upon panic, it created the following kind of files: -rw------- 1 root wheel 549 Jun 26 22:09 info.0 -rw------- 1 root wheel 1518501888 Jun 26 22:09 vmcore.0 -rw------- 1 root wheel 196981 Jun 26 22:09 core.txt.0 -rw------- 1 root wheel 546 Jun 26 23:15 info.1 -rw------- 1 root wheel 472608768 Jun 26 23:15 vmcore.1 -rw------- 1 root wheel 207034 Jun 26 23:15 core.txt.1 -rw------- 1 root wheel 546 Jun 27 00:47 info.2 -rw------- 1 root wheel 667717632 Jun 27 00:47 vmcore.2 -rw------- 1 root wheel 208745 Jun 27 00:48 core.txt.2 -rw------- 1 root wheel 549 Jul 3 14:40 info.3 -rw------- 1 root wheel 1455198208 Jul 3 14:40 vmcore.3 -rw------- 1 root wheel 208173 Jul 3 14:41 core.txt.3 The core.txt.N files contained crashinfo(8) informations along with ddb textdump, because crashinfo(8) outputs dmesg. Yesterday, I upgraded to latest -CURRENT from one from June 9th. While stress-testing overnight, I got a couple of panics but core.txt.N are not created anymore. -rw------- 1 root wheel 530 Jul 17 01:10 info.5 -rw------- 1 root wheel 75776 Jul 17 01:10 textdump.tar.5 -rw------- 1 root wheel 529 Jul 17 02:01 info.6 -rw------- 1 root wheel 74240 Jul 17 02:01 textdump.tar.6 -rw------- 1 root wheel 530 Jul 17 04:20 info.7 -rw------- 1 root wheel 74752 Jul 17 04:20 textdump.tar.7 -rw------- 1 root wheel 530 Jul 17 07:50 info.8 -rw------- 1 root wheel 92672 Jul 17 07:50 textdump.tar.8 -rw------- 1 root wheel 531 Jul 17 08:44 info.9 -rw------- 1 root wheel 110592 Jul 17 08:44 textdump.tar.9 Each textdump.tar.N contains: tar tvf /var/crash/textdump.tar.9 -rw------- 0 root wheel 49152 Jul 17 08:30 ddb.txt -rw------- 0 root wheel 3179 Jul 17 08:30 config.txt -rw------- 0 root wheel 54137 Jul 17 08:30 msgbuf.txt -rw------- 0 root wheel 88 Jul 17 08:30 panic.txt -rw------- 0 root wheel 120 Jul 17 08:30 version.txt Any idea changed in between? I checked svn log in etc/ but I found nothing relevant. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 07:21:53 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3389793 for ; Wed, 17 Jul 2013 07:21:52 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) by mx1.freebsd.org (Postfix) with ESMTP id C12DFA5F for ; Wed, 17 Jul 2013 07:21:52 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id E0335BD977; Wed, 17 Jul 2013 07:21:51 +0000 (UTC) Date: Wed, 17 Jul 2013 09:21:51 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Subject: Re: core.txt.N not created anymore on panic Message-ID: <20130717072151.GF4484@caravan.chchile.org> Mail-Followup-To: freebsd-current@FreeBSD.org References: <20130717071655.GE4484@caravan.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130717071655.GE4484@caravan.chchile.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 07:21:53 -0000 On Wed, Jul 17, 2013 at 09:16:55AM +0200, Jeremie Le Hen wrote: > Hi, > > Early May I set ddb_enable="YES" (crashinfo_enable="YES" by default). > Upon panic, it created the following kind of files: > > -rw------- 1 root wheel 549 Jun 26 22:09 info.0 > -rw------- 1 root wheel 1518501888 Jun 26 22:09 vmcore.0 > -rw------- 1 root wheel 196981 Jun 26 22:09 core.txt.0 > -rw------- 1 root wheel 546 Jun 26 23:15 info.1 > -rw------- 1 root wheel 472608768 Jun 26 23:15 vmcore.1 > -rw------- 1 root wheel 207034 Jun 26 23:15 core.txt.1 > -rw------- 1 root wheel 546 Jun 27 00:47 info.2 > -rw------- 1 root wheel 667717632 Jun 27 00:47 vmcore.2 > -rw------- 1 root wheel 208745 Jun 27 00:48 core.txt.2 > -rw------- 1 root wheel 549 Jul 3 14:40 info.3 > -rw------- 1 root wheel 1455198208 Jul 3 14:40 vmcore.3 > -rw------- 1 root wheel 208173 Jul 3 14:41 core.txt.3 > > The core.txt.N files contained crashinfo(8) informations along with > ddb textdump, because crashinfo(8) outputs dmesg. > > > Yesterday, I upgraded to latest -CURRENT from one from June 9th. While > stress-testing overnight, I got a couple of panics but core.txt.N are > not created anymore. > > -rw------- 1 root wheel 530 Jul 17 01:10 info.5 > -rw------- 1 root wheel 75776 Jul 17 01:10 textdump.tar.5 > -rw------- 1 root wheel 529 Jul 17 02:01 info.6 > -rw------- 1 root wheel 74240 Jul 17 02:01 textdump.tar.6 > -rw------- 1 root wheel 530 Jul 17 04:20 info.7 > -rw------- 1 root wheel 74752 Jul 17 04:20 textdump.tar.7 > -rw------- 1 root wheel 530 Jul 17 07:50 info.8 > -rw------- 1 root wheel 92672 Jul 17 07:50 textdump.tar.8 > -rw------- 1 root wheel 531 Jul 17 08:44 info.9 > -rw------- 1 root wheel 110592 Jul 17 08:44 textdump.tar.9 > > Each textdump.tar.N contains: > > tar tvf /var/crash/textdump.tar.9 > -rw------- 0 root wheel 49152 Jul 17 08:30 ddb.txt > -rw------- 0 root wheel 3179 Jul 17 08:30 config.txt > -rw------- 0 root wheel 54137 Jul 17 08:30 msgbuf.txt > -rw------- 0 root wheel 88 Jul 17 08:30 panic.txt > -rw------- 0 root wheel 120 Jul 17 08:30 version.txt > > Any idea changed in between? I checked svn log in etc/ but I found > nothing relevant. For the record: debug.ddb.capture.bufoff: 0 debug.ddb.capture.maxbufsize: 5242880 debug.ddb.capture.inprogress: 0 debug.ddb.capture.bufsize: 49152 debug.ddb.capture.data: debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo debug.ddb.scripting.unscript: debug.ddb.textdump.pending: 0 debug.ddb.textdump.do_config: 1 debug.ddb.textdump.do_ddb: 1 debug.ddb.textdump.do_msgbuf: 1 debug.ddb.textdump.do_panic: 1 debug.ddb.textdump.do_version: 1 debug.debugger_on_panic: 1 debug.kdb.available: ddb debug.kdb.current: ddb debug.kdb.enter: 0 debug.kdb.panic: 0 debug.kdb.trap: 0 debug.kdb.trap_code: 0 debug.kdb.break_to_debugger: 0 debug.kdb.alt_break_to_debugger: 0 -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 10:07:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 428185BA for ; Wed, 17 Jul 2013 10:07:12 +0000 (UTC) (envelope-from schmiedgen@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id D942D6AB for ; Wed, 17 Jul 2013 10:07:11 +0000 (UTC) Received: from [192.168.10.5] ([62.246.110.10]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MLvGW-1V4tso38Ci-007jhM for ; Wed, 17 Jul 2013 12:07:10 +0200 Message-ID: <51E66CCF.2040205@gmx.net> Date: Wed, 17 Jul 2013 12:07:11 +0200 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joel Dahl Subject: Re: Lenovo x220 - hangs on shutdown References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/6i7PiD3E1/LkptPO2HueCb1Y8/jzOaQmUX59G6lhdMuuqGvEZM CDgQmD7Kot10Y2pEQmOpuveEWR4sX1pTeNN53zY0h2mVd4j7TMvYUdtS37dTJxZpFdUE4xm q7rg1U/hN3iUtns2ueYWUHl8PX8NCM73CPktRspcVnkmlyLzQaimMQqgDc+K0OEJb7avPPE fzBYLayT48rM0izO3XAHQ== Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 10:07:12 -0000 On 16.07.2013 22:48, Joel Dahl wrote: > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. My build is from Sunday. I never type 'shutdown', but it is configured to shutdown when I close the display. Everything works fine. I can investigate revision and shutdown from xterm at home if you like. Michael From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 11:27:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B8CDA3B; Wed, 17 Jul 2013 11:27:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1858CA3E; Wed, 17 Jul 2013 11:27:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA02725; Wed, 17 Jul 2013 14:27:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UzPt3-00007u-04; Wed, 17 Jul 2013 14:27:13 +0300 Message-ID: <51E67F54.9080800@FreeBSD.org> Date: Wed, 17 Jul 2013 14:26:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Deadlock in nullfs/zfs somewhere References: <51DCFEDA.1090901@FreeBSD.org> <51E59FD9.4020103@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 11:27:16 -0000 on 16/07/2013 22:40 Adrian Chadd said the following: > :( So it's a deadlock. Ok, so what's next? A creative process... One possibility is to add getnewvnode_reserve() calls before the ZFS transaction beginnings in the places where a new vnode/znode may have to be allocated within a transaction. This looks like a quick and cheap solution but it makes the code somewhat messier. Another possibility is to change something in VFS machinery, so that VOP_RECLAIM getting blocked for one filesystem does not prevent vnode allocation for other filesystems. I could think of other possible solutions via infrastructural changes in VFS or ZFS... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 12:20:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 84672C9D for ; Wed, 17 Jul 2013 12:20:36 +0000 (UTC) (envelope-from rodrigo@bebik.net) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12]) by mx1.freebsd.org (Postfix) with ESMTP id 13029C9C for ; Wed, 17 Jul 2013 12:20:34 +0000 (UTC) Received: from oldfaithful.bebik.local (unknown [82.227.164.69]) by smtp3-g21.free.fr (Postfix) with ESMTP id D138DA6221 for ; Wed, 17 Jul 2013 14:20:27 +0200 (CEST) Received: by oldfaithful.bebik.local (Postfix, from userid 1001) id ABADDAA88E; Wed, 17 Jul 2013 14:07:33 +0200 (CEST) Date: Wed, 17 Jul 2013 14:07:33 +0200 From: Rodrigo OSORIO To: freebsd-current@freebsd.org Subject: Re: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130717120733.GA36587@oldfaithful.bebik.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 12:20:36 -0000 > Date: Wed, 17 Jul 2013 12:07:11 +0200 > From: Michael Schmiedgen > To: Joel Dahl > Cc: current@freebsd.org > Subject: Re: Lenovo x220 - hangs on shutdown > Message-ID: <51E66CCF.2040205@gmx.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 16.07.2013 22:48, Joel Dahl wrote: > > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. > > My build is from Sunday. I never type 'shutdown', but it is configured > to shutdown when I close the display. Everything works fine. > I can investigate revision and shutdown from xterm at home if you > like. > > Michael Hi, I fall in this kind of issue with my laptop and deactivating powerd solves the problem. I'm sorry but I didn't explore this issue beyond. - rodrigo From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 14:17:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A010ED7 for ; Wed, 17 Jul 2013 14:17:28 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id EA941232 for ; Wed, 17 Jul 2013 14:17:27 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r6HEHQwI072807 for ; Wed, 17 Jul 2013 10:17:26 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at mail.pix.net Message-ID: <51E6A776.7050101@pix.net> Date: Wed, 17 Jul 2013 10:17:26 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: expanding past 1 TB on amd64 References: <51E63E59.6040709@bluerosetech.com> In-Reply-To: <51E63E59.6040709@bluerosetech.com> 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.14 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, 17 Jul 2013 14:17:28 -0000 > On 7/16/2013 2:12 PM, Alan Cox wrote: >> ... The Haswell line of CPUs is widely reported to >>> support DIMMs twice as large, and it's due in September. That would >>> make the systems of late 2013 hold up to 1536GB of memory. > > I'd point you at stuff like the Supermicro X8BQ6 series of mainboards. > QP E5-8800 systems with 1 TB of memory have been around since 2011. That might have been true, but I did check SuperMicro's "motherboard matrix" of available products before posting. The largest listed memory configuration on any of their current products is 768GB. http://www.supermicro.com/products/motherboard/matrix/?cpuclass=all&sorton=memory -Kurt From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 14:53:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24C1DB29 for ; Wed, 17 Jul 2013 14:53:01 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id C8AA860B for ; Wed, 17 Jul 2013 14:53:00 +0000 (UTC) Received: from [194.32.164.26] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id r6HEoQgp079520; Wed, 17 Jul 2013 15:50:26 +0100 (BST) (envelope-from rb@gid.co.uk) Subject: Re: expanding past 1 TB on amd64 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <51E6A776.7050101@pix.net> Date: Wed, 17 Jul 2013 15:50:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E63E59.6040709@bluerosetech.com> <51E6A776.7050101@pix.net> To: Kurt Lidl X-Mailer: Apple Mail (2.1283) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 14:53:01 -0000 Hi, On 17 Jul 2013, at 15:17, Kurt Lidl wrote: >> On 7/16/2013 2:12 PM, Alan Cox wrote: >>> ... The Haswell line of CPUs is widely reported to >>>> support DIMMs twice as large, and it's due in September. That = would >>>> make the systems of late 2013 hold up to 1536GB of memory. >>=20 >> I'd point you at stuff like the Supermicro X8BQ6 series of = mainboards. >> QP E5-8800 systems with 1 TB of memory have been around since 2011. >=20 > That might have been true, but I did check SuperMicro's > "motherboard matrix" of available products before posting. >=20 > The largest listed memory configuration on > any of their current products is 768GB. >=20 > = http://www.supermicro.com/products/motherboard/matrix/?cpuclass=3Dall&sort= on=3Dmemory >=20 > -Kurt http://www.supermicro.com/products/motherboard/Xeon7000 Looks like their matrix is not up-to-date. -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 15:26:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE7F35E5 for ; Wed, 17 Jul 2013 15:26:47 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 758F4880 for ; Wed, 17 Jul 2013 15:26:47 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id a11so1179664qen.24 for ; Wed, 17 Jul 2013 08:26:47 -0700 (PDT) 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=LaZVWk9T4SrMCwQgrFeOb47XKh5WXl4LNR36C8Skkww=; b=yc9NfVG6UfSzhrAtKsn7MtWSQeza+yJJXUSip7VAS/k4NYd1sb3Fx9TSyFx9QNO750 ykmTO55AnLwaFMJWCGI3NYfo5sBIciz6Y4Czmd5ooTPeaXfb65XwOMjhCUltYF7iqYUk bFaE1B4YtQ/TEO3j4Q/9xhEk85k6lOn1SFFgZRn9iudTtxFgWuAEaF3Heo/G/uYnxrpQ LCgCav/MEYcrv7YRQmUP9h2y+wOJBB5SgvK4GxeoLp+QEKKioRfXF8z7AQuHALxywU0z FuFVKquCl6tAodUzLXWH/ealSCY+Znb0AEGX8yWH2rzXMKqrsDXHUAS/ATLay3dhGHRN Jkqg== MIME-Version: 1.0 X-Received: by 10.229.196.73 with SMTP id ef9mr1926327qcb.85.1374074807011; Wed, 17 Jul 2013 08:26:47 -0700 (PDT) Received: by 10.49.49.135 with HTTP; Wed, 17 Jul 2013 08:26:46 -0700 (PDT) In-Reply-To: References: <51E63E59.6040709@bluerosetech.com> <51E6A776.7050101@pix.net> Date: Wed, 17 Jul 2013 08:26:46 -0700 Message-ID: Subject: Re: expanding past 1 TB on amd64 From: Freddie Cash To: Bob Bishop Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD-Current , Kurt Lidl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 15:26:47 -0000 On Wed, Jul 17, 2013 at 7:50 AM, Bob Bishop wrote: > Hi, > > On 17 Jul 2013, at 15:17, Kurt Lidl wrote: > > >> On 7/16/2013 2:12 PM, Alan Cox wrote: > >>> ... The Haswell line of CPUs is widely reported to > >>>> support DIMMs twice as large, and it's due in September. That would > >>>> make the systems of late 2013 hold up to 1536GB of memory. > >> > >> I'd point you at stuff like the Supermicro X8BQ6 series of mainboards. > >> QP E5-8800 systems with 1 TB of memory have been around since 2011. > > > > That might have been true, but I did check SuperMicro's > > "motherboard matrix" of available products before posting. > > > > The largest listed memory configuration on > > any of their current products is 768GB. > > > > > http://www.supermicro.com/products/motherboard/matrix/?cpuclass=all&sorton=memory > > > > -Kurt > > http://www.supermicro.com/products/motherboard/Xeon7000 > > Looks like their matrix is not up-to-date. There's also several AMD motherboards that support 1 TB of RAM: http://www.supermicro.com/products/nfo/AMD_G34.cfm?pg=MOBO You know, the CPUs that started the 64-bit x86 support ... :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 15:46:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52A30C80 for ; Wed, 17 Jul 2013 15:46:16 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB139DA for ; Wed, 17 Jul 2013 15:46:15 +0000 (UTC) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mx.arcor.de (Postfix) with ESMTP id 2DBDEE460B for ; Wed, 17 Jul 2013 17:14:05 +0200 (CEST) Received: from mail-in-15.arcor-online.net (mail-in-15.arcor-online.net [151.189.21.55]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id 2ACAD112020 for ; Wed, 17 Jul 2013 17:14:05 +0200 (CEST) X-Greylist: Passed host: 94.217.103.182 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-15.arcor-online.net EEEAA1AB53E Received: from lorvorc.mips.inka.de (dslb-094-217-103-182.pools.arcor-ip.net [94.217.103.182]) by mail-in-15.arcor-online.net (Postfix) with ESMTPS id EEEAA1AB53E for ; Wed, 17 Jul 2013 17:14:04 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id r6HFE4m0022179 for ; Wed, 17 Jul 2013 17:14:04 +0200 (CEST) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id r6HFE4Mk022178 for freebsd-current@freebsd.org; Wed, 17 Jul 2013 17:14:04 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Sound lag over HDMI Date: Wed, 17 Jul 2013 15:14:04 +0000 (UTC) Message-ID: References: <20130712205446.GB2198@acme.spoerlein.net> <51E0775F.3070805@FreeBSD.org> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 15:46:16 -0000 Alexander Motin wrote: > I don't know what to say. I am now using HDMI audio from NVIDIA card to > quite old external 5.1 receiver with XBMC every day, and I haven't > noticed lags. > > The only potentially related effect I have noticed is that my receiver > eats first second or about that of playback stream. That's from the receiver examining the incoming data to see if it is AC-3, DTS, or plain PCM. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 16:18:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4804A53E for ; Wed, 17 Jul 2013 16:18:15 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF62B5D for ; Wed, 17 Jul 2013 16:18:15 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r6HGIEd1073834; Wed, 17 Jul 2013 12:18:14 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at mail.pix.net Message-ID: <51E6C3C6.8040209@pix.net> Date: Wed, 17 Jul 2013 12:18:14 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Freddie Cash Subject: Re: expanding past 1 TB on amd64 References: <51E63E59.6040709@bluerosetech.com> <51E6A776.7050101@pix.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 16:18:15 -0000 On 7/17/13 11:26 AM, Freddie Cash wrote: > On Wed, Jul 17, 2013 at 7:50 AM, Bob Bishop > wrote: > > Hi, > > On 17 Jul 2013, at 15:17, Kurt Lidl wrote: > > >> On 7/16/2013 2:12 PM, Alan Cox wrote: > >>> ... The Haswell line of CPUs is widely reported to > >>>> support DIMMs twice as large, and it's due in September. That > would > >>>> make the systems of late 2013 hold up to 1536GB of memory. > >> > >> I'd point you at stuff like the Supermicro X8BQ6 series of > mainboards. > >> QP E5-8800 systems with 1 TB of memory have been around since 2011. > > > > That might have been true, but I did check SuperMicro's > > "motherboard matrix" of available products before posting. > > > > The largest listed memory configuration on > > any of their current products is 768GB. > > > > > http://www.supermicro.com/products/motherboard/matrix/?cpuclass=all&sorton=memory > > > > -Kurt > > http://www.supermicro.com/products/motherboard/Xeon7000 > > Looks like their matrix is not up-to-date. > > > There's also several AMD motherboards that support 1 TB of RAM: > http://www.supermicro.com/products/nfo/AMD_G34.cfm?pg=MOBO > > You know, the CPUs that started the 64-bit x86 support ... :) Searching a bit harder, it looks like Intel is shipping a quad-socket board that supports "1500GB" of memory. http://ark.intel.com/products/61033 So, 1500GB is now, and the next doubling will probably be "soon", assuming Intel revs their quad processor boards for Haswell, and that support for 64GB DIMMs is there. I'm not trying to find the biggest motherboard out there, I'm just trying to say that Chris' patch for support up to 16TB isn't too farfetched. And within the next "5 year" window, it's entirely likely that > 4TB systems will be available. -Kurt From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 17:19:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B102611; Wed, 17 Jul 2013 17:19:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 8B044E95; Wed, 17 Jul 2013 17:19:03 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id m46so2072009wev.30 for ; Wed, 17 Jul 2013 10:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QcE8DTskG1MeoodPIsqtquSYJMiHeaUmzK/gBYHIom4=; b=wzgeE/Vid9VR66auA1B1uq7BT9BHFsG7BA9L4fliwv/IYB0Mu8zwKA+/O2ro23N3+D pwnChAlscZsi1r9U8eOK/OmHTTMS1/Vk6+hIcq/xpi9u1Shir4WHr3WZEELIynmTdCtS nFjUQxSG1UmrfVP00z/pO46xzj12xxkl728HBzgVuVNNBOh2jCjvlssk28f4zzgGvDCN 7vbWdyGRn3Q80e8RKlyqWfDjSHDKAl7Kztaj04DmzwD7U/3d5chRNu8v7cDPwu0SyRmM EIhKrI7xkocOYh1nCTmRbiokJwIaqkuausv/xKwFr7HSUcwLeZiQtF/O/mtzozyBD+Je gkKA== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr5541008wjs.79.1374081542505; Wed, 17 Jul 2013 10:19:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 17 Jul 2013 10:19:02 -0700 (PDT) In-Reply-To: <51E67F54.9080800@FreeBSD.org> References: <51DCFEDA.1090901@FreeBSD.org> <51E59FD9.4020103@FreeBSD.org> <51E67F54.9080800@FreeBSD.org> Date: Wed, 17 Jul 2013 10:19:02 -0700 X-Google-Sender-Auth: ptSTsrEDyA2Cg2Pxbh0saE1rqCw Message-ID: Subject: Re: Deadlock in nullfs/zfs somewhere From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 17:19:04 -0000 On 17 July 2013 04:26, Andriy Gapon wrote: > on 16/07/2013 22:40 Adrian Chadd said the following: >> :( So it's a deadlock. Ok, so what's next? > > A creative process... Wonderful. :) > One possibility is to add getnewvnode_reserve() calls before the ZFS transaction > beginnings in the places where a new vnode/znode may have to be allocated within > a transaction. > This looks like a quick and cheap solution but it makes the code somewhat messier. > > Another possibility is to change something in VFS machinery, so that VOP_RECLAIM > getting blocked for one filesystem does not prevent vnode allocation for other > filesystems. > > I could think of other possible solutions via infrastructural changes in VFS or > ZFS... Well, what do others think? This seems like a showstopper for systems with lots and lots of ZFS filesystems doing lots and lots of activity. -adrian From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 17:39:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D84EBD13 for ; Wed, 17 Jul 2013 17:39:32 +0000 (UTC) (envelope-from schmiedgen@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7B12DF86 for ; Wed, 17 Jul 2013 17:39:32 +0000 (UTC) Received: from [192.168.20.2] ([94.222.163.126]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LjvV7-1USevC0FQ1-00bs4Z for ; Wed, 17 Jul 2013 19:39:31 +0200 Message-ID: <51E6D6D2.20804@gmx.net> Date: Wed, 17 Jul 2013 19:39:30 +0200 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130715 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joel Dahl Subject: Re: Lenovo x220 - hangs on shutdown References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:y8K7IK3A7b5QvsiCP+d/+vYR7zyVwhyYJ+5WtoGkt4fV36rpc1B gi5lFRlGlLBvH++spvdNdT6311fKowocheLgFo7z4ZqXfImxJx7K7D5Cm9w+Yo2agO+yWD+ QKYTtMusdpcoKALSioyWLq3HE9KzJOvK6Ey3PEndu1vebQTozf7/4Kzb+/TTpC6Smm0ACvw srJJk2xLgpFrybiA+zQlA== Cc: rodrigo@bebik.net, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 17:39:32 -0000 On 07/16/13 22:48, Joel Dahl wrote: > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. X220, 10.0-CURRENT #0 r253368 amd, powerd running. In xterm I type 'shutdown -p now' and everything works fine. But the kernel is compiled without INVARIANTS and without WITNESS and malloc runs in production mode. Michael From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 17:54:40 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 307E0143 for ; Wed, 17 Jul 2013 17:54:40 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id EAB91C3 for ; Wed, 17 Jul 2013 17:54:39 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 14EFAE3F07A; Wed, 17 Jul 2013 19:54:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ZSUhShDc6o; Wed, 17 Jul 2013 19:54:36 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id C4AE0E3F079; Wed, 17 Jul 2013 19:54:35 +0200 (CEST) Date: Wed, 17 Jul 2013 19:54:33 +0200 From: Joel Dahl To: Michael Schmiedgen Subject: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130717175432.GA56585@devbox.vnode.local> References: <51E6D6D2.20804@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E6D6D2.20804@gmx.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rodrigo@bebik.net, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 17:54:40 -0000 On Wed, Jul 17, 2013 at 07:39:30PM +0200, Michael Schmiedgen wrote: > On 07/16/13 22:48, Joel Dahl wrote: > > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. > > X220, 10.0-CURRENT #0 r253368 amd, powerd running. In xterm I type > 'shutdown -p now' and everything works fine. But the kernel is > compiled without INVARIANTS and without WITNESS and malloc runs > in production mode. I tried enabling powerd - no change. The machine won't power off. -- Joel From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 19:05:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EDC41160 for ; Wed, 17 Jul 2013 19:05:50 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 82AFB3D8 for ; Wed, 17 Jul 2013 19:05:50 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id r6HJ5lhA011710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 Jul 2013 21:05:48 +0200 Received: from [192.168.1.110] (48.Red-83-60-209.dynamicIP.rima-tde.net [83.60.209.48]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6HJ5ko1006107 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 17 Jul 2013 21:05:47 +0200 Message-ID: <51E6EB0A.2060407@entel.upc.edu> Date: Wed, 17 Jul 2013 21:05:46 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD current Subject: Panic when starting X with Intel KMS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Wed, 17 Jul 2013 21:05:48 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 19:05:51 -0000 Hi, I'm having panics or hard freezes when starting X with an Intel video card. The machine is able to start old X+twm without problems but when I try gnome3 (in normal or fallback mode, doesn't matter) the machine panics or hard freezes. This doesn't happen when running X with vesa. With vesa the gnome is able to start in fallback (no composition) mode. Also, an old i386 with an nvidia card is able to run that gnome3 with composition so I'd say it has to do with the intel card. These are the specs of the machine: FreeBSD 10.0-CURRENT #4 r+3dc57aa: Wed Jul 17 15:13:07 CEST 2013 root@portgus:/usr/obj/usr/src/sys/CUSTOM amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 RAM: 8GB Video Card: Intel chipid=0x00468086 The debugging knobs in the kernel config are there. I can also confirm that I can break to the debugger with CTRL+ALT+ESC before starting X. The world was build without debug symbols. Because the machine runs with an Intel card, I had to use my $work dockstation to obtain a serial port and do the debug via serial port with another machine. When starting X, either the machine freezes hard (and so no CTRL+ALT+ESC) or the machine panics. It has never executed X without panics or freezes. I was able to obtain a core dump, the results are at: https://dl.dropboxusercontent.com/u/2094962/core.txt.4 I was unable to dive any further because the dump only shows the kernel side of things. The bt only seems to show the kernel side and the user side of things seems to be corrupt. Any other info I can obtain from the machine in the moment of the panic, let me know. I can easy do the debug via serial port. Gus -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Wed Jul 17 20:45:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 91660BA8 for ; Wed, 17 Jul 2013 20:45:50 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 26BB1A82 for ; Wed, 17 Jul 2013 20:45:49 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id r6HIxswY008017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 Jul 2013 20:59:54 +0200 Received: from [192.168.1.110] (48.Red-83-60-209.dynamicIP.rima-tde.net [83.60.209.48]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6HIxqv2003230 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 17 Jul 2013 20:59:53 +0200 Message-ID: <51E6E9A8.50904@entel.upc.edu> Date: Wed, 17 Jul 2013 20:59:52 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD current Subject: Panic when starting X with Intel KMS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Wed, 17 Jul 2013 20:59:54 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 20:45:50 -0000 Hi, I'm having panics or hard freezes when starting X with an Intel video card. The machine is able to start old X+twm without problems but when I try gnome3 (in normal or fallback mode, doesn't matter) the machine panics or hard freezes. This doesn't happen when running X with vesa. With vesa the gnome is able to start in debug mode. Also, an old i386 with an nvidia card is able to run that gnome3 with composition so I'd say it has to do with the intel card. These are the specs of the machine: FreeBSD 10.0-CURRENT #4 r+3dc57aa: Wed Jul 17 15:13:07 CEST 2013 root@portgus:/usr/obj/usr/src/sys/CUSTOM amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 RAM: 8GB Video Card: Intel chipid=0x00468086 The debugging knobs in the kernel config are there. I can also confirm that I can break to the debugger with CTRL+ALT+ESC before starting X. The world was build without debug symbols. Because the machine runs with an Intel card, I had to use my $work dockstation to obtain a serial port and do the debug via serial port. When starting X, either the machine freezes hard (and so no CTRL+ALT+ESC) or the machine panics. It has never executed X without panics or freezes. I was able to obtain a core dump, the results are at: https://dl.dropboxusercontent.com/u/2094962/core.txt.4 I was unable to dive further because the dump only shows the kernel side of things. The bt only seems to show the kernel side an the user side of things seems to be corrupt. Any other info I can provide, let me know. I can easy do the debug via serial port. Gus -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 00:50:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18CC5553; Thu, 18 Jul 2013 00:50:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C256B869; Thu, 18 Jul 2013 00:50:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6I0obU6041225; Wed, 17 Jul 2013 20:50:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6I0obQA041224; Thu, 18 Jul 2013 00:50:37 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 18 Jul 2013 00:50:37 GMT Message-Id: <201307180050.r6I0obQA041224@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 00:50:44 -0000 TB --- 2013-07-17 23:43:10 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-17 23:43:10 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-17 23:43:10 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-07-17 23:43:10 - cleaning the object tree TB --- 2013-07-17 23:43:10 - /usr/local/bin/svn stat /src TB --- 2013-07-17 23:43:14 - At svn revision 253432 TB --- 2013-07-17 23:43:15 - building world TB --- 2013-07-17 23:43:15 - CROSS_BUILD_TESTING=YES TB --- 2013-07-17 23:43:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-17 23:43:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-17 23:43:15 - SRCCONF=/dev/null TB --- 2013-07-17 23:43:15 - TARGET=ia64 TB --- 2013-07-17 23:43:15 - TARGET_ARCH=ia64 TB --- 2013-07-17 23:43:15 - TZ=UTC TB --- 2013-07-17 23:43:15 - __MAKE_CONF=/dev/null TB --- 2013-07-17 23:43:15 - cd /src TB --- 2013-07-17 23:43:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jul 17 23:43:22 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] LC_ALL=C awk '!/^#|^$/ { printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", toupper($1), ++L, $1, toupper($1); }' < /src/sbin/route/keywords > keywords.h || (rm -f keywords.h; false) rm -f .depend CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/ia64.ia64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/route/route.c cc1: warnings being treated as errors /src/sbin/route/route.c: In function 'rtmsg': /src/sbin/route/route.c:1491: warning: the address of 'so' will always evaluate as 'true' *** Error code 1 Stop. make: stopped in /src/sbin/route *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-18 00:50:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-18 00:50:37 - ERROR: failed to build world TB --- 2013-07-18 00:50:37 - 3190.01 user 612.41 system 4046.74 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 16 03:59:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D90CFA2E; Tue, 16 Jul 2013 03:59:07 +0000 (UTC) (envelope-from miwi@bsdhash.org) Received: from bsdhash.org (bsdhash.org [94.23.250.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0F2A0CA1; Tue, 16 Jul 2013 03:59:01 +0000 (UTC) Received: from [192.168.2.4] (unknown [211.24.100.75]) by bsdhash.org (Postfix) with ESMTPA id 2010F51106; Tue, 16 Jul 2013 11:58:57 +0800 (MYT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: errors building 9-STABLE on recent HEAD From: Martin Wilke In-Reply-To: Date: Tue, 16 Jul 2013 11:58:57 +0800 Message-Id: References: <20130624201149.GB70873@lor.one-eyed-alien.net> <1A835C0A-9A00-49B9-948C-CF69631CA2B7@bsdhash.org> <20130715185218.GB78845@lor.one-eyed-alien.net> To: hiren panchasara X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 18 Jul 2013 01:35:10 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Martin Wilke , wen heping , Brooks Davis , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 03:59:08 -0000 Yea thank you guys, I got it to work now. - Martin On Jul 16, 2013, at 11:42 AM, hiren panchasara = wrote: > On Mon, Jul 15, 2013 at 8:27 PM, wen heping = wrote: >> I build 9-STABLE on head today, while failed many times last month. >=20 > There were some intermittent issues but *recent* stable/9 should build > fine on *recent* head. If not, please report the errors and have sjg@ > look at them. >=20 > Thanks, > Hiren >>=20 >> wen >>=20 >>=20 >> 2013/7/16 Brooks Davis >>=20 >>> After not working for quite some time, I was able to build 9-STABLE = last >>> week. I'm not sure if something changed in the branch or if the new >>> current I'd updated to fixed it. >>>=20 >>> -- Brooks >>>=20 >>> On Sat, Jul 13, 2013 at 11:07:04PM +0800, Martin Wilke wrote: >>>> Hi, >>>>=20 >>>> I see exactly the same error on pointyhat too, did you find any = work >>> around for that? >>>>=20 >>>> On Jun 25, 2013, at 4:11 AM, Brooks Davis = wrote: >>>>=20 >>>>> I recently upgraded my main buildbox from an ancient 9.0-STABLE >>> snapshot >>>>> to head and I've run into an issue building 9-STABLE on it. = Initally >>>>> this was broken by the switch to bmake, but Simon committed a work >>>>> around that and using the fmake port also works around it. Now = I'm >>>>> seeing a strange error in yacc generated code. I say strange = because >>>>> yacc is correctly being bootstrapped so we're using the expected >>> version >>>>> and not the one in HEAD. >>>>>=20 >>>>> Does anyone have any insight into this issue? >>>>>=20 >>>>> cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=3D64 -I. >>> -I/home/bed22/src-9/gnu/usr.bin/binutils/ld >>> -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd >>> -I/home/bed22/obj/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd >>> = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/i= nclude >>> -DTARGET=3D\"x86_64-unknown-freebsd\" = -DDEFAULT_EMULATION=3D\"elf_x86_64_fbsd\" >>> -DSCRIPTDIR=3D\"/usr/libdata\" -DBFD_VERSION_STRING=3D\""2.17.50 = [FreeBSD] >>> 2007-07-03"\" -DBINDIR=3D\"/usr/bin\" -DTARGET_SYSTEM_ROOT=3D\"\" >>> -DTOOLBINDIR=3D\"//usr/bin/libexec\" -D_GNU_SOURCE >>> = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/l= d >>> = -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/b= fd >>> -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k >>> -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >>> -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c ldlex.c >>>>> cc1: warnings being treated as errors >>>>> : In function 'yy_get_next_buffer': >>>>> :3229: warning: passing argument 2 of 'yy_input' from >>>>> incompatible pointer type >>>>> *** [ldlex.o] Error code 1 >>>>>=20 >>>>> Stop in /home/bed22/src-9/gnu/usr.bin/binutils/ld. >>>>> *** [all] Error code 1 >>>>>=20 >>>>> Thanks, >>>>> Brooks >>>>=20 >>>> +-----------------oOO--(_)--OOo-------------------------+ >>>> With best Regards, >>>> Martin Wilke (miwi_(at)_FreeBSD.org) >>>>=20 >>>> Mess with the Best, Die like the Rest >>>>=20 >>>>=20 >>>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 +-----------------oOO--(_)--OOo-------------------------+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 01:38:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8FE8556; Thu, 18 Jul 2013 01:38:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 86E96AE9; Thu, 18 Jul 2013 01:38:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6I1ckDS030339; Wed, 17 Jul 2013 21:38:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6I1ck49030337; Thu, 18 Jul 2013 01:38:46 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 18 Jul 2013 01:38:46 GMT Message-Id: <201307180138.r6I1ck49030337@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:38:48 -0000 TB --- 2013-07-18 00:50:37 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-18 00:50:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-18 00:50:37 - starting HEAD tinderbox run for mips/mips TB --- 2013-07-18 00:50:37 - cleaning the object tree TB --- 2013-07-18 00:50:37 - /usr/local/bin/svn stat /src TB --- 2013-07-18 00:50:45 - At svn revision 253432 TB --- 2013-07-18 00:50:46 - building world TB --- 2013-07-18 00:50:46 - CROSS_BUILD_TESTING=YES TB --- 2013-07-18 00:50:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-18 00:50:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-18 00:50:46 - SRCCONF=/dev/null TB --- 2013-07-18 00:50:46 - TARGET=mips TB --- 2013-07-18 00:50:46 - TARGET_ARCH=mips TB --- 2013-07-18 00:50:46 - TZ=UTC TB --- 2013-07-18 00:50:46 - __MAKE_CONF=/dev/null TB --- 2013-07-18 00:50:46 - cd /src TB --- 2013-07-18 00:50:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 18 00:50:53 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] LC_ALL=C awk '!/^#|^$/ { printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", toupper($1), ++L, $1, toupper($1); }' < /src/sbin/route/keywords > keywords.h || (rm -f keywords.h; false) rm -f .depend CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/mips.mips/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -G0 -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/route/route.c cc1: warnings being treated as errors /src/sbin/route/route.c: In function 'rtmsg': /src/sbin/route/route.c:1491: warning: the address of 'so' will always evaluate as 'true' *** Error code 1 Stop. make: stopped in /src/sbin/route *** Error code 1 Stop. make: stopped in /obj/mips.mips/src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-18 01:38:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-18 01:38:46 - ERROR: failed to build world TB --- 2013-07-18 01:38:46 - 2096.65 user 519.19 system 2889.08 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 02:26:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B77A8E16; Thu, 18 Jul 2013 02:26:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 75A02C59; Thu, 18 Jul 2013 02:26:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6I2QpFQ040977; Wed, 17 Jul 2013 22:26:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6I2Qp4m040964; Thu, 18 Jul 2013 02:26:51 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 18 Jul 2013 02:26:51 GMT Message-Id: <201307180226.r6I2Qp4m040964@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 02:26:56 -0000 TB --- 2013-07-18 01:38:47 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-18 01:38:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-18 01:38:47 - starting HEAD tinderbox run for mips64/mips TB --- 2013-07-18 01:38:47 - cleaning the object tree TB --- 2013-07-18 01:38:47 - /usr/local/bin/svn stat /src TB --- 2013-07-18 01:39:14 - At svn revision 253432 TB --- 2013-07-18 01:39:15 - building world TB --- 2013-07-18 01:39:15 - CROSS_BUILD_TESTING=YES TB --- 2013-07-18 01:39:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-18 01:39:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-18 01:39:15 - SRCCONF=/dev/null TB --- 2013-07-18 01:39:15 - TARGET=mips TB --- 2013-07-18 01:39:15 - TARGET_ARCH=mips64 TB --- 2013-07-18 01:39:15 - TZ=UTC TB --- 2013-07-18 01:39:15 - __MAKE_CONF=/dev/null TB --- 2013-07-18 01:39:15 - cd /src TB --- 2013-07-18 01:39:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 18 01:39:22 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] LC_ALL=C awk '!/^#|^$/ { printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", toupper($1), ++L, $1, toupper($1); }' < /src/sbin/route/keywords > keywords.h || (rm -f keywords.h; false) rm -f .depend CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/mips.mips64/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -G0 -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/route/route.c cc1: warnings being treated as errors /src/sbin/route/route.c: In function 'rtmsg': /src/sbin/route/route.c:1491: warning: the address of 'so' will always evaluate as 'true' *** Error code 1 Stop. make: stopped in /src/sbin/route *** Error code 1 Stop. make: stopped in /obj/mips.mips64/src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-18 02:26:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-18 02:26:51 - ERROR: failed to build world TB --- 2013-07-18 02:26:51 - 2105.06 user 482.70 system 2884.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 03:15:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FC23ABA; Thu, 18 Jul 2013 03:15:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1D47FF75; Thu, 18 Jul 2013 03:15:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6I3Fave004546; Wed, 17 Jul 2013 23:15:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6I3FaGo004545; Thu, 18 Jul 2013 03:15:36 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 18 Jul 2013 03:15:36 GMT Message-Id: <201307180315.r6I3FaGo004545@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 03:15:37 -0000 TB --- 2013-07-18 02:26:51 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-18 02:26:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-18 02:26:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-18 02:26:51 - cleaning the object tree TB --- 2013-07-18 02:26:51 - /usr/local/bin/svn stat /src TB --- 2013-07-18 02:26:55 - At svn revision 253432 TB --- 2013-07-18 02:26:56 - building world TB --- 2013-07-18 02:26:56 - CROSS_BUILD_TESTING=YES TB --- 2013-07-18 02:26:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-18 02:26:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-18 02:26:56 - SRCCONF=/dev/null TB --- 2013-07-18 02:26:56 - TARGET=sparc64 TB --- 2013-07-18 02:26:56 - TARGET_ARCH=sparc64 TB --- 2013-07-18 02:26:56 - TZ=UTC TB --- 2013-07-18 02:26:56 - __MAKE_CONF=/dev/null TB --- 2013-07-18 02:26:56 - cd /src TB --- 2013-07-18 02:26:56 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 18 02:27:03 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] LC_ALL=C awk '!/^#|^$/ { printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", toupper($1), ++L, $1, toupper($1); }' < /src/sbin/route/keywords > keywords.h || (rm -f keywords.h; false) rm -f .depend CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/sparc64.sparc64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/route/route.c cc1: warnings being treated as errors /src/sbin/route/route.c: In function 'rtmsg': /src/sbin/route/route.c:1491: warning: the address of 'so' will always evaluate as 'true' *** Error code 1 Stop. make: stopped in /src/sbin/route *** Error code 1 Stop. make: stopped in /obj/sparc64.sparc64/src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-18 03:15:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-18 03:15:36 - ERROR: failed to build world TB --- 2013-07-18 03:15:36 - 2401.46 user 434.80 system 2924.53 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 04:14:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D98F857; Thu, 18 Jul 2013 04:14:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 396792D4; Thu, 18 Jul 2013 04:14:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6I4EfPA083296; Thu, 18 Jul 2013 00:14:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6I4EfmC083292; Thu, 18 Jul 2013 04:14:41 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 18 Jul 2013 04:14:41 GMT Message-Id: <201307180414.r6I4EfmC083292@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 04:14:42 -0000 TB --- 2013-07-18 02:00:53 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-18 02:00:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-18 02:00:53 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-07-18 02:00:53 - cleaning the object tree TB --- 2013-07-18 02:00:53 - /usr/local/bin/svn stat /src TB --- 2013-07-18 02:01:02 - At svn revision 253432 TB --- 2013-07-18 02:01:03 - building world TB --- 2013-07-18 02:01:03 - CROSS_BUILD_TESTING=YES TB --- 2013-07-18 02:01:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-18 02:01:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-18 02:01:03 - SRCCONF=/dev/null TB --- 2013-07-18 02:01:03 - TARGET=powerpc TB --- 2013-07-18 02:01:03 - TARGET_ARCH=powerpc TB --- 2013-07-18 02:01:03 - TZ=UTC TB --- 2013-07-18 02:01:03 - __MAKE_CONF=/dev/null TB --- 2013-07-18 02:01:03 - cd /src TB --- 2013-07-18 02:01:03 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 18 02:01:11 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] LC_ALL=C awk '!/^#|^$/ { printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", toupper($1), ++L, $1, toupper($1); }' < /src/sbin/route/keywords > keywords.h || (rm -f keywords.h; false) rm -f .depend CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/powerpc.powerpc/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/route/route.c cc1: warnings being treated as errors /src/sbin/route/route.c: In function 'rtmsg': /src/sbin/route/route.c:1491: warning: the address of 'so' will always evaluate as 'true' *** Error code 1 Stop. make: stopped in /src/sbin/route *** Error code 1 Stop. make: stopped in /obj/powerpc.powerpc/src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-18 04:14:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-18 04:14:41 - ERROR: failed to build world TB --- 2013-07-18 04:14:41 - 7074.83 user 806.41 system 8027.67 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 04:17:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1953899E; Thu, 18 Jul 2013 04:17:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CAB8C2ED; Thu, 18 Jul 2013 04:17:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6I4HGQT087622; Thu, 18 Jul 2013 00:17:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6I4HGZx087621; Thu, 18 Jul 2013 04:17:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 18 Jul 2013 04:17:16 GMT Message-Id: <201307180417.r6I4HGZx087621@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 04:17:17 -0000 TB --- 2013-07-18 02:03:56 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-18 02:03:56 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-18 02:03:56 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-07-18 02:03:56 - cleaning the object tree TB --- 2013-07-18 02:03:56 - /usr/local/bin/svn stat /src TB --- 2013-07-18 02:03:59 - At svn revision 253432 TB --- 2013-07-18 02:04:00 - building world TB --- 2013-07-18 02:04:00 - CROSS_BUILD_TESTING=YES TB --- 2013-07-18 02:04:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-18 02:04:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-18 02:04:00 - SRCCONF=/dev/null TB --- 2013-07-18 02:04:00 - TARGET=powerpc TB --- 2013-07-18 02:04:00 - TARGET_ARCH=powerpc64 TB --- 2013-07-18 02:04:00 - TZ=UTC TB --- 2013-07-18 02:04:00 - __MAKE_CONF=/dev/null TB --- 2013-07-18 02:04:00 - cd /src TB --- 2013-07-18 02:04:00 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 18 02:04:07 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] LC_ALL=C awk '!/^#|^$/ { printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", toupper($1), ++L, $1, toupper($1); }' < /src/sbin/route/keywords > keywords.h || (rm -f keywords.h; false) rm -f .depend CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/powerpc.powerpc64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/route/route.c cc1: warnings being treated as errors /src/sbin/route/route.c: In function 'rtmsg': /src/sbin/route/route.c:1491: warning: the address of 'so' will always evaluate as 'true' *** Error code 1 Stop. make: stopped in /src/sbin/route *** Error code 1 Stop. make: stopped in /obj/powerpc.powerpc64/src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue/rescue *** Error code 1 Stop. make: stopped in /src/rescue *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-18 04:17:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-18 04:17:16 - ERROR: failed to build world TB --- 2013-07-18 04:17:16 - 7126.42 user 816.09 system 7999.89 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 09:00:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E3890E46 for ; Thu, 18 Jul 2013 09:00:30 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC3EFB7 for ; Thu, 18 Jul 2013 09:00:30 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id j14so1553976eak.36 for ; Thu, 18 Jul 2013 02:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=H8En/l+FniryLLqwaBQ/mTu/4J/5B8OTXn+e6Em9Wb0=; b=fEOuG3C2WVVjTC0sq/7LbUGk5YTM5QxNielxKn4juSWDMlEA1UQCfN96r6Qbxzpf2b X0fevak9HWmDkYvVrmVA6qHiErhldmUpWt4ZJEBUwi4BuvEQ69oNdWmmrNs7e5Gd8Nj4 ECaZiw1pAYgY262ulyKs7asyUcJ3FRz4bloGIOZfBc6K9AqQaRY9ENQtkuWlSyJEbLei +Z3/MPGF7aR5gOSlZGkZ1WH566YK0GFfRkb8i2jMzWkzQvjt3EmnOrjBPOeWJVsU91lb OQL7IHV3Qys/qAKNZVvEHBmWGDxVUskVYo2CCDr6xfrgQ0N41YgeywKRIfS1Ovt9hDUA Ig3Q== X-Received: by 10.14.224.201 with SMTP id x49mr10129393eep.6.1374138029508; Thu, 18 Jul 2013 02:00:29 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPSA id a4sm17671210eez.0.2013.07.18.02.00.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Jul 2013 02:00:28 -0700 (PDT) Date: Thu, 18 Jul 2013 12:00:26 +0300 From: Mikolaj Golub To: freebsd-current@FreeBSD.org Subject: Re: core.txt.N not created anymore on panic Message-ID: <20130718090025.GA27874@gmail.com> References: <20130717071655.GE4484@caravan.chchile.org> <20130717072151.GF4484@caravan.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130717072151.GF4484@caravan.chchile.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 09:00:31 -0000 On Wed, Jul 17, 2013 at 09:21:51AM +0200, Jeremie Le Hen wrote: > On Wed, Jul 17, 2013 at 09:16:55AM +0200, Jeremie Le Hen wrote: > > Hi, > > > > Early May I set ddb_enable="YES" (crashinfo_enable="YES" by default). > > Upon panic, it created the following kind of files: > > > > -rw------- 1 root wheel 549 Jun 26 22:09 info.0 > > -rw------- 1 root wheel 1518501888 Jun 26 22:09 vmcore.0 > > -rw------- 1 root wheel 196981 Jun 26 22:09 core.txt.0 > > -rw------- 1 root wheel 546 Jun 26 23:15 info.1 > > -rw------- 1 root wheel 472608768 Jun 26 23:15 vmcore.1 > > -rw------- 1 root wheel 207034 Jun 26 23:15 core.txt.1 > > -rw------- 1 root wheel 546 Jun 27 00:47 info.2 > > -rw------- 1 root wheel 667717632 Jun 27 00:47 vmcore.2 > > -rw------- 1 root wheel 208745 Jun 27 00:48 core.txt.2 > > -rw------- 1 root wheel 549 Jul 3 14:40 info.3 > > -rw------- 1 root wheel 1455198208 Jul 3 14:40 vmcore.3 > > -rw------- 1 root wheel 208173 Jul 3 14:41 core.txt.3 > > > > The core.txt.N files contained crashinfo(8) informations along with > > ddb textdump, because crashinfo(8) outputs dmesg. > > > > > > Yesterday, I upgraded to latest -CURRENT from one from June 9th. While > > stress-testing overnight, I got a couple of panics but core.txt.N are > > not created anymore. > > > > -rw------- 1 root wheel 530 Jul 17 01:10 info.5 > > -rw------- 1 root wheel 75776 Jul 17 01:10 textdump.tar.5 > > -rw------- 1 root wheel 529 Jul 17 02:01 info.6 > > -rw------- 1 root wheel 74240 Jul 17 02:01 textdump.tar.6 > > -rw------- 1 root wheel 530 Jul 17 04:20 info.7 > > -rw------- 1 root wheel 74752 Jul 17 04:20 textdump.tar.7 > > -rw------- 1 root wheel 530 Jul 17 07:50 info.8 > > -rw------- 1 root wheel 92672 Jul 17 07:50 textdump.tar.8 > > -rw------- 1 root wheel 531 Jul 17 08:44 info.9 > > -rw------- 1 root wheel 110592 Jul 17 08:44 textdump.tar.9 > > > > Each textdump.tar.N contains: > > > > tar tvf /var/crash/textdump.tar.9 > > -rw------- 0 root wheel 49152 Jul 17 08:30 ddb.txt > > -rw------- 0 root wheel 3179 Jul 17 08:30 config.txt > > -rw------- 0 root wheel 54137 Jul 17 08:30 msgbuf.txt > > -rw------- 0 root wheel 88 Jul 17 08:30 panic.txt > > -rw------- 0 root wheel 120 Jul 17 08:30 version.txt > > > > Any idea changed in between? I checked svn log in etc/ but I found > > nothing relevant. Before your system was configured to generate vmcore dumps. Now it is configured to generate textdumps. crashinfo(8) works with vmcore. > > For the record: > > debug.ddb.capture.bufoff: 0 > debug.ddb.capture.maxbufsize: 5242880 > debug.ddb.capture.inprogress: 0 > debug.ddb.capture.bufsize: 49152 > debug.ddb.capture.data: > debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show > lockedvnods > kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; 'textdump set' tells ddb to store dumps in textdump format. Remove this from /etc/ddb.conf (and run /etc/rc.d/ddb) if you want crashinfo(8) data. -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 18:15:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FB501EF; Thu, 18 Jul 2013 18:15:26 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 855B5E43; Thu, 18 Jul 2013 18:15:25 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id j13so3251272wgh.24 for ; Thu, 18 Jul 2013 11:15:24 -0700 (PDT) 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=P2IcmhbE2UpTzRYy+R//RAasATE2Ma2M5mFYBiFER5g=; b=aKIIYKf0Y7sNNHB4Vm9/VJUgaZE2Gvvne1LIzhnLEGuOdVfJm88s+issyEezv1GDEh M9OwKq1Gmnl7RMeoFwypTTu6GwLNb3PSE3fK3YefcOl3VXRyM5W/PhMp7MwXjkfA/+Xj 2aHdBiGCv9/cYrWBNobxfd/88W/RN/nQ8ZD7jbISYamvvLsiYiF1J1c6EivNT46ULQTn rvC2kH5MjRxOC1S/bKjr+YZ+tIF8G+bUmkF8TJqu7i246eewXPb/B/q0PgF9i9e39IJL vR022rvf28Hh6JbYehy/Xb0XvastH6blP20rK1gfo6YaHjwANk+9X1Rvb7Htry+rgbAu 2gWA== MIME-Version: 1.0 X-Received: by 10.194.1.226 with SMTP id 2mr9520775wjp.91.1374171324671; Thu, 18 Jul 2013 11:15:24 -0700 (PDT) Received: by 10.194.240.132 with HTTP; Thu, 18 Jul 2013 11:15:24 -0700 (PDT) Date: Thu, 18 Jul 2013 22:15:24 +0400 Message-ID: Subject: RaspberryPi (ARMv6) after update EABI not build perl From: Andrey Fesenko To: "freebsd-arm@freebsd.org" , ports@freebsd.org, freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 18:15:26 -0000 Hi, anyone succeeded build perl for eabi? my rpi make results in an error equally for all perl version # define PERL_FPU_INIT (void)fpsetmask(0) ^ 1 warning generated. LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 cc -pthread -Wl,-E -fstack-protector -L/usr/local/lib -o miniperl gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o miniperlmain.o opmini.o perlmini.o -lm -lcrypt -lutil LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 ./miniperl -w -Ilib -MExporter -e '' || /usr/bin/make minitest longjmp botch. Abort trap (core dumped) LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 ./miniperl -Ilib make_patchnum.pl Updating 'git_version.h' and 'lib/Config_git.pl' longjmp botch. *** Signal 6 Stop. make: stopped in /usr/ports/lang/perl5.14/work/perl-5.14.4 *** Error code 1 (ignored) You may see some irrelevant test failures if you have been unable to build lib/Config.pm, or the Unicode data files. cd t && (rm -f perl; /bin/ln -s ../miniperl perl) && LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 ./perl TEST base/*.t comp/*.t cmd/*.t run/*.t io/*.t re/*.t op/*.t uni/*.t >> make failed for lang/perl5.14 ===>>> Aborting update ===>>> Killing background jobs Terminated ===>>> You can restart from the point of failure with this command line: portmaster lang/perl5.14 ===>>> Exiting From owner-freebsd-current@FreeBSD.ORG Thu Jul 18 18:19:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9577754C; Thu, 18 Jul 2013 18:19:13 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id D7370E90; Thu, 18 Jul 2013 18:19:12 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id w56so3198146wes.39 for ; Thu, 18 Jul 2013 11:19:12 -0700 (PDT) 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 :content-type; bh=Di1H+ayjvnxDEhXSslso7LrmTG9xHz+dwJybjPwrxKM=; b=lTxyQ7lfFRK6+uPRis7W+fQV7pilYuNc9VzZ+XVt8+TZZWyYbspdVABozG7a6JebsK rdYP2K8+7UhNkEAL2Kk3YqAyzYSbk9yaRc9MijPJkIGcu1vDNP+5VWHVIOgHxmw6YVKC 22x8llu1NT3GoDue4bUjxaJMoGKyXOOnob+YCLdYLVMcmawQYjBxRhm1nYOGqTqzL3HF k/uTuwGWgF3gaGEJcvmG3wPMU7XDOJnp56Sy3VX5yw7ILve//SloIjFguahrccYSaj3N aOwwPyKNj0g5QNtSs4QdrD7x6ESSgPFsSe1ed+XmnbFRA72yvz79xFsxlu3MJKu2+/51 ExWg== MIME-Version: 1.0 X-Received: by 10.194.1.226 with SMTP id 2mr9532455wjp.91.1374171551995; Thu, 18 Jul 2013 11:19:11 -0700 (PDT) Received: by 10.194.240.132 with HTTP; Thu, 18 Jul 2013 11:19:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jul 2013 22:19:11 +0400 Message-ID: Subject: Re: RaspberryPi (ARMv6) after update EABI not build perl From: Andrey Fesenko To: "freebsd-arm@freebsd.org" , ports@freebsd.org, freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 18:19:13 -0000 Sory, # uname -a FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253414M: Wed Jul 17 16:12:39 MSK 2013 andrey@my_book.local:/home/andrey/obj/arm.armv6/usr/src/sys/RPI-B-IPv6 arm system compile clang On Thu, Jul 18, 2013 at 10:15 PM, Andrey Fesenko wrote: > Hi, anyone succeeded build perl for eabi? my rpi make results in an > error equally for all perl version > > # define PERL_FPU_INIT (void)fpsetmask(0) > ^ > 1 warning generated. > LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 cc -pthread > -Wl,-E -fstack-protector -L/usr/local/lib -o miniperl gv.o toke.o > perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o keywords.o > hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o > doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o > perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o > miniperlmain.o opmini.o perlmini.o -lm -lcrypt -lutil > LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 ./miniperl > -w -Ilib -MExporter -e '' || /usr/bin/make minitest > longjmp botch. > Abort trap (core dumped) > LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 ./miniperl > -Ilib make_patchnum.pl > Updating 'git_version.h' and 'lib/Config_git.pl' > longjmp botch. > *** Signal 6 > > Stop. > make: stopped in /usr/ports/lang/perl5.14/work/perl-5.14.4 > *** Error code 1 (ignored) > > You may see some irrelevant test failures if you have been unable > to build lib/Config.pm, or the Unicode data files. > > cd t && (rm -f perl; /bin/ln -s ../miniperl perl) && > LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 ./perl TEST > base/*.t comp/*.t cmd/*.t run/*.t io/*.t re/*.t op/*.t uni/*.t > t/base/cond.....................longjmp botch. > FAILED--no leader found > Failed a basic test (base/cond.t) -- cannot continue. > longjmp botch. > *** Signal 6 (ignored) > /bin/ln -s perldelta.pod pod/perl5144delta.pod > LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4 ./miniperl > -Ilib autodoc.pl > longjmp botch. > *** Signal 6 > > Stop. > make: stopped in /usr/ports/lang/perl5.14/work/perl-5.14.4 > *** Error code 1 > > Stop. > make: stopped in /usr/ports/lang/perl5.14 > *** Error code 1 > > Stop. > make: stopped in /usr/ports/lang/perl5.14 > > ===>>> make failed for lang/perl5.14 > ===>>> Aborting update > > ===>>> Killing background jobs > Terminated > > ===>>> You can restart from the point of failure with this command line: > portmaster lang/perl5.14 > > ===>>> Exiting From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 05:29:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED5831E6 for ; Fri, 19 Jul 2013 05:29:32 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id 85837FB1 for ; Fri, 19 Jul 2013 05:29:32 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id c41so2151324eek.12 for ; Thu, 18 Jul 2013 22:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ccCg7w48an4ZoaquWFWHLreNe56BIP+A/Vpc0JjAvbg=; b=Yo5IHV9d0ayERgc5+hzDWOq25RQOXktgmnvFDmdvtk7rFKiFYFTHBPLEuGvyTtMC1J qmrniQDDAHdVMIHJsqY51kpPKHA0yG9o3SpjnuoJLF1vuXQg6bXWNHc2xVVi19hFZvgS Iu0Ai5UIULuIo1lDbe1aANLzx5mvlNUFZyd9dVmQIea3hYZYVma9Zr/upkcU/c1AK82D wDgakU/hPJq4HId5pE0NR/RtFUalPCEzz8szinA/LU2o5x39bHo7nk9CCj4k40JPSCdc dx/6M4OWg30Yy+C7rULUwBQm5EvyBdkTvv8mTDs+9ZcFmW9w/N2Jez8SThgY2/NxfsCP Ofew== X-Received: by 10.15.10.132 with SMTP id g4mr14045359eet.38.1374211771584; Thu, 18 Jul 2013 22:29:31 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.187.173]) by mx.google.com with ESMTPSA id i2sm24540335eeu.4.2013.07.18.22.29.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 22:29:30 -0700 (PDT) Message-ID: <51E8CEB6.3020900@gmail.com> Date: Fri, 19 Jul 2013 08:29:26 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130519 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: FUSE not work. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 05:29:33 -0000 There is a problem after mount NTFS, fuse not work. uname -a FreeBSD scorpion.kiev.ua 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Thu Jul 18 22:23:54 EEST 2013 root@scorpion.kiev.ua:/usr/obj/usr/src/sys/Kernel amd64 kldstat | grep fuse 16 1 0xffffffff81e26000 8b3f fuse.ko ntfs-3g -o debug /dev/ada0s1 /mnt/ntfs_0 FUSE library version: 2.9.2 nullpath_ok: 0 nopath: 0 utime_omit_ok: 0 Version 2012.1.15 external FUSE 29 Mounted /dev/ada0s1 (Read-Write, label "Install", NTFS 3.1) Cmdline options: debug Mount options: allow_other,nonempty,relatime,fsname=/dev/ada0s1 Ownership and permissions disabled, configuration type 1 unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 2092 INIT: 7.8 flags=0x00000000 max_readahead=0x00010000 INIT: 7.19 flags=0x00000050 max_readahead=0x00010000 max_write=0x00020000 max_background=0 congestion_threshold=0 ls -la /mnt/ntfs_0 unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 2096 getattr / unique: 2, success, outsize: 112 ls: /mnt/ntfs_0: Input/output error fuse: writing device: Invalid argument unique: 1, success, outsize: 40 ls -la /mnt unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 2097 getattr / unique: 3, success, outsize: 112 fuse: writing device: Invalid argument ls: ntfs_0: Input/output error From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 09:40:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 78976811 for ; Fri, 19 Jul 2013 09:40:13 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 48273CC5 for ; Fri, 19 Jul 2013 09:40:13 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id D97318B32 for ; Fri, 19 Jul 2013 11:40:11 +0200 (CEST) Message-ID: <51E90975.9030407@peterschmitt.fr> Date: Fri, 19 Jul 2013 11:40:05 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FUSE not work. References: <51E8CEB6.3020900@gmail.com> In-Reply-To: <51E8CEB6.3020900@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 09:40:13 -0000 Le 19/07/2013 07:29, Alexander Panyushkin a écrit : > There is a problem after mount NTFS, fuse not work. […] > fuse: writing device: Invalid argument > ls: ntfs_0: Input/output error Have you rebuild the fusefs-kmod port and then reloaded the kernel module ? I had a crash if I didn't so on 9-STABLE. From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 12:00:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFBA456D for ; Fri, 19 Jul 2013 12:00:08 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 8B179350 for ; Fri, 19 Jul 2013 12:00:08 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id l18so3830695wgh.26 for ; Fri, 19 Jul 2013 05:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=S0pqQbJD9w1LPno8gKQIrWk6QR+U7DNvuQV4hlpDLiY=; b=IQwMQNbkFrQJX9sKO1cNdJucaqctaKM+BopmWua1bqYNJREYXEOOMyUgc77b1aAsgd MJKh1KgB3yT4L/8kx5R9OIS8Ce54azmvfwrXjNyUvAR1BngnO0rEgP5z2VDwFg+whJGa 5Ks6kuo1aGRuIV6i/7v5ISyLd8QbLzGRlTS+J0JZZ2EDT8hhrZAyKmHJf4rdeJsSdzI8 tHqT/hbfV9/kase517cmbcnwHyzMQFK0q58+omfiC+NnKJ5tKvuaRwKmAXI16+UtQMUs 5f19lKUqRRgsmSTEQBeEQqTeEyDq2mvCM6h1q5R8K+W/gbrgq04yEDAxNnpZk+yMX9jD oY1A== X-Received: by 10.180.39.212 with SMTP id r20mr11317643wik.30.1374235207772; Fri, 19 Jul 2013 05:00:07 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.187.173]) by mx.google.com with ESMTPSA id u9sm22591506wif.6.2013.07.19.05.00.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 05:00:06 -0700 (PDT) Message-ID: <51E92A43.7050202@gmail.com> Date: Fri, 19 Jul 2013 15:00:03 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130519 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FUSE not work. References: <51E8CEB6.3020900@gmail.com> <51E90975.9030407@peterschmitt.fr> In-Reply-To: <51E90975.9030407@peterschmitt.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 12:00:09 -0000 19.07.2013 12:40, Florent Peterschmitt пишет: > Have you rebuild the fusefs-kmod port and then reloaded the kernel > module ? I had a crash if I didn't so on 9-STABLE. In FreeBSD 10 fusefs-kmod port doesn't need to be installed anymore for -CURRENT setups. http://svnweb.freebsd.org/base?view=revision&revision=241519 From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 14:38:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 43473CC0 for ; Fri, 19 Jul 2013 14:38:48 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm29-vm6.bullet.mail.ne1.yahoo.com (nm29-vm6.bullet.mail.ne1.yahoo.com [98.138.91.122]) by mx1.freebsd.org (Postfix) with ESMTP id 105E6D9D for ; Fri, 19 Jul 2013 14:38:47 +0000 (UTC) Received: from [98.138.90.50] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2013 14:37:00 -0000 Received: from [98.138.84.42] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2013 14:37:00 -0000 Received: from [127.0.0.1] by smtp110.mail.ne1.yahoo.com with NNFMP; 19 Jul 2013 14:37:00 -0000 X-Yahoo-Newman-Id: 128909.57004.bm@smtp110.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LQnistEVM1nBiTarpk7c0cu7SV0Tl1s0PaMR0JV9vNaDb01 sM1xV2Vl3FmfOIJOgoQGi1Bo7.EGrHK7yukR0pEJbPYlykGI4i8zNU04OcBZ eLTwxO8LmS7gVdGfLc5kc7K97qD2BchsfAB.Sr4I_prniuHflhOP61uD0j8B FTaIc1eYXKCUp6ReqeCSf.7oGW3pTZVlke3r.iqLQ_WuLlkafTdsQsYKg0dX 5_kLAHQIsVUsr4ZznSWkTxVXyu0SxtxcLoc14YS7hiPDfBCmHWcOOWMKF5eU 8wjwltvlAQy1PX0lCI0EarBFgfv2hmt5cH.LDSS6qjrBSXTublTmHwhNDT0C 7s.DADZGcFaAxg6wUTagGGWudyO1Egg4rvsuSwvuKmkW78wid2gWmdx3BaXg e2l0RlnZrY5Q4kfI0UDcE5JRQEvVg9gkPSc7yxn6gEVwhg6rsHrbVPsOYhXT 6N4L8sumPfZ0Ns6Rh9Pf2Exu7X2lflDYsSX5Zq_6Ixl5w49ZpL4LzCOLv86b xWoTVnDRG0ABcs6fmjozd2nQu3r1SZFyvKs6lrwh0FBM0 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp110.mail.ne1.yahoo.com with SMTP; 19 Jul 2013 07:36:59 -0700 PDT Message-ID: <51E94F09.4020109@FreeBSD.org> Date: Fri, 19 Jul 2013 09:36:57 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: FUSE not work. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Panyushkin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 14:38:48 -0000 Hello; The internal data structures in the FUSE kernel module have been updated to be more compatible with MacFUSE and the linux FUSE. This basically measn you have to rebuild your fuse modules (including NTFS). We should not really update the FUSE_KERNEL_MINOR_VERSION yet. I will add a note to UPDATING. Pedro. From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 15:29:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09132EF7; Fri, 19 Jul 2013 15:29:24 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1A5FCD; Fri, 19 Jul 2013 15:29:23 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id c13so2479015eek.31 for ; Fri, 19 Jul 2013 08:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Z2vHVYAX+PMFpdg9wurBgMbkD2b1va4OBGMGtEDT4VA=; b=oi1HpA2LovgNfNym0WncwKmgwl5toveJkylxM5DyS2qoFLkn7U9/H33NPjNNHssfWk btYO1Zmh+A1AsQvsVrD8GbwCL4L5CI7eZBXYEk7WixwKZPxqV9DewKpdFf89QTWxQ7M1 F7UADpl/Rt//HXGzaXeKunuZrwO+piAw5WJDm1qj2RZTdYRixZQ/atReY+34w1WII6kq 647wbTwnXmyFGlkca1eEGGyCcYTycUQbCXmr41R4VsjnnNswxHarQnjRZAAwAKWJUF4N K+MMSx7f0gldxk6q9CINx5Q+Eadx7yWboVwfYjRTs1hts+Cb0X00Dddy4PFCwTfKsXq2 x+mw== X-Received: by 10.15.67.140 with SMTP id u12mr16382609eex.90.1374247762529; Fri, 19 Jul 2013 08:29:22 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.187.173]) by mx.google.com with ESMTPSA id b7sm28165248eef.16.2013.07.19.08.29.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 08:29:21 -0700 (PDT) Message-ID: <51E95B4D.4030104@gmail.com> Date: Fri, 19 Jul 2013 18:29:17 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130519 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pedro Giffuni Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> In-Reply-To: <51E94F09.4020109@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 15:29:24 -0000 19.07.2013 17:36, Pedro Giffuni пишет: > Hello; > > The internal data structures in the FUSE kernel module have been > updated to be more compatible with MacFUSE and the linux FUSE. > > This basically measn you have to rebuild your fuse modules > (including NTFS). > > We should not really update the FUSE_KERNEL_MINOR_VERSION yet. > I will add a note to UPDATING. > > Pedro. Unfortunately the port is not build in FreeBSD 10 ===>>> Starting build for sysutils/fusefs-kmod <<<=== ===>>> All dependencies are up to date ===> Cleaning for fusefs-kmod-0.3.9.p1.20080208_11 ===> Found saved configuration for fusefs-kmod-0.3.9.p1.20080208_11 ===> Fetching all distfiles required by fusefs-kmod-0.3.9.p1.20080208_11 for building ===> Extracting for fusefs-kmod-0.3.9.p1.20080208_11 => SHA256 Checksum OK for fuse4bsd/498acaef33b0.tar.gz. ===> Patching for fusefs-kmod-0.3.9.p1.20080208_11 ===> Applying extra patch /usr/ports/sysutils/fusefs-kmod/files/extra-patch-fuse_module__fuse_vnops.c ===> Applying extra patch /usr/ports/sysutils/fusefs-kmod/files/extrapatch-fuse_module__fuse_vnops.c ===> Applying FreeBSD patches for fusefs-kmod-0.3.9.p1.20080208_11 ===> fusefs-kmod-0.3.9.p1.20080208_11 depends on package: fusefs-libs>2.4.1 - found ===> fusefs-kmod-0.3.9.p1.20080208_11 depends on executable: deplate - found ===> Configuring for fusefs-kmod-0.3.9.p1.20080208_11 ===> Building for fusefs-kmod-0.3.9.p1.20080208_11 ===> fuse_module (all) Warning: Object directory not changed from original /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include x86 -> /usr/src/sys/x86/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_main.c cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_msg.c cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_dev.c cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vfsops.c cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vnops.c In file included from fuse_vnops.c:36: @/vm/vm_pager.h:126:2: warning: implicit declaration of function 'rw_assert' is invalid in C99 [-Wimplicit-function-declaration] VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:226:2: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:126:2: error: use of undeclared identifier 'RA_WLOCKED' @/vm/vm_object.h:226:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:143:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:226:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:167:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:226:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:190:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(m->object); ^ @/vm/vm_object.h:226:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ fuse_vnops.c:3397:3: warning: implicit declaration of function 'VM_OBJECT_LOCK' is invalid in C99 [-Wimplicit-function-declaration] VM_OBJECT_LOCK(vp->v_object); ^ fuse_vnops.c:3398:3: warning: implicit declaration of function 'vm_page_lock_queues' is invalid in C99 [-Wimplicit-function-declaration] vm_page_lock_queues(); ^ fuse_vnops.c:3406:4: warning: implicit declaration of function 'vm_page_unlock_queues' is invalid in C99 [-Wimplicit-function-declaration] vm_page_unlock_queues(); ^ fuse_vnops.c:3407:4: warning: implicit declaration of function 'VM_OBJECT_UNLOCK' is invalid in C99 [-Wimplicit-function-declaration] VM_OBJECT_UNLOCK(vp->v_object); ^ 5 warnings and 4 errors generated. *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0 *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/fusefs-kmod *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/fusefs-kmod ===>>> make failed for sysutils/fusefs-kmod ===>>> Aborting update ===>>> Killing background jobs Terminated Terminated ===>>> You can restart from the point of failure with this command line: portmaster sysutils/fusefs-kmod ===>>> Exiting From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 16:33:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C47A4B5; Fri, 19 Jul 2013 16:33:53 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) by mx1.freebsd.org (Postfix) with ESMTP id 57B3D346; Fri, 19 Jul 2013 16:33:53 +0000 (UTC) Received: from [10.1.3.5] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 3CF1819E091; Fri, 19 Jul 2013 16:24:56 +0000 (UTC) Message-ID: <51E96856.20001@mail.lifanov.com> Date: Fri, 19 Jul 2013 12:24:54 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexander Panyushkin Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> In-Reply-To: <51E95B4D.4030104@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Pedro Giffuni , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 16:33:53 -0000 On 07/19/13 11:29, Alexander Panyushkin wrote: > 19.07.2013 17:36, Pedro Giffuni пишет: >> Hello; >> >> The internal data structures in the FUSE kernel module have been >> updated to be more compatible with MacFUSE and the linux FUSE. >> >> This basically measn you have to rebuild your fuse modules >> (including NTFS). >> >> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. >> I will add a note to UPDATING. >> >> Pedro. > > > > Unfortunately the port is not build in FreeBSD 10 > > > ===>>> Starting build for sysutils/fusefs-kmod <<<=== > > ===>>> All dependencies are up to date > > ===> Cleaning for fusefs-kmod-0.3.9.p1.20080208_11 > ===> Found saved configuration for fusefs-kmod-0.3.9.p1.20080208_11 > ===> Fetching all distfiles required by fusefs-kmod-0.3.9.p1.20080208_11 > for building > ===> Extracting for fusefs-kmod-0.3.9.p1.20080208_11 > => SHA256 Checksum OK for fuse4bsd/498acaef33b0.tar.gz. > ===> Patching for fusefs-kmod-0.3.9.p1.20080208_11 > ===> Applying extra patch > /usr/ports/sysutils/fusefs-kmod/files/extra-patch-fuse_module__fuse_vnops.c > ===> Applying extra patch > /usr/ports/sysutils/fusefs-kmod/files/extrapatch-fuse_module__fuse_vnops.c > ===> Applying FreeBSD patches for fusefs-kmod-0.3.9.p1.20080208_11 > ===> fusefs-kmod-0.3.9.p1.20080208_11 depends on package: > fusefs-libs>2.4.1 - found > ===> fusefs-kmod-0.3.9.p1.20080208_11 depends on executable: deplate - > found > ===> Configuring for fusefs-kmod-0.3.9.p1.20080208_11 > ===> Building for fusefs-kmod-0.3.9.p1.20080208_11 > ===> fuse_module (all) > Warning: Object directory not changed from original > /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module > @ -> /usr/src/sys > machine -> /usr/src/sys/amd64/include > x86 -> /usr/src/sys/x86/include > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq > -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-error-tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_main.c > cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq > -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-error-tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_msg.c > cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq > -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-error-tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_dev.c > cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq > -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-error-tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vfsops.c > cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq > -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-error-tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vnops.c > In file included from fuse_vnops.c:36: > @/vm/vm_pager.h:126:2: warning: implicit declaration of function > 'rw_assert' is invalid in C99 [-Wimplicit-function-declaration] > VM_OBJECT_ASSERT_WLOCKED(object); > ^ > @/vm/vm_object.h:226:2: note: expanded from macro > 'VM_OBJECT_ASSERT_WLOCKED' > rw_assert(&(object)->lock, RA_WLOCKED) > ^ > In file included from fuse_vnops.c:36: > @/vm/vm_pager.h:126:2: error: use of undeclared identifier 'RA_WLOCKED' > @/vm/vm_object.h:226:29: note: expanded from macro > 'VM_OBJECT_ASSERT_WLOCKED' > rw_assert(&(object)->lock, RA_WLOCKED) > ^ > In file included from fuse_vnops.c:36: > @/vm/vm_pager.h:143:2: error: use of undeclared identifier 'RA_WLOCKED' > VM_OBJECT_ASSERT_WLOCKED(object); > ^ > @/vm/vm_object.h:226:29: note: expanded from macro > 'VM_OBJECT_ASSERT_WLOCKED' > rw_assert(&(object)->lock, RA_WLOCKED) > ^ > In file included from fuse_vnops.c:36: > @/vm/vm_pager.h:167:2: error: use of undeclared identifier 'RA_WLOCKED' > VM_OBJECT_ASSERT_WLOCKED(object); > ^ > @/vm/vm_object.h:226:29: note: expanded from macro > 'VM_OBJECT_ASSERT_WLOCKED' > rw_assert(&(object)->lock, RA_WLOCKED) > ^ > In file included from fuse_vnops.c:36: > @/vm/vm_pager.h:190:2: error: use of undeclared identifier 'RA_WLOCKED' > VM_OBJECT_ASSERT_WLOCKED(m->object); > ^ > @/vm/vm_object.h:226:29: note: expanded from macro > 'VM_OBJECT_ASSERT_WLOCKED' > rw_assert(&(object)->lock, RA_WLOCKED) > ^ > fuse_vnops.c:3397:3: warning: implicit declaration of function > 'VM_OBJECT_LOCK' is invalid in C99 [-Wimplicit-function-declaration] > VM_OBJECT_LOCK(vp->v_object); > ^ > fuse_vnops.c:3398:3: warning: implicit declaration of function > 'vm_page_lock_queues' is invalid in C99 [-Wimplicit-function-declaration] > vm_page_lock_queues(); > ^ > fuse_vnops.c:3406:4: warning: implicit declaration of function > 'vm_page_unlock_queues' is invalid in C99 [-Wimplicit-function-declaration] > vm_page_unlock_queues(); > ^ > fuse_vnops.c:3407:4: warning: implicit declaration of function > 'VM_OBJECT_UNLOCK' is invalid in C99 [-Wimplicit-function-declaration] > VM_OBJECT_UNLOCK(vp->v_object); > ^ > 5 warnings and 4 errors generated. > *** Error code 1 > > Stop. > make: stopped in > /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module > *** Error code 1 > > Stop. > make: stopped in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0 > *** Error code 1 > > Stop. > make: stopped in /usr/ports/sysutils/fusefs-kmod > *** Error code 1 > > Stop. > make: stopped in /usr/ports/sysutils/fusefs-kmod > > ===>>> make failed for sysutils/fusefs-kmod > ===>>> Aborting update > > ===>>> Killing background jobs > Terminated > Terminated > > ===>>> You can restart from the point of failure with this command line: > portmaster sysutils/fusefs-kmod > > ===>>> Exiting > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" You don't need sysutils/fusefs-kmod, since FreeBSD 10 includes FUSE in base. Reverse dependencies (sysutils/fusefs-curlftpfs, etc.) will correctly skip building it. This ought to use logic like that from emulators/virtio-kmod/Makefile. - Nikolai Lifanov From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 16:45:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2D1173F for ; Fri, 19 Jul 2013 16:45:11 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm29-vm7.bullet.mail.gq1.yahoo.com (nm29-vm7.bullet.mail.gq1.yahoo.com [98.136.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAAE3D3 for ; Fri, 19 Jul 2013 16:45:11 +0000 (UTC) Received: from [98.137.12.55] by nm29.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jul 2013 16:42:47 -0000 Received: from [98.136.164.76] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jul 2013 16:42:47 -0000 Received: from [127.0.0.1] by smtp238.mail.gq1.yahoo.com with NNFMP; 19 Jul 2013 16:42:47 -0000 X-Yahoo-Newman-Id: 266774.45674.bm@smtp238.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: utpbm9QVM1lpCxZDxBGIdGH5AEWQuuqStdSUvrQ0BFSDrMt Sk2L_TmlHRjF9fL5ygS433IjONHqUFYC3dX1QhAgOV1sU4gyazzqH3xisT9_ 8k.CAnlZxM9NaPM0KHDt03kbEc53YUYIsGxv2okHmHZN.MPDdwEw6KbrpOsl sdTZ3UaUvxs7TdNtpTJsFUd1I0nJhOJ9OO5uxhucOAX6pZgffh5ELymGs1fZ HQ0X4v5vgcOj2MRuGFvftjnPFEov0qaVg6hIU3zInAGf4H7h9adotRdw9EUY 5bXwINvsfibMlBYbou4mjjM2ivbkAqUREOgK6idK4eZxtSzjQL3oxoDeXRFc 0OjMdDlOJgalzLaU.o2r071djMAN6r62loIEqDSK4bgJ3e8.wweus1wZZ3wX K4onbnyCWa6xa7IA0D5YMqL.AogC.bKhLBt8ZjsySvTWB6WyU0I3dpNYzWjq GkGt08PdlV95ee911L3AE6Xbw62OjQcKU1HsmIk2jOqI5dRk1EgPAjFhYWbY rK962MqGmeVrz3NKNZAeB_I_VojEJPu.au_xqO53StE77 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp238.mail.gq1.yahoo.com with SMTP; 19 Jul 2013 16:42:47 +0000 UTC Message-ID: <51E96C84.3000209@FreeBSD.org> Date: Fri, 19 Jul 2013 11:42:44 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexander Panyushkin Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> In-Reply-To: <51E95B4D.4030104@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 16:45:11 -0000 (re-posting since the original response didn't make it through) On 19.07.2013 10:29, Alexander Panyushkin wrote: > 19.07.2013 17:36, Pedro Giffuni пишет: >> Hello; >> >> The internal data structures in the FUSE kernel module have been >> updated to be more compatible with MacFUSE and the linux FUSE. >> >> This basically means you have to rebuild your fuse modules >> (including NTFS). >> >> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. >> I will add a note to UPDATING. >> >> Pedro. > > > > Unfortunately the port is not build in FreeBSD 10 > > > ===>>> Starting build for sysutils/fusefs-kmod <<<=== > fusefs-kmod is not needed on -current. I meant you have to rebuild and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. Since this is a ports issue I will not update the UPDATING file. Developers that need to know should use __FreeBSD_version 1000038 as a reference. Pedro. From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 17:07:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A394BC9; Fri, 19 Jul 2013 17:07:55 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id A00346AE; Fri, 19 Jul 2013 17:07:54 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id m14so2517340eaj.2 for ; Fri, 19 Jul 2013 10:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pIRsyD1l9z1f/dZ9c/MrbDCpI6zA20gsjh5k2GjhsFE=; b=BTZc1fcA2wnuRk1WYAo/7oq0/CDJm3pMq+G/4qGUU1XB3l+ll6Bw+5U2bn7HTILHIf 1BOBfH3e+sk4A3594A//yooQXl9nnQ6D8PSjhaj8xRnRrXmfUpv/Y7lAmi4/1h40uJCF xTrpyd4xFkbMvaT5bMl89n1jrsWbqrrpYuzlon3t4Ja+bcXodjAjM/MIG9nVUdW2USbT O2CANAfZ5XEX02huHGekoszP7nJnXZqwyDRrq//CjaQ2pBdoVmiaMgT4E7psStxLaKcc W+m29elcIn/bIOVIsLB97S42W17xcy+GyVD6DqHIxVXz2JV2AM3ZC7Bj0AMYhauyh8S6 k+BQ== X-Received: by 10.14.179.133 with SMTP id h5mr16921670eem.46.1374253673781; Fri, 19 Jul 2013 10:07:53 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.187.173]) by mx.google.com with ESMTPSA id bj46sm28822645eeb.13.2013.07.19.10.07.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:07:53 -0700 (PDT) Message-ID: <51E97265.8040507@gmail.com> Date: Fri, 19 Jul 2013 20:07:49 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130519 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pedro Giffuni Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> In-Reply-To: <51E96C84.3000209@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 17:07:55 -0000 19.07.2013 19:42, Pedro Giffuni пишет: > (re-posting since the original response didn't make it through) > > On 19.07.2013 10:29, Alexander Panyushkin wrote: >> 19.07.2013 17:36, Pedro Giffuni пишет: >>> Hello; >>> >>> The internal data structures in the FUSE kernel module have been >>> updated to be more compatible with MacFUSE and the linux FUSE. >>> >>> This basically means you have to rebuild your fuse modules >>> (including NTFS). >>> >>> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. >>> I will add a note to UPDATING. >>> >>> Pedro. >> >> >> >> Unfortunately the port is not build in FreeBSD 10 >> >> >> ===>>> Starting build for sysutils/fusefs-kmod <<<=== >> > > fusefs-kmod is not needed on -current. I meant you have to rebuild > and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. > > Since this is a ports issue I will not update the UPDATING file. > > Developers that need to know should use __FreeBSD_version > 1000038 as a reference. > I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no effect. sysctl kern.osreldate kern.osreldate: 1000037 ntfs-3g /dev/ad10s1 /mnt/ntfs_0 mount ... /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) ls -la /mnt/ntfs_0 unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 getattr / unique: 18, success, outsize: 112 fuse: writing device: Invalid argument ls: /mnt/ntfs_0: Input/output error From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 17:35:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 191A97C3 for ; Fri, 19 Jul 2013 17:35:26 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id D3ABB87F for ; Fri, 19 Jul 2013 17:35:25 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p14so3325376vbm.4 for ; Fri, 19 Jul 2013 10:35:25 -0700 (PDT) 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=plCiAgAwkq/NHbCEPa67QtlAa8SJkwhTXgogjv3rgnU=; b=imly4VdBWzAF9XICK8Zzneibs1ewZCGqVMORACOUwRmpbHbn1b4XBsVsdDRE0lJSr0 PD8PFuzwT7CkfgYdQYWkj3Iadqw2yRr5YoLzAQWi8mB27ZWhMkLpMtP8odVAyD+rliT/ 1/4Ndg602ZRtrT4zK5NTzgKtRb86Le9MbxC1q/CSgSBDYP1VQMVaDGVZFmjxz+/5Kn1D eaC0GDc7ocEvEQlD/WR9MZvj6ky+nHzF/Af0HqZVL69yG/f2u6cdg7/XtiAJK+r6vVsI Z6n/eEXv1z4patPjxSmYsFsqQzhyqTT8GQDtPq4egwVWYY7rpo6rDFjo5grTrOO2bCre 1a4w== MIME-Version: 1.0 X-Received: by 10.220.79.73 with SMTP id o9mr5982487vck.78.1374255325271; Fri, 19 Jul 2013 10:35:25 -0700 (PDT) Received: by 10.221.8.135 with HTTP; Fri, 19 Jul 2013 10:35:25 -0700 (PDT) Date: Fri, 19 Jul 2013 13:35:25 -0400 Message-ID: Subject: buildworld failed on HEAD From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 17:35:26 -0000 hello all, I cant seem to figure out what is making build world fail, I could use some help from someone that knows more Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r253459: Fri Jul 19 00:47:22 UTC 2013 root@Border:/usr/obj/usr/src/sys/BORDER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Family = 0x6 Model = 0xf Stepping = 7 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7970164736 (7600 MB) --- var-tracking.o --- cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/var-tracking.c -o var-tracking.o --- usr.sbin.all__D --- --- acpi.o --- cc -O2 -pipe -I/usr/src/usr.sbin/acpi/acpidump/../../../sys -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.sbin/acpi/acpidump/acpi.c --- lib.all__D --- --- tty_update.po --- cc -pg -O2 -pipe -I. -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tty/tty_update.c -o tty_update.po --- usr.bin.all__D --- --- parsedata.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.bin/calendar/parsedata.c --- io.o --- --- parsedata.o --- /usr/src/usr.bin/calendar/parsedata.c:989:17: error: null character ignored [-Werror,-Wnull-character] i = strtol (s, ^ --- io.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.bin/calendar/io.c --- parsedata.o --- 1 error generated. *** [parsedata.o] Error code 1 make: stopped in /usr/src/usr.bin/calendar -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 17:53:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33F35CF0 for ; Fri, 19 Jul 2013 17:53:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 0436F947 for ; Fri, 19 Jul 2013 17:53:48 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id fb19so5801133obc.9 for ; Fri, 19 Jul 2013 10:53:48 -0700 (PDT) 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=5YV48YskKdT076EfusurVoR6K4ZFQpiWya0IER3oojE=; b=e3QFqCJgKkacoaW7WnnHsTyToEuIhOHSiXWNSGdO7db7z4PnrnH+OjsRWKjoeSVrYi qoK10cnKEAWQatJKK1C2nHeVLYTf2ua7QlbQ2ubft7r7SNOcdHq/QaPKdhcoI503h7ZQ ct6AeVmTOVLjvVYklViKC0hPyKVHU9kQ8Ofe3kzsATVPK6BSsHi4sHEr3Bpu5fjEZtP5 jptfKEYsCdMG/zfzbE/faXrZe3naTnXHHcFTbBaCgi6hOWoVp833ZVy0ah6D4VX77EtJ GWD920CUHFQZ7NezX3UHFI9lxBYil96nnhPbxgQt6eon2t/OS/NGiZv2PY00KJ4tH/UD 3psg== MIME-Version: 1.0 X-Received: by 10.60.140.168 with SMTP id rh8mr18965829oeb.17.1374256428641; Fri, 19 Jul 2013 10:53:48 -0700 (PDT) Received: by 10.76.123.76 with HTTP; Fri, 19 Jul 2013 10:53:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jul 2013 13:53:48 -0400 Message-ID: Subject: Re: buildworld failed on HEAD From: Ryan Stone To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 17:53:49 -0000 On Fri, Jul 19, 2013 at 1:35 PM, Sam Fourman Jr. wrote: > /usr/src/usr.bin/calendar/parsedata.c:989:17: error: null character ignored > [-Werror,-Wnull-character] > i = strtol (s, > Try looking at this file in vi. It sounds like a '\0' has somehow been inserted into this file and corrupted it. How did you get your source tree? From owner-freebsd-current@FreeBSD.ORG Fri Jul 19 18:17:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59518310 for ; Fri, 19 Jul 2013 18:17:32 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC47A44 for ; Fri, 19 Jul 2013 18:17:32 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id da11so3544296veb.6 for ; Fri, 19 Jul 2013 11:17:30 -0700 (PDT) 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=/2fk7eAeOExWXeyYxr0BYLfuFMjObl0XezvoIrZXwxI=; b=j1b88KaAJKC5Av9bk9N/NEp5y9vj31yUkavKh93pCxLyOuUyq2l3X8PapxxqVYV//z grpm2+/GifJvydT5zLIiMi2L3F1zzNjEhRhuWYp4XiELlWZaHXppe/HlLin02OsJotOi AcAbZU+ky1vrfw472E/NqOVc+gk6SlMpAIFpBm3VxjFmD8s7nnZbvPYCUJVVQu+CzpNZ PbTBObrrEAhfc+udeoVDWq/zy1BLJPfzOelsAIRxyz8/JAamOjve3uph604nsht9inXM KTfahI+6L5HuZaNIMLTm08QqOvA1TAOKsXaYx8b0ecm52e8oVtvPj14yrZLqE/H7CBla Mrmg== MIME-Version: 1.0 X-Received: by 10.52.32.133 with SMTP id j5mr5097724vdi.103.1374257850331; Fri, 19 Jul 2013 11:17:30 -0700 (PDT) Received: by 10.221.8.135 with HTTP; Fri, 19 Jul 2013 11:17:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jul 2013 14:17:30 -0400 Message-ID: Subject: Re: buildworld failed on HEAD From: "Sam Fourman Jr." To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 18:17:32 -0000 On Fri, Jul 19, 2013 at 1:53 PM, Ryan Stone wrote: > On Fri, Jul 19, 2013 at 1:35 PM, Sam Fourman Jr. wrote: > >> /usr/src/usr.bin/calendar/parsedata.c:989:17: error: null character >> ignored >> [-Werror,-Wnull-character] >> i = strtol (s, >> > > Try looking at this file in vi. It sounds like a '\0' has somehow been > inserted into this file and corrupted it. How did you get your source tree? > thats EXACTLY whats happening here... 988 if (s[0] == '+' || s[0] == '-') { 989 i = strtol (s,^@&es, 10); 990 if (*es != '\0') /* trailing junk */ 991 errx (1, "Invalid specifier format: %s\n", s); 992 return (i); 993 } 994 I used the new svnlite tool to get the src... so I did this: rm /usr/src/usr.bin/calendar/parsedata.c svnlite up and it restored the file but it still has the ^@ so im just going to manually remove it... im not sure whats going on here... Sam -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 01:25:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 293C8A99 for ; Sat, 20 Jul 2013 01:25:15 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm14-vm3.bullet.mail.ne1.yahoo.com (nm14-vm3.bullet.mail.ne1.yahoo.com [98.138.91.144]) by mx1.freebsd.org (Postfix) with ESMTP id A9AEDB07 for ; Sat, 20 Jul 2013 01:25:14 +0000 (UTC) Received: from [98.138.226.179] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2013 01:22:54 -0000 Received: from [98.138.226.126] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2013 01:22:54 -0000 Received: from [127.0.0.1] by smtp205.mail.ne1.yahoo.com with NNFMP; 20 Jul 2013 01:22:54 -0000 X-Yahoo-Newman-Id: 315952.68347.bm@smtp205.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kpdUHDYVM1nTeHyT4M7HMGH6yj1OUjmrQnm3.hq3YgVt50x JOAxWDGsJILyKW_t9I9AVgVE9IotoaaGA4GQsLyD3k22k5RBMYZYoCGkny.W woG3zfeNJ8eqczsMZEyuO0gC.fkMg9fvmoLOjRAq4eThvPn3zqyBwKmgszdK 4GAB5ZKSaSSAoZge9710AHYP5en.NMsDAYFky7PNOWFELc7HA2byZrEC6d29 CVX9vXTgqKp_Ofh_97z1Xr.MMhGjztznaPhuB4qaqbbiBrGpGHjyM3FMhUEG H.1WF0cSIO2ZerufPr45ViIYve3oIN7G5ZAGPam7c.EWox8lMGq23nCMvo61 WcNFo5QfHgfKhtbXln2a65Q_7udH7RjZenFGtcMzhU9EJfHwgxuFw50d.LNm PK2wJ1nRpBl3skaqfGck_vrEA5J5qfTNe6uPLeqhsYiBkZsFdmF9ASFOGuFa K_7a2EBJkv2oPJqMYHBb1SWSleqXluPVxhKjpdq_5yUmSr2HwAEuCqmy7zZh St97E54EzqLk86XSZZbCMTvbJvw-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp205.mail.ne1.yahoo.com with SMTP; 19 Jul 2013 18:22:52 -0700 PDT Message-ID: <51E9E669.3090500@FreeBSD.org> Date: Fri, 19 Jul 2013 20:22:49 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexander Panyushkin Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> In-Reply-To: <51E97265.8040507@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 01:25:15 -0000 On 19.07.2013 12:07, Alexander Panyushkin wrote: > 19.07.2013 19:42, Pedro Giffuni пишет: >> (re-posting since the original response didn't make it through) >> >> On 19.07.2013 10:29, Alexander Panyushkin wrote: >>> 19.07.2013 17:36, Pedro Giffuni пишет: >>>> Hello; >>>> >>>> The internal data structures in the FUSE kernel module have been >>>> updated to be more compatible with MacFUSE and the linux FUSE. >>>> >>>> This basically means you have to rebuild your fuse modules >>>> (including NTFS). >>>> >>>> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. >>>> I will add a note to UPDATING. >>>> >>>> Pedro. >>> >>> >>> >>> Unfortunately the port is not build in FreeBSD 10 >>> >>> >>> ===>>> Starting build for sysutils/fusefs-kmod <<<=== >>> >> >> fusefs-kmod is not needed on -current. I meant you have to rebuild >> and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. >> >> Since this is a ports issue I will not update the UPDATING file. >> >> Developers that need to know should use __FreeBSD_version >> 1000038 as a reference. >> > > I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no > effect. > > sysctl kern.osreldate > kern.osreldate: 1000037 > > ntfs-3g /dev/ad10s1 /mnt/ntfs_0 > mount > ... > /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) > > ls -la /mnt/ntfs_0 > unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 > getattr / > unique: 18, success, outsize: 112 > fuse: writing device: Invalid argument > ls: /mnt/ntfs_0: Input/output error > From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 04:42:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68B8391; Sat, 20 Jul 2013 04:42:42 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 296491FD; Sat, 20 Jul 2013 04:42:42 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id up14so6299928obb.14 for ; Fri, 19 Jul 2013 21:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kg5b3Fnd2DzjtMDaYZcGfIlsu94bOLBssI1XF55r+b0=; b=nBuJEyTGx2LuIHmOSEc8ckcBLCkMyeKcGqsd/o2d8Hyi0FWkMYF67csqKaa4UwNhx3 eo8oKqHOy6To2r+PA30GRD7tTLfzElshRYWH7iqUtiBuBoGvSTrsOtc9TfKxETkoDHiT tNS7D4t57W05J78eaYufM7imCaAIK5gOPGa/ldvaozVNU9si6GNaOLiKaOqYLiAWsh2l GFt7flPKIb1jw185k4cpF/2sZCuUZK2EcLpT6oBrBTCVem4D+wo77iaBSQBzKzQiGeLh kjskA+kp1qUvno8i4w9QnQ/V6frhVO4OkggPByy+LaEaaMrj73gSfYz1PgjD6mmaLZDE +xPA== MIME-Version: 1.0 X-Received: by 10.182.153.72 with SMTP id ve8mr14729378obb.39.1374295361763; Fri, 19 Jul 2013 21:42:41 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Fri, 19 Jul 2013 21:42:41 -0700 (PDT) In-Reply-To: <51E9E669.3090500@FreeBSD.org> References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> Date: Fri, 19 Jul 2013 21:42:41 -0700 X-Google-Sender-Auth: PHfrWbDYpx5YLQ1poL2U7YHFhro Message-ID: Subject: Re: FUSE not work. From: Kevin Oberman To: Pedro Giffuni Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Panyushkin , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 04:42:42 -0000 On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni wrote: > On 19.07.2013 12:07, Alexander Panyushkin wrote: > >> 19.07.2013 19:42, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> (re-posting since the original response didn't make it through) >>> >>> On 19.07.2013 10:29, Alexander Panyushkin wrote: >>> >>>> 19.07.2013 17:36, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>> >>>>> Hello; >>>>> >>>>> The internal data structures in the FUSE kernel module have been >>>>> updated to be more compatible with MacFUSE and the linux FUSE. >>>>> >>>>> This basically means you have to rebuild your fuse modules >>>>> (including NTFS). >>>>> >>>>> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. >>>>> I will add a note to UPDATING. >>>>> >>>>> Pedro. >>>>> >>>> >>>> >>>> >>>> Unfortunately the port is not build in FreeBSD 10 >>>> >>>> >>>> =3D=3D=3D>>> Starting build for sysutils/fusefs-kmod <<<=3D=3D=3D >>>> >>>> >>> fusefs-kmod is not needed on -current. I meant you have to rebuild >>> and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. >>> >>> Since this is a ports issue I will not update the UPDATING file. >>> >>> Developers that need to know should use __FreeBSD_version >>> 1000038 as a reference. >>> >>> >> I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no effec= t. >> >> sysctl kern.osreldate >> kern.osreldate: 1000037 >> >> ntfs-3g /dev/ad10s1 /mnt/ntfs_0 >> mount >> ... >> /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) >> >> ls -la /mnt/ntfs_0 >> unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 >> getattr / >> unique: 18, success, outsize: 112 >> fuse: writing device: Invalid argument >> ls: /mnt/ntfs_0: Input/output error >> >> fuse is at least partly broken in -current. I discovered that if you mount two devices that use fuse, when you umount any of them, ll are marked as not mounted and disappear from df(1) or mount(8) output, but only one is actually cleanly unmounted and, if it has been written to, will likely be corrupt. This applies to at least ntfs. ATM no one is supporting fuse in current, so this may become a serious issue before long. --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 07:40:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9243C985 for ; Sat, 20 Jul 2013 07:40:13 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2918AB for ; Sat, 20 Jul 2013 07:40:12 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 4E656BD432; Sat, 20 Jul 2013 07:40:12 +0000 (UTC) Date: Sat, 20 Jul 2013 09:40:12 +0200 From: Jeremie Le Hen To: Mikolaj Golub Subject: Re: core.txt.N not created anymore on panic Message-ID: <20130720074011.GC13628@caravan.chchile.org> Mail-Followup-To: Mikolaj Golub , freebsd-current@FreeBSD.org References: <20130717071655.GE4484@caravan.chchile.org> <20130717072151.GF4484@caravan.chchile.org> <20130718090025.GA27874@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130718090025.GA27874@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 07:40:13 -0000 On Thu, Jul 18, 2013 at 12:00:26PM +0300, Mikolaj Golub wrote: > On Wed, Jul 17, 2013 at 09:21:51AM +0200, Jeremie Le Hen wrote: > > On Wed, Jul 17, 2013 at 09:16:55AM +0200, Jeremie Le Hen wrote: > > > Hi, > > > > > > Early May I set ddb_enable="YES" (crashinfo_enable="YES" by default). > > > Upon panic, it created the following kind of files: > > > > > > -rw------- 1 root wheel 549 Jun 26 22:09 info.0 > > > -rw------- 1 root wheel 1518501888 Jun 26 22:09 vmcore.0 > > > -rw------- 1 root wheel 196981 Jun 26 22:09 core.txt.0 > > > -rw------- 1 root wheel 546 Jun 26 23:15 info.1 > > > -rw------- 1 root wheel 472608768 Jun 26 23:15 vmcore.1 > > > -rw------- 1 root wheel 207034 Jun 26 23:15 core.txt.1 > > > -rw------- 1 root wheel 546 Jun 27 00:47 info.2 > > > -rw------- 1 root wheel 667717632 Jun 27 00:47 vmcore.2 > > > -rw------- 1 root wheel 208745 Jun 27 00:48 core.txt.2 > > > -rw------- 1 root wheel 549 Jul 3 14:40 info.3 > > > -rw------- 1 root wheel 1455198208 Jul 3 14:40 vmcore.3 > > > -rw------- 1 root wheel 208173 Jul 3 14:41 core.txt.3 > > > > > > The core.txt.N files contained crashinfo(8) informations along with > > > ddb textdump, because crashinfo(8) outputs dmesg. > > > > > > > > > Yesterday, I upgraded to latest -CURRENT from one from June 9th. While > > > stress-testing overnight, I got a couple of panics but core.txt.N are > > > not created anymore. > > > > > > -rw------- 1 root wheel 530 Jul 17 01:10 info.5 > > > -rw------- 1 root wheel 75776 Jul 17 01:10 textdump.tar.5 > > > -rw------- 1 root wheel 529 Jul 17 02:01 info.6 > > > -rw------- 1 root wheel 74240 Jul 17 02:01 textdump.tar.6 > > > -rw------- 1 root wheel 530 Jul 17 04:20 info.7 > > > -rw------- 1 root wheel 74752 Jul 17 04:20 textdump.tar.7 > > > -rw------- 1 root wheel 530 Jul 17 07:50 info.8 > > > -rw------- 1 root wheel 92672 Jul 17 07:50 textdump.tar.8 > > > -rw------- 1 root wheel 531 Jul 17 08:44 info.9 > > > -rw------- 1 root wheel 110592 Jul 17 08:44 textdump.tar.9 > > > > > > Each textdump.tar.N contains: > > > > > > tar tvf /var/crash/textdump.tar.9 > > > -rw------- 0 root wheel 49152 Jul 17 08:30 ddb.txt > > > -rw------- 0 root wheel 3179 Jul 17 08:30 config.txt > > > -rw------- 0 root wheel 54137 Jul 17 08:30 msgbuf.txt > > > -rw------- 0 root wheel 88 Jul 17 08:30 panic.txt > > > -rw------- 0 root wheel 120 Jul 17 08:30 version.txt > > > > > > Any idea changed in between? I checked svn log in etc/ but I found > > > nothing relevant. > > Before your system was configured to generate vmcore dumps. Now it is > configured to generate textdumps. crashinfo(8) works with vmcore. > > > > > For the record: > > > > debug.ddb.capture.bufoff: 0 > > debug.ddb.capture.maxbufsize: 5242880 > > debug.ddb.capture.inprogress: 0 > > debug.ddb.capture.bufsize: 49152 > > debug.ddb.capture.data: > > debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show > > lockedvnods > > kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; > > 'textdump set' tells ddb to store dumps in textdump format. Remove > this from /etc/ddb.conf (and run /etc/rc.d/ddb) if you want > crashinfo(8) data. That was it, thanks! I'm still confused why until recently, it worked as if textdump wasn't enabled. ddb capture was and I have never modified ddb.conf. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 10:26:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C395EFF for ; Sat, 20 Jul 2013 10:26:09 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id E5455C68 for ; Sat, 20 Jul 2013 10:26:08 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id r6K8xLXR011085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 20 Jul 2013 10:59:21 +0200 Received: from [192.168.1.110] (48.Red-83-60-209.dynamicIP.rima-tde.net [83.60.209.48]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6K8xJGR019079 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 20 Jul 2013 10:59:20 +0200 Message-ID: <51EA5166.4020508@entel.upc.edu> Date: Sat, 20 Jul 2013 10:59:18 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> In-Reply-To: <51E6EB0A.2060407@entel.upc.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sat, 20 Jul 2013 10:59:21 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 10:26:09 -0000 Al 17/07/2013 21:05, En/na Gustau Pérez i Querol ha escrit: > Hi, > > I'm having panics or hard freezes when starting X with an Intel > video card. The machine is able to start old X+twm without problems > but when I try gnome3 (in normal or fallback mode, doesn't matter) the > machine panics or hard freezes. > > This doesn't happen when running X with vesa. With vesa the gnome > is able to start in fallback (no composition) mode. Also, an old i386 > with an nvidia card is able to run that gnome3 with composition so I'd > say it has to do with the intel card. > > These are the specs of the machine: > > FreeBSD 10.0-CURRENT #4 r+3dc57aa: Wed Jul 17 15:13:07 CEST 2013 > root@portgus:/usr/obj/usr/src/sys/CUSTOM amd64 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > RAM: 8GB > Video Card: Intel chipid=0x00468086 > > The debugging knobs in the kernel config are there. I can also > confirm that I can break to the debugger with CTRL+ALT+ESC before > starting X. The world was build without debug symbols. > > Because the machine runs with an Intel card, I had to use my $work > dockstation to obtain a serial port and do the debug via serial port > with another machine. > > When starting X, either the machine freezes hard (and so no > CTRL+ALT+ESC) or the machine panics. It has never executed X without > panics or freezes. > > I was able to obtain a core dump, the results are at: > > https://dl.dropboxusercontent.com/u/2094962/core.txt.4 > > I was unable to dive any further because the dump only shows the > kernel side of things. The bt only seems to show the kernel side and > the user side of things seems to be corrupt. > > Any other info I can obtain from the machine in the moment of the > panic, let me know. I can easy do the debug via serial port. > > Gus > Reading the backtrace I see this: panic: pmap_release: pmap resident count -398580 != 0 which comes from amd64/amd64/pmap.c:1936. I suspect that pmap->pm_stats.resident_count being negative is a bug. Can this be caused by a userspace process? If that's possible, any idea why I get a corrupted stack an thus I'm not able to find the root of the problem. G. -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 11:20:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1A5460B; Sat, 20 Jul 2013 11:20:57 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 75C19DC8; Sat, 20 Jul 2013 11:20:57 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so6496886obc.34 for ; Sat, 20 Jul 2013 04:20:56 -0700 (PDT) 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=YePN99PcJCQogF935GC6MW5bG/eH8QchDUoKk554w+A=; b=U9Qjq6qOkIyiiOAhXwAzFScmOaRFwaHCrQ1jIxv649IixB0iXz1QtLCmCvfxYbZvqx CBSQwH6sreP/FMDmuDhejNMvKgV6IoY6zX9XDT3VGLDzcPyZw756oQCdV6lOT0TFBeNP agqr96XEWg6EPMw2jmkPg3TLlAufE0Rrnw1jflHP99uO/TAX9qwl/TTEL6wt3ofHGjuB 5gUlyQMaK++yr5Fi/Yi1jhOJv6pPeSQZPeRnBnim75E4GsU5p4Zp8urPZks07CX4iKci Z45gDNQyI3bzpVtL+1H8DPo01j8ausN5rD18Y+qe7DfZeLuQBIq5bAdvM5nlU0ZkAAK3 Seog== MIME-Version: 1.0 X-Received: by 10.60.102.41 with SMTP id fl9mr21196335oeb.37.1374319256472; Sat, 20 Jul 2013 04:20:56 -0700 (PDT) Received: by 10.182.227.231 with HTTP; Sat, 20 Jul 2013 04:20:56 -0700 (PDT) In-Reply-To: <51EA5166.4020508@entel.upc.edu> References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> Date: Sat, 20 Jul 2013 13:20:56 +0200 Message-ID: Subject: Re: Panic when starting X with Intel KMS From: Oliver Pinter To: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 11:20:57 -0000 On 7/20/13, Gustau P=E9rez i Querol wrote: > Al 17/07/2013 21:05, En/na Gustau P=E9rez i Querol ha escrit: >> Hi, >> >> I'm having panics or hard freezes when starting X with an Intel >> video card. The machine is able to start old X+twm without problems >> but when I try gnome3 (in normal or fallback mode, doesn't matter) the >> machine panics or hard freezes. >> >> This doesn't happen when running X with vesa. With vesa the gnome >> is able to start in fallback (no composition) mode. Also, an old i386 >> with an nvidia card is able to run that gnome3 with composition so I'd >> say it has to do with the intel card. >> >> These are the specs of the machine: >> >> FreeBSD 10.0-CURRENT #4 r+3dc57aa: Wed Jul 17 15:13:07 CEST 2013 >> root@portgus:/usr/obj/usr/src/sys/CUSTOM amd64 >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> RAM: 8GB >> Video Card: Intel chipid=3D0x00468086 >> >> The debugging knobs in the kernel config are there. I can also >> confirm that I can break to the debugger with CTRL+ALT+ESC before >> starting X. The world was build without debug symbols. >> >> Because the machine runs with an Intel card, I had to use my $work >> dockstation to obtain a serial port and do the debug via serial port >> with another machine. >> >> When starting X, either the machine freezes hard (and so no >> CTRL+ALT+ESC) or the machine panics. It has never executed X without >> panics or freezes. >> >> I was able to obtain a core dump, the results are at: >> >> https://dl.dropboxusercontent.com/u/2094962/core.txt.4 >> >> I was unable to dive any further because the dump only shows the >> kernel side of things. The bt only seems to show the kernel side and >> the user side of things seems to be corrupt. >> >> Any other info I can obtain from the machine in the moment of the >> panic, let me know. I can easy do the debug via serial port. >> >> Gus >> > > Reading the backtrace I see this: > > panic: pmap_release: pmap resident count -398580 !=3D 0 > > which comes from amd64/amd64/pmap.c:1936. I suspect that > pmap->pm_stats.resident_count being negative is a bug. > > Can this be caused by a userspace process? If that's possible, any > idea why I get a corrupted stack an thus I'm not able to find the root > of the problem. Added kib@ to CC. > > G. > > > -- > Salut i for=E7a, > > Gustau > > -------------------------------------------------------------------------= -- > Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting > Stop top-posting : http://en.wikipedia.org/wiki/Posting_style=09 > > O O O Gustau P=E9rez i Querol > O O O Unitat de Gesti=F3 dels departaments > O O O Matem=E0tica Aplicada IV i Enginyeria Telem=E0tica > > Universitat Polit=E8cnica de Catalunya > Edifici C3 - Despatx S101-B > UPC Campus Nord UPC > C/ Jordi Girona, 1-3 > 08034 - Barcelona > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 11:22:20 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A770728; Sat, 20 Jul 2013 11:22:20 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) by mx1.freebsd.org (Postfix) with ESMTP id DEB58DDE; Sat, 20 Jul 2013 11:22:19 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id B121DBD6F2; Sat, 20 Jul 2013 11:22:18 +0000 (UTC) Date: Sat, 20 Jul 2013 13:22:18 +0200 From: Jeremie Le Hen To: trasz@FreeBSD.org, alc@FreeBSD.org Subject: Fix for sys_munlock(2) with racct Message-ID: <20130720112218.GD13628@caravan.chchile.org> Mail-Followup-To: trasz@FreeBSD.org, alc@FreeBSD.org, freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 11:22:20 -0000 Hi Edward, Alan, I plan to commit the following patch: http://people.freebsd.org/~jlh/racct_munlock.diff This solves the following panic: panic: racct_sub: freeing 301989888 of resource 5, which is more than allocated 73728 for pwsafe (pid 4177) The problem is that the racct code in sys_munlock() trusts too much the user's input. vm_map_unwire_count() now returns how much memory has really been unwired. Any objection? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 15:05:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 35AA0E38 for ; Sat, 20 Jul 2013 15:05:25 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm18-vm4.bullet.mail.ne1.yahoo.com (nm18-vm4.bullet.mail.ne1.yahoo.com [98.138.91.178]) by mx1.freebsd.org (Postfix) with ESMTP id DE58966B for ; Sat, 20 Jul 2013 15:05:24 +0000 (UTC) Received: from [98.138.226.177] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2013 15:03:01 -0000 Received: from [98.138.84.46] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2013 15:03:01 -0000 Received: from [127.0.0.1] by smtp114.mail.ne1.yahoo.com with NNFMP; 20 Jul 2013 15:03:01 -0000 X-Yahoo-Newman-Id: 672383.31376.bm@smtp114.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yNCXH8kVM1mqGU373fTU1MgAJ9fKXwUoRldAXMcN_04x2g9 N5iSmOzCFog2J91HbQCHaCMDDjkDhzMH.Mx83oAsq5SXbRkagSqW_eusr2S0 uuAHMuO41XqgWKYHBoO7DMG_Q9ii.CkZrglOOBG22dkj0UrWljKODhjrVGLj g2ueT6e626vLKifbM87H8Ic.11iD5VU8l9NiuYPiq3xfBsP50CN79XeptJT1 4cwGJ7sI9L63leZJoBKfm5cK2kklIJGx27EUHAcdfrtp13tXXV3Z8yZoHiPF VEJazUTy3yd6iOwh_1MJF_wn2KGdPX4pjuAKASV59Zwr5K.uajixBarpFP4X n188nh3EAKoVUy_bWHBDNbNnWVN6E_37vZl5uFIjgiohVFQ3Qy5KxrKOiusi nENqWmeUO3v.TiNQzSDMoqig6agDOJbU_tc3cEgeI8.NFbVaJ2gg.rjpPvN5 VvLkL9Kv4grrmTJQCzi7Hqgj3ovX7wPgHG.D7e8DqJppWarEgsqFkf3ej2u6 nA5AaFQTN6BrKqh_jeswMPkZDfHMskGE- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp114.mail.ne1.yahoo.com with SMTP; 20 Jul 2013 08:03:01 -0700 PDT Message-ID: <51EAA6A3.0@FreeBSD.org> Date: Sat, 20 Jul 2013 10:02:59 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Panyushkin , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 15:05:25 -0000 On 19.07.2013 23:42, Kevin Oberman wrote: > ... > > > fuse is at least partly broken in -current. I discovered that if you > mount two devices that use fuse, when you umount any of them, ll are > marked as not mounted and disappear from df(1) or mount(8) output, but > only one is actually cleanly unmounted and, if it has been written to, > will likely be corrupt. This applies to at least ntfs. > > ATM no one is supporting fuse in current, so this may become a serious > issue before long. I reverted my incompatible changes and will try to see if upstream wants to adopt something compatible for birthtime support. I do agree that fuse needs a lot of work. I wonder if NetBSD's puffs/libperfuse is any better. Pedro. From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 20:43:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 696B4AA8 for ; Sat, 20 Jul 2013 20:43:28 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:470:fd92:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 768962FC for ; Sat, 20 Jul 2013 20:43:27 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 80F5983C5 for ; Sun, 21 Jul 2013 05:43:26 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id rZIxb3lA_Ber for ; Sun, 21 Jul 2013 05:43:24 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:470:fd92:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA for ; Sun, 21 Jul 2013 05:43:24 +0900 (JST) Date: Sun, 21 Jul 2013 05:43:23 +0900 From: Taku YAMAMOTO To: freebsd-current@freebsd.org Subject: IPSEC crashes after r253088 Message-Id: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; i386-portbld-freebsd10.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.14 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, 20 Jul 2013 20:43:28 -0000 After r253088, systems with IPSEC and KSTACK_PAGES < 4 crashes on booting into multi-user mode. The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with kernel stack overflow. The problem is what we have in sys/net/vnet.h: #define SYSCTL_VNET_PCPUSTAT(parent, nbr, name, type, array, desc) \ static int \ array##_sysctl(SYSCTL_HANDLER_ARGS) \ { \ type s; \ CTASSERT((sizeof(type) / sizeof(uint64_t)) == \ (sizeof(VNET(array)) / sizeof(counter_u64_t))); \ COUNTER_ARRAY_COPY(VNET(array), &s, sizeof(type) / sizeof(uint64_t));\ if (req->newptr) \ COUNTER_ARRAY_ZERO(VNET(array), \ sizeof(type) / sizeof(uint64_t)); \ return (SYSCTL_OUT(req, &s, sizeof(type))); \ } \ SYSCTL_VNET_PROC(parent, nbr, name, CTLTYPE_OPAQUE | CTLFLAG_RW, NULL, \ 0, array ## _sysctl, "I", desc) where type is struct ipsecstat which is 12560 bytes of size (larger than 3 pages) of size when processing net.inet.ipsec.ipsecstats. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Sat Jul 20 23:04:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BFFA5FD7 for ; Sat, 20 Jul 2013 23:04:42 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 80F0A92B for ; Sat, 20 Jul 2013 23:04:42 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id 0235A8B for ; Sun, 21 Jul 2013 01:04:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BbwRiAMrV_nS for ; Sun, 21 Jul 2013 01:04:31 +0200 (CEST) Received: from [192.168.0.5] (178-36-46-51.adsl.inetia.pl [178.36.46.51]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id 423257E for ; Sun, 21 Jul 2013 01:04:31 +0200 (CEST) Message-ID: <51EB178E.7030708@dat.pl> Date: Sun, 21 Jul 2013 01:04:46 +0200 From: Maciej Milewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: IPSEC crashes after r253088 References: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> In-Reply-To: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> 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.14 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, 20 Jul 2013 23:04:42 -0000 On 20.07.2013 22:43, Taku YAMAMOTO wrote: > After r253088, systems with IPSEC and KSTACK_PAGES < 4 crashes on > booting into multi-user mode. > > The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with > kernel stack overflow. > > > The problem is what we have in sys/net/vnet.h: > > #define SYSCTL_VNET_PCPUSTAT(parent, nbr, name, type, array, desc) \ > static int \ > array##_sysctl(SYSCTL_HANDLER_ARGS) \ > { \ > type s; \ > CTASSERT((sizeof(type) / sizeof(uint64_t)) == \ > (sizeof(VNET(array)) / sizeof(counter_u64_t))); \ > COUNTER_ARRAY_COPY(VNET(array), &s, sizeof(type) / sizeof(uint64_t));\ > if (req->newptr) \ > COUNTER_ARRAY_ZERO(VNET(array), \ > sizeof(type) / sizeof(uint64_t)); \ > return (SYSCTL_OUT(req, &s, sizeof(type))); \ > } \ > SYSCTL_VNET_PROC(parent, nbr, name, CTLTYPE_OPAQUE | CTLFLAG_RW, NULL, \ > 0, array ## _sysctl, "I", desc) > > where type is struct ipsecstat which is 12560 bytes of size (larger than > 3 pages) of size when processing net.inet.ipsec.ipsecstats. > I can confirm. I've been hit by that problem on MIPS platform. -- Pozdrawiam, Maciej Milewski