From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 00:20:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 062D7325; Sun, 26 Oct 2014 00:20:49 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96BE1E11; Sun, 26 Oct 2014 00:20:48 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id z60so2554880qgd.15 for ; Sat, 25 Oct 2014 17:20: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:content-transfer-encoding; bh=SQ83G/29GkhbXUxXZdNnIJ17AXVtmNSOGj5xKmqeMts=; b=i/mYuHgZlwrKB2SzaPDBE8cINT981cXjXnZ5D1WnSlO7+Ltwmev5PSr9fWTdJxIcnc vp42otvI49vOSMW2ATCINuPPz5R3f6ae05lJOhxS9wxEXrbNIO937p8wmkZlkYHaoP8F k5Y2jQnJSBoOXwjs5OdB+jL12RDoZ/rjUT/hjdy1DG0zg7z+zPBgfFkGHceBOavLZnpL PPF2TVpWm4eDvqq5UdK0qGjZOsZoxrXwKeIrWGES+pTFDxznYxrrtiAVUkGoHwPddbv+ OFygmlBjtt2jJyKyn2PyeGe3bkXGByaIeBnEi7oIHJjj61jTdhMbGT+S63MV2m/xpJa5 4Oig== MIME-Version: 1.0 X-Received: by 10.229.53.133 with SMTP id m5mr19814856qcg.28.1414282847680; Sat, 25 Oct 2014 17:20:47 -0700 (PDT) Received: by 10.140.85.83 with HTTP; Sat, 25 Oct 2014 17:20:47 -0700 (PDT) In-Reply-To: References: <154A442D-7814-4618-9AFC-6F9FB3F5DFD3@gmail.com> <5443A89F.8050801@digiware.nl> Date: Sat, 25 Oct 2014 17:20:47 -0700 Message-ID: Subject: Re: HEADS UP: Merging projects/bhyve_svm to HEAD From: Neel Natu To: Zaphod Beeblebrox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Benjamin Perrault , freebsd-current , Neel Natu , "freebsd-virtualization@freebsd.org" , Anish Gupta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 00:20:49 -0000 Hi, On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox wrot= e: > I tried to integrate this patch into 10.1_RC3 and I failed. Is there a > timeframe to MFC this to 10.1 or 10-STABLE? > It will be MFCed to 10-STABLE but I don't have a specific time frame in min= d. I'll guess that it'll be towards the end of November but can be accelerated if someone has a need for this in 10-STABLE sooner. best Neel > On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault > wrote: >> >> After a few days of extensive testing and abuse, i=E2=80=99ve run into n= o new >> issues or unknowns what so ever. Everything that worked before still wor= ks >> now ( and a few bugs from fixed from HEAD ). >> >> Thus, I have gone ahead and pushed r273182 w/ Neel=E2=80=99s patch out t= o about 80 >> of the assorted AMD boxes in the production and dev pods that I care for= . If >> end users see something, I=E2=80=99ll let you know, but I have a feeling= they won=E2=80=99t. >> >> Again - Excellent work. >> >> cheers, >> -bp >> >> > On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen >> > wrote: >> > >> > On 16-10-2014 5:00, Anish Gupta wrote: >> >> Hi all, >> >> >> >> The projects/bhyve_svm branch is ready to be merged to HEAD. >> >> >> >> This branch contains patches to bhyve to enable it to work on AMD >> >> processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD >> >> processor since 2010 will have the features required by bhyve. >> >> >> >> bhyve on AMD supports (almost) all the features available with Intel >> >> [2]. All guest OSes supported on Intel are supported on AMD. All the >> >> bhyve-related utilities function similarly on both Intel and AMD >> >> platforms [3]. >> >> >> >> The patch against HEAD revision 273066 is available for review and >> >> testing: >> >> https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel=E2=80=99s= web >> >> directory] >> >> >> >> [1]: http://en.wikipedia.org/wiki/X86_virtualization >> >> [2]: bhyve doesn't support PCI passthru on AMD at this time >> >> [3]: bhyvectl has grown some processor-specific options >> > >> > Fetched the patch and compiled. >> > Now running: HEAD r273066M and I was able to throw at it all the tests >> > and images that in the past works. And perhaps even better. >> > >> > Great work. >> > --WjW >> > >> > >> > _______________________________________________ >> > freebsd-virtualization@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> > To unsubscribe, send any mail to >> > "freebsd-virtualization-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 08:48:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D637EE7 for ; Sun, 26 Oct 2014 08:48:21 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E94BD79 for ; Sun, 26 Oct 2014 08:48:20 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XiJUp-0001gV-F2 for freebsd-current@freebsd.org; Sun, 26 Oct 2014 01:48:19 -0700 Date: Sun, 26 Oct 2014 01:48:19 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20141026104814.6f72435c@rsbsd.rsb> In-Reply-To: <1792153082.7496945.1414276866911.JavaMail.root@uoguelph.ca> References: <1414231671692-5959433.post@n5.nabble.com> <544BC6B7.90608@pinyon.org> <20141025195819.1cc75873@rsbsd.rsb> <544C084A.3070807@pinyon.org> <1792153082.7496945.1414276866911.JavaMail.root@uoguelph.ca> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 08:48:21 -0000 Sorry guys, we have a considerable time-zone difference. >> It appears that the sysctl must be set before mountd, nfsd are >> started to take effect. (Or they must be restarted after it is set.) I had apparently re-started nfsd but not mountd. This time re-starting both and launching the PXE client fails at mount_root stage as expected: exec /sbin/init: error 43 exec /rescue/init: error 43 panic: no init One cannot set "sysctl vfs.nfsd.server_min_nfsvers=4" until one of mountd/nfsd is started however, otherwise it gives an error. I have not tried, but I suppose this error does not happen when placeed in /etc/sysctl.conf? sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or directory >> Maybe it was the talk about getting rid of the oldnfs stuff that >> made you think V2, 3 were going away? Yes, that was it and I obviously misunderstood that thread. What's the max NFS version that supports mount_root from PXE clients then? As I recall, this would be V3. However, root is consistently being mounted as V2. The fstab for diskless clients: 192.168.2.1:/data/amd64 / nfs ro,nfsv3 0 0 192.168.2.1:/usr/local /usr/local nfs ro,nfsv4 0 0 192.168.2.1:/home /home nfs rw,nfsv4,hard,intr 0 0 nfsstat shows "/" as NFSV2, while the other two are NFSV4. Changing fstab entry to nfsv4 for root gives same result. I tried set "sysctl vfs.nfsd.server_min_nfsvers=3" and I get the same mount_root error as when this was set to 4. Im I missing something? It does not seem that "vfs.nfsd.server_min_nfsvers" will be of much use to me, unless I can get > V2 to mount as root. Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 09:38:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBCC46FD for ; Sun, 26 Oct 2014 09:38:05 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C9711AA for ; Sun, 26 Oct 2014 09:38:04 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1XiKAt-000KR3-Qq; Sun, 26 Oct 2014 11:31:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Some NFS server V4 questions From: Daniel Braniss In-Reply-To: <20141026104814.6f72435c@rsbsd.rsb> Date: Sun, 26 Oct 2014 11:31:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1414231671692-5959433.post@n5.nabble.com> <544BC6B7.90608@pinyon.org> <20141025195819.1cc75873@rsbsd.rsb> <544C084A.3070807@pinyon.org> <1792153082.7496945.1414276866911.JavaMail.root@uoguelph.ca> <20141026104814.6f72435c@rsbsd.rsb> To: Beeblebrox X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 09:38:05 -0000 > On Oct 26, 2014, at 10:48 AM, Beeblebrox wrote: >=20 > Sorry guys, we have a considerable time-zone difference. >=20 >>> It appears that the sysctl must be set before mountd, nfsd are >>> started to take effect. (Or they must be restarted after it is set.) > I had apparently re-started nfsd but not mountd. This time re-starting = both and launching the PXE client fails at mount_root stage as expected: > exec /sbin/init: error 43 > exec /rescue/init: error 43 > panic: no init >=20 > One cannot set "sysctl vfs.nfsd.server_min_nfsvers=3D4" until one of = mountd/nfsd is started however, otherwise it gives an error. I have not = tried, but I suppose this error does not happen when placeed in = /etc/sysctl.conf? > sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or = directory >=20 >>> Maybe it was the talk about getting rid of the oldnfs stuff that >>> made you think V2, 3 were going away? > Yes, that was it and I obviously misunderstood that thread. >=20 > What's the max NFS version that supports mount_root from PXE clients = then? As I recall, this would be V3. However, root is consistently being = mounted as V2. to get pxeboot to do v3, add: boot-nfsroot-options=3D=E2=80=9Cnfsv3=E2=80=9D to /boot/loader.conf > The fstab for diskless clients: > 192.168.2.1:/data/amd64 / nfs ro,nfsv3 0 0 > 192.168.2.1:/usr/local /usr/local nfs ro,nfsv4 0 0 > 192.168.2.1:/home /home nfs rw,nfsv4,hard,intr 0 0 >=20 > nfsstat shows "/" as NFSV2, while the other two are NFSV4. Changing = fstab entry to nfsv4 for root gives same result. > I tried set "sysctl vfs.nfsd.server_min_nfsvers=3D3" and I get the = same mount_root error as when this was set to 4. Im I missing something? = It does not seem that "vfs.nfsd.server_min_nfsvers" will be of much use = to me, unless I can get > V2 to mount as root. >=20 > Regards. >=20 >=20 >=20 >=20 > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: = http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp595943= 3p5959595.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > 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 Oct 26 10:53:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAFB6F3B for ; Sun, 26 Oct 2014 10:53:35 +0000 (UTC) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9CCD9FF for ; Sun, 26 Oct 2014 10:53:35 +0000 (UTC) Received: from [87.79.253.40] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XiLRu-0000ko-OI for freebsd-current@freebsd.org; Sun, 26 Oct 2014 11:53:26 +0100 Date: Sun, 26 Oct 2014 12:53:30 +0100 From: Fabian Keil Cc: FreeBSD Current Subject: Re: Panic after USB deadlock followed by kldunload umass.ko Message-ID: <7af2d4d6.5c73ae4f@fabiankeil.de> In-Reply-To: <5449119B.8090401@selasky.org> References: <03fafb9a.529c7f26@fabiankeil.de> <5449119B.8090401@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/jBCTiW+Ox5SQQx9H=bWpUVb"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 10:53:36 -0000 --Sig_/jBCTiW+Ox5SQQx9H=bWpUVb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hans Petter Selasky wrote: > On 10/23/14 16:28, Fabian Keil wrote: > > kldunload umass.ko lead to a panic, dumping didn't work. > > > > Screenshots are available at: > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/ > > > > I've seen locked-up usbconfig processes in the past, > > usually after executing a shell function that does: > > > > | usbconfig_output=3D"$(sudo usbconfig -d ${device} add_quirk UQ_MSC_NO= _INQUIRY)" > > | [... error handling snipped ] > > | usbconfig_output=3D"$(sudo usbconfig -d ${device} reset)" > > > > Sometimes the second command seems to mess up the USB system. > USB detach is synchronous. If for example umass fails to detach, due to=20 > reference counts not reaching zero, that might be the root cause. Try to= =20 > get a backtrace from the "usb_process()" processes using kgdb, and=20 > you'll see right away what is going on. Thanks for the quick response. So far I haven't been able to intentionally reproduce the issue, but I'll try the above the next time I unintentionally run into this again. Fabian --Sig_/jBCTiW+Ox5SQQx9H=bWpUVb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRM4LoACgkQBYqIVf93VJ0/5ACePA2VOIuPTluXisMcoEffN1Ha wYYAn1CPV4W8B9yBuhwPN6zcTfJJtPER =eLqz -----END PGP SIGNATURE----- --Sig_/jBCTiW+Ox5SQQx9H=bWpUVb-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 12:14:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D40EB67 for ; Sun, 26 Oct 2014 12:14:06 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 03C06B3 for ; Sun, 26 Oct 2014 12:14:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAN3kTFSDaFve/2dsb2JhbABcg2JYBIMCyWUMhndUAoEaAX2EAgEBAQMBAQEBICsgBgUbGAICDRkCKQEJJgYIBwQBHASICwMJCQ2zUI0+F4YuAQEBAQEBBAEBAQEBAQEbgSyPCwEBGzQHgneBVAWWT4QOhDU8kEGEAIQUIS8BAQEEgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,790,1406606400"; d="scan'208";a="163558058" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Oct 2014 08:14:05 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 10B65B3F14; Sun, 26 Oct 2014 08:14:05 -0400 (EDT) Date: Sun, 26 Oct 2014 08:14:05 -0400 (EDT) From: Rick Macklem To: Beeblebrox Message-ID: <1990486074.7623473.1414325645061.JavaMail.root@uoguelph.ca> In-Reply-To: <20141026104814.6f72435c@rsbsd.rsb> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 12:14:06 -0000 Beeblebrox wrote: > Sorry guys, we have a considerable time-zone difference. > > >> It appears that the sysctl must be set before mountd, nfsd are > >> started to take effect. (Or they must be restarted after it is > >> set.) > I had apparently re-started nfsd but not mountd. This time > re-starting both and launching the PXE client fails at mount_root > stage as expected: > exec /sbin/init: error 43 > exec /rescue/init: error 43 > panic: no init > > One cannot set "sysctl vfs.nfsd.server_min_nfsvers=4" until one of > mountd/nfsd is started however, otherwise it gives an error. I have > not tried, but I suppose this error does not happen when placeed in > /etc/sysctl.conf? > sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or > directory > It works if it is /etc/sysctl.conf if "options NFSD" are specified for the kernel, which is what GENERIC for i386 has. If "options NFSD" isn't in your kernel config, I think you'd have to get nfsd.ko loaded before setting the sysctl and do both before starting mountd. I don't know of a clean way to do this? Putting kldload and sysctl command lines in mountd_precmd() in /etc/rc.d/mountd would do it I suspect. Maybe rc variables for this should be added? (I haven't tried this since the only kernels I have handy have "options NFSD" in them.) rick > >> Maybe it was the talk about getting rid of the oldnfs stuff that > >> made you think V2, 3 were going away? > Yes, that was it and I obviously misunderstood that thread. > > What's the max NFS version that supports mount_root from PXE clients > then? As I recall, this would be V3. However, root is consistently > being mounted as V2. > The fstab for diskless clients: > 192.168.2.1:/data/amd64 / nfs ro,nfsv3 0 0 > 192.168.2.1:/usr/local /usr/local nfs ro,nfsv4 0 0 > 192.168.2.1:/home /home nfs rw,nfsv4,hard,intr 0 0 > > nfsstat shows "/" as NFSV2, while the other two are NFSV4. Changing > fstab entry to nfsv4 for root gives same result. > I tried set "sysctl vfs.nfsd.server_min_nfsvers=3" and I get the same > mount_root error as when this was set to 4. Im I missing something? > It does not seem that "vfs.nfsd.server_min_nfsvers" will be of much > use to me, unless I can get > V2 to mount as root. > > Regards. > > > > > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > 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 Oct 26 12:19:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75878CA9 for ; Sun, 26 Oct 2014 12:19:30 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3C804D6 for ; Sun, 26 Oct 2014 12:19:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAArmTFSDaFve/2dsb2JhbABcg2JYBIMCyWUMhndUAoEaAX2EAgEBAQMBAQEBICsgBgUbGAICDRkCKQEJJgYIBwQBHASICwMJCQ2zT40+F4YuAQEBAQEBBAEBAQEBAQEbgSyPCwEBGzQHgneBVAWWT4QOhHGUQYQUIS8BAQEEgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,790,1406606400"; d="scan'208";a="163558658" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Oct 2014 08:19:28 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D30DAB3F4E; Sun, 26 Oct 2014 08:19:28 -0400 (EDT) Date: Sun, 26 Oct 2014 08:19:28 -0400 (EDT) From: Rick Macklem To: Beeblebrox Message-ID: <704800695.7624925.1414325968854.JavaMail.root@uoguelph.ca> In-Reply-To: <20141026104814.6f72435c@rsbsd.rsb> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 12:19:30 -0000 Beeblebrox wrote: > Sorry guys, we have a considerable time-zone difference. > > >> It appears that the sysctl must be set before mountd, nfsd are > >> started to take effect. (Or they must be restarted after it is > >> set.) > I had apparently re-started nfsd but not mountd. This time > re-starting both and launching the PXE client fails at mount_root > stage as expected: > exec /sbin/init: error 43 > exec /rescue/init: error 43 > panic: no init > > One cannot set "sysctl vfs.nfsd.server_min_nfsvers=4" until one of > mountd/nfsd is started however, otherwise it gives an error. I have > not tried, but I suppose this error does not happen when placeed in > /etc/sysctl.conf? > sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or > directory > > >> Maybe it was the talk about getting rid of the oldnfs stuff that > >> made you think V2, 3 were going away? > Yes, that was it and I obviously misunderstood that thread. > > What's the max NFS version that supports mount_root from PXE clients > then? As I recall, this would be V3. However, root is consistently > being mounted as V2. > The fstab for diskless clients: > 192.168.2.1:/data/amd64 / nfs ro,nfsv3 0 0 > 192.168.2.1:/usr/local /usr/local nfs ro,nfsv4 0 0 > 192.168.2.1:/home /home nfs rw,nfsv4,hard,intr 0 0 Just fyi, "hard" is the default and "intr" is an alternative to "hard", so I'm not sure what you get when specifying both? You should choose one or the other. (You will get "hard" for the first 2 entries.) rick > > nfsstat shows "/" as NFSV2, while the other two are NFSV4. Changing > fstab entry to nfsv4 for root gives same result. > I tried set "sysctl vfs.nfsd.server_min_nfsvers=3" and I get the same > mount_root error as when this was set to 4. Im I missing something? > It does not seem that "vfs.nfsd.server_min_nfsvers" will be of much > use to me, unless I can get > V2 to mount as root. > > Regards. > > > > > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > 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 Oct 26 12:41:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71929246 for ; Sun, 26 Oct 2014 12:41:19 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14CF132F for ; Sun, 26 Oct 2014 12:41:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9QCf9nK016866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2014 14:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9QCf9nK016866 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9QCf9WF016865; Sun, 26 Oct 2014 14:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 26 Oct 2014 14:41:09 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: Some NFS server V4 questions Message-ID: <20141026124109.GR1877@kib.kiev.ua> References: <20141026104814.6f72435c@rsbsd.rsb> <1990486074.7623473.1414325645061.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1990486074.7623473.1414325645061.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 12:41:19 -0000 On Sun, Oct 26, 2014 at 08:14:05AM -0400, Rick Macklem wrote: > Beeblebrox wrote: > > Sorry guys, we have a considerable time-zone difference. > > > > >> It appears that the sysctl must be set before mountd, nfsd are > > >> started to take effect. (Or they must be restarted after it is > > >> set.) > > I had apparently re-started nfsd but not mountd. This time > > re-starting both and launching the PXE client fails at mount_root > > stage as expected: > > exec /sbin/init: error 43 > > exec /rescue/init: error 43 > > panic: no init > > > > One cannot set "sysctl vfs.nfsd.server_min_nfsvers=4" until one of > > mountd/nfsd is started however, otherwise it gives an error. I have > > not tried, but I suppose this error does not happen when placeed in > > /etc/sysctl.conf? > > sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or > > directory > > > It works if it is /etc/sysctl.conf if "options NFSD" are specified > for the kernel, which is what GENERIC for i386 has. > > If "options NFSD" isn't in your kernel config, I think you'd have to > get nfsd.ko loaded before setting the sysctl and do both before > starting mountd. > > I don't know of a clean way to do this? > > Putting kldload and sysctl command lines in mountd_precmd() in > /etc/rc.d/mountd would do it I suspect. Maybe rc variables for > this should be added? (I haven't tried this since the only > kernels I have handy have "options NFSD" in them.) With the following patch, the same variables should work when set from the loader.conf (i.e. pre-boot) or using kenv(8). diff --git a/sys/fs/nfsserver/nfs_nfsdkrpc.c b/sys/fs/nfsserver/nfs_nfsdkrpc.c index d2145cc..4fb9c93 100644 --- a/sys/fs/nfsserver/nfs_nfsdkrpc.c +++ b/sys/fs/nfsserver/nfs_nfsdkrpc.c @@ -85,16 +85,16 @@ SYSCTL_DECL(_vfs_nfsd); SVCPOOL *nfsrvd_pool; static int nfs_privport = 0; -SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RW, +SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RWTUN, &nfs_privport, 0, "Only allow clients using a privileged port for NFSv2 and 3"); static int nfs_minvers = NFS_VER2; -SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RW, +SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RWTUN, &nfs_minvers, 0, "The lowest version of NFS handled by the server"); static int nfs_maxvers = NFS_VER4; -SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RW, +SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RWTUN, &nfs_maxvers, 0, "The highest version of NFS handled by the server"); static int nfs_proc(struct nfsrv_descript *, u_int32_t, SVCXPRT *xprt, From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 12:50:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 883983E6 for ; Sun, 26 Oct 2014 12:50:37 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 378F636D for ; Sun, 26 Oct 2014 12:50:36 +0000 (UTC) Received: from fortune.joker.local (180-198-225-68.nagoya1.commufa.jp [180.198.225.68]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.3/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id s9QCoZOh002381 for ; Sun, 26 Oct 2014 21:50:35 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 26 Oct 2014 21:50:34 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg? Message-Id: <20141026215034.3a71aa9bc48c0ecaaf5791fb@dec.sakura.ne.jp> In-Reply-To: <54458B06.5050301@freebsd.org> References: <20140811221043.492110d4@arch> <20140813213718.4814f58c@arch> <53EC1214.9020505@pinyon.org> <20141018121150.5aae6682@X220.alogt.com> <20141018145857.c17931841923f39c79464033@dec.sakura.ne.jp> <20141020183253.GE6490@blisses.org> <5837e41bf824926f9c49325e1817aec8@ultimatedns.net> <54458B06.5050301@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; 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.18-1 Precedence: 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, 26 Oct 2014 12:50:37 -0000 On Mon, 20 Oct 2014 18:21:58 -0400 Allan Jude wrote: > On 2014-10-20 17:15, Chris H wrote: > > On Mon, 20 Oct 2014 14:32:53 -0400 Mason Loring Bliss wrote > > > >> On Sat, Oct 18, 2014 at 02:58:57PM +0900, Tomoaki AOKI wrote: > >> > >>> I think the advantages of the forum are... > >>> > >>> *Well moderated by moderators and anministrators. > >>> *Registering email address is needed, but not disclosed by default. > >> > >> The disadvantages of web fora include: > >> > >> * I can't read things in my very efficient email client. Related: > >> * I have to compose my replies in a web browser edit window. > >> * I need to visit periodically and hope that the site makes it possible for > >> me to attend to unread messages without struggling. > >> > >> I think wikis are useful. I think web fora exist because folks haven't had > >> sufficient exposure to email to make the advantages clear. Not discussed here > >> are newsgroups, which are perhaps ideal for the sorts of topics commonly > >> found on mailing lists, except perhaps that they're not at all centralized. > > > > This thread reeks of bikeshed. > > There isn't anything wrong with all of the opinions shared in this thread > > except there will surely be no final consensus. :) > > > > --Chris > >> > >> -- > >> Mason Loring Bliss (( "In the drowsy dark cave of the mind dreams > >> mason@blisses.org )) build their nest with fragments dropped > >> http://blisses.org/ (( from day's caravan." - Rabindranath Tagore > >> _______________________________________________ > >> 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" > > > > > > _______________________________________________ > > 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" > > > > This thread is supposed to be about how to make it easier for people to > migrate to FreeBSD from Linux. Not a discussion about forums vs mailing > lists vs newsgroups. > > -- > Allan Jude > I guess. So I won't post further discussion about "Forum vs ML vs ..." in this thread. (Will pop in again if another thread purely for that is created. But as Chris noted later, there would be no final consensus.) Sorry for noise and long delay. -- Tomoaki AOKI junchoon@dec.sakura.ne.jp From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 13:18:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B4B08D3 for ; Sun, 26 Oct 2014 13:18:53 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D620829 for ; Sun, 26 Oct 2014 13:18:53 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::ac44:5633:9f66:7bdb] (unknown [IPv6:2001:7b8:3a7:0:ac44:5633:9f66:7bdb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5DC9EB80A; Sun, 26 Oct 2014 14:18:47 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: buildkernel fails on head From: Dimitry Andric In-Reply-To: <2096535.O1qKY0qN4C@quad> Date: Sun, 26 Oct 2014 14:18:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D4E40EA-D2AB-499F-8DAF-E0DAB4985DA9@FreeBSD.org> References: <2096535.O1qKY0qN4C@quad> To: Maxim V FIlimonov X-Mailer: Apple Mail (2.1990.1) Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 13:18:53 -0000 On 25 Oct 2014, at 23:39, Maxim V FIlimonov wrote: >=20 > I'm trying to build the current FreeBSD kernel, and that's what I get: >=20 > % sudo make buildkernel >=20 > -------------------------------------------------------------- >>>> Kernel build for GENERIC started on Sun Oct 26 01:39:13 MSK 2014 > -------------------------------------------------------------- > =3D=3D=3D> GENERIC > mkdir -p /usr/obj/usr/src/head/sys >=20 > -------------------------------------------------------------- >>>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /usr/src/head/sys/amd64/conf; =20 > = PATH=3D/usr/obj/usr/src/head/tmp/legacy/usr/sbin:/usr/obj/usr/src/head/tmp= /legacy/usr/bin:/usr/obj/usr/src/head/tmp/legacy/usr/games:/usr/obj/usr/sr= c/head/tmp/legacy/bin:/usr/obj/usr/src/head/tmp/usr/sbin:/usr/obj/usr/src/= head/tmp/usr/bin:/usr/obj/usr/src/head/tmp/usr/games:/sbin:/bin:/usr/sbin:= /usr/bin =20 > config -d /usr/obj/usr/src/head/sys/GENERIC -I = '/usr/src/head/sys/amd64/conf'=20 > '/usr/src/head/sys/amd64/conf/GENERIC' > config: illegal option -- I > usage: config [-CgmpV] [-d destdir] sysname > config -x kernel > *** Error code 64 >=20 > Stop. > make[1]: stopped in /usr/src/head > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src/head >=20 >=20 > is there a workaround for that? Is the kernel build broken? Your config executable is too old. Most likely, you need to run "make kernel-toolchain" first. -Dimitry From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 13:24:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68BABA1C; Sun, 26 Oct 2014 13:24:26 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2992E8DB; Sun, 26 Oct 2014 13:24:26 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id vb8so2260329obc.11 for ; Sun, 26 Oct 2014 06:24:25 -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=SO9jvO48DbKJtjgPJdKMqoR/q6RECF5nsN8pCYjz4v0=; b=FNDLcKz9wnLgYTUbfu9JnVKyxRY/9J6o+7NsA2TvkbWNOQXhXWB7MLbKYBExb3xP+G kqKjeMQH16Km9dIqCXL+1CQxB2mLI52mP5gAoP0X/Hs9sx7WzTl49AG1BLOZfGk6HQ89 NHb+OgetBDUK0nm8cZvIOTOhTbvJTyU5uZVoq7QLWmCMIYGbCXRD+34Syp1//gkmJllu f1/Dk/XNYQKw9MIPpPCT5KIh63UFX9kShv/FNWZVWaayO1szugwmd2ujDJjQGHOk9lGS x4rVJUOgRN8bXdmzSMqIKunuA1CUSRmBzgWALeI0kzLRGAFRb41L8XJdXMtEb8KODq1b yW+g== MIME-Version: 1.0 X-Received: by 10.182.20.195 with SMTP id p3mr2177198obe.42.1414329864966; Sun, 26 Oct 2014 06:24:24 -0700 (PDT) Received: by 10.182.251.135 with HTTP; Sun, 26 Oct 2014 06:24:24 -0700 (PDT) In-Reply-To: <20141025204536.GD19066@dft-labs.eu> References: <20141025204536.GD19066@dft-labs.eu> Date: Sun, 26 Oct 2014 15:24:24 +0200 Message-ID: Subject: Re: junior kernel tasks From: Anastasios Mag To: Mateusz Guzik , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-Mailman-Approved-At: Sun, 26 Oct 2014 14:36:40 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 13:24:26 -0000 Nice info... On Sat, Oct 25, 2014 at 11:45 PM, Mateusz Guzik wrote: > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" > > Cheers, > -- > Mateusz Guzik > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Mageirias Anastasios www.junkbytes.com From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 17:50:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96B45131; Sun, 26 Oct 2014 17:50:17 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6B71140; Sun, 26 Oct 2014 17:50:16 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id gm9so3298160lab.32 for ; Sun, 26 Oct 2014 10:50:14 -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:message-id:subject :from:to:content-type; bh=EMG8dy3/bWuxqoYN4J/E6BKquCh3EJDFqrlY3P5XLAk=; b=o+/jWN+AWDw7pqAYmbcIjFlhTofX34jO0nl7IZ7ZEA4BhnqB0poSrCts1tOqdK8BZz MZZDqgzI772JeYoLD+QTKW3X16FgQqn3jaCQEw65pFlpHjhS+S9bN6eMEoDtwGcdR77U zleT6YThlZ8Tcrd8yXNSgqRvdvQr0VJsNY11J9Q5ugtAYjLOMcwepbKuTOGxgNMK69Hn CwZqug5vqhwQQpwbjMg8Y4bpiQCXnKPgsyTu7xZq2ph8RvlAA14Thhk3R3LPclyg/NYC 5PxU+jIs6i8PBA/SnxBI4HPkXJSlinDdpdBmUrl6REG8QLh3JAxsG0AurM34JJWfGzB8 JPIQ== MIME-Version: 1.0 X-Received: by 10.152.5.169 with SMTP id t9mr3679645lat.90.1414345814870; Sun, 26 Oct 2014 10:50:14 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Sun, 26 Oct 2014 10:50:14 -0700 (PDT) In-Reply-To: <20141025204536.GD19066@dft-labs.eu> References: <20141025204536.GD19066@dft-labs.eu> Date: Sun, 26 Oct 2014 10:50:14 -0700 X-Google-Sender-Auth: lSBKNHZ2epheJUJxEH0fI_AstB4 Message-ID: Subject: Re: junior kernel tasks From: Craig Rodrigues To: Mateusz Guzik , "freebsd-hackers@freebsd.org" , freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 17:50:17 -0000 On Sat, Oct 25, 2014 at 1:45 PM, Mateusz Guzik wrote: > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. > > https://wiki.freebsd.org/JuniorJobs > > Thanks for making that list. I was looking at some other projects, and noticed that on the front page of http://www.dragonflybsd.org/ , they have a "Now Hiring" section with multiple links to Code Bounties, Summer of Code, etc., to help attract new people to the project. We need something like that on the front page of freebsd.org, to help attract new blood to the project. We have all the info, but it is just scattered across many different web pages, and is often outdated and not maintained. -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 18:04:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DB5AE5A; Sun, 26 Oct 2014 18:04:59 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 443C3364; Sun, 26 Oct 2014 18:04:59 +0000 (UTC) Received: from quad.localnet (home.bein.link [172.16.32.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPS id A6A621AF172; Sun, 26 Oct 2014 18:04:54 +0000 (UTC) From: Maxim V FIlimonov To: freebsd-current@freebsd.org Subject: Re: buildkernel fails on head Date: Sun, 26 Oct 2014 21:04:55 +0300 Message-ID: <2675015.Pnaaeo1R3H@quad> User-Agent: KMail/4.14.2 (FreeBSD/10.0-RELEASE-p11; KDE/4.14.2; amd64; ; ) In-Reply-To: <1D4E40EA-D2AB-499F-8DAF-E0DAB4985DA9@FreeBSD.org> References: <2096535.O1qKY0qN4C@quad> <1D4E40EA-D2AB-499F-8DAF-E0DAB4985DA9@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 18:04:59 -0000 On Sunday 26 October 2014 14:18:47 Dimitry Andric wrote: > > Your config executable is too old. Most likely, you need to run "make > kernel-toolchain" first. > Thank you very much, that helped. -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 18:11:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2764D9B for ; Sun, 26 Oct 2014 18:11:09 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECD67623 for ; Sun, 26 Oct 2014 18:11:08 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XiSHM-0004Rj-Nl for freebsd-current@freebsd.org; Sun, 26 Oct 2014 11:11:00 -0700 Date: Sun, 26 Oct 2014 11:11:00 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20141026201045.04af8c34@rsbsd.rsb> In-Reply-To: <704800695.7624925.1414325968854.JavaMail.root@uoguelph.ca> References: <1414231671692-5959433.post@n5.nabble.com> <544BC6B7.90608@pinyon.org> <20141025195819.1cc75873@rsbsd.rsb> <544C084A.3070807@pinyon.org> <1792153082.7496945.1414276866911.JavaMail.root@uoguelph.ca> <20141026104814.6f72435c@rsbsd.rsb> <704800695.7624925.1414325968854.JavaMail.root@uoguelph.ca> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 18:11:09 -0000 Dan: >> to get pxeboot to do v3, add to /boot/loader.conf >> boot-nfsroot-options=3D=E2=80=9Cnfsv3=E2=80=9D Thanks. I'm using grub for the bootloader and menu, and comparable entry sh= ould be: set kfreebsd.boot.nfsroot.options=3D"nfsv3" It does not work however. mount_root hangs for a while then reverts to V2. = I've asked about this on the grub-devel list, and will share the answer her= e. Rick: Would it be worth trying to pass a nolockd option for this? As you had stat= ed in another thread, "For NFSv3 mounts, I'd suggest the nolockd option, unless you have multiple= clients concurrently doing byte range locking on the same file. (With "nol= ockd" option on the mounts, you shouldn't need to run rpc.lockd, rpc.statd = and that implies NFSLOCKD shouldn't be needed, too.)" Should I try this? If yes, how is it done? >> Just fyi, "hard" is the default and "intr" is an alternative to "hard", = so I'm not sure what you get when specifying both? You should choose one or= the other. (You will get "hard" for the first 2 entries.) Thanks. Corrected by removing both. Konstantin: Have not gotten around to trying the code yet and thanks. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Some-NFS= -server-V4-questions-tp5959433p5959686.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Oct 26 20:30:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAE0AA4B for ; Sun, 26 Oct 2014 20:30:28 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 72403200 for ; Sun, 26 Oct 2014 20:30:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EACNZTVSDaFve/2dsb2JhbABcg2JYBIMCyWYMhndUAoEeAX2EAgEBAQMBAQEBICsgCxsYAgINGQIpAQkmBggHBAEcBIgLAwkJDbNQjS8Xhi4BAQEHAQEBAQEBARuBLI8LAQEbATMHgneBVAWWT4QOhHGUQYQUIS8BAQEEgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,791,1406606400"; d="scan'208";a="163612419" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Oct 2014 16:30:25 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D2748B404E; Sun, 26 Oct 2014 16:30:25 -0400 (EDT) Date: Sun, 26 Oct 2014 16:30:25 -0400 (EDT) From: Rick Macklem To: Beeblebrox Message-ID: <1453060363.7814476.1414355425851.JavaMail.root@uoguelph.ca> In-Reply-To: <20141026201045.04af8c34@rsbsd.rsb> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 20:30:28 -0000 Beeblebrox wrote: > Dan: > >> to get pxeboot to do v3, add to /boot/loader.conf > >> boot-nfsroot-options=3D=E2=80=9Cnfsv3=E2=80=9D > Thanks. I'm using grub for the bootloader and menu, and comparable > entry should be: > set kfreebsd.boot.nfsroot.options=3D"nfsv3" > It does not work however. mount_root hangs for a while then reverts > to V2. I've asked about this on the grub-devel list, and will share > the answer here. >=20 > Rick: > Would it be worth trying to pass a nolockd option for this? As you > had stated in another thread, > "For NFSv3 mounts, I'd suggest the nolockd option, unless you have > multiple clients concurrently doing byte range locking on the same > file. (With "nolockd" option on the mounts, you shouldn't need to > run rpc.lockd, rpc.statd and that implies NFSLOCKD shouldn't be > needed, too.)" > Should I try this? If yes, how is it done? >=20 Well, I thought that the root fs was remounted ("mount -u") using the options specified in /etc/fstab for the root fs. As far as I know, putting the "nolockd" option there should work. rick > >> Just fyi, "hard" is the default and "intr" is an alternative to > >> "hard", so I'm not sure what you get when specifying both? You > >> should choose one or the other. (You will get "hard" for the > >> first 2 entries.) > Thanks. Corrected by removing both. >=20 > Konstantin: > Have not gotten around to trying the code yet and thanks. >=20 >=20 >=20 >=20 > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp59594= 33p5959686.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > 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 Oct 26 21:34:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A4967F8 for ; Sun, 26 Oct 2014 21:34:18 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0241CA87 for ; Sun, 26 Oct 2014 21:34:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAGNoTVSDaFve/2dsb2JhbABcg2JYBIMCyWoMhndUAoEfAX2EAwEBBAEBASArIAsbGgINGQIpAQkmBggHBAEcBIgLAxINs1KNLxeGLgEBAQEBAQQBAQEBAQEBARqBLI8LAQEbNAeCd4FUBZZPhA6ENTyGOooHhACEFCEvAQEBBIEIOYEDAQEB X-IronPort-AV: E=Sophos;i="5.04,791,1406606400"; d="scan'208";a="163617021" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Oct 2014 17:34:16 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 86B12B42FB; Sun, 26 Oct 2014 17:34:16 -0400 (EDT) Date: Sun, 26 Oct 2014 17:34:16 -0400 (EDT) From: Rick Macklem To: Beeblebrox Message-ID: <57684075.7856858.1414359256539.JavaMail.root@uoguelph.ca> In-Reply-To: <20141026104814.6f72435c@rsbsd.rsb> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 21:34:18 -0000 Beeblebrox wrote: Dan: >> to get pxeboot to do v3, add to /boot/loader.conf >> boot-nfsroot-options="nfsv3" >Thanks. I'm using grub for the bootloader and menu, and comparable entry should be: >set kfreebsd.boot.nfsroot.options=3D"nfsv3" >It does not work however. mount_root hangs for a while then reverts to V2. >I've asked about this on the grub-devel list, and will share the answer here. > I'm not sure. I vaguely recall that pxeboot (which is a stripped down version of "boot") uses NFS to read /boot/loader.conf. I'd try putting it in /boot/loader.conf on the root fs on the server, even if it is using grub later. This all assumes that your kernel is built with "options NFS_ROOT". If it built with "options BOOTP" etc, then it is an entirely different story. Good luck with it, rick ps: At some point, capturing the packets and looking at them in wireshark should tell you what it is doing and when. [stuff snipped for brevity] > Regards. > > > > > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > 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 Oct 26 22:40:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1D3D221; Sun, 26 Oct 2014 22:40:53 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7761BF43; Sun, 26 Oct 2014 22:40:53 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id hq11so1779492vcb.8 for ; Sun, 26 Oct 2014 15:40:52 -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=7Gqi+/UZbvXi9ZA0YjwjFpApB5JG0iMBXFM601QkTR4=; b=CXJy4f7jeKiAR8Etf/gCPuA4Cg20MW7d8JFlnbw8wT7F4HVmhfzLAuGTy7fslmKkZa 5YGVTeJh3hhN9z4Pv2eScEpySdHqtO5nDibzifrzjOal+xb24FbbPs1JH6Dy+Dm85Mv3 PbnqBZ0mpbbnD5HuqF0Vtq5tgQc660CjCp5JR1b+A+iyrlcweII5ZNS3bF/wHkvlzbgh 82kOdzwiKQNNjjNuIOSc9bw8fRNt50B3I2qVWXXQOxv7TmlRHckABe2CLylxqJRc40Dl Ao3NpEUZCIFMew+l0GP43yor0MyxEqMSdBJUsFzS1dVeNPI2ltBbQLSVZ+KWfpIyrnxG 8z5Q== MIME-Version: 1.0 X-Received: by 10.52.96.228 with SMTP id dv4mr5929080vdb.9.1414363252592; Sun, 26 Oct 2014 15:40:52 -0700 (PDT) Received: by 10.220.118.73 with HTTP; Sun, 26 Oct 2014 15:40:52 -0700 (PDT) In-Reply-To: References: <154A442D-7814-4618-9AFC-6F9FB3F5DFD3@gmail.com> <5443A89F.8050801@digiware.nl> Date: Sun, 26 Oct 2014 18:40:52 -0400 Message-ID: Subject: Re: HEADS UP: Merging projects/bhyve_svm to HEAD From: Zaphod Beeblebrox To: Neel Natu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Benjamin Perrault , freebsd-current , Neel Natu , "freebsd-virtualization@freebsd.org" , Anish Gupta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 22:40:54 -0000 I would be using such a patch as soon as it was available. On a friend's advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig of RAM. I'd dearly like to use it to track down the netgraph bug (see my other recent posts), but it doesn't currently qualify. On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu wrote: > Hi, > > On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox > wrote: > > I tried to integrate this patch into 10.1_RC3 and I failed. Is there a > > timeframe to MFC this to 10.1 or 10-STABLE? > > > > It will be MFCed to 10-STABLE but I don't have a specific time frame in > mind. > > I'll guess that it'll be towards the end of November but can be > accelerated if someone has a need for this in 10-STABLE sooner. > > best > Neel > > > On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault < > ben.perrault@gmail.com> > > wrote: > >> > >> After a few days of extensive testing and abuse, i=E2=80=99ve run into= no new > >> issues or unknowns what so ever. Everything that worked before still > works > >> now ( and a few bugs from fixed from HEAD ). > >> > >> Thus, I have gone ahead and pushed r273182 w/ Neel=E2=80=99s patch out= to about > 80 > >> of the assorted AMD boxes in the production and dev pods that I care > for. If > >> end users see something, I=E2=80=99ll let you know, but I have a feeli= ng they > won=E2=80=99t. > >> > >> Again - Excellent work. > >> > >> cheers, > >> -bp > >> > >> > On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen > >> > wrote: > >> > > >> > On 16-10-2014 5:00, Anish Gupta wrote: > >> >> Hi all, > >> >> > >> >> The projects/bhyve_svm branch is ready to be merged to HEAD. > >> >> > >> >> This branch contains patches to bhyve to enable it to work on AMD > >> >> processors with SVM/AMD-V hardware extensions[1]. Pretty much any A= MD > >> >> processor since 2010 will have the features required by bhyve. > >> >> > >> >> bhyve on AMD supports (almost) all the features available with Inte= l > >> >> [2]. All guest OSes supported on Intel are supported on AMD. All th= e > >> >> bhyve-related utilities function similarly on both Intel and AMD > >> >> platforms [3]. > >> >> > >> >> The patch against HEAD revision 273066 is available for review and > >> >> testing: > >> >> https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel=E2=80= =99s web > >> >> directory] > >> >> > >> >> [1]: http://en.wikipedia.org/wiki/X86_virtualization > >> >> [2]: bhyve doesn't support PCI passthru on AMD at this time > >> >> [3]: bhyvectl has grown some processor-specific options > >> > > >> > Fetched the patch and compiled. > >> > Now running: HEAD r273066M and I was able to throw at it all the tes= ts > >> > and images that in the past works. And perhaps even better. > >> > > >> > Great work. > >> > --WjW > >> > > >> > > >> > _______________________________________________ > >> > freebsd-virtualization@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > >> > To unsubscribe, send any mail to > >> > "freebsd-virtualization-unsubscribe@freebsd.org" > >> > >> _______________________________________________ > >> 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 Oct 26 22:42:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31D2B377 for ; Sun, 26 Oct 2014 22:42:31 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id EC73EFE8 for ; Sun, 26 Oct 2014 22:42:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAJR3TVSDaFve/2dsb2JhbABcg2JYBIMCyWsKhnlUAoEgAX2EAwEBBAEBASArIAYFBRYOCgICDRkCKQEJJgYIBwQBHASIIA2zbJN4AQEBAQEFAQEBAQEBARuBLI8LAQEbNAeCd4FUBZZPhA6ENTyQQYQAhBQhLweBCDmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,792,1406606400"; d="scan'208";a="163624052" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Oct 2014 18:42:29 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 69563B416D; Sun, 26 Oct 2014 18:42:29 -0400 (EDT) Date: Sun, 26 Oct 2014 18:42:29 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <234024408.7891655.1414363349422.JavaMail.root@uoguelph.ca> In-Reply-To: <20141026124109.GR1877@kib.kiev.ua> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org, Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Oct 2014 22:42:31 -0000 Kostik wrote: > On Sun, Oct 26, 2014 at 08:14:05AM -0400, Rick Macklem wrote: > > Beeblebrox wrote: > > > Sorry guys, we have a considerable time-zone difference. > > > > > > >> It appears that the sysctl must be set before mountd, nfsd are > > > >> started to take effect. (Or they must be restarted after it is > > > >> set.) > > > I had apparently re-started nfsd but not mountd. This time > > > re-starting both and launching the PXE client fails at mount_root > > > stage as expected: > > > exec /sbin/init: error 43 > > > exec /rescue/init: error 43 > > > panic: no init > > > > > > One cannot set "sysctl vfs.nfsd.server_min_nfsvers=4" until one > > > of > > > mountd/nfsd is started however, otherwise it gives an error. I > > > have > > > not tried, but I suppose this error does not happen when placeed > > > in > > > /etc/sysctl.conf? > > > sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file > > > or > > > directory > > > > > It works if it is /etc/sysctl.conf if "options NFSD" are specified > > for the kernel, which is what GENERIC for i386 has. > > > > If "options NFSD" isn't in your kernel config, I think you'd have > > to > > get nfsd.ko loaded before setting the sysctl and do both before > > starting mountd. > > > > I don't know of a clean way to do this? > > > > Putting kldload and sysctl command lines in mountd_precmd() in > > /etc/rc.d/mountd would do it I suspect. Maybe rc variables for > > this should be added? (I haven't tried this since the only > > kernels I have handy have "options NFSD" in them.) > > With the following patch, the same variables should work when > set from the loader.conf (i.e. pre-boot) or using kenv(8). > > diff --git a/sys/fs/nfsserver/nfs_nfsdkrpc.c > b/sys/fs/nfsserver/nfs_nfsdkrpc.c > index d2145cc..4fb9c93 100644 > --- a/sys/fs/nfsserver/nfs_nfsdkrpc.c > +++ b/sys/fs/nfsserver/nfs_nfsdkrpc.c > @@ -85,16 +85,16 @@ SYSCTL_DECL(_vfs_nfsd); > SVCPOOL *nfsrvd_pool; > > static int nfs_privport = 0; > -SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RW, > +SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RWTUN, > &nfs_privport, 0, > "Only allow clients using a privileged port for NFSv2 and 3"); > > static int nfs_minvers = NFS_VER2; > -SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RW, > +SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RWTUN, > &nfs_minvers, 0, "The lowest version of NFS handled by the > server"); > > static int nfs_maxvers = NFS_VER4; > -SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RW, > +SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RWTUN, > &nfs_maxvers, 0, "The highest version of NFS handled by the > server"); > > static int nfs_proc(struct nfsrv_descript *, u_int32_t, SVCXPRT > *xprt, Worked fine for me. Do you mind if I commit this or would you rather do it. Thanks, rick > _______________________________________________ > 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 Oct 27 00:22:45 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51CBD8BA; Mon, 27 Oct 2014 00:22:45 +0000 (UTC) Received: from mail.jrv.org (adsl-70-243-84-11.dsl.austtx.swbell.net [70.243.84.11]) by mx1.freebsd.org (Postfix) with ESMTP id 08876B34; Mon, 27 Oct 2014 00:22:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id D2B0F1B6C41; Sun, 26 Oct 2014 19:22:36 -0500 (CDT) Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra64.housenet.jrv [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Jy30G9Y-t3Az; Sun, 26 Oct 2014 19:22:26 -0500 (CDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id D79A11B6C3C; Sun, 26 Oct 2014 19:22:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra64.housenet.jrv Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra64.housenet.jrv [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Dh7RDba9VwES; Sun, 26 Oct 2014 19:22:26 -0500 (CDT) Received: from [192.168.138.128] (BMX.housenet.jrv [192.168.3.140]) by mail.jrv.org (Postfix) with ESMTPSA id B50751B6C39; Sun, 26 Oct 2014 19:22:26 -0500 (CDT) Message-ID: <544D9056.10805@jrv.org> Date: Sun, 26 Oct 2014 18:22:46 -0600 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "James R. Van Artsdalen" Subject: Re: zfs recv hangs in kmem arena References: <54250AE9.6070609@jrv.org> <543FAB3C.4090503@jrv.org> In-Reply-To: <543FAB3C.4090503@jrv.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Oct 2014 01:49:32 +0000 Cc: freebsd-fs@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 00:22:45 -0000 I was able to complete a ZFS replication by manually intervening each time "zfs recv" blocked on "kmem arena": running the program at the end was sufficient to unblock zfs each of the 17 times it stalled. The program is intended to consume about 24GB RAM out of 32GB physical RAM, thereby pressuring the ARC and kernel cache to shrink: when the program exits it would leave plenty of free RAM for zfs or whatever else. What actually happened is that every time, zfs unblocked as the program below was growing: it was never necessary to wait for the program to exit and free memory before zfs unblocked. On 10/16/2014 6:25 AM, James R. Van Artsdalen wrote: > The zfs recv / kmem arena hang happens with -CURRENT as well as > 10-STABLE, on two different systems, with 16GB or 32GB of RAM, from > memstick or normal multi-user environments, > > Hangs usually seem to hapeen 1TB to 3TB in, but last night one run hung > after only 4.35MB. > > On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote: >> FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2 r272070M: >> Wed Sep 24 17:36:56 CDT 2014 >> james@BLACKIE.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 >> >> With current STABLE10 I am unable to replicate a ZFS pool using zfs >> send/recv without zfs hanging in state "kmem arena", within the first >> 4TB or so (of a 23TB Pool). >> >> The most recent attempt used this command line >> >> SUPERTEX:/root# zfs send -R BIGTEX/UNIX@syssnap | ssh BLACKIE zfs recv >> -duvF BIGTOX >> >> though local replications fail in kmem arena too. >> >> The two machines I've been attempting this on have 16BG and 32GB of RAM >> each and are otherwise idle. >> >> Any suggestions on how to get around, or investigate, "kmem arena"? >> >> # top >> last pid: 3272; load averages: 0.22, 0.22, 0.23 up >> 0+08:25:02 01:32:07 >> 34 processes: 1 running, 33 sleeping >> CPU: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% idle >> Mem: 21M Active, 82M Inact, 15G Wired, 28M Cache, 450M Free >> ARC: 12G Total, 24M MFU, 12G MRU, 23M Anon, 216M Header, 47M Other >> Swap: 16G Total, 16G Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 1173 root 1 52 0 86476K 7780K select 0 124:33 0.00% sshd >> 1176 root 1 46 0 87276K 47732K kmem a 3 48:36 0.00% zfs >> 968 root 32 20 0 12344K 1888K rpcsvc 0 0:13 0.00% nfsd >> 1009 root 1 20 0 25452K 2864K select 3 0:01 0.00% ntpd >> ... #include #include long long s = ( (long long) 1 << 32) - 65; main() { char *p; p = calloc (s, 1); memset (p, 1, s); p = calloc (s, 1); memset (p, 1, s); p = calloc (s, 1); memset (p, 1, s); p = calloc (s, 1); memset (p, 1, s); p = calloc (s, 1); memset (p, 1, s); p = calloc (s, 1); memset (p, 1, s); } From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 05:25:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4B19BB3 for ; Mon, 27 Oct 2014 05:25:02 +0000 (UTC) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru [78.107.232.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dchagin.static.corbina.net", Issuer "dchagin.static.corbina.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CBFC1A4A for ; Mon, 27 Oct 2014 05:25:00 +0000 (UTC) Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.9/8.14.9) with ESMTP id s9QL2Cff001464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Oct 2014 00:02:12 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.9/8.14.9/Submit) id s9QL2Bbv001463; Mon, 27 Oct 2014 00:02:11 +0300 (MSK) (envelope-from dchagin) Date: Mon, 27 Oct 2014 00:02:11 +0300 From: Chagin Dmitry To: Konstantin Belousov Subject: Re: Ver 2 of the patch [was: Re: i915 driver update testing] Message-ID: <20141026210211.GA1103@dchagin.static.corbina.net> References: <20141007042043.GG26076@kib.kiev.ua> <5433E408.2010601@egr.msu.edu> <20141007164419.GB2153@kib.kiev.ua> <20141007180106.GD2153@kib.kiev.ua> <54344766.1040700@egr.msu.edu> <20141008170525.GH2153@kib.kiev.ua> <54358C88.2080501@egr.msu.edu> <20141022122640.GL1877@kib.kiev.ua> <54480C9B.7070606@egr.msu.edu> <20141023190329.GP1877@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <20141023190329.GP1877@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adam McDougall , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 05:25:02 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: > On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: > > On 10/22/2014 08:26, Konstantin Belousov wrote: >=20 > Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one > private report of the patch worked from person who got the same panic > in iicbb. Hi, Kostik! i915.6.patch & i7-4700.=20 FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 r2= 73708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 root@dchagin.s= tatic.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY amd64 Unread portion of the kernel message buffer: FDI TX state assertion failure (expected off, current on) error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Ha= swell pipe > 0 error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Ha= swell pipe > 0 drmn1: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin= 5 panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/h= ead/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 cpuid =3D 2 Uptime: 27s Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..9= 1% Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols #0 doadump (textdump=3D1) at /home/dchagin/head/sys/kern/kern_shutdown.c:2= 61 261 dumptid =3D curthread->td_tid; (kgdb) #0 doadump (textdump=3D1) at /home/dchagin/head/sys/kern/kern_shutd= own.c:261 #1 0xffffffff80691a75 in kern_reboot (howto=3D260) at /home/dchagin/head/sys/kern/kern_shutdown.c:447 #2 0xffffffff80692670 in vpanic ( fmt=3D0xffffffff80c763b9 "_sx_xlock_hard: recursed on non-recursive sx = %s @ %s:%d\n", ap=3D0xfffffe033c750d60) at /home/dchagin/head/sys/kern/kern_shutdown.c:746 #3 0xffffffff8069204c in kassert_panic ( fmt=3D0xffffffff80c763b9 "_sx_xlock_hard: recursed on non-recursive sx = %s @ %s:%d\n") at /home/dchagin/head/sys/kern/kern_shutdown.c:634 #4 0xffffffff806a09b0 in _sx_xlock_hard (sx=3D0xfffffe00039480e8,=20 tid=3D18446735277793944768, opts=3D0,=20 file=3D0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/= =2E./../../dev/drm2/i915/intel_iic.c", line=3D370) at /home/dchagin/head/sys/kern/kern_sx.c:519 #5 0xffffffff8069f9ed in __sx_xlock (sx=3D0xfffffe00039480e8,=20 td=3D0xfffff8000a9324c0, opts=3D0,=20 file=3D0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/= =2E./../../dev/drm2/i915/intel_iic.c", line=3D370) at sx.h:154 #6 0xffffffff8069f893 in _sx_xlock (sx=3D0xfffffe00039480e8, opts=3D0,=20 file=3D0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/= =2E./../../dev/drm2/i915/intel_iic.c", line=3D370) at /home/dchagin/head/sys/kern/kern_sx.c:311 #7 0xffffffff816464e6 in intel_gmbus_transfer (idev=3D0xfffff80080a99900,= =20 msgs=3D0xfffffe033c7511e0, nmsgs=3D2) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i= ntel_iic.c:370 #8 0xffffffff81646ac7 in intel_gmbus_transfer (idev=3D,=20 msgs=3D, nmsgs=3D) at iicbus_if.h:131 #9 0xffffffff8044a445 in IICBUS_TRANSFER (dev=3D0xfffff80080a99900,=20 msgs=3D0xfffffe033c7511e0, nmsgs=3D2) at iicbus_if.h:131 #10 0xffffffff8044a39b in iicbus_transfer (bus=3D0xfffff80080a99800,=20 msgs=3D0xfffffe033c7511e0, nmsgs=3D2) at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355 #11 0xffffffff8169309d in drm_do_probe_ddc_edid (adapter=3D0xfffff80080a998= 00,=20 buf=3D0xfffffe033c751257 ""y", block=3D, len=3D1) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.= c:290 #12 0xffffffff816909bc in drm_get_edid (connector=3D0xfffff80080826c00,=20 adapter=3D0xfffff80080a99800) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.= c:388 #13 0xffffffff81645690 in intel_hdmi_detect (connector=3D0xfffff80080826c00= ,=20 force=3D) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i= ntel_hdmi.c:465 #14 0xffffffff8168adf5 in drm_helper_probe_single_connector_modes ( connector=3D0xfffff80080826c00, maxX=3D8192, maxY=3D8192) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_= helper.c:135 #15 0xffffffff8169387f in drm_fb_helper_initial_config ( fb_helper=3D0xfffff8008093b200, bpp_sel=3D32) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_he= lper.c:1164 #16 0xffffffff81643e41 in intel_fbdev_init (dev=3D) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i= ntel_fb.c:245 #17 0xffffffff81617082 in i915_driver_load (dev=3D0xfffff80009807800, flags= =3D0) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i= 915_dma.c:1181 #18 0xffffffff8168ece5 in drm_attach (kdev=3D0xfffff800071b6e00,=20 idlist=3D) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c= :591 #19 0xffffffff806dd737 in DEVICE_ATTACH (dev=3D0xfffff800071b6e00) at device_if.h:180 #20 0xffffffff806dd19c in device_attach (dev=3D0xfffff800071b6e00) at /home/dchagin/head/sys/kern/subr_bus.c:2836 #21 0xffffffff806dd0c4 in device_probe_and_attach (dev=3D0xfffff800071b6e00) at /home/dchagin/head/sys/kern/subr_bus.c:2794 #22 0xffffffff806df8ba in bus_generic_driver_added (dev=3D0xfffff80003e3f20= 0,=20 driver=3D0xffffffff816726e0) at /home/dchagin/head/sys/kern/subr_bus.c:= 3845 #23 0xffffffff806e330f in BUS_DRIVER_ADDED (_dev=3D0xfffff80003e3f200,=20 _driver=3D0xffffffff816726e0) at bus_if.h:204 #24 0xffffffff806da51a in devclass_driver_added (dc=3D0xfffff80003e3c880,= =20 driver=3D0xffffffff816726e0) at /home/dchagin/head/sys/kern/subr_bus.c:= 1065 #25 0xffffffff806da302 in devclass_add_driver (dc=3D0xfffff80003e3c880,=20 driver=3D0xffffffff816726e0, pass=3D2147483647, dcp=3D0xffffffff816b8cb= 8) at /home/dchagin/head/sys/kern/subr_bus.c:1138 #26 0xffffffff806e1779 in driver_module_handler (mod=3D0xfffff80003dbb980,= =20 what=3D0, arg=3D0xffffffff81672710) at /home/dchagin/head/sys/kern/subr_bus.c:4694 #27 0xffffffff8066e2a0 in module_register_init (arg=3D0xffffffff816726c8) at /home/dchagin/head/sys/kern/kern_module.c:123 #28 0xffffffff8065d334 in linker_file_sysinit (lf=3D0xfffff8008012e200) at /home/dchagin/head/sys/kern/kern_linker.c:224 #29 0xffffffff8065cad3 in linker_load_file ( filename=3D0xfffff8000a90a120 "/boot/kernel/i915kms.ko",=20 result=3D0xfffffe033c751858) at /home/dchagin/head/sys/kern/kern_linker.c:424 #30 0xffffffff80658ec1 in linker_load_module (kldname=3D0x0,=20 modname=3D0xfffff8000a6bf800 "i915kms", parent=3D0x0, verinfo=3D0x0,=20 lfpp=3D0xfffffe033c7518b8) at /home/dchagin/head/sys/kern/kern_linker.c= :1999 #31 0xffffffff8065aeb9 in kern_kldload (td=3D0xfffff8000a9324c0,=20 file=3D0xfffff8000a6bf800 "i915kms", fileid=3D0xfffffe033c751900) at /home/dchagin/head/sys/kern/kern_linker.c:1031 #32 0xffffffff8065afbb in sys_kldload (td=3D0xfffff8000a9324c0,=20 uap=3D0xfffffe033c751a58) at /home/dchagin/head/sys/kern/kern_linker.c:= 1057 #33 0xffffffff80b5a098 in syscallenter (td=3D0xfffff8000a9324c0,=20 sa=3D0xfffffe033c751a48) at subr_syscall.c:133 #34 0xffffffff80b59a4f in amd64_syscall (td=3D0xfffff8000a9324c0, traced=3D= 0) at /home/dchagin/head/sys/amd64/amd64/trap.c:987 #35 0xffffffff80b2eacb in Xfast_syscall () at /home/dchagin/head/sys/amd64/amd64/exception.S:390 #36 0x000000080088d42a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 Sun Oct 26 23:41:48 MSK 2014 Oct 26 23:41:54 dchagin login: ROOT LOGIN (root) ON ttyv0 info: [drm] Initialized drm 1.1.0 20060810 drmn1: on vgapci1 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xe0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. XXXKIB HACK: HSW RC OFF FDI TX state assertion failure (expected off, current on) error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Ha= swell pipe > 0 error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Ha= swell pipe > 0 drmn1: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin= 5 panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/h= ead/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 cpuid =3D 2 Uptime: 27s Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..9= 1% --=20 Have fun! chd --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRNYVMACgkQ0t2Tb3OO/O2FSwCbBTYxYNjMzEUBwaLrhtgr9jw2 Cf0AnA+YPxr/x1N/cZTUEKbYYj9eJryb =rHJF -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 07:48:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEBF6DDD for ; Mon, 27 Oct 2014 07:48:29 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CA0A973 for ; Mon, 27 Oct 2014 07:48:29 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9R7mMcM069816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 09:48:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9R7mMcM069816 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9R7mLP2069815; Mon, 27 Oct 2014 09:48:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Oct 2014 09:48:21 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: Some NFS server V4 questions Message-ID: <20141027074821.GU1877@kib.kiev.ua> References: <20141026124109.GR1877@kib.kiev.ua> <234024408.7891655.1414363349422.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <234024408.7891655.1414363349422.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 07:48:29 -0000 On Sun, Oct 26, 2014 at 06:42:29PM -0400, Rick Macklem wrote: > Worked fine for me. Do you mind if I commit this or would you rather > do it. I committed the change as r273727. One issue with the commit is the specified MFC. The change will compile on stable/10, but as far as I remember the state of sysctl patches, it is nop on 10. It can be made functional with more patches to nfsserver, but I prefer for the functionality to wait the needed MFCs in kern_sysctl.c. From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 09:46:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7252C9A for ; Mon, 27 Oct 2014 09:46:40 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C0D5894 for ; Mon, 27 Oct 2014 09:46:40 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id n3so5746936wiv.15 for ; Mon, 27 Oct 2014 02:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MFYamSpCpXAqglJfD6aVMd+KbQUBNV+ZWDKga24XLOE=; b=Zoc0DB0e87M1fdlNlNeuOgRw70OMMceoLd7Rfq5GxZ4lgDb4X+Z57wYLg0KmZbICdF g6wqanA9o7vzx6fmWuRm7BZPtrHFr7FMaIH9p00ELqX8Ag+EJbun+pBvaZqra86VMaUB 1qiNxpfqvBGsSjMFX7y6SpaYSggrXsvfnTjEgmv5WI586okR8SazR5fkuJfeiAxgpaFo 8xKXqHH4S0DHblpI4oFxhHfRs26Bjjdc6K+0MhQ0zI1P+ySp71vilyflTEB494Es87zt orlKl5Aa/hpF4Wl1ooYxURJUwylyK8CME+e+wgjDg9OgSR9Kg9lSIfDCDvwdAbri9Gkn gtww== X-Received: by 10.180.9.169 with SMTP id a9mr19854581wib.7.1414403198474; Mon, 27 Oct 2014 02:46:38 -0700 (PDT) Received: from [192.168.1.14] (dvf247.internetdsl.tpnet.pl. [83.19.243.247]) by mx.google.com with ESMTPSA id l9sm14400317wia.0.2014.10.27.02.46.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 02:46:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: ZFS: i/o error - all block copies unavailable #2 From: Kazik CC In-Reply-To: <1414062766738-5958899.post@n5.nabble.com> Date: Mon, 27 Oct 2014 10:46:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141022153846.GA7092@brick.home> <9711EF60-74E0-46E4-A89E-CD0486F3C457@gmail.com> <1414062766738-5958899.post@n5.nabble.com> To: Beeblebrox X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 09:46:40 -0000 Unfortunatelly it changed nothing. Still same error. I also did try = grub2, but without success. > On 23 Oct 2014, at 13:12, Beeblebrox wrote: >=20 > You might want to try from the mfsbsd.iso environment, > 1. Import and mount the zpool you want to boot from > 2. Copy /boot/zfs/zpool.cache to /mnt/boot/zfs/ (over-write existing > zpool.cache file) > 3. Edit /mnt/boot/loader.conf and add any of these that you don't = already > have: > zfs_load=3D"YES" > opensolaris_load=3D"YES" > vfs.root.mountfrom=3D"zfs:zroot_name" > zpool_cache_load=3D"YES" > zpool_cache_type=3D"/boot/zfs/zpool.cache" > zpool_cache_name=3D"/boot/zfs/zpool.cache" >=20 > Might be worth a try. >=20 >=20 >=20 > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: = http://freebsd.1045724.n5.nabble.com/ZFS-i-o-error-all-block-copies-unavai= lable-2-tp5958692p5958899.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > 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 Oct 27 06:30:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AF42CCB; Mon, 27 Oct 2014 06:30:53 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E7182; Mon, 27 Oct 2014 06:30:52 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so4828045wgg.15 for ; Sun, 26 Oct 2014 23:30:51 -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=a6kGT3NPK1iEHsoKkgGZLfze++/y5U61OJRgcbvDnwA=; b=qYimyVf+pp+EF8ATlv7he3RTt2K6vWYB8KiZJD5xaBOMS25JOi78m30f0x6Rw9RZ4Q Vu4ROF4NO8+z2pe0kMjC8T/ksO9k9Iiz5rKytUCYSF+5aMlWDf2RGHjrHpmJEy1sqHCj MWGewfbMVtXqEbJe8oX6GcNXJERsDfhATYRtx7xCdhKgs/ZR+/qTjqPKOGJECBBvvnLW dvbCT1vA2uiDL7ZDXoSbBqiZhlzB0QxaUPW4Dkl8USMxvNgJwydPC2LK/EPhxajOAjTZ X3X+TmpY6DUeY91bFc9TnpNQtltIj0gXqW2t5Z4LQeMIYjhhL25qaKHs/HgBVj6dzHV5 oQeA== MIME-Version: 1.0 X-Received: by 10.194.77.199 with SMTP id u7mr823594wjw.92.1414391450910; Sun, 26 Oct 2014 23:30:50 -0700 (PDT) Received: by 10.180.8.8 with HTTP; Sun, 26 Oct 2014 23:30:50 -0700 (PDT) Received: by 10.180.8.8 with HTTP; Sun, 26 Oct 2014 23:30:50 -0700 (PDT) In-Reply-To: <20141025204536.GD19066@dft-labs.eu> References: <20141025204536.GD19066@dft-labs.eu> Date: Mon, 27 Oct 2014 07:30:50 +0100 Message-ID: Subject: Re: junior kernel tasks From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= To: FreeBSD Hackers , Mateusz Guzik , freebsd-current@freebsd.org X-Mailman-Approved-At: Mon, 27 Oct 2014 11:25:55 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 06:30:53 -0000 El 25/10/2014 22:46, "Mateusz Guzik" escribi=C3=B3: > > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. It would be nice if this page lists other junior tasks in base, documentation, etc, not just the kernel. Cheers. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" > > Cheers, > -- > Mateusz Guzik > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 12:23:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36F60B5E for ; Mon, 27 Oct 2014 12:23:26 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id EB3E6E27 for ; Mon, 27 Oct 2014 12:23:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAEs4TlSDaFve/2dsb2JhbABcg2JYBIMCyi8KhnlUAoEsAX2EAwEBBAEBASArIAsFFg4KAgINGQIpAQkmBggHBAEcBIggDbU6lDsBAQEBAQEEAQEBAQEBAQEagSyPCwEBGzQHgneBVAWWT4QOhHGUQYQUIS8HgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,795,1406606400"; d="scan'208";a="163701283" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 27 Oct 2014 08:23:18 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D435CB4059; Mon, 27 Oct 2014 08:23:18 -0400 (EDT) Date: Mon, 27 Oct 2014 08:23:18 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <616638147.8121466.1414412598859.JavaMail.root@uoguelph.ca> In-Reply-To: <20141027074821.GU1877@kib.kiev.ua> Subject: Re: Some NFS server V4 questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org, Beeblebrox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 12:23:26 -0000 Kostik wrote: > On Sun, Oct 26, 2014 at 06:42:29PM -0400, Rick Macklem wrote: > > Worked fine for me. Do you mind if I commit this or would you > > rather > > do it. > > I committed the change as r273727. > > One issue with the commit is the specified MFC. The change will > compile > on stable/10, but as far as I remember the state of sysctl patches, > it is nop on 10. It can be made functional with more patches to > nfsserver, but I prefer for the functionality to wait the needed MFCs > in > kern_sysctl.c. Righto. Thanks. I think the workaround of "build a kernel with options NFSD" (which most GENERIC kernels have) will be sufficient for now. Thanks again, rick ps: Now I know what TUN means;-) > _______________________________________________ > 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 Oct 27 13:12:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA6F5D13 for ; Mon, 27 Oct 2014 13:12:36 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F8FC62F for ; Mon, 27 Oct 2014 13:12:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Xik65-000okH-6i>; Mon, 27 Oct 2014 14:12:33 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=prometheus.zeit.bima) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Xik65-0011kh-2D>; Mon, 27 Oct 2014 14:12:33 +0100 Date: Mon, 27 Oct 2014 14:11:56 +0100 From: "O. Hartmann" To: freebsd-current@freebsd.org Subject: emulators/virtualbox-ose: compilation on CURRENT fails due to: tstVMStructRC: 1: Syntax error: "(" unexpected Message-ID: <20141027141156.24a261e1@prometheus.zeit.bima> Organization: FU Berlin X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 13:12:37 -0000 Compiling emulators/virtualbox-ose on a freshly installed CURRENT (FreeBSD 11.0-CURRENT #0 r273719: Mon Oct 27 07:59:12 CET 2014 amd64) results in the below shown error. I also tried to install the package on CURRENT via pkg install, but this results in a 32-Bit VirtualBox only - which is inacceptable. I have running emulators/virtualbox-ose on several other CURRENT machines, but most of those boxes are "grown", that means, they got CURRENT months ago and are maintained as usual (buildworld/portmaster). This box has been installed a couple of weeks ago and is successfully rejecting compilation of port emulators/virtualbox-ose, although I already updated the ports tree and did successfully a portmaster -R -fd /emulators/virtualbox-ose. Since I use some non-standard optimization flags in /etc/src.conf and /etc/make.conf (-O3 and CPUTYPE=native instead of plain -O and outdated architectural compatibilities), I switched back to the FreeBSD vanilla standard - but still the same. I can not imagine that the CPU of that specific box could be the culprit: dmesg output: CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3192.82-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 Features=0xbfebfbff Features2=0x7fbae3ff AMD Features=0x28100800 AMD Features2=0x1 Structured Extended Features=0x281 XSAVE Features=0x1 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 9107931136 (8686 MB) avail memory = 8147902464 (7770 MB) I have also problems compiling the port on a newly setup laptop (Intel i5-4200M CPU/Haswell), CURRENT as of the same date as reported here. The failure is the same. It seems, that on CURRENT installations as of a certain date not far in the past, the port fails to recompile successfully. The error is: [...] kBuild: Generating tstVMStructSize - /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/bin/tstVMStructRC: 1: Syntax error: "(" unexpected kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h] Error 2 kmk: *** Deleting file `/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h' kmk: *** Waiting for unfinished jobs.... filesplitter: Out of 144 files: 144 rewritten, 0 unchanged. (/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include) kmk_builtin_append "/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers" kmk: *** Exiting with status 2 *** Error code 2 From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 15:27:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86692379 for ; Mon, 27 Oct 2014 15:27:03 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A06E6D7 for ; Mon, 27 Oct 2014 15:27:03 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id at20so4583132iec.39 for ; Mon, 27 Oct 2014 08:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=6rP9R+Fe957yECs/xWDcxl2oSK1ecv+bwLYolirAvSo=; b=Ll1zUcmqNx826SeqqIgusnYeAbMQc104nAhTWJR3jP0K3GnpYE+yTpYj44s86aOl6j IDS4+VEI704xkdFS4ZVdrfca17PRvySsBCV9AZz+U9Ysy499mdajUxsC0Ffl6yfZqmSg +DivtNB4CoEq1hmP2SziOFhJ7Mwl9TRB5r/pDThwXjG1oR1cQAq3qfVnLxTumKcJbZoF AzJeCktbQedTtSbtfhwntVoLjtDTqPjoj8RX2jF059SCd4vbwTRAPwgXjdKER6Hi/rza AjiOj60hiKHJmpo8h4RdG/lM7IulEz8sWxqzezaZTR2g+Lb05/qywPH/mzms2IZ9l5dP BoLA== X-Received: by 10.42.187.72 with SMTP id cv8mr19799007icb.22.1414423622752; Mon, 27 Oct 2014 08:27:02 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.132 with HTTP; Mon, 27 Oct 2014 08:26:42 -0700 (PDT) From: Ed Maste Date: Mon, 27 Oct 2014 11:26:42 -0400 X-Google-Sender-Auth: g_pM70-Hfe7QW1HHVloBkhfH8iE Message-ID: Subject: Looking for libvgl users To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 15:27:03 -0000 vgl(3) is a graphics library for syscons(4) that provides some basic graphics operations (e.g. some mode setting, bitmaps, boxes, ellipses). Right now it does not support the newer vt(4) console. In order to help determine the priority of a porting effort to add vt(4) support I'd like to better understand where vgl is being used now. I'd be interested in hearing about both open source software using vgl as well as proprietary or internal applications. So if you're using vgl I'd appreciate a follow up (in private is fine) with a brief description of your use case. Thanks, Ed From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 16:35:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA19533 for ; Mon, 27 Oct 2014 16:35:14 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93CF3F8B for ; Mon, 27 Oct 2014 16:35:14 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wm4so2292231obc.6 for ; Mon, 27 Oct 2014 09:35:13 -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=0ZQtxvNcEzJYKISK+yjlG8mim5quUBKofe3wjN6+ZB8=; b=Tip0llNatlSXmTFG61exCMulWqYHHcpJBfoRQQIZuh4rgIVjV4k0pXUZEPoQvrqFwB cA1XHFSGkNSgc09nSpAKkOgZwMv27lSBqq2bgKM/rL+9duYlJmcUf6noqyOLglTYHUDC 18zeb37FpLv31VllHpQ8yrLX58i1s5EyMxnFhEoE1TZbSas/5PRhpw1HLrKb8lKz0oBz OiXn+04co6zhdk4XViZZiur3b+uG/49kSnJv89l5489hSeyW1fW6O+NQOoOPFwtVyiWf R/Owu5Zc3Afpuz3pSftdR/GB0sD7vKDTynPnWErSX82xDI1fcJxajHk+zuv8tMOi50z4 3Lfw== MIME-Version: 1.0 X-Received: by 10.182.233.169 with SMTP id tx9mr9499382obc.38.1414427713905; Mon, 27 Oct 2014 09:35:13 -0700 (PDT) Received: by 10.202.104.195 with HTTP; Mon, 27 Oct 2014 09:35:13 -0700 (PDT) In-Reply-To: References: <5441E834.2000906@freebsd.org> <544246E8.1090001@ijs.si> <20141019074600.GD82214@funkthat.com> Date: Mon, 27 Oct 2014 09:35:13 -0700 Message-ID: Subject: Re: ssh None cipher From: Freddie Cash To: Mark Martinec , FreeBSD-Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 16:35:15 -0000 On Sun, Oct 19, 2014 at 10:35 AM, Freddie Cash wrote: > On Oct 19, 2014 12:46 AM, "John-Mark Gurney" wrote: > > > > Freddie Cash wrote this message on Sat, Oct 18, 2014 at 10:21 -0700: > > > On Oct 18, 2014 3:54 AM, "Mark Martinec" > > > > wrote: > > > > > > > > If the purpose of having a none cipher is to have a fast > > > > file transfer, then one should be using sysutils/bbcp > > > > for that purposes. Uses ssd for authentication, and > > > > opens unencrypted channel(s) for the actual data transfer. > > > > It's also very fast, can use multiple TCP streams. > > > > > > That's an interesting alternative to rsync, scp, and ftp, but doesn't > help > > > with zfs send/recv which is where the none cipher really shines. > > > > > > Without the none cipher, SSH becomes the bottleneck limiting transfer= s > to > > > around 400 Mbps on a gigabit LAN. With the none cipher, the network > becomes > > > the bottleneck limiting transfers to around 920 Mbps on the same > gigabit > > > LAN. > > > > > > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs= . > > > > Are you running on HEAD or possibly 10.x (I believe we have OpenSSL > > 1.0.x on 10.x)? > > Nope, 9.2. And I don't think the 6200 series Opterons have AES-NI. > =E2=80=8BCorrection, the AMD Opteron 6200-series of CPUs to support AES-NI. However, these storage boxes use AMD Opteron 6128 CPUs. :( They do not support AES-NI. AES-based ciphers are extremely slow on these systems; the multithreaded AES-based ciphers are better, but nowhere near what the NONE cipher provides. :) sysutils/bbcp is interesting as an alternative, but it's a lot more complex than just enabling NONE in OpenSSH. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 16:44:49 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1636BA99 for ; Mon, 27 Oct 2014 16:44:49 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE4F212E for ; Mon, 27 Oct 2014 16:44:48 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XinPS-000Nsp-IN for freebsd-current@FreeBSD.org; Mon, 27 Oct 2014 17:44:46 +0100 Message-ID: <544E7679.7070207@FreeBSD.org> Date: Mon, 27 Oct 2014 17:44:41 +0100 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: HEADS UP: Enabling vt(4) by default Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7gtjCHoFeCMGWelobjbWXIfRSvvsFgmhs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 16:44:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7gtjCHoFeCMGWelobjbWXIfRSvvsFgmhs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! vt(4) is fairly usable today and we would like to enable it by default in one week (Monday November 3, 2014). For those who never used vt(4), here are its benefits: o It supports Unicode and double-width characters. o It supports the kernel video drivers (KMS) and allows to switch to and from an X session. o It supports UEFI. Of course, there are still issues. A list is available on the wiki: https://wiki.freebsd.org/Newcons#Known_Issues And in Bugzilla: https://bugs.freebsd.org/bugzilla/buglist.cgi?resolution=3D---&keywords=3D= vt Here's a summary of the major problems: o The keymap selection in bsdconfig(8), used by the installer, has not been updated to use the vt keymap list instead of the syscons one. o Only UTF-8 character maps. o The console resolution is currently fixed to the value chosen by the underlying graphics driver. o No support for several vidcontrol(1) features. o Graphics features such as mouse pointers and font setting work only in VGA graphics mode, not in VGA text mode. The goal is to fix remaining bugs in time before FreeBSD 11.0 release cyc= le. If you want to switch back to syscons, you may use the following line in /boot/loader.conf: kern.vty=3Dsc And please tell us why! :) --=20 Jean-S=C3=A9bastien P=C3=A9dron --7gtjCHoFeCMGWelobjbWXIfRSvvsFgmhs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUTnZ+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMWBQP/0SSBP95c1vFM6lJxzZR30SK qvIHOd384JelwZW5/JcD2+FSJT9DukJPAeD6FhshY7/Se4TndaUNvP45RpJTiVMX sVs8sZkIBjV0FKsv50yZ7SfxR/mAa1u1PuCoh2d1fJIVUonbeSgyXB0AEsNfD4xr IASVGtf4zTt7JaQfFKnrZ+HmJJHGRjoI+KgEyhtwAHZJbWgC2AWJwe2s2zgMJeHI ipTTgBE0qFOD+fK1HoeuoM/ai06Q+Cu5e+k/379XXRkBtlKdhEnAF2W6FlU52R/j uwBMWRlykGssrAFsABWrxZZq680tompmJEJA3rqD6wYs1w88rbZTt6TQ1whvGlTf VP1UDPnV/LSK767McQq9lqpgut85gm7+yjo/UZVXrWOA4K0j7XPwkxYN66eSf47h tzp7SJXI1XM5uRg+hIhoIzzDUI2nRKCWxjISEZk3rVHpUORDU728MRS5e5bkrq2H 3iFdP+dZwhXs6fuCtd5sJ9Serd3kGRJyOEqs0I2CVjWPAliLCjKCI9sH+BBj12nb okWRoQz6St62NWqt81uhPWbZk3g5KDvqU8qOqawmvM0ZAXi+eTK4LmcexfQ5q+Nk B9FvCxFVrVfQQuQZbDhvQsMjfWLD+QFl78fDmyeBOeqe+YLwCUMSwi2jQdEYKwER e9dmvL/jVJ/JRw51vUyb =XV9v -----END PGP SIGNATURE----- --7gtjCHoFeCMGWelobjbWXIfRSvvsFgmhs-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 16:58:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80C4B12E; Mon, 27 Oct 2014 16:58:31 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EE1B288; Mon, 27 Oct 2014 16:58:31 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id D9139B82C; Mon, 27 Oct 2014 12:58:28 -0400 (EDT) Message-ID: <544E79B0.1040006@protected-networks.net> Date: Mon, 27 Oct 2014 12:58:24 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current , pi@freebsd.org Subject: SVN r273734 breaks i386 compilation OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tgaSqlddoBTakG4OFAloG8MSOw5a6JD0w" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 16:58:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tgaSqlddoBTakG4OFAloG8MSOw5a6JD0w Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The updates to dd cause this on an i386 .. =3D=3D=3D> bin/dd (all) cc -O2 -pipe -march=3Dpentium4 -std=3Dgnu99 -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 -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/bin/dd/args.c /usr/src/bin/dd/args.c:192:43: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "bs must be between 1 and %jd", SSIZE_MAX); ~~~ ^~~~~~~~~ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fffffff /* max value for an int */ ^~~~~~~~~~ /usr/src/bin/dd/args.c:201:44: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "cbs must be between 1 and %jd", SSIZE_MAX); ~~~ ^~~~~~~~~ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fffffff /* max value for an int */ ^~~~~~~~~~ /usr/src/bin/dd/args.c:221:46: error: format specifies type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'unsigned int' [-Werror,-Wformat] errx(1, "files must be between 1 and %ju", SIZE_MAX); ~~~ ^~~~~~~~ %u /usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:180:18: note: expanded from macro 'SIZE_MAX' #define SIZE_MAX UINT32_MAX ^~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:82:20: note: expanded from macro 'UINT32_MAX' #define UINT32_MAX 0xffffffffU ^~~~~~~~~~~ /usr/src/bin/dd/args.c:241:45: error: format specifies type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "ibs must be between 1 and %ju", SSIZE_MA= X); ~~~ ^~~~~~~~= ~ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fffffff /* max value for an int */ ^~~~~~~~~~ /usr/src/bin/dd/args.c:259:45: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "obs must be between 1 and %jd", SSIZE_MA= X); ~~~ ^~~~~~~~= ~ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fffffff /* max value for an int */ ^~~~~~~~~~ 5 errors generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/bin/dd *** Error code 1 --tgaSqlddoBTakG4OFAloG8MSOw5a6JD0w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlROebQACgkQQv9rrgRC1JI6eACfVJ1KYrCt6zJQ+IFGRkqqHDSP YMUAoK9EMTbfVuGkX07/XXVbVGnm5/tE =DgRo -----END PGP SIGNATURE----- --tgaSqlddoBTakG4OFAloG8MSOw5a6JD0w-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 17:41:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1DD8580; Mon, 27 Oct 2014 17:41:03 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90BCD942; Mon, 27 Oct 2014 17:41:03 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XioHu-0003oD-Pq; Mon, 27 Oct 2014 18:41:02 +0100 Date: Mon, 27 Oct 2014 18:41:02 +0100 From: Kurt Jaeger To: Michael Butler Subject: Re: SVN r273734 breaks i386 compilation Message-ID: <20141027174102.GH66862@home.opsec.eu> References: <544E79B0.1040006@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544E79B0.1040006@protected-networks.net> X-Mailman-Approved-At: Mon, 27 Oct 2014 17:48:13 +0000 Cc: freebsd-current , pi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 17:41:04 -0000 Hi! > The updates to dd cause this on an i386 .. Yes, I'm sorry. Change reverted. -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 18:10:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C48B0BCE; Mon, 27 Oct 2014 18:10:38 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BD63CF3; Mon, 27 Oct 2014 18:10:38 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id y10so3735958wgg.11 for ; Mon, 27 Oct 2014 11:10:36 -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:message-id:subject :from:to:cc:content-type; bh=TLJVWj6y7ZnB0F3CwNfxHkTzRWhRnzrUDbPBv2rb2JM=; b=mTu3b7bcOtIqPnDhdGRzWK2W2POmkq5mMQZWq82FzzUePtzTv/ZZR2zXFBzpvolVFm KiNn+GZbk0tt4s0J36/0EgeWkyzZ16lMJgGyVpOWJ0ocMzAtK/cwViRCp/A89z0t+IPe +zlPXgemyP974s2xVaj+mS7vGckjD87fxWzUn6Gop+5QFrO7FR+3DlwCWMWxGOKZAJ9I /GvAXIZtiNJ4uFBj9ZTrN8H5bhhLV8d1wQyssTXsJqlmMjPN9oICTSmZPltmureHgmGn +g1MLds8khKTK8kb5MmgFyAxinuPql2sN+bDpN6v7EpYFhW09SOgsCM3DySjPt1zHI/1 k/8A== MIME-Version: 1.0 X-Received: by 10.180.188.41 with SMTP id fx9mr22066778wic.59.1414433436311; Mon, 27 Oct 2014 11:10:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Mon, 27 Oct 2014 11:10:36 -0700 (PDT) In-Reply-To: <20141026210211.GA1103@dchagin.static.corbina.net> References: <20141007042043.GG26076@kib.kiev.ua> <5433E408.2010601@egr.msu.edu> <20141007164419.GB2153@kib.kiev.ua> <20141007180106.GD2153@kib.kiev.ua> <54344766.1040700@egr.msu.edu> <20141008170525.GH2153@kib.kiev.ua> <54358C88.2080501@egr.msu.edu> <20141022122640.GL1877@kib.kiev.ua> <54480C9B.7070606@egr.msu.edu> <20141023190329.GP1877@kib.kiev.ua> <20141026210211.GA1103@dchagin.static.corbina.net> Date: Mon, 27 Oct 2014 11:10:36 -0700 X-Google-Sender-Auth: vO4R0VT6w7gHq1xQ10gzTl97XYM Message-ID: Subject: Re: Ver 2 of the patch [was: Re: i915 driver update testing] From: Adrian Chadd To: Chagin Dmitry Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Adam McDougall , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 18:10:39 -0000 This is Haswell, right? Didn't Kib say "not interested in haswell testing yet" ? -adrian On 26 October 2014 14:02, Chagin Dmitry wrote: > On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: >> On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: >> > On 10/22/2014 08:26, Konstantin Belousov wrote: >> >> Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one >> private report of the patch worked from person who got the same panic >> in iicbb. > > Hi, Kostik! > > i915.6.patch & i7-4700. > > > FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 r273708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 root@dchagin.static.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY amd64 > > Unread portion of the kernel message buffer: > FDI TX state assertion failure (expected off, current on) > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > drmn1: taking over the fictitious range 0xe0000000-0xf0000000 > info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off > info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 > panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > > cpuid = 2 > Uptime: 27s > Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% > > Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. > Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols > Reading symbols from /boot/kernel/i915kms.ko.symbols...done. > Loaded symbols for /boot/kernel/i915kms.ko.symbols > Reading symbols from /boot/kernel/drm2.ko.symbols...done. > Loaded symbols for /boot/kernel/drm2.ko.symbols > #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 > 261 dumptid = curthread->td_tid; > (kgdb) #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 > #1 0xffffffff80691a75 in kern_reboot (howto=260) > at /home/dchagin/head/sys/kern/kern_shutdown.c:447 > #2 0xffffffff80692670 in vpanic ( > fmt=0xffffffff80c763b9 "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n", ap=0xfffffe033c750d60) > at /home/dchagin/head/sys/kern/kern_shutdown.c:746 > #3 0xffffffff8069204c in kassert_panic ( > fmt=0xffffffff80c763b9 "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at /home/dchagin/head/sys/kern/kern_shutdown.c:634 > #4 0xffffffff806a09b0 in _sx_xlock_hard (sx=0xfffffe00039480e8, > tid=18446735277793944768, opts=0, > file=0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", line=370) > at /home/dchagin/head/sys/kern/kern_sx.c:519 > #5 0xffffffff8069f9ed in __sx_xlock (sx=0xfffffe00039480e8, > td=0xfffff8000a9324c0, opts=0, > file=0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", line=370) at sx.h:154 > #6 0xffffffff8069f893 in _sx_xlock (sx=0xfffffe00039480e8, opts=0, > file=0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", line=370) > at /home/dchagin/head/sys/kern/kern_sx.c:311 > #7 0xffffffff816464e6 in intel_gmbus_transfer (idev=0xfffff80080a99900, > msgs=0xfffffe033c7511e0, nmsgs=2) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > #8 0xffffffff81646ac7 in intel_gmbus_transfer (idev=, > msgs=, nmsgs=) > at iicbus_if.h:131 > #9 0xffffffff8044a445 in IICBUS_TRANSFER (dev=0xfffff80080a99900, > msgs=0xfffffe033c7511e0, nmsgs=2) at iicbus_if.h:131 > #10 0xffffffff8044a39b in iicbus_transfer (bus=0xfffff80080a99800, > msgs=0xfffffe033c7511e0, nmsgs=2) > at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355 > #11 0xffffffff8169309d in drm_do_probe_ddc_edid (adapter=0xfffff80080a99800, > buf=0xfffffe033c751257 ""y", block=, len=1) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:290 > #12 0xffffffff816909bc in drm_get_edid (connector=0xfffff80080826c00, > adapter=0xfffff80080a99800) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:388 > #13 0xffffffff81645690 in intel_hdmi_detect (connector=0xfffff80080826c00, > force=) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_hdmi.c:465 > #14 0xffffffff8168adf5 in drm_helper_probe_single_connector_modes ( > connector=0xfffff80080826c00, maxX=8192, maxY=8192) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:135 > #15 0xffffffff8169387f in drm_fb_helper_initial_config ( > fb_helper=0xfffff8008093b200, bpp_sel=32) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:1164 > #16 0xffffffff81643e41 in intel_fbdev_init (dev=) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_fb.c:245 > #17 0xffffffff81617082 in i915_driver_load (dev=0xfffff80009807800, flags=0) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_dma.c:1181 > #18 0xffffffff8168ece5 in drm_attach (kdev=0xfffff800071b6e00, > idlist=) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:591 > #19 0xffffffff806dd737 in DEVICE_ATTACH (dev=0xfffff800071b6e00) > at device_if.h:180 > #20 0xffffffff806dd19c in device_attach (dev=0xfffff800071b6e00) > at /home/dchagin/head/sys/kern/subr_bus.c:2836 > #21 0xffffffff806dd0c4 in device_probe_and_attach (dev=0xfffff800071b6e00) > at /home/dchagin/head/sys/kern/subr_bus.c:2794 > #22 0xffffffff806df8ba in bus_generic_driver_added (dev=0xfffff80003e3f200, > driver=0xffffffff816726e0) at /home/dchagin/head/sys/kern/subr_bus.c:3845 > #23 0xffffffff806e330f in BUS_DRIVER_ADDED (_dev=0xfffff80003e3f200, > _driver=0xffffffff816726e0) at bus_if.h:204 > #24 0xffffffff806da51a in devclass_driver_added (dc=0xfffff80003e3c880, > driver=0xffffffff816726e0) at /home/dchagin/head/sys/kern/subr_bus.c:1065 > #25 0xffffffff806da302 in devclass_add_driver (dc=0xfffff80003e3c880, > driver=0xffffffff816726e0, pass=2147483647, dcp=0xffffffff816b8cb8) > at /home/dchagin/head/sys/kern/subr_bus.c:1138 > #26 0xffffffff806e1779 in driver_module_handler (mod=0xfffff80003dbb980, > what=0, arg=0xffffffff81672710) > at /home/dchagin/head/sys/kern/subr_bus.c:4694 > #27 0xffffffff8066e2a0 in module_register_init (arg=0xffffffff816726c8) > at /home/dchagin/head/sys/kern/kern_module.c:123 > #28 0xffffffff8065d334 in linker_file_sysinit (lf=0xfffff8008012e200) > at /home/dchagin/head/sys/kern/kern_linker.c:224 > #29 0xffffffff8065cad3 in linker_load_file ( > filename=0xfffff8000a90a120 "/boot/kernel/i915kms.ko", > result=0xfffffe033c751858) > at /home/dchagin/head/sys/kern/kern_linker.c:424 > #30 0xffffffff80658ec1 in linker_load_module (kldname=0x0, > modname=0xfffff8000a6bf800 "i915kms", parent=0x0, verinfo=0x0, > lfpp=0xfffffe033c7518b8) at /home/dchagin/head/sys/kern/kern_linker.c:1999 > #31 0xffffffff8065aeb9 in kern_kldload (td=0xfffff8000a9324c0, > file=0xfffff8000a6bf800 "i915kms", fileid=0xfffffe033c751900) > at /home/dchagin/head/sys/kern/kern_linker.c:1031 > #32 0xffffffff8065afbb in sys_kldload (td=0xfffff8000a9324c0, > uap=0xfffffe033c751a58) at /home/dchagin/head/sys/kern/kern_linker.c:1057 > #33 0xffffffff80b5a098 in syscallenter (td=0xfffff8000a9324c0, > sa=0xfffffe033c751a48) at subr_syscall.c:133 > #34 0xffffffff80b59a4f in amd64_syscall (td=0xfffff8000a9324c0, traced=0) > at /home/dchagin/head/sys/amd64/amd64/trap.c:987 > #35 0xffffffff80b2eacb in Xfast_syscall () > at /home/dchagin/head/sys/amd64/amd64/exception.S:390 > #36 0x000000080088d42a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > Sun Oct 26 23:41:48 MSK 2014 > Oct 26 23:41:54 dchagin login: ROOT LOGIN (root) ON ttyv0 > info: [drm] Initialized drm 1.1.0 20060810 > drmn1: on vgapci1 > info: [drm] MSI enabled 1 message(s) > info: [drm] AGP at 0xe0000000 256MB > iicbus0: on iicbb0 addr 0xff > iic0: on iicbus0 > iic1: on iicbus1 > iicbus2: on iicbb1 addr 0xff > iic2: on iicbus2 > iic3: on iicbus3 > iicbus4: on iicbb2 addr 0xff > iic4: on iicbus4 > iic5: on iicbus5 > iicbus6: on iicbb3 addr 0xff > iic6: on iicbus6 > iic7: on iicbus7 > iicbus8: on iicbb4 addr 0xff > iic8: on iicbus8 > iic9: on iicbus9 > iicbus10: on iicbb5 addr 0xff > iic10: on iicbus10 > iic11: on iicbus11 > iicbus12: on iicbb6 addr 0xff > iic12: on iicbus12 > iic13: on iicbus13 > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > XXXKIB HACK: HSW RC OFF > FDI TX state assertion failure (expected off, current on) > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > drmn1: taking over the fictitious range 0xe0000000-0xf0000000 > info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off > info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 > panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > > cpuid = 2 > Uptime: 27s > Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% > -- > Have fun! > chd From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 20:22:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AAE94C4 for ; Mon, 27 Oct 2014 20:22:02 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E15EE2D for ; Mon, 27 Oct 2014 20:22:01 +0000 (UTC) Received: from pluto.sol.local ([188.102.183.116]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MYwQh-1XeED32Q8h-00VjLR for ; Mon, 27 Oct 2014 21:21:54 +0100 Message-ID: <544EA961.2090508@gmx.net> Date: Mon, 27 Oct 2014 21:21:53 +0100 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current Subject: Mounting ZFS with error 5 failed, since r271963 callout convert Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EqTvDgOcgwd1h4fc6edHUUviTjbp1pnXgXkMzRKx8ce3Z2pBfbf 0XkSRWUMhn5swPo/SykCYM5gT1MAulMTz9lxYt+diAUJ/2oLXBR6CcCbAt8BJVPmEOMkd+W a4pFtHTs+S10fgzcapQoUjbsOScROR+LHuwBIvEqrJYC5WBGBelrG5WIC9NNLrak1zSvLYu Kph9IxQQCvIc6/jjttWig== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 20:22:02 -0000 Hi List, my ZFS does not mount. I bifurcated to r271963 that does not work anymore. The commit seems not directly related to ZFS, but is rather a conversion from timeout(9) to callout(9). After booting the kernel it drops to the mount prompt, stating that ZFS cannot be mounted because of 'error 5'. Any hints? Can I provide some more information? Thanks, Michael From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 21:29:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE85E339 for ; Mon, 27 Oct 2014 21:29:32 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79A0476E for ; Mon, 27 Oct 2014 21:29:32 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id gq15so1471501lab.1 for ; Mon, 27 Oct 2014 14:29: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=EKhoFbiV1+qcA/JHe1cnwtsvpS8iUpymkDS8e7AnD+w=; b=u8bjDUe562+rQk+bgANff+bWd1OzhedOdjyOMaH9V3AfI/HkMnydPi9tr98ucNUIEi YXY3d7fHwM7/F06XXJ58A0T/w8caKdM2y151cINhhLKQZxJGCHZxuIB6Xo+Rtv0i5OV2 vuvEiQ2nbm2bTH9pPM0mnyD23j9weBLgqC4nVs+zv+QpC+fY+CiuySzAd1atJGEpyoSQ 8K1N2eW5Ds3ttRF/uUausdrPHXdRW/nl6nEfkTmrymBdY5gMbr5/7XWjQ6KW/XwWGHeA N53Qe3cLcR+S7ZxVjIPwZr9Rqc35WmHD6MnBNH4RSz1G+7ifWhkaXAhd5ofKyULATYVk lEUg== MIME-Version: 1.0 X-Received: by 10.152.2.100 with SMTP id 4mr26530760lat.6.1414445370371; Mon, 27 Oct 2014 14:29:30 -0700 (PDT) Received: by 10.25.0.6 with HTTP; Mon, 27 Oct 2014 14:29:30 -0700 (PDT) In-Reply-To: <544EA961.2090508@gmx.net> References: <544EA961.2090508@gmx.net> Date: Mon, 27 Oct 2014 17:29:30 -0400 Message-ID: Subject: Re: Mounting ZFS with error 5 failed, since r271963 callout convert From: Ryan Stone To: Michael Schmiedgen Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 21:29:33 -0000 On Mon, Oct 27, 2014 at 4:21 PM, Michael Schmiedgen wrote: > Hi List, > > my ZFS does not mount. I bifurcated to r271963 that > does not work anymore. The commit seems not directly > related to ZFS, but is rather a conversion from timeout(9) > to callout(9). > > After booting the kernel it drops to the mount prompt, > stating that ZFS cannot be mounted because of 'error 5'. > > Any hints? Can I provide some more information? > > Thanks, > Michael The changes to the 3 files there look to be independent, so can you narrow this down further by applying the patch to only a single file? Of those three only ACPI looks like it could affect ZFS or disks, so this will be the patch to try first: https://svnweb.freebsd.org/base/head/sys/dev/acpica/acpi.c?view=patch&r1=271889&r2=271963&pathrev=271963 If you can get a verbose boot log from the machine that would be helpful, but you'd need a serial console to capture that. From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 21:51:00 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06E7AE5D; Mon, 27 Oct 2014 21:50:59 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A2D409C0; Mon, 27 Oct 2014 21:50:59 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s9RLowte075571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 14:50:58 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s9RLowHq075570; Mon, 27 Oct 2014 14:50:58 -0700 (PDT) (envelope-from jmg) Date: Mon, 27 Oct 2014 14:50:58 -0700 From: John-Mark Gurney To: freebsd-testing@FreeBSD.org Subject: issues w/ installing stuff multiple times... Message-ID: <20141027215058.GN82214@funkthat.com> Mail-Followup-To: freebsd-testing@FreeBSD.org, current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 27 Oct 2014 14:50:58 -0700 (PDT) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 21:51:00 -0000 There are issues w/ installing tests where the test files get installed multiple times. To reproduce this, use the following steps: make installworld -j 8 DESTDIR= -DNO_ROOT Once you have done the above, in there will be the file METALOG, run: grep -v type=dir /METALOG | awk '{ print $1 }' | sort | uniq -d This will print out the current list if files that get installed multiple times.... Currently, it looks like all the tests subdirs are installed a second time... Could someone look at making it so that they don't get installed multiple times? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 21:55:11 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FC51161; Mon, 27 Oct 2014 21:55:11 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F5ADA84; Mon, 27 Oct 2014 21:55:11 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id eu11so6317086pac.30 for ; Mon, 27 Oct 2014 14:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=UoSs3NeILJoGF31mXN0WJtxfAeuBVf20wkGVM/KPKMY=; b=jIugk8KTMjkPruL8e3ps3A96jJehuiXpGlEAnHhuCDh5Z5a32ucxi3a6BiVCANdowg LIY+WfMioIf3x23nOT8m4kWKgZOsm1ZLTiKA2JxQuTEyLx0vkb+cV/X7NdqLcheomp8I BUZXQAOSkxx0Swz5crs5uQaAZk6eggCsWuvFoatSviwf06+AQ+e1Cz3tUC4Q9C+yAgSj jD8mkcmS9531agtXHQjih+AllcW/c5TrJn5k9aL0tIGovJ1bbkjDX2cQ42SNTXL1/UyH To4rlDb6eMuRVUaeLep4WfVLyl3Y4sxCUQg7xXvKtTU1A7DSL+Kbb+K8ap9tvqONMJBr VmJg== X-Received: by 10.66.228.35 with SMTP id sf3mr26682190pac.110.1414446910542; Mon, 27 Oct 2014 14:55:10 -0700 (PDT) Received: from [192.168.242.55] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id x7sm11749639pdj.36.2014.10.27.14.55.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:55:09 -0700 (PDT) References: <20141027215058.GN82214@funkthat.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20141027215058.GN82214@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: issues w/ installing stuff multiple times... Date: Mon, 27 Oct 2014 14:55:09 -0700 To: John-Mark Gurney Cc: "freebsd-testing@FreeBSD.org" , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 21:55:11 -0000 > On Oct 27, 2014, at 14:50, John-Mark Gurney wrote: >=20 > There are issues w/ installing tests where the test files get installed > multiple times. >=20 > To reproduce this, use the following steps: > make installworld -j 8 DESTDIR=3D -DNO_ROOT >=20 > Once you have done the above, in there will be the file > METALOG, run: > grep -v type=3Ddir /METALOG | awk '{ print $1 }' | sort | un= iq -d >=20 > This will print out the current list if files that get installed multiple > times.... >=20 > Currently, it looks like all the tests subdirs are installed a second > time... >=20 > Could someone look at making it so that they don't get installed > multiple times? Hi jmg! I have a patch out for this that I need to commit today. Thank you for t= he reminder. Cheers!= From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 22:10:49 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AE70593; Mon, 27 Oct 2014 22:10:49 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 04751BC7; Mon, 27 Oct 2014 22:10:48 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 5BEE15A9F29; Mon, 27 Oct 2014 22:10:48 +0000 (UTC) Date: Mon, 27 Oct 2014 22:10:48 +0000 From: Brooks Davis To: Garrett Cooper Subject: Re: issues w/ installing stuff multiple times... Message-ID: <20141027221048.GF59119@spindle.one-eyed-alien.net> References: <20141027215058.GN82214@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="11Y7aswkeuHtSBEs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-testing@FreeBSD.org" , John-Mark Gurney , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 22:10:49 -0000 --11Y7aswkeuHtSBEs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 27, 2014 at 02:55:09PM -0700, Garrett Cooper wrote: >=20 > > On Oct 27, 2014, at 14:50, John-Mark Gurney wrote: > >=20 > > There are issues w/ installing tests where the test files get installed > > multiple times. > >=20 > > To reproduce this, use the following steps: > > make installworld -j 8 DESTDIR=3D -DNO_ROOT > >=20 > > Once you have done the above, in there will be the file > > METALOG, run: > > grep -v type=3Ddir /METALOG | awk '{ print $1 }' | sort |= uniq -d > >=20 > > This will print out the current list if files that get installed multip= le > > times.... > >=20 > > Currently, it looks like all the tests subdirs are installed a second > > time... > >=20 > > Could someone look at making it so that they don't get installed > > multiple times? >=20 > Hi jmg! > I have a patch out for this that I need to commit today. Thank you fo= r the reminder. Great to hear this will be fixed. Once we've fixed them all, it would be really good to have a test in Jenkins looking out for new duplicate files since they are always bugs. -- Brooks --11Y7aswkeuHtSBEs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlROwucACgkQXY6L6fI4GtSsTQCg1n09XFf1wBXxJbfcQkidIsGm YL4An07FfBIdexR14oYGbG/YPU2mzRbX =CFgn -----END PGP SIGNATURE----- --11Y7aswkeuHtSBEs-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 22:46:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A087622D for ; Mon, 27 Oct 2014 22:46:27 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37860F7A for ; Mon, 27 Oct 2014 22:46:26 +0000 (UTC) Received: from pluto.sol.local ([188.102.183.116]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MSp1l-1XZEQ03pZt-00Rpqp; Mon, 27 Oct 2014 23:46:18 +0100 Message-ID: <544ECB39.1000507@gmx.net> Date: Mon, 27 Oct 2014 23:46:17 +0100 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ryan Stone Subject: Re: Mounting ZFS with error 5 failed, since r271963 callout convert References: <544EA961.2090508@gmx.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UdiIOsQeGpHTIV7Co7a5ylMJm9+f0Q4SskUN1OAuKM1Me62O5SN ATnS/YcpAxqzjTQLhK+6KoaAGcfwxOEL4GS6wtRKkmpfVIluU5yhOI47YYNIji6WN4947yQ XI5aeuebVGtbIi51ApSDwrKNm3AVF0q9K/XePRKjaVuQEyxEapbsynQX8SPtk4/xzngxmpO TcQMCyHjkcVMXV3WVGPnQ== X-UI-Out-Filterresults: notjunk:1; Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 22:46:27 -0000 On 10/27/2014 22:29, Ryan Stone wrote: > On Mon, Oct 27, 2014 at 4:21 PM, Michael Schmiedgen wrote: >> Hi List, >> >> my ZFS does not mount. I bifurcated to r271963 that >> does not work anymore. The commit seems not directly >> related to ZFS, but is rather a conversion from timeout(9) >> to callout(9). >> >> After booting the kernel it drops to the mount prompt, >> stating that ZFS cannot be mounted because of 'error 5'. >> >> Any hints? Can I provide some more information? >> >> Thanks, >> Michael > > The changes to the 3 files there look to be independent, so can you > narrow this down further by applying the patch to only a single file? > Of those three only ACPI looks like it could affect ZFS or disks, so > this will be the patch to try first: > > https://svnweb.freebsd.org/base/head/sys/dev/acpica/acpi.c?view=patch&r1=271889&r2=271963&pathrev=271963 > > If you can get a verbose boot log from the machine that would be > helpful, but you'd need a serial console to capture that. > I applied first acpi.c, then atkbd.c and at last kern_cons.c that triggered the error. https://svnweb.freebsd.org/base/head/sys/kern/kern_cons.c?r1=271963&r2=271962&pathrev=271963 In previous months I had already the same problem with ZFS if nvidia driver was loaded via /boot/loader.conf. It triggered the same error. So I loaded the driver on demand with kldload after login and everything (X + stuff) worked fine. Very strange... Does anyone have a clue what is going on here? Thanks, Michael From owner-freebsd-current@FreeBSD.ORG Mon Oct 27 22:47:34 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F273A337; Mon, 27 Oct 2014 22:47:33 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B32CBF90; Mon, 27 Oct 2014 22:47:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s9RMlW16076294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 15:47:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s9RMlWXQ076293; Mon, 27 Oct 2014 15:47:32 -0700 (PDT) (envelope-from jmg) Date: Mon, 27 Oct 2014 15:47:32 -0700 From: John-Mark Gurney To: Brooks Davis Subject: Re: issues w/ installing stuff multiple times... Message-ID: <20141027224732.GP82214@funkthat.com> Mail-Followup-To: Brooks Davis , Garrett Cooper , "freebsd-testing@FreeBSD.org" , "current@FreeBSD.org" References: <20141027215058.GN82214@funkthat.com> <20141027221048.GF59119@spindle.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141027221048.GF59119@spindle.one-eyed-alien.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 27 Oct 2014 15:47:32 -0700 (PDT) Cc: "freebsd-testing@FreeBSD.org" , "current@FreeBSD.org" , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Oct 2014 22:47:34 -0000 Brooks Davis wrote this message on Mon, Oct 27, 2014 at 22:10 +0000: > On Mon, Oct 27, 2014 at 02:55:09PM -0700, Garrett Cooper wrote: > > > > > On Oct 27, 2014, at 14:50, John-Mark Gurney wrote: > > > > > > There are issues w/ installing tests where the test files get installed > > > multiple times. > > > > > > To reproduce this, use the following steps: > > > make installworld -j 8 DESTDIR= -DNO_ROOT > > > > > > Once you have done the above, in there will be the file > > > METALOG, run: > > > grep -v type=dir /METALOG | awk '{ print $1 }' | sort | uniq -d > > > > > > This will print out the current list if files that get installed multiple > > > times.... > > > > > > Currently, it looks like all the tests subdirs are installed a second > > > time... > > > > > > Could someone look at making it so that they don't get installed > > > multiple times? > > > > Hi jmg! > > I have a patch out for this that I need to commit today. Thank you for the reminder. > > Great to hear this will be fixed. Once we've fixed them all, it would be > really good to have a test in Jenkins looking out for new duplicate files > since they are always bugs. I agree.... I've given the meat of the test above... Any output from that pipeline means that there is a bug... Also, it'd be good if Jenkins would do an installworld in addition to a buildworld... We've recently had breakages that are only uncovered when installworld is done... Current items (other than tests) installed multiple times: /etc/mail/mailer.conf /usr/libdata/pkgconfig/* various man pages: nvlist_freef, various loader So, shouldn't be too much work to knock the rest out... If someone adds the jenkins test, I'll fix the remaining issues (others are free to fix these too)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 10:31:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62468E33 for ; Tue, 28 Oct 2014 10:31:00 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C48EC678 for ; Tue, 28 Oct 2014 10:30:59 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9SAUtY2049405 for ; Tue, 28 Oct 2014 11:30:55 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 1524237B7; Tue, 28 Oct 2014 11:30:55 +0100 (CET) Message-ID: <544F7059.6010608@omnilan.de> Date: Tue, 28 Oct 2014 11:30:49 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: missing nullmailer feature in dma(8)/dmagent X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D87A46BCDA3C1C5A752BAB4" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 28 Oct 2014 11:30:55 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 10:31:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D87A46BCDA3C1C5A752BAB4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I haven't found a way to instruct dma(8) to also forward unqualified recipients to the relayhost. It always delivers unqualified addresses locally (if not translated by "aliases"). ssmtp(8) provides an option to define a recipient address for all local recipients who's ID is <1000. nullmailer(7) does exactly what I want, it doesn't care about the host part of the recipient address, it just passes it over. I'm missing an option for dma(8), which disables local delivery completely, or like ssmtp, optionally only for ids <1000 resp. not existing local users. Why?: Maintaining aliases at each machine is too expensive. My aim is that any operator or daemon of any (human-users-less) machine can simply drop mails to 'chief' or 'root' or 'monitor'. Then there are MSAs (I don't call them mailhub, in my world a mailhub stores email, which often is called a "mailhost"), and only these MSAs care about recipient aliasing and delivery to mailhub or relayhost. With that setup I have exactly one (resp. each redundant MSA) place to maintain aliases and/or other forwarding rules/mailertables etc. Since most smtp-agent implementations handle multiple A records =E2=80=93 although I haven't fo= und one which evaluates MX records =E2=80=93 and I have more than one MSA, I can = pretty reliably guaranteee that any failing machine/device/daemon can drop a note which won't get lost. If I did aliasing on the mailhub instead at the interposed MSA, I'd loose poor mans' redundancy=E2=80=A6 According to dma(8) on 11-current, it's the same like in ports (mail/dma), which I used for testing. I like the decision to replace sendmail, since almost any time in the past when I really needed to use the fullfeatured MTA capabilities, I had to replace base sendmail with a SASL extended version=E2=80=A6 But I'd still need to spread nullmailer(7) with current's dma featrues in 11. Thanks, -Harry --------------enig3D87A46BCDA3C1C5A752BAB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRPcF4ACgkQLDqVQ9VXb8j0awCgjiGQu5lx2HPwrzazQqc5QKA0 Jn0An2GS7H8lgTNbQhsNiUNu6ARWSili =dtY0 -----END PGP SIGNATURE----- --------------enig3D87A46BCDA3C1C5A752BAB4-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 16:21:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FB933C4; Tue, 28 Oct 2014 16:21:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 246CD20F; Tue, 28 Oct 2014 16:21:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D12C8B984; Tue, 28 Oct 2014 12:21:06 -0400 (EDT) From: John Baldwin To: Rick Macklem Subject: Re: RFC: getting rid of oldnfs Date: Tue, 28 Oct 2014 11:47:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1773502329.7493477.1414275856279.JavaMail.root@uoguelph.ca> In-Reply-To: <1773502329.7493477.1414275856279.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201410281147.12525.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Oct 2014 12:21:06 -0400 (EDT) Cc: Konstantin Belousov , freebsd-current , Robert Watson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 16:21:09 -0000 On Saturday, October 25, 2014 6:24:16 pm Rick Macklem wrote: > Kostik wrote: > > On Fri, Oct 24, 2014 at 04:43:28PM +0100, Robert Watson wrote: > > > On Thu, 23 Oct 2014, Rick Macklem wrote: > > > > > > > Someone just pinged me on this and I figured I should bring it > > > > up. > > > > > > > > 1 - Is anyone out there still using oldnfs due to unresolved > > > > problems with the new one? (I am not aware of any outstanding > > > > issues in the new nfs that don't exist in the oldnfs.) > > > > 2 - Does anyone see a problem with getting rid of oldnfs for > > > > FreebSD-11? > > > > 3 - If I get rid of it in -head, I can do it either in > > > > mid-December > > > > or mid-April. (I can't do commits during the winter.) > > > > Does anyone have a rough idea when the 11.0 release cycle will > > > > start, so I can choose which of the above would be preferable? > > > > (I figured I'd wait until after the last 10.n release that > > > > happens > > > > before 11.0, since it will be easier to MFC before the > > > > removal of > > > > oldnfs.) > > > > > > > > Thanks in advance for any comments, rick > > > > ps: John, I've cc'd you since I thought you are the guy most > > > > likely to > > > > need to do commits/MFCs to oldnfs. > > > > > > I think removing it is fine, but as early as possible (as John > > > says) to give > > > our -CURRENT users time to stop working around bugs and start > > > reporting them > > > :-). > > > > I remember the main reason for keeping oldnfs, both server and > > client, > > around in HEAD was to facilitate MFC of fixes to the branches which > > still use oldnfs, i.e. stable/8. If this reason is still valid, > > oldnfs > > have to stay in HEAD till stable/8 is supported or interested for > > developers. > > > > I usually do not like direct commits into the stable branches. > > Otherwise, I see no reason to keep oldnfs around. > > > Well, the only commits I've done to "old" were bugfixes that applied > to both old and new. > > John has been the main "fix the old NFS" guy lately. So, John, do you > anticipate more patches to the old NFS that need to be MFC'd down? I do not, no. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 15:11:53 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FB75E17 for ; Tue, 28 Oct 2014 15:11:53 +0000 (UTC) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 394CE9E6 for ; Tue, 28 Oct 2014 15:11:52 +0000 (UTC) X_CMAE_Category: , , X-CNFS-Analysis: v=2.0 cv=NupTgrhJ c=1 sm=1 a=60v6UuX1j5Kr1+jwqVp4LA==:17 a=L9H7d07YOLsA:10 a=kj9zAlcOel0A:10 a=sIt-5M63AAAA:8 a=h8q0AbzJTnsl8VEo-NwA:9 a=CjuIK1q_8ugA:10 a=1p8otL-nuPoA:10 a=2CpXIMWgOcYA:10 a=uoym9oCq25cA:10 a=60v6UuX1j5Kr1+jwqVp4LA==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.39.248 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.39.248] ([209.6.39.248:54876] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTP id CF/35-47743-232BF445; Tue, 28 Oct 2014 11:11:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21583.45618.148583.732742@jerusalem.litteratus.org> Date: Tue, 28 Oct 2014 11:11:46 -0400 To: Ian Lepore Subject: Re: can't build CURRENT/amd64 using 9.3? In-Reply-To: <1414252396.12052.643.camel@revolution.hippie.lan> References: <1414252396.12052.643.camel@revolution.hippie.lan> X-Mailer: VM 8.2.0b under 24.3.1 (amd64-portbld-freebsd10.1) X-Mailman-Approved-At: Tue, 28 Oct 2014 16:40:07 +0000 Cc: roberthuff@rcn.com, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 15:11:53 -0000 Fixed by scrubbing 9.3 and installing 10.1-RC3, which solved a couple of other issues. Respectfully, Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 16:44:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C940F38 for ; Tue, 28 Oct 2014 16:44:22 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 021306AD for ; Tue, 28 Oct 2014 16:44:21 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so2198666wib.13 for ; Tue, 28 Oct 2014 09:44:20 -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=7jVVCXL+Ouw+fEp7Z1igJeihxvQ/nTXKH+VNKul3Nt0=; b=YTPTbvJw1bXBqltCGhUVCeqsKKTpEObp6Endkz1tzqLpOLGCUEiVOrsTzfjjklaKqd g1hK0CmnsfxGVC+aSGY9RkJluNZODEeadpEo5txVXBF2rt6SvNqRAT/rpJZ4r9jVAg8i RXgVy0JGmSlKbBNwRxRZIdwVzwM0/bt3XY3mo2NqyLo4CV6H7htJSFSeYVdJvLN53q+G enRmpwG0KVw6i6zhyQTyoDfpJKPz2xqMqvMrSIgyWsvLcpMDEw4zZPfV1lhXp+5uhd7n nk1Fy8d35ppfFTBvC1x0mNLFYYf+M1iBtdNvVm999lq3qv+AktRGHfxBQ420LcXzfNcZ FcrQ== X-Received: by 10.194.184.12 with SMTP id eq12mr5967464wjc.100.1414514660138; Tue, 28 Oct 2014 09:44:20 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id pn4sm2395322wjc.38.2014.10.28.09.44.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 09:44:19 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 28 Oct 2014 17:44:17 +0100 From: Baptiste Daroussin To: Harald Schmalzbauer Subject: Re: missing nullmailer feature in dma(8)/dmagent Message-ID: <20141028164417.GE26796@ivaldir.etoilebsd.net> References: <544F7059.6010608@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN" Content-Disposition: inline In-Reply-To: <544F7059.6010608@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 16:44:22 -0000 --DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 11:30:49AM +0100, Harald Schmalzbauer wrote: > Hello, >=20 > I haven't found a way to instruct dma(8) to also forward unqualified > recipients to the relayhost. It always delivers unqualified addresses > locally (if not translated by "aliases"). >=20 > ssmtp(8) provides an option to define a recipient address for all local > recipients who's ID is <1000. > nullmailer(7) does exactly what I want, it doesn't care about the host > part of the recipient address, it just passes it over. >=20 > I'm missing an option for dma(8), which disables local delivery > completely, or like ssmtp, optionally only for ids <1000 resp. not > existing local users. >=20 > Why?: > Maintaining aliases at each machine is too expensive. > My aim is that any operator or daemon of any (human-users-less) machine > can simply drop mails to 'chief' or 'root' or 'monitor'. Then there are > MSAs (I don't call them mailhub, in my world a mailhub stores email, > which often is called a "mailhost"), and only these MSAs care about > recipient aliasing and delivery to mailhub or relayhost. With that setup > I have exactly one (resp. each redundant MSA) place to maintain aliases > and/or other forwarding rules/mailertables etc. Since most smtp-agent > implementations handle multiple A records =E2=80=93 although I haven't fo= und one > which evaluates MX records =E2=80=93 and I have more than one MSA, I can = pretty > reliably guaranteee that any failing machine/device/daemon can drop a > note which won't get lost. If I did aliasing on the mailhub instead at > the interposed MSA, I'd loose poor mans' redundancy=E2=80=A6 >=20 > According to dma(8) on 11-current, it's the same like in ports > (mail/dma), which I used for testing. > I like the decision to replace sendmail, since almost any time in the > past when I really needed to use the fullfeatured MTA capabilities, I > had to replace base sendmail with a SASL extended version=E2=80=A6 > But I'd still need to spread nullmailer(7) with current's dma featrues > in 11. >=20 The NULLCLIENT feature should exactly be what you are looking for, no? As written in the manpage: ---- Bypass aliases and local delivery, and instead forward all mails to the defined `SMARTHOST'. `NULLCLIENT' requires `SMARTHOST' to be set. ---- regards, Bapt --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRPx+EACgkQ8kTtMUmk6EyUsgCgmHSB/x/qhzZvg45BM6AxNiuV 7V4An3p4bFe+PlBhQgQuGDzTtz/FDYbZ =cnlz -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 16:54:11 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74696300; Tue, 28 Oct 2014 16:54:11 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1B0A82B; Tue, 28 Oct 2014 16:54:10 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9SGs7Al054455; Tue, 28 Oct 2014 17:54:07 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 4205B3880; Tue, 28 Oct 2014 17:54:07 +0100 (CET) Message-ID: <544FCA29.8080303@omnilan.de> Date: Tue, 28 Oct 2014 17:54:01 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: missing nullmailer feature in dma(8)/dmagent References: <544F7059.6010608@omnilan.de> <20141028164417.GE26796@ivaldir.etoilebsd.net> In-Reply-To: <20141028164417.GE26796@ivaldir.etoilebsd.net> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig11CCF63A8037037456DF9B73" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 28 Oct 2014 17:54:07 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 16:54:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig11CCF63A8037037456DF9B73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (loca= ltime): =E2=80=A6 > The NULLCLIENT feature should exactly be what you are looking for, no? > As written in the manpage: > > ---- > Bypass aliases and local delivery, and instead forward all mails to > the defined `SMARTHOST'. `NULLCLIENT' requires `SMARTHOST' to be > set. > ---- Doh=E2=80=A6 should try harder getting more sleep ;-) Sorry for the noise, seems indeed to be exactly what I was looking for. Can't explain why I missed that, thanks! -Harry --------------enig11CCF63A8037037456DF9B73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRPyi4ACgkQLDqVQ9VXb8jfTACgi+xKRgbOIZ9PJKD6Bo31/Y7g cP0AoKRATLDCUCvzy4iWvgyXeTEk92Jy =gwya -----END PGP SIGNATURE----- --------------enig11CCF63A8037037456DF9B73-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 18:26:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D80FCE3A; Tue, 28 Oct 2014 18:26:29 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B060321D; Tue, 28 Oct 2014 18:26:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 27419B96E; Tue, 28 Oct 2014 14:26:28 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: junior kernel tasks Date: Tue, 28 Oct 2014 13:21:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141025204536.GD19066@dft-labs.eu> In-Reply-To: <20141025204536.GD19066@dft-labs.eu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201410281321.31986.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Oct 2014 14:26:28 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Mateusz Guzik , bugmeister@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 18:26:29 -0000 On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" Even though our bugmeisters have decided that we should not have wishlist items in our bug tracker, I really wish we could store the various idea lists (we have several) in an issue tracker instead. This would allow for folks to comment on ideas, vote for them, etc. It would also make it easier for more people to submit new ideas. It also provides a better place to store metadata about the issue itself (wikis are kind of poor for that). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 18:26:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3435A9A for ; Tue, 28 Oct 2014 18:26:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A576228 for ; Tue, 28 Oct 2014 18:26:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0A13B980; Tue, 28 Oct 2014 14:26:37 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Mounting ZFS with error 5 failed, since r271963 callout convert Date: Tue, 28 Oct 2014 13:28:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <544EA961.2090508@gmx.net> <544ECB39.1000507@gmx.net> In-Reply-To: <544ECB39.1000507@gmx.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201410281328.21798.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Oct 2014 14:26:38 -0400 (EDT) Cc: Ryan Stone , Michael Schmiedgen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 18:26:39 -0000 On Monday, October 27, 2014 6:46:17 pm Michael Schmiedgen wrote: > On 10/27/2014 22:29, Ryan Stone wrote: > > On Mon, Oct 27, 2014 at 4:21 PM, Michael Schmiedgen wrote: > >> Hi List, > >> > >> my ZFS does not mount. I bifurcated to r271963 that > >> does not work anymore. The commit seems not directly > >> related to ZFS, but is rather a conversion from timeout(9) > >> to callout(9). > >> > >> After booting the kernel it drops to the mount prompt, > >> stating that ZFS cannot be mounted because of 'error 5'. > >> > >> Any hints? Can I provide some more information? > >> > >> Thanks, > >> Michael > > > > The changes to the 3 files there look to be independent, so can you > > narrow this down further by applying the patch to only a single file? > > Of those three only ACPI looks like it could affect ZFS or disks, so > > this will be the patch to try first: > > > > https://svnweb.freebsd.org/base/head/sys/dev/acpica/acpi.c?view=patch&r1=271889&r2=271963&pathrev=271963 > > > > If you can get a verbose boot log from the machine that would be > > helpful, but you'd need a serial console to capture that. > > > > I applied first acpi.c, then atkbd.c and at last kern_cons.c that > triggered the error. > > https://svnweb.freebsd.org/base/head/sys/kern/kern_cons.c?r1=271963&r2=271962&pathrev=271963 > > In previous months I had already the same problem with ZFS if > nvidia driver was loaded via /boot/loader.conf. It triggered > the same error. So I loaded the driver on demand with kldload > after login and everything (X + stuff) worked fine. > > Very strange... > > Does anyone have a clue what is going on here? So not loading the nvidia driver during boot fixed it? That seems odd indeed. Did you recompile the driver after updating? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 20:42:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A339850; Tue, 28 Oct 2014 20:42:11 +0000 (UTC) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E0F03E5; Tue, 28 Oct 2014 20:42:10 +0000 (UTC) Received: from [80.67.16.118] (helo=webmailfront01.ispgateway.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1XjDUE-0003QF-PY; Tue, 28 Oct 2014 21:35:26 +0100 Received: from a89-182-206-145.net-htp.de (a89-182-206-145.net-htp.de [89.182.206.145]) by webmail.df.eu (Horde Framework) with HTTP; Tue, 28 Oct 2014 21:35:26 +0100 Date: Tue, 28 Oct 2014 21:35:26 +0100 Message-ID: <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> From: Marcus von Appen To: John Baldwin Subject: Re: junior kernel tasks References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> In-Reply-To: <201410281321.31986.jhb@freebsd.org> Reply-to: mva@freebsd.org User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: ZnJlZWJzZEBzeXNmYXVsdC5vcmc= Cc: Mateusz Guzik , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, bugmeister@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 20:42:11 -0000 Quoting John Baldwin : > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: >> Hello, >> >> In short, nice kernel tasks people with C language skills can do in few >> evenings. >> >> https://wiki.freebsd.org/JuniorJobs >> >> It is assumed you know how to obtain sources and build the kernel. >> >> What you can get in return: >> - your own code in FreeBSD tree >> - eternal glory [1] >> - fun [2] >> >> If you are not interested, but know someone who does, please pass it >> down. >> >> [1] - not really, no >> [2] - well, I guess that's subjective, so that's not a "no" > > Even though our bugmeisters have decided that we should not have wishlist > items in our bug tracker, I really wish we could store the various idea lists > (we have several) in an issue tracker instead. This would allow for folks to > comment on ideas, vote for them, etc. It would also make it easier for more > people to submit new ideas. > Speaking not strictly with the bugmeister hat, but from experience, please do not let us go down the road of (ab)using a bug tracking solution as task and idea management system. I think that using the tasks feature of phabricator (our reviews instance) would provide better workflow support for those things, starting out from sketching out rough ideas, discussing them, breaking them up in seperate tasks (linked to and dependent on each other) and collaborating on them (take a look at https://developer.blender.org/T42339 for a brief example). Having said this, let's keep the bug tracker a bug tracker. Cheers Marcus From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 22:14:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7E2794E; Tue, 28 Oct 2014 22:14:19 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8E13EEF; Tue, 28 Oct 2014 22:14:18 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id n12so2002208wgh.2 for ; Tue, 28 Oct 2014 15:14:17 -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=BkMvX47UN2mFxPgp6F7+H5NnXxrAeU5v2/a0k81slKE=; b=sAiqoGNYOWCX1xw5sWkcJWek4QZFOv4jQG90F8Sf/OMa+8npGWOthByG2wKEL5OWQk QhNG6Nqd96Kz0c0SKjkYziE2EAhHz6D4F6iip53aB/sZcWc5kz+sVX0PNS7au2OnCsJp EjTB/bdmq9ZqDSVlXiFvMvQ6ALBSX6Q1kj27ubIsVeylKvfi7koJH0X1AvdTI8/Wu4+G 0sPUnhLXObxqcqA8teL6YGiMWihS+6VueoMMhS/QkppydRhsAkl2brKxHQZOKsp3VUs0 d/Or5XCvF2PJzCzDpq3r6tfiafvEHYnc/oGcBEKNud4jGk4Pbj6BNYFTsyzmcp1vsNmi I9QQ== X-Received: by 10.194.123.69 with SMTP id ly5mr7357936wjb.9.1414534456976; Tue, 28 Oct 2014 15:14:16 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id td9sm3583023wic.15.2014.10.28.15.14.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 15:14:15 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 28 Oct 2014 23:14:13 +0100 From: Baptiste Daroussin To: Marcus von Appen Subject: Re: junior kernel tasks Message-ID: <20141028221413.GF26796@ivaldir.etoilebsd.net> References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline In-Reply-To: <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Mateusz Guzik , bugmeister@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 22:14:20 -0000 --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: >=20 > Quoting John Baldwin : >=20 > > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > >> Hello, > >> > >> In short, nice kernel tasks people with C language skills can do in few > >> evenings. > >> > >> https://wiki.freebsd.org/JuniorJobs > >> > >> It is assumed you know how to obtain sources and build the kernel. > >> > >> What you can get in return: > >> - your own code in FreeBSD tree > >> - eternal glory [1] > >> - fun [2] > >> > >> If you are not interested, but know someone who does, please pass it > >> down. > >> > >> [1] - not really, no > >> [2] - well, I guess that's subjective, so that's not a "no" > > > > Even though our bugmeisters have decided that we should not have wishli= st > > items in our bug tracker, I really wish we could store the various idea= lists > > (we have several) in an issue tracker instead. This would allow for fo= lks to > > comment on ideas, vote for them, etc. It would also make it easier for= more > > people to submit new ideas. > > >=20 > Speaking not strictly with the bugmeister hat, but from experience, pleas= e do > not let us go down the road of (ab)using a bug tracking solution as task = and > idea management system. I think that using the tasks feature of phabricat= or > (our reviews instance) would provide better workflow support for those th= ings, > starting out from sketching out rough ideas, discussing them, breaking th= em up > in seperate tasks (linked to and dependent on each other) and collaborati= ng > on them (take a look at https://developer.blender.org/T42339 for a =20 > brief example). >=20 > Having said this, let's keep the bug tracker a bug tracker. >=20 > Cheers > Marcus >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" I disabled the tasks on phabricator to avoid having it a duplicate of bugzi= lla, but if we have a use for it I can activate it! Actually I do like the idea of the bug tracker aka bugzilla being only for = bugs and uxe phabricator for tracking the tasks regards, Bapt --ni93GHxFvA+th69W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQFTUACgkQ8kTtMUmk6Eyb1gCcDkSG6z4tvBjF/wwf4VaJSrNL gsgAn1uQ0po05HWKqbaMoG8HtZDYcrNn =DylX -----END PGP SIGNATURE----- --ni93GHxFvA+th69W-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 22:30:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06601FB1; Tue, 28 Oct 2014 22:30:32 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F2FCE6; Tue, 28 Oct 2014 22:30:31 +0000 (UTC) Received: from pluto.sol.local ([88.74.238.41]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M85r3-1XwuPX0kGv-00vgL8; Tue, 28 Oct 2014 23:30:22 +0100 Message-ID: <545018F9.5020909@gmx.net> Date: Tue, 28 Oct 2014 23:30:17 +0100 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org Subject: Re: Mounting ZFS with error 5 failed, since r271963 callout convert References: <544EA961.2090508@gmx.net> <544ECB39.1000507@gmx.net> <201410281328.21798.jhb@freebsd.org> In-Reply-To: <201410281328.21798.jhb@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1JQGZxAxPFxtBvO1/0W9huAEEjoMVyYR31NN6DJsIWPy/pEj/pp blgE8B9MU8eCii3QIEwr8hCO6ZtjZFqAgOtZkPc+6Bs6xqaKm+eZIIJuLA7h/A30QpBP8mX 1bB5QXGLwYvsmCpht168vAutc2BViRumq/F9GlYIaiFgRaBHVL6z/u4tstE1KnXonOZTeRc YhrCgEyQC5bS544C96/4A== X-UI-Out-Filterresults: notjunk:1; Cc: Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 22:30:32 -0000 >> In previous months I had already the same problem with ZFS if >> nvidia driver was loaded via /boot/loader.conf. It triggered >> the same error. So I loaded the driver on demand with kldload >> after login and everything (X + stuff) worked fine. >> >> Very strange... >> >> Does anyone have a clue what is going on here? > > So not loading the nvidia driver during boot fixed it? That seems odd indeed. > Did you recompile the driver after updating? > The nvidia driver problem started long before r271963. If I update my CURRENT, non base stuff will be deleted and ports will be completly new installed. The nvidia problem persisted some of these cycles before I gave up. I can test if the problem still exists. But now there is a similar problem with applying kern_cons.c in r271963. I do not know whether these two are related. Please let me know if you want to see some configuration or logs or anything. Thanks, Michael From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 22:56:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAA9F508 for ; Tue, 28 Oct 2014 22:56:30 +0000 (UTC) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id 24F9A3B0 for ; Tue, 28 Oct 2014 22:56:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 6E3225BD4F for ; Tue, 28 Oct 2014 23:51:08 +0100 (CET) Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CbxjP3-9EIp5 for ; Tue, 28 Oct 2014 23:51:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 6F7D35BD4E for ; Tue, 28 Oct 2014 23:51:04 +0100 (CET) X-Virus-Scanned: amavisd-new at galore.get.c.bitbit.net Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AZNXNdQuffFW for ; Tue, 28 Oct 2014 23:51:04 +0100 (CET) Received: from onyx.thanelange.no (cm-84.208.179.208.getinternet.no [84.208.179.208]) by galore.getmail.no (Postfix) with ESMTP id 455A65BD49 for ; Tue, 28 Oct 2014 23:51:04 +0100 (CET) Date: Tue, 28 Oct 2014 23:50:11 +0100 From: Gyrd Thane Lange To: freebsd-current@freebsd.org Subject: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Message-ID: <20141028235011.543be3ea@onyx.thanelange.no> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 22:56:30 -0000 Hi! I'm trying to build CURRENT r273800 with an empty (actually nonexisting) /etc/src.conf when it previously had contained: WITHOUT_MODULES=dtrace WITHOUT_CDDL= # uname -a FreeBSD onyx.thanelange.no 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r273066M: Sun Oct 19 20:12:57 CEST 2014 root@onyx.thanelange.no:/usr/obj/usr/src/sys/ONYX amd64 # rm -rf /usr/obj/* # make buildworld buildkernel The world build succeeds fine, but the kernel build fails with: -------------------------------------------------------------- >>> stage 3.2: building everything -------------------------------------------------------------- cd /usr/obj/usr/src/sys/ONYX; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 11.0-CURRENT amd64 1100040" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC="cc " CXX="c++ " DEPFLAGS="" CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" make -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -g -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 -Wno-error-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror /usr/src/sys/amd64/amd64/locore.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -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 -Wno-error-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror /usr/src/sys/cam/cam.c ctfconvert -L VERSION -g cam.o make[2]: exec(ctfconvert) failed (No such file or directory) *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/ONYX *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src # find /usr/src/ /usr/obj -name ctfconvert -type f | xargs ls -l -rwxr-xr-x 1 root wheel 371211 Oct 28 22:06 /usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert This tells me that buildworld succeeded in building the ctfconvert binary, but buildkernel is not picking up the newly built tool. Any advice on getting around this? I would prefer not having to install the new world before building and installing the new kernel. Best regards, Gyrd ^_^ From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 23:01:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7939F867 for ; Tue, 28 Oct 2014 23:01:49 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49AC83F6 for ; Tue, 28 Oct 2014 23:01:48 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjFlm-0007pH-82; Tue, 28 Oct 2014 23:01:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9SN1dCd079326; Tue, 28 Oct 2014 17:01:39 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19aj0uLQnEP5CVM4eztEyyA X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) From: Ian Lepore To: Gyrd Thane Lange In-Reply-To: <20141028235011.543be3ea@onyx.thanelange.no> References: <20141028235011.543be3ea@onyx.thanelange.no> Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Oct 2014 17:01:39 -0600 Message-ID: <1414537299.17308.28.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:01:49 -0000 On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin Do a "make kernel-toolchain" which will build a new ctfconvert and put it in the right place within /usr/obj to be used during buildkernel. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 23:08:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF191A78 for ; Tue, 28 Oct 2014 23:08:03 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C78A6B0 for ; Tue, 28 Oct 2014 23:08:03 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id cs9so1259771qab.23 for ; Tue, 28 Oct 2014 16:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MRAxFpAKZrgNB6SfjtE8ZGfYeohxt9d8LVMU8XHD3x8=; b=C17gBRI3J2gjvSAAwT+kuEquSdp9Za1XbGsSuq0imUXG3ycWUZZwOxKn5ksDDO/wu8 F9+wYvlRuEulMsoaVmRam7kiuFMxn8aLCZCVV2/OEQo3Ajy8EQwe39Rhv/rwXuZJi4fs Ec4boq4CzxKtQIJX9xmBl6FMutZ9JDguapaIY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MRAxFpAKZrgNB6SfjtE8ZGfYeohxt9d8LVMU8XHD3x8=; b=NMEZX+J6dRWrp8T5YqqQfkMf79bUrAPcQlC/w8Xal54gX0TWy1t/TNI5R1bjtWMViV dviGxLxmARa2MsovBKfchJbGDjQk77Eha12b5hKqqTD131WWe/dIQJ78rQzNMWMUNpCE O7W6yc1QzkbEvMdHIUtWgNHor5CYh3kLQ8RSClbRW8FkIUB208GBl73yRmOirZHcp4dI RHg79hIt6J3sv4eYfh0f+6mfNswxauCum0wbcWtKazpnM/yChC2gAct4jlyRIsiF/OSr zcrjE/hnw2WDUAHsM+byN9WwsHMaDJhew+e7v5BtFJptxmvL0ZTH+DSuKrsI1LE2XwVx EbHg== X-Gm-Message-State: ALoCoQnEBioqBwZnIqocwrBmU6bk1gTekvUmGCgZbv49G+dFZcO9MmUD8OjGgJ/NmKRYBMRXNAq5 X-Received: by 10.224.130.71 with SMTP id r7mr9942597qas.69.1414537682143; Tue, 28 Oct 2014 16:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.92.200 with HTTP; Tue, 28 Oct 2014 16:07:31 -0700 (PDT) In-Reply-To: <20141028221413.GF26796@ivaldir.etoilebsd.net> References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> From: Eitan Adler Date: Tue, 28 Oct 2014 16:07:31 -0700 Message-ID: Subject: Re: junior kernel tasks To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Cc: Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:08:03 -0000 On 28 October 2014 15:14, Baptiste Daroussin wrote: > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: >> >> Quoting John Baldwin : >> >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: >> >> Hello, >> >> >> >> In short, nice kernel tasks people with C language skills can do in few >> >> evenings. >> >> >> >> https://wiki.freebsd.org/JuniorJobs >> >> >> >> It is assumed you know how to obtain sources and build the kernel. >> >> >> >> What you can get in return: >> >> - your own code in FreeBSD tree >> >> - eternal glory [1] >> >> - fun [2] >> >> >> >> If you are not interested, but know someone who does, please pass it >> >> down. >> >> >> >> [1] - not really, no >> >> [2] - well, I guess that's subjective, so that's not a "no" >> > >> > Even though our bugmeisters have decided that we should not have wishlist >> > items in our bug tracker, I really wish we could store the various idea lists >> > (we have several) in an issue tracker instead. This would allow for folks to >> > comment on ideas, vote for them, etc. It would also make it easier for more >> > people to submit new ideas. >> > >> >> Speaking not strictly with the bugmeister hat, but from experience, please do >> not let us go down the road of (ab)using a bug tracking solution as task and >> idea management system. I think that using the tasks feature of phabricator >> (our reviews instance) would provide better workflow support for those things, >> starting out from sketching out rough ideas, discussing them, breaking them up >> in seperate tasks (linked to and dependent on each other) and collaborating >> on them (take a look at https://developer.blender.org/T42339 for a >> brief example). >> >> Having said this, let's keep the bug tracker a bug tracker. >> >> Cheers >> Marcus >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, > but if we have a use for it I can activate it! > > Actually I do like the idea of the bug tracker aka bugzilla being only for bugs > and uxe phabricator for tracking the tasks having disparate trackers for "wishlist" and "bugs" is quite harmful and splits the conversations. It makes people learn multiple systems and search multiple places - especially if the feature ends up being submitted as a patch to the bug tracker. I'd rather keep wishlist items in the bug tracker than split them into two. (also, fwiw, I'd rather keep the tasks number space clean should we ever decide to import from bugzilla -> phabricator) -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 23:19:39 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DC6AE5E; Tue, 28 Oct 2014 23:19:39 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C37A980E; Tue, 28 Oct 2014 23:19:38 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so3155338wid.10 for ; Tue, 28 Oct 2014 16:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=3Mm7I2ITub/u8eZNaTKB2ahL0NN/GOKR1JKPPY/7ZO8=; b=G5rKyqbpBBzI1pKNteIL/6XdLjoXETRukSFDykFtvNc6YvATAOq0RYfQ5LSmlLTWya duGVy5CjQ/7rJD9bxY//DgSGaJiCtgYTIjaaBnM6Ujy0/sWVfOwXQYfjevdVuE3m6dK+ QbvAMY0eoYQ/W4AtctbaLtW4rg0Cr3r+hC4U4ysUxiEQ9t2uEmV/ySBDaafcntfR1SBG wQLwMtfN5I/eBUYJsF5U+oMuHa+rUXEli67weGpL/jwU/SvM9c2sTQdPAJb5EtlzUdGa 6na/J4IntV1QMhzLPSEHO3DYrBOYe8tMKGwLh0mOSRJFPZ8cjEc7i/tSL76GLwrrJ3VX 1pcQ== X-Received: by 10.194.93.68 with SMTP id cs4mr4132569wjb.97.1414538377001; Tue, 28 Oct 2014 16:19:37 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id c15sm15052666wib.3.2014.10.28.16.19.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 16:19:35 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 00:19:33 +0100 From: Baptiste Daroussin To: ports@FreeBSD.org, current@FreeBSD.org Subject: pkg 1.4 freeze please test test test! Message-ID: <20141028231933.GG26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:19:39 -0000 --HKEL+t8MFpg/ASTE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, We are starting the release process of pkg 1.4, we want to have a better release process than with every single previous version of pkg. For that we will need you help! pkg-devel has been updated to the latest version of pkg as of alpha2. Changes you can expect in pkg 1.4 are the following: - Loads of bug fixes - Stricter checking of the path passed via the plist - Removal of the bundled libyaml - new --raw-format to chose the output format for info -R and search -R - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64) the old ABI is available as a fallback in ALTABI - pkg check now support a quiet mode - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging configuration files - new @config keyword to mark a file as a config file (during upgrade/reinstallation it will try to merge the configuration with the one the user may have modified) an option AUTOMERGE is available to prevent automerging if automerge fails a .pkgnew file will be created along with the untouched user version of the configuration - The update procedure has been improved and speed up a lot (in particular for machine with low resources) - The unique identifier has been modified to be pkgname meaning now ports can be moved in new categories without having to be considered a different package - Only libraries starting by lib* are added to the provided libraries - General speed up of all operations We need help in testing, but we also need help in writing regression tests ! The more we have tests the more stable the releases will be. The release will also allow to be able to package base! regards, Bapt --HKEL+t8MFpg/ASTE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQJIUACgkQ8kTtMUmk6ExL5QCglJ5Q7XrdTcXfqL23uKihJhLP 3j4AoI9x4WjlPMQyQNuYw2qGoS63sOKb =xEtd -----END PGP SIGNATURE----- --HKEL+t8MFpg/ASTE-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 23:27:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46FBBC4 for ; Tue, 28 Oct 2014 23:27:09 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 07D038DE for ; Tue, 28 Oct 2014 23:27:08 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6C7EF65653 for ; Tue, 28 Oct 2014 23:27:07 +0000 (UTC) Message-ID: <5450264E.5060909@freebsd.org> Date: Tue, 28 Oct 2014 19:27:10 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: pkg 1.4 freeze please test test test! References: <20141028231933.GG26796@ivaldir.etoilebsd.net> In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cK2rrn01vsu8mfLGlfIXAB6PgBocI6eCj" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:27:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cK2rrn01vsu8mfLGlfIXAB6PgBocI6eCj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-28 19:19, Baptiste Daroussin wrote: > Hi all, >=20 > We are starting the release process of pkg 1.4, we want to have a bette= r release > process than with every single previous version of pkg. For that we wil= l need > you help! >=20 > pkg-devel has been updated to the latest version of pkg as of alpha2. >=20 > Changes you can expect in pkg 1.4 are the following: > - Loads of bug fixes > - Stricter checking of the path passed via the plist > - Removal of the bundled libyaml > - new --raw-format to chose the output format for info -R and search -R= > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10= :amd64) > the old ABI is available as a fallback in ALTABI > - pkg check now support a quiet mode > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerg= ing > configuration files > - new @config keyword to mark a file as a config file (during > upgrade/reinstallation it will try to merge the configuration with th= e one the > user may have modified) an option AUTOMERGE is available to prevent > automerging if automerge fails a .pkgnew file will be created along w= ith the > untouched user version of the configuration > - The update procedure has been improved and speed up a lot (in particu= lar for > machine with low resources) > - The unique identifier has been modified to be pkgname meaning now por= ts can be > moved in new categories without having to be considered a different p= ackage > - Only libraries starting by lib* are added to the provided libraries > - General speed up of all operations >=20 > We need help in testing, but we also need help in writing regression te= sts ! > The more we have tests the more stable the releases will be. >=20 > The release will also allow to be able to package base! >=20 > regards, > Bapt >=20 Naming the option 'AUTOMERGE' when it stops the automatic merging, seems like a really bad idea. Either make it AUTOMERGE=3Dfalse or NOAUTHMERGE o= r something. --=20 Allan Jude --cK2rrn01vsu8mfLGlfIXAB6PgBocI6eCj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUUCZRAAoJEJrBFpNRJZKfqIoQALxVEOyPcn3S2wdMB5FutO5/ JGPK+5IhAzIjSvJc8CA59y6R1t/DYDuE/ilxTIRqaoHDkAfg4Ix3VkTgVAa3DhQ5 7h5fYsGRjf76R0edst20U/vx+rNOaNjTlzb8N2GBfVlDCIBCekK3ZdG4EMedUpMR 2h9ZQpVYtiZpnjUCh71MGxDPAeT576ZusEfS3KJpV4dQASPZnnRHm27qWLhxrkl6 8AUllm5tmF2BCak6LkRUn8zXTBfrTxQ9mhgo9CHWS0psrrWJbcfp+b/4oDlluInl LDggmcG4kRxzJ9jPldmVMrEKAPvIn502MPXLJg6gVQ46rHQC1FCVDEojDZMQzVSN 1eiD8oHmJt3Bm0j6JnayRsF2TMvzLEK8bm3FC1M747rdqpdN9w93cIy141ATaQmD 6d3ECszntYplHlEKyhRB9AckyT34I9kZJ8zxCAFO1u+y+bHLDwqw75TftNojGECs InMsaaA9mdgU7KZ4ThnaZ90X016xfCryQqVQZPE6yBMU9B1sGVSdjdln9WXyN0o/ FEcJ7EZ2tOuERoEMzCD/ePaavAwKwVm+uzq5avtpTFXYG1Rr5Y2UI+EzJxFA2Blq a0Q63019WiK96c7MMDcEfwmOWAFDXQ6NzsMXivHXc26X9r93vzlyVkrhzVzfOnpZ LLNhMbI3mCnCKUrR5Joc =/FAW -----END PGP SIGNATURE----- --cK2rrn01vsu8mfLGlfIXAB6PgBocI6eCj-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 23:35:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5912E332; Tue, 28 Oct 2014 23:35:17 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE3459BB; Tue, 28 Oct 2014 23:35:16 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id k14so670557wgh.29 for ; Tue, 28 Oct 2014 16:35:15 -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=70lPYcQWgxG72QlX5Qsu2RMITT64ObJHL90q7EJUWO4=; b=B/WYHtuWEoubXiiaZVPnFCUm9y/ABcH/SFbmVRWT/BNPcp64VvmHkzNIkmEYeI1nrq 03DjKRwdYMta46uXJsqAL5kZCWe8QoVyvuE+RGv4peL5Q/5Spfd54XkbK1mN8+0k+kQ1 iM+p2qTYKCuXPmc7f7loPKivTGizuBsOLjj0r9W5b5+Psbv7vk0dUZdtpwQiy94+xDSB AvHXcWsZP68aZdjSnKP9Vq8VRXrs8pNqtLukLhoi5Ylo65tlRWN0s3eUhmbKcy2W2psf 8Q6E12m9+zHLRblm8B7ponuKBcFHBr1PnKXD+/BQjHg17UsBsdD9CfnXLP1VJJUnMTIw clRQ== X-Received: by 10.194.187.77 with SMTP id fq13mr8430003wjc.14.1414539315016; Tue, 28 Oct 2014 16:35:15 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id lm9sm3349114wjc.45.2014.10.28.16.35.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 16:35:14 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 00:35:11 +0100 From: Baptiste Daroussin To: Allan Jude Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141028233511.GH26796@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <5450264E.5060909@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="poemUeGtc2GQvHuH" Content-Disposition: inline In-Reply-To: <5450264E.5060909@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:35:17 -0000 --poemUeGtc2GQvHuH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 07:27:10PM -0400, Allan Jude wrote: > On 2014-10-28 19:19, Baptiste Daroussin wrote: > > Hi all, > >=20 > > We are starting the release process of pkg 1.4, we want to have a bette= r release > > process than with every single previous version of pkg. For that we wil= l need > > you help! > >=20 > > pkg-devel has been updated to the latest version of pkg as of alpha2. > >=20 > > Changes you can expect in pkg 1.4 are the following: > > - Loads of bug fixes > > - Stricter checking of the path passed via the plist > > - Removal of the bundled libyaml > > - new --raw-format to chose the output format for info -R and search -R > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10= :amd64) > > the old ABI is available as a fallback in ALTABI > > - pkg check now support a quiet mode > > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerg= ing > > configuration files > > - new @config keyword to mark a file as a config file (during > > upgrade/reinstallation it will try to merge the configuration with th= e one the > > user may have modified) an option AUTOMERGE is available to prevent > > automerging if automerge fails a .pkgnew file will be created along w= ith the > > untouched user version of the configuration > > - The update procedure has been improved and speed up a lot (in particu= lar for > > machine with low resources) > > - The unique identifier has been modified to be pkgname meaning now por= ts can be > > moved in new categories without having to be considered a different p= ackage > > - Only libraries starting by lib* are added to the provided libraries > > - General speed up of all operations > >=20 > > We need help in testing, but we also need help in writing regression te= sts ! > > The more we have tests the more stable the releases will be. > >=20 > > The release will also allow to be able to package base! > >=20 > > regards, > > Bapt > >=20 >=20 > Naming the option 'AUTOMERGE' when it stops the automatic merging, seems > like a really bad idea. Either make it AUTOMERGE=3Dfalse or NOAUTHMERGE or > something. The default it automerge: true you have to change it to automerge: false to prevent it to work regards, Bapt --poemUeGtc2GQvHuH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQKC8ACgkQ8kTtMUmk6EwJYACgt6egJvOQZ+qBN4426m5Z/D86 rJoAnAzIZr07FsQTxRT+fmOILvUMRL3r =kKy9 -----END PGP SIGNATURE----- --poemUeGtc2GQvHuH-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 23:36:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E44B9434; Tue, 28 Oct 2014 23:36:19 +0000 (UTC) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF0E9C4; Tue, 28 Oct 2014 23:36:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 0D2CB5BB41; Wed, 29 Oct 2014 00:36:18 +0100 (CET) Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vhJnH2A6k4Qs; Wed, 29 Oct 2014 00:36:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 2642C5AA33; Wed, 29 Oct 2014 00:36:08 +0100 (CET) X-Virus-Scanned: amavisd-new at galore.get.c.bitbit.net Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UfOd1V-YLpH2; Wed, 29 Oct 2014 00:36:08 +0100 (CET) Received: from onyx.thanelange.no (cm-84.208.179.208.getinternet.no [84.208.179.208]) by galore.getmail.no (Postfix) with ESMTP id F41025BB41; Wed, 29 Oct 2014 00:36:07 +0100 (CET) Date: Wed, 29 Oct 2014 00:35:15 +0100 From: Gyrd Thane Lange To: Ian Lepore Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Message-ID: <20141029003515.28e26444@onyx.thanelange.no> In-Reply-To: <1414537299.17308.28.camel@revolution.hippie.lan> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:36:20 -0000 On Tue, 28 Oct 2014 17:01:39 -0600 Ian Lepore wrote: > On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > Do a "make kernel-toolchain" which will build a new ctfconvert and put > it in the right place within /usr/obj to be used during buildkernel. Thanks, I will try this (building now). But if it works I'll be somewhat confused. I thought kernel-toolchain was implicit when doing a full buildworld (which I've already done), and I already have a ctfconvert (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). The problem looks more like buildkernel is ignoring the ctfconvert tool in /usr/obj/ and instead is expecting to find it in /usr/bin (or some such). Gyrd ^_^ > > -- Ian > > > _______________________________________________ > 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 Oct 28 23:45:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C0075AA; Tue, 28 Oct 2014 23:45:48 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC401AA0; Tue, 28 Oct 2014 23:45:47 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id tp5so1876369ieb.22 for ; Tue, 28 Oct 2014 16:45: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:content-transfer-encoding; bh=RHz1vBPJm6BK98wpjUftTro/MEDzYKRpH9A0uY60vGw=; b=pvxBf+FArJEgGzj58112QpN4Zza+7SGqP+b6nJ822BHb6cb8FmjffpeIgJU9E12Cg8 GiAU7m4//lJOI5GBWw/Oy3Z2BhicfzyMeKm+MjXLQx8ISn0r3PezHREvQBIGPb0GM29j WAAuXbaFgo1r1AlnRLAlra9KRL7ybFFFTE2MerhhMstioDuA2Cn+n/6ahORUzAzfnMlb AfVWTmm9SboO2tQUc2ohPxRr3HWjN/xWXgmnAi3iTqTsPtsLJ69Ak+R2MHRTXgrsaY29 0pXCN4NU5Z1CrgojnjgVUPbLvtcOS9jDbZMYUgdw1I6af7zEV44HwLRdXpl5dQGwnMuK r0Dg== MIME-Version: 1.0 X-Received: by 10.42.250.17 with SMTP id mm17mr7139774icb.18.1414539947176; Tue, 28 Oct 2014 16:45:47 -0700 (PDT) Received: by 10.50.193.135 with HTTP; Tue, 28 Oct 2014 16:45:47 -0700 (PDT) In-Reply-To: <20141029003515.28e26444@onyx.thanelange.no> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> Date: Tue, 28 Oct 2014 16:45:47 -0700 Message-ID: Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) From: NGie Cooper To: Gyrd Thane Lange Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Ian Lepore , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:45:48 -0000 On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange w= rote: > On Tue, 28 Oct 2014 17:01:39 -0600 > Ian Lepore wrote: > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: >> > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legac= y/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy= /bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/us= r/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> >> Do a "make kernel-toolchain" which will build a new ctfconvert and put >> it in the right place within /usr/obj to be used during buildkernel. > > Thanks, I will try this (building now). But if it works I'll be somewhat > confused. I thought kernel-toolchain was implicit when doing a full > buildworld (which I've already done), and I already have a ctfconvert > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). > > The problem looks more like buildkernel is ignoring the ctfconvert > tool in /usr/obj/ and instead is expecting to find it in /usr/bin (or > some such). It should be located in /usr/obj -- we should not expect the tool in /usr/bin to be correct/compatible with the source tree. Cheers! From owner-freebsd-current@FreeBSD.ORG Tue Oct 28 23:49:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEB1E6EF for ; Tue, 28 Oct 2014 23:49:49 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 9F091AD3 for ; Tue, 28 Oct 2014 23:49:49 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5E4116574F for ; Tue, 28 Oct 2014 23:49:48 +0000 (UTC) Message-ID: <54502B9E.7050707@freebsd.org> Date: Tue, 28 Oct 2014 19:49:50 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: pkg 1.4 freeze please test test test! References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <5450264E.5060909@freebsd.org> <20141028233511.GH26796@ivaldir.etoilebsd.net> In-Reply-To: <20141028233511.GH26796@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e6RFIiGASVx5dt9NCgmaKOfMCINbouQJM" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 28 Oct 2014 23:49:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e6RFIiGASVx5dt9NCgmaKOfMCINbouQJM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-28 19:35, Baptiste Daroussin wrote: > On Tue, Oct 28, 2014 at 07:27:10PM -0400, Allan Jude wrote: >> On 2014-10-28 19:19, Baptiste Daroussin wrote: >>> Hi all, >>> >>> We are starting the release process of pkg 1.4, we want to have a bet= ter release >>> process than with every single previous version of pkg. For that we w= ill need >>> you help! >>> >>> pkg-devel has been updated to the latest version of pkg as of alpha2.= >>> >>> Changes you can expect in pkg 1.4 are the following: >>> - Loads of bug fixes >>> - Stricter checking of the path passed via the plist >>> - Removal of the bundled libyaml >>> - new --raw-format to chose the output format for info -R and search = -R >>> - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:= 10:amd64) >>> the old ABI is available as a fallback in ALTABI >>> - pkg check now support a quiet mode >>> - new 3 way merge code ("stolen" from the fossil-scm) to allow autome= rging >>> configuration files >>> - new @config keyword to mark a file as a config file (during >>> upgrade/reinstallation it will try to merge the configuration with = the one the >>> user may have modified) an option AUTOMERGE is available to prevent= >>> automerging if automerge fails a .pkgnew file will be created along= with the >>> untouched user version of the configuration >>> - The update procedure has been improved and speed up a lot (in parti= cular for >>> machine with low resources) >>> - The unique identifier has been modified to be pkgname meaning now p= orts can be >>> moved in new categories without having to be considered a different= package >>> - Only libraries starting by lib* are added to the provided libraries= >>> - General speed up of all operations >>> >>> We need help in testing, but we also need help in writing regression = tests ! >>> The more we have tests the more stable the releases will be. >>> >>> The release will also allow to be able to package base! >>> >>> regards, >>> Bapt >>> >> >> Naming the option 'AUTOMERGE' when it stops the automatic merging, see= ms >> like a really bad idea. Either make it AUTOMERGE=3Dfalse or NOAUTHMERG= E or >> something. >=20 > The default it automerge: true you have to change it to automerge: fals= e to > prevent it to work >=20 > regards, > Bapt >=20 Right, that makes sense, thank you. --=20 Allan Jude --e6RFIiGASVx5dt9NCgmaKOfMCINbouQJM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUUCuiAAoJEJrBFpNRJZKfzgAP/iuMoBO63Jcn3jTB/yh5lcf0 FHprLVkDh+QBT+8MroSUzanJjJ4FCZoNWiulrw2vuaYi23v3PG3WZsGoQNZGok1B 2Z0RxMKHi/g/cQmrBLbUGjqI4oqUwp4HvPmfPe5bCDS7dx9SHkCj/XehL762W9pB 2J+hZ3OvGG8KzjGQewLcvML3nyf5v5as6fDkKmVqNlO243wVr2tVusagHMWcVZIR B9RZr1RJwrs/ixUfc2nL7La2T/mlFPWjaFCNILvHpPRRxzEeZ2i7gMyJtX+7I/4H BsNYchl9DtCHZQFojM5Hy99/+e4LFXhstqiZVZtFLNYNIRRdZP6T+E2Y3LHmENid m0beIUljCC61MvpKJtE+EDAGx7mmu7y7V0PlVv3cRSmtYdgiMpZZQUZZKidumlVQ th9kDIWzQCLycp4d5kJpWJQF2i7XAf9/Zw0/pHTWLVvPVCZdxd8TM1pArXvJrMje N5XcexKpRVj/vXZD6iWBqPhXHjlY/SYw5ciwSf5RIpdjEHOeqWw3qqHS/M7aTgTA ED/jlaPNqcjWPf+NfeTL24QqZU3z1EbRzP2M6PdlxKfURxSSkzj11ylXbWklN/TK FZLa1BIt9DaG7AGy+/BXBxpAhBbT0QPW2ux+OanFeJ+6+wA5j8v/XXB75/wDGHzO 5AH41ge7A8QISSC4cINN =Tzkp -----END PGP SIGNATURE----- --e6RFIiGASVx5dt9NCgmaKOfMCINbouQJM-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 00:21:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7B03C6E for ; Wed, 29 Oct 2014 00:21:01 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B09DFDA7 for ; Wed, 29 Oct 2014 00:21:01 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id r10so289692igi.6 for ; Tue, 28 Oct 2014 17:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=0l9VTBEisvMjh9mEDNiBXihiYFyG+eBYUi9AJOtfPTI=; b=fUtF2yB63ZGU/IZ7y1TI98q6bzmTVQP9V5pTW4GAdGDDsdQsLEJpZVngmtdFY3XY4m 0/V+H0uvSLiESDH5BIpuvI+uotgo9Ri6SBn3Xw/mIGQJriiCWz04d9TzWgjddxhz60bq rlgbC/mvCaKyUWQqQHqwRr4pkSq0E96MkfoBOUww4e44C1OubWr9X2uMprUXyncKfs7b cjvZTm0v2CHpseJLBpn2jRfQ+3Zb4QN6WLouxSCoOsUNudUNqQnadm1lNj9fW7OKevZl nGymqfjYRWoP7IICx46fTA9aBBgZzJpudABgR+JcHrFnzq/LHVHVeyiUh5g0K1u2e66w t2Og== X-Received: by 10.43.144.131 with SMTP id jq3mr6084290icc.66.1414542061159; Tue, 28 Oct 2014 17:21:01 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.132 with HTTP; Tue, 28 Oct 2014 17:20:40 -0700 (PDT) From: Ed Maste Date: Tue, 28 Oct 2014 20:20:40 -0400 X-Google-Sender-Auth: Z3mY2ZIMxe6X9vRsyCW3s-IJY0E Message-ID: Subject: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 00:21:02 -0000 I am preparing to move the standalone kernel debug data out of /boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach used for userland debug data. This significantly reduces the boot partition size requirement, and is a step towards supporting the installation of kernel debug data ony when required. LLDB and GDB automatically search for debug data under /usr/lib/debug/ so this change should be transparent from an end-user perspective. The change can be reviewed in Phabricator at https://reviews.freebsd.org/D1006 and can be fetched as a unified diff from https://people.freebsd.org/~emaste/patches/D1006.diff This does not change any defaults or knobs: kernel debug files are still built by default, and may be disabled by setting WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize this with userland debug in a later step. Note that the change renames the intermediate and debug data files to be consistent with userland debug data: in the build directory the kernel with debug data included is now named kernel.full, and and kernel.debug is the standalone debug data file. I plan to merge this in a few days if there are no issues reported in further review or testing. -Ed From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 00:25:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FA67DBA; Wed, 29 Oct 2014 00:25:40 +0000 (UTC) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id 44FFCE5C; Wed, 29 Oct 2014 00:25:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 1A91343A39; Wed, 29 Oct 2014 01:25:30 +0100 (CET) Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JKU-DvIPaSKY; Wed, 29 Oct 2014 01:25:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 9746B43A6E; Wed, 29 Oct 2014 01:25:25 +0100 (CET) X-Virus-Scanned: amavisd-new at galore.get.c.bitbit.net Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BGapKRhy8kwQ; Wed, 29 Oct 2014 01:25:25 +0100 (CET) Received: from onyx.thanelange.no (cm-84.208.179.208.getinternet.no [84.208.179.208]) by galore.getmail.no (Postfix) with ESMTP id 6C46343A39; Wed, 29 Oct 2014 01:25:25 +0100 (CET) Date: Wed, 29 Oct 2014 01:24:32 +0100 From: Gyrd Thane Lange To: NGie Cooper Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Message-ID: <20141029012432.41e22c7a@onyx.thanelange.no> In-Reply-To: References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Ian Lepore , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 00:25:40 -0000 On Tue, 28 Oct 2014 16:45:47 -0700 NGie Cooper wrote: > On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange > wrote: > > On Tue, 28 Oct 2014 17:01:39 -0600 > > Ian Lepore wrote: > > > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > >> > >> Do a "make kernel-toolchain" which will build a new ctfconvert and > >> put it in the right place within /usr/obj to be used during > >> buildkernel. > > > > Thanks, I will try this (building now). But if it works I'll be > > somewhat confused. I thought kernel-toolchain was implicit when > > doing a full buildworld (which I've already done), and I already > > have a ctfconvert > > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). Finished a make kernel-toolchain (but it left me with even less binaries than make buildworld): # find /usr/src/ /usr/obj -name ctfconvert -type f (nothing found) > > The problem looks more like buildkernel is ignoring the ctfconvert > > tool in /usr/obj/ and instead is expecting to find it in /usr/bin > > (or some such). > > It should be located in /usr/obj -- we should not expect the tool > in /usr/bin to be correct/compatible with the source tree. I agree. :) while waiting for a proper solution for this, I'll try looking at the Makefiles and bsd.*.mk files under /usr/src my self, but I have never looked at them before so I don't expect a speedy success. Gyrd ^_^ > Cheers! > _______________________________________________ > 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 Wed Oct 29 00:42:03 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADB8E130; Wed, 29 Oct 2014 00:42:03 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 003DEFDB; Wed, 29 Oct 2014 00:42:02 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ex7so361588wid.2 for ; Tue, 28 Oct 2014 17:42:01 -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=dHJ8UFmWSfAgY7LKQty1zwvDbLw2zGd6jP7HUx1tJjk=; b=IrPvro5J1M6gPrKEhnfyF0AEwW0SHEi0MWcMBBeyMbeyb24cVLgScM0WvQiG+AqjQ8 XUfSO3T2OYqcngaJN4iDP8wUijPbXDGQ9KLb27gym4Xzv4CfoowPUZftBo6XRO0KMarY l3Ptnli3JigtQF0oVxBvb7oNrDktJddnG5SOcGP+U2B0w8pwIVyozik6rMirztVpD2py C/f4hlC+LEXqrs/56FOA+gIs/SfT0R2DJYbUQT+9vULFr01WdnsE70fJx6N3tx2o+8Zw Iwyccit+ZYqxzzHxpL/xf9VTIQSP3VBWei8pQOt5U3ATSY5IjK+yH7JBtcvUsRKx1oaC QGtQ== MIME-Version: 1.0 X-Received: by 10.181.13.208 with SMTP id fa16mr31830648wid.61.1414543321045; Tue, 28 Oct 2014 17:42:01 -0700 (PDT) Received: by 10.180.89.178 with HTTP; Tue, 28 Oct 2014 17:42:00 -0700 (PDT) In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> Date: Tue, 28 Oct 2014 22:42:00 -0200 Message-ID: Subject: Re: pkg 1.4 freeze please test test test! From: Cassiano Peixoto To: Baptiste Daroussin X-Mailman-Approved-At: Wed, 29 Oct 2014 01:09:02 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "ports@freebsd.org" , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 00:42:03 -0000 Hi guys, Congrats, really good job. How can i test package base? I didn't find any info about that. Thanks. On Tuesday, October 28, 2014, Baptiste Daroussin wrote: > Hi all, > > We are starting the release process of pkg 1.4, we want to have a better > release > process than with every single previous version of pkg. For that we will > need > you help! > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > Changes you can expect in pkg 1.4 are the following: > - Loads of bug fixes > - Stricter checking of the path passed via the plist > - Removal of the bundled libyaml > - new --raw-format to chose the output format for info -R and search -R > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become > FreeBSD:10:amd64) > the old ABI is available as a fallback in ALTABI > - pkg check now support a quiet mode > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging > configuration files > - new @config keyword to mark a file as a config file (during > upgrade/reinstallation it will try to merge the configuration with the > one the > user may have modified) an option AUTOMERGE is available to prevent > automerging if automerge fails a .pkgnew file will be created along with > the > untouched user version of the configuration > - The update procedure has been improved and speed up a lot (in particular > for > machine with low resources) > - The unique identifier has been modified to be pkgname meaning now ports > can be > moved in new categories without having to be considered a different > package > - Only libraries starting by lib* are added to the provided libraries > - General speed up of all operations > > We need help in testing, but we also need help in writing regression tests > ! > The more we have tests the more stable the releases will be. > > The release will also allow to be able to package base! > > regards, > Bapt > From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 01:33:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16A5C724 for ; Wed, 29 Oct 2014 01:33:45 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4D926C1 for ; Wed, 29 Oct 2014 01:33:44 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id f10so127933yha.31 for ; Tue, 28 Oct 2014 18:33:44 -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=/o6A62lObxT0XGs/uzE3DlglqYgt8PnzwlqEcILsBis=; b=j+T3pIEQ9J3tEZselni53VfsyG5zEQkSkPrc/T4+BcCfuw+DziM6fb3ZStoHqZi9CR JWBOGVVCO/tdsB3gGQUTLtbvL0BYqsdSph7xh+ywBfRn0xBOCp+BSWEoUbvwrSttu9zn kDRXCTlOFMfHgz5UoMkKWoIvLG8VOMVhNd/ZU3lQslXvmSia9y5KdqVN9uqeKAfGwBq3 SPe/zIohpRttHnh/zd3c76LmMfhSyJXMs4nZbfwnLBrUXuQ1h8NlIzRmm2McdqqpEEpV IYw8OflyScBjgC+CYBTNbl6YAKBNbsn/UP8aduGdnEhBufPmCAFJd6KZUCsjlBhJTnTO uNoA== MIME-Version: 1.0 X-Received: by 10.170.36.12 with SMTP id 12mr8052933yke.57.1414546423880; Tue, 28 Oct 2014 18:33:43 -0700 (PDT) Received: by 10.170.118.21 with HTTP; Tue, 28 Oct 2014 18:33:43 -0700 (PDT) In-Reply-To: <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> Date: Tue, 28 Oct 2014 18:33:43 -0700 Message-ID: Subject: Re: junior kernel tasks From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 01:33:45 -0000 On Tue, Oct 28, 2014 at 1:35 PM, Marcus von Appen wrote: > > Quoting John Baldwin : > > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: >> >>> Hello, >>> >>> In short, nice kernel tasks people with C language skills can do in few >>> evenings. >>> >>> https://wiki.freebsd.org/JuniorJobs >>> >>> It is assumed you know how to obtain sources and build the kernel. >>> >>> What you can get in return: >>> - your own code in FreeBSD tree >>> - eternal glory [1] >>> - fun [2] >>> >>> If you are not interested, but know someone who does, please pass it >>> down. >>> >>> [1] - not really, no >>> [2] - well, I guess that's subjective, so that's not a "no" >>> >> >> Even though our bugmeisters have decided that we should not have wishlist >> items in our bug tracker, I really wish we could store the various idea >> lists >> (we have several) in an issue tracker instead. This would allow for >> folks to >> comment on ideas, vote for them, etc. It would also make it easier for >> more >> people to submit new ideas. >> >> > Speaking not strictly with the bugmeister hat, but from experience, please > do > not let us go down the road of (ab)using a bug tracking solution as task > and > idea management system. I think that using the tasks feature of phabricator > (our reviews instance) would provide better workflow support for those > things, > starting out from sketching out rough ideas, discussing them, breaking > them up > in seperate tasks (linked to and dependent on each other) and collaborating > on them (take a look at https://developer.blender.org/T42339 for a brief > example). > > Having said this, let's keep the bug tracker a bug tracker. > > Cheers > Marcus > > > _______________________________________________ > 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" > I do not know difficulty of maintaining a tracker such as "bug tracker" , a different tracker such as "development tracker" may be defined and used . In that way , ideas which are not expressible as "bug" in "bug tracker" ( because sometimes it is not possible to decide whether a problem is "bug" or a "design decision" ) may be specified in " development tracker" and be followed from there . With such a structure the improvement ideas will not be lost in individual mails . At some point an idea may be considered useless or inapplicable but over time it may become very feasible but forgotten or the same person may not mention it once more . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 01:39:12 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BBA889A; Wed, 29 Oct 2014 01:39:12 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC1EF74D; Wed, 29 Oct 2014 01:39:11 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s9T1d0Yc023841; Tue, 28 Oct 2014 17:39:04 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201410290139.s9T1d0Yc023841@gw.catspoiler.org> Date: Tue, 28 Oct 2014 18:39:00 -0700 (PDT) From: Don Lewis Subject: Re: pkg 1.4 freeze please test test test! To: bapt@FreeBSD.org In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 01:39:12 -0000 On 29 Oct, Baptiste Daroussin wrote: > Hi all, > > We are starting the release process of pkg 1.4, we want to have a better release > process than with every single previous version of pkg. For that we will need > you help! > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > Changes you can expect in pkg 1.4 are the following: > - Loads of bug fixes I kind of doubt that I'll have time to test it, but I've stumbled across an interesting test case for package building with pkg-1.3.8_3. When I tried to build a multimedia/2mandvd package with poudriere (either bulk or testport) in a FreeBSD 10 amd64 host and jail, pkg-static segfaults. Portsmon also sees this failure, which also seems to be affecting head/amd64 as well: If I run poudriere jail -i to keep the jail around, I don't see any leftover core files, I'm guessing because pkg-static's cwd is in the r/o /usr/ports tree. If I then cd /usr/ports/multimedia/2mandvd in the jail and run: make clean make stage make package pkg-static doesn't segfault, but it never exits either. I left it running for a couple of days and it was still stuck at 100% CPU. If I truss -p the process, I don't get any output, which means it's not doing any syscalls. I tried attaching gdb to the process, but got some strange error messages that I didn't understand. I then ran pkg-static under gdb with the same command line arguments and it still looped forever. I interrupted it to get a stack trace, but that wasn't helpful because the executable was stripped. If I run pkg instead of pkg-static, it seems to work properly. I was hoping to gather some more information to file a bug report, but haven't had time to work on this in the last week. From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 03:04:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B96DA03; Wed, 29 Oct 2014 03:04:06 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51EA0C9; Wed, 29 Oct 2014 03:04:06 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tr6so2157631ieb.14 for ; Tue, 28 Oct 2014 20:04:05 -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:message-id:subject :from:to:cc:content-type; bh=wkf4gY/p7y4ufhB4A4IY+pIDFC9V6ACG4N2dB8lPKmI=; b=Ghq65zv9wyKjuNv/v7z+89n7+raLbjffH1Fu5QO6bnhbF6aJL+QTZwWhgal6effRrZ LfB+8uyUDdvpquoEk7dB6fgjS4KypmfOdDgE/XYAOzc8M7f4xC+E0rOBXWT+xJngX952 fEYIlLJqFYLgdOHV5fDpNLNQQbPQYDruUppcpMCEX1gVuDpCvUlCRUqaPK3nSZCW2ls1 y2zUmnmtr7JHB+SqupI6R5xK70WM65rkAqNuA5lSZE8BUgz8Vgm0mC+ddkhmztGAXHk0 uefFOGNqPt/AVq+I+FBzsrvE4h6EyZNIviF3qM9R4gPLlVwCyB7+YWbcLs3eFfl9tkEB OY4A== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr9420335igb.0.1414551845575; Tue, 28 Oct 2014 20:04:05 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.11.152 with HTTP; Tue, 28 Oct 2014 20:04:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Oct 2014 20:04:05 -0700 X-Google-Sender-Auth: B_D5gsvQ51Ng7CweiU4WWMOGKfM Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ From: Kevin Oberman To: Ed Maste Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 03:04:06 -0000 On Tue, Oct 28, 2014 at 5:20 PM, Ed Maste wrote: > I am preparing to move the standalone kernel debug data out of > /boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach > used for userland debug data. This significantly reduces the boot > partition size requirement, and is a step towards supporting the > installation of kernel debug data ony when required. LLDB and GDB > automatically search for debug data under /usr/lib/debug/ so this > change should be transparent from an end-user perspective. > > The change can be reviewed in Phabricator at > https://reviews.freebsd.org/D1006 and can be fetched as a unified diff > from https://people.freebsd.org/~emaste/patches/D1006.diff > > This does not change any defaults or knobs: kernel debug files are > still built by default, and may be disabled by setting > WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize > this with userland debug in a later step. > > Note that the change renames the intermediate and debug data files to > be consistent with userland debug data: in the build directory the > kernel with debug data included is now named kernel.full, and and > kernel.debug is the standalone debug data file. > > I plan to merge this in a few days if there are no issues reported in > further review or testing. > > -Ed > Finally! This is great news. /usr/lib seems like an odd place, though. Does not seem to match the description in hier(7) (not that the man page can't be updated). Looks to me like it fits /var a bit better, though I'm not sure that much data is appropriate for many /var partitions. Still, wherever the symbol files end up, getting them out of root is something many people have wanted for a long time. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 03:11:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51630B8A for ; Wed, 29 Oct 2014 03:11:32 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 173601A6 for ; Wed, 29 Oct 2014 03:11:32 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id rl12so2149257iec.31 for ; Tue, 28 Oct 2014 20:11:31 -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:from:date:message-id :subject:to:cc:content-type; bh=OvR2wIZdl/N+F9ImcsyYdyClMD6/LaC1WkfnXtz2qzY=; b=MiWYbrYrfw9dvLtTvuIfagOxq8q2UroAO0rMZqs6zvCfFRQFnYlhMbSBe7ZZeen+rF 24D1WBeL3owsFXZsFpPX5VqD1WpJ9nzRA6E2y+zowL4OMrUJkX1eT+T4rZ8KMZ/8aVty m4FmkqEAOVTMC58yDt7FEMLzT3a850qbuJOMCU0zdOEKkoo6i1VPF8rhizYQpQMmpG0m h++ExmEPbqwYihK8lj9CWS22c/xdFVzlAnOkyAL4BOkx13J+IbhZGwVJLhQi5vWzOqqe +VyFtufl7ussMcS35YY9asESAUsh6O/lXMSEtV0sOgL2F3ICj55JfjREiN4QeVTgMksb +w5A== X-Received: by 10.107.41.79 with SMTP id p76mr8729359iop.10.1414552291259; Tue, 28 Oct 2014 20:11:31 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.132 with HTTP; Tue, 28 Oct 2014 20:11:10 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Tue, 28 Oct 2014 23:11:10 -0400 X-Google-Sender-Auth: oXfpHBtvHKM3A-SjhCn9x5R8_Y8 Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 03:11:32 -0000 On 28 October 2014 23:04, Kevin Oberman wrote: > > Finally! This is great news. > > /usr/lib seems like an odd place, though. Does not seem to match the > description in hier(7) (not that the man page can't be updated). Looks to me > like it fits /var a bit better, though I'm not sure that much data is > appropriate for many /var partitions. /usr/lib/debug is the standard location for standalone debug data established by GDB, and seems like a decent enough location. I'll make sure to update the man page. -Ed From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 04:39:18 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7A12D35; Wed, 29 Oct 2014 04:39:18 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BF27B81; Wed, 29 Oct 2014 04:39:18 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id y10so2172692pdj.40 for ; Tue, 28 Oct 2014 21:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LnzvuLvFYcPRrpWob5qzTNv5D1CmiRPmzlaGweo+VzQ=; b=olYpVqS0slq3+KiF7yx6GSf3cesQPcT9ctlTWQ+UAs0ojtmryVIG5JCYZOIVCT+q1v 3lCvldpuK3jzgX5zUtwHBbJAD04teKTkqawU2l/XPz8HiET0drI5025M4RdJVM6iT5JA 1MY9+S7p5cRGZGg16eDRHoFJMRr9aFkl5qxVrgumF5Wyzb/E3f82yPyy55FdEAU0hwyL TCWZB3Ir/p8EFpKirmWzrVm0jzIJVLpDmm6onqBfvP69V5yB9RnJn7YPfm7xu+IWwqH7 FnR09Cz6bBU3nvb/bnd2ap+1G2IVzQ2rO87ftj6U1T3BVK59/hN3FDDrl04cjkwvJ3df 45CQ== X-Received: by 10.70.42.15 with SMTP id j15mr8052198pdl.17.1414557558134; Tue, 28 Oct 2014 21:39:18 -0700 (PDT) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id ra4sm3047509pab.33.2014.10.28.21.39.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 21:39:17 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6C4B31FC-B77F-4AA8-91F3-794F23D2AC67"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: issues w/ installing stuff multiple times... From: Garrett Cooper In-Reply-To: <20141027221048.GF59119@spindle.one-eyed-alien.net> Date: Tue, 28 Oct 2014 21:39:14 -0700 Message-Id: <80D41F31-3CF7-4537-8D72-30A0324F0F59@gmail.com> References: <20141027215058.GN82214@funkthat.com> <20141027221048.GF59119@spindle.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@FreeBSD.org" , John-Mark Gurney , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 04:39:19 -0000 --Apple-Mail=_6C4B31FC-B77F-4AA8-91F3-794F23D2AC67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 27, 2014, at 15:10, Brooks Davis wrote: > On Mon, Oct 27, 2014 at 02:55:09PM -0700, Garrett Cooper wrote: >>=20 >>> On Oct 27, 2014, at 14:50, John-Mark Gurney = wrote: >>>=20 >>> There are issues w/ installing tests where the test files get = installed >>> multiple times. >>>=20 >>> To reproduce this, use the following steps: >>> make installworld -j 8 DESTDIR=3D -DNO_ROOT >>>=20 >>> Once you have done the above, in there will be the = file >>> METALOG, run: >>> grep -v type=3Ddir /METALOG | awk '{ print $1 }' | = sort | uniq -d >>>=20 >>> This will print out the current list if files that get installed = multiple >>> times.... >>>=20 >>> Currently, it looks like all the tests subdirs are installed a = second >>> time... >>>=20 >>> Could someone look at making it so that they don't get installed >>> multiple times? >>=20 >> Hi jmg! >> I have a patch out for this that I need to commit today. Thank you = for the reminder. >=20 > Great to hear this will be fixed. Once we've fixed them all, it would = be > really good to have a test in Jenkins looking out for new duplicate = files > since they are always bugs. I got swamped at $work yet again. I need to do a bit more testing for = the patch, but I=92ll try to get it out this week after I=92ve done the = necessary testing. Thank you, --Apple-Mail=_6C4B31FC-B77F-4AA8-91F3-794F23D2AC67 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUUG9yAAoJEMZr5QU6S73eNQcH/1dWKs7kczw9gtFxcESW13oa jE3doMHU+ogbueqKF73vXG3bJJlFJfC355U9qgF+Capxa0O6eVV+B+9/hKBjegnK rdJTrn2eW+WvTIO6MMgGbhM0ZwWFmnObmYOdLFUk+LL7EgkdZfYvV3lU6Hzf8ORf qNZ2xIg/7bqLvmBsKcJhQiVFnnHs4QyVspeBbKB90jLNH560oNUNuze/p5YinAum lY8Uex0Z+cdVngS0+1zpol0RNRF3WA1dBqHd28IwoIDCpgAV5fi/JbSXtXB0vBV3 JHpXI+KRy+VcwRbMaYX3JIZDRPRVhfuwTNqsfUnq5GWZeachOJ+5sMlIBP9bMfI= =Rk23 -----END PGP SIGNATURE----- --Apple-Mail=_6C4B31FC-B77F-4AA8-91F3-794F23D2AC67-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 05:55:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3854890A for ; Wed, 29 Oct 2014 05:55:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 259C2282 for ; Wed, 29 Oct 2014 05:55:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9CD8EFEE for ; Wed, 29 Oct 2014 05:55:45 +0000 (UTC) Date: Wed, 29 Oct 2014 05:55:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <713751442.8.1414562145570.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1196887681.7.1414547574107.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1196887681.7.1414547574107.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #144 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 05:55:45 -0000 See ------------------------------------------ [...truncated 22 lines...] FreeBSD 11.0-CURRENT #1618: Wed Oct 29 05:42:13 UTC 2014 jenkins@jenkins-10.freebsd.org:/usr/obj/builds/FreeBSD_HEAD/sys/GENERIC= amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2399.77-MHz K8-class = CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c Steppi= ng=3D2 Features=3D0x9f83ab7f Features2=3D0x829e6257 AMD Features=3D0x24100800 AMD Features2=3D0x1 TSC: P-state invariant Hypervisor: Origin =3D "bhyve bhyve " real memory =3D 2147483648 (2048 MB) avail memory =3D 2040360960 (1945 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded; using insecure entropy ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized module_register_init: MOD_LOAD (vesa, 0xffffffff80dae150, 0) error 19 acpi0: on motherboard acpi0: Power Button (fixed) atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 10000000 Hz quality 950 Event timer "HPET" frequency 10000000 Hz quality 550 Event timer "HPET1" frequency 10000000 Hz quality 450 Event timer "HPET2" frequency 10000000 Hz quality 450 Event timer "HPET3" frequency 10000000 Hz quality 450 Event timer "HPET4" frequency 10000000 Hz quality 450 Event timer "HPET5" frequency 10000000 Hz quality 450 Event timer "HPET6" frequency 10000000 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 virtio_pci0: port 0x2000-0x201f mem 0xc0000000= -0xc0001fff irq 16 at device 2.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x1018020 virtio_pci0: negotiated features: 0x18020 vtnet0: Ethernet address: 58:9c:fc:00:00:2e ahci0: mem 0xc0002000-0xc00023ff irq 17 a= t device 3.0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard sc0: at flags 0x100 on isa0 sc0: MDA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3b0-0x3bb iomem 0xb0000-0xb7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 123456 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2048MB (4194304 512 byte sectors: 16H 63S/T 4161C) ada0: Previously was known as ad4 random: unblocking device. SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/TESTROOT [rw]... Setting hostuuid: 2efd6eda-5f30-11e4-8bbc-589cfc00002e. Setting hostid: 0x7af35512. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: /dev/ufs/TESTROOT: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/TESTROOT: clean, 1053174 free (398 frags, 131597 blocks, 0.0% frag= mentation) Mounting local file systems:. Writing entropy file:. /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Starting Network: lo0 vtnet0. lo0: flags=3D8049 metric 0 mtu 16384 =09options=3D600003 =09inet6 ::1 prefixlen 128=20 =09inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 =09inet 127.0.0.1 netmask 0xff000000=20 =09nd6 options=3D21 vtnet0: flags=3D8902 metric 0 mtu 1500 =09options=3D80028 =09ether 58:9c:fc:00:00:2e =09nd6 options=3D29 =09media: Ethernet 10Gbase-T =09status: active Starting devd. Starting Network: vtnet0. vtnet0: flags=3D8902 metric 0 mtu 1500 =09options=3D80028 =09ether 58:9c:fc:00:00:2e =09nd6 options=3D29 =09media: Ethernet 10Gbase-T =09status: active Starting pflogd:=20 add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Creating and/or trimming log files. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 32-bit compatibility ldconfig path: /usr/lib32 Starting casperd. Clearing /tmp (X related). Updating motd:. Mounting late file systems:. Configuring syscons: blanktime. Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Wed Oct 29 05:55:33 UTC 2014 FreeBSD/amd64 (Amnesiac) (ttyu0) login: root root Oct 29 05:55:33 login: ROOT LOGIN (root) ON ttyu0 FreeBSD 11.0-CURRENT (GENERIC) #1618: Wed Oct 29 05:42:13 UTC 2014 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-question= s/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd= / directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier Edit /etc/motd to change this login announcement. root@:~ # cd /usr/tests cd /usr/tests root@:/usr/tests # kyua test kyua test kyua: E: Load of 'Kyuafile' failed: Failed to load Lua file 'Kyuafile': Kyu= afile:49: Load of 'bin/Kyuafile' failed: Failed to load Lua file 'bin/Kyuaf= ile': bin/Kyuafile:49: Load of 'bin/sh/Kyuafile' failed: Failed to load Lua= file 'bin/sh/Kyuafile': bin/sh/Kyuafile:8: Load of 'bin/sh/errors/Kyuafile= ' failed: File 'bin/sh/errors/Kyuafile' not found. root@:/usr/tests # kyua report --verbose --results-filter passed,skipped,xf= ail,broken,failed --output test-report.txt kyua report --verbose --results-filter passed,skipped,xfail,b =08roken,fail= ed --output test-report.txt kyua: E: No previous results file found for test suite usr_tests. root@:/usr/tests # kyua report-junit --output=3Dtest-report.xml kyua report-junit --output=3Dtest-report.xml kyua: E: No previous results file found for test suite usr_tests. root@:/usr/tests # shutdown -p now shutdown -p now Shutdown NOW! shutdown: [pid 674] root@:/usr/tests # = =20 =07*** FINAL System shutdown message from root@ ***=07 = =20 System going down IMMEDIATELY = =20 = =20 Oct 29 05:55:34 shutdown: power-down by root:=20 System shutdown time has arrived=07=07 Stopping cron. Waiting for PIDS: 616. Stopping casperd. Waiting for PIDS: 510. Stopping devd. Waiting for PIDS: 336. Writing entropy file:. . Terminated Oct 29 05:55:35 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. lock order reversal: 1st 0xfffff800062c37c8 ufs (ufs) @ /builds/FreeBSD_HEAD/sys/kern/vfs_mount= .c:1223 2nd 0xfffff800062c4240 devfs (devfs) @ /builds/FreeBSD_HEAD/sys/kern/vfs_s= ubr.c:2144 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe007b56d= 5b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe007b56d660 witness_checkorder() at witness_checkorder+0xdad/frame 0xfffffe007b56d6f0 __lockmgr_args() at __lockmgr_args+0x9ca/frame 0xfffffe007b56d820 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe007b56d840 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe007b56d870 _vn_lock() at _vn_lock+0xaa/frame 0xfffffe007b56d8e0 vget() at vget+0x67/frame 0xfffffe007b56d920 devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe007b56d970 devfs_root() at devfs_root+0x43/frame 0xfffffe007b56d9a0 dounmount() at dounmount+0x345/frame 0xfffffe007b56da20 vfs_unmountall() at vfs_unmountall+0x61/frame 0xfffffe007b56da50 kern_reboot() at kern_reboot+0x530/frame 0xfffffe007b56dac0 sys_reboot() at sys_reboot+0x5a/frame 0xfffffe007b56dae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe007b56dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe007b56dbf0 --- syscall (55, FreeBSD ELF64, sys_reboot), rip =3D 0x40f2ac, rsp =3D 0x7f= ffffffe6d8, rbp =3D 0x7fffffffe7d0 --- Uptime: 11s acpi0: Powering system off + sudo python /vm/freebsd-ci/scripts/test/extract-test-logs.py -f /vm/freeb= sd-ci/scripts/test/config/config.json cp: /tmp/tmppyDscR/usr/tests/*.xml: No such file or directory mdconfig -a -u 99 -t vnode -f /net/jenkins-10.freebsd.org/builds/Build-UFS-= image/image/FreeBSD_HEAD/test.img umount /tmp/tmppyDscR mdconfig -d -u 99 Recording test results Test reports were found but none of them are new. Did tests run?=20 For example, is 6 hr 53 min old Build step 'Publish JUnit test result report' changed build result to FAILU= RE From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 07:56:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B0D9BB; Wed, 29 Oct 2014 07:56:15 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA052F68; Wed, 29 Oct 2014 07:56:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9T7u4HZ077553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 09:56:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9T7u4HZ077553 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9T7u3LW077550; Wed, 29 Oct 2014 09:56:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Oct 2014 09:56:03 +0200 From: Konstantin Belousov To: Chagin Dmitry Subject: Re: Ver 2 of the patch [was: Re: i915 driver update testing] Message-ID: <20141029075603.GC53947@kib.kiev.ua> References: <5433E408.2010601@egr.msu.edu> <20141007164419.GB2153@kib.kiev.ua> <20141007180106.GD2153@kib.kiev.ua> <54344766.1040700@egr.msu.edu> <20141008170525.GH2153@kib.kiev.ua> <54358C88.2080501@egr.msu.edu> <20141022122640.GL1877@kib.kiev.ua> <54480C9B.7070606@egr.msu.edu> <20141023190329.GP1877@kib.kiev.ua> <20141026210211.GA1103@dchagin.static.corbina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141026210211.GA1103@dchagin.static.corbina.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Adam McDougall , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 07:56:15 -0000 On Mon, Oct 27, 2014 at 12:02:11AM +0300, Chagin Dmitry wrote: > On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: > > On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: > > > On 10/22/2014 08:26, Konstantin Belousov wrote: > > > > Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one > > private report of the patch worked from person who got the same panic > > in iicbb. > > Hi, Kostik! > > i915.6.patch & i7-4700. > > > FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 r273708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 root@dchagin.static.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY amd64 > > Unread portion of the kernel message buffer: > FDI TX state assertion failure (expected off, current on) > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > drmn1: taking over the fictitious range 0xe0000000-0xf0000000 > info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off > info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 > panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > > cpuid = 2 > Uptime: 27s > Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% > > Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. > Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols > Reading symbols from /boot/kernel/i915kms.ko.symbols...done. > Loaded symbols for /boot/kernel/i915kms.ko.symbols > Reading symbols from /boot/kernel/drm2.ko.symbols...done. > Loaded symbols for /boot/kernel/drm2.ko.symbols > #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 > 261 dumptid = curthread->td_tid; > (kgdb) #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 > #1 0xffffffff80691a75 in kern_reboot (howto=260) > at /home/dchagin/head/sys/kern/kern_shutdown.c:447 > #2 0xffffffff80692670 in vpanic ( > fmt=0xffffffff80c763b9 "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n", ap=0xfffffe033c750d60) > at /home/dchagin/head/sys/kern/kern_shutdown.c:746 > #3 0xffffffff8069204c in kassert_panic ( > fmt=0xffffffff80c763b9 "_sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n") at /home/dchagin/head/sys/kern/kern_shutdown.c:634 > #4 0xffffffff806a09b0 in _sx_xlock_hard (sx=0xfffffe00039480e8, > tid=18446735277793944768, opts=0, > file=0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", line=370) > at /home/dchagin/head/sys/kern/kern_sx.c:519 > #5 0xffffffff8069f9ed in __sx_xlock (sx=0xfffffe00039480e8, > td=0xfffff8000a9324c0, opts=0, > file=0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", line=370) at sx.h:154 > #6 0xffffffff8069f893 in _sx_xlock (sx=0xfffffe00039480e8, opts=0, > file=0xffffffff8166d4e7 "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", line=370) > at /home/dchagin/head/sys/kern/kern_sx.c:311 > #7 0xffffffff816464e6 in intel_gmbus_transfer (idev=0xfffff80080a99900, > msgs=0xfffffe033c7511e0, nmsgs=2) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > #8 0xffffffff81646ac7 in intel_gmbus_transfer (idev=, > msgs=, nmsgs=) > at iicbus_if.h:131 > #9 0xffffffff8044a445 in IICBUS_TRANSFER (dev=0xfffff80080a99900, > msgs=0xfffffe033c7511e0, nmsgs=2) at iicbus_if.h:131 > #10 0xffffffff8044a39b in iicbus_transfer (bus=0xfffff80080a99800, > msgs=0xfffffe033c7511e0, nmsgs=2) > at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355 > #11 0xffffffff8169309d in drm_do_probe_ddc_edid (adapter=0xfffff80080a99800, > buf=0xfffffe033c751257 ""y", block=, len=1) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:290 > #12 0xffffffff816909bc in drm_get_edid (connector=0xfffff80080826c00, > adapter=0xfffff80080a99800) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:388 > #13 0xffffffff81645690 in intel_hdmi_detect (connector=0xfffff80080826c00, > force=) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_hdmi.c:465 > #14 0xffffffff8168adf5 in drm_helper_probe_single_connector_modes ( > connector=0xfffff80080826c00, maxX=8192, maxY=8192) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:135 > #15 0xffffffff8169387f in drm_fb_helper_initial_config ( > fb_helper=0xfffff8008093b200, bpp_sel=32) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:1164 > #16 0xffffffff81643e41 in intel_fbdev_init (dev=) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_fb.c:245 > #17 0xffffffff81617082 in i915_driver_load (dev=0xfffff80009807800, flags=0) > at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_dma.c:1181 > #18 0xffffffff8168ece5 in drm_attach (kdev=0xfffff800071b6e00, > idlist=) > at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:591 > #19 0xffffffff806dd737 in DEVICE_ATTACH (dev=0xfffff800071b6e00) > at device_if.h:180 > #20 0xffffffff806dd19c in device_attach (dev=0xfffff800071b6e00) > at /home/dchagin/head/sys/kern/subr_bus.c:2836 > #21 0xffffffff806dd0c4 in device_probe_and_attach (dev=0xfffff800071b6e00) > at /home/dchagin/head/sys/kern/subr_bus.c:2794 > #22 0xffffffff806df8ba in bus_generic_driver_added (dev=0xfffff80003e3f200, > driver=0xffffffff816726e0) at /home/dchagin/head/sys/kern/subr_bus.c:3845 > #23 0xffffffff806e330f in BUS_DRIVER_ADDED (_dev=0xfffff80003e3f200, > _driver=0xffffffff816726e0) at bus_if.h:204 > #24 0xffffffff806da51a in devclass_driver_added (dc=0xfffff80003e3c880, > driver=0xffffffff816726e0) at /home/dchagin/head/sys/kern/subr_bus.c:1065 > #25 0xffffffff806da302 in devclass_add_driver (dc=0xfffff80003e3c880, > driver=0xffffffff816726e0, pass=2147483647, dcp=0xffffffff816b8cb8) > at /home/dchagin/head/sys/kern/subr_bus.c:1138 > #26 0xffffffff806e1779 in driver_module_handler (mod=0xfffff80003dbb980, > what=0, arg=0xffffffff81672710) > at /home/dchagin/head/sys/kern/subr_bus.c:4694 > #27 0xffffffff8066e2a0 in module_register_init (arg=0xffffffff816726c8) > at /home/dchagin/head/sys/kern/kern_module.c:123 > #28 0xffffffff8065d334 in linker_file_sysinit (lf=0xfffff8008012e200) > at /home/dchagin/head/sys/kern/kern_linker.c:224 > #29 0xffffffff8065cad3 in linker_load_file ( > filename=0xfffff8000a90a120 "/boot/kernel/i915kms.ko", > result=0xfffffe033c751858) > at /home/dchagin/head/sys/kern/kern_linker.c:424 > #30 0xffffffff80658ec1 in linker_load_module (kldname=0x0, > modname=0xfffff8000a6bf800 "i915kms", parent=0x0, verinfo=0x0, > lfpp=0xfffffe033c7518b8) at /home/dchagin/head/sys/kern/kern_linker.c:1999 > #31 0xffffffff8065aeb9 in kern_kldload (td=0xfffff8000a9324c0, > file=0xfffff8000a6bf800 "i915kms", fileid=0xfffffe033c751900) > at /home/dchagin/head/sys/kern/kern_linker.c:1031 > #32 0xffffffff8065afbb in sys_kldload (td=0xfffff8000a9324c0, > uap=0xfffffe033c751a58) at /home/dchagin/head/sys/kern/kern_linker.c:1057 > #33 0xffffffff80b5a098 in syscallenter (td=0xfffff8000a9324c0, > sa=0xfffffe033c751a48) at subr_syscall.c:133 > #34 0xffffffff80b59a4f in amd64_syscall (td=0xfffff8000a9324c0, traced=0) > at /home/dchagin/head/sys/amd64/amd64/trap.c:987 > #35 0xffffffff80b2eacb in Xfast_syscall () > at /home/dchagin/head/sys/amd64/amd64/exception.S:390 > #36 0x000000080088d42a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > Sun Oct 26 23:41:48 MSK 2014 > Oct 26 23:41:54 dchagin login: ROOT LOGIN (root) ON ttyv0 > info: [drm] Initialized drm 1.1.0 20060810 > drmn1: on vgapci1 > info: [drm] MSI enabled 1 message(s) > info: [drm] AGP at 0xe0000000 256MB > iicbus0: on iicbb0 addr 0xff > iic0: on iicbus0 > iic1: on iicbus1 > iicbus2: on iicbb1 addr 0xff > iic2: on iicbus2 > iic3: on iicbus3 > iicbus4: on iicbb2 addr 0xff > iic4: on iicbus4 > iic5: on iicbus5 > iicbus6: on iicbb3 addr 0xff > iic6: on iicbus6 > iic7: on iicbus7 > iicbus8: on iicbb4 addr 0xff > iic8: on iicbus8 > iic9: on iicbus9 > iicbus10: on iicbb5 addr 0xff > iic10: on iicbus10 > iic11: on iicbus11 > iicbus12: on iicbb6 addr 0xff > iic12: on iicbus12 > iic13: on iicbus13 > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > XXXKIB HACK: HSW RC OFF > FDI TX state assertion failure (expected off, current on) > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe > 0 > drmn1: taking over the fictitious range 0xe0000000-0xf0000000 > info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off > info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 > panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > > cpuid = 2 > Uptime: 27s > Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% I am not sure what happens there. Recursion on gmbus_sx could only occur if IICBUS_TRANSFER() on bbbus devices somehow called back to intel_gmbus_transfer(). I do not see how this is possible. I set force_bit_dev manually (in a hackish way) on my two test boxes, one sandy bridge, one haswell, and both machines loaded i915kms and startx Xorg server successfully. Did you performed clean build after applying the patch ? From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 08:01:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62D194A5 for ; Wed, 29 Oct 2014 08:01:52 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 517FEF1 for ; Wed, 29 Oct 2014 08:01:52 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DFBBA70 for ; Wed, 29 Oct 2014 08:01:52 +0000 (UTC) Date: Wed, 29 Oct 2014 08:01:52 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <908620827.10.1414569712882.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <713751442.8.1414562145570.JavaMail.jenkins@jenkins-9.freebsd.org> References: <713751442.8.1414562145570.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD-tests2 #145 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 08:01:52 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 09:13:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42A06376; Wed, 29 Oct 2014 09:13:24 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CFA8A1E; Wed, 29 Oct 2014 09:13:23 +0000 (UTC) Received: from [192.168.0.106] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id s9T95vjj076908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 09:06:00 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52] claimed to be [192.168.0.106] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ From: David Chisnall In-Reply-To: Date: Wed, 29 Oct 2014 09:05:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Maste X-Mailer: Apple Mail (2.1878.6) Cc: Kevin Oberman , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 09:13:24 -0000 On 29 Oct 2014, at 03:11, Ed Maste wrote: > /usr/lib/debug is the standard location for standalone debug data > established by GDB, and seems like a decent enough location. I'll make > sure to update the man page. Do gdb and lldb also look in /usr/local/lib/debug? If not, it would be = great if we could at least teach lldb to do this so that we can start = thinking about splitting debug info into separate packages for ports = (and providing it as an optional install for everything). David From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 09:35:52 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A259ABCB; Wed, 29 Oct 2014 09:35:52 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [84.201.143.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5681CC35; Wed, 29 Oct 2014 09:35:51 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward4l.mail.yandex.net (Yandex) with ESMTP id C88E71441295; Wed, 29 Oct 2014 12:35:41 +0300 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 9CF83E40275; Wed, 29 Oct 2014 12:35:40 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:40c:120b:a9ff:fe93:c998]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 97ICnHF1An-ZdSimkOQ; Wed, 29 Oct 2014 12:35:40 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 765454ed-9d77-45d4-b3a9-754409616c00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1414575340; bh=nxJBUaCWwdO7eFbsiYR0jhKO2yDcc2gDW++MYt1m3NM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type; b=Eh/rtxIqZ19nZ8Q6kOootom9WzTaGHwC/FDHZrqY2CmVymgBwStwk9i593kkftlBH pYcSDoi8+Se0Brwp3nQJ8ByXpyhtQJTbBg3DBVx0+JIVdzsKO6YzSEldovNU+qIbdL Jn8Mz7o77nPe17qN9UKXjFxiT6BwscnXLBczF4ac= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5450B4E5.7020804@yandex.ru> Date: Wed, 29 Oct 2014 12:35:33 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-current Subject: [RFC][RFT] overhaul if_gre(4) Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 09:35:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All, I prepared the patch for review https://reviews.freebsd.org/D1023 Split if_gre(4) into two modules, if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * make implementation conform to the RFC 2784 and partially to RFC 2890; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove caching routes support. This fixes problem, when gre(4) doesn't work at system startup. But this also removes ability to have tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, use our standard ioctls for tunnels. me(4): * use the same locking model as gre(4); * use if_transmit; * implementation conform to RFC 2004; --=20 WBR, Andrey V. Elsukov --MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUULTpAAoJEAHF6gQQyKF6+PUIAJgZbHITiPZgBU1pgS7CxcQ7 qaaUc3a8/ClH5pbSH1fdgiboF00ONplUP+F3XElAJn8l9GcfzNEcnBFVffdATaYK NycbCAjYeA9k26pLNiGywianuGI4uOFAOeTXaZhbCIBaaRlIffUCntS1oc/bMZ3w JV/gBHwbGizawOnWkN/MvGvdw8StJmywZyJ8F617xgZ1mzIP6nd2SCfBPRpX2s/w LTAqf3MnIR7bpc4+4qKoVPVmz+SdFDiAFgaxbZ7XeAfoxpJXQzZCYezrw6HzqF8t D7SwSnDJmFGOcMPALNbwK/anyZmwYI1A9V73pkYdCEHBftS1N+aaOh4LMiL4gs4= =5vQs -----END PGP SIGNATURE----- --MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 10:20:12 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CBDEB3F; Wed, 29 Oct 2014 10:20:12 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BFA314C; Wed, 29 Oct 2014 10:20:11 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so4117298wiv.9 for ; Wed, 29 Oct 2014 03:20:10 -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=b5MLO37hYTvORfwNYLRWiB9kkGf+bMy4blmj4Uw4dN0=; b=w73ZbEGAROkozyXFKLHC/zM6uSYJJYbMh3n5DWxuYqW1s4NJ/8u9i9ifvDMM4CDFX0 2QysGAlKDiBL/urKVahQvQ9vjV7fw0Y8lUyhLIH5bfA/NAPGDrqn8fwf/K0JCCIdv2N5 +IQmz7F22Sa/EgvV3sEyUiOQ62Eu8lVB+NLu8yTwGWfPXv4nBNYhUydL4rFeJGPJU7MG WOIMMGg+LOubURTIf1DbPpGPJblZmGp7QWJNXKLwdEQkIrytMw/z1KpZWqLud63krjuS IvQwjkVXAtdF1uHzW8qx7jUg3gJsVrErd/Sx2MrrTigz9PzAIHLuZe4rlUtI5NBlllMa 46Xw== X-Received: by 10.180.8.233 with SMTP id u9mr11578394wia.19.1414578009327; Wed, 29 Oct 2014 03:20:09 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fm10sm18206851wib.21.2014.10.29.03.20.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 03:20:08 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 11:20:06 +0100 From: Baptiste Daroussin To: Jeffrey Bouquet Subject: Re: pkg-devel-1.4.0-a3 works good so far Message-ID: <20141029102006.GC82736@ivaldir.etoilebsd.net> References: <1414577918.99001.YahooMailBasic@web140904.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline In-Reply-To: <1414577918.99001.YahooMailBasic@web140904.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 10:20:12 -0000 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 03:18:38AM -0700, Jeffrey Bouquet via freebsd-ports= wrote: > Built with clang... none of the problems (so far) from the previous build= s appear to exist from > initial testing of pkg and of a port install. > v9=20 > had to use -DFORCE_PKG_REGISTER though... > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" Great thanks! Bapt --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQv1YACgkQ8kTtMUmk6EyYZgCgi6rCiPaxzAmaVriNN7mTpu27 XH8AniStE0+ufNZ5VP6mD7toMiYUp5dn =mUjP -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 10:42:05 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 571A5EAC; Wed, 29 Oct 2014 10:42:05 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E5083F8; Wed, 29 Oct 2014 10:42:04 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 55D2BC412EF; Wed, 29 Oct 2014 13:42:01 +0300 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id C1E0AE4012E; Wed, 29 Oct 2014 13:42:00 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:40c:120b:a9ff:fe93:c998]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id oaWXsYcSOI-g0S8WBO7; Wed, 29 Oct 2014 13:42:00 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 12054929-7e41-4b41-a276-28d46211034b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1414579320; bh=kyUzpNy4EShnPNQbaxSGRCp2rUUtQdKF4GFQLel8elY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=cwLGm89uYIGzynLKIoI7foL/9MY+PCoX5IFJrLqjmy9Ro8cFISu/H/rkK4jToco7l h2hZ1uAwtHUg+3joYv61SQbYN+O1qR2Mce+hZMU2BxJXoYWT5MZ+egRPPE8V44uZpz s25rX39yoDWzh8N8ANlBrFrAWCEFYXb/wj7CWbFk= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5450C470.4060503@yandex.ru> Date: Wed, 29 Oct 2014 13:41:52 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-current Subject: Re: [RFC][RFT] overhaul if_gre(4) References: <5450B4E5.7020804@yandex.ru> In-Reply-To: <5450B4E5.7020804@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 10:42:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.10.2014 12:35, Andrey V. Elsukov wrote: > Hi All, >=20 > I prepared the patch for review > https://reviews.freebsd.org/D1023 For those who want to test, I prepared a tarball with sources https://people.freebsd.org/~ae/gre.tgz Modules should work on stable/10 and head/ without modifications. And they will not work on stable/9. --=20 WBR, Andrey V. Elsukov --1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUUMR1AAoJEAHF6gQQyKF6sGsIAMDOaRLdWDCRrec5V26BeoC9 3++eh+Yl9vCaXe6/piKATVb+keOxijgoVW/k8XdR5yXRfzJx5fd13PM8bjEJ71H+ TiGt6SSs134zHMIEP1kiNrVJgsEgHtpD9P7hIlntSSNYG9M/rBg860ZzldREbF6x 64hXJZQMAl6s4UH3AMpnVQNesW9zfC7yCB6OEYh8eBfl9vj8q0/onNLSphOxFruX 3d0nm1UY+jxpQV92GgqHyHcxQwcIu8XKQEkAYBwJl9qEza/iljaZW1G47x9YnJSl F/Eze4LD4PuA7IOUy7yxNTrQV5FA6+SnqoHTcq0V6JPhU6sRsMXdrgavrTMSnx4= =4PcY -----END PGP SIGNATURE----- --1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 10:18:45 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62312B1A for ; Wed, 29 Oct 2014 10:18:45 +0000 (UTC) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0ECBC13B for ; Wed, 29 Oct 2014 10:18:44 +0000 (UTC) Received: from [98.139.215.143] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2014 10:18:38 -0000 Received: from [98.139.212.237] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2014 10:18:38 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 29 Oct 2014 10:18:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 615147.5336.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 33999 invoked by uid 60001); 29 Oct 2014 10:18:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1414577918; bh=Sh90z1w9sT8C8kuBMw/iyeGaocuaR90oYctVPluSVyU=; h=Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=QI0t055XYTPRT1yMUgEtTK2K6clp1BhA4DaNH16nqbZDXuZOsufwtZqvVK9eBmqmJx20s8xqSRx+o6Pvx47QxSiIik/xBtRGRznnJamQ3vLT0z8hOzV05m19z0dEGSLReoU16Jh/2Enme4B6hC9ivoq5B8mjOGp//KFI4tDIofc= X-YMail-OSG: Y7W_g0cVM1n.39qkaiUq.Wes6iQmb3d0mlei_t5Y70zESRM 07ZpPTAXhRkG0WzduDlsqENkLOKcACTzXMC059Pim6_Aeu9kwSZfkhK9TLMA c7l9V4VHvJaJE3iP8CC1iPZA3IUmLtvslCABN6becDFHAvVS10DRF7fR9kXd KyjN47bw5rKhy1XH.qqXcuP8KNg3fp196dEDBEMe1oz3ZfGp8f1QS8BKrHSA n_5szR4x.DxV_Us6YmGcB857uTyQHrVJ8lW3uGDKLObGQXiDTm.mfU0mXCEk 6EPvPqB6NU55vz0OU4H5if39i.tL5vB7iLkD1fbeDVs7JRLjgRgJbCqk8vJr yrIk1fnd1qsmkS67fu1NQKnmnAuLGNlSz9crM.tJDWv_7q.xZiNKFHb79ksd kuGU8bsY1N5Q2azjKVGne5WGmcnfc86IA076uGGLS5mBCXJ8Zf8yWX4pWYYT ZMvXipopnArDnW9jL7tdG3kEvHvuymIterRk8ud3Xv4bZjaVXcoT3ptvIkn1 L9JAGNrCr9YnHsMZBGiPsNCKjNBa3tswTfRFlgSMUEiTf9XfozbGUJA-- Received: from [66.92.43.99] by web140904.mail.bf1.yahoo.com via HTTP; Wed, 29 Oct 2014 03:18:38 PDT X-Rocket-MIMEInfo: 002.001, QnVpbHQgd2l0aCBjbGFuZy4uLiBub25lIG9mIHRoZSBwcm9ibGVtcyAoc28gZmFyKSBmcm9tIHRoZSBwcmV2aW91cyBidWlsZHMgYXBwZWFyIHRvIGV4aXN0IGZyb20NCmluaXRpYWwgdGVzdGluZyBvZiBwa2cgYW5kIG9mIGEgcG9ydCBpbnN0YWxsLg0KdjkgDQpoYWQgdG8gdXNlIC1ERk9SQ0VfUEtHX1JFR0lTVEVSIHRob3VnaC4uLgEwAQEBAQ-- X-Mailer: YahooMailClassic/810 YahooMailWebService/0.8.203.733 Message-ID: <1414577918.99001.YahooMailBasic@web140904.mail.bf1.yahoo.com> Date: Wed, 29 Oct 2014 03:18:38 -0700 From: Jeffrey Bouquet Subject: pkg-devel-1.4.0-a3 works good so far To: current@freebsd.org, ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 29 Oct 2014 11:28:53 +0000 Cc: bapt@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 10:18:45 -0000 Built with clang... none of the problems (so far) from the previous builds appear to exist from initial testing of pkg and of a port install. v9 had to use -DFORCE_PKG_REGISTER though... From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 12:13:35 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F25C843; Wed, 29 Oct 2014 12:13:35 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEFC0EEE; Wed, 29 Oct 2014 12:13:34 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XjS7y-000P4t-Aw; Wed, 29 Oct 2014 16:13:26 +0400 Date: Wed, 29 Oct 2014 16:13:26 +0400 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029121326.GA83878@zxy.spb.ru> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 12:13:35 -0000 On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote: > Hi all, > > We are starting the release process of pkg 1.4, we want to have a better release > process than with every single previous version of pkg. For that we will need > you help! I have issuse, but I am not test on 1.4. I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version. pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache). > pkg-devel has been updated to the latest version of pkg as of alpha2. > > Changes you can expect in pkg 1.4 are the following: > - Loads of bug fixes > - Stricter checking of the path passed via the plist > - Removal of the bundled libyaml > - new --raw-format to chose the output format for info -R and search -R > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64) > the old ABI is available as a fallback in ALTABI linux packages still freebsd:10:x86:32 ? > - pkg check now support a quiet mode > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging > configuration files > - new @config keyword to mark a file as a config file (during > upgrade/reinstallation it will try to merge the configuration with the one the > user may have modified) an option AUTOMERGE is available to prevent > automerging if automerge fails a .pkgnew file will be created along with the > untouched user version of the configuration > - The update procedure has been improved and speed up a lot (in particular for > machine with low resources) > - The unique identifier has been modified to be pkgname meaning now ports can be > moved in new categories without having to be considered a different package > - Only libraries starting by lib* are added to the provided libraries > - General speed up of all operations > > We need help in testing, but we also need help in writing regression tests ! > The more we have tests the more stable the releases will be. > > The release will also allow to be able to package base! > > regards, > Bapt From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 12:24:58 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 453B5CB9; Wed, 29 Oct 2014 12:24:58 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5F2775; Wed, 29 Oct 2014 12:24:57 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id d1so1518710wiv.7 for ; Wed, 29 Oct 2014 05:24:55 -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=ZpzEhJgtkNxDVFw3Nlo7dh4Z18AnC4nCk/JwT34C5+U=; b=xLAm+j2g9y9umkV6BftFs38DTbP9RcWJVQeN3JI2vNkVYMy+gkSNEEDuWLG4zMJCJf PaB5tCzOPj6ONpax1hbwCtgkK5HR91MVfPUVCCZxqRFJladpZuzGLIirjUqKD9Tho9DR 7iFAZwz8y2VkQQ/guF5emnLOoqu4bWo4wxE419APdU3Utakk6hUb9UNXqT+vijyhGyex dZUMYkyYgYma9qamv5obhQZ7S2cRKdr0qbZCHrVWPqkdywDTZdWUccOSXpF60FLTJVvJ JMrbLw0+ZZO8pCJ/jvRPC2tVVOkTpkZS9hwD1MrdeYxdW9Aolghbpz4w2BypvMVvkzZu uFYw== X-Received: by 10.180.82.170 with SMTP id j10mr20506725wiy.35.1414585495864; Wed, 29 Oct 2014 05:24:55 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id q5sm18563543wiy.16.2014.10.29.05.24.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 05:24:54 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 13:24:52 +0100 From: Baptiste Daroussin To: Slawa Olhovchenkov Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029122452.GH82736@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PW0Eas8rCkcu1VkF" Content-Disposition: inline In-Reply-To: <20141029121326.GA83878@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 12:24:58 -0000 --PW0Eas8rCkcu1VkF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote: > On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote: >=20 > > Hi all, > >=20 > > We are starting the release process of pkg 1.4, we want to have a bette= r release > > process than with every single previous version of pkg. For that we wil= l need > > you help! >=20 > I have issuse, but I am not test on 1.4. > I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version. > pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache= ). This is a problem with the port infrastructure for pecl >=20 > > pkg-devel has been updated to the latest version of pkg as of alpha2. > >=20 > > Changes you can expect in pkg 1.4 are the following: > > - Loads of bug fixes > > - Stricter checking of the path passed via the plist > > - Removal of the bundled libyaml > > - new --raw-format to chose the output format for info -R and search -R > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10= :amd64) > > the old ABI is available as a fallback in ALTABI >=20 > linux packages still freebsd:10:x86:32 ? Yes for now, we plan to change that later. regards, Bapt --PW0Eas8rCkcu1VkF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQ3JQACgkQ8kTtMUmk6Ex0VQCfQdY45TjsJDDlgBGmaog6M7no bOIAn0xiMkMmN1eUnwJnuLcr8T4u6a+U =6DAi -----END PGP SIGNATURE----- --PW0Eas8rCkcu1VkF-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 12:31:59 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C23CCED1; Wed, 29 Oct 2014 12:31:59 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CFAE179; Wed, 29 Oct 2014 12:31:59 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XjSPt-000PNy-JB; Wed, 29 Oct 2014 16:31:57 +0400 Date: Wed, 29 Oct 2014 16:31:57 +0400 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029123157.GI9763@zxy.spb.ru> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029122452.GH82736@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 12:31:59 -0000 On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote: > On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote: > > On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote: > > > > > Hi all, > > > > > > We are starting the release process of pkg 1.4, we want to have a better release > > > process than with every single previous version of pkg. For that we will need > > > you help! > > > > I have issuse, but I am not test on 1.4. > > I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version. > > pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache). > > This is a problem with the port infrastructure for pecl What problem? deps: { php55-session: { origin: "www/php55-session", version: "5.5.17_1" }, php55: { origin: "lang/php55", version: "5.5.17_1" }, php55-zlib: { origin: "archivers/php55-zlib", version: "5.5.17_1" } } > > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > > > > > Changes you can expect in pkg 1.4 are the following: > > > - Loads of bug fixes > > > - Stricter checking of the path passed via the plist > > > - Removal of the bundled libyaml > > > - new --raw-format to chose the output format for info -R and search -R > > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64) > > > the old ABI is available as a fallback in ALTABI > > > > linux packages still freebsd:10:x86:32 ? > > Yes for now, we plan to change that later. > > regards, > Bapt From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 12:40:31 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D6871AE; Wed, 29 Oct 2014 12:40:31 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F083D25A; Wed, 29 Oct 2014 12:40:30 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id n3so1421775wiv.4 for ; Wed, 29 Oct 2014 05:40:29 -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=TYNhSI/WIbLAJf+0A5qEJKYNvGRu2tCD3lK81GSvYF0=; b=jLrW2h95ud9I/yiJtAF/OcFR1VN1CvAW0huHf3HKTwRoBb5VVuUxclqPf6aBgFqcz4 8Vg885pRih6VBbzdhGWl/QGC3tixL2wNJ7sLpiRHQTHCjM0x0u6fgfxVWbOJbSNOVyIn BK1NTt1eqdfvVutoM+1x3B3NmTr00CvCaffsWus/HVd7tX/HomwPkbPjo1m3iXq8jr9o s4IUj2qum+wiK3LiKhsLetXVjuKVwMjSX/+AaxtM5a5/a9Kt02QPnHwfEf3rcc/0mZfZ BCYdKqP2/vxYvyv28uRp6VX4NaIm7S/iwq79whr/pSx/o2Hmqkg+/AkCQ8JaiPHHle5K pbHA== X-Received: by 10.181.8.98 with SMTP id dj2mr12301541wid.70.1414586429211; Wed, 29 Oct 2014 05:40:29 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id p3sm5040334wjf.49.2014.10.29.05.40.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 05:40:28 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 13:40:25 +0100 From: Baptiste Daroussin To: Slawa Olhovchenkov Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029124025.GI82736@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZOudaV4lSIjFTlHv" Content-Disposition: inline In-Reply-To: <20141029123157.GI9763@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 12:40:31 -0000 --ZOudaV4lSIjFTlHv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 04:31:57PM +0400, Slawa Olhovchenkov wrote: > On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote: >=20 > > On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote: > > > On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote: > > >=20 > > > > Hi all, > > > >=20 > > > > We are starting the release process of pkg 1.4, we want to have a b= etter release > > > > process than with every single previous version of pkg. For that we= will need > > > > you help! > > >=20 > > > I have issuse, but I am not test on 1.4. > > > I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version. > > > pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memc= ache). > >=20 > > This is a problem with the port infrastructure for pecl >=20 > What problem? >=20 > deps: { > php55-session: { > origin: "www/php55-session", > version: "5.5.17_1" > }, > php55: { > origin: "lang/php55", > version: "5.5.17_1" > }, > php55-zlib: { > origin: "archivers/php55-zlib", > version: "5.5.17_1" > } > } >=20 How can we know pecl-memcache has to be reinstalled? We won't reinstall each time a version of a dep changes :) regards, Bapt --ZOudaV4lSIjFTlHv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQ4DkACgkQ8kTtMUmk6Ew2ngCggQWHhYL5/Wt9pTcWdURGmaia 5SUAnAw1x9136A9IgpKUcAIUrkV4Rs+R =sNwW -----END PGP SIGNATURE----- --ZOudaV4lSIjFTlHv-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 12:48:34 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53E5B434; Wed, 29 Oct 2014 12:48:34 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CE732E0; Wed, 29 Oct 2014 12:48:34 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XjSfw-000Pe3-5Z; Wed, 29 Oct 2014 16:48:32 +0400 Date: Wed, 29 Oct 2014 16:48:32 +0400 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029124832.GJ9763@zxy.spb.ru> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029124025.GI82736@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 12:48:34 -0000 On Wed, Oct 29, 2014 at 01:40:25PM +0100, Baptiste Daroussin wrote: > On Wed, Oct 29, 2014 at 04:31:57PM +0400, Slawa Olhovchenkov wrote: > > On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote: > > > > > On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote: > > > > On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote: > > > > > > > > > Hi all, > > > > > > > > > > We are starting the release process of pkg 1.4, we want to have a better release > > > > > process than with every single previous version of pkg. For that we will need > > > > > you help! > > > > > > > > I have issuse, but I am not test on 1.4. > > > > I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change version. > > > > pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache). > > > > > > This is a problem with the port infrastructure for pecl > > > > What problem? > > > > deps: { > > php55-session: { > > origin: "www/php55-session", > > version: "5.5.17_1" > > }, > > php55: { > > origin: "lang/php55", > > version: "5.5.17_1" > > }, > > php55-zlib: { > > origin: "archivers/php55-zlib", > > version: "5.5.17_1" > > } > > } > > > How can we know pecl-memcache has to be reinstalled? > > We won't reinstall each time a version of a dep changes :) And what is solution? May be some flag on package (php) for reinstall all deps? From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 12:53:10 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0587062F; Wed, 29 Oct 2014 12:53:10 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 678A43B8; Wed, 29 Oct 2014 12:53:09 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id m15so1807816wgh.27 for ; Wed, 29 Oct 2014 05:53:07 -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=LzfnkgYvGJbhsxW1t0hZmwiJ39Wd9RvdhxawIKFU7W8=; b=ZFRnpxgul8ejpIonCbWzuocwUD/tsGs6NUGt7luMmr3LKF5qwE45b9G0riDCe2QNk1 RLFaUVqNaioX6R7NdmoYFrgeaPm6GEDzAnJdUKtVsUMD8Wq+a+xle27TsGI5j2jRTvkW qF/zXrCcpARKq69CmsZRclqfH+bo+SD83kFCaSkypzvDXNRiWPPkE5i1/Qlc6jknS6CX 8GSGoI86bEn6cTVH7Ta9Cebaj7RyezDKgkO2thSX3CsyFoZMgfo1G3llmnSAjm5TYx1W FuJdBevuL4dK+vMksmtEf7UWAHIpsTb+NLlRImim1t09aEWtC4ZpTG3qBD4+B8amnw04 zAOw== X-Received: by 10.194.110.167 with SMTP id ib7mr12459456wjb.95.1414587187716; Wed, 29 Oct 2014 05:53:07 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id ua8sm5121429wjc.7.2014.10.29.05.53.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 05:53:06 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 13:53:04 +0100 From: Baptiste Daroussin To: Slawa Olhovchenkov Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029125304.GJ82736@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlxN1C6awaFNesUv" Content-Disposition: inline In-Reply-To: <20141029124832.GJ9763@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 12:53:10 -0000 --UlxN1C6awaFNesUv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 04:48:32PM +0400, Slawa Olhovchenkov wrote: > On Wed, Oct 29, 2014 at 01:40:25PM +0100, Baptiste Daroussin wrote: >=20 > > On Wed, Oct 29, 2014 at 04:31:57PM +0400, Slawa Olhovchenkov wrote: > > > On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote: > > >=20 > > > > On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote: > > > > > On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrot= e: > > > > >=20 > > > > > > Hi all, > > > > > >=20 > > > > > > We are starting the release process of pkg 1.4, we want to have= a better release > > > > > > process than with every single previous version of pkg. For tha= t we will need > > > > > > you help! > > > > >=20 > > > > > I have issuse, but I am not test on 1.4. > > > > > I upgrade php (5.5.15 -> 5.5.17), pecl-memcache don't change vers= ion. > > > > > pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-= memcache). > > > >=20 > > > > This is a problem with the port infrastructure for pecl > > >=20 > > > What problem? > > >=20 > > > deps: { > > > php55-session: { > > > origin: "www/php55-session", > > > version: "5.5.17_1" > > > }, > > > php55: { > > > origin: "lang/php55", > > > version: "5.5.17_1" > > > }, > > > php55-zlib: { > > > origin: "archivers/php55-zlib", > > > version: "5.5.17_1" > > > } > > > } > > >=20 > > How can we know pecl-memcache has to be reinstalled? > >=20 > > We won't reinstall each time a version of a dep changes :) >=20 > And what is solution? > May be some flag on package (php) for reinstall all deps? I do have no idea, I'm open for suggestions :) Either on the package side with triggers but that means implementing trigge= r in package Or in package side with provide/requires saying that this packages requires= an exact version of php meaning in case of upgrade of php the version would ha= ve changed Or someone has to be clever and find a ports only solution. Why the help does a minor version has an inpact on the pecl? isn't the abi stable over minor versions? regards, Bapt --UlxN1C6awaFNesUv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQ4zAACgkQ8kTtMUmk6EzWcACfWfdrb/JsKM9fdu/tbz/CyXT8 KP8AnjJEGilcNxEk4BTUukAWbWS/n284 =WKUx -----END PGP SIGNATURE----- --UlxN1C6awaFNesUv-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 13:03:51 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ACE0930; Wed, 29 Oct 2014 13:03:51 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33B9E6C0; Wed, 29 Oct 2014 13:03:51 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XjSuj-000Ps5-5i; Wed, 29 Oct 2014 17:03:49 +0400 Date: Wed, 29 Oct 2014 17:03:49 +0400 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029130348.GK9763@zxy.spb.ru> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> <20141029125304.GJ82736@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029125304.GJ82736@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 13:03:51 -0000 On Wed, Oct 29, 2014 at 01:53:04PM +0100, Baptiste Daroussin wrote: > > > How can we know pecl-memcache has to be reinstalled? > > > > > > We won't reinstall each time a version of a dep changes :) > > > > And what is solution? > > May be some flag on package (php) for reinstall all deps? > > I do have no idea, I'm open for suggestions :) > Either on the package side with triggers but that means implementing trigger in > package > Or in package side with provide/requires saying that this packages requires an > exact version of php meaning in case of upgrade of php the version would have > changed May be (as workaround) some database witch this packages? List, or regexp. This is need for some binary modules and don't need for "text" modules. But for some cases -- and for "text" modules too. > Or someone has to be clever and find a ports only solution. On ports side pecl-memcache rebuild on php version changed. > Why the help does a minor version has an inpact on the pecl? isn't the abi > stable over minor versions? I am don't know -- I am not php guru. As result -- memcache module don't loaded and "class Memcache not found". May be just strict version check. From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 13:12:39 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB7C8DE1; Wed, 29 Oct 2014 13:12:39 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2C2B843; Wed, 29 Oct 2014 13:12:38 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so1640574wib.17 for ; Wed, 29 Oct 2014 06:12:37 -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=B5AjjUdVgrVrONZVkw4klMmj0H0XRaaXL2UmDMVmi78=; b=O/RcT0oCbkuz6EVvCAFbhFAMGHUmVynTLk3vJXp28TUe72ALuWzEsvE3tumXwILoM5 8CCTDPHoDPSBKnXSBBLjUt36BqrSZHpX9r2GCYKV7PbNKWnDRMOX9xCrWqBsGXnTiYjk 4/PAGGQHPCvJZacCK0Dq5GnkrII7kaUhW6ueCKK76rJm2OtS2BOOHFBGVT0TpV9UdA7R tOLDiohjJSfivPG4ErI4LYEcNDfEaN9RqDFpykK3on4SZw9fgBBl0uEMzyofJRCBJogR GkgcuDDlCaqlsNnA11iMiPUEkNZVwEpGDRtg+KKXGLr29qwKZQTLX0i2URGRUaJe6Xgf 0IdA== MIME-Version: 1.0 X-Received: by 10.194.81.6 with SMTP id v6mr12245634wjx.39.1414588357144; Wed, 29 Oct 2014 06:12:37 -0700 (PDT) Received: by 10.194.223.1 with HTTP; Wed, 29 Oct 2014 06:12:37 -0700 (PDT) In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> Date: Wed, 29 Oct 2014 14:12:37 +0100 Message-ID: Subject: Re: pkg 1.4 freeze please test test test! From: Cristiano Deana To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Cc: ports@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 13:12:39 -0000 On Wed, Oct 29, 2014 at 12:19 AM, Baptiste Daroussin wrote: Hi Baptiste, > We are starting the release process of pkg 1.4, we want to have a better release > process than with every single previous version of pkg. For that we will need > you help! glad to help. I'd like to test it on a 10 system, so I suppose I have to install ports-mgmt/pkg-devel Can we test it now, then remove it when 1.4 will be in -RELEASE or -STABLE? Thank you -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 13:34:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF851378 for ; Wed, 29 Oct 2014 13:34:11 +0000 (UTC) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7B49AA37 for ; Wed, 29 Oct 2014 13:34:11 +0000 (UTC) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id B18A814B0C3 for ; Wed, 29 Oct 2014 14:28:09 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id pUh0OX-fatNM for ; Wed, 29 Oct 2014 14:28:05 +0100 (CET) Received: from hosting.syscare.sk (hosting [188.40.39.37]) by services.syscare.sk (Postfix) with ESMTP id AA04314B0BA for ; Wed, 29 Oct 2014 14:28:05 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Oct 2014 14:28:05 +0100 From: Daniel Gerzo To: freebsd-current@freebsd.org Subject: Re: pkg 1.4 freeze please test test test! Organization: The FreeBSD Project In-Reply-To: <20141029125304.GJ82736@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> <20141029125304.GJ82736@ivaldir.etoilebsd.net> Message-ID: <7335fc556eaf4bce60a1b6373e348699@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 13:34:11 -0000 On 2014-10-29 13:53, Baptiste Daroussin wrote: >> > How can we know pecl-memcache has to be reinstalled? >> > >> > We won't reinstall each time a version of a dep changes :) >> >> And what is solution? >> May be some flag on package (php) for reinstall all deps? > > I do have no idea, I'm open for suggestions :) > Either on the package side with triggers but that means implementing > trigger in > package > Or in package side with provide/requires saying that this packages > requires an > exact version of php meaning in case of upgrade of php the version > would have > changed > > Or someone has to be clever and find a ports only solution. This has been reported previously and the issue is bein tracked at https://github.com/freebsd/pkg/issues/585 It affects more then just pecl packages... -- Kind regards Daniel From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 13:40:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6921517; Wed, 29 Oct 2014 13:40:05 +0000 (UTC) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCE0A86; Wed, 29 Oct 2014 13:40:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 928AC577C4; Wed, 29 Oct 2014 14:39:53 +0100 (CET) Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8Fm4349zhwKQ; Wed, 29 Oct 2014 14:39:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 0180A576C1; Wed, 29 Oct 2014 14:39:45 +0100 (CET) X-Virus-Scanned: amavisd-new at galore.get.c.bitbit.net Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oH81D_2DLXRa; Wed, 29 Oct 2014 14:39:44 +0100 (CET) Received: from onyx.thanelange.no (cm-84.208.179.208.getinternet.no [84.208.179.208]) by galore.getmail.no (Postfix) with ESMTP id 8FA105643A; Wed, 29 Oct 2014 14:39:43 +0100 (CET) Date: Wed, 29 Oct 2014 14:38:50 +0100 From: Gyrd Thane Lange To: NGie Cooper Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Message-ID: <20141029143850.5af41378@onyx.thanelange.no> In-Reply-To: <20141029012432.41e22c7a@onyx.thanelange.no> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Ian Lepore , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 13:40:06 -0000 On Wed, 29 Oct 2014 01:24:32 +0100 Gyrd Thane Lange wrote: > On Tue, 28 Oct 2014 16:45:47 -0700 > NGie Cooper wrote: > > > On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange > > wrote: > > > On Tue, 28 Oct 2014 17:01:39 -0600 > > > Ian Lepore wrote: > > > > > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > > >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > >> > > >> Do a "make kernel-toolchain" which will build a new ctfconvert > > >> and put it in the right place within /usr/obj to be used during > > >> buildkernel. > > > > > > Thanks, I will try this (building now). But if it works I'll be > > > somewhat confused. I thought kernel-toolchain was implicit when > > > doing a full buildworld (which I've already done), and I already > > > have a ctfconvert > > > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). > > Finished a make kernel-toolchain (but it left me with even less > binaries than make buildworld): > > # find /usr/src/ /usr/obj -name ctfconvert -type f > (nothing found) > > > > The problem looks more like buildkernel is ignoring the ctfconvert > > > tool in /usr/obj/ and instead is expecting to find it in /usr/bin > > > (or some such). > > > > It should be located in /usr/obj -- we should not expect the > > tool in /usr/bin to be correct/compatible with the source tree. > > I agree. :) > > while waiting for a proper solution for this, I'll try looking at the > Makefiles and bsd.*.mk files under /usr/src my self, but I have never > looked at them before so I don't expect a speedy success. Discovered that the tools are set in /usr/src/share/mk/sys.mk: CTFCONVERT ?= ctfconvert CTFMERGE ?= ctfmerge DTRACE ?= dtrace I then set the following in my /etc/src.conf (NB! long lines): CTFCONVERT=env LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf/ /usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert CTFMERGE=env LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf /usr/obj/usr/src/cddl/usr.bin/ctfmerge/ctfmerge DTRACE=env LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf:/usr/obj/usr/src/cddl/lib/libdtrace /usr/obj/usr/src/cddl/usr.sbin/dtrace/dtrace This allowed me to successfully build the kernel. Gyrd ^_^ > > Gyrd ^_^ > > > Cheers! > > _______________________________________________ > > 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" > _______________________________________________ > 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 Wed Oct 29 13:49:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F92D7F4; Wed, 29 Oct 2014 13:49:17 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE178B99; Wed, 29 Oct 2014 13:49:16 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so3346621wgg.5 for ; Wed, 29 Oct 2014 06:49:14 -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=7xZT3yNRK18VfQiev9m1JuH+Fq2wwiESYJAJLMpMhw8=; b=YtYmTclrCD8jAuNjqjWKRty4ZPdwSpzbu+1hgW/NhH4s/wzyGcuEO26mxOxjk+lL7x 0ziRBWLkVHEliEVZJS0AdE/pTP3Zk36nIZN/WcUAixBQMTNcX5nElzbsSaC1fFBG1QXl iOng8GdrvpRUxmyr59e0zyUswgWm4RJLeN42lPgPw8brqBvpbY9fRJWkqykTFDEw+5y6 QZflM3xfHJ0NLLvjPkoDjY9hXuCzO/J5+uSkfNdZ5JMpMgZ6ZjuBujGCtgbU9c0+MrvG q9ELsRKFS7tjyyemSboGbZxScgx3pzy8a10sxHEA0OpVF7f3uUzfnF3yaWvOAzZDWKCT TRyA== X-Received: by 10.194.191.163 with SMTP id gz3mr3490259wjc.114.1414590554793; Wed, 29 Oct 2014 06:49:14 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id f7sm5604309wiz.13.2014.10.29.06.49.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 06:49:13 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 14:49:11 +0100 From: Baptiste Daroussin To: Daniel Gerzo Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029134911.GK82736@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> <20141029125304.GJ82736@ivaldir.etoilebsd.net> <7335fc556eaf4bce60a1b6373e348699@rulez.sk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j/HO4hzKTNbM1mOX" Content-Disposition: inline In-Reply-To: <7335fc556eaf4bce60a1b6373e348699@rulez.sk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 13:49:17 -0000 --j/HO4hzKTNbM1mOX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 02:28:05PM +0100, Daniel Gerzo wrote: > On 2014-10-29 13:53, Baptiste Daroussin wrote: > >> > How can we know pecl-memcache has to be reinstalled? > >> > > >> > We won't reinstall each time a version of a dep changes :) > >>=20 > >> And what is solution? > >> May be some flag on package (php) for reinstall all deps? > >=20 > > I do have no idea, I'm open for suggestions :) > > Either on the package side with triggers but that means implementing=20 > > trigger in > > package > > Or in package side with provide/requires saying that this packages=20 > > requires an > > exact version of php meaning in case of upgrade of php the version=20 > > would have > > changed > >=20 > > Or someone has to be clever and find a ports only solution. >=20 > This has been reported previously and the issue is bein tracked at=20 > https://github.com/freebsd/pkg/issues/585 > It affects more then just pecl packages... What I would like is a technical description of what happen what are the symptoms and the real failure. I need to know how often we should reinstall the package depending on php e= very minor version? every medium version? Which one should be reinstalled? all pear? all pecl, anything using phpize? Right now the plan is to add the PHP_VERSION_ID to the version of the packa= ge using phpize so each time php is bumped then the version changed and it is reinstalled. For example: pecl-yaml-1.1.1 will become: pecl-yaml-1.1.1.50434 for 5.4.34 That is if only things using phpize needs to be reinstalled and that should= be fairly easy to do regards, Bapt --j/HO4hzKTNbM1mOX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQ8FcACgkQ8kTtMUmk6Ey3OQCfT01Fi7YwWRklaBxz+IOBLJ4Z TgAAnREJlgH9hSddWNAf3JqgiIl0/eqE =XbpW -----END PGP SIGNATURE----- --j/HO4hzKTNbM1mOX-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 13:53:56 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D4A19C7; Wed, 29 Oct 2014 13:53:56 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B0C8C5C; Wed, 29 Oct 2014 13:53:55 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id n12so3378695wgh.2 for ; Wed, 29 Oct 2014 06:53:54 -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=8uDBwHz4WUgvkQbiCpwfiD3S5ovPiPEejHBTgt5pjn0=; b=PfcuRpK9m6yS18/umjsgbHEfbffHJr/DTykgjId0Y7A7D4PB74lhEyWvK3AwofYIuQ WJXPH1U2nCHJyEvYGBlSzmBZ/NbrCwRiHJkWVWq7qTV420SIx9f8Ev7NmQuUyH56kA2Z f54iJDt8zBs1FjZvs51xJy4p0NoAlJ8w8PiPgTA4hf4Rf+eIEXPTnaizkix5I7KqM38/ WpBC3h2z5wzwMhXJfMAMSDcbby9RYIkIMb8km570MZNqWw8nOLVOFkDDoBMJuan45LY7 0w+Eoo9Nki7B9OVrA8b88cfiU+iYdLmPBT7nGxAiTJ098cwVJFrbgq6VUZXd/YJvn2RE 8UJw== X-Received: by 10.194.122.104 with SMTP id lr8mr12960977wjb.28.1414590834300; Wed, 29 Oct 2014 06:53:54 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id l5sm5633859wif.3.2014.10.29.06.53.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 06:53:53 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 14:53:51 +0100 From: Baptiste Daroussin To: Cristiano Deana Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029135351.GA9726@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 13:53:56 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 02:12:37PM +0100, Cristiano Deana wrote: > On Wed, Oct 29, 2014 at 12:19 AM, Baptiste Daroussin w= rote: >=20 > Hi Baptiste, >=20 > > We are starting the release process of pkg 1.4, we want to have a bette= r release > > process than with every single previous version of pkg. For that we wil= l need > > you help! >=20 > glad to help. > I'd like to test it on a 10 system, so I suppose I have to install > ports-mgmt/pkg-devel >=20 > Can we test it now, then remove it when 1.4 will be in -RELEASE or -STABL= E? >=20 yes remove the current pkg pkg delete -f pkg install ports-mgmt/pkg-devel (adding WITH_PKG=3Ddevel in make.conf) use it when you want to go back to stable when 1.4 will be out: pkg delete pkg pkg bootstrap regards, Bapt --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQ8W8ACgkQ8kTtMUmk6ExJcgCdEDh0yxGxTTLkuav03FyNqzK6 s3EAoMLVhbjhPinqVoCAwEtk/nv49XbH =wFYd -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 14:07:21 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8EAEC6F; Wed, 29 Oct 2014 14:07:20 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CFAD6A; Wed, 29 Oct 2014 14:07:20 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id z12so1947492wgg.23 for ; Wed, 29 Oct 2014 07:07:17 -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=vIznOSIsRDGaSSkCXMy5IyKzJPqQ6AP5Q5JqM1WTc84=; b=QDaqAjfphp6cJA4FUgZ2Wu6QxkcqhGlkpHyz3GmFFHd3o8sKMfmdL6lxtLMtPawGUi id+OYknKSkMGcSiDU1+c4W3DDi5DuOsW2u47MuxFnv6aEl2/y1VCBmoOBIwCG2B6AmOm CBUOSvNk46HXWX9u0BjcxyBENX9eHx/IfL/ajFmfa3DjiPCA4dyR5ArA9cSyD2kHkg9D DzUULnKLZEUhDF+jI599tCFsndW4JBrGcV+QGeKQnqUK+FsLNO2tm1aQTiwoU3iUsCtT cmZZmXvxZ3w37mGEiKtCeOMOTvewZ4tGnFiIdwKuYVefSrOPH1HCgM+jPVojML+xmm48 oyCQ== X-Received: by 10.194.184.12 with SMTP id eq12mr13372568wjc.100.1414591637512; Wed, 29 Oct 2014 07:07:17 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id dq7sm5655224wid.12.2014.10.29.07.07.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 07:07:16 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 15:07:14 +0100 From: Baptiste Daroussin To: Slawa Olhovchenkov Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029140714.GB9726@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> <20141029125304.GJ82736@ivaldir.etoilebsd.net> <20141029130348.GK9763@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: <20141029130348.GK9763@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 14:07:21 -0000 --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 05:03:49PM +0400, Slawa Olhovchenkov wrote: > On Wed, Oct 29, 2014 at 01:53:04PM +0100, Baptiste Daroussin wrote: >=20 > > > > How can we know pecl-memcache has to be reinstalled? > > > >=20 > > > > We won't reinstall each time a version of a dep changes :) > > >=20 > > > And what is solution? > > > May be some flag on package (php) for reinstall all deps? > >=20 > > I do have no idea, I'm open for suggestions :) > > Either on the package side with triggers but that means implementing tr= igger in > > package > > Or in package side with provide/requires saying that this packages requ= ires an > > exact version of php meaning in case of upgrade of php the version woul= d have > > changed >=20 > May be (as workaround) some database witch this packages? > List, or regexp. >=20 > This is need for some binary modules and don't need for "text" > modules. > But for some cases -- and for "text" modules too. >=20 > > Or someone has to be clever and find a ports only solution. >=20 > On ports side pecl-memcache rebuild on php version changed. >=20 > > Why the help does a minor version has an inpact on the pecl? isn't the = abi > > stable over minor versions? >=20 > I am don't know -- I am not php guru. > As result -- memcache module don't loaded and "class Memcache not > found". > May be just strict version check. >=20 =46rom what I do read from here: https://wiki.php.net/rfc/releaseprocess#releases_cycle only going from X.Y to X.Y+1 needs to rebuild the extensions. and going from X.Y.Z to X.Y.Z+1 should be compatible regards, Bapt --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQ9JIACgkQ8kTtMUmk6EzKAgCgtjowFND9IMV5vdSe5ZqFkbRr edgAn1okxEy8ePH4HdP17bWCSZy0ocj0 =Ywa8 -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 14:18:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E5CDF7C; Wed, 29 Oct 2014 14:18:07 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C56D5E7E; Wed, 29 Oct 2014 14:18:06 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id a13so1324567igq.17 for ; Wed, 29 Oct 2014 07:18:06 -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:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=oV462S6zsZba/7Nq1Tk83Nh+iI6CX3qXEeO7eh8vVRM=; b=j7lVR4Lq4KXLk9tvv7glfrqtYF2QzyLvs6cKtz9PWPsvLidBEmO5wnsoG070z8/GPk cngZFExsdjHZSOpHIuysgSHrCUrMzCbJRmBEuDIu4j3mgF4klyy7R0/sBXtHkjfTapmh Bs+q9NyPwKSnQLS2GLLcnSXUybh/Y7vqe4HgmnyW3jigUTs3Je6Pk8hOrGxHZp0p4fUz TBcYahuf1y1t1fXoOAReOmtGhR5Vp+eCtMQpMix2sOMxhcDf1TiQkYeEfDn9qoV44z2v AFgfv4lD0Bwcf98WnesxCzrLkI1Q1oLE4ZRuKqoXYWA6yzGcgxj69yRGeoxfGG24AYl9 m2Zg== X-Received: by 10.50.79.232 with SMTP id m8mr38423351igx.11.1414592275112; Wed, 29 Oct 2014 07:17:55 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.132 with HTTP; Wed, 29 Oct 2014 07:17:33 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Wed, 29 Oct 2014 10:17:33 -0400 X-Google-Sender-Auth: mlAFz4FItTbExGJPmXuExvOGsnI Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: David Chisnall Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kevin Oberman , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 14:18:07 -0000 On 29 October 2014 05:05, David Chisnall wrote: > On 29 Oct 2014, at 03:11, Ed Maste wrote: > >> /usr/lib/debug is the standard location for standalone debug data >> established by GDB, and seems like a decent enough location. I'll make >> sure to update the man page. > > Do gdb and lldb also look in /usr/local/lib/debug? If not, it would be g= reat if we could at least teach lldb to do this so that we can start thinki= ng about splitting debug info into separate packages for ports (and providi= ng it as an optional install for everything). Not yet, but it's trivial to add for at least LLDB. My end goal is what you describe - kernel, base system userland, and packages/ports can all provide standalone debug packages which will install to a consistent and well-known location, and be picked up automatically by the debugger. Part of this project depends on moving past our old binutils though, so we can start using the build-id ELF note to link the executable or library with its associated debug data. From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 14:20:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEDDF130; Wed, 29 Oct 2014 14:20:47 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06CAEF25; Wed, 29 Oct 2014 14:20:46 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id z12so1982427wgg.37 for ; Wed, 29 Oct 2014 07:20:45 -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=k+JibDu2Fr6H6CKc3p3k+zEQ8pYWE0JKRxv32UFDgPk=; b=HejJg4s+eFNvByXXfJuoayCvzdcI6VdM/teuOYAkp+0UsddvZOmlTncnpCjNjRIhSg iA42FGEPjF9uHNvBSlDjglT/KjvV9cvR8luhx7ZEVDbTiqvrH5NGuLgsTsatwWK2QDk9 OIiqcTgwyXfxRCxS5F57py5bRwFqkYSHHTJbQpi62idwCgNoO2dg+BmXse0lWBqbPnTZ E7CL4kZIGmYEPBLZVu15FTC3dLo0/lQjrcNidMxwkzxySmKGf07tDnJ1lEzY33jKsBp5 jcZrQxmf7lWLwQVec7IqC4Te1dHCVXt7Ru1FRRQUiVJ1loZAs6bLO7mwFtH3Q9K93674 dC2g== X-Received: by 10.194.48.84 with SMTP id j20mr12861529wjn.35.1414592445325; Wed, 29 Oct 2014 07:20:45 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id r10sm1793317wiy.19.2014.10.29.07.20.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 07:20:44 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 15:20:42 +0100 From: Baptiste Daroussin To: Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Message-ID: <20141029142042.GC9726@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Kevin Oberman , FreeBSD Current , David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 14:20:47 -0000 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 10:17:33AM -0400, Ed Maste wrote: > On 29 October 2014 05:05, David Chisnall wrote: > > On 29 Oct 2014, at 03:11, Ed Maste wrote: > > > >> /usr/lib/debug is the standard location for standalone debug data > >> established by GDB, and seems like a decent enough location. I'll make > >> sure to update the man page. > > > > Do gdb and lldb also look in /usr/local/lib/debug? If not, it would be= great if we could at least teach lldb to do this so that we can start thin= king about splitting debug info into separate packages for ports (and provi= ding it as an optional install for everything). >=20 > Not yet, but it's trivial to add for at least LLDB. My end goal is > what you describe - kernel, base system userland, and packages/ports > can all provide standalone debug packages which will install to a > consistent and well-known location, and be picked up automatically by > the debugger. >=20 > Part of this project depends on moving past our old binutils though, > so we can start using the build-id ELF note to link the executable or > library with its associated debug data. Port debuginfo packages are coming sooner than later so yeah lldb reading a default standard location in localbase would be nice :) regards, Bapt --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQ97oACgkQ8kTtMUmk6Eys5wCdHA7Ofh5Bao65bU5A/4K0XffZ 668An3Nt/1tFf/486u/fv64mFGGZbaMA =MahV -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 14:42:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D2C64CD; Wed, 29 Oct 2014 14:42:26 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A7F71B5; Wed, 29 Oct 2014 14:42:25 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjUS7-000H7e-RV; Wed, 29 Oct 2014 14:42:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9TEgMJ3080879; Wed, 29 Oct 2014 08:42:22 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/B4Sc1bh6kg2sohNRodivT X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) From: Ian Lepore To: Gyrd Thane Lange In-Reply-To: <20141029143850.5af41378@onyx.thanelange.no> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Oct 2014 08:42:22 -0600 Message-ID: <1414593742.17308.72.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , NGie Cooper , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 14:42:26 -0000 On Wed, 2014-10-29 at 14:38 +0100, Gyrd Thane Lange wrote: > On Wed, 29 Oct 2014 01:24:32 +0100 > Gyrd Thane Lange wrote: > > > On Tue, 28 Oct 2014 16:45:47 -0700 > > NGie Cooper wrote: > > > > > On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange > > > wrote: > > > > On Tue, 28 Oct 2014 17:01:39 -0600 > > > > Ian Lepore wrote: > > > > > > > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > > > >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > > >> > > > >> Do a "make kernel-toolchain" which will build a new ctfconvert > > > >> and put it in the right place within /usr/obj to be used during > > > >> buildkernel. > > > > > > > > Thanks, I will try this (building now). But if it works I'll be > > > > somewhat confused. I thought kernel-toolchain was implicit when > > > > doing a full buildworld (which I've already done), and I already > > > > have a ctfconvert > > > > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). > > > > Finished a make kernel-toolchain (but it left me with even less > > binaries than make buildworld): > > > > # find /usr/src/ /usr/obj -name ctfconvert -type f > > (nothing found) > > > > > > The problem looks more like buildkernel is ignoring the ctfconvert > > > > tool in /usr/obj/ and instead is expecting to find it in /usr/bin > > > > (or some such). > > > > > > It should be located in /usr/obj -- we should not expect the > > > tool in /usr/bin to be correct/compatible with the source tree. > > > > I agree. :) > > > > while waiting for a proper solution for this, I'll try looking at the > > Makefiles and bsd.*.mk files under /usr/src my self, but I have never > > looked at them before so I don't expect a speedy success. > > Discovered that the tools are set in /usr/src/share/mk/sys.mk: > > CTFCONVERT ?= ctfconvert > CTFMERGE ?= ctfmerge > DTRACE ?= dtrace > > I then set the following in my /etc/src.conf (NB! long lines): > > CTFCONVERT=env > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf/ /usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert > CTFMERGE=env > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf /usr/obj/usr/src/cddl/usr.bin/ctfmerge/ctfmerge > DTRACE=env > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf:/usr/obj/usr/src/cddl/lib/libdtrace /usr/obj/usr/src/cddl/usr.sbin/dtrace/dtrace > > This allowed me to successfully build the kernel. > The important question to be asking at this point: Why are you the only person in the world who has had to do this? Until you have an answer to that, nothing is really fixed. The thing that's different for you than for most people, I guess, is that you originally built the system WITHOUT_CDDL then removed that option. That's almost certainly a factor somehow. Also, the copy of the tool within obj that it should use is not the copy you manually pointed to with those changes. When newer build tools are needed, they exist within /usr/obj/usr/src/tmp/. So... why doesn't ctfconvert exist for you in that location after making kernel-toolchain? -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 16:02:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BB64F40; Wed, 29 Oct 2014 16:02:22 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01087DF1; Wed, 29 Oct 2014 16:02:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C721AB986; Wed, 29 Oct 2014 12:02:20 -0400 (EDT) From: John Baldwin To: Eitan Adler Subject: Re: junior kernel tasks Date: Wed, 29 Oct 2014 11:55:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141025204536.GD19066@dft-labs.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201410291155.53950.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Oct 2014 12:02:20 -0400 (EDT) Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 16:02:22 -0000 On Tuesday, October 28, 2014 7:07:31 pm Eitan Adler wrote: > On 28 October 2014 15:14, Baptiste Daroussin wrote: > > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: > >> > >> Quoting John Baldwin : > >> > >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > >> >> Hello, > >> >> > >> >> In short, nice kernel tasks people with C language skills can do in few > >> >> evenings. > >> >> > >> >> https://wiki.freebsd.org/JuniorJobs > >> >> > >> >> It is assumed you know how to obtain sources and build the kernel. > >> >> > >> >> What you can get in return: > >> >> - your own code in FreeBSD tree > >> >> - eternal glory [1] > >> >> - fun [2] > >> >> > >> >> If you are not interested, but know someone who does, please pass it > >> >> down. > >> >> > >> >> [1] - not really, no > >> >> [2] - well, I guess that's subjective, so that's not a "no" > >> > > >> > Even though our bugmeisters have decided that we should not have wishlist > >> > items in our bug tracker, I really wish we could store the various idea lists > >> > (we have several) in an issue tracker instead. This would allow for folks to > >> > comment on ideas, vote for them, etc. It would also make it easier for more > >> > people to submit new ideas. > >> > > >> > >> Speaking not strictly with the bugmeister hat, but from experience, please do > >> not let us go down the road of (ab)using a bug tracking solution as task and > >> idea management system. I think that using the tasks feature of phabricator > >> (our reviews instance) would provide better workflow support for those things, > >> starting out from sketching out rough ideas, discussing them, breaking them up > >> in seperate tasks (linked to and dependent on each other) and collaborating > >> on them (take a look at https://developer.blender.org/T42339 for a > >> brief example). > >> > >> Having said this, let's keep the bug tracker a bug tracker. > >> > >> Cheers > >> Marcus > > > > I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, > > but if we have a use for it I can activate it! > > > > Actually I do like the idea of the bug tracker aka bugzilla being only for bugs > > and uxe phabricator for tracking the tasks > > having disparate trackers for "wishlist" and "bugs" is quite harmful > and splits the conversations. It makes people learn multiple systems > and search multiple places - especially if the feature ends up being > submitted as a patch to the bug tracker. > > I'd rather keep wishlist items in the bug tracker than split them into two. > > (also, fwiw, I'd rather keep the tasks number space clean should we > ever decide to import from bugzilla -> phabricator) I'm not tied to a specific issue tracker to use for this and am happy to other folks debate which implementation is best, but what I would prefer is a system to let us manage "ideas to implement" like the ideas page for GSoC and this wiki page. The desired output is a list of vetted tasks. A task might start out as a wishlist entry, but someone has to step up and say "yes, this is a good idea and I will review it / shepherd it, etc." for it to become a "vetted task". Being able to store conversation about each task and tag it with other meta data (e.g. tagging the person who "owns" the task and will do the review / sheperding as well as being able to categorize them, etc.) However, I do think one important thing is that when a new idea is submitted, it has a built-in sunset. If no one grabs it after time X it becomes closed instead of remaining an open wishlist forever. Similarly if the "owner" of a task drops ownership, the timer would start while waiting for a new owner. However, this does feel very much like an issue tracker. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 16:11:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AA99597 for ; Wed, 29 Oct 2014 16:11:28 +0000 (UTC) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 45EBDE94 for ; Wed, 29 Oct 2014 16:11:28 +0000 (UTC) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 12B8514B993 for ; Wed, 29 Oct 2014 17:11:04 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id jbWenfvLClEs for ; Wed, 29 Oct 2014 17:10:58 +0100 (CET) Received: from hosting.syscare.sk (hosting [188.40.39.37]) by services.syscare.sk (Postfix) with ESMTP id 27F5714B98C for ; Wed, 29 Oct 2014 17:10:58 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Oct 2014 17:10:58 +0100 From: Daniel Gerzo To: freebsd-current@freebsd.org Subject: Re: pkg 1.4 freeze please test test test! Organization: The FreeBSD Project In-Reply-To: <20141029140714.GB9726@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> <20141029125304.GJ82736@ivaldir.etoilebsd.net> <20141029130348.GK9763@zxy.spb.ru> <20141029140714.GB9726@ivaldir.etoilebsd.net> Message-ID: X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 16:11:28 -0000 On 2014-10-29 15:07, Baptiste Daroussin wrote: > On Wed, Oct 29, 2014 at 05:03:49PM +0400, Slawa Olhovchenkov wrote: >> On Wed, Oct 29, 2014 at 01:53:04PM +0100, Baptiste Daroussin wrote: >> >> > > > How can we know pecl-memcache has to be reinstalled? >> > > > >> > > > We won't reinstall each time a version of a dep changes :) >> > > >> > > And what is solution? >> > > May be some flag on package (php) for reinstall all deps? >> > >> > I do have no idea, I'm open for suggestions :) >> > Either on the package side with triggers but that means implementing trigger in >> > package >> > Or in package side with provide/requires saying that this packages requires an >> > exact version of php meaning in case of upgrade of php the version would have >> > changed >> >> May be (as workaround) some database witch this packages? >> List, or regexp. >> >> This is need for some binary modules and don't need for "text" >> modules. >> But for some cases -- and for "text" modules too. >> >> > Or someone has to be clever and find a ports only solution. >> >> On ports side pecl-memcache rebuild on php version changed. >> >> > Why the help does a minor version has an inpact on the pecl? isn't the abi >> > stable over minor versions? >> >> I am don't know -- I am not php guru. >> As result -- memcache module don't loaded and "class Memcache not >> found". >> May be just strict version check. >> > > From what I do read from here: > https://wiki.php.net/rfc/releaseprocess#releases_cycle > > only going from X.Y to X.Y+1 needs to rebuild the extensions. > and going from X.Y.Z to X.Y.Z+1 should be compatible As far as I can tell from my own experience, every time I upgrade PHP, I always have to also reinstall pecl- packages, and even some other things like xcache, xdebug and so on. -- Kind regards Daniel From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 16:13:07 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7B7E6E3; Wed, 29 Oct 2014 16:13:07 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C9926F41; Wed, 29 Oct 2014 16:13:06 +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 SAA28935; Wed, 29 Oct 2014 18:11:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XjVqU-0000W8-NW; Wed, 29 Oct 2014 18:11:38 +0200 Message-ID: <54511184.2020600@FreeBSD.org> Date: Wed, 29 Oct 2014 12:10:44 -0400 From: Andriy Gapon User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ed Maste , David Chisnall Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 16:13:07 -0000 On 29/10/2014 10:17, Ed Maste wrote: > On 29 October 2014 05:05, David Chisnall wrote: >> On 29 Oct 2014, at 03:11, Ed Maste wrote: >> >>> /usr/lib/debug is the standard location for standalone debug data >>> established by GDB, and seems like a decent enough location. I'll make >>> sure to update the man page. >> >> Do gdb and lldb also look in /usr/local/lib/debug? If not, it would be great if we could at least teach lldb to do this so that we can start thinking about splitting debug info into separate packages for ports (and providing it as an optional install for everything). > > Not yet, but it's trivial to add for at least LLDB. My end goal is > what you describe - kernel, base system userland, and packages/ports > can all provide standalone debug packages which will install to a > consistent and well-known location, and be picked up automatically by > the debugger. > > Part of this project depends on moving past our old binutils though, > so we can start using the build-id ELF note to link the executable or > library with its associated debug data. Another part of the issue is DTrace tools that need to look for userland symbols. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 16:18:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9A4C852; Wed, 29 Oct 2014 16:18:17 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54A13F7C; Wed, 29 Oct 2014 16:18:17 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id m15so2275022wgh.13 for ; Wed, 29 Oct 2014 09:18:15 -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=ii+d558owmQJRX7IjTvYGZikML8JofBOIkqWUYsuPiE=; b=VlW8Gi3JtWJ2I5yg2y1N60iea+i/qNHw+TlZXbdf0aSb4aB4XQKWDBJ99Q3qxKBuut AtUfVMtvcO6BYOFgSUqO8yOLTQlPap5oRgnUrSmvjVsJsP0K4tc/MzEDTkDyGGTNObG0 zSEER2zJ7P2p09/AxSqEQy21DTs58FXxpmWv4KGXTHLWckxT4S2siOyLQaoQolM18ImW VGRe7gVyUzzj5wkrzN/7A/dD9zE6KoCN1UVDAXTAv2ye/VHoy4AP9QY2kAI/KVR4jaLo ZCa5obWPcwtqPlsLkOl5/w0MSnwg4AY4YCQynbh8SYunY5sxN/sb19WfBRK+mgarjC6h Dzfw== X-Received: by 10.194.60.109 with SMTP id g13mr12898245wjr.109.1414599495544; Wed, 29 Oct 2014 09:18:15 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id pc8sm5657882wjb.36.2014.10.29.09.18.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 09:18:14 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 17:18:12 +0100 From: Baptiste Daroussin To: Daniel Gerzo Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029161812.GA11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> <20141029125304.GJ82736@ivaldir.etoilebsd.net> <20141029130348.GK9763@zxy.spb.ru> <20141029140714.GB9726@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 16:18:18 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 05:10:58PM +0100, Daniel Gerzo wrote: > On 2014-10-29 15:07, Baptiste Daroussin wrote: > > On Wed, Oct 29, 2014 at 05:03:49PM +0400, Slawa Olhovchenkov wrote: > >> On Wed, Oct 29, 2014 at 01:53:04PM +0100, Baptiste Daroussin wrote: > >>=20 > >> > > > How can we know pecl-memcache has to be reinstalled? > >> > > > > >> > > > We won't reinstall each time a version of a dep changes :) > >> > > > >> > > And what is solution? > >> > > May be some flag on package (php) for reinstall all deps? > >> > > >> > I do have no idea, I'm open for suggestions :) > >> > Either on the package side with triggers but that means implementing= trigger in > >> > package > >> > Or in package side with provide/requires saying that this packages r= equires an > >> > exact version of php meaning in case of upgrade of php the version w= ould have > >> > changed > >>=20 > >> May be (as workaround) some database witch this packages? > >> List, or regexp. > >>=20 > >> This is need for some binary modules and don't need for "text" > >> modules. > >> But for some cases -- and for "text" modules too. > >>=20 > >> > Or someone has to be clever and find a ports only solution. > >>=20 > >> On ports side pecl-memcache rebuild on php version changed. > >>=20 > >> > Why the help does a minor version has an inpact on the pecl? isn't t= he abi > >> > stable over minor versions? > >>=20 > >> I am don't know -- I am not php guru. > >> As result -- memcache module don't loaded and "class Memcache not > >> found". > >> May be just strict version check. > >>=20 > >=20 > > From what I do read from here: > > https://wiki.php.net/rfc/releaseprocess#releases_cycle > >=20 > > only going from X.Y to X.Y+1 needs to rebuild the extensions. > > and going from X.Y.Z to X.Y.Z+1 should be compatible >=20 > As far as I can tell from my own experience, every time I upgrade PHP, I= =20 > always have to also reinstall pecl- packages, and even some other things= =20 > like xcache, xdebug and so on. >=20 Right it is not a pkg problem them but a port one. because same problem will occur with portmaster/portupgrade, the fix should= go in the ports tree, I have an idea will implement when I do have time. regards, Bapt --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRE0QACgkQ8kTtMUmk6ExargCfZWGOFJjxE/hIANVcMgZ6k1bj BjMAn1BCGdSM/eg45JTHFN3o+3tBy/be =E2Vk -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 16:19:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 624EBA79; Wed, 29 Oct 2014 16:19:00 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28D36FA8; Wed, 29 Oct 2014 16:19:00 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id bj1so3509196pad.3 for ; Wed, 29 Oct 2014 09:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=gVVKw9aiEXRVTKo0tO4REru0jQq17fVnTbm4NIMwjuo=; b=lPTS3oId3as/lN5Wo2WYOJ7kZ8Rjgb5JEVh9xJYHA8qmbSmn66lJC7urRSCR2BejsW ng5Jt5ourVrnZF6f8jEAKX+ahwis2MjwNRL8BzNt4V2Oj+lbSQxcDpGzzsICmM8XoGEO wAtL8ZkF8A/DUX2pVnmPydhyUuv5r60juGlklKYbPYQluu0RL/NuBUyx3RLGEyYlOPD2 rnQKy6vV0PAGpNIQE9t/GLAndpuQrGUSZ2fDKsT7qrYZWu6lt4xq5yQpDXCzE0FSrTPp K20mKqpm79GwTHHB5yMVLgN0kFT8Vaohrs3bMjJJjO9FoqKDLiVpeceUiIEnXZFyAcdN THUQ== X-Received: by 10.70.91.10 with SMTP id ca10mr11683027pdb.6.1414599539732; Wed, 29 Oct 2014 09:18:59 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:8571:b1b9:d19:9112? ([2601:8:ab80:7d6:8571:b1b9:d19:9112]) by mx.google.com with ESMTPSA id mo1sm4733341pbc.69.2014.10.29.09.18.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 09:18:58 -0700 (PDT) References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> <1414593742.17308.72.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1414593742.17308.72.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Date: Wed, 29 Oct 2014 09:18:58 -0700 To: Ian Lepore Cc: Gyrd Thane Lange , FreeBSD Current , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 16:19:00 -0000 > On Oct 29, 2014, at 07:42, Ian Lepore wrote: ... > Why are you the only person in the world who has had to do this? They're not the only one. $work is running into an issue where there's a mis= match between the host and build version which is generating corrupt ctf sec= tions. I thought it had been fixed on CURRENT recently, but the converse might be t= rue--it might have been broken because it's no longer being built as part of= the bootstrap tools process. My gut says that this section is prematurely optimizing it out of the build,= because it's assumed that the host tool will always be binary compatible wi= th the build tool: https://svnweb.freebsd.org/base/head/Makefile.inc1?annotate=3D273755#l1270= From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 16:04:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6511C32F for ; Wed, 29 Oct 2014 16:04:43 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25F21E2D for ; Wed, 29 Oct 2014 16:04:42 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id tr6so3327223ieb.32 for ; Wed, 29 Oct 2014 09:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webassign.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JIqT8nlbrphK3sI9MwqjRnrHiAbD2bNqW5jCQb3zWEU=; b=WK92Wq3LexuvbIYKP3PtaZ9Z4W25ViR/OKU+N4g7pzHyS8lxolTVogBNaDsStDRWQO RINY+OlqBi6Kx54MwIHHzre0Gnk23ZRsQH1ALfzECFuOX/asb31uz7oE3rASkU7crrBv JzetODCFEEPK3aPq9wGLdgPC8Owl6iRGtAWKg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JIqT8nlbrphK3sI9MwqjRnrHiAbD2bNqW5jCQb3zWEU=; b=Y/rJfRWilJNrjZd55dtJU045nKnqWOwvUi/tcsLMbUhuDSOpF8LsQrVeUm8xfJSiPK EoQx8N8UCNwFsbalPQP0IRf+LsidXXE+4wUK5ZN9jGLL4BNuenDrdDaoX/S4DRFDjecY KBdKA5NzM86xlakaoEoLLIB7eWy1fww3hmFM2huYZGvCBMW4iVzXqwmRqY0EpnaloVKY wmTD7o4RkQZxQYQnZqBUdLdJhhJpbN0nkBu/q18k71VxXvUPFye0rKlOvxihtGwdtk0T OetGHRMDLWwnXNJklmdJpN9vqHDx+t7IAWCnR74b+f7tHUfTkzBRkskQalsFfx6vbXVt EfrA== X-Gm-Message-State: ALoCoQlQydP9BUh+lMz+F4xOANezEZfUApvaUO486zeaW5jK2IG0F+1DZKMGa1gMabJ1gCsJPFeO X-Received: by 10.50.4.4 with SMTP id g4mr13855993igg.22.1414598682307; Wed, 29 Oct 2014 09:04:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.116 with HTTP; Wed, 29 Oct 2014 09:04:21 -0700 (PDT) In-Reply-To: <201410291155.53950.jhb@freebsd.org> References: <20141025204536.GD19066@dft-labs.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> <201410291155.53950.jhb@freebsd.org> From: Hunter Satterwhite Date: Wed, 29 Oct 2014 12:04:21 -0400 Message-ID: Subject: Re: junior kernel tasks To: John Baldwin X-Mailman-Approved-At: Wed, 29 Oct 2014 16:19:40 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , Eitan Adler , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 16:04:43 -0000 GitHub + Gitter? https://gitter.im/ On Wed, Oct 29, 2014 at 11:55 AM, John Baldwin wrote: > On Tuesday, October 28, 2014 7:07:31 pm Eitan Adler wrote: > > On 28 October 2014 15:14, Baptiste Daroussin wrote: > > > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: > > >> > > >> Quoting John Baldwin : > > >> > > >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > > >> >> Hello, > > >> >> > > >> >> In short, nice kernel tasks people with C language skills can do > in few > > >> >> evenings. > > >> >> > > >> >> https://wiki.freebsd.org/JuniorJobs > > >> >> > > >> >> It is assumed you know how to obtain sources and build the kernel. > > >> >> > > >> >> What you can get in return: > > >> >> - your own code in FreeBSD tree > > >> >> - eternal glory [1] > > >> >> - fun [2] > > >> >> > > >> >> If you are not interested, but know someone who does, please pass > it > > >> >> down. > > >> >> > > >> >> [1] - not really, no > > >> >> [2] - well, I guess that's subjective, so that's not a "no" > > >> > > > >> > Even though our bugmeisters have decided that we should not have > wishlist > > >> > items in our bug tracker, I really wish we could store the various > idea lists > > >> > (we have several) in an issue tracker instead. This would allow > for folks to > > >> > comment on ideas, vote for them, etc. It would also make it easier > for more > > >> > people to submit new ideas. > > >> > > > >> > > >> Speaking not strictly with the bugmeister hat, but from experience, > please do > > >> not let us go down the road of (ab)using a bug tracking solution as > task and > > >> idea management system. I think that using the tasks feature of > phabricator > > >> (our reviews instance) would provide better workflow support for > those things, > > >> starting out from sketching out rough ideas, discussing them, > breaking them up > > >> in seperate tasks (linked to and dependent on each other) and > collaborating > > >> on them (take a look at https://developer.blender.org/T42339 for a > > >> brief example). > > >> > > >> Having said this, let's keep the bug tracker a bug tracker. > > >> > > >> Cheers > > >> Marcus > > > > > > I disabled the tasks on phabricator to avoid having it a duplicate of > bugzilla, > > > but if we have a use for it I can activate it! > > > > > > Actually I do like the idea of the bug tracker aka bugzilla being only > for bugs > > > and uxe phabricator for tracking the tasks > > > > having disparate trackers for "wishlist" and "bugs" is quite harmful > > and splits the conversations. It makes people learn multiple systems > > and search multiple places - especially if the feature ends up being > > submitted as a patch to the bug tracker. > > > > I'd rather keep wishlist items in the bug tracker than split them into > two. > > > > (also, fwiw, I'd rather keep the tasks number space clean should we > > ever decide to import from bugzilla -> phabricator) > > I'm not tied to a specific issue tracker to use for this and am happy to > other > folks debate which implementation is best, but what I would prefer is a > system > to let us manage "ideas to implement" like the ideas page for GSoC and this > wiki page. The desired output is a list of vetted tasks. A task might > start > out as a wishlist entry, but someone has to step up and say "yes, this is > a good > idea and I will review it / shepherd it, etc." for it to become a "vetted > task". > Being able to store conversation about each task and tag it with other meta > data (e.g. tagging the person who "owns" the task and will do the review / > sheperding as well as being able to categorize them, etc.) However, I do > think > one important thing is that when a new idea is submitted, it has a built-in > sunset. If no one grabs it after time X it becomes closed instead of > remaining > an open wishlist forever. Similarly if the "owner" of a task drops > ownership, > the timer would start while waiting for a new owner. However, this does > feel > very much like an issue tracker. > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Hunter Satterwhite Systems Engineer, Technical Operations (TechOps) From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 16:47:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73BDD78F for ; Wed, 29 Oct 2014 16:47:21 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08C28370 for ; Wed, 29 Oct 2014 16:47:20 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so5148610wiv.8 for ; Wed, 29 Oct 2014 09:47:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gSXRSVxZdlVxv60eHx4IAymLkCMY4odOIsnE0to+C30=; b=KctuomkYim0FxXi3wnMFFSFKrDgbG50nox1Hz1u/S5fUtEwc8FiHC5II+TPa1AG054 vfbOq8AIiYnavfpkcRj2iskqnlBBABwLBY5wCv9A1PIMlcVHPdOuLR2Gu6hHXDdr8nNb XXLJixdKVZaGzMXKGinMlfld7Jb9xVDHNUl1mB63GPBxMkumrSMKDm/CO2/P1eBegpUB VKBDFFyOFyyvwuplg7g4O2+tkF+O6EY+gAN0+XNyGzP/jQtIJfJIqed21ZPPwjbHhgy/ 5/dp5wyTUbTKpRTaYUA2HKfK4UOEYjjzHQXY3voDibPRVkO71XK2GZV8WEM4dG77S9EU rgoA== X-Gm-Message-State: ALoCoQkRnv4ah6aBYNzBZKXcY8UXy8Mmn85hw2RbQ6eutycrPcoH8wc0ojWvp4F4TgTLG5fa6+FR X-Received: by 10.194.57.81 with SMTP id g17mr14441297wjq.12.1414601232504; Wed, 29 Oct 2014 09:47:12 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id b6sm6084424wiy.22.2014.10.29.09.47.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 09:47:11 -0700 (PDT) Message-ID: <54511A7E.1020307@multiplay.co.uk> Date: Wed, 29 Oct 2014 16:49:02 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 16:47:21 -0000 Hmm not sure I like this idea as it would make it more difficult to make a copy / backup a kernel. ATM when I want to copy a kernel for debugging its a one liner, splitting debug symbols off to /usr/lib would prevent this. Is there not a way to allow separate install of the debug files but to the same location maintaining compartmentalization for the needed kernel files? On 29/10/2014 00:20, Ed Maste wrote: > I am preparing to move the standalone kernel debug data out of > /boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach > used for userland debug data. This significantly reduces the boot > partition size requirement, and is a step towards supporting the > installation of kernel debug data ony when required. LLDB and GDB > automatically search for debug data under /usr/lib/debug/ so this > change should be transparent from an end-user perspective. > > The change can be reviewed in Phabricator at > https://reviews.freebsd.org/D1006 and can be fetched as a unified diff > from https://people.freebsd.org/~emaste/patches/D1006.diff > > This does not change any defaults or knobs: kernel debug files are > still built by default, and may be disabled by setting > WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize > this with userland debug in a later step. > > Note that the change renames the intermediate and debug data files to > be consistent with userland debug data: in the build directory the > kernel with debug data included is now named kernel.full, and and > kernel.debug is the standalone debug data file. > > I plan to merge this in a few days if there are no issues reported in > further review or testing. > > -Ed > _______________________________________________ > 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 Wed Oct 29 17:37:09 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6507CBC1; Wed, 29 Oct 2014 17:37:09 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19BF6B1F; Wed, 29 Oct 2014 17:37:09 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XjXBB-0004aP-H2; Wed, 29 Oct 2014 21:37:05 +0400 Date: Wed, 29 Oct 2014 21:37:05 +0400 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029173705.GL9763@zxy.spb.ru> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029121326.GA83878@zxy.spb.ru> <20141029122452.GH82736@ivaldir.etoilebsd.net> <20141029123157.GI9763@zxy.spb.ru> <20141029124025.GI82736@ivaldir.etoilebsd.net> <20141029124832.GJ9763@zxy.spb.ru> <20141029125304.GJ82736@ivaldir.etoilebsd.net> <20141029130348.GK9763@zxy.spb.ru> <20141029140714.GB9726@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029140714.GB9726@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 17:37:09 -0000 On Wed, Oct 29, 2014 at 03:07:14PM +0100, Baptiste Daroussin wrote: > > > Why the help does a minor version has an inpact on the pecl? isn't the abi > > > stable over minor versions? > > > > I am don't know -- I am not php guru. > > As result -- memcache module don't loaded and "class Memcache not > > found". > > May be just strict version check. > > > > From what I do read from here: > https://wiki.php.net/rfc/releaseprocess#releases_cycle > > only going from X.Y to X.Y+1 needs to rebuild the extensions. > and going from X.Y.Z to X.Y.Z+1 should be compatible I don't know. May be this is specific only for pecl-memcache. May be reinstalling php lost information about installed extensions. From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 17:38:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3635BD74; Wed, 29 Oct 2014 17:38:41 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1EA2B50; Wed, 29 Oct 2014 17:38:40 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id u7so2520716qaz.27 for ; Wed, 29 Oct 2014 10:38:40 -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=+6CS0RM+LKCX3RcH5SaM3hwQEdrJ4d5jCeA4t9+9x58=; b=wrykEVYKsBsa/1ZqTzRMyHYqlT+4e4qnuzMSUWas50lB81qwW9LLlmhHw4HFgJHZcC Bt2TgPF2buSccLm8Klzkkf5IVEAecFjBYClkKE3xfQZ1NOEvFqSSxW7qZUKQhbH+9AHo TKWKeYC3+c/UQBi517tn8+Mk+IaTlPFp0y5HWDjqa5GCCZy/exYDuZPjHWVp8a3kcWKl 6ke0OkfVIDr62XeTOyWvT3j0DoYlRPxCX14kuROfuPyFXhTD7vv+Wbb+iTDJ+d0V+57k Bku9LserrqtAqye9AAkqtwk3stUKZ3hCjb5Gqh1OAV2pnCx/hY4px0FCyd0uNtUDOXD4 8xgA== X-Received: by 10.229.35.197 with SMTP id q5mr18137731qcd.26.1414604318730; Wed, 29 Oct 2014 10:38:38 -0700 (PDT) Received: from ip-172-31-25-62.ec2.internal (ec2-54-85-57-1.compute-1.amazonaws.com. [54.85.57.1]) by mx.google.com with ESMTPSA id v16sm4664717qae.29.2014.10.29.10.38.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 10:38:38 -0700 (PDT) Sender: Mark Johnston Date: Wed, 29 Oct 2014 17:44:54 +0000 From: Mark Johnston To: Garrett Cooper Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Message-ID: <20141029174454.GB80471@ip-172-31-25-62.ec2.internal> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> <1414593742.17308.72.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Gyrd Thane Lange , FreeBSD Current , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 17:38:41 -0000 On Wed, Oct 29, 2014 at 09:18:58AM -0700, Garrett Cooper wrote: > > > On Oct 29, 2014, at 07:42, Ian Lepore wrote: > > ... > > > Why are you the only person in the world who has had to do this? > > They're not the only one. $work is running into an issue where there's a mismatch between the host and build version which is generating corrupt ctf sections. > > I thought it had been fixed on CURRENT recently, but the converse might be true--it might have been broken because it's no longer being built as part of the bootstrap tools process. Are you referring to r266567? I'm looking at whether we could unconditionally add ctf* to the bootstrap tools. That would address the OP's problem I think, as well as the corruption issue. > > My gut says that this section is prematurely optimizing it out of the build, because it's assumed that the host tool will always be binary compatible with the build tool: > https://svnweb.freebsd.org/base/head/Makefile.inc1?annotate=273755#l1270 From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 17:52:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69146337; Wed, 29 Oct 2014 17:52:18 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E529FD42; Wed, 29 Oct 2014 17:52:17 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id f12so2520720qad.10 for ; Wed, 29 Oct 2014 10:52:17 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ZOH5ek6+/38wz8MexZoizERnqH3XD8P6DNDvxgEJJmE=; b=z5yy7EPqhSoRCFWr/OFkbqP0io6bXYyJ/z+jR3+dMIr64D+jx9kRVJ1z2soAYNYWOl C2ZhQcZxTAxG/J3n5in0d8i46+EZjs7FodJ5EsDcfIPM4n1lNh5xQUT+sOa9hY0Lu3Gj PSDtgfXDe0CdH3iPJPFz7SXQQlBSFmubI7NqZ8vxWTnoao8aIbvHLXUvvstrd8boSo1i n0xgm9O1DxmtHTnSYrv3FbkArmssWhoY0B6YPW6Ux9KiHjRYzP5sX8zHT/6+RCGGdcMb +p0s+UKIVqFar2EQJhM47d/YIB2FTgCuzEHhidtiVeoHWIBafRx6hHmHQOaRSW8sUTRy 7CCQ== X-Received: by 10.224.74.194 with SMTP id v2mr11849458qaj.60.1414605136980; Wed, 29 Oct 2014 10:52:16 -0700 (PDT) Received: from ip-172-31-25-62.ec2.internal (ec2-54-85-57-1.compute-1.amazonaws.com. [54.85.57.1]) by mx.google.com with ESMTPSA id k5sm36722qai.45.2014.10.29.10.52.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 10:52:16 -0700 (PDT) Date: Wed, 29 Oct 2014 17:58:33 +0000 From: Mark Johnston To: Andriy Gapon Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Message-ID: <20141029175833.GC80471@ip-172-31-25-62.ec2.internal> References: <54511184.2020600@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54511184.2020600@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: David Chisnall , FreeBSD Current , Ed Maste , Kevin Oberman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 17:52:18 -0000 On Wed, Oct 29, 2014 at 12:10:44PM -0400, Andriy Gapon wrote: > On 29/10/2014 10:17, Ed Maste wrote: > > On 29 October 2014 05:05, David Chisnall wrote: > >> On 29 Oct 2014, at 03:11, Ed Maste wrote: > >> > >>> /usr/lib/debug is the standard location for standalone debug data > >>> established by GDB, and seems like a decent enough location. I'll make > >>> sure to update the man page. > >> > >> Do gdb and lldb also look in /usr/local/lib/debug? If not, it would be great if we could at least teach lldb to do this so that we can start thinking about splitting debug info into separate packages for ports (and providing it as an optional install for everything). > > > > Not yet, but it's trivial to add for at least LLDB. My end goal is > > what you describe - kernel, base system userland, and packages/ports > > can all provide standalone debug packages which will install to a > > consistent and well-known location, and be picked up automatically by > > the debugger. > > > > Part of this project depends on moving past our old binutils though, > > so we can start using the build-id ELF note to link the executable or > > library with its associated debug data. > > Another part of the issue is DTrace tools that need to look for userland > symbols. A while ago I wrote some code for libproc to handle .gnu_debuglink and read stripped sections out of the standalone debug file. It seemed to me though that that kind of functionality really belongs somewhere more central, maybe in libelf. I'm not really sure what the interface should look like; I haven't seen any other libraries that handle external debug files, aside from bfd. Also note that DTrace doesn't strictly need userland symbols to work. The pid provider is a lot more useful if they're available though. From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 18:16:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC6CBE0C; Wed, 29 Oct 2014 18:16:28 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A9FFFF8; Wed, 29 Oct 2014 18:16:28 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id bj1so3668261pad.17 for ; Wed, 29 Oct 2014 11:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3D084qgIlzMojANO/Yw7gSN0Uf3096r9TquOz1DBuk8=; b=w1uWO6FmMKD+sHjGPl0IJtpS6BO+/0d0SPR4TAbu/uofyfOeCU1ja7UisOJkJldW6b OEkBA0jjco7dwkJ7zk4jskxH+Ojo5J/22X/yvRv4t3Q1cMODk5mr7KMJllno/BlhEvL+ cdfTx+eNlLpxPVY+jz+v0D/4yVAy8xA2dBtW3KLsRNdDkH7gY9Ing8FSPX7dF4z4aFtx WGEy+uBwNsuEigRP0iT9VvMdK77VdfUVXORBJy/VUa7looYl8o71hAPR45E54KrsjXIf qzU7iWAPrLgttpgkln/ST17rqph7ytHsz4S12mlixNxBEjAcVl3kHheHuza25ObaIJxb Twbw== X-Received: by 10.70.38.165 with SMTP id h5mr11779954pdk.121.1414606587992; Wed, 29 Oct 2014 11:16:27 -0700 (PDT) Received: from [10.222.96.105] (mobile-166-171-121-185.mycingular.net. [166.171.121.185]) by mx.google.com with ESMTPSA id y2sm4962981pdp.31.2014.10.29.11.16.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 11:16:27 -0700 (PDT) References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> <1414593742.17308.72.camel@revolution.hippie.lan> <20141029174454.GB80471@ip-172-31-25-62.ec2.internal> Mime-Version: 1.0 (1.0) In-Reply-To: <20141029174454.GB80471@ip-172-31-25-62.ec2.internal> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <37A8B971-10B2-4A2D-B6A1-2E6E957C097A@gmail.com> X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Date: Wed, 29 Oct 2014 11:16:23 -0700 To: Mark Johnston Cc: Gyrd Thane Lange , FreeBSD Current , Warner Losh , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 18:16:28 -0000 > On Oct 29, 2014, at 10:44, Mark Johnston wrote: >=20 >> On Wed, Oct 29, 2014 at 09:18:58AM -0700, Garrett Cooper wrote: >>=20 >>> On Oct 29, 2014, at 07:42, Ian Lepore wrote: >>=20 >> ... >>=20 >>> Why are you the only person in the world who has had to do this? >>=20 >> They're not the only one. $work is running into an issue where there's a m= ismatch between the host and build version which is generating corrupt ctf s= ections. >>=20 >> I thought it had been fixed on CURRENT recently, but the converse might b= e true--it might have been broken because it's no longer being built as part= of the bootstrap tools process. >=20 > Are you referring to r266567? I'm looking at whether we could > unconditionally add ctf* to the bootstrap tools. That would address the > OP's problem I think, as well as the corruption issue. >=20 >>=20 >> My gut says that this section is prematurely optimizing it out of the bui= ld, because it's assumed that the host tool will always be binary compatible= with the build tool: >> https://svnweb.freebsd.org/base/head/Makefile.inc1?annotate=3D273755#l127= 0 Yes. ctfconvert always needs to be built with the build tree version instead= of relying on the host version because using the host version will break if= /when the ctf format between the build and host machine changes. Some care m= ight need to be taken with the library dependencies for ctfconvert, but libe= lf is a relatively simple library from what I remember... Thank you!= From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 19:16:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28254C34 for ; Wed, 29 Oct 2014 19:16:12 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E28968DA for ; Wed, 29 Oct 2014 19:16:11 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id h3so1922555igd.8 for ; Wed, 29 Oct 2014 12:16:11 -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:from:date:message-id :subject:to:cc:content-type; bh=ttedl1wBdpr4NElsKAgCIxbI0U5XUMUNocgrZcpiIAA=; b=jtseyy0TpFZqNKhamptNgJIPTO0Y8VmE/vYbnK5v1r/+LJ+JN8lz6kTl+a+EoWPiiT fGlvcdWoUw2GsSd0/78jVz6RbaTlzjb+V1KfExqpVsjXkfjCnDp94deSp49l17mPRv2w rP7I8OnsVLlkWMn+dl1TCXY+2o3a8v6R4v7IQVIk77oKTKVNbx4GzuO+QTLHb6Ajearf 1wSMqPo1CFKcQScFjahER5bXs9k++LpmtDXrG0yHddtVc4F0QeUqIgBwUP/gYxvb5/3L cLaZDFfqPWfgBP3Thqa/hFIRfA9kbE4qPDARALzT+G5Y180jz39ZuZwxzzYe2fFghWzT UOsw== X-Received: by 10.43.164.200 with SMTP id mt8mr5192138icc.22.1414610171287; Wed, 29 Oct 2014 12:16:11 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Wed, 29 Oct 2014 12:15:50 -0700 (PDT) In-Reply-To: <54511A7E.1020307@multiplay.co.uk> References: <54511A7E.1020307@multiplay.co.uk> From: Ed Maste Date: Wed, 29 Oct 2014 15:15:50 -0400 X-Google-Sender-Auth: irpbXWAdzpfAhM9v9Ap_dw2jJD4 Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 19:16:12 -0000 On 29 October 2014 12:49, Steven Hartland wrote: > Hmm not sure I like this idea as it would make it more difficult to make a > copy / backup a kernel. > > ATM when I want to copy a kernel for debugging its a one liner, splitting > debug symbols off to /usr/lib would prevent this. To retain the current behaviour you can set DEBUGDIR= (i.e., empty), as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}. From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 20:08:50 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66CA52BC; Wed, 29 Oct 2014 20:08:50 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9970E54; Wed, 29 Oct 2014 20:08:49 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id q5so5603429wiv.17 for ; Wed, 29 Oct 2014 13:08:48 -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=JrOKjwVDW6pgNB5XnBf6zGdu6qqAa9aOcbA2Gwcr3pM=; b=z80+38fAlGoRqzSjR6SAtnwVLEbxirGV7v4h0OTsDadYQHXWNzjXSu1dUu32nZPESY VYEjfnFjX4ANK5aluBGvHlZJBufIbVMXyOzPZ0leyLC75n0AlDJ8wHu+923k0VTSSuyq r0/4NuYqpnDzAWRyjb+jI8dElC+bDtt9l+VdQc5AX0GLLdw6wX/uYS1bV3Z1nuUeCejQ E9U/2kJwOU0CmIX9I+BM82LHXpexJviNtKFODjmoeFuJx7cmMbDcH15yT10loGjcLzZY um7poKU4DmYkkjbUJRAlw8IOhp/9azzj9ZRDeF7f6v39sbjiOpGWnH7ADH9GQC1Z0TNM UMaw== X-Received: by 10.180.91.49 with SMTP id cb17mr14480669wib.30.1414613328010; Wed, 29 Oct 2014 13:08:48 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id wx3sm6293006wjc.19.2014.10.29.13.08.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 13:08:47 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 21:08:45 +0100 From: Baptiste Daroussin To: Anton Afanasyev Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029200844.GG11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RMedoP2+Pr6Rq0N2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "ports@freebsd.org" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:08:50 -0000 --RMedoP2+Pr6Rq0N2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 01:05:49PM -0700, Anton Afanasyev wrote: > On Tue, Oct 28, 2014 at 4:19 PM, Baptiste Daroussin > wrote: >=20 > > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerg= ing > > configuration files > > - new @config keyword to mark a file as a config file (during > > upgrade/reinstallation it will try to merge the configuration with the > > one the > > user may have modified) an option AUTOMERGE is available to prevent > > automerging if automerge fails a .pkgnew file will be created along w= ith > > the > > untouched user version of the configuration > > > Would it make sense to let the user specify the merge tool to use and > always use it, instead of having to support the merge code within pkg? That will defeat cross installation/upgrades (install arm package in an arm= chroot) but yes allowing a users to define their own merge tool in general instead = of the internal one could make sense. regards, Bapt --RMedoP2+Pr6Rq0N2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRSUwACgkQ8kTtMUmk6EzxHACgiKiCZLXM8w1Fk9G3BwwZ+NVi v2kAn34fNwboZbMU3kSh+tZFOt3TqSM6 =W1c1 -----END PGP SIGNATURE----- --RMedoP2+Pr6Rq0N2-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 20:15:27 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8189D61C; Wed, 29 Oct 2014 20:15:27 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E28EFF30; Wed, 29 Oct 2014 20:15:26 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s9TKFGnk027453; Wed, 29 Oct 2014 12:15:20 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201410292015.s9TKFGnk027453@gw.catspoiler.org> Date: Wed, 29 Oct 2014 13:15:16 -0700 (PDT) From: Don Lewis Subject: Re: pkg 1.4 freeze please test test test! To: bapt@FreeBSD.org In-Reply-To: <201410290139.s9T1d0Yc023841@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:15:27 -0000 On 28 Oct, Don Lewis wrote: > On 29 Oct, Baptiste Daroussin wrote: >> Hi all, >> >> We are starting the release process of pkg 1.4, we want to have a better release >> process than with every single previous version of pkg. For that we will need >> you help! >> >> pkg-devel has been updated to the latest version of pkg as of alpha2. >> >> Changes you can expect in pkg 1.4 are the following: >> - Loads of bug fixes > > I kind of doubt that I'll have time to test it, but I've stumbled across > an interesting test case for package building with pkg-1.3.8_3. > > When I tried to build a multimedia/2mandvd package with > poudriere (either bulk or testport) in a FreeBSD 10 amd64 host and jail, > pkg-static segfaults. Portsmon also sees this failure, which also > seems to be affecting head/amd64 as well: > > > If I run poudriere jail -i to keep the jail around, I don't see any > leftover core files, I'm guessing because pkg-static's cwd is in the r/o > /usr/ports tree. If I then cd /usr/ports/multimedia/2mandvd in the > jail and run: > make clean > make stage > make package > pkg-static doesn't segfault, but it never exits either. I left it > running for a couple of days and it was still stuck at 100% CPU. If > I truss -p the process, I don't get any output, which means it's not > doing any syscalls. I found some time to test this version. I added WITH_PKG=devel to the make.conf file for the poudriere jail and ran: poudriere testport -j 101STABLEamd64 -o multimedia/2mandvd ====>> Creating the reference jail... done ====>> Mounting system devices for 101STABLEamd64-default ====>> Mounting ports/packages/distfiles ====>> Mounting packages from: /var/poudriere/data/packages/101STABLEamd64-default ====>> Logs: /var/poudriere/data/logs/bulk/101STABLEamd64-default/2014-10-29_10h36m35s ====>> Appending to make.conf: /usr/local/etc/poudriere.d/101STABLEamd64-make.conf /etc/resolv.conf -> /var/poudriere/data/build/101STABLEamd64-default/ref/etc/resolv.conf ====>> Starting jail 101STABLEamd64-default ====>> Loading MOVED ====>> Calculating ports order and dependencies ====>> Sanity checking the repository ====>> Deleting old version: desktop-file-utils-0.22_2.txz [snip] ====>> Deleting stale symlinks ====>> Deleting empty directories ====>> Cleaning the build queue ====>> Building 99 packages using 4 builders ====>> Starting/Cloning builders ====>> Hit CTRL+t at any time to see build progress and stats ====>> [01] Starting build of ports-mgmt/pkg-devel ====>> [01] Finished build of ports-mgmt/pkg-devel: Success [snip] ====>> Stopping 4 builders ====>> Portlint check WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [497]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [498]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [499]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [500]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [501]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [502]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [503]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [504]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [505]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [506]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [507]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [508]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [509]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [510]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [511]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [512]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [513]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [514]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [515]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [516]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [517]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [518]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [519]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [520]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [521]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [522]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [523]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [524]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [525]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [526]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [527]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [528]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [529]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: /var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd/pkg-plist: [530]: @dirrm[try] is deprecated. If you require special directory handling, use @dir instead and consult the porter's handbook. WARN: Makefile: possible use of absolute pathname "/bash". WARN: Consider to set DEVELOPER=yes in /etc/make.conf 0 fatal errors and 36 warnings found. ====>> Building with flags: ====>> Removing existing /usr/local build started at Wed Oct 29 11:41:53 PDT 2014 port directory: /usr/ports/multimedia/2mandvd building for: FreeBSD 101STABLEamd64-default 10.1-BETA3 FreeBSD 10.1-BETA3 amd64 maintained by: ports@FreeBSD.org Makefile ident: $FreeBSD: head/multimedia/2mandvd/Makefile 367888 2014-09-10 20:50:31Z gerald $ Poudriere version: 3.0.19 Host OSVERSION: 1000717 Jail OSVERSION: 1000717 ---Begin Environment--- PKGREPOSITORY=/tmp/pkgs PACKAGES=/tmp/pkgs OSVERSION=1000717 UNAME_v=FreeBSD 10.1-BETA3 UNAME_r=10.1-BETA3 BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 WARNING_WAIT=0 SAVED_TERM=xterm NO_WARNING_PKG_INSTALL_EOL=yes MASTERMNT=/var/poudriere/data/build/101STABLEamd64-default/ref PKG_EXT=txz FORCE_PACKAGE=yes PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin POUDRIERE_BUILD_TYPE=bulk PKGNG=1 PKG_DELETE=/usr/local/sbin/pkg-static delete -y -f PKG_ADD=/usr/local/sbin/pkg-static add OLDPWD=/usr/home/dl PWD=/var/poudriere/data/build/101STABLEamd64-default/ref/usr/ports/multimedia/2mandvd MASTERNAME=101STABLEamd64-default DEVELOPER_MODE=yes USER=root HOME=/root POUDRIERE_VERSION=3.0.19 SKIPSANITY=0 LOCALBASE=/usr/local PACKAGE_BUILDING=yes DEV_WARNING_WAIT=0 PKG_BIN=/usr/local/sbin/pkg-static ---End Environment--- ---Begin OPTIONS List--- ---End OPTIONS List--- --CONFIGURE_ARGS-- --with-qt-includes=/usr/local/include/qt4 --with-qt-libraries=/usr/local/lib/qt4 --with-extra-includes=/usr/local/include --with-extra-libs=/usr/local/lib --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- XDG_DATA_HOME=/wrkdirs/usr/ports/multimedia/2mandvd/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/multimedia/2mandvd/work HOME=/wrkdirs/usr/ports/multimedia/2mandvd/work TMPDIR="/tmp" QTDIR="/usr/local" QMAKE="/usr/local/bin/qmake-qt4" MOC="/usr/local/bin/moc-qt4" RCC="/usr/local/bin/rcc" UIC="/usr/local/bin/uic-qt4" QMAKESPEC="/usr/local/share/qt4/mkspecs/freebsd-$(ccver="$(c++ --version)"; case "$ccver" in *clang*) echo clang ;; *) echo g++ ;; esac)" SDL_CONFIG=/usr/local/bin/sdl-config MAKE=gmake ac_cv_path_PERL=/usr/local/bin/perl ac_cv_path_PERL_PATH=/usr/local/bin/perl SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- XDG_DATA_HOME=/wrkdirs/usr/ports/multimedia/2mandvd/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/multimedia/2mandvd/work HOME=/wrkdirs/usr/ports/multimedia/2mandvd/work TMPDIR="/tmp" SDL_CONFIG=/usr/local/bin/sdl-config NO_PIE=yes SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -pipe -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS="" LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -o root -g wheel -m 555" BSD_INSTALL_LIB="install -s -o root -g wheel -m 444" BSD_INSTALL_SCRIPT="install -o root -g wheel -m 555" BSD_INSTALL_DATA="install -o root -g wheel -m 0644" BSD_INSTALL_MAN="install -o root -g wheel -m 444" --End MAKE_ENV-- --SUB_LIST-- PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/2ManDVD DOCSDIR=/usr/local/share/doc/2ManDVD EXAMPLESDIR=/usr/local/share/examples/2ManDVD WWWDIR=/usr/local/www/2ManDVD ETCDIR=/usr/local/etc/2ManDVD --End SUB_LIST-- ---Begin make.conf--- USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs PACKAGES=/packages DISTDIR=/distfiles #### /usr/local/etc/poudriere.d/101STABLEamd64-make.conf #### # Global port options LICENSES_ACCEPTED=jgraph OPTIONS_SET=CUPS APPLET ATLAS SZIP LETTER WITH_ATLAS=yes WITH_PKG=devel # Specific port options audio_libao_SET=ESOUND NAS audio_sox_SET=AMRNB AMRWB LADSPA devel_git_SET=GUI SVN devel_gvfs_SET=GPHOTO2 graphics_evince_SET=DVI IMPRESS T1LIB graphics_gimp-help_SET=EN graphics_gimp-help_UNSET=ALL graphcs_gtkam_SET=GNOME graphics_opencv_SET=OPENEXR graphics_sane-frontends_SET=GIMP lang_ruby_SET=RDOC lang_tcl85_SET=TZDATA mail_cyrus-imapd24_SET=IDLED math_gnuplot_SET=PDF math_scilab_SET=UMFPACK AMANDA_USER=amanda AMANDA_GNUTAR_LISTDIR=/var/amanda/gnutar-lists AMANDA_DATES=/var/amanda/amandates multimedia_dvdslideshow_SET=LAME multimedia_dvdauthor_SET=IMAGEMAGICK multimedia_ffmpeg_SET=AACPLUS ALSA ASS CDIO FAAC GSM LAME LIBV4L OPENAL OPENJPEG OPENSSL SDL VDPAU multimedia_ffmpeg0_SET=AACPLUS ALSA FAAC LAME OPENJPEG VDPAU multimedia_libquicktime_SET=DV FAAD multimedia_mencoder_SET=FAAC OTCHAIN THEORA multimedia_mplayer_SET=OTCHAIN CDPARANOIA multimedia_totem-pl-parser_SET=QUVI multimedia_transcode_SET=X264 OGG VORBIS THEORA QUICKTIME multimedia_x264_SET=X11_OUTPUT multimedia_xine_SET=AALIB WIN32_CODECS net-im_gajim_SET=CRYPTO print_cups-base_SET=LIBUSB print_fontforge_SET=FREETYPE print_freetype_SET=LCD_FILTERING PNG print_gutenprint_SET=GIMP security_ca_root_nss_SET=ETCSYMLINK security_ipsec-tools_SET=STATS sysutils_nut_SET=CGI sysutils_nut_UNSET=SNMP sysutils_xcdroast_SET=NONROOT sysutils_xmbmon_SET=X11 x11-drivers_xorg-drivers_SET=MGA x11_xscreensaver-gnome-hacks_SET=ALL_FORTUNES ---End make.conf--- =================================================== ===> License GPLv2 accepted by the user =========================================================================== =================================================== ===> 2ManDVD-1.8.5_1 depends on file: /usr/local/sbin/pkg - not found ===> Verifying install for /usr/local/sbin/pkg in /usr/ports/ports-mgmt/pkg-devel ===> Installing existing package /packages/All/pkg-1.4.0.a3.txz [101STABLEamd64-default] Installing pkg-1.4.0.a3... [101STABLEamd64-default] Extracting pkg-1.4.0.a3... done Message for pkg-1.4.0.a3: If you are upgrading from the old package format, first run: # pkg2ng ===> Returning to build of 2ManDVD-1.8.5_1 [snip] ====> Compressing man pages (compress-man) =========================================================================== ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done =================================================== ===> Building package for 2ManDVD-1.8.5_1 pkg-static: Warning: @dirrm[try] is deprecated, please use @dir At this point pkg-static runs forever: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 21736 root 1 103 0 13940K 8020K CPU2 2 89:24 100.00% pkg-stati From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 20:18:06 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44B52819; Wed, 29 Oct 2014 20:18:06 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84B88F58; Wed, 29 Oct 2014 20:18:05 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id m15so2757650wgh.27 for ; Wed, 29 Oct 2014 13:18:03 -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=1h8eGz4BRCP0GzbWbj5PuX/9CG7P7vnfy2lC/KOpPFE=; b=fAweYRqLabGGIVTdHwBTaCALuAqn8KIWq9soVn9IDopRzlNLS0rbs4csXqGaEwU29p F2cOGNsutRIRE3XmxOzE1sKg776pNuLeMs1JADeraDxhrR2EzOf08p18f2LSOTVznh+r KRdq/Ef7mCwdyrwAof1pMGWslnbDkIIpCVEs5IG1GNkyw8rOjSuZrbXQommrQMK79Z59 KYba4IYluzJpN4QX0jUYZhrPVKx7bhtaSDG3q2nm0qn7vpQaSkVqnv4NlDsFXNo1PHX5 jwnknHK3kDICUDaE2bCuxWA0LW5tO+9ebp6ID0fH8C4Lbu7QJ6Pr3d0jfNh6Eps7Z7JM +HCA== X-Received: by 10.180.90.105 with SMTP id bv9mr39076223wib.53.1414613883862; Wed, 29 Oct 2014 13:18:03 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id m6sm6649505wiy.16.2014.10.29.13.18.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 13:18:02 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 21:18:00 +0100 From: Baptiste Daroussin To: Don Lewis Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029201800.GH11033@ivaldir.etoilebsd.net> References: <201410290139.s9T1d0Yc023841@gw.catspoiler.org> <201410292015.s9TKFGnk027453@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zq44+AAfm4giZpo5" Content-Disposition: inline In-Reply-To: <201410292015.s9TKFGnk027453@gw.catspoiler.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:18:06 -0000 --zq44+AAfm4giZpo5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 01:15:16PM -0700, Don Lewis wrote: > On 28 Oct, Don Lewis wrote: > > On 29 Oct, Baptiste Daroussin wrote: > >> Hi all, > >>=20 > >> We are starting the release process of pkg 1.4, we want to have a bett= er release > >> process than with every single previous version of pkg. For that we wi= ll need > >> you help! > >>=20 > >> pkg-devel has been updated to the latest version of pkg as of alpha2. > >>=20 > >> Changes you can expect in pkg 1.4 are the following: > >> - Loads of bug fixes > >=20 > > I kind of doubt that I'll have time to test it, but I've stumbled across > > an interesting test case for package building with pkg-1.3.8_3. > >=20 > > When I tried to build a multimedia/2mandvd package with > > poudriere (either bulk or testport) in a FreeBSD 10 amd64 host and jail, > > pkg-static segfaults. Portsmon also sees this failure, which also > > seems to be affecting head/amd64 as well: > > > >=20 > > If I run poudriere jail -i to keep the jail around, I don't see any > > leftover core files, I'm guessing because pkg-static's cwd is in the r/o > > /usr/ports tree. If I then cd /usr/ports/multimedia/2mandvd in the > > jail and run: > > make clean > > make stage > > make package > > pkg-static doesn't segfault, but it never exits either. I left it > > running for a couple of days and it was still stuck at 100% CPU. If > > I truss -p the process, I don't get any output, which means it's not > > doing any syscalls. >=20 >=20 > I found some time to test this version. I added WITH_PKG=3Ddevel to the > make.conf file for the poudriere jail and ran: >=20 > poudriere testport -j 101STABLEamd64 -o multimedia/2mandvd Ah crap this 2mandvd again..... Ok I'll track it down, thanks 2mandvd is a nightmare for me :) But a good testcase. Thank you for pointing this to me regards, Bapt --zq44+AAfm4giZpo5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRS3gACgkQ8kTtMUmk6EzQGgCcDRv/eywENIWz7xRkEzpT6Lee QNwAniDXush1E77YP7rXCffu7GOD88jD =7cU2 -----END PGP SIGNATURE----- --zq44+AAfm4giZpo5-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 20:24:01 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 230A7D30; Wed, 29 Oct 2014 20:24:01 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85BD4CF; Wed, 29 Oct 2014 20:24:00 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so4190332wgh.10 for ; Wed, 29 Oct 2014 13:23:58 -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=NA4yVyyfVUV5Y+sPIeeYnLS0WiOc/cGuDTHwFq+A3ZQ=; b=xDQpwvDQ79RfQa/t172wTPyXTxqfCem0OpBeBWkC9H9hj5abbVG/cnwYnKT8gLYtD+ MOfTk45NPXIrs79v41ZHX/bmd2lvyeU2sKh9fKBoXky0QUx0ph7mhBp0CS9yUUSdwWan 1huKuc1lBJUUJiTjKW9O0p6uliXElNqDnN0CAZEvmXLM5DX3kBq4VcGawQJzZiPFMFBe BUdB/B1kHTfM8fSvIs8XhbV8d7sAR8Obt+LCu4BYOoxct/242Kt+JlMV1Ilvt91fzMt2 pwcheJ0tNP/8V/UtPFXzG19gEMRAkucyJZzsM8fv+1//ZK76a/4tL80SLUiNI1FbeZhH lYDw== X-Received: by 10.180.73.19 with SMTP id h19mr37971249wiv.3.1414614238795; Wed, 29 Oct 2014 13:23:58 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id rx8sm1785425wjb.30.2014.10.29.13.23.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 13:23:57 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 29 Oct 2014 21:23:56 +0100 From: Baptiste Daroussin To: Anton Afanasyev Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029202355.GI11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029200844.GG11033@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9iyR+p8Z2cn535Lj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "ports@freebsd.org" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:24:01 -0000 --9iyR+p8Z2cn535Lj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 01:22:01PM -0700, Anton Afanasyev wrote: > On Wed, Oct 29, 2014 at 1:08 PM, Baptiste Daroussin > wrote: >=20 > > On Wed, Oct 29, 2014 at 01:05:49PM -0700, Anton Afanasyev wrote: > > > On Tue, Oct 28, 2014 at 4:19 PM, Baptiste Daroussin > > > wrote: > > > > > > > - new 3 way merge code ("stolen" from the fossil-scm) to allow > > automerging > > > > configuration files > > > > - new @config keyword to mark a file as a config file (during > > > > upgrade/reinstallation it will try to merge the configuration with > > the > > > > one the > > > > user may have modified) an option AUTOMERGE is available to preve= nt > > > > automerging if automerge fails a .pkgnew file will be created alo= ng > > with > > > > the > > > > untouched user version of the configuration > > > > > > > Would it make sense to let the user specify the merge tool to use and > > > always use it, instead of having to support the merge code within pkg? > > > > That will defeat cross installation/upgrades (install arm package in an > > arm chroot) > > > > but yes allowing a users to define their own merge tool in general inst= ead > > of > > the internal one could make sense. > > > > regards, > > Bapt > > >=20 > I (and this is just a personal opinion of one man, of course) find it > better to be explicitly told that "this default config file has changed a= nd > you need to review it and merge with your local changed copy, even if you > didn't make any drastic changes to your version", as opposed to "by the > way, we merged a new version of this config file with your changes", as > that forces one to know what and why has changed. I've already lost a > config file for one of my ports (squid, the last 2.something version) due > to it getting overwritten with the default, so wouldn't want anything like > that to happen again (and yes, I know, I must have backups; but that's not > the point here). >=20 > If auto-merging is going to stay, an option to turn it off and always use= a > merge tool or perform the merge manually would be appreciated. there is an option to turn it off as I said in the announcement: AUTOMERGE: false in pkg.conf regards, Bapt --9iyR+p8Z2cn535Lj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRTNsACgkQ8kTtMUmk6EywOgCdGLcpVezDDHZKXXkyt3w3q4CE 98EAnRWQ4Syfzcc80XTva/QzK/YWDaYT =HWgL -----END PGP SIGNATURE----- --9iyR+p8Z2cn535Lj-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 20:33:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C942B7; Wed, 29 Oct 2014 20:33:44 +0000 (UTC) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) by mx1.freebsd.org (Postfix) with ESMTP id F41451D7; Wed, 29 Oct 2014 20:33:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id D009FA51EB; Wed, 29 Oct 2014 21:25:52 +0100 (CET) Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zoZdZohxzUmi; Wed, 29 Oct 2014 21:25:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 4C4C6A5318; Wed, 29 Oct 2014 21:25:48 +0100 (CET) X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1v4N-AlsqSDg; Wed, 29 Oct 2014 21:25:48 +0100 (CET) Received: from onyx.thanelange.no (cm-84.208.179.208.getinternet.no [84.208.179.208]) by lamora.getmail.no (Postfix) with ESMTP id 1B5BAA525F; Wed, 29 Oct 2014 21:25:48 +0100 (CET) Date: Wed, 29 Oct 2014 21:24:54 +0100 From: Gyrd Thane Lange To: Ian Lepore Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Message-ID: <20141029212454.6fcfc3ac@onyx.thanelange.no> In-Reply-To: <1414593742.17308.72.camel@revolution.hippie.lan> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> <1414593742.17308.72.camel@revolution.hippie.lan> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , NGie Cooper , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:33:44 -0000 On Wed, 29 Oct 2014 08:42:22 -0600 Ian Lepore wrote: > On Wed, 2014-10-29 at 14:38 +0100, Gyrd Thane Lange wrote: > > On Wed, 29 Oct 2014 01:24:32 +0100 > > Gyrd Thane Lange wrote: > > > > > On Tue, 28 Oct 2014 16:45:47 -0700 > > > NGie Cooper wrote: > > > > > > > On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange > > > > wrote: > > > > > On Tue, 28 Oct 2014 17:01:39 -0600 > > > > > Ian Lepore wrote: > > > > > > > > > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > > > > >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > > > >> > > > > >> Do a "make kernel-toolchain" which will build a new > > > > >> ctfconvert and put it in the right place within /usr/obj to > > > > >> be used during buildkernel. > > > > > > > > > > Thanks, I will try this (building now). But if it works I'll > > > > > be somewhat confused. I thought kernel-toolchain was implicit > > > > > when doing a full buildworld (which I've already done), and I > > > > > already have a ctfconvert > > > > > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). > > > > > > Finished a make kernel-toolchain (but it left me with even less > > > binaries than make buildworld): > > > > > > # find /usr/src/ /usr/obj -name ctfconvert -type f > > > (nothing found) > > > > > > > > The problem looks more like buildkernel is ignoring the > > > > > ctfconvert tool in /usr/obj/ and instead is expecting to find > > > > > it in /usr/bin (or some such). > > > > > > > > It should be located in /usr/obj -- we should not expect the > > > > tool in /usr/bin to be correct/compatible with the source tree. > > > > > > I agree. :) > > > > > > while waiting for a proper solution for this, I'll try looking at > > > the Makefiles and bsd.*.mk files under /usr/src my self, but I > > > have never looked at them before so I don't expect a speedy > > > success. > > > > Discovered that the tools are set in /usr/src/share/mk/sys.mk: > > > > CTFCONVERT ?= ctfconvert > > CTFMERGE ?= ctfmerge > > DTRACE ?= dtrace > > > > I then set the following in my /etc/src.conf (NB! long lines): > > > > CTFCONVERT=env > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf/ /usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert > > CTFMERGE=env > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf /usr/obj/usr/src/cddl/usr.bin/ctfmerge/ctfmerge > > DTRACE=env > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf:/usr/obj/usr/src/cddl/lib/libdtrace /usr/obj/usr/src/cddl/usr.sbin/dtrace/dtrace > > > > This allowed me to successfully build the kernel. > > > > The important question to be asking at this point: > > Why are you the only person in the world who has had to do this? > > Until you have an answer to that, nothing is really fixed. The thing > that's different for you than for most people, I guess, is that you > originally built the system WITHOUT_CDDL then removed that option. > That's almost certainly a factor somehow. > > Also, the copy of the tool within obj that it should use is not the > copy you manually pointed to with those changes. When newer build > tools are needed, they exist within /usr/obj/usr/src/tmp/. So... why > doesn't ctfconvert exist for you in that location after making > kernel-toolchain? It does not exist in that location for anybody (not just me)*. I just happen to notice it sooner because I have no ctfconvert installed on the host beforehand. Actually, mine is the better situation in that the build stopped with an up front error instead of using the wrong (possible outdated) tools and introduced other subtle errors. I believe this is reproducible on anybodys system by deleting/moving the ctfconvert tool away from the host, before trying to build a dtrace enabled kernel. I see elsewhere in the thread that Garret and Mark are onto the real problem and solution. Gyrd ^_^ * Actually, I did see some libraries copied to /usr/obj/usr/src/tmp/.../ but none of the tools. Users that are upgrading from quite older versions and/or are crossbuilding may have the tools. > > -- Ian > > > _______________________________________________ > 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 Wed Oct 29 20:53:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 821FA497; Wed, 29 Oct 2014 20:53:47 +0000 (UTC) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B111B5E2; Wed, 29 Oct 2014 20:53:46 +0000 (UTC) Received: from [89.182.109.102] (helo=localhost) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1XjaFN-0003yV-VV; Wed, 29 Oct 2014 21:53:38 +0100 Date: Wed, 29 Oct 2014 21:53:36 +0100 From: Marcus von Appen To: Eitan Adler Subject: Re: junior kernel tasks Message-ID: <20141029205336.GA1303@medusa.sysfault.org> Reply-To: Marcus von Appen Mail-Followup-To: Eitan Adler , Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Df-Sender: MTEyNTc0Mg== Cc: FreeBSD Hackers , Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:53:47 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On, Wed Oct 29, 2014, Eitan Adler wrote: > On 28 October 2014 15:14, Baptiste Daroussin wrote: > > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: > >> > >> Quoting John Baldwin : > >> > >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > >> >> Hello, > >> >> > >> >> In short, nice kernel tasks people with C language skills can do in few > >> >> evenings. > >> >> > >> >> https://wiki.freebsd.org/JuniorJobs > >> >> > >> >> It is assumed you know how to obtain sources and build the kernel. > >> >> > >> >> What you can get in return: > >> >> - your own code in FreeBSD tree > >> >> - eternal glory [1] > >> >> - fun [2] > >> >> > >> >> If you are not interested, but know someone who does, please pass it > >> >> down. > >> >> > >> >> [1] - not really, no > >> >> [2] - well, I guess that's subjective, so that's not a "no" > >> > > >> > Even though our bugmeisters have decided that we should not have wishlist > >> > items in our bug tracker, I really wish we could store the various idea lists > >> > (we have several) in an issue tracker instead. This would allow for folks to > >> > comment on ideas, vote for them, etc. It would also make it easier for more > >> > people to submit new ideas. > >> > > >> > >> Speaking not strictly with the bugmeister hat, but from experience, please do > >> not let us go down the road of (ab)using a bug tracking solution as task and > >> idea management system. I think that using the tasks feature of phabricator > >> (our reviews instance) would provide better workflow support for those things, > >> starting out from sketching out rough ideas, discussing them, breaking them up > >> in seperate tasks (linked to and dependent on each other) and collaborating > >> on them (take a look at https://developer.blender.org/T42339 for a > >> brief example). > >> > >> Having said this, let's keep the bug tracker a bug tracker. > >> > >> Cheers > >> Marcus > >> > >> > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, > > but if we have a use for it I can activate it! > > > > Actually I do like the idea of the bug tracker aka bugzilla being only for bugs > > and uxe phabricator for tracking the tasks > > having disparate trackers for "wishlist" and "bugs" is quite harmful > and splits the conversations. It makes people learn multiple systems > and search multiple places - especially if the feature ends up being > submitted as a patch to the bug tracker. We have this situation right now with reviews and the bug tracker. reviews is used by the committers only right now, and both loosely interact with each other. Opening reviews to the public won't improve the situation of having two disparate systems to look into. Same goes for the Wiki and bug tracker, mailing lists, etc. The more relevant question thus would be: how do we point people to the correct location and at which point of time? This will call for a more tight integration in the foresesable future (e.g. search abilities for reviews, that can be triggered from the bug tracker and vice versa). > I'd rather keep wishlist items in the bug tracker than split them into two. > > (also, fwiw, I'd rather keep the tasks number space clean should we > ever decide to import from bugzilla -> phabricator) > Fair enough. If we are going to do that, the area however should be separate from typical "bugs", so people do not confuse wishes with bugs and vice versa. Also, to avoid long and misleading comment trails, we would need the ability to hide/remove errornous (bug-related) comments in the wishlist (a feature wished for independent of this, but a necessary prerequisite [probably coming soon]). Wishlist items thus should not belong to a currently existing product or component, but should be clearly classified in an own product and/or component category. Except from that, what else would be required and desired to have a suitable wishlist? The bug tracker right now features: - tags - keywords - links to internal bugs/items (dependencies and blockers) - links to external systems - links to svn commits and reviews - attachments - flags to request/confirm/deny things Cheers Marcus --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRU9AACgkQi68/ErJnpkc9UQCdGZ/MoEDqs/Sa8MalLiTs3j7K rWEAni9Kmig1t+j6WjwRC7tkanCHIu0H =hunL -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 20:06:11 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02428C4; Wed, 29 Oct 2014 20:06:11 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96BC5E2F; Wed, 29 Oct 2014 20:06:10 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id b13so3412583qcw.6 for ; Wed, 29 Oct 2014 13:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=PrE4UCEpq205m/AtC0Ay3VU9cJpxhtR1+EHxeqCXKto=; b=lOh8QQ1u129bPJt8YPhlaOR5R9CwYR55sz0sH/QIVKYzQculzhe6IBBi8PzlbdxLWX 5Mr1ADS6R9qyw8sAitNJTyE2shfkkOLL8RCPRRV1+o0R8hwYyhhgG+Vweu3Ofiub9kVF 6x9Ek+2F7TJ/Sj22Nf84hu6Tn5QnjAodmIS03pGKi4yL7Oby5bBGc9wLmldGlojMCeJj ClPcm4ASwMvHi2Hzx/msEiTPdFtRDfdHN/dW10SSd3UoTDzkOomSBTRvLLbFY5BLaZk+ fnPgTcBd4oTF3dxS5bkoAtBY+4vO40JsA0x9ZmNfFaJn0V/xaRW4bjOyej91GmxGmfw5 4zxA== X-Received: by 10.140.102.7 with SMTP id v7mr18068450qge.68.1414613169599; Wed, 29 Oct 2014 13:06:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.3.2 with HTTP; Wed, 29 Oct 2014 13:05:49 -0700 (PDT) In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> From: Anton Afanasyev Date: Wed, 29 Oct 2014 13:05:49 -0700 Message-ID: Subject: Re: pkg 1.4 freeze please test test test! To: Baptiste Daroussin , "ports@freebsd.org" , current@freebsd.org X-Mailman-Approved-At: Wed, 29 Oct 2014 21:01:15 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:06:11 -0000 On Tue, Oct 28, 2014 at 4:19 PM, Baptiste Daroussin wrote: > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging > configuration files > - new @config keyword to mark a file as a config file (during > upgrade/reinstallation it will try to merge the configuration with the > one the > user may have modified) an option AUTOMERGE is available to prevent > automerging if automerge fails a .pkgnew file will be created along with > the > untouched user version of the configuration > Would it make sense to let the user specify the merge tool to use and always use it, instead of having to support the merge code within pkg? Anton From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 21:03:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E10069C9; Wed, 29 Oct 2014 21:03:22 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CDF9755; Wed, 29 Oct 2014 21:03:22 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjaOn-000Lrc-44; Wed, 29 Oct 2014 21:03:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9TL3JOw081523; Wed, 29 Oct 2014 15:03:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5dh+luNSTt5D8dLtw8OFq X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) From: Ian Lepore To: Gyrd Thane Lange In-Reply-To: <20141029212454.6fcfc3ac@onyx.thanelange.no> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> <1414593742.17308.72.camel@revolution.hippie.lan> <20141029212454.6fcfc3ac@onyx.thanelange.no> Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Oct 2014 15:03:19 -0600 Message-ID: <1414616599.17308.141.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , NGie Cooper , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 21:03:23 -0000 On Wed, 2014-10-29 at 21:24 +0100, Gyrd Thane Lange wrote: > On Wed, 29 Oct 2014 08:42:22 -0600 > Ian Lepore wrote: > > > On Wed, 2014-10-29 at 14:38 +0100, Gyrd Thane Lange wrote: > > > On Wed, 29 Oct 2014 01:24:32 +0100 > > > Gyrd Thane Lange wrote: > > > > > > > On Tue, 28 Oct 2014 16:45:47 -0700 > > > > NGie Cooper wrote: > > > > > > > > > On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange > > > > > wrote: > > > > > > On Tue, 28 Oct 2014 17:01:39 -0600 > > > > > > Ian Lepore wrote: > > > > > > > > > > > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote: > > > > > >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > > > > >> > > > > > >> Do a "make kernel-toolchain" which will build a new > > > > > >> ctfconvert and put it in the right place within /usr/obj to > > > > > >> be used during buildkernel. > > > > > > > > > > > > Thanks, I will try this (building now). But if it works I'll > > > > > > be somewhat confused. I thought kernel-toolchain was implicit > > > > > > when doing a full buildworld (which I've already done), and I > > > > > > already have a ctfconvert > > > > > > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert). > > > > > > > > Finished a make kernel-toolchain (but it left me with even less > > > > binaries than make buildworld): > > > > > > > > # find /usr/src/ /usr/obj -name ctfconvert -type f > > > > (nothing found) > > > > > > > > > > The problem looks more like buildkernel is ignoring the > > > > > > ctfconvert tool in /usr/obj/ and instead is expecting to find > > > > > > it in /usr/bin (or some such). > > > > > > > > > > It should be located in /usr/obj -- we should not expect the > > > > > tool in /usr/bin to be correct/compatible with the source tree. > > > > > > > > I agree. :) > > > > > > > > while waiting for a proper solution for this, I'll try looking at > > > > the Makefiles and bsd.*.mk files under /usr/src my self, but I > > > > have never looked at them before so I don't expect a speedy > > > > success. > > > > > > Discovered that the tools are set in /usr/src/share/mk/sys.mk: > > > > > > CTFCONVERT ?= ctfconvert > > > CTFMERGE ?= ctfmerge > > > DTRACE ?= dtrace > > > > > > I then set the following in my /etc/src.conf (NB! long lines): > > > > > > CTFCONVERT=env > > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf/ /usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert > > > CTFMERGE=env > > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf /usr/obj/usr/src/cddl/usr.bin/ctfmerge/ctfmerge > > > DTRACE=env > > > LD_LIBRARY_PATH=/usr/obj/usr/src/cddl/lib/libctf:/usr/obj/usr/src/cddl/lib/libdtrace /usr/obj/usr/src/cddl/usr.sbin/dtrace/dtrace > > > > > > This allowed me to successfully build the kernel. > > > > > > > The important question to be asking at this point: > > > > Why are you the only person in the world who has had to do this? > > > > Until you have an answer to that, nothing is really fixed. The thing > > that's different for you than for most people, I guess, is that you > > originally built the system WITHOUT_CDDL then removed that option. > > That's almost certainly a factor somehow. > > > > Also, the copy of the tool within obj that it should use is not the > > copy you manually pointed to with those changes. When newer build > > tools are needed, they exist within /usr/obj/usr/src/tmp/. So... why > > doesn't ctfconvert exist for you in that location after making > > kernel-toolchain? > > It does not exist in that location for anybody (not just me)*. I just Umm, no. It exists for me, for example: revolution > find obj/ -name ctfconvert -type f obj/arm.armv6/local/build/staging/freebsd/wand/src/cddl/usr.bin/ctfconvert/ctfconvert obj/arm.armv6/local/build/staging/freebsd/wand/src/tmp/legacy/usr/bin/ctfconvert obj/arm.armv6/local/build/staging/freebsd/wand/src/tmp/local/build/staging/freebsd/wand/src/cddl/usr.bin/ctfconvert/ctfconvert The first file is the one that will get installed to DESTDIR during installworld. The second is the one that gets built in the legacy step and then is used to build the one in the bootstrap step. The third is the one built in the bootstrap step that gets used for buildworld and buildkernel. These exist for me because my build system is older than 1100006. Yours is not, so there's no need to build a newer ctfconvert because the already-installed one on your system is good enough. Except there was no already-installed one, because you had WITHOUT_CDDL when you did installworld. Then I offered bad advice that "make kernel-toolchain" should fix it. I just didn't think hard enough about what the actual problem was. The right advice would have been that you should install the ctfconvert that didn't get installed originally because of your options. In other words "make buildworld installworld SUBDIR_OVERRIDE=cddl" is probably the right way to undo the WITHOUT_CDDL decision. It appears that src/Makefile.inc1 already does the right thing in regards to building ctconvert as a bootstrap tool when it needs to. > happen to notice it sooner because I have no ctfconvert installed on > the host beforehand. Actually, mine is the better situation in that the > build stopped with an up front error instead of using the wrong > (possible outdated) tools and introduced other subtle errors. > > I believe this is reproducible on anybodys system by deleting/moving > the ctfconvert tool away from the host, before trying to build a dtrace > enabled kernel. > I think you'll find that that is true of any number of programs in /usr/bin including, for example, cc or ar or ld. > I see elsewhere in the thread that Garret and Mark are onto the real > problem and solution. > I don't think so. Mark referred to a problem with the wrong version of ctfconvert, and he said he thought it had been fixed. Your problem wasn't corrupted files due to wrong-version. We must not let this situation turn into some kind of mythology about an incompatibility that doesn't exist. You reported that a tool was missing during the build, we know why it was missing, and we know what to do to make it not be missing anymore. Problem solved. -- Ian > Gyrd ^_^ > > * Actually, I did see some libraries copied to /usr/obj/usr/src/tmp/.../ > but none of the tools. Users that are upgrading from quite older > versions and/or are crossbuilding may have the tools. > > > > > -- Ian > > > > > > _______________________________________________ > > 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 Wed Oct 29 20:22:23 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6F44BC7; Wed, 29 Oct 2014 20:22:23 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56AD08E; Wed, 29 Oct 2014 20:22:23 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id i13so2708624qae.22 for ; Wed, 29 Oct 2014 13:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Sp2Xy7K+YqjJ3xGsIiRPItID8l1QiD3EM2pdF1950b4=; b=AaUTD3df6VjVvsClGyWLefqNYeGzFX2BLPRMy5IJNuzyBrMKhnootaWv3tjcaPS388 TyCZVlVGl0GkvnCx3ToCm9dFbkhpJnzGGNTc5v05O7PapBawk2XD6ux28E/LSSsIIuJe TiHLjBOg7o/gUh8PBzCUD/bE31F82kkphF2MOEPzMwLLI9joBIY7WLO5ffOtzKDBRccD bWymR9y2wbujbM3Hbmi6MbEXBjIhwqMm2FXQGmhmC10ZQi2c37ubmScE6fPcR79ZGsnN 2zAzUeoviGrt5M29qWv2ceCO8xwGlA9B+hcyUidRa/8EpRHwt42ST0NUopxdjk/GKpMw jfXQ== X-Received: by 10.140.82.144 with SMTP id h16mr18066437qgd.40.1414614141934; Wed, 29 Oct 2014 13:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.3.2 with HTTP; Wed, 29 Oct 2014 13:22:01 -0700 (PDT) In-Reply-To: <20141029200844.GG11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029200844.GG11033@ivaldir.etoilebsd.net> From: Anton Afanasyev Date: Wed, 29 Oct 2014 13:22:01 -0700 Message-ID: Subject: Re: pkg 1.4 freeze please test test test! To: Baptiste Daroussin , "ports@freebsd.org" , current@freebsd.org X-Mailman-Approved-At: Wed, 29 Oct 2014 21:13:00 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 20:22:23 -0000 On Wed, Oct 29, 2014 at 1:08 PM, Baptiste Daroussin wrote: > On Wed, Oct 29, 2014 at 01:05:49PM -0700, Anton Afanasyev wrote: > > On Tue, Oct 28, 2014 at 4:19 PM, Baptiste Daroussin > > wrote: > > > > > - new 3 way merge code ("stolen" from the fossil-scm) to allow > automerging > > > configuration files > > > - new @config keyword to mark a file as a config file (during > > > upgrade/reinstallation it will try to merge the configuration with > the > > > one the > > > user may have modified) an option AUTOMERGE is available to prevent > > > automerging if automerge fails a .pkgnew file will be created along > with > > > the > > > untouched user version of the configuration > > > > > Would it make sense to let the user specify the merge tool to use and > > always use it, instead of having to support the merge code within pkg? > > That will defeat cross installation/upgrades (install arm package in an > arm chroot) > > but yes allowing a users to define their own merge tool in general instead > of > the internal one could make sense. > > regards, > Bapt > I (and this is just a personal opinion of one man, of course) find it better to be explicitly told that "this default config file has changed and you need to review it and merge with your local changed copy, even if you didn't make any drastic changes to your version", as opposed to "by the way, we merged a new version of this config file with your changes", as that forces one to know what and why has changed. I've already lost a config file for one of my ports (squid, the last 2.something version) due to it getting overwritten with the default, so wouldn't want anything like that to happen again (and yes, I know, I must have backups; but that's not the point here). If auto-merging is going to stay, an option to turn it off and always use a merge tool or perform the merge manually would be appreciated. Anton From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 21:37:59 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCE5B579; Wed, 29 Oct 2014 21:37:59 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EACF8ACE; Wed, 29 Oct 2014 21:37:58 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3jSjn61Y6SzbB0; Wed, 29 Oct 2014 22:37:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1414618664; x=1416433065; bh=S5UnV2DKgrpywtRLmvFXGE/QGVibPBzRhN1qZ0lHkqQ=; b= erFNiO1B5ulA03PuBazFrYRORhB/ttiH1cIjX3cIjDs1tVj9uqlq0lFytCB2utGa sA8XLRGBF9NBOPGKKMCeyPYr+4BxZHmjL8jNa5waaZX8fROZ3NczooFnv2BhvlGA G4R0cNX90gnUfiAEMkRD6Nb8tZHYFbDlCeGnW8redQY= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id DMOLvZ6dRlhv; Wed, 29 Oct 2014 22:37:44 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Wed, 29 Oct 2014 22:37:44 +0100 (CET) Message-ID: <54515E27.9010404@madpilot.net> Date: Wed, 29 Oct 2014 22:37:43 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Baptiste Daroussin , ports@FreeBSD.org, current@FreeBSD.org Subject: Re: pkg 1.4 freeze please test test test! References: <20141028231933.GG26796@ivaldir.etoilebsd.net> In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 21:37:59 -0000 On 10/29/14 00:19, Baptiste Daroussin wrote: > Hi all, > > We are starting the release process of pkg 1.4, we want to have a better release > process than with every single previous version of pkg. For that we will need > you help! Hi, last version works fine, but, sometimes, core files show up in port directory...for no reason, really. Noticed this while doing some make patch and make extract in a standalone port directory outside the ports tree. Anyway are you interested in the core file for investigation? This is a backtrace: (gdb) bt #0 0x00000000007df0bb in strlen () #1 0x0000000000402c88 in add_to_check (head=0x7fffffffe0f8, pkg=0x80105b600) at audit.c:79 #2 0x000000000040200e in exec_audit (argc=1, argv=0x7fffffffe898) at audit.c:205 #3 0x0000000000411132 in main (argc=2, argv=0x7fffffffe890) at main.c:822 -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 22:08:26 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10E5D200; Wed, 29 Oct 2014 22:08:26 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0B5CE0D; Wed, 29 Oct 2014 22:08:25 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id la4so1177094vcb.1 for ; Wed, 29 Oct 2014 15:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nrizHk63h/e61EpGbOaI8Nj5aNQXPcUY9CvjFvrn/Cc=; b=inPxZvhFRdkwfTOqMszuGWEc4H2TbthsuG/GRBFbsvdE+YoPkLjSHvhhJWibCh9EAQ +RvyB5MDX/XqLEne1Q8+LL8pDHGDfvWi/F5mk26DKpfWE+qIt3OI1OdNSmGElCnfe+9b vxbyIf3ERnbOIahD7CZUdNIMMdPS8mh1WW+z09Vujx7vUKlyDRImE1Jmk922sRhk1R6T NRPoWhQDwM0aRncP0SgQ1zvBdla0dFujv/p6P6/y/CWpk5CD2YCVnYeQVMbL91Yj1pQR 3t+cF3+SmEfxUONeoIl3yzubLZgNJMj1dgXmbOnig4wX2LWXeKgoL2hv2XbstKL7Gae5 VhHg== X-Received: by 10.53.12.232 with SMTP id et8mr5227848vdd.91.1414620504738; Wed, 29 Oct 2014 15:08:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.136.76 with HTTP; Wed, 29 Oct 2014 15:07:44 -0700 (PDT) In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> From: Henry Hu Date: Wed, 29 Oct 2014 18:07:44 -0400 Message-ID: Subject: Re: pkg 1.4 freeze please test test test! To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-ports@freebsd.org" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 22:08:26 -0000 Hi, On Tue, Oct 28, 2014 at 7:19 PM, Baptiste Daroussin wrote: > Hi all, > > We are starting the release process of pkg 1.4, we want to have a better > release > process than with every single previous version of pkg. For that we will > need > you help! > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > Changes you can expect in pkg 1.4 are the following: > - Loads of bug fixes > - Stricter checking of the path passed via the plist > - Removal of the bundled libyaml > - new --raw-format to chose the output format for info -R and search -R > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become > FreeBSD:10:amd64) > the old ABI is available as a fallback in ALTABI > - pkg check now support a quiet mode > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging > configuration files > - new @config keyword to mark a file as a config file (during > upgrade/reinstallation it will try to merge the configuration with the > one the > user may have modified) an option AUTOMERGE is available to prevent > automerging if automerge fails a .pkgnew file will be created along with > the > untouched user version of the configuration > - The update procedure has been improved and speed up a lot (in particular > for > machine with low resources) > - The unique identifier has been modified to be pkgname meaning now ports > can be > moved in new categories without having to be considered a different > package > - Only libraries starting by lib* are added to the provided libraries > - General speed up of all operations > > We need help in testing, but we also need help in writing regression tests > ! > The more we have tests the more stable the releases will be. > > The release will also allow to be able to package base! > I've just tried pkg-devel 1.4.0.alpha3 and found something strange: when a pkg is removed, pkgs which depend on it are not removed. For example: > sudo pkg remove libX11 Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: libX11-1.6.2_2,1 The operation will free 6 MB. Proceed with deinstalling packages? [y/N]: > sudo pkg remove -R libX11 Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: libX11-1.6.2_2,1 The operation will free 6 MB. Proceed with deinstalling packages? [y/N]: But pkg info -r libX11 produces a long list. If I downgrade to pkg 1.3.8, pkg remove libX11 asks me to remove almost everything. Is this a regression? > > regards, > Bapt > -- Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 22:47:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 413B75E0; Wed, 29 Oct 2014 22:47:31 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05F4733D; Wed, 29 Oct 2014 22:47:31 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lj1so4054254pab.8 for ; Wed, 29 Oct 2014 15:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=adayjtGnjEYhqh5sj0mpLjHOyhiZp00bdJ/SWvgP6cg=; b=pdAbUvK5LoWt7Q1+XAKMm3n6mWUPYGJjVyMzkVQomAQ31x4qfUpip6SpJtCVDUbEpq cudwSUtC6lcuDYX3ZMJNzVK3xyu2OtHW28RFXAN2CJYUkxVSKzaDkk/FkOzaKWWgUQin cqlm/RGceWQXj1Y06/SnzTPCJgjMRHC0+TlJeXrxf+s71gG6KEnEq3jPW4vLldVS5dp2 CBvmRCZCdbFM8jRJ3W79awtRhsPrxRDdGmJsZg4n7pu7bgYu+HS+hfhFFVe2sBpd9d2C 6NG1hw36NI3em3Soe8G437Yemo9BUgyyQSTOd41EDCwthLUZbBHVCp6S8M71hrT+u6uE JCww== X-Received: by 10.70.23.133 with SMTP id m5mr13155179pdf.131.1414622850635; Wed, 29 Oct 2014 15:47:30 -0700 (PDT) Received: from [10.222.96.105] (mobile-166-171-121-185.mycingular.net. [166.171.121.185]) by mx.google.com with ESMTPSA id s15sm5235859pdl.90.2014.10.29.15.47.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 15:47:29 -0700 (PDT) References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> <1414593742.17308.72.camel@revolution.hippie.lan> <20141029212454.6fcfc3ac@onyx.thanelange.no> <1414616599.17308.141.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1414616599.17308.141.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4C533C42-2919-4E96-856C-FB6369F453FB@gmail.com> X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Date: Wed, 29 Oct 2014 15:47:25 -0700 To: Ian Lepore Cc: Gyrd Thane Lange , FreeBSD Current , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 22:47:31 -0000 > On Oct 29, 2014, at 14:03, Ian Lepore wrote: ... > It appears that src/Makefile.inc1 already does the right thing in > regards to building ctconvert as a bootstrap tool when it needs to. Yes and no. The assumption with the version checks is the the tool is presen= t on the base system (which might be invalidated by build options or install= root pruning) and doesn't necessarily need to be rebuilt. It's an optimizat= ion that works in most, but not all cases. This is why make in /Makefile has testcases to ensure that it can bootstrap t= he build properly. >> happen to notice it sooner because I have no ctfconvert installed on >> the host beforehand. Actually, mine is the better situation in that the >> build stopped with an up front error instead of using the wrong >> (possible outdated) tools and introduced other subtle errors. >>=20 >> I believe this is reproducible on anybodys system by deleting/moving >> the ctfconvert tool away from the host, before trying to build a dtrace >> enabled kernel. >=20 > I think you'll find that that is true of any number of programs > in /usr/bin including, for example, cc or ar or ld. Which gets invalidated periodically, ie you can't build current on certain s= table versions. >> I see elsewhere in the thread that Garret and Mark are onto the real >> problem and solution. >=20 > I don't think so. Mark referred to a problem with the wrong version of > ctfconvert, and he said he thought it had been fixed. Your problem > wasn't corrupted files due to wrong-version. >=20 > We must not let this situation turn into some kind of mythology about an > incompatibility that doesn't exist. You reported that a tool was > missing during the build, we know why it was missing, and we know what > to do to make it not be missing anymore. Problem solved. In the simple case yes, but not in our case. Our case involves making fixes t= o ctfconvert, without bumping the osreldate, because we've forked FreeBSD at= a particular point in time. ctfconvert is not compatible between the build h= ost and the src checkout, so our ctf data gets corrupted when the host copy o= f ctfconvert gets run on the binaries. Cheers..= From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 23:00:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EEF6A6C; Wed, 29 Oct 2014 23:00:32 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1984A75A; Wed, 29 Oct 2014 23:00:32 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id v10so3813256pde.8 for ; Wed, 29 Oct 2014 16:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=SRZgvvQvTtjTmY5IchGB+MjrPu044eEBWDzwfdscOq0=; b=OdtVnolMg9jTKAlW1V2G+LVkmcBNrAbUusNwD1reSDIyDRe28Nb27mFjTz59rgCKrJ R7ZBpAMtD9ZUCw7CrspzYFYNrOotjIw+byK+0wltJ3yhFGxMmobTmUSVXQ/d3ipPt5Zg YCXL8jM/rrm0JTx6/58MsfF2DTTZKmLuqsoKy5GYzcwU4V4JwrXxOwexbWQV4NRYrtnb TejBTAfByG/EaLCAplSCfBcCDHPLrw5FrGP+QkZK28jrutFcMy873NZj0CE6aOEC/h/B ZndZHbniNDw5XNH8ussmAUQsmsuwbJCI0FUh1vieoHNvvy0TWsOoK+8WCA7MxsEI4rES sabQ== X-Received: by 10.67.14.129 with SMTP id fg1mr13091404pad.114.1414623631669; Wed, 29 Oct 2014 16:00:31 -0700 (PDT) Received: from [10.222.96.105] (mobile-166-171-121-185.mycingular.net. [166.171.121.185]) by mx.google.com with ESMTPSA id lr4sm5293908pab.42.2014.10.29.16.00.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 16:00:31 -0700 (PDT) References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> <20141029205336.GA1303@medusa.sysfault.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20141029205336.GA1303@medusa.sysfault.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Tracking enhancements/wishlist items (was "junior kernel tasks") Date: Wed, 29 Oct 2014 16:00:29 -0700 To: Marcus von Appen Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , Eitan Adler , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 23:00:32 -0000 > On Oct 29, 2014, at 13:53, Marcus von Appen wrote: ... If we are going to do that, the area however should be > separate from typical "bugs", so people do not confuse wishes with bugs > and vice versa. Also, to avoid long and misleading comment trails, we > would need the ability to hide/remove errornous (bug-related) comments > in the wishlist (a feature wished for independent of this, but a > necessary prerequisite [probably coming soon]). >=20 > Wishlist items thus should not belong to a currently existing product or > component, but should be clearly classified in an own product and/or > component category. >=20 > Except from that, what else would be required and desired to have a > suitable wishlist? The bug tracker right now features: >=20 > - tags > - keywords > - links to internal bugs/items (dependencies and blockers) > - links to external systems > - links to svn commits and reviews > - attachments > - flags to request/confirm/deny things At $work we use Enhancement in the severity field to generally denote these k= inds of items. However, we could always use wishlist in the Keywords field. All I ask for is a centralized place to track this or easy way to look this u= p instead of 10+ wiki pages and doc pages full of outdated/incorrect materia= l.= From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 23:03:26 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6762D2C; Wed, 29 Oct 2014 23:03:26 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54666796; Wed, 29 Oct 2014 23:03:26 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so3041508wib.11 for ; Wed, 29 Oct 2014 16:03:24 -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=uBgO3f5k7Ezzj/RikNliF7YAZlGJt7qTFU/K4gPWV8g=; b=e7wUkmElDFoTOdUWXPCGWb/cwq0SddhSu2sRS0B2eki3F8EzKysCIsrtV3+9jYU38t VBbGnB2eznQLvNvie34LimnsDCWW93jlkLYL7N72ciGkFgXz3eHDpVQhukIxEdsAYlac ONPAQGUgKMF7yLTGYwSE0IwYdY6qT7kffjEWrc/81Y1CY1dao7cjpHc961mdQds+PiDn H+vCMpRa3sW5twxqNGtFDSdoE7IKi5MTUQCUGXPUvN3z6X8nWq6HczBqlmdDBkatFgc4 qCJet7MyVrlLx3/VL6ejzbkPOPNN42tjhTqJrUVkqg6+E8++BYaz+3rgi/P+Ka2xaDcm 0tOQ== X-Received: by 10.194.82.104 with SMTP id h8mr16037411wjy.44.1414623804543; Wed, 29 Oct 2014 16:03:24 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id u8sm6719503wjq.1.2014.10.29.16.03.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 16:03:23 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 30 Oct 2014 00:03:21 +0100 From: Baptiste Daroussin To: Henry Hu Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029230321.GL11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="00hq2S6J2Jlg6EbK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-ports@freebsd.org" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 23:03:27 -0000 --00hq2S6J2Jlg6EbK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 06:07:44PM -0400, Henry Hu wrote: > Hi, >=20 >=20 > On Tue, Oct 28, 2014 at 7:19 PM, Baptiste Daroussin > wrote: >=20 > > Hi all, > > > > We are starting the release process of pkg 1.4, we want to have a better > > release > > process than with every single previous version of pkg. For that we will > > need > > you help! > > > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > > > Changes you can expect in pkg 1.4 are the following: > > - Loads of bug fixes > > - Stricter checking of the path passed via the plist > > - Removal of the bundled libyaml > > - new --raw-format to chose the output format for info -R and search -R > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become > > FreeBSD:10:amd64) > > the old ABI is available as a fallback in ALTABI > > - pkg check now support a quiet mode > > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerg= ing > > configuration files > > - new @config keyword to mark a file as a config file (during > > upgrade/reinstallation it will try to merge the configuration with the > > one the > > user may have modified) an option AUTOMERGE is available to prevent > > automerging if automerge fails a .pkgnew file will be created along w= ith > > the > > untouched user version of the configuration > > - The update procedure has been improved and speed up a lot (in particu= lar > > for > > machine with low resources) > > - The unique identifier has been modified to be pkgname meaning now por= ts > > can be > > moved in new categories without having to be considered a different > > package > > - Only libraries starting by lib* are added to the provided libraries > > - General speed up of all operations > > > > We need help in testing, but we also need help in writing regression te= sts > > ! > > The more we have tests the more stable the releases will be. > > > > The release will also allow to be able to package base! > > >=20 > I've just tried pkg-devel 1.4.0.alpha3 and found something strange: when a > pkg is removed, pkgs which depend on it are not removed. >=20 > For example: >=20 > > sudo pkg remove libX11 > Checking integrity... done (0 conflicting) > Deinstallation has been requested for the following 1 packages (of 0 > packages in the universe): >=20 > Installed packages to be REMOVED: > libX11-1.6.2_2,1 >=20 > The operation will free 6 MB. >=20 > Proceed with deinstalling packages? [y/N]: > > sudo pkg remove -R libX11 > Checking integrity... done (0 conflicting) > Deinstallation has been requested for the following 1 packages (of 0 > packages in the universe): >=20 > Installed packages to be REMOVED: > libX11-1.6.2_2,1 >=20 > The operation will free 6 MB. >=20 > Proceed with deinstalling packages? [y/N]: >=20 Seems like can you store somewhere you /var/db/pkg/local.sqlite so that we = can fix your situation? Best regards, Bapt --00hq2S6J2Jlg6EbK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRcjkACgkQ8kTtMUmk6Ey6YACfdQFVCQUMkdSdBMAlu/tR335F DzUAoIWSNYYIORBVaSMeIvyvUYgDdpk/ =XyJg -----END PGP SIGNATURE----- --00hq2S6J2Jlg6EbK-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 23:04:36 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A61BBEC5; Wed, 29 Oct 2014 23:04:36 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17CEB7AB; Wed, 29 Oct 2014 23:04:35 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ex7so3049513wid.8 for ; Wed, 29 Oct 2014 16:04:34 -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=PYyqc5G/cp9tHZpQOHRsxlBVxYmWiLZj92u/qmtvtk4=; b=CrMh8nMknMz84NRPOIDS8wEfSKqgrOnAYvvj0iXAFK0h6jvwZNsFhKNRnJShUsRfgm VpCeqAdHe4OeR7B4YiByF2oVU5vLvHpAufzpXKBUbIQIMBSgFvaK95jzSWKm3stXPY1z u7QHkkAHnGwohSIKBT6VLoTFvBw5reUGl2Gu4tLz+z0AWFRgcwjJ2l91G7/arZADQ5yX g7pXy+m1w1FOWLeDGWptAbBMSaFxj9ElucyG/SoWkdLOcfUuq+jedttRd5LrQcRqWkI/ 6a8WVU43yhk4xG3fRcK6f9UtXx+OjVkF0Khs9Fqy6fp4nxCnNwGi1QBxZl9/83q0svZa +kvg== X-Received: by 10.194.223.67 with SMTP id qs3mr1261wjc.127.1414623874479; Wed, 29 Oct 2014 16:04:34 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id u8sm6722098wjq.1.2014.10.29.16.04.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 16:04:33 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 30 Oct 2014 00:04:31 +0100 From: Baptiste Daroussin To: Guido Falsi Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141029230431.GM11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <54515E27.9010404@madpilot.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jB+02Y6wHc2pEa2x" Content-Disposition: inline In-Reply-To: <54515E27.9010404@madpilot.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 29 Oct 2014 23:04:36 -0000 --jB+02Y6wHc2pEa2x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 10:37:43PM +0100, Guido Falsi wrote: > On 10/29/14 00:19, Baptiste Daroussin wrote: > > Hi all, > >=20 > > We are starting the release process of pkg 1.4, we want to have a bette= r release > > process than with every single previous version of pkg. For that we wil= l need > > you help! >=20 > Hi, last version works fine, but, sometimes, core files show up in port > directory...for no reason, really. >=20 > Noticed this while doing some make patch and make extract in a > standalone port directory outside the ports tree. >=20 > Anyway are you interested in the core file for investigation? >=20 > This is a backtrace: >=20 > (gdb) bt > #0 0x00000000007df0bb in strlen () > #1 0x0000000000402c88 in add_to_check (head=3D0x7fffffffe0f8, > pkg=3D0x80105b600) > at audit.c:79 > #2 0x000000000040200e in exec_audit (argc=3D1, argv=3D0x7fffffffe898) > at audit.c:205 > #3 0x0000000000411132 in main (argc=3D2, argv=3D0x7fffffffe890) at main.= c:822 >=20 Disable vulnerability checking in your ports tree waiting for pkg 1.4.0.alp= ha4 to be released (which should happen in a couple of hours now) This has been fixed in git master Best regards, Bapt --jB+02Y6wHc2pEa2x Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRcn8ACgkQ8kTtMUmk6Ex5UACfXpzBgfBShkm7LBLPDFvPv2ae PJUAn0GuolFP7w+ii4jYhFMiqRnR6F4w =9flV -----END PGP SIGNATURE----- --jB+02Y6wHc2pEa2x-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 00:39:51 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B14D5499; Thu, 30 Oct 2014 00:39:51 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FF81125; Thu, 30 Oct 2014 00:39:50 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so6044380wiv.3 for ; Wed, 29 Oct 2014 17:39:49 -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=0i6dydH4AfJ6ScuiKjRtjMdMrJOEiT8WJsAJAXtyw7U=; b=rd2OM/HA9XLRfzAd1F5DGG7KnSOaPd0qKgHc5meOX06Eyns/ibl2OvolVjUK/8NZGl T2pbeCm9yZUiQ9YpYQBCtY4NgcNoU8hzLYso8GypTNhF+lsAZbcvD5J1AGAgmZrfqWQT N9zHNkMgu7d3wpP+uBcMZcbYPN4Bf+yAjag30Y2J4XMb7wY2PBdejfQ77m0J42412Hiw ThgOkMn8rrW01lif6Q5AfLgxgeiiwwLJ7kKb58T0AJ/4NvK/lpUL2QOUNPzHsMpw9eSX Wq3g06ihOVJFk5ttdVwQj9UGgbvlsY91ensjArr0CIrO/QV3Gbm7VKHAv6ggGE+WhHdV N1pQ== X-Received: by 10.194.100.98 with SMTP id ex2mr15933612wjb.48.1414629589312; Wed, 29 Oct 2014 17:39:49 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id gy4sm980531wib.11.2014.10.29.17.39.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 17:39:48 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 30 Oct 2014 01:39:46 +0100 From: Baptiste Daroussin To: Henry Hu Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141030003946.GR11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029230321.GL11033@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7UIJfHqpdi+oBJdT" Content-Disposition: inline In-Reply-To: <20141029230321.GL11033@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-ports@freebsd.org" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 00:39:51 -0000 --7UIJfHqpdi+oBJdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2014 at 12:03:21AM +0100, Baptiste Daroussin wrote: > On Wed, Oct 29, 2014 at 06:07:44PM -0400, Henry Hu wrote: > > Hi, > >=20 > >=20 > > On Tue, Oct 28, 2014 at 7:19 PM, Baptiste Daroussin > > wrote: > >=20 > > > Hi all, > > > > > > We are starting the release process of pkg 1.4, we want to have a bet= ter > > > release > > > process than with every single previous version of pkg. For that we w= ill > > > need > > > you help! > > > > > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > > > > > Changes you can expect in pkg 1.4 are the following: > > > - Loads of bug fixes > > > - Stricter checking of the path passed via the plist > > > - Removal of the bundled libyaml > > > - new --raw-format to chose the output format for info -R and search = -R > > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become > > > FreeBSD:10:amd64) > > > the old ABI is available as a fallback in ALTABI > > > - pkg check now support a quiet mode > > > - new 3 way merge code ("stolen" from the fossil-scm) to allow autome= rging > > > configuration files > > > - new @config keyword to mark a file as a config file (during > > > upgrade/reinstallation it will try to merge the configuration with = the > > > one the > > > user may have modified) an option AUTOMERGE is available to prevent > > > automerging if automerge fails a .pkgnew file will be created along= with > > > the > > > untouched user version of the configuration > > > - The update procedure has been improved and speed up a lot (in parti= cular > > > for > > > machine with low resources) > > > - The unique identifier has been modified to be pkgname meaning now p= orts > > > can be > > > moved in new categories without having to be considered a different > > > package > > > - Only libraries starting by lib* are added to the provided libraries > > > - General speed up of all operations > > > > > > We need help in testing, but we also need help in writing regression = tests > > > ! > > > The more we have tests the more stable the releases will be. > > > > > > The release will also allow to be able to package base! > > > > >=20 > > I've just tried pkg-devel 1.4.0.alpha3 and found something strange: whe= n a > > pkg is removed, pkgs which depend on it are not removed. > >=20 > > For example: > >=20 > > > sudo pkg remove libX11 > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > >=20 > > Installed packages to be REMOVED: > > libX11-1.6.2_2,1 > >=20 > > The operation will free 6 MB. > >=20 > > Proceed with deinstalling packages? [y/N]: > > > sudo pkg remove -R libX11 > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > >=20 > > Installed packages to be REMOVED: > > libX11-1.6.2_2,1 > >=20 > > The operation will free 6 MB. > >=20 > > Proceed with deinstalling packages? [y/N]: > >=20 > Seems like can you store somewhere you /var/db/pkg/local.sqlite so that w= e can > fix your situation? >=20 > Best regards, > Bapt Thanks fixed in the git master will be in alpha4 Actually you have lots of locked packages so on alpha4 pkg will just tell y= ou that libX11 cannot be removed because of locks :) regards, Bapt --7UIJfHqpdi+oBJdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRiNIACgkQ8kTtMUmk6Ex3XwCgv9H4ZIY29hEt0RMecjeP/9a1 QqkAn3MwR4jw9r7kTeVT/TviSx8GfhLV =ukEQ -----END PGP SIGNATURE----- --7UIJfHqpdi+oBJdT-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 00:43:12 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC0DC668; Thu, 30 Oct 2014 00:43:12 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 761461DB; Thu, 30 Oct 2014 00:43:12 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id la4so1280911vcb.1 for ; Wed, 29 Oct 2014 17:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zkqguEi+UzmMfOk4JBVK3rEbqrb1VJncS5dQoTGgbLk=; b=EbnZkzNP1iUO2dwqnnPkSEnSziBjmUnXaAV2zgpEclRgprpGoyV+DMbI8/akUWhIps oROcMS2P42aX3TWDok5X40oVDh0fAUGvX3hdof6cW6NIxn8uYwEPGl3sRl4RhsYxlFby yTajnw5dC/ouwJZ2bujWKlqNVHA5f2cUcHwOsAzUDchRcJ+Rv7kn+5mXPHbbl2tRv4zJ vjQbMqNRMQwkFJ8/E9skR+IoGbAwCHhPKy+w4mle4XQdJ5qR3ozza/7LRYVYjXRDf6HT KAkpFg/0lZbOSSgIs4R3LbTNZRgsHfuPDO/VgtAKswX2OpNMN/p1li6gYwX53X6xwuLh pIXg== X-Received: by 10.220.168.74 with SMTP id t10mr8378416vcy.47.1414629791412; Wed, 29 Oct 2014 17:43:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.136.76 with HTTP; Wed, 29 Oct 2014 17:42:30 -0700 (PDT) In-Reply-To: <20141030003946.GR11033@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141029230321.GL11033@ivaldir.etoilebsd.net> <20141030003946.GR11033@ivaldir.etoilebsd.net> From: Henry Hu Date: Wed, 29 Oct 2014 20:42:30 -0400 Message-ID: Subject: Re: pkg 1.4 freeze please test test test! To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-ports@freebsd.org" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 00:43:13 -0000 On Wed, Oct 29, 2014 at 8:39 PM, Baptiste Daroussin wrote: > On Thu, Oct 30, 2014 at 12:03:21AM +0100, Baptiste Daroussin wrote: > > On Wed, Oct 29, 2014 at 06:07:44PM -0400, Henry Hu wrote: > > > Hi, > > > > > > > > > On Tue, Oct 28, 2014 at 7:19 PM, Baptiste Daroussin > > > wrote: > > > > > > > Hi all, > > > > > > > > We are starting the release process of pkg 1.4, we want to have a > better > > > > release > > > > process than with every single previous version of pkg. For that we > will > > > > need > > > > you help! > > > > > > > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > > > > > > > Changes you can expect in pkg 1.4 are the following: > > > > - Loads of bug fixes > > > > - Stricter checking of the path passed via the plist > > > > - Removal of the bundled libyaml > > > > - new --raw-format to chose the output format for info -R and search > -R > > > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become > > > > FreeBSD:10:amd64) > > > > the old ABI is available as a fallback in ALTABI > > > > - pkg check now support a quiet mode > > > > - new 3 way merge code ("stolen" from the fossil-scm) to allow > automerging > > > > configuration files > > > > - new @config keyword to mark a file as a config file (during > > > > upgrade/reinstallation it will try to merge the configuration with > the > > > > one the > > > > user may have modified) an option AUTOMERGE is available to prevent > > > > automerging if automerge fails a .pkgnew file will be created > along with > > > > the > > > > untouched user version of the configuration > > > > - The update procedure has been improved and speed up a lot (in > particular > > > > for > > > > machine with low resources) > > > > - The unique identifier has been modified to be pkgname meaning now > ports > > > > can be > > > > moved in new categories without having to be considered a different > > > > package > > > > - Only libraries starting by lib* are added to the provided libraries > > > > - General speed up of all operations > > > > > > > > We need help in testing, but we also need help in writing regression > tests > > > > ! > > > > The more we have tests the more stable the releases will be. > > > > > > > > The release will also allow to be able to package base! > > > > > > > > > > I've just tried pkg-devel 1.4.0.alpha3 and found something strange: > when a > > > pkg is removed, pkgs which depend on it are not removed. > > > > > > For example: > > > > > > > sudo pkg remove libX11 > > > Checking integrity... done (0 conflicting) > > > Deinstallation has been requested for the following 1 packages (of 0 > > > packages in the universe): > > > > > > Installed packages to be REMOVED: > > > libX11-1.6.2_2,1 > > > > > > The operation will free 6 MB. > > > > > > Proceed with deinstalling packages? [y/N]: > > > > sudo pkg remove -R libX11 > > > Checking integrity... done (0 conflicting) > > > Deinstallation has been requested for the following 1 packages (of 0 > > > packages in the universe): > > > > > > Installed packages to be REMOVED: > > > libX11-1.6.2_2,1 > > > > > > The operation will free 6 MB. > > > > > > Proceed with deinstalling packages? [y/N]: > > > > > Seems like can you store somewhere you /var/db/pkg/local.sqlite so that > we can > > fix your situation? > > > > Best regards, > > Bapt > > Thanks fixed in the git master will be in alpha4 > Thanks! Nice work! > Actually you have lots of locked packages so on alpha4 pkg will just tell > you > that libX11 cannot be removed because of locks :) > Well, I don't like to lock pkgs, but that's the only option I know to keep my packages with different options selected intact during pkg upgrade. > > regards, > Bapt > -- Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 02:34:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBC3A3A3; Thu, 30 Oct 2014 02:34:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B248DAB; Thu, 30 Oct 2014 02:34:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id s9U2WP23042273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Oct 2014 19:32:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id s9U2WOHF042272; Wed, 29 Oct 2014 19:32:24 -0700 (PDT) (envelope-from sgk) Date: Wed, 29 Oct 2014 19:32:24 -0700 From: Steve Kargl To: Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Message-ID: <20141030023224.GA42236@troutmask.apl.washington.edu> References: <54511A7E.1020307@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current , Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 02:34:33 -0000 On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote: > On 29 October 2014 12:49, Steven Hartland wrote: > > Hmm not sure I like this idea as it would make it more difficult to make a > > copy / backup a kernel. > > > > ATM when I want to copy a kernel for debugging its a one liner, splitting > > debug symbols off to /usr/lib would prevent this. > > To retain the current behaviour you can set DEBUGDIR= (i.e., empty), > as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}. No, you can't. su root cp -pR /boot/kernel /boot/good Where does DEBUGDIR enter the picture? The above will copy both kernel and kernel.symbol to /boot/good. With your scheme one loses kernel.symbol (along with all other *.symbol files?). If one escapes to the boot prompt, she can do 'boot /boot/good/kernel', will the boot process automatically find a (nonexistant?) /usr/lib/boot/good/kernel.symbol. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 02:52:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FE0D712 for ; Thu, 30 Oct 2014 02:52:13 +0000 (UTC) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E55EBF64 for ; Thu, 30 Oct 2014 02:52:12 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id y10so263626wgg.16 for ; Wed, 29 Oct 2014 19:52:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HK4yn/sV47Xo/h7H/ZlWdj25c5LR6S1QSGfaSpdbTI0=; b=Uy2wT0r67Ah7sLEpt1frrfNn+9dzE9BFXtnojMrVtXBY78TdRFVKPJwVhWTXCnLHYy k0t+97LoVYK1DMxppHkmnES+OwhDxks08H9IqgU8eV0DmWrCUZkQbvvzLCXLOD60jlb6 fxC+Wk0tKeZitsFteWSKMiUOJR5lsDxCngtMCtUomBzdhyWaQSYAh/A4uZx/cAUR+Wad eOpcp9XcrUV3dOjDoJ6EJHgw+ePiyKydL/0OkSdjagtMmqjignEm/lxGZVuWc5rTPrTu MSEqxdTwKU/VYmpz/+ysMblr2VFanR8SQYSDGHC0xFN32YuLwe2sbB6zDnHTioZc/SdT +9qA== X-Gm-Message-State: ALoCoQl7UAQATu0LOmIF9hlR8rR4Y5b/2Bvw5LPpLw1XsEaMiYqDeaiOhK8+NjSsCagsRHdoAHPV X-Received: by 10.180.10.231 with SMTP id l7mr40427601wib.1.1414637525414; Wed, 29 Oct 2014 19:52:05 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id 10sm7126669wjs.21.2014.10.29.19.52.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 19:52:04 -0700 (PDT) Message-ID: <5451A843.90805@multiplay.co.uk> Date: Thu, 30 Oct 2014 02:53:55 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Steve Kargl , Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> In-Reply-To: <20141030023224.GA42236@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 02:52:13 -0000 On 30/10/2014 02:32, Steve Kargl wrote: > On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote: >> On 29 October 2014 12:49, Steven Hartland wrote: >>> Hmm not sure I like this idea as it would make it more difficult to make a >>> copy / backup a kernel. >>> >>> ATM when I want to copy a kernel for debugging its a one liner, splitting >>> debug symbols off to /usr/lib would prevent this. >> To retain the current behaviour you can set DEBUGDIR= (i.e., empty), >> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}. > No, you can't. > > su root > cp -pR /boot/kernel /boot/good > > Where does DEBUGDIR enter the picture? The above will copy > both kernel and kernel.symbol to /boot/good. With your scheme > one loses kernel.symbol (along with all other *.symbol files?). > If one escapes to the boot prompt, she can do 'boot /boot/good/kernel', > will the boot process automatically find a (nonexistant?) > /usr/lib/boot/good/kernel.symbol. Indeed, if my understanding of this proposal is correct it will make working with multiple kernels much harder. Making things harder to manage vs saving a little bit of space on the root partition really doesn't sound like a good idea; especially when with the ZFS install, which I would suggest is becoming the norm, the root partition doesn't suffer from space issues anyway. From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 02:53:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08BC2823; Thu, 30 Oct 2014 02:53:23 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CA6DAF70; Thu, 30 Oct 2014 02:53:22 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9U2rHkj003422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 19:53:20 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5451A817.4030704@freebsd.org> Date: Thu, 30 Oct 2014 10:53:11 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Kargl , Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> In-Reply-To: <20141030023224.GA42236@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 02:53:23 -0000 On 10/30/14, 10:32 AM, Steve Kargl wrote: > On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote: >> On 29 October 2014 12:49, Steven Hartland wrote: >>> Hmm not sure I like this idea as it would make it more difficult to make a >>> copy / backup a kernel. >>> >>> ATM when I want to copy a kernel for debugging its a one liner, splitting >>> debug symbols off to /usr/lib would prevent this. >> To retain the current behaviour you can set DEBUGDIR= (i.e., empty), >> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}. > No, you can't. > > su root > cp -pR /boot/kernel /boot/good > > Where does DEBUGDIR enter the picture? The above will copy > both kernel and kernel.symbol to /boot/good. With your scheme > one loses kernel.symbol (along with all other *.symbol files?). > If one escapes to the boot prompt, she can do 'boot /boot/good/kernel', > will the boot process automatically find a (nonexistant?) > /usr/lib/boot/good/kernel.symbol. you can also set "KERNEL" in the make and it will install to /boot/$KERNEL/ It would need to put the symbols in /usr/lib/...$KERNEL/ as well, and then you are bound to get confusion when you copy the new kernel to the default place when you tested it. maybe put a symlink in the kernel directory and follow that? keeping symbols and kernel in sync is going to get a lot more complicated. > From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 04:00:59 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2B0744D; Thu, 30 Oct 2014 04:00:59 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 477FD8EF; Thu, 30 Oct 2014 04:00:59 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s9U40meC028718; Wed, 29 Oct 2014 20:00:52 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201410300400.s9U40meC028718@gw.catspoiler.org> Date: Wed, 29 Oct 2014 21:00:48 -0700 (PDT) From: Don Lewis Subject: Re: pkg 1.4 freeze please test test test! To: bapt@FreeBSD.org In-Reply-To: <20141029201800.GH11033@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 04:00:59 -0000 On 29 Oct, Baptiste Daroussin wrote: > On Wed, Oct 29, 2014 at 01:15:16PM -0700, Don Lewis wrote: >> On 28 Oct, Don Lewis wrote: >> > On 29 Oct, Baptiste Daroussin wrote: >> >> Hi all, >> >> >> >> We are starting the release process of pkg 1.4, we want to have a better release >> >> process than with every single previous version of pkg. For that we will need >> >> you help! >> >> >> >> pkg-devel has been updated to the latest version of pkg as of alpha2. >> >> >> >> Changes you can expect in pkg 1.4 are the following: >> >> - Loads of bug fixes >> > >> > I kind of doubt that I'll have time to test it, but I've stumbled across >> > an interesting test case for package building with pkg-1.3.8_3. >> > >> > When I tried to build a multimedia/2mandvd package with >> > poudriere (either bulk or testport) in a FreeBSD 10 amd64 host and jail, >> > pkg-static segfaults. Portsmon also sees this failure, which also >> > seems to be affecting head/amd64 as well: >> > >> > >> > If I run poudriere jail -i to keep the jail around, I don't see any >> > leftover core files, I'm guessing because pkg-static's cwd is in the r/o >> > /usr/ports tree. If I then cd /usr/ports/multimedia/2mandvd in the >> > jail and run: >> > make clean >> > make stage >> > make package >> > pkg-static doesn't segfault, but it never exits either. I left it >> > running for a couple of days and it was still stuck at 100% CPU. If >> > I truss -p the process, I don't get any output, which means it's not >> > doing any syscalls. >> >> >> I found some time to test this version. I added WITH_PKG=devel to the >> make.conf file for the poudriere jail and ran: >> >> poudriere testport -j 101STABLEamd64 -o multimedia/2mandvd > > Ah crap this 2mandvd again..... > > Ok I'll track it down, thanks Seems to work fine on 8.4, both i386 and amd64, so it appears to be sensitive to something in base. > 2mandvd is a nightmare for me :) Back when I was still using portupgrade to build packages, I didn't have trouble building the package, but portupgrade would fail during the deinstall phase for 2mandvd. I think it was complaining about non-ASCII characters in the plist, but I don't know where the error was coming from. I didn't have trouble manually doing the deinstall with pkg delete, and then I could run portupgrade -Np. I didn't think of trying pkg-static to see if it behaved differently. From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 06:19:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDB90752 for ; Thu, 30 Oct 2014 06:19:53 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A446E825 for ; Thu, 30 Oct 2014 06:19:53 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id x3so3676179qcv.18 for ; Wed, 29 Oct 2014 23:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4hHdKiUZMR8yQgL45C06/kKdvKAA0YK5plBoYmPnYWc=; b=JAZAopk5cK3rf9PfSm1HkMDSeAch5HabDNKbJS4JSgu2+vevbPwzwtOSU261H1BAu6 TgKvh7cl9R+I+V04i9KpA2wzrjCq0LQlSVEeRKvpFY0zxFTsplnZCPB1xUGLB/w3QWnD HPwdDoWlZe5QBuurDeP2HpFnkSWS+9JCtxlp4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4hHdKiUZMR8yQgL45C06/kKdvKAA0YK5plBoYmPnYWc=; b=gdpsbl14fbM00JpACb8cPVYxNOHlOgirBMJMIPPorUxNj2Pkez37/piIyZ5Q6Hj+it Ffh6DT5uWZGe926zezhexi/3CLBMwLGC0c2cipYbr3jNCmSlv/YyuaZZ9qOVIscgzWNN qm1g9OuvM1kegts8UQXPHEXpcvNtfkAVIwhyQdDBaDIAdvdkVsoaKnJ8FU4vnw6Rftef O1875srPy/Pm5oIcaddLcsuZt/oa5y60tgdXHAIAhtR5SllNsaCm+oQS8gsLjQaZOI8J YDEM1lHwuWLB3c2weFVd/WSYLCk/N4efbZLGCtiP/Auo8YgOYUu6uzxuWJtaehXUrU7/ 0q5A== X-Gm-Message-State: ALoCoQlgaCFY9iZhKpn0oec01qrqoTC/psYi2nD84lYFVDMKppTmQxaKwfwetsvvaT2JcZcmYFsO X-Received: by 10.229.53.133 with SMTP id m5mr23197891qcg.28.1414649992583; Wed, 29 Oct 2014 23:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.131 with HTTP; Wed, 29 Oct 2014 23:19:22 -0700 (PDT) In-Reply-To: References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> <20141029205336.GA1303@medusa.sysfault.org> From: Eitan Adler Date: Wed, 29 Oct 2014 23:19:22 -0700 Message-ID: Subject: Re: Tracking enhancements/wishlist items (was "junior kernel tasks") To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 06:19:54 -0000 On 29 October 2014 16:00, Garrett Cooper wrote: > >> On Oct 29, 2014, at 13:53, Marcus von Appen wrote: > > ... > > If we are going to do that, the area however should be >> separate from typical "bugs", so people do not confuse wishes with bugs >> and vice versa. Also, to avoid long and misleading comment trails, we >> would need the ability to hide/remove errornous (bug-related) comments >> in the wishlist (a feature wished for independent of this, but a >> necessary prerequisite [probably coming soon]). >> >> Wishlist items thus should not belong to a currently existing product or >> component, but should be clearly classified in an own product and/or >> component category. >> >> Except from that, what else would be required and desired to have a >> suitable wishlist? The bug tracker right now features: >> >> - tags >> - keywords >> - links to internal bugs/items (dependencies and blockers) >> - links to external systems >> - links to svn commits and reviews >> - attachments >> - flags to request/confirm/deny things > > At $work we use Enhancement in the severity field to generally denote these kinds of items. However, we could always use wishlist in the Keywords field. > > All I ask for is a centralized place to track this or easy way to look this up instead of 10+ wiki pages and doc pages full of outdated/incorrect material. I don't object to an 'Enhancement' section of the bug tracker. This is far better than split trackers. Generally, I've found that using bug trackers for wishlist items leads to other discoverability problems, but if we manage to solve that, then it isn't terrible. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 06:20:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F98B948; Thu, 30 Oct 2014 06:20:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D54608CB; Thu, 30 Oct 2014 06:20:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s9U6KQhh012127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 23:20:27 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s9U6KQFl012126; Wed, 29 Oct 2014 23:20:26 -0700 (PDT) (envelope-from jmg) Date: Wed, 29 Oct 2014 23:20:26 -0700 From: John-Mark Gurney To: Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Message-ID: <20141030062026.GC8852@funkthat.com> Mail-Followup-To: Ed Maste , freebsd-current@freebsd.org References: <54511A7E.1020307@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54511A7E.1020307@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 29 Oct 2014 23:20:27 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 06:20:28 -0000 Steven Hartland wrote this message on Wed, Oct 29, 2014 at 16:49 +0000: > Hmm not sure I like this idea as it would make it more difficult to make > a copy / backup a kernel. > > ATM when I want to copy a kernel for debugging its a one liner, > splitting debug symbols off to /usr/lib would prevent this. > > Is there not a way to allow separate install of the debug files but to > the same location maintaining compartmentalization for the needed kernel > files? Oh, make sure that make install (or installkernel) properly handles moving the debug data too... i.e. kernel to kernel.old... > On 29/10/2014 00:20, Ed Maste wrote: > >I am preparing to move the standalone kernel debug data out of > >/boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach > >used for userland debug data. This significantly reduces the boot > >partition size requirement, and is a step towards supporting the > >installation of kernel debug data ony when required. LLDB and GDB > >automatically search for debug data under /usr/lib/debug/ so this > >change should be transparent from an end-user perspective. > > > >The change can be reviewed in Phabricator at > >https://reviews.freebsd.org/D1006 and can be fetched as a unified diff > >from https://people.freebsd.org/~emaste/patches/D1006.diff > > > >This does not change any defaults or knobs: kernel debug files are > >still built by default, and may be disabled by setting > >WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize > >this with userland debug in a later step. > > > >Note that the change renames the intermediate and debug data files to > >be consistent with userland debug data: in the build directory the > >kernel with debug data included is now named kernel.full, and and > >kernel.debug is the standalone debug data file. > > > >I plan to merge this in a few days if there are no issues reported in > >further review or testing. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 08:21:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D74DCE01; Thu, 30 Oct 2014 08:21:27 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97E907B1; Thu, 30 Oct 2014 08:21:27 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Xjkys-001itA-8B>; Thu, 30 Oct 2014 09:21:18 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=prometheus) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Xjkys-003k8z-3s>; Thu, 30 Oct 2014 09:21:18 +0100 Date: Thu, 30 Oct 2014 09:20:39 +0100 From: "O. Hartmann" To: freebsd-current , freebsd-questions Subject: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so Message-ID: <20141030092039.47802349@prometheus> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 08:21:27 -0000 On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 07:52:22 CET 2014 amd64) a running net/openldap24-sasl-server system is installed and running and is now about to be the database backend for Kerberos/Heimdal. net/openldap24-sasl-server is at openldap-sasl-server-2.4.40. The database storage scheme of the LDAP backend is MDB, as it is highly recommended by the vendors of OpenLDAP. Searching for suitable manuals, I found some HowTos describing how to setup MIT Kerberos V with an OpenLDAP backend and I started following the instructions there. Despite the fact that http://www.h5l.org/manual is dead(!) and no usefull documentation or any kind of a hint where to find useful documentation for Heimdal can be found, many of the MIT Kerberos V setup instructions seem to be a dead end when using Heimdal on FreeBSD. Most of the links on that heimdal site ends up in ERROR 404! Well, I think my objective isn't that exotic in an more advanced server environment and I think since FreeBSD is supposed to be used in advanced server environments this task should be well known - but little information/documentation is available. Nevertheless, I use the base system's heimdal implementation and I run into a very frustrating error when trying to run "kamdin -l": kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so: Cannot open "/usr/lib/hdb_ldap.so" The setup for the stanza [kdc] is [...] [kdc] database = { dbname=ldap:ou=kerberos,dc=server,dc=gdr #hdb-ldap-structural-object = inetOrgPerson mkey_file = /var/heimdal/m-key acl_file = /var/heimdal/kadmind.acl } instructions taken from http://www.padl.com/Research/Heimdal.html. Well, it seems that FreeBSD ships with a crippled heimdal implementation. Where is /usr/lib/hdb_ldap.so? I'm toying around this issue for several days now and it gets more and more frustrating, also with the perspective of having no running samba 4.1 server for the windows domain. Can someone give me a hint where to find suitable FreeBSD docs for a task like this? I guess since FreeBSD is considered a server OS more than a desktop/toy OS, there must be a solution for this. FreeBSD ships with heimdal in the base, but it seems this heimdal is broken. P.S. Please CC me. From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 08:35:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77B0D45E for ; Thu, 30 Oct 2014 08:35:54 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 061558F5 for ; Thu, 30 Oct 2014 08:35:53 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id m15so3643186wgh.21 for ; Thu, 30 Oct 2014 01:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7KBQOZD8KEEEBmb2xgogw7PlVxaxKeyKmYqy1GOMXxA=; b=OHmE8FvgPCzMA1Is9i1MLcLW1ODNJIFmqv1DK9RmxmNf7TNwiWrjkd9ykqHjzOhbCj lvnyjqRN9fMn673BTp6JXaUT7hu7P6e0oZW9ObdieVrMUvOX/9GLdUlEnBhQchIF0Gyd +GVnlofTXbegHcqoXXQaGIxvUgX2/n8F/dGGoMzybkVJ/zdrAgAoNEGYmU61EvDVq7y7 dtSDWNDqgEDaY+d3xLfbvhNrWAf6C0oXCs1wMec3sZSFYDQ65eOdVLedu7KzJIxcLWsL no4cxu2rGRy1gJ1qJMRVGu4DY1vgqulXwDBHQ49Z6bm7NftqCm44bdSbUtDgDirQxiqU idEw== X-Received: by 10.180.19.68 with SMTP id c4mr18661011wie.44.1414658151419; Thu, 30 Oct 2014 01:35:51 -0700 (PDT) Received: from [192.168.50.14] (business-86-101-229-9.business.broadband.hu. [86.101.229.9]) by mx.google.com with ESMTPSA id ua8sm7883490wjc.7.2014.10.30.01.35.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 01:35:50 -0700 (PDT) Message-ID: <5451F865.4040004@gmail.com> Date: Thu, 30 Oct 2014 09:35:49 +0100 From: =?ISO-8859-1?Q?L=E9vai_L=E1szl=F3?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.8.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so References: <20141030092039.47802349@prometheus> In-Reply-To: <20141030092039.47802349@prometheus> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 08:35:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, try this: [1] kill all kerberos process [2] to start KDC: /usr/local/libexec/kdc --detach [3] /usr/local/sbin/kadmin -l kadmin> list -l * [...] Principal: krbtgt/... Principal expires: never Password expires: never Last password change: never Max ticket life: unlimited Max renewable life: unlimited Kvno: 1 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes: Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: Principal: kadmin/changepw@... Principal expires: never Password expires: never Last password change: never Max ticket life: 5 minutes Max renewable life: 5 minutes Kvno: 1 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes: pwchange-service, requires-pre-auth, disallow-proxiable, disallow-renewable, disallow-tgt-based, disallow-postdated Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: Principal: kadmin/admin@... Principal expires: never Password expires: never Last password change: never Max ticket life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes: requires-pre-auth Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: Principal: changepw/kerberos@... Principal expires: never Password expires: never Last password change: never Max ticket life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: pwchange-service, disallow-tgt-based Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: Principal: kadmin/hprop@... Principal expires: never Password expires: never Last password change: never Max ticket life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: requires-pre-auth, disallow-tgt-based Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: Principal: WELLKNOWN/ANONYMOUS@... Principal expires: never Password expires: never Last password change: never Max ticket life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: requires-pre-auth Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: Principal: default@... Principal expires: never Password expires: never Last password change: never Max ticket life: 1 day Max renewable life: 1 week Kvno: 1 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: disallow-all-tix Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: [...] 2014-10-30 09:20 keltezéssel, O. Hartmann írta: > On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 07:52:22 > CET 2014 amd64) a running net/openldap24-sasl-server system is > installed and running and is now about to be the database backend > for Kerberos/Heimdal. net/openldap24-sasl-server is at > openldap-sasl-server-2.4.40. > > The database storage scheme of the LDAP backend is MDB, as it is > highly recommended by the vendors of OpenLDAP. > > Searching for suitable manuals, I found some HowTos describing how > to setup MIT Kerberos V with an OpenLDAP backend and I started > following the instructions there. Despite the fact that > http://www.h5l.org/manual is dead(!) and no usefull documentation > or any kind of a hint where to find useful documentation for > Heimdal can be found, many of the MIT Kerberos V setup instructions > seem to be a dead end when using Heimdal on FreeBSD. Most of the > links on that heimdal site ends up in ERROR 404! > > Well, I think my objective isn't that exotic in an more advanced > server environment and I think since FreeBSD is supposed to be used > in advanced server environments this task should be well known - > but little information/documentation is available. > > Nevertheless, I use the base system's heimdal implementation and I > run into a very frustrating error when trying to run "kamdin -l": > > kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so: > Cannot open "/usr/lib/hdb_ldap.so" > > The setup for the stanza [kdc] is > > [...] [kdc] database = { > dbname=ldap:ou=kerberos,dc=server,dc=gdr > #hdb-ldap-structural-object = inetOrgPerson mkey_file = > /var/heimdal/m-key acl_file = /var/heimdal/kadmind.acl } > > instructions taken from > http://www.padl.com/Research/Heimdal.html. > > Well, it seems that FreeBSD ships with a crippled heimdal > implementation. Where is /usr/lib/hdb_ldap.so? > > I'm toying around this issue for several days now and it gets more > and more frustrating, also with the perspective of having no > running samba 4.1 server for the windows domain. > > Can someone give me a hint where to find suitable FreeBSD docs for > a task like this? I guess since FreeBSD is considered a server OS > more than a desktop/toy OS, there must be a solution for this. > FreeBSD ships with heimdal in the base, but it seems this heimdal > is broken. > > P.S. Please CC me. _______________________________________________ > 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" > - -- Tisztelettel: Lévai László -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRR+GEACgkQtgVHtSvpUlo8hgD/dJbCxh7dBdm1tosZ8fdmMuCf o6fBH3629SPMpGxxon0A/jK7hheRgcJYaIRTVUbmwKm3clbkVW4smcNCf8dPrTq5 =vvoI -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 08:48:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCA21633 for ; Thu, 30 Oct 2014 08:48:30 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61B889E7 for ; Thu, 30 Oct 2014 08:48:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XjlPA-001zja-Ae>; Thu, 30 Oct 2014 09:48:28 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=prometheus) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XjlPA-003oe7-6Q>; Thu, 30 Oct 2014 09:48:28 +0100 Date: Thu, 30 Oct 2014 09:47:49 +0100 From: "O. Hartmann" To: =?ISO-8859-1?Q?L=E9vai_L=E1szl=F3?= Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so Message-ID: <20141030094749.101ca5f5@prometheus> In-Reply-To: <5451F865.4040004@gmail.com> References: <20141030092039.47802349@prometheus> <5451F865.4040004@gmail.com> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 87.138.105.249 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 08:48:31 -0000 On Thu, 30 Oct 2014 09:35:49 +0100 L=E9vai L=E1szl=F3 wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi, try this: >=20 > [1] kill all kerberos process > [2] to start KDC: /usr/local/libexec/kdc --detach > [3] /usr/local/sbin/kadmin -l > kadmin> list -l * > [...] >=20 > Principal: krbtgt/... > Principal expires: never > Password expires: never > Last password change: never > Max ticket life: unlimited > Max renewable life: unlimited > Kvno: 1 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2014-10-28 11:44:00 UTC > Modifier: unknown > Attributes: > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) > PK-INIT ACL: > Aliases: >=20 > Principal: kadmin/changepw@... > Principal expires: never > Password expires: never > Last password change: never > Max ticket life: 5 minutes > Max renewable life: 5 minutes > Kvno: 1 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2014-10-28 11:44:00 UTC > Modifier: unknown > Attributes: pwchange-service, requires-pre-auth, > disallow-proxiable, disallow-renewable, disallow-tgt-based, > disallow-postdated > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) > PK-INIT ACL: > Aliases: >=20 > Principal: kadmin/admin@... > Principal expires: never > Password expires: never > Last password change: never > Max ticket life: 1 hour > Max renewable life: 1 hour > Kvno: 1 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2014-10-28 11:44:00 UTC > Modifier: unknown > Attributes: requires-pre-auth > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) > PK-INIT ACL: > Aliases: >=20 > Principal: changepw/kerberos@... > Principal expires: never > Password expires: never > Last password change: never > Max ticket life: 1 hour > Max renewable life: 1 hour > Kvno: 1 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2014-10-28 11:44:01 UTC > Modifier: unknown > Attributes: pwchange-service, disallow-tgt-based > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) > PK-INIT ACL: > Aliases: >=20 > Principal: kadmin/hprop@... > Principal expires: never > Password expires: never > Last password change: never > Max ticket life: 1 hour > Max renewable life: 1 hour > Kvno: 1 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2014-10-28 11:44:01 UTC > Modifier: unknown > Attributes: requires-pre-auth, disallow-tgt-based > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) > PK-INIT ACL: > Aliases: >=20 > Principal: WELLKNOWN/ANONYMOUS@... > Principal expires: never > Password expires: never > Last password change: never > Max ticket life: 1 hour > Max renewable life: 1 hour > Kvno: 1 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2014-10-28 11:44:01 UTC > Modifier: unknown > Attributes: requires-pre-auth > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) > PK-INIT ACL: > Aliases: >=20 > Principal: default@... > Principal expires: never > Password expires: never > Last password change: never > Max ticket life: 1 day > Max renewable life: 1 week > Kvno: 1 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2014-10-28 11:44:01 UTC > Modifier: unknown > Attributes: disallow-all-tix > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) > PK-INIT ACL: > Aliases: > [...] Hello. This seems not to be the base system's Heimdal since you use /usr/local as prefix!=20 What is your database/storage backend for your Heimdal installation? Is it OpenLDAP? Tnak you very much in advance, Oliver >=20 >=20 > 2014-10-30 09:20 keltez=E9ssel, O. Hartmann =EDrta: > > On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 07:52:22 > > CET 2014 amd64) a running net/openldap24-sasl-server system is > > installed and running and is now about to be the database backend > > for Kerberos/Heimdal. net/openldap24-sasl-server is at=20 > > openldap-sasl-server-2.4.40. > >=20 > > The database storage scheme of the LDAP backend is MDB, as it is > > highly recommended by the vendors of OpenLDAP. > >=20 > > Searching for suitable manuals, I found some HowTos describing how > > to setup MIT Kerberos V with an OpenLDAP backend and I started > > following the instructions there. Despite the fact that > > http://www.h5l.org/manual is dead(!) and no usefull documentation > > or any kind of a hint where to find useful documentation for > > Heimdal can be found, many of the MIT Kerberos V setup instructions > > seem to be a dead end when using Heimdal on FreeBSD. Most of the > > links on that heimdal site ends up in ERROR 404! > >=20 > > Well, I think my objective isn't that exotic in an more advanced > > server environment and I think since FreeBSD is supposed to be used > > in advanced server environments this task should be well known - > > but little information/documentation is available. > >=20 > > Nevertheless, I use the base system's heimdal implementation and I > > run into a very frustrating error when trying to run "kamdin -l": > >=20 > > kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so:=20 > > Cannot open "/usr/lib/hdb_ldap.so" > >=20 > > The setup for the stanza [kdc] is > >=20 > > [...] [kdc] database =3D {=20 > > dbname=3Dldap:ou=3Dkerberos,dc=3Dserver,dc=3Dgdr=20 > > #hdb-ldap-structural-object =3D inetOrgPerson mkey_file =3D > > /var/heimdal/m-key acl_file =3D /var/heimdal/kadmind.acl } > >=20 > > instructions taken from > > http://www.padl.com/Research/Heimdal.html. > >=20 > > Well, it seems that FreeBSD ships with a crippled heimdal=20 > > implementation. Where is /usr/lib/hdb_ldap.so? > >=20 > > I'm toying around this issue for several days now and it gets more > > and more frustrating, also with the perspective of having no > > running samba 4.1 server for the windows domain. > >=20 > > Can someone give me a hint where to find suitable FreeBSD docs for > > a task like this? I guess since FreeBSD is considered a server OS > > more than a desktop/toy OS, there must be a solution for this. > > FreeBSD ships with heimdal in the base, but it seems this heimdal > > is broken. > >=20 > > P.S. Please CC me. _______________________________________________=20 > > freebsd-current@freebsd.org mailing list=20 > > http://lists.freebsd.org/mailman/listinfo/freebsd-current To > > unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > >=20 >=20 > - --=20 > Tisztelettel: > L=E9vai L=E1szl=F3 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) >=20 > iF4EAREIAAYFAlRR+GEACgkQtgVHtSvpUlo8hgD/dJbCxh7dBdm1tosZ8fdmMuCf > o6fBH3629SPMpGxxon0A/jK7hheRgcJYaIRTVUbmwKm3clbkVW4smcNCf8dPrTq5 > =3DvvoI > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Thu Oct 30 09:02:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D933BA5 for ; Thu, 30 Oct 2014 09:02:23 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF6CAB81 for ; Thu, 30 Oct 2014 09:02:22 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so3715076wgg.33 for ; Thu, 30 Oct 2014 02:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ODHNmn/HxD/O7Dnzgm7cLhD7yxWFuTns/g2sOonFPfA=; b=WhyUlm96SKRR3nG5lv3LDzR0so8a/LW488pagDyvz9qc/7g1FI58JQRFaYyQWmg7uq 6Rv0zxwlPtceABUWYvGOWHaIzsstydhMSCFZqh5BGmoCk7i6dEwAHoIi9g+cwTZbMeKY ago5F5vlNUFJTUG2BY8Roy0HxA9KkQtP43jUyQixFF+yXrMTdXEBN9RcTi5PO2q5mU/O Azm8h/kMduWKjUw4wJWMrNgxwmjVpIBJKnw7QwYVTgHLcXpLHxfuUXLp3v2GL8ILWqkW kjBafy/EXoQ7PmTD5uJ32PRr97oytN5ODVhkahDnE4uCvc2ydBVZE0PeGn1aW9UBF3gR ag/A== X-Received: by 10.180.8.34 with SMTP id o2mr8807698wia.23.1414659741161; Thu, 30 Oct 2014 02:02:21 -0700 (PDT) Received: from [192.168.50.14] (business-86-101-229-9.business.broadband.hu. [86.101.229.9]) by mx.google.com with ESMTPSA id u13sm6777440wiv.10.2014.10.30.02.02.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 02:02:20 -0700 (PDT) Message-ID: <5451FE9B.9000301@gmail.com> Date: Thu, 30 Oct 2014 10:02:19 +0100 From: =?ISO-8859-1?Q?L=E9vai_L=E1szl=F3?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.8.1 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so References: <20141030092039.47802349@prometheus> <5451F865.4040004@gmail.com> <20141030094749.101ca5f5@prometheus> In-Reply-To: <20141030094749.101ca5f5@prometheus> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 09:02:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 2014-10-30 09:47 keltezéssel, O. Hartmann írta: > On Thu, 30 Oct 2014 09:35:49 +0100 Lévai László > wrote: > > Hi, try this: > > [1] kill all kerberos process [2] to start KDC: > /usr/local/libexec/kdc --detach [3] /usr/local/sbin/kadmin -l > kadmin> list -l * [...] > > Principal: krbtgt/... Principal expires: never Password expires: > never Last password change: never Max ticket life: unlimited Max > renewable life: unlimited Kvno: 1 Mkvno: unknown Last successful > login: never Last failed login: never Failed login count: 0 Last > modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes: > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > > Principal: kadmin/changepw@... Principal expires: never Password > expires: never Last password change: never Max ticket life: 5 > minutes Max renewable life: 5 minutes Kvno: 1 Mkvno: unknown Last > successful login: never Last failed login: never Failed login > count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: unknown > Attributes: pwchange-service, requires-pre-auth, > disallow-proxiable, disallow-renewable, disallow-tgt-based, > disallow-postdated Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: > Aliases: > > Principal: kadmin/admin@... Principal expires: never Password > expires: never Last password change: never Max ticket life: 1 hour > Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful > login: never Last failed login: never Failed login count: 0 Last > modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes: > requires-pre-auth Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: > Aliases: > > Principal: changepw/kerberos@... Principal expires: never Password > expires: never Last password change: never Max ticket life: 1 hour > Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful > login: never Last failed login: never Failed login count: 0 Last > modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: > pwchange-service, disallow-tgt-based Keytypes: > aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > > Principal: kadmin/hprop@... Principal expires: never Password > expires: never Last password change: never Max ticket life: 1 hour > Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful > login: never Last failed login: never Failed login count: 0 Last > modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: > requires-pre-auth, disallow-tgt-based Keytypes: > aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > > Principal: WELLKNOWN/ANONYMOUS@... Principal expires: never > Password expires: never Last password change: never Max ticket > life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last > successful login: never Last failed login: never Failed login > count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: unknown > Attributes: requires-pre-auth Keytypes: > aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > > Principal: default@... Principal expires: never Password expires: > never Last password change: never Max ticket life: 1 day Max > renewable life: 1 week Kvno: 1 Mkvno: unknown Last successful > login: never Last failed login: never Failed login count: 0 Last > modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: > disallow-all-tix Keytypes: aes256-cts-hmac-sha1-96(pw-salt), > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: > Aliases: [...] > >> Hello. > >> This seems not to be the base system's Heimdal since you use >> /usr/local as prefix! > The base system's Heimdal with OpenLDAP backend not worked form me. So I installed the security/heimdal port and OpenLDAP24 server. root@lea:~ # /usr/local/libexec/slapd -VV @(#) $OpenLDAP: slapd 2.4.40 (Oct 17 2014 16:17:52) $ root@lea...:/usr/ports/net/openldap24-server/work/openldap-2.4.40/servers/slapd root@lea:~ # /usr/local/libexec/kdc --version kdc (Heimdal 1.5.2) Copyright 1995-2011 Kungliga Tekniska Högskolan Send bug-reports to heimdal-bugs@h5l.org root@lea:~ # /usr/local/libexec/kdc --builtin-hdb builtin hdb backends: ndbm:, keytab:, ldap:, ldapi:, sqlite: oterwise the system kdc: root@lea:~ # /usr/libexec/kdc --builtin-hdb builtin hdb backends: db:, mit-db:, ndbm:, keytab:, sqlite: >> What is your database/storage backend for your Heimdal >> installation? Is it OpenLDAP? > >> Tnak you very much in advance, > >> Oliver > > > > 2014-10-30 09:20 keltezéssel, O. Hartmann írta: >>>> On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 >>>> 07:52:22 CET 2014 amd64) a running net/openldap24-sasl-server >>>> system is installed and running and is now about to be the >>>> database backend for Kerberos/Heimdal. >>>> net/openldap24-sasl-server is at >>>> openldap-sasl-server-2.4.40. >>>> >>>> The database storage scheme of the LDAP backend is MDB, as it >>>> is highly recommended by the vendors of OpenLDAP. >>>> >>>> Searching for suitable manuals, I found some HowTos >>>> describing how to setup MIT Kerberos V with an OpenLDAP >>>> backend and I started following the instructions there. >>>> Despite the fact that http://www.h5l.org/manual is dead(!) >>>> and no usefull documentation or any kind of a hint where to >>>> find useful documentation for Heimdal can be found, many of >>>> the MIT Kerberos V setup instructions seem to be a dead end >>>> when using Heimdal on FreeBSD. Most of the links on that >>>> heimdal site ends up in ERROR 404! >>>> >>>> Well, I think my objective isn't that exotic in an more >>>> advanced server environment and I think since FreeBSD is >>>> supposed to be used in advanced server environments this task >>>> should be well known - but little information/documentation >>>> is available. >>>> >>>> Nevertheless, I use the base system's heimdal implementation >>>> and I run into a very frustrating error when trying to run >>>> "kamdin -l": >>>> >>>> kadmin: error trying to load dynamic module >>>> /usr/lib/hdb_ldap.so: Cannot open "/usr/lib/hdb_ldap.so" >>>> >>>> The setup for the stanza [kdc] is >>>> >>>> [...] [kdc] database = { >>>> dbname=ldap:ou=kerberos,dc=server,dc=gdr >>>> #hdb-ldap-structural-object = inetOrgPerson mkey_file = >>>> /var/heimdal/m-key acl_file = /var/heimdal/kadmind.acl } >>>> >>>> instructions taken from >>>> http://www.padl.com/Research/Heimdal.html. >>>> >>>> Well, it seems that FreeBSD ships with a crippled heimdal >>>> implementation. Where is /usr/lib/hdb_ldap.so? >>>> >>>> I'm toying around this issue for several days now and it gets >>>> more and more frustrating, also with the perspective of >>>> having no running samba 4.1 server for the windows domain. >>>> >>>> Can someone give me a hint where to find suitable FreeBSD >>>> docs for a task like this? I guess since FreeBSD is >>>> considered a server OS more than a desktop/toy OS, there must >>>> be a solution for this. FreeBSD ships with heimdal in the >>>> base, but it seems this heimdal is broken. >>>> >>>> P.S. Please CC me. >>>> _______________________________________________ >>>> 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" >>>> > >> _______________________________________________ >> 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" > - -- Tisztelettel: Lévai László -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRR/psACgkQtgVHtSvpUlqM0AD+Pwy6+M1eQVDoXJBqvr4tC5Ct UYAu1NlTZzk1EQ+scrgA+QHXWl3nEj0SN3EpIghIee10dCMUmrNbIm5ga8+CpeUk =GC3n -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 09:12:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEC01F34 for ; Thu, 30 Oct 2014 09:12:49 +0000 (UTC) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F695C81 for ; Thu, 30 Oct 2014 09:12:48 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so5163107wgg.4 for ; Thu, 30 Oct 2014 02:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W9Ao90YhLavy4iv5BzpFjXHEJDBHRJgFE1lj7gBC0IE=; b=XHBlcRBNUqO4jSgu1+tCpXdLOlx7b3kuNOt64vI/wCIl6SfZ9dpPgKR/p6cbdbdjEQ EZp7uzauooierXLhUSYff8LeGRiiApSdrYQDeyrmb9ihgJTnYKuQY2zUQeEXThB6f7lM Vod7NJFoQhaEd6H2P7c0dXvqxVaslpQk1Jb2gxZ8jnaMWwoXkUDA/2Rp4svyIsDXEnfi 1Ggc6Ro1rBtt7cA+7HHU0CocDuIcqtIMSoppJbyVFhD2fcCz3xTsTbaBN+163RefC/MM 2r8AaLVBij9XYRSBf/9hlG3rgBPCogN5igE1+VSJW2XMXFpOYuR4uN7l+xzDbqvMm2Ta 4j4Q== X-Gm-Message-State: ALoCoQnF2V3zo/T0M4r/8SpoasU8O2dy9XVKEHL6rCINxlCjgFOi+ZnxeOFObCkAOTbvyg914RuS X-Received: by 10.180.104.99 with SMTP id gd3mr18327643wib.10.1414660361523; Thu, 30 Oct 2014 02:12:41 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id gm9sm8294150wib.18.2014.10.30.02.12.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Oct 2014 02:12:40 -0700 (PDT) Message-ID: <54520177.5000008@multiplay.co.uk> Date: Thu, 30 Oct 2014 09:14:31 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "O'Connor, Daniel" Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> In-Reply-To: <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , Ed Maste , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 09:12:49 -0000 On 30/10/2014 08:24, O'Connor, Daniel wrote: > On 30 Oct 2014, at 13:23, Steven Hartland wrote: >> Making things harder to manage vs saving a little bit of space on the >> root partition really doesn't sound like a good idea; especially when >> with the ZFS install, which I would suggest is becoming the norm, the >> root partition doesn't suffer from space issues anyway. > Note that it’s not “a little bit” of space. > [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}' > 49312 > [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’ > 212464 > > i.e. the debug information is more than 4x larger than the code its for (!). That's still a trivial about of space in the grand scheme of things. > I agree managing the symbol files does become significantly more difficult in this case but the patch makes quite a substantial difference to the number of kernels you can keep in / (especially on older installs which have <1GB roots). The better solution is to not use a 1GB root. > Perhaps there could be a flag to disable it just for the kernel that could be put into /etc/make.conf? That way it’s set and forget if you are kernel juggling. Making it a none default option which can be used by those who have got limited space on their root. Regards Steve From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 09:47:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ACD171A for ; Thu, 30 Oct 2014 09:47:20 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91A27F8C for ; Thu, 30 Oct 2014 09:47:19 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XjmK5-002bxH-I3>; Thu, 30 Oct 2014 10:47:17 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=prometheus) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XjmK5-003xhX-DX>; Thu, 30 Oct 2014 10:47:17 +0100 Date: Thu, 30 Oct 2014 10:46:39 +0100 From: "O. Hartmann" To: =?ISO-8859-1?Q?L=E9vai_L=E1szl=F3?= Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so Message-ID: <20141030104639.49a11c14@prometheus> In-Reply-To: <5451FE9B.9000301@gmail.com> References: <20141030092039.47802349@prometheus> <5451F865.4040004@gmail.com> <20141030094749.101ca5f5@prometheus> <5451FE9B.9000301@gmail.com> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 87.138.105.249 Cc: freebsd-current@freebsd.org, =?ISO-8859-1?Q?Mika=EBl?= Urankar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 09:47:20 -0000 On Thu, 30 Oct 2014 10:02:19 +0100 L=E9vai L=E1szl=F3 wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 >=20 >=20 > 2014-10-30 09:47 keltez=E9ssel, O. Hartmann =EDrta: > > On Thu, 30 Oct 2014 09:35:49 +0100 L=E9vai L=E1szl=F3 > > wrote: > >=20 > > Hi, try this: > >=20 > > [1] kill all kerberos process [2] to start KDC: > > /usr/local/libexec/kdc --detach [3] /usr/local/sbin/kadmin -l=20 > > kadmin> list -l * [...] > >=20 > > Principal: krbtgt/... Principal expires: never Password expires: > > never Last password change: never Max ticket life: unlimited Max > > renewable life: unlimited Kvno: 1 Mkvno: unknown Last successful > > login: never Last failed login: never Failed login count: 0 Last > > modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes:=20 > > Keytypes: aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > >=20 > > Principal: kadmin/changepw@... Principal expires: never Password > > expires: never Last password change: never Max ticket life: 5 > > minutes Max renewable life: 5 minutes Kvno: 1 Mkvno: unknown Last > > successful login: never Last failed login: never Failed login > > count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: unknown=20 > > Attributes: pwchange-service, requires-pre-auth,=20 > > disallow-proxiable, disallow-renewable, disallow-tgt-based,=20 > > disallow-postdated Keytypes: aes256-cts-hmac-sha1-96(pw-salt),=20 > > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL:=20 > > Aliases: > >=20 > > Principal: kadmin/admin@... Principal expires: never Password > > expires: never Last password change: never Max ticket life: 1 hour=20 > > Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful > > login: never Last failed login: never Failed login count: 0 Last > > modified: 2014-10-28 11:44:00 UTC Modifier: unknown Attributes: > > requires-pre-auth Keytypes: aes256-cts-hmac-sha1-96(pw-salt),=20 > > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL:=20 > > Aliases: > >=20 > > Principal: changepw/kerberos@... Principal expires: never Password > > expires: never Last password change: never Max ticket life: 1 hour=20 > > Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful > > login: never Last failed login: never Failed login count: 0 Last > > modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: > > pwchange-service, disallow-tgt-based Keytypes: > > aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > >=20 > > Principal: kadmin/hprop@... Principal expires: never Password > > expires: never Last password change: never Max ticket life: 1 hour=20 > > Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last successful > > login: never Last failed login: never Failed login count: 0 Last > > modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: > > requires-pre-auth, disallow-tgt-based Keytypes: > > aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > >=20 > > Principal: WELLKNOWN/ANONYMOUS@... Principal expires: never=20 > > Password expires: never Last password change: never Max ticket > > life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last > > successful login: never Last failed login: never Failed login > > count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: unknown=20 > > Attributes: requires-pre-auth Keytypes: > > aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), > > arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: > >=20 > > Principal: default@... Principal expires: never Password expires: > > never Last password change: never Max ticket life: 1 day Max > > renewable life: 1 week Kvno: 1 Mkvno: unknown Last successful > > login: never Last failed login: never Failed login count: 0 Last > > modified: 2014-10-28 11:44:01 UTC Modifier: unknown Attributes: > > disallow-all-tix Keytypes: aes256-cts-hmac-sha1-96(pw-salt),=20 > > des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL:=20 > > Aliases: [...] > >=20 > >> Hello. > >=20 > >> This seems not to be the base system's Heimdal since you use > >> /usr/local as prefix! > >=20 >=20 > The base system's Heimdal with OpenLDAP backend not worked form me. So > I installed the security/heimdal port and OpenLDAP24 server. >=20 > root@lea:~ # /usr/local/libexec/slapd -VV > @(#) $OpenLDAP: slapd 2.4.40 (Oct 17 2014 16:17:52) $ > root@lea...:/usr/ports/net/openldap24-server/work/openldap-2.4.40/server= s/slapd >=20 >=20 > root@lea:~ # /usr/local/libexec/kdc --version > kdc (Heimdal 1.5.2) > Copyright 1995-2011 Kungliga Tekniska H=F6gskolan > Send bug-reports to heimdal-bugs@h5l.org >=20 >=20 > root@lea:~ # /usr/local/libexec/kdc --builtin-hdb > builtin hdb backends: ndbm:, keytab:, ldap:, ldapi:, sqlite: >=20 > oterwise the system kdc: > root@lea:~ # /usr/libexec/kdc --builtin-hdb > builtin hdb backends: db:, mit-db:, ndbm:, keytab:, sqlite: >=20 >=20 > >> What is your database/storage backend for your Heimdal > >> installation? Is it OpenLDAP? > >=20 > >> Tnak you very much in advance, > >=20 > >> Oliver > >=20 > >=20 > >=20 > > 2014-10-30 09:20 keltez=E9ssel, O. Hartmann =EDrta: > >>>> On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 > >>>> 07:52:22 CET 2014 amd64) a running net/openldap24-sasl-server > >>>> system is installed and running and is now about to be the > >>>> database backend for Kerberos/Heimdal. > >>>> net/openldap24-sasl-server is at=20 > >>>> openldap-sasl-server-2.4.40. > >>>>=20 > >>>> The database storage scheme of the LDAP backend is MDB, as it > >>>> is highly recommended by the vendors of OpenLDAP. > >>>>=20 > >>>> Searching for suitable manuals, I found some HowTos > >>>> describing how to setup MIT Kerberos V with an OpenLDAP > >>>> backend and I started following the instructions there. > >>>> Despite the fact that http://www.h5l.org/manual is dead(!) > >>>> and no usefull documentation or any kind of a hint where to > >>>> find useful documentation for Heimdal can be found, many of > >>>> the MIT Kerberos V setup instructions seem to be a dead end > >>>> when using Heimdal on FreeBSD. Most of the links on that > >>>> heimdal site ends up in ERROR 404! > >>>>=20 > >>>> Well, I think my objective isn't that exotic in an more > >>>> advanced server environment and I think since FreeBSD is > >>>> supposed to be used in advanced server environments this task > >>>> should be well known - but little information/documentation > >>>> is available. > >>>>=20 > >>>> Nevertheless, I use the base system's heimdal implementation > >>>> and I run into a very frustrating error when trying to run > >>>> "kamdin -l": > >>>>=20 > >>>> kadmin: error trying to load dynamic module > >>>> /usr/lib/hdb_ldap.so: Cannot open "/usr/lib/hdb_ldap.so" > >>>>=20 > >>>> The setup for the stanza [kdc] is > >>>>=20 > >>>> [...] [kdc] database =3D {=20 > >>>> dbname=3Dldap:ou=3Dkerberos,dc=3Dserver,dc=3Dgdr=20 > >>>> #hdb-ldap-structural-object =3D inetOrgPerson mkey_file =3D=20 > >>>> /var/heimdal/m-key acl_file =3D /var/heimdal/kadmind.acl } > >>>>=20 > >>>> instructions taken from=20 > >>>> http://www.padl.com/Research/Heimdal.html. > >>>>=20 > >>>> Well, it seems that FreeBSD ships with a crippled heimdal=20 > >>>> implementation. Where is /usr/lib/hdb_ldap.so? > >>>>=20 > >>>> I'm toying around this issue for several days now and it gets > >>>> more and more frustrating, also with the perspective of > >>>> having no running samba 4.1 server for the windows domain. > >>>>=20 > >>>> Can someone give me a hint where to find suitable FreeBSD > >>>> docs for a task like this? I guess since FreeBSD is > >>>> considered a server OS more than a desktop/toy OS, there must > >>>> be a solution for this. FreeBSD ships with heimdal in the > >>>> base, but it seems this heimdal is broken. > >>>>=20 > >>>> P.S. Please CC me. > >>>> _______________________________________________=20 > >>>> freebsd-current@freebsd.org mailing list=20 > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current To=20 > >>>> unsubscribe, send any mail to=20 > >>>> "freebsd-current-unsubscribe@freebsd.org" [...] Yes, the base system is only a crippled version and I guess it is due to the fact that OpenLDAP is also NOT part of the base and the libraries/headers necessary to built the LDAP support in the base systems's heimdal are missing. The lack of documentation is simply a mess. I excluded by intention the port security/heimdal to proof whether FreeBSD is capable of handling a common and very usual server task like the mentioned scenario. I overcame this problem by installing the port security/heimdal, but now I run into the next problem which is highly intransparent: kadmin> init MY.REALM kadmin: hdb_open: ldap_sasl_bind_s: Confidentiality required My LDAP server expects TLS authentication. I would expect a LDAP aware client to llok for the proper informations at /usr/local/openldap/ldap.conf. Obviously, Heimdal doesn't. Is there anything I've missed? Since I can not find any suitable documentation (www.h5l.org/manual is dead!), I'm floating dead in the water. I found several HowTo manuals, but the most sophistaceted referes to MIT Kerberos 5 as mentioned earlier and can be found here: http://www.math.ucla.edu/~jimc/documents/ldap/kerberos-ldap-1202.html But this manual seems to be unapplicable to Heimdal. But without docs it is hard to impossible (in a reasonable timeframe for productive use) to figure that out. Anyway, if there is some hint, I would appreciate it. Thanks in advance, Oliver From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 10:03:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1F91CAC for ; Thu, 30 Oct 2014 10:03:41 +0000 (UTC) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6054B1E4 for ; Thu, 30 Oct 2014 10:03:40 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so5263610wgg.4 for ; Thu, 30 Oct 2014 03:03:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R6O/TFTufcdDKlkICQ9eF5jab+2hbsFjsmTH+r6VUcU=; b=JE0JzVhcbSnrMMxhqVWPTZUnZfNh2QLqSQQWZBIbD60RqvcmtIsYDAhpmorRo/UJdp Bh4Dfr9Jj03MQ2clKzytc76JsOxd4/mTFh5J3xTVnh+Z2ft47LDYIG05oxh0pmJJZ2+a GjPpT4rlspWMXcgsGd2NZWWJ/1pqFm7AQIaG+e4jksPCSIt4o1CO233dOXlwluMotBd8 GyjxgXxvAl0jQ8wYa1bygwzb+wCE2G6ssgAIdSn3EfyS/HjNv2bjaqD2p3P5aDAtSRj+ 4yYhgcys5iIxreLb1EyO0UK7eAs9mTsqDKm3XP4Syad76Z+be5IjMlSPTeEK6m3jFmRj HvDA== X-Gm-Message-State: ALoCoQlxt2XupxpALhc+eIPepSDVJ/FZ22CLE8rQUUIkyp4Im1/y6n9UhM3LIiA4MNay8Ukm0WTL X-Received: by 10.180.99.1 with SMTP id em1mr8170837wib.29.1414663418846; Thu, 30 Oct 2014 03:03:38 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id l10sm21630332wif.20.2014.10.30.03.03.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Oct 2014 03:03:38 -0700 (PDT) Message-ID: <54520D69.8080404@multiplay.co.uk> Date: Thu, 30 Oct 2014 10:05:29 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "O'Connor, Daniel" Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> In-Reply-To: <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , Ed Maste , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 10:03:42 -0000 On 30/10/2014 09:47, O'Connor, Daniel wrote: > On 30 Oct 2014, at 19:44, Steven Hartland wrote: >> On 30/10/2014 08:24, O'Connor, Daniel wrote: >>> On 30 Oct 2014, at 13:23, Steven Hartland wrote: >>>> Making things harder to manage vs saving a little bit of space on the >>>> root partition really doesn't sound like a good idea; especially when >>>> with the ZFS install, which I would suggest is becoming the norm, the >>>> root partition doesn't suffer from space issues anyway. >>> Note that it’s not “a little bit” of space. >>> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}' >>> 49312 >>> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’ >>> 212464 >>> >>> i.e. the debug information is more than 4x larger than the code its for (!). >> That's still a trivial about of space in the grand scheme of things. > Yes. > >>> I agree managing the symbol files does become significantly more difficult in this case but the patch makes quite a substantial difference to the number of kernels you can keep in / (especially on older installs which have <1GB roots). >> The better solution is to not use a 1GB root. > Unfortunately once you install it’s impossible to expand. There are quite a few older systems that have been upgraded with relatively small root partitions. I would suggest we treat those as legacy systems and look to improve the layout moving forward, instead of applying changes which make it more difficult to maintain for everyone. >>> Perhaps there could be a flag to disable it just for the kernel that could be put into /etc/make.conf? That way it’s set and forget if you are kernel juggling. >> Making it a none default option which can be used by those who have got >> limited space on their root. > Perhaps, but the defaults have been for quite small root partitions for a long time so I expect there are a lot of systems with a small root. These systems are working fine though are they not? They may not be able to have loads of kernels installed but if you want to do that then its worth the pain of the reinstall instead of penalizing everyone. Regards Steve From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 10:33:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD68E5A4 for ; Thu, 30 Oct 2014 10:33:22 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AD746F1 for ; Thu, 30 Oct 2014 10:33:22 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so3852991wgh.24 for ; Thu, 30 Oct 2014 03:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DA6hrPzPBG9XnMMdsqDbDS8Rv8D+mytrHB2jQj7VcVM=; b=xSfBz5774BpOx3PhHSDlyiL/tun2oC/ulbwNEoQhl819D9cSWFDbRgNAjhav6QUbES LYrnbLjt7KlGdF7A9YunDYMfrFuX/UEfA4cGky4jx/gAfAE7Fhlb6brgCMyvn+ff5sM1 Q0ejWphWiWOQkWkSUFy8xmS5sk42LTawfX3XqcC/eqBXxY3fAT2fgjGdc3VBlcRSFO0S r7/EPnB2niywREXFALz/NbFwk3n+X8lhK7DTVcGFQ6nz4loZ5vnO3eGNuZzb7lEGDZK7 fDBoN/OjwQzJ3XQWgcTmWeGNxgFz0Aiwx87S5Vykpy+DghSMOWHyMUB9Iw36qiTofuIB kxHw== X-Received: by 10.180.187.44 with SMTP id fp12mr19399780wic.72.1414665200567; Thu, 30 Oct 2014 03:33:20 -0700 (PDT) Received: from [192.168.50.14] (business-86-101-229-9.business.broadband.hu. [86.101.229.9]) by mx.google.com with ESMTPSA id n4sm11682229wiz.17.2014.10.30.03.33.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 03:33:19 -0700 (PDT) Message-ID: <545213EF.2050904@gmail.com> Date: Thu, 30 Oct 2014 11:33:19 +0100 From: =?ISO-8859-1?Q?L=E9vai_L=E1szl=F3?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.8.1 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so References: <20141030092039.47802349@prometheus> <5451F865.4040004@gmail.com> <20141030094749.101ca5f5@prometheus> <5451FE9B.9000301@gmail.com> <20141030104639.49a11c14@prometheus> In-Reply-To: <20141030104639.49a11c14@prometheus> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, =?ISO-8859-1?Q?Mika=EBl_Urankar?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 10:33:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I work two weeks ago this Heimdal + OpenLDAP combo. Now Heimdal can connect to OpenLDAP backend. I turned off TLS encryption and everyone can write the LDAP tree (for testing purpose). After that init MY.REALM is working. BUT. For some reasons ssh login with GSSAPIAuth not working yet. I'm floating dead in the water too :-) 2014-10-30 10:46 keltezéssel, O. Hartmann írta: > On Thu, 30 Oct 2014 10:02:19 +0100 Lévai László > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> >> >> 2014-10-30 09:47 keltezéssel, O. Hartmann írta: >>> On Thu, 30 Oct 2014 09:35:49 +0100 Lévai László >>> wrote: >>> >>> Hi, try this: >>> >>> [1] kill all kerberos process [2] to start KDC: >>> /usr/local/libexec/kdc --detach [3] /usr/local/sbin/kadmin -l >>> kadmin> list -l * [...] >>> >>> Principal: krbtgt/... Principal expires: never Password >>> expires: never Last password change: never Max ticket life: >>> unlimited Max renewable life: unlimited Kvno: 1 Mkvno: unknown >>> Last successful login: never Last failed login: never Failed >>> login count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: >>> unknown Attributes: Keytypes: aes256-cts-hmac-sha1-96(pw-salt), >>> des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: >>> Aliases: >>> >>> Principal: kadmin/changepw@... Principal expires: never >>> Password expires: never Last password change: never Max ticket >>> life: 5 minutes Max renewable life: 5 minutes Kvno: 1 Mkvno: >>> unknown Last successful login: never Last failed login: never >>> Failed login count: 0 Last modified: 2014-10-28 11:44:00 UTC >>> Modifier: unknown Attributes: pwchange-service, >>> requires-pre-auth, disallow-proxiable, disallow-renewable, >>> disallow-tgt-based, disallow-postdated Keytypes: >>> aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), >>> arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: >>> >>> Principal: kadmin/admin@... Principal expires: never Password >>> expires: never Last password change: never Max ticket life: 1 >>> hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last >>> successful login: never Last failed login: never Failed login >>> count: 0 Last modified: 2014-10-28 11:44:00 UTC Modifier: >>> unknown Attributes: requires-pre-auth Keytypes: >>> aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), >>> arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: >>> >>> Principal: changepw/kerberos@... Principal expires: never >>> Password expires: never Last password change: never Max ticket >>> life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown >>> Last successful login: never Last failed login: never Failed >>> login count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: >>> unknown Attributes: pwchange-service, disallow-tgt-based >>> Keytypes: aes256-cts-hmac-sha1-96(pw-salt), >>> des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: >>> Aliases: >>> >>> Principal: kadmin/hprop@... Principal expires: never Password >>> expires: never Last password change: never Max ticket life: 1 >>> hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown Last >>> successful login: never Last failed login: never Failed login >>> count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: >>> unknown Attributes: requires-pre-auth, disallow-tgt-based >>> Keytypes: aes256-cts-hmac-sha1-96(pw-salt), >>> des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt) PK-INIT ACL: >>> Aliases: >>> >>> Principal: WELLKNOWN/ANONYMOUS@... Principal expires: never >>> Password expires: never Last password change: never Max ticket >>> life: 1 hour Max renewable life: 1 hour Kvno: 1 Mkvno: unknown >>> Last successful login: never Last failed login: never Failed >>> login count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: >>> unknown Attributes: requires-pre-auth Keytypes: >>> aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), >>> arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: >>> >>> Principal: default@... Principal expires: never Password >>> expires: never Last password change: never Max ticket life: 1 >>> day Max renewable life: 1 week Kvno: 1 Mkvno: unknown Last >>> successful login: never Last failed login: never Failed login >>> count: 0 Last modified: 2014-10-28 11:44:01 UTC Modifier: >>> unknown Attributes: disallow-all-tix Keytypes: >>> aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), >>> arcfour-hmac-md5(pw-salt) PK-INIT ACL: Aliases: [...] >>> >>>> Hello. >>> >>>> This seems not to be the base system's Heimdal since you use >>>> /usr/local as prefix! >>> >> >> The base system's Heimdal with OpenLDAP backend not worked form >> me. So I installed the security/heimdal port and OpenLDAP24 >> server. >> >> root@lea:~ # /usr/local/libexec/slapd -VV @(#) $OpenLDAP: slapd >> 2.4.40 (Oct 17 2014 16:17:52) $ >> root@lea...:/usr/ports/net/openldap24-server/work/openldap-2.4.40/servers/slapd >> >> >> >> root@lea:~ # /usr/local/libexec/kdc --version >> kdc (Heimdal 1.5.2) Copyright 1995-2011 Kungliga Tekniska >> Högskolan Send bug-reports to heimdal-bugs@h5l.org >> >> >> root@lea:~ # /usr/local/libexec/kdc --builtin-hdb builtin hdb >> backends: ndbm:, keytab:, ldap:, ldapi:, sqlite: >> >> oterwise the system kdc: root@lea:~ # /usr/libexec/kdc >> --builtin-hdb builtin hdb backends: db:, mit-db:, ndbm:, keytab:, >> sqlite: >> >> >>>> What is your database/storage backend for your Heimdal >>>> installation? Is it OpenLDAP? >>> >>>> Tnak you very much in advance, >>> >>>> Oliver >>> >>> >>> >>> 2014-10-30 09:20 keltezéssel, O. Hartmann írta: >>>>>> On CURRENT (FreeBSD 11.0-CURRENT #0 r273810: Wed Oct 29 >>>>>> 07:52:22 CET 2014 amd64) a running >>>>>> net/openldap24-sasl-server system is installed and >>>>>> running and is now about to be the database backend for >>>>>> Kerberos/Heimdal. net/openldap24-sasl-server is at >>>>>> openldap-sasl-server-2.4.40. >>>>>> >>>>>> The database storage scheme of the LDAP backend is MDB, >>>>>> as it is highly recommended by the vendors of OpenLDAP. >>>>>> >>>>>> Searching for suitable manuals, I found some HowTos >>>>>> describing how to setup MIT Kerberos V with an OpenLDAP >>>>>> backend and I started following the instructions there. >>>>>> Despite the fact that http://www.h5l.org/manual is >>>>>> dead(!) and no usefull documentation or any kind of a >>>>>> hint where to find useful documentation for Heimdal can >>>>>> be found, many of the MIT Kerberos V setup instructions >>>>>> seem to be a dead end when using Heimdal on FreeBSD. Most >>>>>> of the links on that heimdal site ends up in ERROR 404! >>>>>> >>>>>> Well, I think my objective isn't that exotic in an more >>>>>> advanced server environment and I think since FreeBSD is >>>>>> supposed to be used in advanced server environments this >>>>>> task should be well known - but little >>>>>> information/documentation is available. >>>>>> >>>>>> Nevertheless, I use the base system's heimdal >>>>>> implementation and I run into a very frustrating error >>>>>> when trying to run "kamdin -l": >>>>>> >>>>>> kadmin: error trying to load dynamic module >>>>>> /usr/lib/hdb_ldap.so: Cannot open "/usr/lib/hdb_ldap.so" >>>>>> >>>>>> The setup for the stanza [kdc] is >>>>>> >>>>>> [...] [kdc] database = { >>>>>> dbname=ldap:ou=kerberos,dc=server,dc=gdr >>>>>> #hdb-ldap-structural-object = inetOrgPerson mkey_file >>>>>> = /var/heimdal/m-key acl_file = /var/heimdal/kadmind.acl >>>>>> } >>>>>> >>>>>> instructions taken from >>>>>> http://www.padl.com/Research/Heimdal.html. >>>>>> >>>>>> Well, it seems that FreeBSD ships with a crippled heimdal >>>>>> implementation. Where is /usr/lib/hdb_ldap.so? >>>>>> >>>>>> I'm toying around this issue for several days now and it >>>>>> gets more and more frustrating, also with the perspective >>>>>> of having no running samba 4.1 server for the windows >>>>>> domain. >>>>>> >>>>>> Can someone give me a hint where to find suitable >>>>>> FreeBSD docs for a task like this? I guess since FreeBSD >>>>>> is considered a server OS more than a desktop/toy OS, >>>>>> there must be a solution for this. FreeBSD ships with >>>>>> heimdal in the base, but it seems this heimdal is >>>>>> broken. >>>>>> >>>>>> P.S. Please CC me. >>>>>> _______________________________________________ >>>>>> 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" > [...] > > Yes, the base system is only a crippled version and I guess it is > due to the fact that OpenLDAP is also NOT part of the base and the > libraries/headers necessary to built the LDAP support in the base > systems's heimdal are missing. > > The lack of documentation is simply a mess. I excluded by intention > the port security/heimdal to proof whether FreeBSD is capable of > handling a common and very usual server task like the mentioned > scenario. > > I overcame this problem by installing the port security/heimdal, > but now I run into the next problem which is highly intransparent: > > kadmin> init MY.REALM kadmin: hdb_open: ldap_sasl_bind_s: > Confidentiality required > > My LDAP server expects TLS authentication. I would expect a LDAP > aware client to llok for the proper informations at > /usr/local/openldap/ldap.conf. Obviously, Heimdal doesn't. Is > there anything I've missed? Since I can not find any suitable > documentation (www.h5l.org/manual is dead!), I'm floating dead in > the water. > > I found several HowTo manuals, but the most sophistaceted referes > to MIT Kerberos 5 as mentioned earlier and can be found here: > > http://www.math.ucla.edu/~jimc/documents/ldap/kerberos-ldap-1202.html > > But this manual seems to be unapplicable to Heimdal. But without > docs it is hard to impossible (in a reasonable timeframe for > productive use) to figure that out. > > Anyway, if there is some hint, I would appreciate it. > > Thanks in advance, Oliver > - -- Tisztelettel: Lévai László -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRSE+4ACgkQtgVHtSvpUlrgGgD/Rpalss9gc6ZfM/6x09fkhLLY 1jaCYirnMxgrWjmMS0kA/RFYN4q7MMMmYrzHDbKtIcKgODJiV5h5q6j4UMUdSysL =G/Nn -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 08:25:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BCA4FEC; Thu, 30 Oct 2014 08:25:29 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A52F7F4; Thu, 30 Oct 2014 08:25:28 +0000 (UTC) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9U8PPd5008868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 04:25:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9U8PPd5008868 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1414657526; bh=ua79zxQnOFPNkW9jPpQuhFJfL7o=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EMZ3jJuhlhV/uU0zEyvy0fzHrbwodgdx7OIUOmBU9TJHL84FuAFDovsieIrj+F3Uw DN4Bj4Sq++MAd22NCInuF97Slg9sPGsPNnAMrbtcZZk/owuJo9DYjQgfEq0hz0LFAU hGN2ipKON/w5KsairlWPIjHcdzFpr3L7TcMAUO8Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9U8PPd5008868 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 30 Oct 2014 04:24:22 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9U8PHtv032753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 04:25:18 -0400 Received: from mx34a.corp.emc.com ([169.254.1.112]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 30 Oct 2014 04:25:17 -0400 From: "O'Connor, Daniel" To: Steven Hartland Date: Thu, 30 Oct 2014 04:24:46 -0400 Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Thread-Topic: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Thread-Index: Ac/0GwhySaxuLMgFQuWzOvY6BbI6Wg== Message-ID: <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> In-Reply-To: <5451A843.90805@multiplay.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Thu, 30 Oct 2014 11:18:02 +0000 Cc: FreeBSD Current , Ed Maste , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 08:25:29 -0000 On 30 Oct 2014, at 13:23, Steven Hartland wrote: > Making things harder to manage vs saving a little bit of space on the=20 > root partition really doesn't sound like a good idea; especially when=20 > with the ZFS install, which I would suggest is becoming the norm, the=20 > root partition doesn't suffer from space issues anyway. Note that it=92s not =93a little bit=94 of space. [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i +=3D $5} END {print = $5}' 49312 [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i +=3D $5} END {print $= 5}=92 212464 i.e. the debug information is more than 4x larger than the code its for (!)= . I agree managing the symbol files does become significantly more difficult = in this case but the patch makes quite a substantial difference to the numb= er of kernels you can keep in / (especially on older installs which have <1= GB roots). Perhaps there could be a flag to disable it just for the kernel that could = be put into /etc/make.conf? That way it=92s set and forget if you are kerne= l juggling. Regards, Daniel O=92Connor Senior Software Engineer Isilon Platforms Team From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 09:48:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C8E2933; Thu, 30 Oct 2014 09:48:56 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd51.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1851FBB; Thu, 30 Oct 2014 09:48:55 +0000 (UTC) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9U9mkRk010984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 05:48:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s9U9mkRk010984 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1414662527; bh=iubPeSm2mAqYG5bDG4fxdCAel44=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KdxN8LDVVbw30QbiSW0V0rjkSQGUoqREmAhSXbp94SHMkGbEAPPkX7fyY4tNf5LVf 3kjcDvVMTX/HGwPOh02/FLCj1N0z51FRMHFPFU5BoVQ5dKSzisK5CY8P7X/0YHUHv6 nRAk+62jFWYajCpBJS09klqEBlRkzczz96U4zn/g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s9U9mkRk010984 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 30 Oct 2014 05:47:51 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9U9mWIk017636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 05:48:33 -0400 Received: from mx34a.corp.emc.com ([169.254.1.112]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Thu, 30 Oct 2014 05:48:32 -0400 From: "O'Connor, Daniel" To: Steven Hartland Date: Thu, 30 Oct 2014 05:47:58 -0400 Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Thread-Topic: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Thread-Index: Ac/0JqozkaFV+nbzSpqwoZbVolbxug== Message-ID: <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> In-Reply-To: <54520177.5000008@multiplay.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Thu, 30 Oct 2014 11:18:17 +0000 Cc: FreeBSD Current , Ed Maste , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 09:48:56 -0000 On 30 Oct 2014, at 19:44, Steven Hartland wrote: > On 30/10/2014 08:24, O'Connor, Daniel wrote: >> On 30 Oct 2014, at 13:23, Steven Hartland wrot= e: >>> Making things harder to manage vs saving a little bit of space on the >>> root partition really doesn't sound like a good idea; especially when >>> with the ZFS install, which I would suggest is becoming the norm, the >>> root partition doesn't suffer from space issues anyway. >> Note that it=92s not =93a little bit=94 of space. >> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i +=3D $5} END {pri= nt $5}' >> 49312 >> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i +=3D $5} END {prin= t $5}=92 >> 212464 >>=20 >> i.e. the debug information is more than 4x larger than the code its for = (!). > That's still a trivial about of space in the grand scheme of things. Yes. >> I agree managing the symbol files does become significantly more difficu= lt in this case but the patch makes quite a substantial difference to the n= umber of kernels you can keep in / (especially on older installs which have= <1GB roots). > The better solution is to not use a 1GB root. Unfortunately once you install it=92s impossible to expand. There are quite= a few older systems that have been upgraded with relatively small root par= titions. >> Perhaps there could be a flag to disable it just for the kernel that cou= ld be put into /etc/make.conf? That way it=92s set and forget if you are ke= rnel juggling. > Making it a none default option which can be used by those who have got=20 > limited space on their root. Perhaps, but the defaults have been for quite small root partitions for a l= ong time so I expect there are a lot of systems with a small root. Regards, Daniel O=92Connor Senior Software Engineer Isilon Platforms Team From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 12:10:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F72C743; Thu, 30 Oct 2014 12:10:21 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FD0CD4; Thu, 30 Oct 2014 12:10:19 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A363A25D37C7; Thu, 30 Oct 2014 12:10:09 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 671F6C7709B; Thu, 30 Oct 2014 12:10:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 5rUgvv2gS7jd; Thu, 30 Oct 2014 12:10:05 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DF247C77057; Thu, 30 Oct 2014 12:10:04 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ From: "Bjoern A. Zeeb" In-Reply-To: <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> Date: Thu, 30 Oct 2014 12:10:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> To: FreeBSD Current X-Mailer: Apple Mail (2.1878.6) Cc: Ed Maste X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 12:10:21 -0000 On 30 Oct 2014, at 09:47 , O'Connor, Daniel = wrote: > On 30 Oct 2014, at 19:44, Steven Hartland = wrote: >> On 30/10/2014 08:24, O'Connor, Daniel wrote: >>> On 30 Oct 2014, at 13:23, Steven Hartland = wrote: >>>> Making things harder to manage vs saving a little bit of space on = the >>>> root partition really doesn't sound like a good idea; especially = when >>>> with the ZFS install, which I would suggest is becoming the norm, = the >>>> root partition doesn't suffer from space issues anyway. >>> Note that it=92s not =93a little bit=94 of space. >>> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i +=3D $5} END = {print $5}' >>> 49312 >>> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i +=3D $5} END = {print $5}=92 >>> 212464 >>>=20 >>> i.e. the debug information is more than 4x larger than the code its = for (!). >> That's still a trivial about of space in the grand scheme of things. >=20 > Yes. No it is not a trivial amount of space; it=92s about 20ish% of the = installation of the base system. I guess I am one source for the request to get them out of = /boot/kernel/*.symbols into a spearate tarball and not install them by = default for users. The reasons for me are indeed manyfold: (a) symbol files are for developers. Developers are clever people, = often with custom systems, they know how to deal with them as they = already do whatever they want anyway in 7 different ways. (b) A user should usually never have to bother with them, so why have = them installed in first place? They go onto (release) the media so that = developers have access to them, or that users, if guided by a developer, = can install them to debug a problem. Moving them to a separate = directory and into a different tarball makes that a lot easier. (c) We have people deploying gazillions of FreeBSD systems from default = media, this stuff does add up; 10TB sounds small unless you have to = back it up regularly, need disaster copies, or you need to minimise = recovery or migration time, when every s is worth a few $$s. (d) A couple of times a year I do spare VM image backup and recovery = including migration. Moving the data back and forth can only happen in = a very limited time frame, so I try to keep these VM images as small as = possible. rm -f /boot/kernel/*.symbol after install is really not = keeping the sparseness as no one really supports TRIM on the VM images. = Thus I=92d just have lost 200MB * n VMs that I need to move around over = 200ms RTT. There are cruel workarounds; I know how to apply them as I = am a developer, but if I do this stuff, there must be 1000s of users = doing that, and they don=92t. (e) People still have / (boot) filesystems in the 256M-1G space for the = foreseeable future. How do you ever cramp two kernels in there during = an update for a machine that you will never ever see again because it=92s = in Antarctica on a 9600 baud connection? (f) =85 Yes I can understand that on these 40TB ZFS machines, no one gives a = damn about 200MB, but unfortunately not the entire world runs on these = kinds of machines. We have plenty of users on 10 year old hardware = still running a FreeBSD installation and it works perfectly fine and = does the job (until the HW dies;-). The entire cp -pR kernel kernel.good solution is nothing I=92d expect a = user to ever do. But I am aware that=92s a =93developer standard=94. = Maybe we just need to improve the situation for ourselves rather than = pessimising 98% of users out there. I personally do not mind where the symbol files will end up as long as = they are in their own directory and not onto systems by default with = releases unless someone ticks a box. Whether that is = /boot/kernel/symbols/* or /usr/lib/***, I couldn=92t care less, apart = from the fact that /boot remains on a space constrained file system for = a lot of legacy system that symbol files have filled up more than once = for me in the past. So maybe the real solution is indeed for developers to think how to = manage kernels and related files and settings in the future? =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 13:08:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D85E65E for ; Thu, 30 Oct 2014 13:08:02 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AE6B92E for ; Thu, 30 Oct 2014 13:08:02 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id y20so2780844ier.11 for ; Thu, 30 Oct 2014 06:08:01 -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:from:date:message-id :subject:to:cc:content-type; bh=wgfrWyGyKfPlju64HISTTbXLamS+XnDiltN5OLLwrqM=; b=KETMJ9rNfCdDDQPLO9vusBxW9jVNWXvFYz8s0ZMg0ZSFqZ2aiR2oA4S/uK7JtYlSjV zgCOeuQ+5EnW51+DBoFEpPknMxxa3qW3wNuZYNJkoaLIJrfZAFqCOSvA6H+efF2E2GTx 5R1hJYowEGKdpxMa2Bn9fTwK0J4tpWLXj/sKZ3c8aoZapGF+oRmz5fkU2Ing+BoPt2T2 uf7/SghCCvHtV/dreJqeFqDP7K15CXkddW6zE+Ue4Ix8+hHEnLS4Cn34gQDZkdmF4FTk RfsCdaMTjLRebVm1Z72siV/eSlekXAUiN0CZR/bsWmYyFNqaToQoUubdqHIgMiADPEmV S/uw== X-Received: by 10.51.17.104 with SMTP id gd8mr20221015igd.21.1414674481764; Thu, 30 Oct 2014 06:08:01 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Thu, 30 Oct 2014 06:07:40 -0700 (PDT) In-Reply-To: <20141030023224.GA42236@troutmask.apl.washington.edu> References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> From: Ed Maste Date: Thu, 30 Oct 2014 09:07:40 -0400 X-Google-Sender-Auth: OmfBTOdBjJxc_XkLDA2McAZo6WQ Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 13:08:02 -0000 On 29 October 2014 22:32, Steve Kargl wrote: > On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote: >> On 29 October 2014 12:49, Steven Hartland wrote: >> > Hmm not sure I like this idea as it would make it more difficult to make a >> > copy / backup a kernel. >> > >> > ATM when I want to copy a kernel for debugging its a one liner, splitting >> > debug symbols off to /usr/lib would prevent this. >> >> To retain the current behaviour you can set DEBUGDIR= (i.e., empty), >> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}. > > No, you can't. > > su root > cp -pR /boot/kernel /boot/good > > Where does DEBUGDIR enter the picture? In your kernel build configuration (src.conf or similar ways). From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 13:10:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9630D7E6 for ; Thu, 30 Oct 2014 13:10:41 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58A80952 for ; Thu, 30 Oct 2014 13:10:41 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id hl2so3248026igb.10 for ; Thu, 30 Oct 2014 06:10:40 -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:from:date:message-id :subject:to:cc:content-type; bh=b2z5ALMFwDF274rch8qVyVFZii6PkqAgvs8amup2pFg=; b=taPYqkpSMVQU5yEIea3kxjkphnTjcxEFs7dMF3PQqwZhT6jmjmLwCu5oIKK6Q9Ja8D dHBWjRRAS3UGwpoeNV8crxLSr0cLqxOCoCvvqf+3MND2SE0JwOGNod+xdPG1sEM6nkvY fP9/gqGc7pW3DtsplCt5IufeL0wX02sSS6cWBqokQtvnv8gKfINsBYXeuHdeFzjVU/Vy deiy3APTLaVhe9AxC3wHjKhHWMwXLD9e1soQm1VbYMpZ9EecjMlvFFP/noQnwWfapXtd bxZxlnx7/tgCjTBoEYJLoKLSMLjeOj160VLPIcYbxURNw4BAJjeVyeaHxxJz8Tg2F+t1 TwEw== X-Received: by 10.107.13.137 with SMTP id 131mr19824491ion.2.1414674640627; Thu, 30 Oct 2014 06:10:40 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Thu, 30 Oct 2014 06:10:19 -0700 (PDT) In-Reply-To: References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> From: Ed Maste Date: Thu, 30 Oct 2014 09:10:19 -0400 X-Google-Sender-Auth: qg8CZheasdh8bkI-PKYXWYp8uPQ Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 13:10:41 -0000 On 30 October 2014 09:07, Ed Maste wrote: > On 29 October 2014 22:32, Steve Kargl wrote: >> On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote: >>> On 29 October 2014 12:49, Steven Hartland wrote: >>> > Hmm not sure I like this idea as it would make it more difficult to make a >>> > copy / backup a kernel. >>> > >>> > ATM when I want to copy a kernel for debugging its a one liner, splitting >>> > debug symbols off to /usr/lib would prevent this. >>> >>> To retain the current behaviour you can set DEBUGDIR= (i.e., empty), >>> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}. >> >> No, you can't. >> >> su root >> cp -pR /boot/kernel /boot/good >> >> Where does DEBUGDIR enter the picture? > > In your kernel build configuration (src.conf or similar ways). Oops, that should be "build / install configuration (src.conf or similar)." That is, if you set DEBUGDIR= then the debug data will be installed in the same directory as the kernel / binaries / libraries, and everything will work as it does today. From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 13:19:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DC6E9D9 for ; Thu, 30 Oct 2014 13:19:40 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA0DEA2B for ; Thu, 30 Oct 2014 13:19:39 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so7374948wiv.14 for ; Thu, 30 Oct 2014 06:19:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=p6E2LeFaNfdRlpItdHm5j6WaZs6phu/YiODw360rM4U=; b=MpbE2eKsQBPxDEY8xFSrCdvXQ2qsVACjCqMMDM9B4qBs2SvO6aVGmVCTpp/saLQ9HT MZlTrGC6SV9yZ3kI6k3zALBvn+o8pnz8d542ITk5O1DvzAsUg/ApXYpUXJQJQ3Xfdm+w WM/7Kt/vC3IY6hnjUTOxwOPrkd3pllHqgPW62emwVY7s2M4Of/XeQPodiMhPf+Aumaxm tJjN65SJFIb9J6PVWF0k9f+XgmJI2DQD9SIrW0oZ+brJYPMzCA/PxCxgXwfKNtkiMGir xnn5J1uS0vUIG1EGHPYheGXPrKw2ZNtatP5AtM+B6b0jGd1/TaWBjvqeFYr2TQUiMT1v kv0Q== X-Gm-Message-State: ALoCoQlBc9EHgvsSIDousFeiE2QbRiEFNgBchptJiZ7RjDf7zXXo+VWBCMDgcQ8B0nx6HT+vQ/pe X-Received: by 10.180.106.104 with SMTP id gt8mr28806765wib.51.1414675177196; Thu, 30 Oct 2014 06:19:37 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id p1sm8678677wjy.22.2014.10.30.06.19.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Oct 2014 06:19:35 -0700 (PDT) Message-ID: <54523B57.1010802@multiplay.co.uk> Date: Thu, 30 Oct 2014 13:21:27 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 13:19:40 -0000 On 30/10/2014 12:10, Bjoern A. Zeeb wrote: > On 30 Oct 2014, at 09:47 , O'Connor, Daniel wrote: > >> On 30 Oct 2014, at 19:44, Steven Hartland wrote: >>> On 30/10/2014 08:24, O'Connor, Daniel wrote: >>>> On 30 Oct 2014, at 13:23, Steven Hartland wrote: >>>>> Making things harder to manage vs saving a little bit of space on the >>>>> root partition really doesn't sound like a good idea; especially when >>>>> with the ZFS install, which I would suggest is becoming the norm, the >>>>> root partition doesn't suffer from space issues anyway. >>>> Note that it’s not “a little bit” of space. >>>> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}' >>>> 49312 >>>> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’ >>>> 212464 >>>> >>>> i.e. the debug information is more than 4x larger than the code its for (!). >>> That's still a trivial about of space in the grand scheme of things. >> Yes. > No it is not a trivial amount of space; it’s about 20ish% of the installation of the base system. It may be a decent percentage but when that's a percentage of a small number its still results in a trivial amount of space in the grand scheme of things, which was my point ;-) > I guess I am one source for the request to get them out of /boot/kernel/*.symbols into a spearate tarball and not install them by default for users. The thing to keep in mind, if we don't have symbols installed is how we create useful panic information. > The reasons for me are indeed manyfold: > > (a) symbol files are for developers. Developers are clever people, often with custom systems, they know how to deal with them as they already do whatever they want anyway in 7 different ways. Yes and no, generating useful information from a users panic issue is something we really need to ensure is still possible. As where they aren't the developer, they are the source of the information. So maybe some sort of post processing utility? > (b) A user should usually never have to bother with them, so why have them installed in first place? They go onto (release) the media so that developers have access to them, or that users, if guided by a developer, can install them to debug a problem. Moving them to a separate directory and into a different tarball makes that a lot easier. Assuming the above is solved yes. > (c) We have people deploying gazillions of FreeBSD systems from default media, this stuff does add up; 10TB sounds small unless you have to back it up regularly, need disaster copies, or you need to minimise recovery or migration time, when every s is worth a few $$s. Are you suggesting you only backup your root partition and not your usr partition, as if so its a null argument as the total size is still the same. I'm assuming not and your saying we shouldn't install debug at all, which has the above side effect. > (d) A couple of times a year I do spare VM image backup and recovery including migration. Moving the data back and forth can only happen in a very limited time frame, so I try to keep these VM images as small as possible. rm -f /boot/kernel/*.symbol after install is really not keeping the sparseness as no one really supports TRIM on the VM images. Thus I’d just have lost 200MB * n VMs that I need to move around over 200ms RTT. There are cruel workarounds; I know how to apply them as I am a developer, but if I do this stuff, there must be 1000s of users doing that, and they don’t. Sounds like having a way to not install symbols to the root partition for *binary* installs is the real requirement? So having an alternative location off root would be solution. > (e) People still have / (boot) filesystems in the 256M-1G space for the foreseeable future. How do you ever cramp two kernels in there during an update for a machine that you will never ever see again because it’s in Antarctica on a 9600 baud connection? While I appreciate such systems exist surely given your previous point where you actually don't want them installed at all, so providing that option instead of moving them to a different location can causing a load more issues is a better solution is it not? > (f) … > > Yes I can understand that on these 40TB ZFS machines, no one gives a damn about 200MB, but unfortunately not the entire world runs on these kinds of machines. We have plenty of users on 10 year old hardware still running a FreeBSD installation and it works perfectly fine and does the job (until the HW dies;-). > > > The entire cp -pR kernel kernel.good solution is nothing I’d expect a user to ever do. But I am aware that’s a “developer standard”. Maybe we just need to improve the situation for ourselves rather than pessimising 98% of users out there. Indeed. > I personally do not mind where the symbol files will end up as long as they are in their own directory and not onto systems by default with releases unless someone ticks a box. Whether that is /boot/kernel/symbols/* or /usr/lib/***, I couldn’t care less, apart from the fact that /boot remains on a space constrained file system for a lot of legacy system that symbol files have filled up more than once for me in the past. > > > So maybe the real solution is indeed for developers to think how to manage kernels and related files and settings in the future? > That sounds totally reasonable. We just need to have someway to easily post generate the useful information we currently get from a panic when the user doesn't have symbols installed. I think overall there's options to move forward, we just need to ensure its not at the expense of usability for those that do have space. Regards Steve From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 14:16:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B21AB910 for ; Thu, 30 Oct 2014 14:16:19 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72783FBA for ; Thu, 30 Oct 2014 14:16:19 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id l13so3675375iga.9 for ; Thu, 30 Oct 2014 07:16:18 -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:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=jx4slMVwuRjUidpvjRTQXrLh2x9sYKkU8cifqmQeNqs=; b=NVJfQRi0J2TBTe5qdrVLqiWGSk8x4NBbwNYPJFm1viuOd7iCmks1F3LrDehjLC2GC3 AWmuIImfZF2HXq8J1LEqe3+zcgUeUQAek6yqwabJSiKzbRFSda28gsNxdVgNc/1NBYMi ZVdPLNLV1CBm6eslFPDltbLdQaSHdd0YZdVH2O5/xy6OKlKSqw1u/BxC1MJTMhCpHHSv EJ1StIJYhLpBhyOC7VnYSsTMWEyNvKByaTQ/rIcXASXK1xh4H9iwe5VNJF9IXwGEwI1X jhPSUllQRK3BBLiL9Cqv9llXWeS9f/VSfgbcYEpkiJBg0keCj2C7wwX4os+EmwxHxXj+ abpA== X-Received: by 10.50.43.137 with SMTP id w9mr20519267igl.33.1414678578874; Thu, 30 Oct 2014 07:16:18 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Thu, 30 Oct 2014 07:15:58 -0700 (PDT) In-Reply-To: <54523B57.1010802@multiplay.co.uk> References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> <54523B57.1010802@multiplay.co.uk> From: Ed Maste Date: Thu, 30 Oct 2014 10:15:58 -0400 X-Google-Sender-Auth: 0dtnIH4wAGPE58-QTnQ2w53LL68 Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 14:16:19 -0000 On 30 October 2014 09:21, Steven Hartland wrote: > > On 30/10/2014 12:10, Bjoern A. Zeeb wrote: >> >> (a) symbol files are for developers. Developers are clever people, ofte= n >> with custom systems, they know how to deal with them as they already do >> whatever they want anyway in 7 different ways. > > Yes and no, generating useful information from a users panic issue is > something we really need to ensure is still possible. As where they aren'= t > the developer, they are the source of the information. > > So maybe some sort of post processing utility? We're also going to make debug data for userland (libraries and binaries) available. On my system there's about 360MB of kernel debug and 1.5GB of userland debug, and we definitely don't want to unconditionally install all of that. Thus we're going to have to provide the capability of installing debug data at install time or later anyway, We already have some limited post-processing involved in kernel crash handling - /etc/rc.d/savecore to pull the crash out of the swap/dump partition, and crashinfo to extract useful information using kgdb. There are many useful improvements we could make in kernel crash handling, including having the process support on-demand fetching of the kernel debug data. > Sounds like having a way to not install symbols to the root partition for > *binary* installs is the real requirement? That is a requirement, yes. Moving the debug data to a separate partition also opens up some compelling use cases for large scale deployments, where multiple systems run the same release. The machines can run from their own install on disk, but have the infrequently-used debug data NFS mounted from a common location. The / and /boot partitions may be mounted read-only. >> The entire cp -pR kernel kernel.good solution is nothing I=E2=80=99d exp= ect a user >> to ever do. But I am aware that=E2=80=99s a =E2=80=9Cdeveloper standard= =E2=80=9D. Maybe we just >> need to improve the situation for ourselves rather than pessimising 98% = of >> users out there. > > Indeed. ... > I think overall there's options to move forward, we just need to ensure i= ts > not at the expense of usability for those that do have space. Setting DEBUGDIR=3D in /etc/src.conf will retain the current behaviour of installing the debug data beside the kernel and modules (and userland binaries and libraries). Does this adequately address your use case? >> Whether that is /boot/kernel/symbols/* >> or /usr/lib/***, I couldn=E2=80=99t care less Note that if they go in /boot/kernel/symbols/ then we have to teach GDB, LLDB, and other tools to look there; if they go in /usr/lib/debug they're found automatically by the debuggers. We may have to add standalone debug path support to other tools, but it's very little additional work. From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 14:24:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55C88B96 for ; Thu, 30 Oct 2014 14:24:52 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D58F911A for ; Thu, 30 Oct 2014 14:24:51 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id h11so7560480wiw.6 for ; Thu, 30 Oct 2014 07:24:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xNfFTxufkJma8vPbEN6tY2dS1f5yf7qrRJd0Z45L820=; b=c1bKumrRI8kp4+sDWgKwKkzl9QEAGcXQrTDaI5NifTdwNsQnNBE3OsxQrdWgzpUQSS HGexF4yM+PicZNUc75utxEAthhxPBp+KsX3gjixW4ciGa/zW/j8VFMS1jJxchYWp8PL5 hnNN7HBnoqEw7bSeif2/D0ribEePs/ulZmaGUKEPFEDqElx21mkAbL1IDu7PKGOxFrkE mOqVuC0lKBP8RHM6EWDW7Tn6UyHCb4g6HJ0dVaFI1dpZA+KwPs3bYBmczz7aRgzG/Coj sCmHueeCcnWGzW4IZ3r2Od8GAnNCnvHdbJs7q1gaxyHIujGlM57rdl/Rvk22u71/q/Y7 V4hQ== X-Gm-Message-State: ALoCoQn5ZuDE2uH9FH7JTomlpHNpRgeCrhXwpkHoQTQkXZ6lsuoKmQ6ea9sg2c1BMb6KjJfHwQbO X-Received: by 10.180.221.129 with SMTP id qe1mr20748803wic.21.1414679089475; Thu, 30 Oct 2014 07:24:49 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id bg10sm8840982wjc.47.2014.10.30.07.24.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Oct 2014 07:24:48 -0700 (PDT) Message-ID: <54524A9F.8000400@multiplay.co.uk> Date: Thu, 30 Oct 2014 14:26:39 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> <54523B57.1010802@multiplay.co.uk> In-Reply-To: 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.18-1 Precedence: 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, 30 Oct 2014 14:24:52 -0000 On 30/10/2014 14:15, Ed Maste wrote: > On 30 October 2014 09:21, Steven Hartland wrote: >> On 30/10/2014 12:10, Bjoern A. Zeeb wrote: >>> (a) symbol files are for developers. Developers are clever people, often >>> with custom systems, they know how to deal with them as they already do >>> whatever they want anyway in 7 different ways. >> Yes and no, generating useful information from a users panic issue is >> something we really need to ensure is still possible. As where they aren't >> the developer, they are the source of the information. >> >> So maybe some sort of post processing utility? > We're also going to make debug data for userland (libraries and > binaries) available. On my system there's about 360MB of kernel debug > and 1.5GB of userland debug, and we definitely don't want to > unconditionally install all of that. Thus we're going to have to > provide the capability of installing debug data at install time or > later anyway, > > We already have some limited post-processing involved in kernel crash > handling - /etc/rc.d/savecore to pull the crash out of the swap/dump > partition, and crashinfo to extract useful information using kgdb. > There are many useful improvements we could make in kernel crash > handling, including having the process support on-demand fetching of > the kernel debug data. Yer that's the process that was in my head, if debug symbols aren't available when savecore runs we're going to need a way to update / rerun when they are available, or even better give it the ability to do the same job with remote symbols? > Sounds like having a way to not install symbols to the root partition for > *binary* installs is the real requirement? > That is a requirement, yes. > > Moving the debug data to a separate partition also opens up some > compelling use cases for large scale deployments, where multiple > systems run the same release. The machines can run from their own > install on disk, but have the infrequently-used debug data NFS mounted > from a common location. The / and /boot partitions may be mounted > read-only. Sound like a good idea :) > >>> The entire cp -pR kernel kernel.good solution is nothing I’d expect a user >>> to ever do. But I am aware that’s a “developer standardâ€. Maybe we just >>> need to improve the situation for ourselves rather than pessimising 98% of >>> users out there. >> Indeed. > ... >> I think overall there's options to move forward, we just need to ensure its >> not at the expense of usability for those that do have space. > Setting DEBUGDIR= in /etc/src.conf will retain the current behaviour > of installing the debug data beside the kernel and modules (and > userland binaries and libraries). Does this adequately address your > use case? Yep that works :) > >>> Whether that is /boot/kernel/symbols/* >>> or /usr/lib/***, I couldn’t care less > Note that if they go in /boot/kernel/symbols/ then we have to teach > GDB, LLDB, and other tools to look there; if they go in /usr/lib/debug > they're found automatically by the debuggers. > > We may have to add standalone debug path support to other tools, but > it's very little additional work. One thing to check would be to ensure that /usr is mounted when savecore runs. Regards Steve From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 14:41:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BC11D8 for ; Thu, 30 Oct 2014 14:41:00 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BE5A242 for ; Thu, 30 Oct 2014 14:41:00 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id hn18so3442387igb.1 for ; Thu, 30 Oct 2014 07:40:59 -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:from:date:message-id :subject:to:cc:content-type; bh=/CHIE1YY9+xac2hwll5c1x+nDOorO30T1TcBb6BCRR0=; b=BmZZrkHPzYEwyBVLQU1w+hvIRDNoJxGWteob06Xu6jJD9OczsIZ3Bx/dttMjUWYKA1 shx7jPhEy0qmfWKjVZGROYMODFIo3o0V8r7ehNpgSamMrcelWTXUxJrQhg7nMavpTP8F JcE0zldHSNSuckGsfl8QCgeU1+aoQsig8Os7gYDcj+S0xMkblcqafenpDaLRdvksTprM nyPgmQqsVUf2CIZKbyha/CjMvN/YPc4ZplEpMJ2AA5fKMZsDkTTDkyEJJF8MBPLAWyKq 3KUCQffXzL8Di+T5FTu7WEqywB4ZBK52V1BHbLhxxussP6cp5TkO+FMd4IamXxZ5m8XX 9imA== X-Received: by 10.107.13.137 with SMTP id 131mr20493530ion.2.1414680059648; Thu, 30 Oct 2014 07:40:59 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Thu, 30 Oct 2014 07:40:39 -0700 (PDT) In-Reply-To: <54524A9F.8000400@multiplay.co.uk> References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> <54523B57.1010802@multiplay.co.uk> <54524A9F.8000400@multiplay.co.uk> From: Ed Maste Date: Thu, 30 Oct 2014 10:40:39 -0400 X-Google-Sender-Auth: JCt1nPIDeZk9CHxKudKm6RD5Gh8 Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 14:41:00 -0000 On 30 October 2014 10:26, Steven Hartland wrote: > > Yer that's the process that was in my head, if debug symbols aren't > available when savecore runs we're going to need a way to update / rerun > when they are available, or even better give it the ability to do the same > job with remote symbols? Yeah, remote symbol support will be excellent (eventually). Crashinfo already operates on the most recent dump by default, so the solution could be as simple as adding a flag to fetch debug files if not already installed. The user would only need to run crashinfo -f to regenerate the crash information with debug data available (and we could mention that explicitly in the crash report). >> Setting DEBUGDIR= in /etc/src.conf will retain the current behaviour >> of installing the debug data beside the kernel and modules (and >> userland binaries and libraries). Does this adequately address your >> use case? > > Yep that works :) Great. I've been pondering this for so long that I may have forgotten not everyone has the same context. > One thing to check would be to ensure that /usr is mounted when savecore > runs. Indeed, but we're covered there: the crash info is generated by /usr/sbin/crashinfo, which relies on /usr/bin/gdb, so it better be mounted :) From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 16:01:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B5E87A2 for ; Thu, 30 Oct 2014 16:01:47 +0000 (UTC) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAE2CCBB for ; Thu, 30 Oct 2014 16:01:46 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id m15so4602610wgh.13 for ; Thu, 30 Oct 2014 09:01:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7TdtU/6Hck0fAN+4jsJvz35WxYttTu/aUVmDr7pUF8I=; b=FQRrHATe7TkpOYxDMQe8B3hlz1rCEtgBESahkECdL6bS8tw06NpW24aWx1q5ZUJrvy AdReZrgQxYUe/JPyHEmYiWR3G+xukl8V/ueBo678b8b4N197xLJD2iQjadaFLg2uzqQF FP5+v1+qzKBScdLSMtSnyVfaSCKb9K53wQmf2OxyK+zJRC8878qKmposJtbMUc8z9TIj URAW+OXtdcO0mfzGGlL9X7fP7/2BmBP9OGNDjyzKX3z2ozv0mz/mWCnRBOW1EiFzvdw8 C+R8hYc0UsiMMbuXYQkMggR9W4G/LIxez0xomUJ012juC4ghxKJL3mDs3xwcGHGKgJcd BUkQ== X-Gm-Message-State: ALoCoQkZE+7Ftp0rofg4wY1UR/FWzVbHAu3G93eqHtdqm7R654Miq/GBRcslqNFkdWR8A3u0e3Wf X-Received: by 10.180.77.170 with SMTP id t10mr11739039wiw.57.1414684904518; Thu, 30 Oct 2014 09:01:44 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id rx8sm4596472wjb.30.2014.10.30.09.01.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Oct 2014 09:01:42 -0700 (PDT) Message-ID: <54526156.3080400@multiplay.co.uk> Date: Thu, 30 Oct 2014 16:03:34 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> <54523B57.1010802@multiplay.co.uk> <54524A9F.8000400@multiplay.co.uk> 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.18-1 Precedence: 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, 30 Oct 2014 16:01:47 -0000 On 30/10/2014 14:40, Ed Maste wrote: > On 30 October 2014 10:26, Steven Hartland wrote: >> Yer that's the process that was in my head, if debug symbols aren't >> available when savecore runs we're going to need a way to update / rerun >> when they are available, or even better give it the ability to do the same >> job with remote symbols? > Yeah, remote symbol support will be excellent (eventually). > > Crashinfo already operates on the most recent dump by default, so the > solution could be as simple as adding a flag to fetch debug files if > not already installed. The user would only need to run crashinfo -f to > regenerate the crash information with debug data available (and we > could mention that explicitly in the crash report). > >>> Setting DEBUGDIR= in /etc/src.conf will retain the current behaviour >>> of installing the debug data beside the kernel and modules (and >>> userland binaries and libraries). Does this adequately address your >>> use case? >> Yep that works :) > Great. > > I've been pondering this for so long that I may have forgotten not > everyone has the same context. > >> One thing to check would be to ensure that /usr is mounted when savecore >> runs. > Indeed, but we're covered there: the crash info is generated by > /usr/sbin/crashinfo, which relies on /usr/bin/gdb, so it better be > mounted :) Fantastic, thanks for taking the time to address my concerns, much appreciated :D From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 16:49:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E6B3DCF for ; Thu, 30 Oct 2014 16:49:37 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05020253 for ; Thu, 30 Oct 2014 16:49:37 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id h3so5514580igd.7 for ; Thu, 30 Oct 2014 09:49:36 -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:from:date:message-id :subject:to:content-type; bh=s0Cl7gzW5k7UszwJVnZQ1se9xjelcCQmgqYmTq/MYOk=; b=RECXtuSosnxpzrrWhrs87cJ5PKne73Ysp1gjlrsAgkLvUHMv2riOdMX+3EjgptBBbU NiDItBs53NBoWT+7kEumjSf9oy1Mezkjf1wb738SPETDRXCF5gfoqyIWTgC0tMfuSSoJ at37SPl0Ks5ktbFttNPJrQIHnKifzQBsLPBRFfhtbcwdNnAwafiHDFkOVBj9AnpPMYI3 ksUpja/1RFfS21VSt1M0VN86j56Z0RCPbags7B319Gu6rl2gQhyvKLU3AdJSrO5bNlPg LJLvul6bD8+m9lTmqJ4jnj0YkU+/ha3K67AhjUmXzwNmZvp+R1U3TYholVENJhmBXXa7 AUng== X-Received: by 10.51.17.104 with SMTP id gd8mr21843998igd.21.1414687776497; Thu, 30 Oct 2014 09:49:36 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.207 with HTTP; Thu, 30 Oct 2014 09:49:16 -0700 (PDT) In-Reply-To: <20141030062026.GC8852@funkthat.com> References: <54511A7E.1020307@multiplay.co.uk> <20141030062026.GC8852@funkthat.com> From: Ed Maste Date: Thu, 30 Oct 2014 12:49:16 -0400 X-Google-Sender-Auth: 0GiS0eJMDdWluxb7utXqB9Ub2Y4 Message-ID: Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 16:49:37 -0000 On 30 October 2014 02:20, John-Mark Gurney wrote: > > Oh, make sure that make install (or installkernel) properly handles > moving the debug data too... i.e. kernel to kernel.old... Yes, in the case that /boot/kernel is moved to /boot/kernel.old /usr/lib/debug/boot/kernel is moved to /usr/lib/debug/boot/kernel.old. From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 16:50:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66EC1EE1; Thu, 30 Oct 2014 16:50:19 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BAC4267; Thu, 30 Oct 2014 16:50:19 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id r10so5496496pdi.31 for ; Thu, 30 Oct 2014 09:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=c98HdC/57AFVOSjlBIHb45uqvtiI9hH9qvmOxVb/bVY=; b=gzpMikm2/4KMXYVAmKJysMD6R7MFvE2Vfi9iI1lCxBhevEm9hqYdgCtLtUvJ4ZOP2D ROtUhFAvIEiZi/WRw0PjyioP80PQcq9GZm/WPdM4yF29gdNFNJPgqqseXONvJgBWui5I z9Nm2b5vQxBaf09B1F2UdDcDbblk299d2I0GPm3j9WL3KvojsJ0gJlXRPnIlltuLEbCa YlaBU6hyUYf7dWGtLwHMQYszF67bUenZXM8sV4dowVX+CxVPap3XjEPe80jptJEK8M7o cTIlF1JMhOR3W3RKncd0EYJz//S5oWj4eey18RZ/a9zOU1fIm/F2AdfK5N0xO+HFXDSW FEUQ== X-Received: by 10.70.35.49 with SMTP id e17mr18423665pdj.68.1414687818753; Thu, 30 Oct 2014 09:50:18 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:e815:f674:cee1:d6e8? ([2601:8:ab80:7d6:e815:f674:cee1:d6e8]) by mx.google.com with ESMTPSA id q1sm7611475pdq.67.2014.10.30.09.50.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 09:50:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_422EE7AB-1976-4C7D-A12F-42F7F87F411A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ From: Garrett Cooper In-Reply-To: Date: Thu, 30 Oct 2014 09:50:16 -0700 Message-Id: <66EC00B6-CDEF-49E5-9BA5-C87359E93152@gmail.com> References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> <54523B57.1010802@multiplay.co.uk> To: Ed Maste X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current , Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 16:50:19 -0000 --Apple-Mail=_422EE7AB-1976-4C7D-A12F-42F7F87F411A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 30, 2014, at 7:15, Ed Maste wrote: =85 >>> Whether that is /boot/kernel/symbols/* >>> or /usr/lib/***, I couldn=92t care less >=20 > Note that if they go in /boot/kernel/symbols/ then we have to teach > GDB, LLDB, and other tools to look there; if they go in /usr/lib/debug > they're found automatically by the debuggers. >=20 > We may have to add standalone debug path support to other tools, but > it's very little additional work. Teaching gdb/lldb/etc to look in ${DEBUGDIR} for each element in = `kenv module_path` would be really nice. It won=92t fix debug info with = all kids (open-vm-tools or virtualbox installs to /usr/local IIRC), but = it=92s better than nothing. Thanks! --Apple-Mail=_422EE7AB-1976-4C7D-A12F-42F7F87F411A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUUmxIAAoJEMZr5QU6S73eNYIH/RO/JEHtSMfCWfQW9stArMSQ ggdPA2qYXkV8S/1TgbOxeYD8/NoiHoCDmxyXyB34CjKkg7RjNTrqw9G3m91cIS2I 1J3nPAZB5Bfq0gSwjdvI1lNpqMSs6rA5JzWGgQGCAy6ADTRSDCbkBYvHqlyf1Nvt Nokx6SwU10i+fVz1khq5wOqn8EAmpM8sSvuS0+7mjpTIvMH2NkDwosjaJiEjngqb WD6H0+FhAgE4nxWdTEjr0LyXGrj3J0byl+JhOZ6Awm0SR/5vyUF2F1I5QQqSG7La NVaafINas6Utuk70cULLGHkJGd4xGpRH4trjb1SY497/2UJ9iSlMwsrBa8HkxCw= =sTwP -----END PGP SIGNATURE----- --Apple-Mail=_422EE7AB-1976-4C7D-A12F-42F7F87F411A-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 16:57:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4202A101; Thu, 30 Oct 2014 16:57:11 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09267374; Thu, 30 Oct 2014 16:57:11 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fa1so5840459pad.11 for ; Thu, 30 Oct 2014 09:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=d5ggWnsVX7+IyMk2fL+vFkF4FHn2RfMaeQ5G3NfP0f0=; b=gtXDteMOaw/LMLKLnfTc30Vh9CX+TRZl4m7+YwITlWYe4VK2xKh0hP+skJmUtD6bbH QmsjIkUiGGSBD7NLeUebAo4YWIxPaNLmV6CrAryZtuu2eL9JvzqBaFEsx74ByJdk4Fl1 juJAbagaFLB4vewET8jtXQCXrdgpEgWaOYPneytv4u4a/a4FDnkLjD+g2SZQm5Kj9FoH 4IOEb59cVBCY7M8QxcwEHok4oYHowyZ+Mr7g6KZu3E7vPycqrO0QcrzDUftIC0KVuve5 qDQNVAj3JgWeTP3SBK5tSDGM4kh3rExFswjo7ED0WhjJOwz5zRzTtJwMcBZVM9dYckx3 vkAQ== X-Received: by 10.70.140.70 with SMTP id re6mr10267999pdb.149.1414688230448; Thu, 30 Oct 2014 09:57:10 -0700 (PDT) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id k9sm7639838pdj.41.2014.10.30.09.57.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 09:57:09 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8EC6391F-6BA6-4FD0-9024-34BDF98B73D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Booting from symlinked kernels (was "HEADS UP: Standalone kernel debug files moving out of /boot/kernel/") From: Garrett Cooper In-Reply-To: Date: Thu, 30 Oct 2014 09:57:08 -0700 Message-Id: <7F25A179-8252-4A4B-BAFE-04A230F7255D@gmail.com> References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> To: Ed Maste X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current , Steven Hartland , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 16:57:11 -0000 --Apple-Mail=_8EC6391F-6BA6-4FD0-9024-34BDF98B73D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 30, 2014, at 6:07, Ed Maste wrote: > On 29 October 2014 22:32, Steve Kargl = wrote: >> On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote: >>> On 29 October 2014 12:49, Steven Hartland = wrote: >>>> Hmm not sure I like this idea as it would make it more difficult to = make a >>>> copy / backup a kernel. >>>>=20 >>>> ATM when I want to copy a kernel for debugging its a one liner, = splitting >>>> debug symbols off to /usr/lib would prevent this. >>>=20 >>> To retain the current behaviour you can set DEBUGDIR=3D (i.e., = empty), >>> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}. >>=20 >> No, you can't. >>=20 >> su root >> cp -pR /boot/kernel /boot/good >>=20 >> Where does DEBUGDIR enter the picture? >=20 > In your kernel build configuration (src.conf or similar ways). If you use the kernel build infrastructure properly, the debug info = should be installed to ${DEBUGDIR}/boot/${INSTKERNNAME} =97 not = ${DEBUGDIR}/boot/kernel (the latter is broken for folks like my that = have multiple kernel configs in their src.conf). As far as the symlink trick for /boot/kernel is concerned, that only = works on UFS. I used to use it on ZFS, it broke one day, I sent out an = email and got some replies back stating that they weren=92t really = worried about the feature being broken (I can hunt down the email = thread=85 I just don=92t have it in my search results right now). = Another worthwhile bug to explore/fix is: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D153996 . Cheers! -Garrett --Apple-Mail=_8EC6391F-6BA6-4FD0-9024-34BDF98B73D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUUm3kAAoJEMZr5QU6S73et9EIAIhvwIz4g6LElg65ENJKaB+1 VvmCytWy3nV2COmRlorLUjYVC2UM8u4+yfKPfd+65RS13RPcfwFauCknfW6Pm1PH GM6IQnOp0sjlcJWxQCZ1tcATYHrqn0ZzyfWsL9D+UxdX/Cpfple9RlDBEnXR9pEb l2dsoBHCsELt48qSMrchMwAHRGAx19Zvlpem1CF72NJR8PYlSuxG1rhX8tRA+wrZ Zvg3wghkNpUV9NII7SzpPPnLIW9l+3eeS0TS4XVfHQT1PxYCj2qyl8mhfS5uFEr7 arR2U4xofEde4js8N3FCrfNrJznCuZO0JhYcWNoAwVuZqH90u1w5yoCJzv8dOu4= =OUEu -----END PGP SIGNATURE----- --Apple-Mail=_8EC6391F-6BA6-4FD0-9024-34BDF98B73D4-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 17:00:33 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5BEF386; Thu, 30 Oct 2014 17:00:32 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AF5539E; Thu, 30 Oct 2014 17:00:31 +0000 (UTC) Received: from firewallnew (162-230-214-65.lightspeed.lsvlky.sbcglobal.net [162.230.214.65]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id s9UGrYYJ017161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Oct 2014 12:53:35 -0400 (EDT) (envelope-from mikej@mikej.com) Received: from mail.mikej.com (firewall [192.168.6.63]) by firewallnew (8.14.9/8.14.9) with ESMTP id s9UGrT1E055730; Thu, 30 Oct 2014 12:53:32 -0400 (EDT) (envelope-from mikej@mikej.com) X-Authentication-Warning: firewallnew: Host firewall [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 Oct 2014 12:53:29 -0400 From: Michael Jung To: Baptiste Daroussin Subject: pkg 1.4.0.alpha3 - pkg: =?UTF-8?Q?pkg=5Frepo=5Ffetch=5Fremote=5Fm?= =?UTF-8?Q?map=28cannot=20mmap=20fetched=29=3A=20Invalid=20argument=20/=20?= =?UTF-8?Q?Assertion=20failed=3A=20=28curvar=20!=3D=20NULL=29=2C=20functio?= =?UTF-8?Q?n=20pkg=5Fsolve=5Fadd=5Frequest=5Frule=2C=20file=20pkg=5Fsolve?= =?UTF-8?Q?=2Ec=2C=20line=20=35=33=37=2E?= In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> Message-ID: <81d6e143904a67b6f044bb99199a1fc1@mail.mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.0.2 Cc: ports@freebsd.org, current@freebsd.org, owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 17:00:33 -0000 Hello: Errors shown toward end of email. Note this is a cleanly installed jail but an previously built repository from an older version of head. I can nuke the head repository and rebuild from scratch but I wanted to present these errors first. --mikej FreeBSD bsd11 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r273857: Thu Oct 30 08:50:37 EDT 2014 mikej@bsd11:/usr/obj/usr/src/sys/GENERIC amd64 JAILNAME VERSION ARCH METHOD TIMESTAMP PATH 10stable 10.1-PRERELEASE r273580 amd64 svn 2014-10-24 11:10:51 /usr/local/poudriere/jails/10stable head 11.0-CURRENT r273858 amd64 svn 2014-10-30 10:45:31 /usr/local/poudriere/jails/head 9stable 9.2-STABLE amd64 svn /usr/local/poudriere/jails/9stable 9stable32 9.2-STABLE i386 ftp /usr/local/poudriere/jails/9stable32 root@bsd11:~ # pkg -vv Version : 1.4.0.alpha3 PKG_DBDIR = "/var/db/pkg"; PKG_CACHEDIR = "/var/cache/pkg"; PORTSDIR = "/usr/ports"; INDEXDIR = ""; INDEXFILE = "INDEX-11"; HANDLE_RC_SCRIPTS = false; ASSUME_ALWAYS_YES = false; REPOS_DIR [ "/etc/pkg/", "/usr/local/etc/pkg/repos/", ] PLIST_KEYWORDS_DIR = ""; SYSLOG = true; ABI = "FreeBSD:11:amd64"; ALTABI = "freebsd:11:x86:64"; DEVELOPER_MODE = false; VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.bz2"; FETCH_RETRY = 3; PKG_PLUGINS_DIR = "/usr/local/lib/pkg/"; PKG_ENABLE_PLUGINS = true; PLUGINS [ ] DEBUG_SCRIPTS = false; PLUGINS_CONF_DIR = "/usr/local/etc/pkg/"; PERMISSIVE = false; REPO_AUTOUPDATE = true; NAMESERVER = ""; EVENT_PIPE = ""; FETCH_TIMEOUT = 30; UNSET_TIMESTAMP = false; SSH_RESTRICT_DIR = ""; PKG_ENV { } PKG_SSH_ARGS = ""; DEBUG_LEVEL = 0; ALIAS { } CUDF_SOLVER = ""; SAT_SOLVER = ""; RUN_SCRIPTS = true; CASE_SENSITIVE_MATCH = false; LOCK_WAIT = 1; LOCK_RETRIES = 5; SQLITE_PROFILE = false; WORKERS_COUNT = 0; READ_LOCK = false; PLIST_ACCEPT_DIRECTORIES = false; IP_VERSION = 0; AUTOMERGE = true; Repositories: myrepo: { url : "File:///usr/local/poudriere/data/packages/head-default", enabled : yes } FreeBSD_ssp: { url : "pkg+http://pkg.FreeBSD.org/FreeBSD:11:amd64/ssp", enabled : yes, mirror_type : "SRV", signature_type : "FINGERPRINTS", fingerprints : "/usr/share/keys/pkg" } root@bsd11:~ # And here execution from the console: root@bsd11:/usr/local/poudriere/data/packages # rm -r head-default/ root@bsd11:/usr/local/poudriere/data/packages # cd root@bsd11:~ # poudriere bulk -j head archivers/arc [00:00:00] ====>> Creating the reference jail... done [00:00:00] ====>> Mounting system devices for head-default [00:00:00] ====>> Mounting ports/packages/distfiles [00:00:00] ====>> Converting package repository to new format [00:00:00] ====>> Stashing existing package repository [00:00:00] ====>> Mounting ccache from: /var/cache/ccache [00:00:00] ====>> Mounting packages from: /usr/local/poudriere/data/packages/head-default [00:00:00] ====>> Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options [00:00:00] ====>> Appending to make.conf: /usr/local/etc/poudriere.d/head-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/.m/head-default/ref/etc/resolv.conf [00:00:00] ====>> Starting jail head-default [00:00:01] ====>> Logs: /usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_11h12m11s [00:00:01] ====>> Loading MOVED [00:00:01] ====>> Calculating ports order and dependencies [00:00:01] ====>> pkg package missing, skipping sanity [00:00:01] ====>> Skipping incremental rebuild and repository sanity checks [00:00:01] ====>> Cleaning the build queue [00:00:01] ====>> Recording filesystem state for prepkg... done [00:00:03] ====>> Building 3 packages using 3 builders [00:00:03] ====>> Starting/Cloning builders [00:00:03] ====>> Hit CTRL+t at any time to see build progress and stats [00:00:03] ====>> [01][00:00:00] Starting build of ports-mgmt/pkg [00:01:10] ====>> [01][00:01:07] Finished build of ports-mgmt/pkg: Success [00:01:11] ====>> [01][00:00:00] Starting build of devel/ccache [00:01:19] ====>> [01][00:00:08] Finished build of devel/ccache: Success [00:01:20] ====>> [01][00:00:00] Starting build of archivers/arc [00:01:25] ====>> [01][00:00:05] Finished build of archivers/arc: Success [00:01:26] ====>> Stopping 3 builders [00:01:27] ====>> Creating pkgng repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [00:01:29] ====>> Committing packages to repository [00:01:29] ====>> Removing old packages [00:01:29] ====>> Built ports: ports-mgmt/pkg devel/ccache archivers/arc [head-default] [2014-10-30_11h12m11s] [committing:] Queued: 3 Built: 3 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 00:01:28 [00:01:29] ====>> Logs: /usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_11h12m11s [00:01:29] ====>> Cleaning up [00:01:29] ====>> Umounting file systems root@bsd11:~ # root@bsd11:~ # pkg update Updating myrepo repository catalogue... Fetching meta.txz: 100% 260 B 0.3k/s 00:01 Fetching packagesite.txz: 100% 152 B 0.2k/s 00:01 pkg: pkg_repo_fetch_remote_mmap(cannot mmap fetched): Invalid argument <<<<< pkg: Unable to update repository myrepo Updating FreeBSD_ssp repository catalogue... FreeBSD_ssp repository is up-to-date. All repositories are up-to-date. root@bsd11:~ # root@bsd11:~ # pkg update Updating myrepo repository catalogue... myrepo repository is up-to-date. Updating FreeBSD_ssp repository catalogue... FreeBSD_ssp repository is up-to-date. All repositories are up-to-date. root@bsd11:~ # root@bsd11:~ # pkg upgrade Updating myrepo repository catalogue... myrepo repository is up-to-date. Updating FreeBSD_ssp repository catalogue... FreeBSD_ssp repository is up-to-date. All repositories are up-to-date. Updating database digests format: 100% Checking for upgrades (250 candidates): 74% gtkmm24 has no direct installation candidates, change it to gtkmm24? [Y/n]: Checking for upgrades (250 candidates): 91% db48 has no direct installation candidates, change it to db? [Y/n]: Checking for upgrades (250 candidates): 93% compat6x-amd64 has no direct installation candidates, change it to compat6x-amd64? [Y/n]: Checking for upgrades (250 candidates): 100% Processing candidates (250 candidates): 100% Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file pkg_solve.c, line 537. <<<<< Child process pid=45189 terminated abnormally: Abort trap root@bsd11:~ # root@bsd11:~ # ls -la /usr/local/poudriere/data/packages/head-default/ total 8 drwxr-xr-x 3 root wheel 9 Oct 30 11:13 . drwxr-xr-x 8 root wheel 8 Oct 30 11:12 .. lrwxr-xr-x 1 root wheel 16 Oct 30 11:13 .latest -> .real_1414682020 drwxr-xr-x 4 root wheel 8 Oct 30 11:13 .real_1414682020 lrwxr-xr-x 1 root wheel 11 Oct 30 11:13 All -> .latest/All lrwxr-xr-x 1 root wheel 14 Oct 30 11:13 Latest -> .latest/Latest lrwxr-xr-x 1 root wheel 19 Oct 30 11:13 digests.txz -> .latest/digests.txz lrwxr-xr-x 1 root wheel 16 Oct 30 11:13 meta.txz -> .latest/meta.txz lrwxr-xr-x 1 root wheel 23 Oct 30 11:13 packagesite.txz -> .latest/packagesite.txz root@bsd11:~ # Not a programmer debugger - this may be be useless. root@bsd11:~ # gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". (gdb) core pkg.core Core was generated by `pkg'. Program terminated with signal 6, Aborted. #0 0x0000000802b3c12a in ?? () (gdb) http://216.26.158.189/pkg.core Full build logs http://216.26.158.189//2014-10-30_11h12m11s/ I have only tested downstream 10x64 clients against the same build server poudriere jail "10stable" and they do not have any issue with updating the pkg repository or installing newly built packages like archivers/arc. --mikej From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 17:10:15 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9531BD8; Thu, 30 Oct 2014 17:10:15 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 233046BA; Thu, 30 Oct 2014 17:10:14 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id h11so5153023wiw.3 for ; Thu, 30 Oct 2014 10:10:13 -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=V7Rsd/T703dMGf5P5+xlueiaI2u6fhqtLA7ribcLv7M=; b=XwmS6dxYiJovAWfNuoY+yHN+hZB6HVf7YHyHQT+HBKobzNy4IT9IDdks5ScgR7BvSn lCzYtuRXlFDl/iNKfgaH7pSrSYjGT7WvnunjecVA5wKqZsWbsh3IYiY0zHVRnNayvRQU LH2h87v1adJLd7LJR8kP3Maqt5lM+tjUdIaVwV8x3WC5Rt+VqE6DGVs0UT2VbZ1OzhH0 phiHiEHkYRaA0L7rPqyYfsQGJcT5AuoMm3mFClSKww9quBpQXSp7Gnc/aD3KCGY1+NOF Qx9rHtimJsav6Wfc4oiO8lZteJEtYwatlM9EJPH+uEh4qjNbU2jEr9fUTtwk/1qvO4rZ akUw== X-Received: by 10.180.21.140 with SMTP id v12mr45437303wie.44.1414689013381; Thu, 30 Oct 2014 10:10:13 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fv2sm9673022wib.2.2014.10.30.10.10.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Oct 2014 10:10:12 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 30 Oct 2014 18:10:10 +0100 From: Baptiste Daroussin To: Michael Jung Subject: Re: pkg 1.4.0.alpha3 - pkg: pkg_repo_fetch_remote_mmap(cannot mmap fetched): Invalid argument / Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file pkg_solve.c, line 537. Message-ID: <20141030171010.GC2894@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <81d6e143904a67b6f044bb99199a1fc1@mail.mikej.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QRj9sO5tAVLaXnSD" Content-Disposition: inline In-Reply-To: <81d6e143904a67b6f044bb99199a1fc1@mail.mikej.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@freebsd.org, current@freebsd.org, owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 17:10:16 -0000 --QRj9sO5tAVLaXnSD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2014 at 12:53:29PM -0400, Michael Jung wrote: > Hello: >=20 > Errors shown toward end of email. >=20 > Note this is a cleanly installed jail but an previously built repository= =20 > from an older > version of head. I can nuke the head repository and rebuild from=20 > scratch but I wanted to > present these errors first. Can you try alpha4 before nuking the head repository? regards, Bapt --QRj9sO5tAVLaXnSD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRScPIACgkQ8kTtMUmk6EyIgACbBkBFlKpS0+eXR/kEr9JNfWQO lPMAn2322TfsRNUGso2m9Oh6NFG2xXq1 =8rFN -----END PGP SIGNATURE----- --QRj9sO5tAVLaXnSD-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 17:50:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78423899; Thu, 30 Oct 2014 17:50:23 +0000 (UTC) Received: from smtp10.server.rpi.edu (gateway.canit.rpi.edu [128.113.2.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "canit.localdomain", Issuer "canit.localdomain" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 363BBBB7; Thu, 30 Oct 2014 17:50:22 +0000 (UTC) Received: from smtp-auth2.server.rpi.edu (smtp-auth2.server.rpi.edu [128.113.2.232]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id s9UHf14t020762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 13:41:01 -0400 Received: from smtp-auth2.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth2.server.rpi.edu (Postfix) with ESMTP id 6049218444; Thu, 30 Oct 2014 13:41:01 -0400 (EDT) Received: from [128.113.24.47] (gilead-qc124.netel.rpi.edu [128.113.124.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by smtp-auth2.server.rpi.edu (Postfix) with ESMTPSA id 51C9A1843B; Thu, 30 Oct 2014 13:40:46 -0400 (EDT) From: "Garance A Drosehn" To: "Ed Maste" Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Date: Thu, 30 Oct 2014 13:41:06 -0400 Message-ID: In-Reply-To: References: <54511A7E.1020307@multiplay.co.uk> <20141030062026.GC8852@funkthat.com> MIME-Version: 1.0 X-Mailer: MailMate (1.8r4576) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 10.10] X-CanIt-Incident-Id: 03N9tF1Lo X-CanIt-Geo: ip=128.113.124.17; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 17:50:23 -0000 On 30 Oct 2014, at 12:49, Ed Maste wrote: > On 30 October 2014 02:20, John-Mark Gurney wrote: >> >> Oh, make sure that make install (or installkernel) properly handles >> moving the debug data too... i.e. kernel to kernel.old... > > Yes, in the case that /boot/kernel is moved to /boot/kernel.old > /usr/lib/debug/boot/kernel is moved to /usr/lib/debug/boot/kernel.old. I definitely like the idea of moving the debug symbols out to /usr/lib/debug I'm another person who sometimes has multiple kernels sitting in /boot (which is one reason I'd like the debug symbols elsewhere!). I may shuffle those around by hand, and I'm sure I won't remember to shuffle around information under /usr/lib/debug. I also do things like cp -rp kernel kernel-PreBigChange where I save away a copy of the kernel for possible fallback (at some unknown future date), but I wouldn't need two copies of the debug info. When we build a kernel, could we tag it with some unique-ID (by putting that ID in a plain-text file inside the kernel's directory), and then that unique-ID could be used for finding the correct debug info under /usr/lib/debug? This way we wouldn't need to move around any of the debug info under /usr/lib/debug. And we could tell which sets of debug info should be removed by comparing the existing sets of debug info with the kernel-unique-ID's which still exist under /boot. If debug tools need to have the debug-info for the booted kernel to be in a fixed location, then maybe the boot-up process could create a symlink from some fixed pathname to the correct debug info for the kernel which the system booted up on. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 18:46:09 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32A7D967; Thu, 30 Oct 2014 18:46:09 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62116222; Thu, 30 Oct 2014 18:46:08 +0000 (UTC) Received: from firewallnew (162-230-214-65.lightspeed.lsvlky.sbcglobal.net [162.230.214.65]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id s9UIk3PZ045166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Oct 2014 14:46:04 -0400 (EDT) (envelope-from mikej@mikej.com) Received: from mail.mikej.com (firewall [192.168.6.63]) by firewallnew (8.14.9/8.14.9) with ESMTP id s9UIjuRQ071507; Thu, 30 Oct 2014 14:46:02 -0400 (EDT) (envelope-from mikej@mikej.com) X-Authentication-Warning: firewallnew: Host firewall [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 Oct 2014 14:45:56 -0400 From: Michael Jung To: Baptiste Daroussin Subject: Re: pkg 1.4.0.alpha3 - pkg: =?UTF-8?Q?pkg=5Frepo=5Ffetch=5Fremote?= =?UTF-8?Q?=5Fmmap=28cannot=20mmap=20fetched=29=3A=20Invalid=20argument=20?= =?UTF-8?Q?/=20Assertion=20failed=3A=20=28curvar=20!=3D=20NULL=29=2C=20fun?= =?UTF-8?Q?ction=20pkg=5Fsolve=5Fadd=5Frequest=5Frule=2C=20file=20pkg=5Fso?= =?UTF-8?Q?lve=2Ec=2C=20line=20=35=33=37=2E?= In-Reply-To: <20141030171010.GC2894@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <81d6e143904a67b6f044bb99199a1fc1@mail.mikej.com> <20141030171010.GC2894@ivaldir.etoilebsd.net> Message-ID: X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.0.2 Cc: ports@freebsd.org, current@freebsd.org, owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 18:46:09 -0000 On 2014-10-30 13:10, Baptiste Daroussin wrote: > On Thu, Oct 30, 2014 at 12:53:29PM -0400, Michael Jung wrote: >> Hello: >> >> Errors shown toward end of email. >> >> Note this is a cleanly installed jail but an previously built >> repository >> from an older >> version of head. I can nuke the head repository and rebuild from >> scratch but I wanted to >> present these errors first. > > Can you try alpha4 before nuking the head repository? > > regards, > Bapt Ok, I built archivers/zoo, pkg update and pkg install. Looks ok know. I'll let it build my pkg list for head/10/9 with a few new packages and report back it I see any problems. --mikej root@bsd11:/usr/ports/ports-mgmt/pkg-devel # make reinstall root@bsd11:~ # pkg -v 1.4.0.alpha4 root@bsd11:~ # root@bsd11:~ # poudriere bulk -j head archivers/zoo [00:00:00] ====>> Creating the reference jail... done [00:00:00] ====>> Mounting system devices for head-default [00:00:00] ====>> Mounting ports/packages/distfiles [00:00:00] ====>> Stashing existing package repository [00:00:00] ====>> Mounting ccache from: /var/cache/ccache [00:00:00] ====>> Mounting packages from: /usr/local/poudriere/data/packages/head-default [00:00:00] ====>> Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options [00:00:00] ====>> Appending to make.conf: /usr/local/etc/poudriere.d/head-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/.m/head-default/ref/etc/resolv.conf [00:00:00] ====>> Starting jail head-default [00:00:00] ====>> Logs: /usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_14h33m25s [00:00:00] ====>> Loading MOVED [00:00:01] ====>> Calculating ports order and dependencies [00:00:01] ====>> Sanity checking the repository [00:00:01] ====>> Checking packages for incremental rebuild needed [00:00:02] ====>> Deleting stale symlinks [00:00:02] ====>> Deleting empty directories [00:00:02] ====>> Cleaning the build queue [00:00:02] ====>> Recording filesystem state for prepkg... done [00:00:03] ====>> Building 1 packages using 1 builders [00:00:03] ====>> Starting/Cloning builders [00:00:03] ====>> Hit CTRL+t at any time to see build progress and stats [00:00:03] ====>> [01][00:00:00] Starting build of archivers/zoo [00:00:17] ====>> [01][00:00:14] Finished build of archivers/zoo: Success [00:00:18] ====>> Stopping 1 builders [00:00:18] ====>> Creating pkgng repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [00:00:19] ====>> Committing packages to repository [00:00:19] ====>> Removing old packages [00:00:19] ====>> Built ports: archivers/zoo [head-default] [2014-10-30_14h33m25s] [committing:] Queued: 1 Built: 1 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 00:00:20 [00:00:20] ====>> Logs: /usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_14h33m25s [00:00:20] ====>> Cleaning up [00:00:20] ====>> Umounting file systems root@bsd11:~ # root@bsd11:~ # pkg update Updating myrepo repository catalogue... Fetching meta.txz: 100% 264 B 0.3k/s 00:01 Fetching packagesite.txz: 100% 2 KB 1.6k/s 00:01 Processing entries: 100% myrepo repository update completed. 4 packages processed Updating FreeBSD_ssp repository catalogue... FreeBSD_ssp repository is up-to-date. root@bsd11:~ # pkg install zoo Updating myrepo repository catalogue... myrepo repository is up-to-date. Updating FreeBSD_ssp repository catalogue... FreeBSD_ssp repository is up-to-date. All repositories are up-to-date. Updating database digests format: 100% The following 1 packages will be affected (of 0 checked): New packages to be INSTALLED: zoo: 2.10.1_3 [myrepo] The process will require 112 KB more space. 56 KB to be downloaded. Proceed with this action? [y/N]: y Checking integrity... done (0 conflicting) [1/1] Installing zoo-2.10.1_3... [1/1] Extracting zoo-2.10.1_3: 100% root@bsd11:~ # From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 20:52:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E199232 for ; Thu, 30 Oct 2014 20:52:15 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0765212B for ; Thu, 30 Oct 2014 20:52:14 +0000 (UTC) X-AuditID: 1209190c-f795e6d000006c66-25-5452a3cae855 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 35.29.27750.AC3A2545; Thu, 30 Oct 2014 16:47:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9UKl5V9030235; Thu, 30 Oct 2014 16:47:05 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9UKl3bj014359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 16:47:04 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9UKl2iP021626; Thu, 30 Oct 2014 16:47:02 -0400 (EDT) Date: Thu, 30 Oct 2014 16:47:02 -0400 (EDT) From: Benjamin Kaduk To: "O. Hartmann" Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so In-Reply-To: <20141030092039.47802349@prometheus> Message-ID: References: <20141030092039.47802349@prometheus> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrHtqcVCIwcQWXos5bz4wWfyd9YfJ gcljxqf5LB6nth9kDGCK4rJJSc3JLEst0rdL4Mr4/OAVY8EF3YrnV6azNzAeUeli5OSQEDCR +Pb9EyOELSZx4d56ti5GLg4hgdlMEgtuT2CFcDYySrROOs0O4Rxiklg1bSJUWQOjxIynO4DK ODhYBLQlbj0OBxnFJqAiMfPNRjYQW0RAX+Jc02kwm1nAUOLlunvsILawgJ/Eqn3nwWxOoPjx DztZQWxeAUeJufM/M4HYQgIGEhc/9DCD2KICOhKr909hgagRlDg58wkLxEwtieXTt7FMYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjOBQleTZwfjmoNIh RgEORiUeXo0TgSFCrIllxZW5hxglOZiURHmjZgeFCPEl5adUZiQWZ8QXleakFh9ilOBgVhLh 9eoGyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfCuXAjUKFiUmp5a kZaZU4KQZuLgBBnOAzR8E0gNb3FBYm5xZjpE/hSjopQ4rxVIQgAkkVGaB9cLSyWvGMWBXhHm 3QNSxQNMQ3Ddr4AGMwEN/jw1AGRwSSJCSqqBccpjBY0j9fai1/dO9bnw5UqhpW9zux/THK93 Ucpub5QZumy9Hh59YLX9xNmpR/7veqXgrKkQ9jSl5tHba+vZfh/d/OV+W9eh+6wGwTO4LBsC G3POP/+neiNyx1KV79HiR52sk9VVORnq7l7brCBuU3S8cv+Whr1Ht+98dH7/ui6hR4H/L6xa 5aXEUpyRaKjFXFScCAD9u5LUAAMAAA== Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 20:52:15 -0000 [stripping -questions; please don't cross-post] Disclaimer: I am part of the group that develops MIT Kerberos On Thu, 30 Oct 2014, O. Hartmann wrote: > Searching for suitable manuals, I found some HowTos describing how to > setup MIT Kerberos V with an OpenLDAP backend and I started following > the instructions there. Despite the fact that http://www.h5l.org/manual I am not sure why. I guess you already discovered this, but the MIT KDC and the Heimdal KDC are very different beasts to administer. The instructions for one have no bearing on the other. > is dead(!) and no usefull documentation or any kind of a hint where to That was reported to their mailing list independently just today (http://permalink.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/7836) > find useful documentation for Heimdal can be found, many of the MIT > Kerberos V setup instructions seem to be a dead end when using Heimdal > on FreeBSD. Most of the links on that heimdal site ends up in ERROR 404! > > Well, I think my objective isn't that exotic in an more advanced server > environment and I think since FreeBSD is supposed to be used in > advanced server environments this task should be well known - but > little information/documentation is available. In my experience, most people getting into administering Kerberos KDCs do so by learning from someone else already doing so (usually in the same organization), so there are not always written documentation. In my (biased) opinion, the MIT documentation is pretty good; the upstream Heimdal documentation less so. > Nevertheless, I use the base system's heimdal implementation and I run > into a very frustrating error when trying to run "kamdin -l": > > kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so: > Cannot open "/usr/lib/hdb_ldap.so" > > The setup for the stanza [kdc] is > > [...] > [kdc] > database = { > dbname=ldap:ou=kerberos,dc=server,dc=gdr > #hdb-ldap-structural-object = inetOrgPerson > mkey_file = /var/heimdal/m-key > acl_file = /var/heimdal/kadmind.acl > } > > instructions taken from http://www.padl.com/Research/Heimdal.html. > > Well, it seems that FreeBSD ships with a crippled heimdal > implementation. Where is /usr/lib/hdb_ldap.so? You keep using this word "crippled", and I fail to understand why. It is functioning as intended. The FreeBSD base system ships with a limited set of tools, which allow many common server tasks to be performed, but certainly not all, and are not intended to fulfil all advanced server setups. The bundled Heimdal is there to provide the libraries and client utilities, which can be indispensable in many environments, and the KDC implementation is included because it can be useful in simple, small setups. If you need a more complicated Kerberos setup, you should be installing a KDC from ports, or arguably even building from source! The KDC in base functions suitably for the role it is intended to play; that is hardly "crippled". You probably noted that the base system now has dma, and sendmail is on its way out. Sendmail is a pretty big hammer, bigger than what is needed for use by the base system, and dma is more appropriate. The tools in the base system have a purpose, and they are not always suitable for everything in their appropriate area. > I'm toying around this issue for several days now and it gets more and > more frustrating, also with the perspective of having no running samba > 4.1 server for the windows domain. > > Can someone give me a hint where to find suitable FreeBSD docs for a > task like this? I guess since FreeBSD is considered a server OS more > than a desktop/toy OS, there must be a solution for this. FreeBSD ships > with heimdal in the base, but it seems this heimdal is broken. Again, don't use the heimdal from base if you need fancy features. (Are you even tied to Heimdal? If not, you already found the documentation for using LDAP as a backend for an MIT KDC...) >From your later message: > The lack of documentation is simply a mess. I excluded by intention the > port security/heimdal to proof whether FreeBSD is capable of handling a > common and very usual server task like the mentioned scenario. I cannot agree that your mentioned scenario is common and very usual. In my experience the majority of Unix standalone KDC deployments use the default (local) database backend, not an LDAP backend. (Fancy things like Samba, IPA, and AD are different, but they are also not in the domain of things in the base system!) > I overcame this problem by installing the port security/heimdal, but > now I run into the next problem which is highly intransparent: > > kadmin> init MY.REALM > kadmin: hdb_open: ldap_sasl_bind_s: Confidentiality required > > My LDAP server expects TLS authentication. I would expect a LDAP aware > client to llok for the proper informations > at /usr/local/openldap/ldap.conf. Obviously, Heimdal doesn't. Is there I'm not sure that I would. The LDAP database holding KDB information may not be the default LDAP database for the rest of the system (e.g., for nsswitch), and contains sensitive key data; having to specify additional configuration for it seems reasonable to me. I don't know if you followed the MIT documentation this far, but an MIT KDC needing to authenticate to bind to its LDAP server needs to have configuration for this in kdc.conf. > anything I've missed? Since I can not find any suitable documentation > (www.h5l.org/manual is dead!), I'm floating dead in the water. I don't know of any documentation for doing this with Heimdal, sorry. If you were using MIT Kerberos I could be more helpful. -Ben From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 22:39:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A90F5B49 for ; Thu, 30 Oct 2014 22:39:17 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18BF4CC7 for ; Thu, 30 Oct 2014 22:39:16 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id ge10so5323995lab.30 for ; Thu, 30 Oct 2014 15:39:15 -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=MctephqBcZ/PA4SryfcTTZaECbuLYRNfOYJi0KJeBDk=; b=A3vjo5X0mwrkpzy2tZblMGpA/krAlTfusKAXCEuHbzeWjk0ul9/2o7gjT+PcoLSqKz CvhUwpzRDnoFGaXUfVP/+mNwbz6jbDxzMu/5ILFYeZZR6UxGoHeZQiAR6gxgcj+UbdIG FCq0VFGt007EwZyT4jbF8BFeW3hep11EtQUFeOpEnpSMXkAN8pFAGeo4mhrFD5kMWn1n AoaFH25PHy0IHRdg2+07RzLmepsJZnx25coqCQVfADAuM/PSvlvGYUbphlLLooGwz94z h0r5LXz3IJArzzKLxG3q8IfDSsxnODXZe16gXJz7pn/qU829tTPKcGd36nItlEt3oWEB ZMgw== MIME-Version: 1.0 X-Received: by 10.152.18.166 with SMTP id x6mr21743838lad.18.1414708755018; Thu, 30 Oct 2014 15:39:15 -0700 (PDT) Received: by 10.25.21.219 with HTTP; Thu, 30 Oct 2014 15:39:14 -0700 (PDT) Received: by 10.25.21.219 with HTTP; Thu, 30 Oct 2014 15:39:14 -0700 (PDT) In-Reply-To: References: <20141030092039.47802349@prometheus> Date: Thu, 30 Oct 2014 23:39:14 +0100 Message-ID: Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so From: =?UTF-8?B?TMOhc3psw7MgTMOpdmFp?= To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 22:39:17 -0000 Today afternoon I deleted the Heimdal. I will start from begining with security/krb5 port. 2014.10.30. 21:52 ezt =C3=ADrta ("Benjamin Kaduk" ): > [stripping -questions; please don't cross-post] > > Disclaimer: I am part of the group that develops MIT Kerberos > > On Thu, 30 Oct 2014, O. Hartmann wrote: > > > Searching for suitable manuals, I found some HowTos describing how to > > setup MIT Kerberos V with an OpenLDAP backend and I started following > > the instructions there. Despite the fact that http://www.h5l.org/manual > > I am not sure why. I guess you already discovered this, but the MIT KDC > and the Heimdal KDC are very different beasts to administer. The > instructions for one have no bearing on the other. > > > is dead(!) and no usefull documentation or any kind of a hint where to > > That was reported to their mailing list independently just today > ( > http://permalink.gmane.org/gmane.comp.encryption.kerberos.heimdal.general= /7836 > ) > > > find useful documentation for Heimdal can be found, many of the MIT > > Kerberos V setup instructions seem to be a dead end when using Heimdal > > on FreeBSD. Most of the links on that heimdal site ends up in ERROR 404= ! > > > > Well, I think my objective isn't that exotic in an more advanced server > > environment and I think since FreeBSD is supposed to be used in > > advanced server environments this task should be well known - but > > little information/documentation is available. > > In my experience, most people getting into administering Kerberos KDCs do > so by learning from someone else already doing so (usually in the same > organization), so there are not always written documentation. In my > (biased) opinion, the MIT documentation is pretty good; the upstream > Heimdal documentation less so. > > > Nevertheless, I use the base system's heimdal implementation and I run > > into a very frustrating error when trying to run "kamdin -l": > > > > kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so: > > Cannot open "/usr/lib/hdb_ldap.so" > > > > The setup for the stanza [kdc] is > > > > [...] > > [kdc] > > database =3D { > > dbname=3Dldap:ou=3Dkerberos,dc=3Dserver,dc=3Dgdr > > #hdb-ldap-structural-object =3D inetOrgPerson > > mkey_file =3D /var/heimdal/m-key > > acl_file =3D /var/heimdal/kadmind.acl > > } > > > > instructions taken from http://www.padl.com/Research/Heimdal.html. > > > > Well, it seems that FreeBSD ships with a crippled heimdal > > implementation. Where is /usr/lib/hdb_ldap.so? > > You keep using this word "crippled", and I fail to understand why. It is > functioning as intended. The FreeBSD base system ships with a limited se= t > of tools, which allow many common server tasks to be performed, but > certainly not all, and are not intended to fulfil all advanced server > setups. The bundled Heimdal is there to provide the libraries and client > utilities, which can be indispensable in many environments, and the KDC > implementation is included because it can be useful in simple, small > setups. If you need a more complicated Kerberos setup, you should be > installing a KDC from ports, or arguably even building from source! The > KDC in base functions suitably for the role it is intended to play; that > is hardly "crippled". > > You probably noted that the base system now has dma, and sendmail is on > its way out. Sendmail is a pretty big hammer, bigger than what is needed > for use by the base system, and dma is more appropriate. The tools in th= e > base system have a purpose, and they are not always suitable for > everything in their appropriate area. > > > I'm toying around this issue for several days now and it gets more and > > more frustrating, also with the perspective of having no running samba > > 4.1 server for the windows domain. > > > > Can someone give me a hint where to find suitable FreeBSD docs for a > > task like this? I guess since FreeBSD is considered a server OS more > > than a desktop/toy OS, there must be a solution for this. FreeBSD ships > > with heimdal in the base, but it seems this heimdal is broken. > > Again, don't use the heimdal from base if you need fancy features. > > (Are you even tied to Heimdal? If not, you already found the > documentation for using LDAP as a backend for an MIT KDC...) > > > > From your later message: > > > The lack of documentation is simply a mess. I excluded by intention the > > port security/heimdal to proof whether FreeBSD is capable of handling a > > common and very usual server task like the mentioned scenario. > > I cannot agree that your mentioned scenario is common and very usual. In > my experience the majority of Unix standalone KDC deployments use the > default (local) database backend, not an LDAP backend. (Fancy things lik= e > Samba, IPA, and AD are different, but they are also not in the domain of > things in the base system!) > > > I overcame this problem by installing the port security/heimdal, but > > now I run into the next problem which is highly intransparent: > > > > kadmin> init MY.REALM > > kadmin: hdb_open: ldap_sasl_bind_s: Confidentiality required > > > > My LDAP server expects TLS authentication. I would expect a LDAP aware > > client to llok for the proper informations > > at /usr/local/openldap/ldap.conf. Obviously, Heimdal doesn't. Is there > > I'm not sure that I would. The LDAP database holding KDB information may > not be the default LDAP database for the rest of the system (e.g., for > nsswitch), and contains sensitive key data; having to specify additional > configuration for it seems reasonable to me. > > I don't know if you followed the MIT documentation this far, but an MIT > KDC needing to authenticate to bind to its LDAP server needs to > have configuration for this in kdc.conf. > > > anything I've missed? Since I can not find any suitable documentation > > (www.h5l.org/manual is dead!), I'm floating dead in the water. > > I don't know of any documentation for doing this with Heimdal, sorry. If > you were using MIT Kerberos I could be more helpful. > > -Ben > _______________________________________________ > 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 Thu Oct 30 22:57:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 481812EC for ; Thu, 30 Oct 2014 22:57:28 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 37E87E9D for ; Thu, 30 Oct 2014 22:57:28 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 612A73DB for ; Thu, 30 Oct 2014 22:57:28 +0000 (UTC) Date: Thu, 30 Oct 2014 22:57:27 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <215447019.12.1414709847984.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #156 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 30 Oct 2014 22:57:28 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#151 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson2656488593023017721.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/sc= ripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image= /FreeBSD_HEAD/test.img vm_test Consoles: userboot =20 FreeBSD/amd64 User boot, Revision 1.1 (rodrigc@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014) |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08Loading /boot/d= efaults/loader.conf=20 /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08=1B[H=1B[J=1B[7;46H ``` `=1B[8;46Hs`= `.....---.......--.``` -/=1B[9;46H+o .--` /y:` +.=1B[10;4= 6H yo`:. :o `+-=1B[11;46H y/ -/` -o/=1B[12= ;46H .- ::/sy+:.=1B[13;46H / `-- /=1B= [14;46H`: :`=1B[15;46H`: = :`=1B[16;46H / /=1B[17;46H .- = -.=1B[18;46H -- -.=1B[19;46H `:` = `:`=1B[20;46H .-- `--.=1B[21;46H .---.....----.=1B= [25;0H=1B[1;2H ______ ____ _____ _____ =1B[2;2H| ____| = | _ \ / ____| __ \ =1B[3;2H| |___ _ __ ___ ___ | |_) | (___ | = | | |=1B[4;2H| ___| '__/ _ \/ _ \| _ < \___ \| | | |=1B[5;2H| | | | |= __/ __/| |_) |____) | |__| |=1B[6;2H| | | | | | || | | = |=1B[7;2H|_| |_| \___|\___||____/|_____/|_____/ =1B[25;0H=1B[10;2H|= =1B[11;2H|=1B[12;2H|=1B[13;2H|=1B[14;2H|=1B[15;2H|=1B[16;2H|=1B[17;2H|=1B[1= 8;2H|=1B[19;2H|=1B[20;2H|=1B[21;2H|=1B[10;44H|=1B[11;44H|=1B[12;44H|=1B[13;= 44H|=1B[14;44H|=1B[15;44H|=1B[16;44H|=1B[17;44H|=1B[18;44H|=1B[19;44H|=1B[2= 0;44H|=1B[21;44H|=1B[9;3H-----------------------------------------=1B[22;3H= -----------------------------------------=1B[9;2H+=1B[22;2H+=1B[9;44H+=1B[2= 2;44H+=1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08=1B[9;15HWel= come to FreeBSD=1B[11;5H1 =1B[11;6H.=1B[11;8HBoot Multi User [Enter]=1B[12;= 5H2 =1B[12;6H.=1B[12;8HBoot [S]ingle User=1B[13;5H3 =1B[13;6H.=1B[13;8H[Esc= ]ape to loader prompt=1B[14;5H4 =1B[14;6H.=1B[14;8HReboot=1B[16;5HOptions:= =1B[17;5H5 =1B[17;6H.=1B[17;8H[K]ernel: kernel (1 of 2)=1B[18;5H6 =1B[18;6H= .=1B[18;8HConfigure Boot [O]ptions...=1B[25;0H=1B[23;4HAutoboot in 9 second= s. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 8 seconds. [Space] to paus= e=1B[25;0H=1B[23;4HAutoboot in 7 seconds. [Space] to pause=1B[25;0H=1B[23;4= HAutoboot in 6 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 5 sec= onds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 4 seconds. [Space] to p= ause=1B[25;0H=1B[23;4HAutoboot in 3 seconds. [Space] to pause=1B[25;0H=1B[2= 3;4HAutoboot in 2 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 1 = seconds. [Space] to pause=1B[25;0H=1B[23;4H = =1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/boot/kernel/kernel text=3D0x10031e8 /=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08data=3D0x12bec8+0x3d3e70 \=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08syms=3D[0x8+0x146778|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08+0x8+0x161c47\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08] Booting... |=08/=08-=08\=08|=08/=08-=08bhyve -c 2 -m 2G -AI -H -P -g 0 -s 0:0,hostbrid= ge -s 1:0,lpc -s 2:0,virtio-net,tap0,mac=3D58:9c:fc:00:00:2e -s 3:0,ahci-hd= ,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test= .img -l com1,stdio vm_test open of tap device /dev/tap0 failed GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =09The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1630: Thu Oct 30 22:40:43 UTC 2014 jenkins@jenkins-10.freebsd.org:/usr/obj/builds/FreeBSD_HEAD/sys/GENERIC= amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2399.76-MHz K8-class = CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c Steppi= ng=3D2 Features=3D0x9f83ab7f Features2=3D0x829e6257 AMD Features=3D0x24100800 AMD Features2=3D0x1 TSC: P-state invariant Hypervisor: Origin =3D "bhyve bhyve " real memory =3D 2147483648 (2048 MB) avail memory =3D 2040320000 (1945 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded/active; using insecure pseudo-random number genera= tor ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xffffffff80dae150, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor acpi0: on motherboard acpi0: Power Button (fixed) atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 10000000 Hz quality 950 Event timer "HPET" frequency 10000000 Hz quality 550 Event timer "HPET1" frequency 10000000 Hz quality 450 Event timer "HPET2" frequency 10000000 Hz quality 450 Event timer "HPET3" frequency 10000000 Hz quality 450 Event timer "HPET4" frequency 10000000 Hz quality 450 Event timer "HPET5" frequency 10000000 Hz quality 450 Event timer "HPET6" frequency 10000000 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 virtio_pci0: port 0x2000-0x201f mem 0xc0000000= -0xc0001fff irq 16 at device 2.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x1018020 virtio_pci0: negotiated features: 0x18020 vtnet0: Ethernet address: 58:9c:fc:00:00:2e ahci0: mem 0xc0002000-0xc00023ff irq 17 a= t device 3.0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard sc0: at flags 0x100 on isa0 sc0: MDA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3b0-0x3bb iomem 0xb0000-0xb7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 123456 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2048MB (4194304 512 byte sectors: 16H 63S/T 4161C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/TESTROOT [rw]... Setting hostuuid: 0da987e7-6088-11e4-b666-589cfc00002e. Setting hostid: 0xf30fc39d. No suitable dump device was found. Starting file system checks: /dev/ufs/TESTROOT: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/TESTROOT: clean, 1052636 free (500 frags, 131517 blocks, 0.0% frag= mentation) Mounting local file systems:. Writing entropy file:Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 146, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 110, in runTest child2.expect(['login:']) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P',= u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,vir= tio-net,tap0,mac=3D58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10= .freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'= com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): '(500 frags, 131517 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' before (last 100 chars): '(500 frags, 131517 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' after: match: None match_index: None exitstatus: None flag_eof: False pid: 85937 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x80066d150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 00:42:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BAFD45B for ; Fri, 31 Oct 2014 00:42:17 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B94EDAF2 for ; Fri, 31 Oct 2014 00:42:16 +0000 (UTC) X-AuditID: 1209190d-f79c06d000006f95-9e-5452d9b4c520 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.75.28565.4B9D2545; Thu, 30 Oct 2014 20:37:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9V0b7sp031354; Thu, 30 Oct 2014 20:37:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9V0b5Bh022952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 20:37:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9V0b5t6020304; Thu, 30 Oct 2014 20:37:05 -0400 (EDT) Date: Thu, 30 Oct 2014 20:37:05 -0400 (EDT) From: Benjamin Kaduk To: =?ISO-8859-15?Q?L=E1szl=F3_L=E9vai?= Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so In-Reply-To: Message-ID: References: <20141030092039.47802349@prometheus> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6norvlZlCIwaF2XYs5bz4wWZxa84jd 4u+sP0wOzB4zPs1n8dg56y67x6ntBxkDmKO4bFJSczLLUov07RK4Mm4fjizYx1pxreU5awPj KZYuRk4OCQETid0nX7JD2GISF+6tZ+ti5OIQEpjNJLF90UYmCGcjo8SGywtZIZxDTBLvD/+F choYJbZfOckI0s8ioC3xdfMVVhCbTUBFYuabjWwgtoiAq8Sas2uZQGxmgXSJOUdPMYPYwgJ+ Eqv2nQfbzSkQKLF2xiewGl4BR4npp3eB9QoJrGaUOPo7BcQWFdCRWL1/CgtEjaDEyZlPWCBm Bkrcv/CdcQKj4CwkqVlIUhC2usSBTxehbG2J+zfb2BYwsqxilE3JrdLNTczMKU5N1i1OTszL Sy3SNdLLzSzRS00p3cQICndOSd4djO8OKh1iFOBgVOLhXXA8KESINbGsuDL3EKMkB5OSKO+m G0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxT9gHleFMSK6tSi/JhUtIcLErivJt+8IUICaQn lqRmp6YWpBbBZGU4OJQkeNNAhgoWpaanVqRl5pQgpJk4OEGG8wANnwpSw1tckJhbnJkOkT/F qMvR0vS2l0mIJS8/L1VKnDcQpEgApCijNA9uDixNvWIUB3pLmLcCpIoHmOLgJr0CWsIEtOTz 1ACQJSWJCCmpBsYAlrs3nneL124Wf2X81if46TWzhA2Bn3XeT3aO3S4cbNI2sWTn92clGz02 yFrk3YtwPKV8g3HDG39zp0MLrnJaautZdq0Rnn00s8nYdOXcRHNGhh83WLhVpNL99I2mt5pu NP41oaGfl62i+PtxJ/XWNW4ue2/d2bZK3lxmO8NDaW+DbdJ1ckosxRmJhlrMRcWJAIGcSgEu AwAA Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 00:42:17 -0000 On Thu, 30 Oct 2014, L=C3=A1szl=C3=B3 L=C3=A9vai wrote: > Today afternoon I deleted the Heimdal. I will start from begining with > security/krb5 port. You probably want to make sure that /usr/local/bin and /usr/local/sbin are at the front of the PATH of the processes in question, so that the tools from the base system don't intrude and cause confusion. -Ben From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 01:55:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05FADF5 for ; Fri, 31 Oct 2014 01:55:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E534117F for ; Fri, 31 Oct 2014 01:55:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CCC11406 for ; Fri, 31 Oct 2014 01:55:19 +0000 (UTC) Date: Fri, 31 Oct 2014 01:55:19 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1567132259.13.1414720519766.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <215447019.12.1414709847984.JavaMail.jenkins@jenkins-9.freebsd.org> References: <215447019.12.1414709847984.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #157 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 01:55:20 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#152 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson473372950067480802.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/sc= ripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image= /FreeBSD_HEAD/test.img vm_test Consoles: userboot =20 FreeBSD/amd64 User boot, Revision 1.1 (rodrigc@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014) |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08Loading /boot/d= efaults/loader.conf=20 /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08=1B[H=1B[J=1B[7;46H ``` `=1B[8;46Hs`= `.....---.......--.``` -/=1B[9;46H+o .--` /y:` +.=1B[10;4= 6H yo`:. :o `+-=1B[11;46H y/ -/` -o/=1B[12= ;46H .- ::/sy+:.=1B[13;46H / `-- /=1B= [14;46H`: :`=1B[15;46H`: = :`=1B[16;46H / /=1B[17;46H .- = -.=1B[18;46H -- -.=1B[19;46H `:` = `:`=1B[20;46H .-- `--.=1B[21;46H .---.....----.=1B= [25;0H=1B[1;2H ______ ____ _____ _____ =1B[2;2H| ____| = | _ \ / ____| __ \ =1B[3;2H| |___ _ __ ___ ___ | |_) | (___ | = | | |=1B[4;2H| ___| '__/ _ \/ _ \| _ < \___ \| | | |=1B[5;2H| | | | |= __/ __/| |_) |____) | |__| |=1B[6;2H| | | | | | || | | = |=1B[7;2H|_| |_| \___|\___||____/|_____/|_____/ =1B[25;0H=1B[10;2H|= =1B[11;2H|=1B[12;2H|=1B[13;2H|=1B[14;2H|=1B[15;2H|=1B[16;2H|=1B[17;2H|=1B[1= 8;2H|=1B[19;2H|=1B[20;2H|=1B[21;2H|=1B[10;44H|=1B[11;44H|=1B[12;44H|=1B[13;= 44H|=1B[14;44H|=1B[15;44H|=1B[16;44H|=1B[17;44H|=1B[18;44H|=1B[19;44H|=1B[2= 0;44H|=1B[21;44H|=1B[9;3H-----------------------------------------=1B[22;3H= -----------------------------------------=1B[9;2H+=1B[22;2H+=1B[9;44H+=1B[2= 2;44H+=1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08=1B[9;15HWel= come to FreeBSD=1B[11;5H1 =1B[11;6H.=1B[11;8HBoot Multi User [Enter]=1B[12;= 5H2 =1B[12;6H.=1B[12;8HBoot [S]ingle User=1B[13;5H3 =1B[13;6H.=1B[13;8H[Esc= ]ape to loader prompt=1B[14;5H4 =1B[14;6H.=1B[14;8HReboot=1B[16;5HOptions:= =1B[17;5H5 =1B[17;6H.=1B[17;8H[K]ernel: kernel (1 of 2)=1B[18;5H6 =1B[18;6H= .=1B[18;8HConfigure Boot [O]ptions...=1B[25;0H=1B[23;4HAutoboot in 9 second= s. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 8 seconds. [Space] to paus= e=1B[25;0H=1B[23;4HAutoboot in 7 seconds. [Space] to pause=1B[25;0H=1B[23;4= HAutoboot in 6 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 5 sec= onds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 4 seconds. [Space] to p= ause=1B[25;0H=1B[23;4HAutoboot in 3 seconds. [Space] to pause=1B[25;0H=1B[2= 3;4HAutoboot in 2 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 1 = seconds. [Space] to pause=1B[25;0H=1B[23;4H = =1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08/boot/kernel/kernel text=3D0x10031e8 |=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08data=3D0x12bec8+0x3d3e70 -= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08syms=3D[0x8+0x146778\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08+0x8+0x161c47-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08] Booting... \=08|=08/=08-=08\=08|=08/=08bhyve -c 2 -m 2G -AI -H -P -g 0 -s 0:0,hostbrid= ge -s 1:0,lpc -s 2:0,virtio-net,tap0,mac=3D58:9c:fc:00:00:2e -s 3:0,ahci-hd= ,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test= .img -l com1,stdio vm_test open of tap device /dev/tap0 failed GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =09The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1631: Fri Oct 31 01:39:53 UTC 2014 jenkins@jenkins-10.freebsd.org:/usr/obj/builds/FreeBSD_HEAD/sys/GENERIC= amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2399.76-MHz K8-class = CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c Steppi= ng=3D2 Features=3D0x9f83ab7f Features2=3D0x829e6257 AMD Features=3D0x24100800 AMD Features2=3D0x1 TSC: P-state invariant Hypervisor: Origin =3D "bhyve bhyve " real memory =3D 2147483648 (2048 MB) avail memory =3D 2040287232 (1945 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded/active; using insecure pseudo-random number genera= tor ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xffffffff80dae150, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor acpi0: on motherboard acpi0: Power Button (fixed) atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 10000000 Hz quality 950 Event timer "HPET" frequency 10000000 Hz quality 550 Event timer "HPET1" frequency 10000000 Hz quality 450 Event timer "HPET2" frequency 10000000 Hz quality 450 Event timer "HPET3" frequency 10000000 Hz quality 450 Event timer "HPET4" frequency 10000000 Hz quality 450 Event timer "HPET5" frequency 10000000 Hz quality 450 Event timer "HPET6" frequency 10000000 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 virtio_pci0: port 0x2000-0x201f mem 0xc0000000= -0xc0001fff irq 16 at device 2.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x1018020 virtio_pci0: negotiated features: 0x18020 vtnet0: Ethernet address: 58:9c:fc:00:00:2e ahci0: mem 0xc0002000-0xc00023ff irq 17 a= t device 3.0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard sc0: at flags 0x100 on isa0 sc0: MDA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3b0-0x3bb iomem 0xb0000-0xb7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 123456 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2048MB (4194304 512 byte sectors: 16H 63S/T 4161C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/TESTROOT [rw]... Setting hostuuid: e6980d7e-60a0-11e4-aea4-589cfc00002e. Setting hostid: 0xa7ac7c7c. No suitable dump device was found. Starting file system checks: /dev/ufs/TESTROOT: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/TESTROOT: clean, 1052636 free (476 frags, 131520 blocks, 0.0% frag= mentation) Mounting local file systems:. Writing entropy file:Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 146, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 110, in runTest child2.expect(['login:']) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P',= u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,vir= tio-net,tap0,mac=3D58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10= .freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'= com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): '(476 frags, 131520 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' before (last 100 chars): '(476 frags, 131520 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' after: match: None match_index: None exitstatus: None flag_eof: False pid: 188 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x80066d150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 03:16:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0923BC1 for ; Fri, 31 Oct 2014 03:16:50 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6158B1E for ; Fri, 31 Oct 2014 03:16:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=ToW4+TNDu3NH8UNczDnDEJ6lDfYzn5Ls9xe4BMuIiF4=; b=PrM5f7zKKUj/nG6vSaD02wDMyl5Qw2jHtIe1t2BAHH3QpZAQEZGqfoS2mFGvyZ29m5bmFvXjspbSru4wmaxwhKaNuTGHW/nyTgFzrf8tmlsURxS2mIQwFLW1+6sx0R17pvvG7k56fwqkcNVDzMTpW7UmnMtFcYU4jFYrNRG+9mM=; Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]:41298 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xk2hj-0000PK-As for freebsd-current@freebsd.org; Thu, 30 Oct 2014 22:16:49 -0500 Date: Thu, 30 Oct 2014 22:16:35 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: VT: NOT giving extended console Message-ID: <20141031031635.GA857@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 03:16:51 -0000 Upgraded to: FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r273876: Thu Oct 30 21:44:26 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 and do NOT get the big VT console. Dmesg.boot: Copyright (c) 1992-2014 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 11.0-CURRENT #4 r273876: Thu Oct 30 21:44:26 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". link_elf_obj: symbol ttm_agp_tt_create undefined KLD file radeonkms.ko - could not finalize loading info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 VT-x: HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65626714112 (62586 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xffffffff80eb3180, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 uhci0: LegSup = 0x3000 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 coretemp4: on cpu4 est4: on cpu4 coretemp5: on cpu5 est5: on cpu5 coretemp6: on cpu6 est6: on cpu6 coretemp7: on cpu7 est7: on cpu7 usbus0: 12Mbps Full Speed USB v1.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x444 offMax=0x63c hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub3: on usbus3 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 uhub_attach: Turning port 1 power on ata0: DMA limited to UDMA33, controller found non-ATA66 cable uhub_attach: Turning port 1 power on uhub_attach: Turning port 1 power on ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub_attach: Turning port 2 power on uhub_attach: Turning port 2 power on uhub_attach: Turning port 2 power on uhub_attach: Turning port 1 power on uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 uhub_attach: Turning port 2 power on ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #5 Launched! cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present uhub_attach: Turning port 3 power on uhub_attach: Turning port 4 power on uhub_attach: Turning port 5 power on uhub_attach: Turning port 6 power on uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen0.3: at usbus0 random: unblocking device. uhid0: on usbus3 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=0 Upgraded from: r273693 Ideas? (maybe the new Random stuff?) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 05:11:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F48D8A7; Fri, 31 Oct 2014 05:11:08 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8A776BC; Fri, 31 Oct 2014 05:11:07 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-232.lns20.per1.internode.on.net [121.45.229.232]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9V4rF7J007887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 30 Oct 2014 21:53:18 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <545315B5.503@freebsd.org> Date: Fri, 31 Oct 2014 12:53:09 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Garance A Drosehn , Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030062026.GC8852@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 05:11:08 -0000 On 10/31/14, 1:41 AM, Garance A Drosehn wrote: > On 30 Oct 2014, at 12:49, Ed Maste wrote: > >> On 30 October 2014 02:20, John-Mark Gurney wrote: >>> Oh, make sure that make install (or installkernel) properly handles >>> moving the debug data too... i.e. kernel to kernel.old... >> Yes, in the case that /boot/kernel is moved to /boot/kernel.old >> /usr/lib/debug/boot/kernel is moved to /usr/lib/debug/boot/kernel.old. > I definitely like the idea of moving the debug symbols out to /usr/lib/debug > > I'm another person who sometimes has multiple kernels sitting in /boot > (which is one reason I'd like the debug symbols elsewhere!). I may > shuffle those around by hand, and I'm sure I won't remember to shuffle > around information under /usr/lib/debug. I also do things like > cp -rp kernel kernel-PreBigChange > where I save away a copy of the kernel for possible fallback (at some > unknown future date), but I wouldn't need two copies of the debug info. > > When we build a kernel, could we tag it with some unique-ID (by putting > that ID in a plain-text file inside the kernel's directory), and then > that unique-ID could be used for finding the correct debug info under > /usr/lib/debug? This way we wouldn't need to move around any of the > debug info under /usr/lib/debug. And we could tell which sets of > debug info should be removed by comparing the existing sets of debug > info with the kernel-unique-ID's which still exist under /boot. I'd put the debug symbls somewhere with a unique name and than add a symlink from the installed directory.. (and an ID file) So /boot/kernel.old/symbols points to /usr/lib/debug/kernelsymbols.20141031,1250 when you move the directory back to /boot/kernel, it STILL points to the right place.. occasionally remove all directories in /usr/lib/debug/kernelsymbols.* that are not pointed to by a symlink in /boot/*/symbols. An option could make the symlink relative for chroot/jail/nfs issues.. > > If debug tools need to have the debug-info for the booted kernel to > be in a fixed location, then maybe the boot-up process could create > a symlink from some fixed pathname to the correct debug info for the > kernel which the system booted up on. > From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 08:35:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17F0191F for ; Fri, 31 Oct 2014 08:35:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 05628C88 for ; Fri, 31 Oct 2014 08:35:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 250214AB for ; Fri, 31 Oct 2014 08:35:04 +0000 (UTC) Date: Fri, 31 Oct 2014 08:35:04 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <2042370439.15.1414744504116.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1567132259.13.1414720519766.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1567132259.13.1414720519766.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #158 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 08:35:04 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#153 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson4396968245292862072.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/sc= ripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image= /FreeBSD_HEAD/test.img vm_test Consoles: userboot =20 FreeBSD/amd64 User boot, Revision 1.1 (rodrigc@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014) |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08Loading /boot/d= efaults/loader.conf=20 /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08=1B[H=1B[J=1B[7;46H ``` `=1B[8;46Hs`= `.....---.......--.``` -/=1B[9;46H+o .--` /y:` +.=1B[10;4= 6H yo`:. :o `+-=1B[11;46H y/ -/` -o/=1B[12= ;46H .- ::/sy+:.=1B[13;46H / `-- /=1B= [14;46H`: :`=1B[15;46H`: = :`=1B[16;46H / /=1B[17;46H .- = -.=1B[18;46H -- -.=1B[19;46H `:` = `:`=1B[20;46H .-- `--.=1B[21;46H .---.....----.=1B= [25;0H=1B[1;2H ______ ____ _____ _____ =1B[2;2H| ____| = | _ \ / ____| __ \ =1B[3;2H| |___ _ __ ___ ___ | |_) | (___ | = | | |=1B[4;2H| ___| '__/ _ \/ _ \| _ < \___ \| | | |=1B[5;2H| | | | |= __/ __/| |_) |____) | |__| |=1B[6;2H| | | | | | || | | = |=1B[7;2H|_| |_| \___|\___||____/|_____/|_____/ =1B[25;0H=1B[10;2H|= =1B[11;2H|=1B[12;2H|=1B[13;2H|=1B[14;2H|=1B[15;2H|=1B[16;2H|=1B[17;2H|=1B[1= 8;2H|=1B[19;2H|=1B[20;2H|=1B[21;2H|=1B[10;44H|=1B[11;44H|=1B[12;44H|=1B[13;= 44H|=1B[14;44H|=1B[15;44H|=1B[16;44H|=1B[17;44H|=1B[18;44H|=1B[19;44H|=1B[2= 0;44H|=1B[21;44H|=1B[9;3H-----------------------------------------=1B[22;3H= -----------------------------------------=1B[9;2H+=1B[22;2H+=1B[9;44H+=1B[2= 2;44H+=1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08=1B[9;15HWel= come to FreeBSD=1B[11;5H1 =1B[11;6H.=1B[11;8HBoot Multi User [Enter]=1B[12;= 5H2 =1B[12;6H.=1B[12;8HBoot [S]ingle User=1B[13;5H3 =1B[13;6H.=1B[13;8H[Esc= ]ape to loader prompt=1B[14;5H4 =1B[14;6H.=1B[14;8HReboot=1B[16;5HOptions:= =1B[17;5H5 =1B[17;6H.=1B[17;8H[K]ernel: kernel (1 of 2)=1B[18;5H6 =1B[18;6H= .=1B[18;8HConfigure Boot [O]ptions...=1B[25;0H=1B[23;4HAutoboot in 9 second= s. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 8 seconds. [Space] to paus= e=1B[25;0H=1B[23;4HAutoboot in 7 seconds. [Space] to pause=1B[25;0H=1B[23;4= HAutoboot in 6 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 5 sec= onds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 4 seconds. [Space] to p= ause=1B[25;0H=1B[23;4HAutoboot in 3 seconds. [Space] to pause=1B[25;0H=1B[2= 3;4HAutoboot in 2 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 1 = seconds. [Space] to pause=1B[25;0H=1B[23;4H = =1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08/boot/kernel/kernel text=3D0x10031e8 \=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08data=3D0x12bec8+0x3d3e70 /=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08syms=3D[0x8+0x146778-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08+0x8+0x161c47/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08] Booting... -=08\=08|=08/=08-=08\=08|=08bhyve -c 2 -m 2G -AI -H -P -g 0 -s 0:0,hostbrid= ge -s 1:0,lpc -s 2:0,virtio-net,tap0,mac=3D58:9c:fc:00:00:2e -s 3:0,ahci-hd= ,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test= .img -l com1,stdio vm_test open of tap device /dev/tap0 failed GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =09The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1632: Fri Oct 31 08:20:41 UTC 2014 jenkins@jenkins-10.freebsd.org:/usr/obj/builds/FreeBSD_HEAD/sys/GENERIC= amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2399.77-MHz K8-class = CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c Steppi= ng=3D2 Features=3D0x9f83ab7f Features2=3D0x829e6257 AMD Features=3D0x24100800 AMD Features2=3D0x1 TSC: P-state invariant Hypervisor: Origin =3D "bhyve bhyve " real memory =3D 2147483648 (2048 MB) avail memory =3D 2040287232 (1945 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded/active; using insecure pseudo-random number genera= tor ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xffffffff80dae150, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor acpi0: on motherboard acpi0: Power Button (fixed) atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 10000000 Hz quality 950 Event timer "HPET" frequency 10000000 Hz quality 550 Event timer "HPET1" frequency 10000000 Hz quality 450 Event timer "HPET2" frequency 10000000 Hz quality 450 Event timer "HPET3" frequency 10000000 Hz quality 450 Event timer "HPET4" frequency 10000000 Hz quality 450 Event timer "HPET5" frequency 10000000 Hz quality 450 Event timer "HPET6" frequency 10000000 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 virtio_pci0: port 0x2000-0x201f mem 0xc0000000= -0xc0001fff irq 16 at device 2.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x1018020 virtio_pci0: negotiated features: 0x18020 vtnet0: Ethernet address: 58:9c:fc:00:00:2e ahci0: mem 0xc0002000-0xc00023ff irq 17 a= t device 3.0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard sc0: at flags 0x100 on isa0 sc0: MDA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3b0-0x3bb iomem 0xb0000-0xb7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 123456 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2048MB (4194304 512 byte sectors: 16H 63S/T 4161C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/TESTROOT [rw]... Setting hostuuid: be2f5d67-60d8-11e4-a8c3-589cfc00002e. Setting hostid: 0x0bd20e63. No suitable dump device was found. Starting file system checks: /dev/ufs/TESTROOT: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/TESTROOT: clean, 1052636 free (812 frags, 131478 blocks, 0.0% frag= mentation) Mounting local file systems:. Writing entropy file:Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 146, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 110, in runTest child2.expect(['login:']) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P',= u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,vir= tio-net,tap0,mac=3D58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10= .freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'= com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): '(812 frags, 131478 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' before (last 100 chars): '(812 frags, 131478 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' after: match: None match_index: None exitstatus: None flag_eof: False pid: 25340 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x80066d150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 10:35:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE2B9E8D; Fri, 31 Oct 2014 10:35:06 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9122DC4F; Fri, 31 Oct 2014 10:35:06 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xk9Xs-000Okc-EV; Fri, 31 Oct 2014 11:35:04 +0100 Message-ID: <545365D4.4030407@dumbbell.fr> Date: Fri, 31 Oct 2014 11:35:00 +0100 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: VT: NOT giving extended console References: <20141031031635.GA857@borg.lerctr.org> In-Reply-To: <20141031031635.GA857@borg.lerctr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l70LcawfwgBhNvUdvMRFIereXEIheiQSt" Cc: Tijl Coosemans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 10:35:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l70LcawfwgBhNvUdvMRFIereXEIheiQSt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 31.10.2014 04:16, Larry Rosenman wrote: > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #4 r273876: Thu Oct 30 21:44:26 CDT 2014 > root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 2014051= 2 > VT: running with driver "vga". > link_elf_obj: symbol ttm_agp_tt_create undefined > KLD file radeonkms.ko - could not finalize loading Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of the drm2 module. I'll connect it as soon as svn up is finished, except if Tijl beats me to it :) --=20 Jean-S=E9bastien P=E9dron --l70LcawfwgBhNvUdvMRFIereXEIheiQSt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUU2XYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMMn8QAKfO6OtpFhkrmdINkhO3ldxN VmJDIbN2emnEhu5y68SM/+ssiBQwjLO6dvVOGooGb55Iz6esoRx+zjtO52DC9uO0 axlv6dtyhsMBdyq9HbYBtC3HNkCbirO2BOBg6HT/BuagDq1Ns5URmhMBZPSxG88l Rq3mOpwHJVILaSu98XL9k0DAsVBrzJdHl54FnUN3ZNCSbdmJ1TA41E5A3807xEMn 1XMvhn4fzEX4e8hP6aP0zmdFHbqUoe7w07zegR/6aWGGH/G+lN+JQAyVFASLCGyH YzOJ+k5070fdUwt9aYIx5S+SiJrAPBvopatmYgnnCJecBnWGKKZchd5CxxmfaytK Pf5WS2ea+dOfl9/rw86493aoqdh6rRdg12Fd1iRK6hXqSKGepJivHVEErJNQyC2E rWJGq+PrpmdQ5Raaa9PuLmFH7f+DCBhPVWBfwDg4nQXSn+Znpiio8ubuNy6tljHS HWrE5cRApfsqX1hoIVCscCaVf/1p2wOc0Hme+Os9gj5ZedVyccapIa+AISb6idyW Km+bobP9zX5MhC3CtHpD+dz4AKaUi8ePuw6NT/ut6+DIx44Mm15DJpk6XZtNEjRt /PxocPMzkzBId8fjtPcxyFW+LPbFxRCqAlEk4pJrB/0x9w5NXN2KrvkBi8KDR9Cf BMZmcrSrDbQI9Tgk1cr5 =ew3O -----END PGP SIGNATURE----- --l70LcawfwgBhNvUdvMRFIereXEIheiQSt-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 10:46:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8717171A for ; Fri, 31 Oct 2014 10:46:27 +0000 (UTC) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id 21DE7D93 for ; Fri, 31 Oct 2014 10:46:26 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYGAERnU1RR8nxA/2dsb2JhbABcgw6BLNRlAoEaFwEBAQEBfYQDAQEEViMQCxgJJQ8qHgYTiEUByVABAQEBAQUBAQEBHpBdMweESwWRbIwLlkmDeTwvgksBAQE Received: from 64.124-242-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.242.124.64]) by relay.skynet.be with ESMTP; 31 Oct 2014 11:46:18 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.9/8.14.9) with ESMTP id s9VAkHGE001662; Fri, 31 Oct 2014 11:46:17 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Fri, 31 Oct 2014 11:46:17 +0100 From: Tijl Coosemans To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: VT: NOT giving extended console Message-ID: <20141031114617.492e2c01@kalimero.tijl.coosemans.org> In-Reply-To: <545365D4.4030407@dumbbell.fr> References: <20141031031635.GA857@borg.lerctr.org> <545365D4.4030407@dumbbell.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 10:46:27 -0000 On Fri, 31 Oct 2014 11:35:00 +0100 Jean-S=E9bastien P=E9dron wrote: > On 31.10.2014 04:16, Larry Rosenman wrote: >> Copyright (c) 1992-2014 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 11.0-CURRENT #4 r273876: Thu Oct 30 21:44:26 CDT 2014 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >> VT: running with driver "vga". >> link_elf_obj: symbol ttm_agp_tt_create undefined >> KLD file radeonkms.ko - could not finalize loading >=20 > Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of > the drm2 module. >=20 > I'll connect it as soon as svn up is finished, except if Tijl beats me > to it :) =20 Done in r273902. From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 10:48:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CB3191E for ; Fri, 31 Oct 2014 10:48:09 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E38ADB2 for ; Fri, 31 Oct 2014 10:48:09 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xk9kV-000Otc-HK for freebsd-current@freebsd.org; Fri, 31 Oct 2014 11:48:07 +0100 Message-ID: <545368E3.2000208@dumbbell.fr> Date: Fri, 31 Oct 2014 11:48:03 +0100 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: VT: NOT giving extended console References: <20141031031635.GA857@borg.lerctr.org> <545365D4.4030407@dumbbell.fr> <20141031114617.492e2c01@kalimero.tijl.coosemans.org> In-Reply-To: <20141031114617.492e2c01@kalimero.tijl.coosemans.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5m1CCc0U7PxgmMDPODo5m87TU1oQQXX6f" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 10:48:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5m1CCc0U7PxgmMDPODo5m87TU1oQQXX6f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 31.10.2014 11:46, Tijl Coosemans wrote: >> Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build o= f >> the drm2 module. >> >> I'll connect it as soon as svn up is finished, except if Tijl beats me= >> to it :) > =20 > Done in r273902. Thanks :) And thank you very much for adding AGP support! --=20 Jean-S=E9bastien P=E9dron --5m1CCc0U7PxgmMDPODo5m87TU1oQQXX6f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUU2jnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMXi4QAI42bGldx20OBQDzekFen0mI g8BGLR1sg5xpodL+xFBY8nTWGTiVBvn03SMStnDdsbErrmLxaqEdA6i8c35r7XtM Bc7PApanYpNf0N1CFSoa4uiXm0S/bxEIOfNmUPhD+EOWpuftA12hL5Q+wboIujB4 +diKVpSwnwNRt0xGF8g0Ujrvg1nxPvqloI0EyBOEwFrJSkaSXyQyelCVGwq664I2 1rO0nUVmaxgZ/OBHm0/zte0HfL84YWfw8XRY8iNk/qoGVv6wqUZSt30C6oQ2q7bu BvFT9XNI+4jbA9c1XuHpJvXHC7/1wwPYvDDXe0ncpXOpJT8LsnvEDN1qhx965uaQ D1LtJGx5s0HAmHsfU/0ftjiJIZqbwniX6yMqgiNPkmXr7d+XuoEJ6na5xCx6WJ3c oGYU5LzDX1RXKl4bDswzmBmbD7DE89u+jRSMCblV3fCff7tSuVv1PsCdVXKvifYv uQdc2pIAI7ogxnOqOFB9BErC8UdjQOQfHDL1GQUeHd7xqyZgUZ6pz3a1J1iJAeEG 3sx6hVJpktaNTIfGw8VZRNyrH0TP+DGW2PVrnTQPr3WcJ419jSIItKW6amBg1LW6 ccEjElYn2pvl+xQjoWfEVYtFfbHjG6bLluYlY1kB3+BEUk67Z5XsHFiSjuRDu74W KzL6BdCzY2JKrsRoNRXX =Bys1 -----END PGP SIGNATURE----- --5m1CCc0U7PxgmMDPODo5m87TU1oQQXX6f-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 11:37:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39BD07A4 for ; Fri, 31 Oct 2014 11:37:03 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 27879354 for ; Fri, 31 Oct 2014 11:37:03 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 020904EC for ; Fri, 31 Oct 2014 11:37:02 +0000 (UTC) Date: Fri, 31 Oct 2014 11:37:02 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <162415044.17.1414755422765.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2042370439.15.1414744504116.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2042370439.15.1414744504116.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #159 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 11:37:03 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#154 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson6275656759345592008.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/sc= ripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image= /FreeBSD_HEAD/test.img vm_test Consoles: userboot =20 FreeBSD/amd64 User boot, Revision 1.1 (rodrigc@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014) |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08Loading /boot/d= efaults/loader.conf=20 /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08=1B[H=1B[J=1B[7;46H ``` `=1B[8;46Hs`= `.....---.......--.``` -/=1B[9;46H+o .--` /y:` +.=1B[10;4= 6H yo`:. :o `+-=1B[11;46H y/ -/` -o/=1B[12= ;46H .- ::/sy+:.=1B[13;46H / `-- /=1B= [14;46H`: :`=1B[15;46H`: = :`=1B[16;46H / /=1B[17;46H .- = -.=1B[18;46H -- -.=1B[19;46H `:` = `:`=1B[20;46H .-- `--.=1B[21;46H .---.....----.=1B= [25;0H=1B[1;2H ______ ____ _____ _____ =1B[2;2H| ____| = | _ \ / ____| __ \ =1B[3;2H| |___ _ __ ___ ___ | |_) | (___ | = | | |=1B[4;2H| ___| '__/ _ \/ _ \| _ < \___ \| | | |=1B[5;2H| | | | |= __/ __/| |_) |____) | |__| |=1B[6;2H| | | | | | || | | = |=1B[7;2H|_| |_| \___|\___||____/|_____/|_____/ =1B[25;0H=1B[10;2H|= =1B[11;2H|=1B[12;2H|=1B[13;2H|=1B[14;2H|=1B[15;2H|=1B[16;2H|=1B[17;2H|=1B[1= 8;2H|=1B[19;2H|=1B[20;2H|=1B[21;2H|=1B[10;44H|=1B[11;44H|=1B[12;44H|=1B[13;= 44H|=1B[14;44H|=1B[15;44H|=1B[16;44H|=1B[17;44H|=1B[18;44H|=1B[19;44H|=1B[2= 0;44H|=1B[21;44H|=1B[9;3H-----------------------------------------=1B[22;3H= -----------------------------------------=1B[9;2H+=1B[22;2H+=1B[9;44H+=1B[2= 2;44H+=1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08=1B[9;15HWel= come to FreeBSD=1B[11;5H1 =1B[11;6H.=1B[11;8HBoot Multi User [Enter]=1B[12;= 5H2 =1B[12;6H.=1B[12;8HBoot [S]ingle User=1B[13;5H3 =1B[13;6H.=1B[13;8H[Esc= ]ape to loader prompt=1B[14;5H4 =1B[14;6H.=1B[14;8HReboot=1B[16;5HOptions:= =1B[17;5H5 =1B[17;6H.=1B[17;8H[K]ernel: kernel (1 of 2)=1B[18;5H6 =1B[18;6H= .=1B[18;8HConfigure Boot [O]ptions...=1B[25;0H=1B[23;4HAutoboot in 9 second= s. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 8 seconds. [Space] to paus= e=1B[25;0H=1B[23;4HAutoboot in 7 seconds. [Space] to pause=1B[25;0H=1B[23;4= HAutoboot in 6 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 5 sec= onds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 4 seconds. [Space] to p= ause=1B[25;0H=1B[23;4HAutoboot in 3 seconds. [Space] to pause=1B[25;0H=1B[2= 3;4HAutoboot in 2 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 1 = seconds. [Space] to pause=1B[25;0H=1B[23;4H = =1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= /boot/kernel/kernel text=3D0x10031e8 -=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08data=3D0x12bec8+0x3d3e70 |=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08syms=3D= [0x8+0x146760/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08+0x= 8+0x161c40|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08] Booting... /=08-=08\=08|=08/=08-=08\=08bhyve -c 2 -m 2G -AI -H -P -g 0 -s 0:0,hostbrid= ge -s 1:0,lpc -s 2:0,virtio-net,tap0,mac=3D58:9c:fc:00:00:2e -s 3:0,ahci-hd= ,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test= .img -l com1,stdio vm_test open of tap device /dev/tap0 failed GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =09The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1633: Fri Oct 31 11:21:15 UTC 2014 jenkins@jenkins-10.freebsd.org:/usr/obj/builds/FreeBSD_HEAD/sys/GENERIC= amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2399.76-MHz K8-class = CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c Steppi= ng=3D2 Features=3D0x9f83ab7f Features2=3D0x829e6257 AMD Features=3D0x24100800 AMD Features2=3D0x1 TSC: P-state invariant Hypervisor: Origin =3D "bhyve bhyve " real memory =3D 2147483648 (2048 MB) avail memory =3D 2040287232 (1945 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded/active; using insecure pseudo-random number genera= tor ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xffffffff80dae150, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor acpi0: on motherboard acpi0: Power Button (fixed) atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 10000000 Hz quality 950 Event timer "HPET" frequency 10000000 Hz quality 550 Event timer "HPET1" frequency 10000000 Hz quality 450 Event timer "HPET2" frequency 10000000 Hz quality 450 Event timer "HPET3" frequency 10000000 Hz quality 450 Event timer "HPET4" frequency 10000000 Hz quality 450 Event timer "HPET5" frequency 10000000 Hz quality 450 Event timer "HPET6" frequency 10000000 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 virtio_pci0: port 0x2000-0x201f mem 0xc0000000= -0xc0001fff irq 16 at device 2.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x1018020 virtio_pci0: negotiated features: 0x18020 vtnet0: Ethernet address: 58:9c:fc:00:00:2e ahci0: mem 0xc0002000-0xc00023ff irq 17 a= t device 3.0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard sc0: at flags 0x100 on isa0 sc0: MDA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3b0-0x3bb iomem 0xb0000-0xb7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 123456 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2048MB (4194304 512 byte sectors: 16H 63S/T 4161C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/TESTROOT [rw]... Setting hostuuid: 2a6777aa-60f2-11e4-b6c9-589cfc00002e. Setting hostid: 0xe892211e. No suitable dump device was found. Starting file system checks: /dev/ufs/TESTROOT: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/TESTROOT: clean, 1052636 free (476 frags, 131520 blocks, 0.0% frag= mentation) Mounting local file systems:. Writing entropy file:Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 146, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 110, in runTest child2.expect(['login:']) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P',= u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,vir= tio-net,tap0,mac=3D58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10= .freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'= com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): '(476 frags, 131520 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' before (last 100 chars): '(476 frags, 131520 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' after: match: None match_index: None exitstatus: None flag_eof: False pid: 37027 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x80066d150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 11:59:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B243E2F for ; Fri, 31 Oct 2014 11:59:35 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E50E799 for ; Fri, 31 Oct 2014 11:59:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=1HLOTgtA81Zt/ry52EhaIRGfK1P593sNjwGboXvgp04=; b=glgR516LeO73xwsYkmX6CLq0JWSjbDo5f49htx6EX5PBdzFZLyYQuL6hlB81odBUoJAovRD6A25iwHPO9LZJa5k8hq+eKr/YME+90I7T3tgMPt0benjgLCXuyQSey5Co3ahspnEN5PGvJ14hFMrQXkbzSvbXovEe/QN4Hxhv7d0=; Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]:16619 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XkArZ-0004DD-L3 for freebsd-current@freebsd.org; Fri, 31 Oct 2014 06:59:33 -0500 Date: Fri, 31 Oct 2014 06:59:18 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: VT: NOT giving extended console Message-ID: <20141031115918.GB847@borg.lerctr.org> References: <20141031031635.GA857@borg.lerctr.org> <545365D4.4030407@dumbbell.fr> <20141031114617.492e2c01@kalimero.tijl.coosemans.org> <545368E3.2000208@dumbbell.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545368E3.2000208@dumbbell.fr> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 11:59:35 -0000 On Fri, Oct 31, 2014 at 11:48:03AM +0100, Jean-S?bastien P?dron wrote: > On 31.10.2014 11:46, Tijl Coosemans wrote: > >> Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of > >> the drm2 module. > >> > >> I'll connect it as soon as svn up is finished, except if Tijl beats me > >> to it :) > > > > Done in r273902. > > Thanks :) And thank you very much for adding AGP support! > > -- > Jean-S?bastien P?dron > [repost to list, sorry Jean-Sebastien]: Thanks, now I get a constant stream of: Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:26 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:26 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:36 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:36 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:47 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:47 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:57 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:57 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:07 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:07 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:18 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:18 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:28 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:28 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:38 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:38 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:49 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:49 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:59 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:59 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:09 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:09 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:19 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:19 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:30 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:30 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:40 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:40 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:50 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:50 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:56:00 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:56:00 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:56:11 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:56:11 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:56:21 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:56:21 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:56:31 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:56:31 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:56:42 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:56:42 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:56:52 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:56:52 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:57:02 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:57:02 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:57:12 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:57:12 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:57:23 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:57:23 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:57:33 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:57:33 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:57:43 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:57:43 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:57:54 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:57:54 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:58:04 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:58:04 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:58:14 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:58:14 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:58:24 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:58:24 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:58:35 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:58:35 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:58:45 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:58:45 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:58:55 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:58:55 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID dmesg.boot: Copyright (c) 1992-2014 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 11.0-CURRENT #5 r273902: Fri Oct 31 06:45:12 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 VT-x: HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65626693632 (62586 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xffffffff80eb3180, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33001378 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000010C85000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff80011923000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0x0 iic1: on iicbus1 iicbus2: on iicbb2 addr 0x0 iic2: on iicbus2 iicbus3: on iicbb3 addr 0x0 iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 coretemp4: on cpu4 est4: on cpu4 coretemp5: on cpu5 est5: on cpu5 coretemp6: on cpu6 est6: on cpu6 coretemp7: on cpu7 est7: on cpu7 usbus0: 12Mbps Full Speed USB v1.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x444 offMax=0x79a hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 ugen0.1: at usbus0 uhub0: on usbus0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub1: on usbus3 ugen2.1: at usbus2 uhub2: on usbus2 ugen1.1: at usbus1 uhub3: on usbus1 uhub_attach: Turning port 1 power on ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub_attach: Turning port 2 power on uhub_attach: Turning port 1 power on uhub_attach: Turning port 1 power on uhub_attach: Turning port 1 power on uhub0: 2 ports with 2 removable, self powered uhub_attach: Turning port 2 power on uhub_attach: Turning port 2 power on uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 SMP: AP CPU #4 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present uhub_attach: Turning port 2 power on uhub_attach: Turning port 3 power on uhub_attach: Turning port 4 power on Root mount waiting for: usbus3 uhub_attach: Turning port 5 power on uhub_attach: Turning port 6 power on uhub1: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen0.3: at usbus0 error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID random: unblocking device. error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID uhid0: on usbus3 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=0 error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 13:59:15 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37AA3AB9 for ; Fri, 31 Oct 2014 13:59:15 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C82725F3 for ; Fri, 31 Oct 2014 13:59:14 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s9VDxCK5038083 for ; Fri, 31 Oct 2014 06:59:12 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s9VDxCG9038082 for current@freebsd.org; Fri, 31 Oct 2014 06:59:12 -0700 (PDT) (envelope-from david) Date: Fri, 31 Oct 2014 06:59:12 -0700 From: David Wolfskill To: current@freebsd.org Subject: Unclean shutdown for r273852 -> r273899 transition Message-ID: <20141031135912.GA80218@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nWqJwdiWj0NHfEIU" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 13:59:15 -0000 --nWqJwdiWj0NHfEIU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I thought it a bit odd when I rebooted after the "make installworld" completed and found that fsck(8) was checking teh file systems on my laptop. When it also happened for my build machine, I suspected it might not merely be a one-off oddity... and I was able to make use of the serial console on the build machine. THe laptop started out running: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1412 r273= 852M/273852:1100040: Thu Oct 30 05:25:51 PDT 2014 root@g1-252.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 this morning; I performed an in-place source upgrade to: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1413 r273= 899M/273900:1100041: Fri Oct 31 06:01:13 PDT 2014 root@g1-252.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 Here's what things looked like on the cosnole for the build machine (which had been built from sources at the same revisions): Oct 31 06:40:09 freebeast shutdown: reboot by david:=20 Stopping cron. Waiting for PIDS: 723. Stopping sshd. Waiting for PIDS: 713. Stopping rsyncd. Waiting for PIDS: 686. Stopping powerd. Waiting for PIDS: 671. Stopping ntpd. Waiting for PIDS: 668. Stopping lpd. Waiting for PIDS: 647. Stopping lockd. Waiting for PIDS: 630. Stopping statd. Waiting for PIDS: 627. Stopping nfsd. Waiting for PIDS: 623 624. Stopping mountd. Waiting for PIDS: 617. Stopping casperd. Waiting for PIDS: 595. Stopping amd. Waiting for PIDS: 587. Stopping ypbind. Waiting for PIDS: 582. Stopping rpcbind. Waiting for PIDS: 491. Stopping devd. Waiting for PIDS: 407. Writing entropy file:. =2E TermiOct 31 06:40:14 freebeast syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...5 6 6 6 6 4 4 4 4 4 3 1 1 1 1 1 1 1 1 0 0= 0 0 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. lock order reversal: 1st 0xc7925388 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223 2nd 0xc7a7a7f8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper(c11ac524,c6da28c8,c156af90,c156afa4,e1fb9890,...) at = db_trace_self_wrapper+0x2d/frame 0xe1fb9828 kdb_backtrace(c11b00a9,c7a7a7f8,c11a2e94,c6daa3e0,c11e2149,...) at kdb_back= trace+0x30/frame 0xe1fb9890 witness_checkorder(c7a7a7f8,9,c11e2149,55f,0,...) at witness_checkorder+0xd= 0c/frame 0xe1fb98e0 __lockmgr_args(c7a7a7f8,80400,c7a7a818,0,0,0,c11e2149,55f) at __lockmgr_arg= s+0x8f3/frame 0xe1fb99bc vop_stdlock(e1fb9a30,c11e2149,63d,1244,c7a7a838,...) at vop_stdlock+0x4d/fr= ame 0xe1fb99ec VOP_LOCK1_APV(c140ddac,e1fb9a30,0,0,c145ac60,...) at VOP_LOCK1_APV+0x10a/fr= ame 0 ______ ____ _____ _____ =20 | ____| | _ \ / ____| __ \=20 | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____) | |__| | | | | | | | || | | | |_| |_| \___|\___||____/|_____/|_____/ ``` ` s` `.....---.......--.``` -/ =2E..=20 (The stack bactrace is obviously truncated.) =2E.. Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #1651 r273899M/273900:1100041: Fri Oct 31 06:31:31 PD= T 2014 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU) Origin=3D"GenuineIntel" Id=3D0xf41 Family=3D0xf Model=3D0x4 Stepping= =3D1 Features=3D0xbfebfbff Features2=3D0x659d AMD Features=3D0x20100000 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2077032448 (1980 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 random device not loaded/active; using insecure pseudo-random number genera= tor ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor =2E.. SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1800099747 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/aacd0s4a [rw]... Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. Setting hostid: 0xc74551dd. cp: /var/log/utx.lastlogin: No such file or directory chmod: /var/log/utx.lastlogin: No such file or directory cp: /var/log/utx.log: No such file or directory chmod: /var/log/utx.log: No such file or directory Starting file system checks: /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4a: clean, 234181 free (1941 frags, 29030 blocks, 0.5% fragmenta= tion) /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1a: clean, 144421 free (1565 frags, 17857 blocks, 0.4% fragmenta= tion) /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1e: clean, 2589387 free (211371 frags, 297252 blocks, 1.6% fragm= entation) /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1d: clean, 275828 free (3876 frags, 33994 blocks, 0.4% fragmenta= tion) /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2a: clean, 149425 free (97 frags, 18666 blocks, 0.0% fragmentati= on) /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2d: clean, 311378 free (218 frags, 38895 blocks, 0.0% fragmentat= ion) /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3a: clean, 144465 free (1473 frags, 17874 blocks, 0.4% fragmenta= tion) /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3d: clean, 279024 free (41032 frags, 29749 blocks, 4.6% fragment= ation) /dev/aacd0s4d: NO WRITE ACCESS /dev/aacd0s4d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4f: clean, 2090552 free (592 frags, 261245 blocks, 0.0% fragment= ation) THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/aacd0s4d (/usr) File system preen failed, trying fsck -y=20 ** /dev/aacd0s4a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 4306 files, 137698 used, 234181 free (1941 frags, 29030 blocks, 0.5% fragme= ntation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s1a ** Last Mounted on /S1 ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 10354 files, 227458 used, 144421 free (1565 frags, 17857 blocks, 0.4% fragm= entation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s1d ** Last Mounted on /S1/usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 146169 files, 619244 used, 275828 free (3876 frags, 33994 blocks, 0.4% frag= mentation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s2a ** Last Mounted on /S2 ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 10313 files, 222454 used, 149425 free (97 frags, 18666 blocks, 0.0% fragmen= tation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s2d ** Last Mounted on /S2/usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 134366 files, 583702 used, 311378 free (218 frags, 38895 blocks, 0.0% fragm= entation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s3a ** Last Mounted on /S3 ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 10352 files, 227414 used, 144465 free (1473 frags, 17874 blocks, 0.4% fragm= entation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s3d ** Last Mounted on /S3/usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames random: unblocking device. ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 145515 files, 616056 used, 279024 free (41032 frags, 29749 blocks, 4.6% fra= gmentation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s4d (NO WRITE) ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 143274 files, 563503 used, 331464 free (18320 frags, 39143 blocks, 2.0% fra= gmentation) ** /dev/aacd1s1e ** Last Mounted on /common ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 620322 files, 10780289 used, 2589387 free (211371 frags, 297252 blocks, 1.6= % fragmentation) ***** FILE SYSTEM IS CLEAN ***** ** /dev/aacd0s4f ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 575 files, 25776 used, 2090552 free (592 frags, 261245 blocks, 0.0% fragmen= tation) ***** FILE SYSTEM IS CLEAN ***** lock order reversal: 1st 0xc79085c0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223 2nd 0xc7995c68 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper(c11aca2c,c6d9f8c8,c1574418,c157441c,f4cbb860,...) at = db_trace_self_wrapper+0x2d/frame 0xf4cbb7f8 kdb_backtrace(c11b05b1,c7995c68,c11a339c,c6da7448,c11e2649,...) at kdb_back= trace+0x30/frame 0xf4cbb860 witness_checkorder(c7995c68,9,c11e2649,55f,0,...) at witness_checkorder+0xd= 0c/frame 0xf4cbb8b0 __lockmgr_args(c7995c68,80400,c7995c88,0,0,0,c11e2649,55f) at __lockmgr_arg= s+0x8f3/frame 0xf4cbb98c vop_stdlock(f4cbba00,c7937310,c79a32a0,0,c79a32a0,...) at vop_stdlock+0x4d/= frame 0xf4cbb9bc VOP_LOCK1_APV(c140d5a0,f4cbba00,0,0,c145a460,...) at VOP_LOCK1_APV+0x10a/fr= ame 0xf4cbb9e8 _vn_lock(c7995c34,80400,c11e2649,55f,c1574418,...) at _vn_lock+0xa6/frame 0= xf4cbba28 ffs_flushfiles(c79a32a0,8,c7937310,1,c7995c34,...) at ffs_flushfiles+0x142/= frame 0xf4cbba74 softdep_flushfiles(c79a32a0,0,c7937310,0,0,...) at softdep_flushfiles+0x74/= frame 0xf4cbbac8 ffs_unmount(c79a32a0,8000000,c11b92d4,50a,c141db80,...) at ffs_unmount+0x7b= /frame 0xf4cbbb10 dounmount(c79a32a0,8000000,c7937310,48c,0,...) at dounmount+0x4de/frame 0xf= 4cbbb70 sys_unmount(c7937310,f4cbbcc8,8,c11a894c,db,...) at sys_unmount+0x2ca/frame= 0xf4cbbc40 syscall(f4cbbd08) at syscall+0x30c/frame 0xf4cbbcfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf4cbbcfc --- syscall (22, FreeBSD ELF32, sys_unmount), eip =3D 0x280cc63b, esp =3D 0= xbfbfe464, ebp =3D 0xbfbfe530 --- Mounting local file systems:. Writing entropy file:. Setting hostname: freebeast.catwhisker.org. =2E... After the "smoke test" on head, I rebooted the laptop to today's stable/10 (FreeBSD 10.1-PRERELEASE #1374 r273898M/273900:1001501: Fri Oct 31 04:12:05 PDT 2014); the build machine was powered off (until just before midnight). I'm not sure exactly how much of a problem this is, but it seems anomalous, at best. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --nWqJwdiWj0NHfEIU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUU5WwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk72m4QAJLZONQ+dqv2/49PVk6jwPJA iScOgSWTurpfya3LcnBE419Hj2SjJrkyXLQbYrPZcmISUkjQkGdIb/bDNpxpCFJJ m+s73Q9nqnxFLAjv2YTQJtjM36y74wUWYk4MSjtSsC+IUDe2sswxMfLfI67XSD2C WyJ4CFKocvTgQHx0uy9c5MT1e50FRulCGLCEZo7X6O3UosdjBq4WCoJQvtiRKRh0 tpIiEdNU5luu+0fD138Ufrk4dM+LdULq+G3R4JjhB+f/6u6m5hkIOvRpNestDV64 jN6gtz92SSHzYU5JgWqxQXJIRJhBl7oQM4wSbXSyBIaCNAxUrTJPWxCWxtyloM7J h2schwCdEENMkdwJzx0rHKEME2KrUgQFr3b3lpC8BzPFaidByZ7VL4xjkom4p+kT kNeKOFAITJTpGA1tsCAkR0yb9rWDKVMLQReMsrRB++ivINLaaLoV5tUf31ik7PbV HWecWMwsytJMJ0sYoGw4hw7s+p9CJ6GXx6m1m6skkuOGNRVk/HAEeKtKU17kfJfO 8eF/KMor5qbiqYnzS8LG/r/rSVRG9ifSrFObkfoAqqL2Op1P9Wpj78PQwADnvlam bapSKDkbPs5aju4lA4fQ3bGtQ38HSaQm1JCt1qCSwlWFKPrO0BOfznPfaAjFvopm f/nFhAid7HCV93zrnpGS =NaI9 -----END PGP SIGNATURE----- --nWqJwdiWj0NHfEIU-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 14:28:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ED7C9D8 for ; Fri, 31 Oct 2014 14:28:52 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8CBB1959 for ; Fri, 31 Oct 2014 14:28:52 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 92831518 for ; Fri, 31 Oct 2014 14:28:52 +0000 (UTC) Date: Fri, 31 Oct 2014 14:28:52 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <162415044.17.1414755422765.JavaMail.jenkins@jenkins-9.freebsd.org> References: <162415044.17.1414755422765.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #160 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 14:28:52 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#155 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson2662489205289567898.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/sc= ripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image= /FreeBSD_HEAD/test.img vm_test Consoles: userboot =20 FreeBSD/amd64 User boot, Revision 1.1 (rodrigc@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014) |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08Loading /boot/d= efaults/loader.conf=20 /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08=1B[H=1B[J=1B[7;46H ``` `=1B[8;46Hs`= `.....---.......--.``` -/=1B[9;46H+o .--` /y:` +.=1B[10;4= 6H yo`:. :o `+-=1B[11;46H y/ -/` -o/=1B[12= ;46H .- ::/sy+:.=1B[13;46H / `-- /=1B= [14;46H`: :`=1B[15;46H`: = :`=1B[16;46H / /=1B[17;46H .- = -.=1B[18;46H -- -.=1B[19;46H `:` = `:`=1B[20;46H .-- `--.=1B[21;46H .---.....----.=1B= [25;0H=1B[1;2H ______ ____ _____ _____ =1B[2;2H| ____| = | _ \ / ____| __ \ =1B[3;2H| |___ _ __ ___ ___ | |_) | (___ | = | | |=1B[4;2H| ___| '__/ _ \/ _ \| _ < \___ \| | | |=1B[5;2H| | | | |= __/ __/| |_) |____) | |__| |=1B[6;2H| | | | | | || | | = |=1B[7;2H|_| |_| \___|\___||____/|_____/|_____/ =1B[25;0H=1B[10;2H|= =1B[11;2H|=1B[12;2H|=1B[13;2H|=1B[14;2H|=1B[15;2H|=1B[16;2H|=1B[17;2H|=1B[1= 8;2H|=1B[19;2H|=1B[20;2H|=1B[21;2H|=1B[10;44H|=1B[11;44H|=1B[12;44H|=1B[13;= 44H|=1B[14;44H|=1B[15;44H|=1B[16;44H|=1B[17;44H|=1B[18;44H|=1B[19;44H|=1B[2= 0;44H|=1B[21;44H|=1B[9;3H-----------------------------------------=1B[22;3H= -----------------------------------------=1B[9;2H+=1B[22;2H+=1B[9;44H+=1B[2= 2;44H+=1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08=1B[9;15HWel= come to FreeBSD=1B[11;5H1 =1B[11;6H.=1B[11;8HBoot Multi User [Enter]=1B[12;= 5H2 =1B[12;6H.=1B[12;8HBoot [S]ingle User=1B[13;5H3 =1B[13;6H.=1B[13;8H[Esc= ]ape to loader prompt=1B[14;5H4 =1B[14;6H.=1B[14;8HReboot=1B[16;5HOptions:= =1B[17;5H5 =1B[17;6H.=1B[17;8H[K]ernel: kernel (1 of 2)=1B[18;5H6 =1B[18;6H= .=1B[18;8HConfigure Boot [O]ptions...=1B[25;0H=1B[23;4HAutoboot in 9 second= s. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 8 seconds. [Space] to paus= e=1B[25;0H=1B[23;4HAutoboot in 7 seconds. [Space] to pause=1B[25;0H=1B[23;4= HAutoboot in 6 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 5 sec= onds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 4 seconds. [Space] to p= ause=1B[25;0H=1B[23;4HAutoboot in 3 seconds. [Space] to pause=1B[25;0H=1B[2= 3;4HAutoboot in 2 seconds. [Space] to pause=1B[25;0H=1B[23;4HAutoboot in 1 = seconds. [Space] to pause=1B[25;0H=1B[23;4H = =1B[25;0H|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08/boot/kernel/kernel text=3D0x10031e= 8 |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08data=3D0x12bec8= +0x3d3e70 -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08syms=3D[0x8+0x146760\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08+0x8+0x161c40-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08] Booting... \=08|=08/=08-=08\=08|=08/=08bhyve -c 2 -m 2G -AI -H -P -g 0 -s 0:0,hostbrid= ge -s 1:0,lpc -s 2:0,virtio-net,tap0,mac=3D58:9c:fc:00:00:2e -s 3:0,ahci-hd= ,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test= .img -l com1,stdio vm_test open of tap device /dev/tap0 failed GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =09The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1634: Fri Oct 31 14:14:59 UTC 2014 jenkins@jenkins-10.freebsd.org:/usr/obj/builds/FreeBSD_HEAD/sys/GENERIC= amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2399.77-MHz K8-class = CPU) Origin=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 Model=3D0x2c Steppi= ng=3D2 Features=3D0x9f83ab7f Features2=3D0x829e6257 AMD Features=3D0x24100800 AMD Features2=3D0x1 TSC: P-state invariant Hypervisor: Origin =3D "bhyve bhyve " real memory =3D 2147483648 (2048 MB) avail memory =3D 2040287232 (1945 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded/active; using insecure pseudo-random number genera= tor ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xffffffff80dae150, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor acpi0: on motherboard acpi0: Power Button (fixed) atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 10000000 Hz quality 950 Event timer "HPET" frequency 10000000 Hz quality 550 Event timer "HPET1" frequency 10000000 Hz quality 450 Event timer "HPET2" frequency 10000000 Hz quality 450 Event timer "HPET3" frequency 10000000 Hz quality 450 Event timer "HPET4" frequency 10000000 Hz quality 450 Event timer "HPET5" frequency 10000000 Hz quality 450 Event timer "HPET6" frequency 10000000 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 virtio_pci0: port 0x2000-0x201f mem 0xc0000000= -0xc0001fff irq 16 at device 2.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x1018020 virtio_pci0: negotiated features: 0x18020 vtnet0: Ethernet address: 58:9c:fc:00:00:2e ahci0: mem 0xc0002000-0xc00023ff irq 17 a= t device 3.0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard sc0: at flags 0x100 on isa0 sc0: MDA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3b0-0x3bb iomem 0xb0000-0xb7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 123456 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2048MB (4194304 512 byte sectors: 16H 63S/T 4161C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/TESTROOT [rw]... Setting hostuuid: 2bb22ee2-610a-11e4-9a6e-589cfc00002e. Setting hostid: 0x692b9bfe. No suitable dump device was found. Starting file system checks: /dev/ufs/TESTROOT: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/TESTROOT: clean, 1052439 free (671 frags, 131471 blocks, 0.0% frag= mentation) Mounting local file systems:. Writing entropy file:Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 146, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 110, in runTest child2.expect(['login:']) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1= 568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P',= u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,vir= tio-net,tap0,mac=3D58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10= .freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'= com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): '(671 frags, 131471 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' before (last 100 chars): '(671 frags, 131471 blocks, 0.0% fragmentation)\r\= nMounting local file systems:.\r\nWriting entropy file:' after: match: None match_index: None exitstatus: None flag_eof: False pid: 47725 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x80066d150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 16:58:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21D0A198 for ; Fri, 31 Oct 2014 16:58:50 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6E41D46 for ; Fri, 31 Oct 2014 16:58:49 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XkFXE-0003FZ-4T for freebsd-current@freebsd.org; Fri, 31 Oct 2014 17:58:48 +0100 Message-ID: <5453BFC1.8010206@dumbbell.fr> Date: Fri, 31 Oct 2014 17:58:41 +0100 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: VT: NOT giving extended console References: <20141031031635.GA857@borg.lerctr.org> <545365D4.4030407@dumbbell.fr> <20141031114617.492e2c01@kalimero.tijl.coosemans.org> <545368E3.2000208@dumbbell.fr> <20141031115918.GB847@borg.lerctr.org> In-Reply-To: <20141031115918.GB847@borg.lerctr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DbCREMGPUFrXKi5ttSKECIISAOM7tm778" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 16:58:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DbCREMGPUFrXKi5ttSKECIISAOM7tm778 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 31.10.2014 12:59, Larry Rosenman wrote: > Thanks, now I get a constant stream of: >=20 > kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0= invalid. > kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a m= onitor but no|invalid EDID Yeah, the driver reprobe any output connectors every 10" by default. I think there's a setting to tune how/when connectors are probed but we don't expose it currently. Feel free to comment those messages, they are = in: o sys/dev/drm2/drm_edid.c o sys/dev/drm2/radeon/radeon_connectors.c --=20 Jean-S=E9bastien P=E9dron --DbCREMGPUFrXKi5ttSKECIISAOM7tm778 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUU7/IXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMBbQQAI6iwVi3LC5PYK931Yfizysh pVBpsTrXpVFM7GqGDQ4TOUPO2e3g5YVmUDxfZXadCuJjLW9k65w+OWSkvdcrf2O0 Qr+v7z4QSpBzh9ey0ii9FRlpC3rt0cSJJPCKD5Yl2z7W2V3CVmHk7+vj1v3VS0se JW8eezwUbqlDF4tGOnjajbUeIGx2MBXFaE0y5mh0Zwve7O3iWvn/Ug3ytUco9SuZ sqwC6/S+FslqpFSqxyrgVX6W8bwtwJpWZ9K91K9gsTJzCRp39JmioPs7jCJ2MIxC PYNCsprPEU1jbf4sY+3ZS/8YJ6xa01ivs6Sqf5ZmkpRJfkwhYrinsVgoboxx0QkG o+muiyM3fRLJFDw1AS4bbMsEA9wxU8JMqlL6ZJddeLlVG/3Ddp8UVYNSXDKMvqwR oKPUcFTip1Bj918NkDy3+86XUk/sPGM0PnlOI61mYEaYfJ0I11GRodMpylxjZH4T 8RB/2X88sWIA0wutkWY9epofUwInjhtQ2t19+MdpsB1LKAvgcAER57YtOOfvl4Mv 1DSLp6xe0y1zD5z75hwV6VnUkN4VNjioHGYclCsuyZl026mtYPoGTxLjptTrS3Lx clLBsto+KAN1xH/WlqhK/CKBKz4Mu0YMjxKhBXV1sylFSwSw7XiT2WRPsmL7NjMh cjerdkffIRxevhMpGtID =aV9J -----END PGP SIGNATURE----- --DbCREMGPUFrXKi5ttSKECIISAOM7tm778-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 17:04:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08F3C3E1 for ; Fri, 31 Oct 2014 17:04:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id EB6DAE2D for ; Fri, 31 Oct 2014 17:04:29 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F1D43558 for ; Fri, 31 Oct 2014 17:04:29 +0000 (UTC) Date: Fri, 31 Oct 2014 17:04:29 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 17:04:30 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 17:13:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D1DD71C; Fri, 31 Oct 2014 17:13:00 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA16EF32; Fri, 31 Oct 2014 17:12:59 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id p10so7573991pdj.5 for ; Fri, 31 Oct 2014 10:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3AV7gaKQD7XowuL6PUljXGLHKWdyJC91gSqDFWRnCjY=; b=TFEIAzNpcGryN7FfWx41lcw8p9CADkmQR8aus08O8sXlYZ/MxR/MY1tntSv8PhmpkG X+mQ5Pj9jo256PDyQeY8pt0VGwHxKjyYo3/amj8r0JR1nXVGlJulekBO94X28+QPJZuN QhSndgAw5YyopohqzUI0KwLR5+QWL6BBBbrFhmu7UctTQdgNVY6qHVlJcHuE005oFVWE 9XKbHicw88vNAl20Ns4OyZtrVTkbeTB5MuW5Jnzd7Fee5MHoIEBu4/dxF/5ZSZ1k0RaE W4/Nlem3ri47aqPl0KM/GJWJj/d/VpSUOQ79ioXqVd7WI8fTbpzhed9P5/7jle/5sZVk fB6Q== X-Received: by 10.66.118.136 with SMTP id km8mr26708830pab.100.1414775579436; Fri, 31 Oct 2014 10:12:59 -0700 (PDT) Received: from [10.76.101.130] (mobile-166-171-120-203.mycingular.net. [166.171.120.203]) by mx.google.com with ESMTPSA id kk1sm7438025pbd.14.2014.10.31.10.12.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 10:12:58 -0700 (PDT) References: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <333534ED-2753-48DC-98F7-4B4853A1CFEB@gmail.com> X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161 Date: Fri, 31 Oct 2014 10:12:54 -0700 To: "jenkins-admin@freebsd.org" , Craig Rodrigues Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 17:13:00 -0000 > On Oct 31, 2014, at 10:04, jenkins-admin@freebsd.org wrote: >=20 > See Hi Craig, I have a potential fix for this on my github branch (I ATFified the test= case and fixed some broken assumptions; I'll find the PR later). Now that bo= ot is fixed on head I can upgrade, and will see about testing out the fix. I= f I don't get to it today, I'll look at fixing it when I'm down at MeetBSD. Thank you,= From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 16:50:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C97A3FB8 for ; Fri, 31 Oct 2014 16:50:45 +0000 (UTC) Received: from nm39-vm6.bullet.mail.ne1.yahoo.com (nm39-vm6.bullet.mail.ne1.yahoo.com [98.138.229.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8268DC49 for ; Fri, 31 Oct 2014 16:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414774137; bh=bmHrZbv8KJirEenvxo4bbihUT1UPU4R+cWU3YQkfscw=; h=Date:From:Reply-To:To:Subject:From:Subject; b=GFF9vztzBcAG1/aFaaFWJjutzVMLyb/Mze3DW0v9hVNYINC0id9qY1YEfz7owIX9nnGzgGYaKi1nO8C2awdVU7X0uH0v/Y/nRtXVIH4GjSEAvpH4fPnyjoQB7SqVP71MYaFbHK6vgXU7CBlNhl7Ze1Emrj7SjIHCvPQLT/VJ3Zga3R34caFij2nq86S9n0BKh4+LYiJdtdYRYvppwpRs8oo0lmVEBd1wi2QohcRwRl2cvOSRlus75TgA3KG4au5Kp+cCBNPpTNSVuYtkJdVVkUlVpD+GWBDwV3zXJFd3QPuKmnCI+mNxxvipcvwWKk3ffyEr89Wn7Zed0aarzAozAg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=kMcPhrYmXIyIxX6+ZkQmihV3jVGUfyNT+S2t1fYO2g8DU7zM6furmXh9f/zOsdx1LqYeBW8zSlvW/IPmmY43Rbg0ppN7Nc4DyzDJo4FGyAFp5kUkW/ya+64VroCctccdlre7rzDsSUxKfRJMBee4pNupbC/QGHNcRUNL+HkQllIDMYA1bdjL775n9XvduSHmHyqpJW/G+Hv3VhD/x1MGLGt7NWPrKtlbRawoRuwbr3f6Di263fekO717VC6l46CdYzGIoIN2FyLDRhxxJk0T6c+x+IxLUx9VDdd78Ce0VNgOluNP1Z1+mGjgv7fOcJZrhOHQ1aZAP64Ryh1iy30Alw==; Received: from [127.0.0.1] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 31 Oct 2014 16:48:57 -0000 Received: from [98.138.226.178] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 31 Oct 2014 16:46:16 -0000 Received: from [66.196.81.173] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 31 Oct 2014 16:46:16 -0000 Received: from [98.139.212.244] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 16:46:16 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 16:46:16 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 805312.40395.bm@omp1053.mail.bf1.yahoo.com X-YMail-OSG: blrU45cVM1ltVQStsC9qNI7RvW2CB_Vbx34OQieIlNdDSCyW1jn_Yw2EWfN8vJN gFX_irBk2wZY2u0qrECc3wiWedkogL4yfPQmDrb2VjrrEVWOgeXtbcxl.3_iuCwls42fHzGx35rP VjycvzV7g.s7PX.nA1yDBN_Eu1aM0lEDIp3nn6BCrur9VpTDL5IZDE21hVVlw6O71W2XuM3wx7pF Xmlfle5zfQJjUXyvKR6B0UavA35DtEm9of5mBIJNwkoM5bvzfzicQt1wN387S_AvZ1oX_P5KMk_2 5yt_PbuF6CLj._AMABjjhYhReehRjP4G7azzPhWkiR2vghlXQ7JzwOwVDezfzk7sb2Hrt1BHX7NW 4NTQB0b7KckSAh.o..qrL5Znl7NGv1cwpkqjOI4zktlI8r1srtRujhXXhEm5Mz.k45BBgy68DEUQ 8mJrJFlBF2SSzJILzREnZqe4xg5_.WPDJP2FIus5Hqj5SNGzHEjLzSZOg Received: by 66.196.81.105; Fri, 31 Oct 2014 16:46:16 +0000 Date: Fri, 31 Oct 2014 16:46:15 +0000 (UTC) From: John Dison Reply-To: John Dison To: "freebsd-current@freebsd.org" Message-ID: <2074770725.140543.1414773975682.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> Subject: NVidia Tesla K40 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 31 Oct 2014 17:49:02 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 16:50:45 -0000 Hello! I want to use NVidia Tesla K40 GPU for parallel computing.Does FreeBSD support such a hardware? Thanks a lot! From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 18:35:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B23C7DA for ; Fri, 31 Oct 2014 18:35:52 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A126ABBD for ; Fri, 31 Oct 2014 18:35:51 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XkH30-0015Sb-Mf>; Fri, 31 Oct 2014 19:35:42 +0100 Received: from g225118094.adsl.alicedsl.de ([92.225.118.94] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XkH30-003a9Y-JY>; Fri, 31 Oct 2014 19:35:42 +0100 Date: Fri, 31 Oct 2014 19:35:37 +0100 From: "O. Hartmann" To: John Dison Subject: Re: NVidia Tesla K40 Message-ID: <20141031193537.28d8879c.ohartman@zedat.fu-berlin.de> In-Reply-To: <2074770725.140543.1414773975682.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> References: <2074770725.140543.1414773975682.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/9fRoOlzUZ2xHOP9eXP3+l48"; protocol="application/pgp-signature" X-Originating-IP: 92.225.118.94 X-ZEDAT-Hint: A Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 18:35:52 -0000 --Sig_/9fRoOlzUZ2xHOP9eXP3+l48 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 31 Oct 2014 16:46:15 +0000 (UTC) John Dison schrieb: > Hello! > I want to use NVidia Tesla K40 GPU for parallel computing.Does FreeBSD su= pport such a > hardware? Thanks a lot! > _______________________________________________ > 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're out of luck. No, FreeBSD doesn't support GPGPU computing on modern g= raphics hardware. Since 2009 we try to utilize FreeBSD for such a purpose, especial= ly with the use of OpenCL for high performance computing. Around 2010 there was the glimpse of a dawn with Pathscale, offering a Open= ACC-precursor with their compiler infrastructure, supposed to be capable of utilizing Fre= eBSD and nVidia GPUs (that time Tesla) with Pathscale-libraries (I forgot the name, = it's CAPS or something like that) but at the end it revealed its self as a heap of unfin= ished, unmature code and by now the company or ist successor doen't even provide a= commercial product for FreeBSD - the project died! It is even worse: FreeBSD ports dropped Nouveau! There are effords bringing= libclc, the new Mesa library, Glover and OpenCL in combination with LLVM 3.4/3.5 togeth= er to provide OpenCL and via LLVM the nVidia PTX backend, but as far as I know this work = is still under development and immature and FreeBSD is no longer part of the scene due to = the drop of the Nouveau driver (I was told FreeBSD lacks important kernel features know= n for years for KMS). CUDA is completely out of view: nVidia doesn't provide support for FreeBSD.= nVidia fellows claim there is no need/request from FreeBSD people. I believe it is= simply ignorance and a stupid political issue, made years ago, that we suffer from= by now. The situation with open source AMD driver (radeonSI) is unknown to me. We m= ade very bad experiences with AMD hardware in the era of the AMD HD46XX/47XX and HD48XX = chipsets and the development is/was behind the recent chips available on market. On Linu= x there were reports of successfully running OpenCL kernels on the radeonSI drivers with= Glover/Mesa and other mandatory software not available for FreeBSD - the FreeBSD X11 ba= se system is also "methusalem" and behind the recent development. If you would go with A= MD, you would have to stay with open source since AMD doens't provide BLOBs for their GPU= s for FreeBSD. For Linux, the AMD OpenCL SDK is very nice, their hardware is pretty fast (= > nVidia!) while their driver tend to crash. But as said, Linux only. With nVidia you get a pretty fast and nice BLOB for all FreeBSDs and modern= GPUs from nVidia, but there is no OpenCL backend lib (or CUDA). Either way, it is a d= ead end with FreeBSD. There was also once a setup with the FreeBSD Linuxulator - but this is 32bi= t only and a no go for serious scientific compuations. We also tried this with more mode= rn FreeBSDs (8.X, 9.X, 10-CURRENT that time), but with CUDA > 4 you're out of luck. And= FreeBSD doesn't have a 64bit support in the Linuxulator. And why running a Linuxula= tor? If you really plan to use a beast like K40, consider dropping FreeBSD and u= sing Linux! We started with Ubuntu and OpenSuse that time. At the first moment the shock i= s heavy, but you'll come along with Linux very soon. The only bad thing is the missing Z= FS support as someone might be used to in FreeBSD but this is also only a question of tim= e (more short than long!). Linux development is pretty fast these days, support is excell= ent and Linux suffers from bad karma from the days of the Linux 2.4 kernel. That has chan= ged dramatically. A department developing security facilities is now dropping O= penBSD in favour of Debian Linux, even OpenBSD is still considered more "bullet proof= ". But the decision was made due to a dramatic driver issue - I mention this here beca= use also FreeBSD seems to suffer increasingly (compared to to Linux) from driver iss= ues for high performance equipment (special interlink adaptors, WiFi NICs and even the G= PU issue!). I'm very sad having no better experience to tell. oh=20 --Sig_/9fRoOlzUZ2xHOP9eXP3+l48 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUU9Z+AAoJEOgBcD7A/5N8fN0H/jd/KQHwRiqf6biAC4X248ba RKyuGQsfGgMlH9v6GCAHEsoTdveR/9sgZjbGThAaqZtCcKc+TTTzolJI7j0xoljI POQ+7RrXm0m9kPNjErEQLnonWuqBPsUAunVRoaAgtRTLUlMeSRgIoIgqPhT2g7Nx Dtsxm1tlg+BIL/amhbF4DQLrUYF50lTvkw7B/8JIWIL1lZ4PACcoDDNqdpnhPpu4 GYocWPpHd0McSxryl+xH2TMrDSgLMwdU5gkz/s84LY1bZvTPOmncreNeg3PlC8p0 KawGIttlR0vgxBiLK6NhW5kAJmOx6FiMLf3XwGlrl/lRAtk4uVOmJiraBqSDn20= =D9/f -----END PGP SIGNATURE----- --Sig_/9fRoOlzUZ2xHOP9eXP3+l48-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 18:55:15 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EE20C7 for ; Fri, 31 Oct 2014 18:55:15 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0286BDE6 for ; Fri, 31 Oct 2014 18:55:15 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XkHLs-0004YH-Kp for freebsd-current@FreeBSD.org; Fri, 31 Oct 2014 19:55:12 +0100 Message-ID: <5453DB0C.3040106@FreeBSD.org> Date: Fri, 31 Oct 2014 19:55:08 +0100 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD Current Subject: r273910 build failure if is out-of-date Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JVroPHQif73nqT5Md2GqJVIduP0MM2SPo" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 18:55:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JVroPHQif73nqT5Md2GqJVIduP0MM2SPo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi! I have the following error when building HEAD: ---8<--- cc -O2 -pipe -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/include -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../include= -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64 -DNLS -fexceptions -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib= /gdtoa -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib= /libc-vis -DINET6 -I/usr/obj/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../libmd -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib= /jemalloc/include -DMALLOC_PRODUCTION -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib= /tzcode/stdtime -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/stdtime -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/locale -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c cancelpoints_sem_new.c -o cancelpoints_sem_new.o In file included from cancelpoints_sem_new.c:47: /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../include/s= emaphore.h:41: error: field '_kern' has incomplete type cancelpoints_sem_new.c:66: error: 'USEM_MAX_COUNT' undeclared here (not in a function) cc1: warnings being treated as errors cancelpoints_sem_new.c: In function '_sem_getvalue': cancelpoints_sem_new.c:335: warning: implicit declaration of function 'USEM_COUNT' cancelpoints_sem_new.c: In function 'usem_wake': cancelpoints_sem_new.c:342: error: 'UMTX_OP_SEM2_WAKE' undeclared (first use in this function) cancelpoints_sem_new.c:342: error: (Each undeclared identifier is reported only once cancelpoints_sem_new.c:342: error: for each function it appears in.) cancelpoints_sem_new.c: In function 'usem_wait': cancelpoints_sem_new.c:361: error: 'UMTX_OP_SEM2_WAIT' undeclared (first use in this function) cancelpoints_sem_new.c: In function '_sem_post': cancelpoints_sem_new.c:445: error: 'USEM_HAS_WAITERS' undeclared (first use in this function) *** Error code 1 Stop. make[4]: stopped in /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc *** Error code 1 ---8<--- The problem is that the installed version of is out-of-date compared to the version in the source tree. I guess it's supposed to pick the version in the source tree, but I'm not sure what's the correct way of doing this. FYI, this is with base gcc on sparc64. World was updated on August 6. --=20 Jean-S=C3=A9bastien P=C3=A9dron --JVroPHQif73nqT5Md2GqJVIduP0MM2SPo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUU9sQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTM3SkQAK+5rtO31sY5N9RO6Ei7ICrq ++yeeLJclPV/oqad3h42UhbzPjI7lik6sO3Tw5wvYrdcQyi6KMuzJMws7WnD4Kj/ nS8jZ/lfOLKEjt+97MWc6nmBWC1RGyLDZ0ZTrhG1ui0+gaQfA68mFVoWk6am9QCl ja8qEhJAWYWpQPXpnBVST23pJg7hePqytCfsEUbj3ilMPn08Y+5bOGo5o853aUiu vcW3/G/KES6L6fubaMO//bl2fUB4pSWTdmwV8t+8AUyiRxfZr2AaJwoZtXR9BlmV IUEOO0MDU3iLcVXZ1rC4/A2/6xZYOFusT24stGnrs5vRj2TudA50en457OxNJJnW 18PsEptiTJQuZB0H7JM3ACXPUDh7mx5hH2zWofY0FcSRqMoG4ficOfISdpfQB9by 2tlxcxR8IKbb0YA29Ls0SZXXhwuaTXFR4d/p4xdDPBzmUUxwjP4AiO/dR5dyz2d3 W+S+vquAWZJah4pkYJdv2lLM80PeXP+G39WtLlYzwCrzIyVwwgqqOAV1eI1XxDul 387YE9XM7FEF48EYcvNdT8IIalBp+haELXDZESH6YLPJzQ5SWN6Rk5EzXZ0pLLaS o1Yh1uhitDZc7Gni6yma0+/VOq3I0hEEvtff1YoXDpdeAOy68Twl1g0KZ3f8V/+e Mp6wwp7HtqxVMuUHfFUK =PGkA -----END PGP SIGNATURE----- --JVroPHQif73nqT5Md2GqJVIduP0MM2SPo-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 19:20:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C571555F for ; Fri, 31 Oct 2014 19:20:52 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8176D14B for ; Fri, 31 Oct 2014 19:20:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XkHkg-001TOR-GX>; Fri, 31 Oct 2014 20:20:50 +0100 Received: from f052009172.adsl.alicedsl.de ([78.52.9.172] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XkHkg-003fOt-EX>; Fri, 31 Oct 2014 20:20:50 +0100 Date: Fri, 31 Oct 2014 20:20:45 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! Message-ID: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/xZOdZPthiJeqs+ymQBh4+AT"; protocol="application/pgp-signature" X-Originating-IP: 78.52.9.172 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 19:20:52 -0000 --Sig_/xZOdZPthiJeqs+ymQBh4+AT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On all CURRENT systems I updated today (31.10.2014) I had massive filesyste= m corruption after reboot. The systems do have=20 FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 and suffer without exception from the same breakage, quitting services and/= or reporting corrupted filesystems after a fresh reboot - even if I've performed a manua= l triggered "fsck -fz" in single user mode on the console. All systems have GPT partion schemes. The problem is serious! I can not get rid via fsck of the problem of corrup= ted filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql= do not start properly and need to be started manually after a reboot. What is wrong? The fact that several CURRENT boxes are affected the very sa= me way (> 5 ) make me confident this is a serious bug recently introduced. Oliver --Sig_/xZOdZPthiJeqs+ymQBh4+AT Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUU+ESAAoJEOgBcD7A/5N8cjkIAIGxwExvrIQLzwEl1fVb88zA 7D199iIsgqtIi29WPBUV2W5CV0U15i1LYfefbHx4sppdcimTzOypp8qqGRN+oGBh 3IIskoGtCy4hhoicP66OPsPOVxdtGgTW0smlzM3HZI9RdyNWWwJguWzcPJ2Qb2g/ oXJDzJdZXtRy/q2+ydDme/TQqQ7GG6w9lksaprUinCpQsYSbyGTk7V0mxIqXOJ32 cX6wjB9WreBJP4CuZpm41tEqeAfm+mpqa4aPf0sx/PyZzyDyTUF7wyeVH3gTrON5 RMDf2afztsu6krhd1UsvPCGklhbFms3F9z1Q63XOrQgcarlucR8M1MFdenOHKn4= =pG5g -----END PGP SIGNATURE----- --Sig_/xZOdZPthiJeqs+ymQBh4+AT-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 19:25:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B8B081B; Fri, 31 Oct 2014 19:25:38 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE41323D; Fri, 31 Oct 2014 19:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=ZWrVOSZhltsu4Jba9+i835QjHVaRHOJ6WvAHsMHlHDg=; b=MslKc6Cn6wsfFRQj7m8dPvSEH/Q28peUAGq7x0IX0K0UMBJvQQ0LqyDREqFPmBwwjHF1+W/FSKwRyrJYKuSVUI7n0FRu2jCphxkJkgkGAubIBRJ9yv7XFsqJ2e3Lkb6rzYYOSfyG0LY08w4m3u0Z+b6VLkNmWsEnDgpT0fQyGvc=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:33032 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XkHpG-0008s6-LX; Fri, 31 Oct 2014 14:25:36 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 31 Oct 2014 14:25:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 31 Oct 2014 14:25:34 -0500 From: Larry Rosenman To: =?UTF-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= Subject: Re: VT: NOT giving extended console In-Reply-To: <5453BFC1.8010206@dumbbell.fr> References: <20141031031635.GA857@borg.lerctr.org> <545365D4.4030407@dumbbell.fr> <20141031114617.492e2c01@kalimero.tijl.coosemans.org> <545368E3.2000208@dumbbell.fr> <20141031115918.GB847@borg.lerctr.org> <5453BFC1.8010206@dumbbell.fr> Message-ID: <4711c413431bba65a87d57c422296152@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.3 X-Spam-Score: -3.5 (---) X-LERCTR-Spam-Score: -3.5 (---) X-Spam-Report: SpamScore (-3.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594 X-LERCTR-Spam-Report: SpamScore (-3.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594 Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 19:25:38 -0000 On 2014-10-31 11:58, Jean-Sébastien Pédron wrote: > On 31.10.2014 12:59, Larry Rosenman wrote: >> Thanks, now I get a constant stream of: >> >> kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block >> 0 invalid. >> kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a >> monitor but no|invalid EDID > > Yeah, the driver reprobe any output connectors every 10" by default. > > I think there's a setting to tune how/when connectors are probed but we > don't expose it currently. Feel free to comment those messages, they > are in: > o sys/dev/drm2/drm_edid.c > o sys/dev/drm2/radeon/radeon_connectors.c I think we had this before, and someone(I forget who) shut it up...... I really think it's the PROJECTS responsibility to shut this up, as I'm sure I won't be the only one whining........... Can we at least lower it to DEBUG so it doesn't spam /var/log/messages and the console? or put it behind BOOTVERBOSE? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 19:30:20 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D59FDEE1 for ; Fri, 31 Oct 2014 19:30:20 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D5472CC for ; Fri, 31 Oct 2014 19:30:19 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XkHtp-001YJf-VK>; Fri, 31 Oct 2014 20:30:17 +0100 Received: from f052009172.adsl.alicedsl.de ([78.52.9.172] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XkHtp-003gLH-PV>; Fri, 31 Oct 2014 20:30:17 +0100 Date: Fri, 31 Oct 2014 20:30:17 +0100 From: "O. Hartmann" To: David Wolfskill Subject: Re: Unclean shutdown for r273852 -> r273899 transition Message-ID: <20141031203017.02c7da19.ohartman@zedat.fu-berlin.de> In-Reply-To: <20141031135912.GA80218@albert.catwhisker.org> References: <20141031135912.GA80218@albert.catwhisker.org> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/XhMaz10yL7GulqmnNjvdb4L"; protocol="application/pgp-signature" X-Originating-IP: 78.52.9.172 X-ZEDAT-Hint: A Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 19:30:21 -0000 --Sig_/XhMaz10yL7GulqmnNjvdb4L Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 31 Oct 2014 06:59:12 -0700 David Wolfskill schrieb: > I thought it a bit odd when I rebooted after the "make installworld" > completed and found that fsck(8) was checking teh file systems on my > laptop. >=20 > When it also happened for my build machine, I suspected it might not > merely be a one-off oddity... and I was able to make use of the serial > console on the build machine. >=20 > THe laptop started out running: >=20 > FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1412 > r273852M/273852:1100040: Thu Oct 30 05:25:51 PDT 2014 > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 >=20 > this morning; I performed an in-place source upgrade to: >=20 > FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1413 > r273899M/273900:1100041: Fri Oct 31 06:01:13 PDT 2014 > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 >=20 >=20 > Here's what things looked like on the cosnole for the build machine (which > had been built from sources at the same revisions): >=20 > Oct 31 06:40:09 freebeast shutdown: reboot by david:=20 > Stopping cron. > Waiting for PIDS: 723. > Stopping sshd. > Waiting for PIDS: 713. > Stopping rsyncd. > Waiting for PIDS: 686. > Stopping powerd. > Waiting for PIDS: 671. > Stopping ntpd. > Waiting for PIDS: 668. > Stopping lpd. > Waiting for PIDS: 647. > Stopping lockd. > Waiting for PIDS: 630. > Stopping statd. > Waiting for PIDS: 627. > Stopping nfsd. > Waiting for PIDS: 623 624. > Stopping mountd. > Waiting for PIDS: 617. > Stopping casperd. > Waiting for PIDS: 595. > Stopping amd. > Waiting for PIDS: 587. > Stopping ypbind. > Waiting for PIDS: 582. > Stopping rpcbind. > Waiting for PIDS: 491. > Stopping devd. > Waiting for PIDS: 407. > Writing entropy file:. > . > TermiOct 31 06:40:14 freebeast syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...5 6 6 6 6 4 4 4 4 4 3 1 1 1 1 1 1 1 1 0= 0 0 0 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > All buffers synced. > lock order reversal: > 1st 0xc7925388 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223 > 2nd 0xc7a7a7f8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 > KDB: stack backtrace: > db_trace_self_wrapper(c11ac524,c6da28c8,c156af90,c156afa4,e1fb9890,...) at > db_trace_self_wrapper+0x2d/frame 0xe1fb9828 > kdb_backtrace(c11b00a9,c7a7a7f8,c11a2e94,c6daa3e0,c11e2149,...) at > kdb_backtrace+0x30/frame 0xe1fb9890 witness_checkorder(c7a7a7f8,9,c11e214= 9,55f,0,...) > at witness_checkorder+0xd0c/frame 0xe1fb98e0 > __lockmgr_args(c7a7a7f8,80400,c7a7a818,0,0,0,c11e2149,55f) at > __lockmgr_args+0x8f3/frame 0xe1fb99bc > vop_stdlock(e1fb9a30,c11e2149,63d,1244,c7a7a838,...) at vop_stdlock+0x4d/= frame > 0xe1fb99ec VOP_LOCK1_APV(c140ddac,e1fb9a30,0,0,c145ac60,...) at > VOP_LOCK1_APV+0x10a/frame 0 ______ ____ _____ _____ | > ____| | _ \ / ____| __ \ | |___ _ __ ___ ___ | |_) | (___ = | | | | | > ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____)= | |__| | | > | | | | | || | | | |_| |_| \___|\___||____/|____= _/|_____/ > ``` ` s` `.....---.......--.``` -/ ...=20 >=20 > (The stack bactrace is obviously truncated.) >=20 > ... > Booting... > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2014 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 11.0-CURRENT #1651 r273899M/273900:1100041: Fri Oct 31 06:31:31 = PDT 2014 > root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU) > Origin=3D"GenuineIntel" Id=3D0xf41 Family=3D0xf Model=3D0x4 Steppin= g=3D1 > Features=3D0xbfebfbff > Features2=3D0x659d > AMD Features=3D0x20100000 > TSC: P-state invariant > real memory =3D 2147483648 (2048 MB) > avail memory =3D 2077032448 (1980 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 2 package(s) x 1 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 > random device not loaded/active; using insecure pseudo-random number gene= rator > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > random: entropy device infrastructure driver > random: selecting highest priority adaptor > kbd1 at kbdmux0 > random: SOFT: yarrow init() > random: selecting highest priority adaptor > ... > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1800099747 Hz quality 1000 > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/aacd0s4a [rw]... > Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. > Setting hostid: 0xc74551dd. > cp: /var/log/utx.lastlogin: No such file or directory > chmod: /var/log/utx.lastlogin: No such file or directory > cp: /var/log/utx.log: No such file or directory > chmod: /var/log/utx.log: No such file or directory > Starting file system checks: > /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4a: clean, 234181 free (1941 frags, 29030 blocks, 0.5% fragmen= tation) > /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1a: clean, 144421 free (1565 frags, 17857 blocks, 0.4% fragmen= tation) > /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd1s1e: clean, 2589387 free (211371 frags, 297252 blocks, 1.6% fra= gmentation) > /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1d: clean, 275828 free (3876 frags, 33994 blocks, 0.4% fragmen= tation) > /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2a: clean, 149425 free (97 frags, 18666 blocks, 0.0% fragmenta= tion) > /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2d: clean, 311378 free (218 frags, 38895 blocks, 0.0% fragment= ation) > /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3a: clean, 144465 free (1473 frags, 17874 blocks, 0.4% fragmen= tation) > /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3d: clean, 279024 free (41032 frags, 29749 blocks, 4.6% fragme= ntation) > /dev/aacd0s4d: NO WRITE ACCESS > /dev/aacd0s4d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4f: clean, 2090552 free (592 frags, 261245 blocks, 0.0% fragme= ntation) > THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: > ufs: /dev/aacd0s4d (/usr) > File system preen failed, trying fsck -y=20 > ** /dev/aacd0s4a > ** Last Mounted on / > ** Root file system > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 4306 files, 137698 used, 234181 free (1941 frags, 29030 blocks, 0.5% frag= mentation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s1a > ** Last Mounted on /S1 > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 10354 files, 227458 used, 144421 free (1565 frags, 17857 blocks, 0.4% fra= gmentation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s1d > ** Last Mounted on /S1/usr > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 146169 files, 619244 used, 275828 free (3876 frags, 33994 blocks, 0.4% fr= agmentation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s2a > ** Last Mounted on /S2 > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 10313 files, 222454 used, 149425 free (97 frags, 18666 blocks, 0.0% fragm= entation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s2d > ** Last Mounted on /S2/usr > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 134366 files, 583702 used, 311378 free (218 frags, 38895 blocks, 0.0% fra= gmentation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s3a > ** Last Mounted on /S3 > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 10352 files, 227414 used, 144465 free (1473 frags, 17874 blocks, 0.4% fra= gmentation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s3d > ** Last Mounted on /S3/usr > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > random: unblocking device. > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 145515 files, 616056 used, 279024 free (41032 frags, 29749 blocks, 4.6% f= ragmentation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s4d (NO WRITE) > ** Last Mounted on /usr > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 143274 files, 563503 used, 331464 free (18320 frags, 39143 blocks, 2.0% f= ragmentation) > ** /dev/aacd1s1e > ** Last Mounted on /common > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 620322 files, 10780289 used, 2589387 free (211371 frags, 297252 blocks, 1= .6% > fragmentation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > ** /dev/aacd0s4f > ** Last Mounted on /var > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 575 files, 25776 used, 2090552 free (592 frags, 261245 blocks, 0.0% fragm= entation) >=20 > ***** FILE SYSTEM IS CLEAN ***** > lock order reversal: > 1st 0xc79085c0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223 > 2nd 0xc7995c68 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 > KDB: stack backtrace: > db_trace_self_wrapper(c11aca2c,c6d9f8c8,c1574418,c157441c,f4cbb860,...) at > db_trace_self_wrapper+0x2d/frame 0xf4cbb7f8 > kdb_backtrace(c11b05b1,c7995c68,c11a339c,c6da7448,c11e2649,...) at > kdb_backtrace+0x30/frame 0xf4cbb860 witness_checkorder(c7995c68,9,c11e264= 9,55f,0,...) > at witness_checkorder+0xd0c/frame 0xf4cbb8b0 > __lockmgr_args(c7995c68,80400,c7995c88,0,0,0,c11e2649,55f) at > __lockmgr_args+0x8f3/frame 0xf4cbb98c > vop_stdlock(f4cbba00,c7937310,c79a32a0,0,c79a32a0,...) at vop_stdlock+0x4= d/frame > 0xf4cbb9bc VOP_LOCK1_APV(c140d5a0,f4cbba00,0,0,c145a460,...) at > VOP_LOCK1_APV+0x10a/frame 0xf4cbb9e8 _vn_lock(c7995c34,80400,c11e2649,55f= ,c1574418,...) > at _vn_lock+0xa6/frame 0xf4cbba28 ffs_flushfiles(c79a32a0,8,c7937310,1,c7= 995c34,...) at > ffs_flushfiles+0x142/frame 0xf4cbba74 softdep_flushfiles(c79a32a0,0,c7937= 310,0,0,...) > at softdep_flushfiles+0x74/frame 0xf4cbbac8 > ffs_unmount(c79a32a0,8000000,c11b92d4,50a,c141db80,...) at ffs_unmount+0x= 7b/frame > 0xf4cbbb10 dounmount(c79a32a0,8000000,c7937310,48c,0,...) at dounmount+0x= 4de/frame > 0xf4cbbb70 sys_unmount(c7937310,f4cbbcc8,8,c11a894c,db,...) at sys_unmoun= t+0x2ca/frame > 0xf4cbbc40 syscall(f4cbbd08) at syscall+0x30c/frame 0xf4cbbcfc Xint0x80_s= yscall() at > Xint0x80_syscall+0x21/frame 0xf4cbbcfc --- syscall (22, FreeBSD ELF32, sy= s_unmount), > eip =3D 0x280cc63b, esp =3D 0xbfbfe464, ebp =3D 0xbfbfe530 --- Mounting l= ocal file systems:. > Writing entropy file:. Setting hostname: freebeast.catwhisker.org. .... >=20 >=20 > After the "smoke test" on head, I rebooted the laptop to today's > stable/10 (FreeBSD 10.1-PRERELEASE #1374 r273898M/273900:1001501: Fri > Oct 31 04:12:05 PDT 2014); the build machine was powered off (until just > before midnight). >=20 > I'm not sure exactly how much of a problem this is, but it seems > anomalous, at best. >=20 > Peace, > david I see this on ALL of our CURRENT systems as of yesterday and today. The fil= esystem is left unclean and whatever I do with fsck, the system starts compalining abo= ut inconsistencies after a full reboot. At the moment I'm on two boxes at home at=20 FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 with this symptomes. The result is that several services do not start anymore, slapd, nslcd, pos= tgres, hal, dbus, to name some.=20 I think this is serious. oh --Sig_/XhMaz10yL7GulqmnNjvdb4L Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUU+NJAAoJEOgBcD7A/5N8pHwH/1M2N0pIS0/Ke6ZZOT6tumuD vmZXc8pxq2/pvVA49ILjpA/KKvTN8/aNol0IBqLcGbc3t0P7xgeaaLhEb3K7FoHy 6sOUGGjXIi5leiUpFKhRiB2FWXhggr/Q53jiNET66jUJLg9ER996Z99e5OCTmJVA /s2UD8A5Vuff2i/+nagBkyCE91nBJ7ohzTfhAV8G4yfiE2hGVaVIZC01Hsvl5Uk9 Oj0182Viriq0tIqsFbJhANPtxOjP+w3S3mP6pVevhuKCmyJSwf1rMm5eAO3SbhIx uiq3RYH5q2rX1C2s6evT2oO8RI3QmgFTMVoIQA2oqgsvPWAWkEh4RkOAfNmp6Xo= =8sku -----END PGP SIGNATURE----- --Sig_/XhMaz10yL7GulqmnNjvdb4L-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 20:04:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C208D87 for ; Fri, 31 Oct 2014 20:04:58 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 39E4DA53 for ; Fri, 31 Oct 2014 20:04:57 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.9/8.14.9) with ESMTP id s9VK0AWB002147 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 13:00:11 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201410312000.s9VK0AWB002147@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 31 Oct 2014 13:00:10 -0700 To: "O. Hartmann" , FreeBSD CURRENT From: Manfred Antar Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! In-Reply-To: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-102.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID,URIBL_BLOCKED,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0, No X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: s9VK0AWB002147 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 20:04:58 -0000 At 12:20 PM 10/31/2014, O. Hartmann wrote: >On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption >after reboot. The systems do have > >FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 > >and suffer without exception from the same breakage, quitting services and/or reporting >corrupted filesystems after a fresh reboot - even if I've performed a manual triggered >"fsck -fz" in single user mode on the console. > >All systems have GPT partion schemes. > >The problem is serious! I can not get rid via fsck of the problem of corrupted >filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start >properly and need to be started manually after a reboot. > >What is wrong? The fact that several CURRENT boxes are affected the very same way (> 5 ) >make me confident this is a serious bug recently introduced. > >Oliver > With r273911 on amd64, after fresh build installworld. Upon reboot all of a sudden /var is mounted mfs. needless to say many problems with programs that store files in /var -- ie mysql clamav etc, etc I had to change the following in rc.conf to get system to work again. varmfs="AUTO" # Set to YES to always create an mfs /var, NO to never varsize="32m" # Size of mfs /var if created varmfs_flags="-S" # Extra mount options for the mfs /var populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never cleanvar_enable="YES" # Clean the /var directory CHANGED TO : varmfs="NO" # Set to YES to always create an mfs /var, NO to never varsize="32m" # Size of mfs /var if created varmfs_flags="-S" # Extra mount options for the mfs /var populate_var="NO" # Set to YES to always (re)populate /var, NO to never cleanvar_enable="NO" # Clean the /var directory Not why all of a sudden /var/ was mounted mfs. Maybe something to do with the new random stuff, I did a mergemaster before rebooting Not sure if this is related to your problem Manfred ======================== || null@pozo.com || || || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 20:08:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D69B0F26 for ; Fri, 31 Oct 2014 20:08:07 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9CA4A92 for ; Fri, 31 Oct 2014 20:08:07 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XkIUQ-0003rX-Lb for freebsd-current@freebsd.org; Fri, 31 Oct 2014 13:08:06 -0700 Date: Fri, 31 Oct 2014 13:08:06 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1414786086662-5961241.post@n5.nabble.com> Subject: r273918 buildworld broke at semaphore 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.18-1 Precedence: 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, 31 Oct 2014 20:08:07 -0000 First breakage in a long time. Error is: In file included from cancelpoints_sem_new.c:47: /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has incomplete type 'struct _usem2' struct _usem2 _kern; ^ /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration of 'struct _usem2' struct _usem2 _kern; ^ cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 'USEM_MAX_COUNT' _Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too large"); ^ cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] *sval = (int)USEM_COUNT(sem->_kern._count); ^ cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAKE' return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); ^ cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAIT' return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, ^ cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 'USEM_HAS_WAITERS' if (count & USEM_HAS_WAITERS) ^ 1 warning and 5 errors generated. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/r273918-buildworld-broke-at-semaphore-tp5961241.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 20:23:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C64FE46B for ; Fri, 31 Oct 2014 20:23:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B4C6CCA0 for ; Fri, 31 Oct 2014 20:23:39 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id AF2B0583 for ; Fri, 31 Oct 2014 20:23:39 +0000 (UTC) Date: Fri, 31 Oct 2014 20:23:38 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <260264135.21.1414787018889.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> References: <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #162 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 20:23:39 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 20:38:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F21ABADE for ; Fri, 31 Oct 2014 20:38:06 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) by mx1.freebsd.org (Postfix) with ESMTP id 65A7AE0A for ; Fri, 31 Oct 2014 20:38:05 +0000 (UTC) Received: from ninja.humanidyne.net ([92.145.2.167]) by mwinf5d53 with ME id 9wdx1p0033cC39G03wdxWn; Fri, 31 Oct 2014 21:37:57 +0100 X-ME-Helo: ninja.humanidyne.net X-ME-Auth: bWFydGluLm1hdG9Ab3JhbmdlLmZy X-ME-Date: Fri, 31 Oct 2014 21:37:57 +0100 X-ME-IP: 92.145.2.167 Message-ID: <5453F325.1030601@orange.fr> Date: Fri, 31 Oct 2014 21:37:57 +0100 From: Martin MATO User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <201410312000.s9VK0AWB002147@pozo.com> <5453F285.7060504@orange.fr> In-Reply-To: <5453F285.7060504@orange.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 20:38:07 -0000 Le 31.10.2014 21:35, Martin MATO a écrit : > Le 31.10.2014 21:00, Manfred Antar a écrit : >> At 12:20 PM 10/31/2014, O. Hartmann wrote: >> >>> On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption >>> after reboot. The systems do have >>> >>> FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 >>> >>> and suffer without exception from the same breakage, quitting services and/or reporting >>> corrupted filesystems after a fresh reboot - even if I've performed a manual triggered >>> "fsck -fz" in single user mode on the console. >>> >>> All systems have GPT partion schemes. >>> >>> The problem is serious! I can not get rid via fsck of the problem of corrupted >>> filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start >>> properly and need to be started manually after a reboot. >>> >>> What is wrong? The fact that several CURRENT boxes are affected the very same way (> 5 ) >>> make me confident this is a serious bug recently introduced. >>> >>> Oliver >>> >> With r273911 on amd64, after fresh build installworld. >> Upon reboot all of a sudden /var is mounted mfs. >> needless to say many problems with programs that store files in /var -- ie mysql clamav etc, etc >> I had to change the following in rc.conf to get system to work again. >> varmfs="AUTO" # Set to YES to always create an mfs /var, NO to never >> varsize="32m" # Size of mfs /var if created >> varmfs_flags="-S" # Extra mount options for the mfs /var >> populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never >> cleanvar_enable="YES" # Clean the /var directory >> >> CHANGED TO : >> varmfs="NO" # Set to YES to always create an mfs /var, NO to never >> varsize="32m" # Size of mfs /var if created >> varmfs_flags="-S" # Extra mount options for the mfs /var >> populate_var="NO" # Set to YES to always (re)populate /var, NO to never >> cleanvar_enable="NO" # Clean the /var directory >> >> Not why all of a sudden /var/ was mounted mfs. >> Maybe something to do with the new random stuff, I did a mergemaster before rebooting >> Not sure if this is related to your problem >> Manfred >> >> ======================== >> || null@pozo.com || >> || || >> ======================== >> >> > Same things here. > It appears that the ld-elf.so.hints files are not generated ( ldconfig > not executed at boot); well at least in my case. > executing manually a 'service ldconfig start' generate them. > From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 20:55:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB1DAE24; Fri, 31 Oct 2014 20:55:17 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77153FE5; Fri, 31 Oct 2014 20:55:17 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so8453720pab.12 for ; Fri, 31 Oct 2014 13:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GmstKHfkkNCYwhId+ORxbruU5aldhR2L4rvPchtWcpI=; b=sJw/JeXndKKJ3viTndRESkFmP8VF9Al7Vsu+v+DxEXQQT4qVtTCPFO4WB8WdAj6j3P j80gFgeZAt1XwODlx1c6Zh8rPi++RycZTpqHn1Q3EMUMer5dx+cWJkKYCyZRRHjAwGXM my8ch5U2unQIcuBUr7K4ierNsD8vyeyGvqqcEuEjwAiRF4sKUU9mS4zDpgv5ISLRjKLY eKPKQeuGv+WF2k9lKzCEJy1Lvxwg56L70w5K+NYthQk8BuuM0cV1P09slllS/WTOT5ko yUrAWG0g6uZOx6MgwK7U3zzZcBVs/S/8QBtY0WvBggXEcrAxg8BvTJYuLGm+bkYrBPy9 CnuQ== X-Received: by 10.66.148.74 with SMTP id tq10mr7142899pab.122.1414788917062; Fri, 31 Oct 2014 13:55:17 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:34d4:4abd:64bb:590a? ([2601:8:ab80:7d6:34d4:4abd:64bb:590a]) by mx.google.com with ESMTPSA id h1sm10777285pat.6.2014.10.31.13.55.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 13:55:15 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3D02287A-752A-4815-8255-8A9FBDAA94ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: r273910 build failure if is out-of-date From: Garrett Cooper In-Reply-To: <5453DB0C.3040106@FreeBSD.org> Date: Fri, 31 Oct 2014 13:55:14 -0700 Message-Id: <5BF6BAA7-019C-4497-AF32-F9A0FF591ECA@gmail.com> References: <5453DB0C.3040106@FreeBSD.org> To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current , zaphod@berentweb.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 20:55:17 -0000 --Apple-Mail=_3D02287A-752A-4815-8255-8A9FBDAA94ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi dumbbell@! On Oct 31, 2014, at 11:55, Jean-S=E9bastien P=E9dron = wrote: > Hi! >=20 > I have the following error when building HEAD: =85 > The problem is that the installed version of is > out-of-date compared to the version in the source tree. I guess it's > supposed to pick the version in the source tree, but I'm not sure = what's > the correct way of doing this. >=20 > FYI, this is with base gcc on sparc64. World was updated on August 6. Beeblebrox sent out the same thing in the thread titled "r273918 = buildworld broke at semaphore=94. My guess is that it=92s this bug that = I filed a while ago: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192394 , but = Beeblebrox should confirm whether or not he=92s using gcc in the build = or clang. Thanks! --Apple-Mail=_3D02287A-752A-4815-8255-8A9FBDAA94ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUU/cyAAoJEMZr5QU6S73eGdUH/R0158x/jxexy6NkkIXNzQPg mvSsar9QYmxNxFhezXrMGP8wwjnwj8W2QKuPCv3NGJ0STuNxZZigUCeibZblBddQ Dn+GTiKs2pldHX6mjRDeNWVRVd35V4OwhVXKCURiwXWBQjLPf0sjtfBPMTjYRGI4 l/zktuHTXiueJIANksPlehn9DaDEv2GQ9+Rzt+cA9nzEZ4t4TpzObNt91BfpgNVc KNVl0MkhnN+vb49BiRHCD/duaGu0zH6s0GjJqqzNCPtBafJ6NnWhVlSAMNXXwNLL e0C5+ssbnYDAVD8fcCIraLrfoub4bgMNBEHMAg494SMbbQeJuKe80MGNvgC7UmQ= =dSBg -----END PGP SIGNATURE----- --Apple-Mail=_3D02287A-752A-4815-8255-8A9FBDAA94ED-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 21:00:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDC08FB1 for ; Fri, 31 Oct 2014 21:00:13 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE99B6 for ; Fri, 31 Oct 2014 21:00:13 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id a1so7376169wgh.34 for ; Fri, 31 Oct 2014 14:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=EZyHJYQ9fJNSC56xPmUTwJLNFIU/bSu+lTGmIo/23GI=; b=JFbUi/50IkTfDzd04xayHAf612llplS87+Atl4MrN17wgF7VHamfvsmZanfSKr7DN5 ydl7IJizMMLo6u+eotURMH2TCYVI/ou07q2l3IV8YNTLCusEd0dIxeEbe3RXlmWWtfkk GgF6ciVNEsE+3iVQS3e+mSXoY1qhRR7W/bcKQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=EZyHJYQ9fJNSC56xPmUTwJLNFIU/bSu+lTGmIo/23GI=; b=hpt2SlrsHDMH+30RVG7OpnxfkosGR/fxOwHyDHWPrxKWhX+1NsORPiOBlxf7Jz7saA +OFjpuAkjaFIkAYP5OXNu9iU+95bWUU95PAFzM7MUWJqZgOrfHEpLjrZyRnBPLD5knHI IETFFFuBiTfcqMsX/hJ2SLqnet+kO79rYzgZXT/rofZV8uEqm+419Ft5eXRF2xoiYrkZ GiocBzy976W9L5eVXKJY5TYoDdvtEqjznAbHYMunht1WH/NT8i3E0bt5o9pdZOAhO6I8 LEReAuYA73iiTpIn6Z3pJUB45fJ8fSZfKLIahanRmi6ZnL1wjaeJPM86nl1X8YRWEcCq EMZw== X-Gm-Message-State: ALoCoQljqj+pS19zO1/cJkLQCEe4mlLF8bANpDGUUrOrpdKjSKoY60iUo6nDWlolHQsPT2twXfOH X-Received: by 10.194.93.194 with SMTP id cw2mr5643304wjb.112.1414789211295; Fri, 31 Oct 2014 14:00:11 -0700 (PDT) Received: from rsbsd.rsb ([83.66.212.102]) by mx.google.com with ESMTPSA id td9sm205855wic.15.2014.10.31.14.00.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Oct 2014 14:00:10 -0700 (PDT) Date: Fri, 31 Oct 2014 23:00:20 +0200 From: Beeblebrox To: Garrett Cooper Subject: Re: r273910 build failure if is out-of-date Message-ID: <20141031230020.199badb1@rsbsd.rsb> In-Reply-To: <5BF6BAA7-019C-4497-AF32-F9A0FF591ECA@gmail.com> References: <5453DB0C.3040106@FreeBSD.org> <5BF6BAA7-019C-4497-AF32-F9A0FF591ECA@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 21:00:13 -0000 Hello > Beeblebrox should confirm whether or not he=E2=80=99s using gcc in the bu= ild > or clang. Thanks! Using clang I have some tighter settings in src.conf, but nothing clang/gcc related. --=20 FreeBSD_amd64_11-Current_RadeonKMS From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 21:03:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6E0A1F3; Fri, 31 Oct 2014 21:03:27 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B11FD169; Fri, 31 Oct 2014 21:03:27 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id p10so7920231pdj.19 for ; Fri, 31 Oct 2014 14:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CCDXALXdHMchD8eZ9RbFrWgXHkP8jjlyWsmWJwqEx+M=; b=taBBPozfoV8mpv3WRB7WDCxY0r6yUYJ+PBRfAQwMZqqeVTuSxGNBsjE8COkmeDc19U yYxCcFo+NWoFskn6WsjdLTb6PmuJCkdCq6KJFJWk5GB8++EOv/cv5Yick0MznHqSPE18 cP6tqBAJ280l7qmId1GPJWmasPzFEXwT3n+vq9IcD5AxsSG1yKWwlXWAbcFxwqZot1jr JinB/up7S7riKCN5y6dNjylJ3uOS6a1yBN+HiQapZqMZ16i9Osqag5r+eUZqDREeZz+d TZvLtu6zdbjq7accRSsb4J+XFITJhAmfYcM8P+fjIe92TudrB7PB+DqCGr3u6XUqxi36 xSOg== X-Received: by 10.66.218.168 with SMTP id ph8mr27055322pac.51.1414789406738; Fri, 31 Oct 2014 14:03:26 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:34d4:4abd:64bb:590a? ([2601:8:ab80:7d6:34d4:4abd:64bb:590a]) by mx.google.com with ESMTPSA id g3sm10747563pdh.33.2014.10.31.14.03.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 14:03:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_89CEAC5E-A351-4CDD-B822-CB12880139F9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: r273910 build failure if is out-of-date From: Garrett Cooper In-Reply-To: <20141031230020.199badb1@rsbsd.rsb> Date: Fri, 31 Oct 2014 14:03:24 -0700 Message-Id: References: <5453DB0C.3040106@FreeBSD.org> <5BF6BAA7-019C-4497-AF32-F9A0FF591ECA@gmail.com> <20141031230020.199badb1@rsbsd.rsb> To: Beeblebrox X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current , =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 21:03:28 -0000 --Apple-Mail=_89CEAC5E-A351-4CDD-B822-CB12880139F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 31, 2014, at 14:00, Beeblebrox wrote: > Hello >=20 >> Beeblebrox should confirm whether or not he=92s using gcc in the = build >> or clang. Thanks! >=20 > Using clang > I have some tighter settings in src.conf, but nothing clang/gcc = related. Hi! Do you have WITHOUT_CLANG_BOOTSTRAP set? Thanks! --Apple-Mail=_89CEAC5E-A351-4CDD-B822-CB12880139F9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUU/kcAAoJEMZr5QU6S73ey4UH/0wFk8eJlyt9/5PXpQUKxP1+ fPrnrS4Bx8vxN1g2G6eTWckbS4ffElPWMVFk9hZjQQWz6gv5b1SSELrgzApgnHpm PWzuY+T/P2q1/dmPK2Nc2bU4kvbBETXqic2Q9ct+Z+6VVCwOSOdeV4f9KqkCG3Pn vqNIOBspCsYbH2dyWHmA0x3sAcO/I4QkUaBuwrFQT0pCx40QmO8J1VFmJ0qFJ+M+ QRGC3OmQt3rpF/5fShGRR8CpAC1OnkiNoWcaT/7ODi4kLVggmOgQ6z1ASywVPDEP ptCqGa8/dAKwMkzIpnoRT/kJMYMdnOewQhNwQWdzpAXhT0Qr06JjrUYzJU0Xhmg= =2+9W -----END PGP SIGNATURE----- --Apple-Mail=_89CEAC5E-A351-4CDD-B822-CB12880139F9-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 21:12:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9512A537 for ; Fri, 31 Oct 2014 21:12:16 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23312269 for ; Fri, 31 Oct 2014 21:12:15 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so7312131wgh.38 for ; Fri, 31 Oct 2014 14:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=nffKit+US72Y3izW8O0Fn7+fyb66dMnd1gByExoJa5o=; b=IjeLBJFyEtesdMqHD7c4w9NXvNA7WvM8LmBsHRCZ83ba/5qMpq/WwRlQkXjiZmK6pH GmGHTP/DLDcVrS8L7pjHPbYrDfTGBRqqV0CPZM0DMm40MRT1MsrdYj/7A/ToceGKyFYn LqJrgvyL/07Kurh3e6SwpVSfwM2pyBQmjzBA8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=nffKit+US72Y3izW8O0Fn7+fyb66dMnd1gByExoJa5o=; b=Aohu8GWZSXLcanEheJkbfJFiW6S48gnWsDHCm+CR+mzMi3ObIfC566cbas+QzYtpIy odlfJijth8RPXZ48D5k6MiyOBqZyuoZiBxFqbuSX5LzUfRyfA7Eq758yCRMgIV2zWj2h M536Bc+MUF/q3CFrn3OSnzyaIbgyDqErr5UNBQOAyZcu08kP2OKHm6uAKc9bncGM87wR aSHOSnE/Ze1X6wpWMxVGtY88t2p0eckMaNfN0fmCWii7sL6Oqu20kYqelEzaDRA39NWZ K2RehCaYZ+kVDeNd8yxXBHItBosa1v0macG/mdNmP+Ko9tElDYCeKtuohxqo1jqFtHxl i/Yw== X-Gm-Message-State: ALoCoQk1hg5VLlf7FXdZPaHaT1jz8eIIX/ExSgmVXIjeIgg1Z9Cy9TDPp/ToUlzcI6xb8lMpE0EK X-Received: by 10.180.210.167 with SMTP id mv7mr6616281wic.15.1414789934410; Fri, 31 Oct 2014 14:12:14 -0700 (PDT) Received: from rsbsd.rsb ([83.66.212.102]) by mx.google.com with ESMTPSA id td9sm233445wic.15.2014.10.31.14.12.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Oct 2014 14:12:13 -0700 (PDT) Date: Fri, 31 Oct 2014 23:12:24 +0200 From: Beeblebrox To: Garrett Cooper Subject: Re: r273910 build failure if is out-of-date Message-ID: <20141031231224.1f2e03d3@rsbsd.rsb> In-Reply-To: References: <5453DB0C.3040106@FreeBSD.org> <5BF6BAA7-019C-4497-AF32-F9A0FF591ECA@gmail.com> <20141031230020.199badb1@rsbsd.rsb> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 21:12:16 -0000 > Hi! > Do you have WITHOUT_CLANG_BOOTSTRAP set? > Thanks! No. No clang/gcc settings. All src.conf WITHOUT entries are of the sort=20 INET6, PORTSNAP, BLUETOOTH, etc I DO use ccache --=20 FreeBSD_amd64_11-Current_RadeonKMS From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 21:23:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 258CF86C for ; Fri, 31 Oct 2014 21:23:28 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D8EA938A for ; Fri, 31 Oct 2014 21:23:27 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 75FCFADD8; Fri, 31 Oct 2014 21:23:26 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 4494F10969; Fri, 31 Oct 2014 22:23:28 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Oliver Hartmann , Manfred Antar , Martin MATO Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> Date: Fri, 31 Oct 2014 22:23:28 +0100 In-Reply-To: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> (O. Hartmann's message of "Fri, 31 Oct 2014 20:20:45 +0100") Message-ID: <86a94c9bn3.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 21:23:28 -0000 Can you all please tell me which revision(s) you were running before you upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" should do the trick. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 21:47:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 161B2589 for ; Fri, 31 Oct 2014 21:47:45 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFA88CF for ; Fri, 31 Oct 2014 21:47:43 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s9VLibrl005098; Fri, 31 Oct 2014 22:44:45 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <545402C9.4070901@fgznet.ch> Date: Fri, 31 Oct 2014 22:44:41 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Oliver Hartmann , Manfred Antar , Martin MATO Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> In-Reply-To: <86a94c9bn3.fsf@nine.des.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 21:47:45 -0000 On 31.10.14 22:23, Dag-Erling Smørgrav wrote: > Can you all please tell me which revision(s) you were running before you > upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" > should do the trick. +1 here. 'Corrupted' /usr. Changed entry in fstab to not check fs. [zrhws131:/boot/kernel.old] andreast% strings kernel | grep CURRENT @(#)FreeBSD 11.0-CURRENT #33 r273767M: Tue Oct 28 11:20:32 CET 2014 Andreas From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 21:52:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95953711 for ; Fri, 31 Oct 2014 21:52:40 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by mx1.freebsd.org (Postfix) with ESMTP id 327E9993 for ; Fri, 31 Oct 2014 21:52:38 +0000 (UTC) Received: from pcgyver.mooo.com ([92.145.2.167]) by mwinf5d35 with ME id 9xsX1p0073cC39G03xsXZX; Fri, 31 Oct 2014 22:52:32 +0100 X-ME-Helo: pcgyver.mooo.com X-ME-Auth: bWFydGluLm1hdG9Ab3JhbmdlLmZy X-ME-Date: Fri, 31 Oct 2014 22:52:32 +0100 X-ME-IP: 92.145.2.167 Received: from [192.168.0.3] (lincoln.humanidyne.net [192.168.0.3]) by pcgyver.mooo.com (8.14.9/8.14.9) with ESMTP id s9VLqUZA094189; Fri, 31 Oct 2014 22:52:30 +0100 (CET) (envelope-from martin.mato@orange.fr) Message-ID: <54540442.4070204@orange.fr> Date: Fri, 31 Oct 2014 22:50:58 +0100 From: Martin MATO Reply-To: martin.mato@orange.fr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , freebsd-current@freebsd.org Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> In-Reply-To: <86a94c9bn3.fsf@nine.des.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 21:52:40 -0000 Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : > Can you all please tell me which revision(s) you were running before you > upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" > should do the trick. > > DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 22:32:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA31D662 for ; Fri, 31 Oct 2014 22:32:29 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C4DFDC7 for ; Fri, 31 Oct 2014 22:32:29 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.9/8.14.9) with ESMTP id s9VMVsT1002148 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 15:31:55 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201410312231.s9VMVsT1002148@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 31 Oct 2014 15:31:54 -0700 To: Andreas Tobler , Dag-Erling =?iso-8859-1?Q?Sm=C3=B8rgrav?= , Oliver Hartmann , Martin MATO From: Manfred Antar Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! In-Reply-To: <545402C9.4070901@fgznet.ch> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-102.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID,URIBL_BLOCKED,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0, No X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: s9VMVsT1002148 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 22:32:29 -0000 At 02:44 PM 10/31/2014, Andreas Tobler wrote: >On 31.10.14 22:23, Dag-Erling Sm=C3=B8rgrav wrote: >>Can you all please tell me which revision(s) you were running before you >>upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" >>should do the trick. > >+1 here. 'Corrupted' /usr. Changed entry in fstab to not check fs. > >[zrhws131:/boot/kernel.old] andreast% strings kernel | grep CURRENT >@(#)FreeBSD 11.0-CURRENT #33 r273767M: Tue Oct 28 11:20:32 CET 2014 > >Andreas > > > FreeBSD 11.0-CURRENT #0 r273905: Fri Oct 31 06:15:56 PDT 2014 11.0-CURRENT No corruption here, during the last few days i was getting sysctl-random er= ror during boot. So today I did a buildworld installworld buildkernel installkernel, and mer= gemaster . some of the /etc/rc.d/random files were updated. Reboot Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=3D"NO" and cleanvar_enable=3D"NO" everything works fine. I noticed one thing during boot: Writing entropy file:random: unblocking device. takes a little longer=20 I changed to entropy_save_sz=3D"4096" in /etc/rc.conf, maybe thats why. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D || null@pozo.com || || || =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 22:37:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAB817E8 for ; Fri, 31 Oct 2014 22:37:27 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4B0DFC for ; Fri, 31 Oct 2014 22:37:25 +0000 (UTC) Received: from pcgyver.mooo.com ([92.145.2.167]) by mwinf5d35 with ME id 9yd51p00G3cC39G03ydMGo; Fri, 31 Oct 2014 23:37:24 +0100 X-ME-Helo: pcgyver.mooo.com X-ME-Auth: bWFydGluLm1hdG9Ab3JhbmdlLmZy X-ME-Date: Fri, 31 Oct 2014 23:37:24 +0100 X-ME-IP: 92.145.2.167 Received: from [192.168.0.3] (lincoln.humanidyne.net [192.168.0.3]) by pcgyver.mooo.com (8.14.9/8.14.9) with ESMTP id s9VMb4VU024346; Fri, 31 Oct 2014 23:37:05 +0100 (CET) (envelope-from martin.mato@orange.fr) Message-ID: <54540EB4.80207@orange.fr> Date: Fri, 31 Oct 2014 23:35:32 +0100 From: Martin MATO Reply-To: martin.mato@orange.fr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , freebsd-current@freebsd.org Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <54540442.4070204@orange.fr> In-Reply-To: <54540442.4070204@orange.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.18-1 Precedence: 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, 31 Oct 2014 22:37:27 -0000 Le 31/10/2014 22:50, Martin MATO a écrit : > Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : >> Can you all please tell me which revision(s) you were running before you >> upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" >> should do the trick. >> >> DES > Absolutely > here it is > > /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 > r273863: Thu Oct 30 16:55:16 CET 2014 > > ps: there is no filesystem corruption (first thing i checked twice.) > > _______________________________________________ > 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" the is one thing i noticed: there is a new directory under /usr called "tests" containing several directories and files maybe something goes wrong in the 'make installworld' part ? the timestamps are more or less when i tried to upgrade world. i'm reverting back to 273863 to see if i get a system functionnal. find /usr/tests/ /usr/tests/ /usr/tests/bin /usr/tests/bin/chown /usr/tests/bin/chown/chown-f_test /usr/tests/bin/chown/Kyuafile /usr/tests/bin/date /usr/tests/bin/date/Kyuafile /usr/tests/bin/date/format_string_test /usr/tests/bin/mv /usr/tests/bin/mv/legacy_test /usr/tests/bin/mv/Kyuafile /usr/tests/bin/pax /usr/tests/bin/pax/legacy_test /usr/tests/bin/pax/Kyuafile /usr/tests/bin/pkill /usr/tests/bin/pkill/pgrep-F_test /usr/tests/bin/pkill/pgrep-LF_test /usr/tests/bin/pkill/pgrep-P_test /usr/tests/bin/pkill/pgrep-U_test /usr/tests/bin/pkill/pgrep-_g_test /usr/tests/bin/pkill/pgrep-_s_test /usr/tests/bin/pkill/pgrep-g_test /usr/tests/bin/pkill/pgrep-i_test /usr/tests/bin/pkill/pgrep-j_test /usr/tests/bin/pkill/pgrep-l_test /usr/tests/bin/pkill/pgrep-n_test /usr/tests/bin/pkill/pgrep-o_test /usr/tests/bin/pkill/pgrep-q_test /usr/tests/bin/pkill/pgrep-s_test /usr/tests/bin/pkill/pgrep-t_test /usr/tests/bin/pkill/pgrep-v_test /usr/tests/bin/pkill/pgrep-x_test /usr/tests/bin/pkill/pkill-F_test /usr/tests/bin/pkill/pkill-LF_test /usr/tests/bin/pkill/pkill-P_test /usr/tests/bin/pkill/pkill-U_test /usr/tests/bin/pkill/pkill-_g_test /usr/tests/bin/pkill/pkill-g_test /usr/tests/bin/pkill/pkill-i_test /usr/tests/bin/pkill/pkill-j_test /usr/tests/bin/pkill/pkill-s_test /usr/tests/bin/pkill/pkill-t_test /usr/tests/bin/pkill/pkill-x_test /usr/tests/bin/pkill/Kyuafile /usr/tests/bin/sh /usr/tests/bin/sh/builtins /usr/tests/bin/sh/builtins/alias.0 /usr/tests/bin/sh/builtins/alias.0.stdout /usr/tests/bin/sh/builtins/alias.1 /usr/tests/bin/sh/builtins/alias.1.stderr /usr/tests/bin/sh/builtins/alias3.0 /usr/tests/bin/sh/builtins/alias3.0.stdout /usr/tests/bin/sh/builtins/alias4.0 /usr/tests/bin/sh/builtins/break1.0 /usr/tests/bin/sh/builtins/break2.0 /usr/tests/bin/sh/builtins/break2.0.stdout /usr/tests/bin/sh/builtins/break3.0 /usr/tests/bin/sh/builtins/break4.4 /usr/tests/bin/sh/builtins/break5.4 /usr/tests/bin/sh/builtins/break6.0 /usr/tests/bin/sh/builtins/builtin1.0 /usr/tests/bin/sh/builtins/case1.0 /usr/tests/bin/sh/builtins/case2.0 /usr/tests/bin/sh/builtins/case3.0 /usr/tests/bin/sh/builtins/case4.0 /usr/tests/bin/sh/builtins/case5.0 /usr/tests/bin/sh/builtins/case6.0 /usr/tests/bin/sh/builtins/case7.0 /usr/tests/bin/sh/builtins/case8.0 /usr/tests/bin/sh/builtins/case9.0 /usr/tests/bin/sh/builtins/case10.0 /usr/tests/bin/sh/builtins/cd1.0 /usr/tests/bin/sh/builtins/case11.0 /usr/tests/bin/sh/builtins/case12.0 /usr/tests/bin/sh/builtins/case13.0 /usr/tests/bin/sh/builtins/case14.0 /usr/tests/bin/sh/builtins/case15.0 /usr/tests/bin/sh/builtins/case16.0 /usr/tests/bin/sh/builtins/case17.0 /usr/tests/bin/sh/builtins/case18.0 /usr/tests/bin/sh/builtins/case19.0 /usr/tests/bin/sh/builtins/cd2.0 /usr/tests/bin/sh/builtins/cd3.0 /usr/tests/bin/sh/builtins/cd4.0 /usr/tests/bin/sh/builtins/cd5.0 /usr/tests/bin/sh/builtins/cd6.0 /usr/tests/bin/sh/builtins/cd7.0 /usr/tests/bin/sh/builtins/cd8.0 /usr/tests/bin/sh/builtins/command1.0 /usr/tests/bin/sh/builtins/command2.0 /usr/tests/bin/sh/builtins/command3.0 /usr/tests/bin/sh/builtins/command3.0.stdout /usr/tests/bin/sh/builtins/command4.0 /usr/tests/bin/sh/builtins/command5.0 /usr/tests/bin/sh/builtins/command5.0.stdout /usr/tests/bin/sh/builtins/command6.0 /usr/tests/bin/sh/builtins/command6.0.stdout /usr/tests/bin/sh/builtins/dot1.0 /usr/tests/bin/sh/builtins/command7.0 /usr/tests/bin/sh/builtins/command8.0 /usr/tests/bin/sh/builtins/command9.0 /usr/tests/bin/sh/builtins/command10.0 /usr/tests/bin/sh/builtins/command11.0 /usr/tests/bin/sh/builtins/command12.0 /usr/tests/bin/sh/builtins/dot2.0 /usr/tests/bin/sh/builtins/dot3.0 /usr/tests/bin/sh/builtins/dot4.0 /usr/tests/bin/sh/builtins/eval1.0 /usr/tests/bin/sh/builtins/eval2.0 /usr/tests/bin/sh/builtins/eval3.0 /usr/tests/bin/sh/builtins/eval4.0 /usr/tests/bin/sh/builtins/eval5.0 /usr/tests/bin/sh/builtins/eval6.0 /usr/tests/bin/sh/builtins/exec1.0 /usr/tests/bin/sh/builtins/exec2.0 /usr/tests/bin/sh/builtins/exit1.0 /usr/tests/bin/sh/builtins/exit2.8 /usr/tests/bin/sh/builtins/exit3.0 /usr/tests/bin/sh/builtins/export1.0 /usr/tests/bin/sh/builtins/fc1.0 /usr/tests/bin/sh/builtins/fc2.0 /usr/tests/bin/sh/builtins/for1.0 /usr/tests/bin/sh/builtins/for2.0 /usr/tests/bin/sh/builtins/for3.0 /usr/tests/bin/sh/builtins/getopts1.0 /usr/tests/bin/sh/builtins/getopts1.0.stdout /usr/tests/bin/sh/builtins/getopts2.0 /usr/tests/bin/sh/builtins/getopts2.0.stdout /usr/tests/bin/sh/builtins/getopts3.0 /usr/tests/bin/sh/builtins/getopts4.0 /usr/tests/bin/sh/builtins/getopts5.0 /usr/tests/bin/sh/builtins/getopts6.0 /usr/tests/bin/sh/builtins/getopts7.0 /usr/tests/bin/sh/builtins/getopts8.0 /usr/tests/bin/sh/builtins/getopts8.0.stdout /usr/tests/bin/sh/builtins/hash1.0.stdout /usr/tests/bin/sh/builtins/hash2.0 /usr/tests/bin/sh/builtins/hash2.0.stdout /usr/tests/bin/sh/builtins/hash3.0 /usr/tests/bin/sh/builtins/hash3.0.stdout /usr/tests/bin/sh/builtins/hash4.0 /usr/tests/bin/sh/builtins/jobid1.0 /usr/tests/bin/sh/builtins/jobid2.0 /usr/tests/bin/sh/builtins/kill1.0 /usr/tests/bin/sh/builtins/kill2.0 /usr/tests/bin/sh/builtins/lineno.0 /usr/tests/bin/sh/builtins/lineno.0.stdout /usr/tests/bin/sh/builtins/lineno2.0 /usr/tests/bin/sh/builtins/local1.0 /usr/tests/bin/sh/builtins/local2.0 /usr/tests/bin/sh/builtins/local3.0 /usr/tests/bin/sh/builtins/local4.0 /usr/tests/bin/sh/builtins/locale1.0 /usr/tests/bin/sh/builtins/printf1.0 /usr/tests/bin/sh/builtins/printf2.0 /usr/tests/bin/sh/builtins/printf3.0 /usr/tests/bin/sh/builtins/printf4.0 /usr/tests/bin/sh/builtins/read1.0 /usr/tests/bin/sh/builtins/read1.0.stdout /usr/tests/bin/sh/builtins/read2.0 /usr/tests/bin/sh/builtins/read3.0 /usr/tests/bin/sh/builtins/read3.0.stdout /usr/tests/bin/sh/builtins/read4.0 /usr/tests/bin/sh/builtins/read4.0.stdout /usr/tests/bin/sh/builtins/read5.0 /usr/tests/bin/sh/builtins/read6.0 /usr/tests/bin/sh/builtins/read7.0 /usr/tests/bin/sh/builtins/return1.0 /usr/tests/bin/sh/builtins/return2.1 /usr/tests/bin/sh/builtins/return3.1 /usr/tests/bin/sh/builtins/return4.0 /usr/tests/bin/sh/builtins/return5.0 /usr/tests/bin/sh/builtins/return6.4 /usr/tests/bin/sh/builtins/return7.4 /usr/tests/bin/sh/builtins/return8.0 /usr/tests/bin/sh/builtins/set1.0 /usr/tests/bin/sh/builtins/set2.0 /usr/tests/bin/sh/builtins/trap1.0 /usr/tests/bin/sh/builtins/trap10.0 /usr/tests/bin/sh/builtins/trap11.0 /usr/tests/bin/sh/builtins/trap12.0 /usr/tests/bin/sh/builtins/trap13.0 /usr/tests/bin/sh/builtins/trap14.0 /usr/tests/bin/sh/builtins/trap2.0 /usr/tests/bin/sh/builtins/trap3.0 /usr/tests/bin/sh/builtins/trap4.0 /usr/tests/bin/sh/builtins/trap5.0 /usr/tests/bin/sh/builtins/trap6.0 /usr/tests/bin/sh/builtins/trap7.0 /usr/tests/bin/sh/builtins/trap8.0 /usr/tests/bin/sh/builtins/trap9.0 /usr/tests/bin/sh/builtins/type1.0 /usr/tests/bin/sh/builtins/type1.0.stderr /usr/tests/bin/sh/builtins/type2.0 /usr/tests/bin/sh/builtins/type3.0 /usr/tests/bin/sh/builtins/unalias.0 /usr/tests/bin/sh/builtins/var-assign.0 /usr/tests/bin/sh/builtins/var-assign2.0 /usr/tests/bin/sh/builtins/wait1.0 /usr/tests/bin/sh/builtins/wait2.0 /usr/tests/bin/sh/builtins/wait3.0 /usr/tests/bin/sh/builtins/wait4.0 /usr/tests/bin/sh/builtins/wait5.0 /usr/tests/bin/sh/builtins/wait6.0 /usr/tests/bin/sh/builtins/wait7.0 /usr/tests/bin/sh/builtins/wait8.0 /usr/tests/bin/sh/builtins/wait9.127 /usr/tests/bin/sh/builtins/hash1.0 /usr/tests/bin/sh/builtins/wait10.0 /usr/tests/bin/sh/builtins/functional_test /usr/tests/bin/sh/builtins/Kyuafile /usr/tests/bin/sh/builtins/lineno3.0 /usr/tests/bin/sh/builtins/lineno3.0.stdout /usr/tests/bin/sh/builtins/eval7.0 /usr/tests/bin/sh/builtins/eval8.7 /usr/tests/bin/sh/errors /usr/tests/bin/sh/errors/assignment-error1.0 /usr/tests/bin/sh/errors/assignment-error2.0 /usr/tests/bin/sh/errors/backquote-error1.0 /usr/tests/bin/sh/errors/backquote-error2.0 /usr/tests/bin/sh/errors/bad-binary1.126 /usr/tests/bin/sh/errors/bad-keyword1.0 /usr/tests/bin/sh/errors/bad-parm-exp1.0 /usr/tests/bin/sh/errors/bad-parm-exp2.2 /usr/tests/bin/sh/errors/bad-parm-exp2.2.stderr /usr/tests/bin/sh/errors/bad-parm-exp3.2 /usr/tests/bin/sh/errors/bad-parm-exp3.2.stderr /usr/tests/bin/sh/errors/bad-parm-exp4.2 /usr/tests/bin/sh/errors/bad-parm-exp4.2.stderr /usr/tests/bin/sh/errors/bad-parm-exp5.2 /usr/tests/bin/sh/errors/bad-parm-exp5.2.stderr /usr/tests/bin/sh/errors/bad-parm-exp6.2 /usr/tests/bin/sh/errors/bad-parm-exp6.2.stderr /usr/tests/bin/sh/errors/option-error.0 /usr/tests/bin/sh/errors/redirection-error.0 /usr/tests/bin/sh/errors/redirection-error2.2 /usr/tests/bin/sh/errors/redirection-error3.0 /usr/tests/bin/sh/errors/redirection-error4.0 /usr/tests/bin/sh/errors/redirection-error5.0 /usr/tests/bin/sh/errors/redirection-error6.0 /usr/tests/bin/sh/errors/redirection-error7.0 /usr/tests/bin/sh/errors/write-error1.0 /usr/tests/bin/sh/errors/functional_test /usr/tests/bin/sh/errors/Kyuafile /usr/tests/bin/sh/execution /usr/tests/bin/sh/execution/bg1.0 /usr/tests/bin/sh/execution/bg2.0 /usr/tests/bin/sh/execution/bg3.0 /usr/tests/bin/sh/execution/bg4.0 /usr/tests/bin/sh/execution/bg5.0 /usr/tests/bin/sh/execution/bg6.0 /usr/tests/bin/sh/execution/bg6.0.stdout /usr/tests/bin/sh/execution/bg7.0 /usr/tests/bin/sh/execution/bg8.0 /usr/tests/bin/sh/execution/bg9.0 /usr/tests/bin/sh/execution/bg10.0 /usr/tests/bin/sh/execution/bg10.0.stdout /usr/tests/bin/sh/execution/fork1.0 /usr/tests/bin/sh/execution/fork2.0 /usr/tests/bin/sh/execution/fork3.0 /usr/tests/bin/sh/execution/func1.0 /usr/tests/bin/sh/execution/func2.0 /usr/tests/bin/sh/execution/func3.0 /usr/tests/bin/sh/execution/hash1.0 /usr/tests/bin/sh/execution/int-cmd1.0 /usr/tests/bin/sh/execution/killed1.0 /usr/tests/bin/sh/execution/killed2.0 /usr/tests/bin/sh/execution/not1.0 /usr/tests/bin/sh/execution/not2.0 /usr/tests/bin/sh/execution/path1.0 /usr/tests/bin/sh/execution/redir1.0 /usr/tests/bin/sh/execution/redir2.0 /usr/tests/bin/sh/execution/redir3.0 /usr/tests/bin/sh/execution/redir4.0 /usr/tests/bin/sh/execution/redir5.0 /usr/tests/bin/sh/execution/redir6.0 /usr/tests/bin/sh/execution/redir7.0 /usr/tests/bin/sh/execution/set-n1.0 /usr/tests/bin/sh/execution/set-n2.0 /usr/tests/bin/sh/execution/set-n3.0 /usr/tests/bin/sh/execution/set-n4.0 /usr/tests/bin/sh/execution/set-x1.0 /usr/tests/bin/sh/execution/set-x2.0 /usr/tests/bin/sh/execution/set-x3.0 /usr/tests/bin/sh/execution/shellproc1.0 /usr/tests/bin/sh/execution/subshell1.0 /usr/tests/bin/sh/execution/subshell1.0.stdout /usr/tests/bin/sh/execution/subshell2.0 /usr/tests/bin/sh/execution/subshell3.0 /usr/tests/bin/sh/execution/subshell4.0 /usr/tests/bin/sh/execution/unknown1.0 /usr/tests/bin/sh/execution/var-assign1.0 /usr/tests/bin/sh/execution/functional_test /usr/tests/bin/sh/execution/Kyuafile /usr/tests/bin/sh/expansion /usr/tests/bin/sh/expansion/arith1.0 /usr/tests/bin/sh/expansion/arith2.0 /usr/tests/bin/sh/expansion/arith3.0 /usr/tests/bin/sh/expansion/arith4.0 /usr/tests/bin/sh/expansion/arith5.0 /usr/tests/bin/sh/expansion/arith6.0 /usr/tests/bin/sh/expansion/arith7.0 /usr/tests/bin/sh/expansion/arith8.0 /usr/tests/bin/sh/expansion/arith9.0 /usr/tests/bin/sh/expansion/arith10.0 /usr/tests/bin/sh/expansion/arith11.0 /usr/tests/bin/sh/expansion/arith12.0 /usr/tests/bin/sh/expansion/arith13.0 /usr/tests/bin/sh/expansion/assign1.0 /usr/tests/bin/sh/expansion/cmdsubst1.0 /usr/tests/bin/sh/expansion/cmdsubst2.0 /usr/tests/bin/sh/expansion/cmdsubst3.0 /usr/tests/bin/sh/expansion/cmdsubst4.0 /usr/tests/bin/sh/expansion/cmdsubst5.0 /usr/tests/bin/sh/expansion/cmdsubst6.0 /usr/tests/bin/sh/expansion/cmdsubst7.0 /usr/tests/bin/sh/expansion/cmdsubst8.0 /usr/tests/bin/sh/expansion/cmdsubst9.0 /usr/tests/bin/sh/expansion/cmdsubst10.0 /usr/tests/bin/sh/expansion/cmdsubst11.0 /usr/tests/bin/sh/expansion/cmdsubst12.0 /usr/tests/bin/sh/expansion/cmdsubst13.0 /usr/tests/bin/sh/expansion/cmdsubst14.0 /usr/tests/bin/sh/expansion/cmdsubst15.0 /usr/tests/bin/sh/expansion/cmdsubst16.0 /usr/tests/bin/sh/expansion/cmdsubst17.0 /usr/tests/bin/sh/expansion/export1.0 /usr/tests/bin/sh/expansion/export2.0 /usr/tests/bin/sh/expansion/export3.0 /usr/tests/bin/sh/expansion/heredoc1.0 /usr/tests/bin/sh/expansion/heredoc2.0 /usr/tests/bin/sh/expansion/ifs1.0 /usr/tests/bin/sh/expansion/ifs2.0 /usr/tests/bin/sh/expansion/ifs3.0 /usr/tests/bin/sh/expansion/ifs4.0 /usr/tests/bin/sh/expansion/length1.0 /usr/tests/bin/sh/expansion/length2.0 /usr/tests/bin/sh/expansion/length3.0 /usr/tests/bin/sh/expansion/length4.0 /usr/tests/bin/sh/expansion/length5.0 /usr/tests/bin/sh/expansion/length6.0 /usr/tests/bin/sh/expansion/length7.0 /usr/tests/bin/sh/expansion/length8.0 /usr/tests/bin/sh/expansion/local1.0 /usr/tests/bin/sh/expansion/local2.0 /usr/tests/bin/sh/expansion/pathname1.0 /usr/tests/bin/sh/expansion/pathname2.0 /usr/tests/bin/sh/expansion/pathname3.0 /usr/tests/bin/sh/expansion/pathname4.0 /usr/tests/bin/sh/expansion/plus-minus1.0 /usr/tests/bin/sh/expansion/plus-minus2.0 /usr/tests/bin/sh/expansion/plus-minus3.0 /usr/tests/bin/sh/expansion/plus-minus4.0 /usr/tests/bin/sh/expansion/plus-minus5.0 /usr/tests/bin/sh/expansion/plus-minus6.0 /usr/tests/bin/sh/expansion/plus-minus7.0 /usr/tests/bin/sh/expansion/plus-minus8.0 /usr/tests/bin/sh/expansion/question1.0 /usr/tests/bin/sh/expansion/readonly1.0 /usr/tests/bin/sh/expansion/set-u1.0 /usr/tests/bin/sh/expansion/set-u2.0 /usr/tests/bin/sh/expansion/set-u3.0 /usr/tests/bin/sh/expansion/tilde1.0 /usr/tests/bin/sh/expansion/tilde2.0 /usr/tests/bin/sh/expansion/trim1.0 /usr/tests/bin/sh/expansion/trim2.0 /usr/tests/bin/sh/expansion/trim3.0 /usr/tests/bin/sh/expansion/trim4.0 /usr/tests/bin/sh/expansion/trim5.0 /usr/tests/bin/sh/expansion/trim6.0 /usr/tests/bin/sh/expansion/trim7.0 /usr/tests/bin/sh/expansion/trim8.0 /usr/tests/bin/sh/expansion/functional_test /usr/tests/bin/sh/expansion/Kyuafile /usr/tests/bin/sh/expansion/arith14.0 /usr/tests/bin/sh/parameters /usr/tests/bin/sh/parameters/env1.0 /usr/tests/bin/sh/parameters/exitstatus1.0 /usr/tests/bin/sh/parameters/mail1.0 /usr/tests/bin/sh/parameters/mail2.0 /usr/tests/bin/sh/parameters/optind1.0 /usr/tests/bin/sh/parameters/optind2.0 /usr/tests/bin/sh/parameters/positional1.0 /usr/tests/bin/sh/parameters/positional2.0 /usr/tests/bin/sh/parameters/positional3.0 /usr/tests/bin/sh/parameters/positional4.0 /usr/tests/bin/sh/parameters/positional5.0 /usr/tests/bin/sh/parameters/pwd1.0 /usr/tests/bin/sh/parameters/pwd2.0 /usr/tests/bin/sh/parameters/functional_test /usr/tests/bin/sh/parameters/Kyuafile /usr/tests/bin/sh/parameters/positional6.0 /usr/tests/bin/sh/parameters/positional7.0 /usr/tests/bin/sh/parser /usr/tests/bin/sh/parser/alias1.0 /usr/tests/bin/sh/parser/alias2.0 /usr/tests/bin/sh/parser/alias3.0 /usr/tests/bin/sh/parser/alias4.0 /usr/tests/bin/sh/parser/alias5.0 /usr/tests/bin/sh/parser/alias6.0 /usr/tests/bin/sh/parser/alias7.0 /usr/tests/bin/sh/parser/alias8.0 /usr/tests/bin/sh/parser/alias9.0 /usr/tests/bin/sh/parser/alias10.0 /usr/tests/bin/sh/parser/alias11.0 /usr/tests/bin/sh/parser/alias12.0 /usr/tests/bin/sh/parser/alias13.0 /usr/tests/bin/sh/parser/alias14.0 /usr/tests/bin/sh/parser/alias15.0 /usr/tests/bin/sh/parser/alias15.0.stdout /usr/tests/bin/sh/parser/and-pipe-not.0 /usr/tests/bin/sh/parser/case1.0 /usr/tests/bin/sh/parser/case2.0 /usr/tests/bin/sh/parser/dollar-quote1.0 /usr/tests/bin/sh/parser/dollar-quote2.0 /usr/tests/bin/sh/parser/dollar-quote3.0 /usr/tests/bin/sh/parser/dollar-quote4.0 /usr/tests/bin/sh/parser/dollar-quote5.0 /usr/tests/bin/sh/parser/dollar-quote6.0 /usr/tests/bin/sh/parser/dollar-quote7.0 /usr/tests/bin/sh/parser/dollar-quote8.0 /usr/tests/bin/sh/parser/dollar-quote9.0 /usr/tests/bin/sh/parser/dollar-quote10.0 /usr/tests/bin/sh/parser/dollar-quote11.0 /usr/tests/bin/sh/parser/empty-braces1.0 /usr/tests/bin/sh/parser/empty-cmd1.0 /usr/tests/bin/sh/parser/for1.0 /usr/tests/bin/sh/parser/for2.0 /usr/tests/bin/sh/parser/func1.0 /usr/tests/bin/sh/parser/func2.0 /usr/tests/bin/sh/parser/func3.0 /usr/tests/bin/sh/parser/heredoc1.0 /usr/tests/bin/sh/parser/heredoc2.0 /usr/tests/bin/sh/parser/heredoc3.0 /usr/tests/bin/sh/parser/heredoc4.0 /usr/tests/bin/sh/parser/heredoc5.0 /usr/tests/bin/sh/parser/heredoc6.0 /usr/tests/bin/sh/parser/heredoc7.0 /usr/tests/bin/sh/parser/heredoc8.0 /usr/tests/bin/sh/parser/heredoc9.0 /usr/tests/bin/sh/parser/heredoc10.0 /usr/tests/bin/sh/parser/heredoc11.0 /usr/tests/bin/sh/parser/no-space1.0 /usr/tests/bin/sh/parser/no-space2.0 /usr/tests/bin/sh/parser/only-redir1.0 /usr/tests/bin/sh/parser/only-redir2.0 /usr/tests/bin/sh/parser/only-redir3.0 /usr/tests/bin/sh/parser/only-redir4.0 /usr/tests/bin/sh/parser/pipe-not1.0 /usr/tests/bin/sh/parser/var-assign1.0 /usr/tests/bin/sh/parser/functional_test /usr/tests/bin/sh/parser/Kyuafile /usr/tests/bin/sh/parser/heredoc12.0 /usr/tests/bin/sh/parser/line-cont1.0 /usr/tests/bin/sh/parser/line-cont2.0 /usr/tests/bin/sh/parser/line-cont3.0 /usr/tests/bin/sh/parser/line-cont4.0 /usr/tests/bin/sh/parser/line-cont5.0 /usr/tests/bin/sh/parser/line-cont6.0 /usr/tests/bin/sh/parser/line-cont7.0 /usr/tests/bin/sh/parser/line-cont8.0 /usr/tests/bin/sh/parser/line-cont9.0 /usr/tests/bin/sh/parser/line-cont10.0 /usr/tests/bin/sh/parser/line-cont11.0 /usr/tests/bin/sh/set-e /usr/tests/bin/sh/set-e/and1.0 /usr/tests/bin/sh/set-e/and2.1 /usr/tests/bin/sh/set-e/and3.0 /usr/tests/bin/sh/set-e/and4.0 /usr/tests/bin/sh/set-e/background1.0 /usr/tests/bin/sh/set-e/cmd1.0 /usr/tests/bin/sh/set-e/cmd2.1 /usr/tests/bin/sh/set-e/elif1.0 /usr/tests/bin/sh/set-e/elif2.0 /usr/tests/bin/sh/set-e/eval1.0 /usr/tests/bin/sh/set-e/eval2.1 /usr/tests/bin/sh/set-e/for1.0 /usr/tests/bin/sh/set-e/func1.0 /usr/tests/bin/sh/set-e/func2.1 /usr/tests/bin/sh/set-e/if1.0 /usr/tests/bin/sh/set-e/if2.0 /usr/tests/bin/sh/set-e/if3.0 /usr/tests/bin/sh/set-e/not1.0 /usr/tests/bin/sh/set-e/not2.0 /usr/tests/bin/sh/set-e/or1.0 /usr/tests/bin/sh/set-e/or2.0 /usr/tests/bin/sh/set-e/or3.1 /usr/tests/bin/sh/set-e/pipe1.1 /usr/tests/bin/sh/set-e/pipe2.0 /usr/tests/bin/sh/set-e/return1.0 /usr/tests/bin/sh/set-e/semi1.1 /usr/tests/bin/sh/set-e/semi2.1 /usr/tests/bin/sh/set-e/subshell1.0 /usr/tests/bin/sh/set-e/subshell2.1 /usr/tests/bin/sh/set-e/until1.0 /usr/tests/bin/sh/set-e/until2.0 /usr/tests/bin/sh/set-e/until3.0 /usr/tests/bin/sh/set-e/while1.0 /usr/tests/bin/sh/set-e/while2.0 /usr/tests/bin/sh/set-e/while3.0 /usr/tests/bin/sh/set-e/functional_test /usr/tests/bin/sh/set-e/Kyuafile /usr/tests/bin/sh/Kyuafile /usr/tests/bin/test /usr/tests/bin/test/legacy_test /usr/tests/bin/test/Kyuafile /usr/tests/bin/Kyuafile /usr/tests/bin/sleep /usr/tests/bin/sleep/sleep_test /usr/tests/bin/sleep/Kyuafile /usr/tests/cddl /usr/tests/cddl/lib /usr/tests/cddl/lib/Kyuafile /usr/tests/cddl/sbin /usr/tests/cddl/sbin/Kyuafile /usr/tests/cddl/usr.bin /usr/tests/cddl/usr.bin/Kyuafile /usr/tests/cddl/usr.sbin /usr/tests/cddl/usr.sbin/Kyuafile /usr/tests/cddl/Kyuafile /usr/tests/etc /usr/tests/etc/Kyuafile /usr/tests/games /usr/tests/games/Kyuafile /usr/tests/gnu /usr/tests/gnu/lib /usr/tests/gnu/lib/Kyuafile /usr/tests/gnu/usr.bin /usr/tests/gnu/usr.bin/Kyuafile /usr/tests/gnu/usr.bin/diff /usr/tests/gnu/usr.bin/diff/diff_test /usr/tests/gnu/usr.bin/diff/Kyuafile /usr/tests/gnu/usr.bin/diff/d_mallocv1.in /usr/tests/gnu/usr.bin/diff/d_mallocv2.in /usr/tests/gnu/Kyuafile /usr/tests/lib /usr/tests/lib/atf /usr/tests/lib/atf/libatf-c /usr/tests/lib/atf/libatf-c/detail /usr/tests/lib/atf/libatf-c/detail/Kyuafile /usr/tests/lib/atf/libatf-c/detail/process_helpers /usr/tests/lib/atf/libatf-c/detail/version_helper /usr/tests/lib/atf/libatf-c/detail/dynstr_test /usr/tests/lib/atf/libatf-c/detail/env_test /usr/tests/lib/atf/libatf-c/detail/fs_test /usr/tests/lib/atf/libatf-c/detail/list_test /usr/tests/lib/atf/libatf-c/detail/map_test /usr/tests/lib/atf/libatf-c/detail/process_test /usr/tests/lib/atf/libatf-c/detail/sanity_test /usr/tests/lib/atf/libatf-c/detail/text_test /usr/tests/lib/atf/libatf-c/detail/user_test /usr/tests/lib/atf/libatf-c/Kyuafile /usr/tests/lib/atf/libatf-c/macros_h_test.c /usr/tests/lib/atf/libatf-c/unused_test.c /usr/tests/lib/atf/libatf-c/atf_c_test /usr/tests/lib/atf/libatf-c/build_test /usr/tests/lib/atf/libatf-c/check_test /usr/tests/lib/atf/libatf-c/config_test /usr/tests/lib/atf/libatf-c/error_test /usr/tests/lib/atf/libatf-c/macros_test /usr/tests/lib/atf/libatf-c/tc_test /usr/tests/lib/atf/libatf-c/tp_test /usr/tests/lib/atf/libatf-c/utils_test /usr/tests/lib/atf/libatf-c++ /usr/tests/lib/atf/libatf-c++/detail /usr/tests/lib/atf/libatf-c++/detail/Kyuafile /usr/tests/lib/atf/libatf-c++/detail/version_helper /usr/tests/lib/atf/libatf-c++/detail/application_test /usr/tests/lib/atf/libatf-c++/detail/env_test /usr/tests/lib/atf/libatf-c++/detail/exceptions_test /usr/tests/lib/atf/libatf-c++/detail/fs_test /usr/tests/lib/atf/libatf-c++/detail/process_test /usr/tests/lib/atf/libatf-c++/detail/sanity_test /usr/tests/lib/atf/libatf-c++/detail/text_test /usr/tests/lib/atf/libatf-c++/Kyuafile /usr/tests/lib/atf/libatf-c++/macros_hpp_test.cpp /usr/tests/lib/atf/libatf-c++/unused_test.cpp /usr/tests/lib/atf/libatf-c++/atf_c++_test /usr/tests/lib/atf/libatf-c++/build_test /usr/tests/lib/atf/libatf-c++/check_test /usr/tests/lib/atf/libatf-c++/config_test /usr/tests/lib/atf/libatf-c++/macros_test /usr/tests/lib/atf/libatf-c++/tests_test /usr/tests/lib/atf/libatf-c++/utils_test /usr/tests/lib/atf/test-programs /usr/tests/lib/atf/test-programs/sh_helpers /usr/tests/lib/atf/test-programs/config_test /usr/tests/lib/atf/test-programs/expect_test /usr/tests/lib/atf/test-programs/meta_data_test /usr/tests/lib/atf/test-programs/result_test /usr/tests/lib/atf/test-programs/srcdir_test /usr/tests/lib/atf/test-programs/Kyuafile /usr/tests/lib/atf/test-programs/c_helpers /usr/tests/lib/atf/test-programs/cpp_helpers /usr/tests/lib/atf/Kyuafile /usr/tests/lib/libcrypt /usr/tests/lib/libcrypt/Kyuafile /usr/tests/lib/libcrypt/crypt_tests /usr/tests/lib/Kyuafile /usr/tests/lib/libmp /usr/tests/lib/libmp/Kyuafile /usr/tests/lib/libmp/legacy_test /usr/tests/lib/libnv /usr/tests/lib/libnv/Kyuafile /usr/tests/lib/libnv/nvlist_add_test /usr/tests/lib/libnv/nvlist_exists_test /usr/tests/lib/libnv/nvlist_free_test /usr/tests/lib/libnv/nvlist_get_test /usr/tests/lib/libnv/nvlist_move_test /usr/tests/lib/libnv/nvlist_send_recv_test /usr/tests/lib/libutil /usr/tests/lib/libutil/Kyuafile /usr/tests/lib/libutil/flopen_test /usr/tests/lib/libutil/grp_test /usr/tests/lib/libutil/humanize_number_test /usr/tests/lib/libutil/pidfile_test /usr/tests/lib/libutil/trimdomain_test /usr/tests/lib/libutil/trimdomain-nodomain_test /usr/tests/lib/libproc /usr/tests/lib/libproc/Kyuafile /usr/tests/lib/libproc/target_prog /usr/tests/lib/libproc/proc_test /usr/tests/libexec /usr/tests/libexec/atf /usr/tests/libexec/atf/atf-check /usr/tests/libexec/atf/atf-check/atf-check_test /usr/tests/libexec/atf/atf-check/Kyuafile /usr/tests/libexec/atf/atf-sh /usr/tests/libexec/atf/atf-sh/misc_helpers /usr/tests/libexec/atf/atf-sh/atf_check_test /usr/tests/libexec/atf/atf-sh/config_test /usr/tests/libexec/atf/atf-sh/integration_test /usr/tests/libexec/atf/atf-sh/normalize_test /usr/tests/libexec/atf/atf-sh/tc_test /usr/tests/libexec/atf/atf-sh/tp_test /usr/tests/libexec/atf/atf-sh/Kyuafile /usr/tests/libexec/atf/Kyuafile /usr/tests/libexec/rtld-elf /usr/tests/libexec/rtld-elf/libpythagoras.a /usr/tests/libexec/rtld-elf/libpythagoras_p.a /usr/tests/libexec/rtld-elf/libpythagoras.so.0 /usr/tests/libexec/rtld-elf/libpythagoras.so /usr/tests/libexec/rtld-elf/target /usr/tests/libexec/rtld-elf/Kyuafile /usr/tests/libexec/rtld-elf/ld_library_pathfds /usr/tests/libexec/Kyuafile /usr/tests/sbin /usr/tests/sbin/dhclient /usr/tests/sbin/dhclient/Kyuafile /usr/tests/sbin/dhclient/option-domain-search_test /usr/tests/sbin/growfs /usr/tests/sbin/growfs/legacy_test /usr/tests/sbin/growfs/Kyuafile /usr/tests/sbin/mdconfig /usr/tests/sbin/mdconfig/legacy_test /usr/tests/sbin/mdconfig/Kyuafile /usr/tests/sbin/mdconfig/mdconfig.test /usr/tests/sbin/mdconfig/run.pl /usr/tests/sbin/Kyuafile /usr/tests/sbin/devd /usr/tests/sbin/devd/Kyuafile /usr/tests/sbin/devd/client_test /usr/tests/secure /usr/tests/secure/lib /usr/tests/secure/lib/Kyuafile /usr/tests/secure/libexec /usr/tests/secure/libexec/Kyuafile /usr/tests/secure/usr.bin /usr/tests/secure/usr.bin/Kyuafile /usr/tests/secure/usr.sbin /usr/tests/secure/usr.sbin/Kyuafile /usr/tests/secure/Kyuafile /usr/tests/share /usr/tests/share/examples /usr/tests/share/examples/tests /usr/tests/share/examples/tests/atf /usr/tests/share/examples/tests/atf/cp_test /usr/tests/share/examples/tests/atf/Kyuafile /usr/tests/share/examples/tests/atf/printf_test /usr/tests/share/examples/tests/plain /usr/tests/share/examples/tests/plain/cp_test /usr/tests/share/examples/tests/plain/Kyuafile /usr/tests/share/examples/tests/plain/printf_test /usr/tests/share/examples/tests/Kyuafile /usr/tests/share/examples/Kyuafile /usr/tests/share/Kyuafile /usr/tests/sys /usr/tests/sys/kern /usr/tests/sys/kern/Kyuafile /usr/tests/sys/kern/kern_descrip_test /usr/tests/sys/kern/unix_seqpacket_test /usr/tests/sys/netinet /usr/tests/sys/netinet/udp_dontroute /usr/tests/sys/netinet/fibs_test /usr/tests/sys/netinet/Kyuafile /usr/tests/sys/Kyuafile /usr/tests/usr.bin /usr/tests/usr.bin/apply /usr/tests/usr.bin/apply/legacy_test /usr/tests/usr.bin/apply/Kyuafile /usr/tests/usr.bin/apply/regress.00.in /usr/tests/usr.bin/apply/regress.00.out /usr/tests/usr.bin/apply/regress.01.out /usr/tests/usr.bin/apply/regress.01.sh /usr/tests/usr.bin/apply/regress.sh /usr/tests/usr.bin/bmake /usr/tests/usr.bin/bmake/archives /usr/tests/usr.bin/bmake/archives/fmt_44bsd /usr/tests/usr.bin/bmake/archives/fmt_44bsd/legacy_test /usr/tests/usr.bin/bmake/archives/fmt_44bsd/Kyuafile /usr/tests/usr.bin/bmake/archives/fmt_44bsd/Makefile.test /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.status.1 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.status.2 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.status.3 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.status.4 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.status.5 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.status.6 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.status.7 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stderr.1 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stderr.2 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stderr.3 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stderr.4 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stderr.5 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stderr.6 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stderr.7 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stdout.1 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stdout.2 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stdout.3 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stdout.4 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stdout.5 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stdout.6 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/expected.stdout.7 /usr/tests/usr.bin/bmake/archives/fmt_44bsd/libtest.a /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/legacy_test /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/Kyuafile /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/Makefile.test /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.status.1 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.status.2 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.status.3 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.status.4 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.status.5 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.status.6 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.status.7 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stderr.1 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stderr.2 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stderr.3 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stderr.4 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stderr.5 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stderr.6 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stderr.7 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stdout.1 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stdout.2 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stdout.3 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stdout.4 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stdout.5 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stdout.6 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/expected.stdout.7 /usr/tests/usr.bin/bmake/archives/fmt_44bsd_mod/libtest.a /usr/tests/usr.bin/bmake/archives/fmt_oldbsd /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/legacy_test /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/Kyuafile /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/Makefile.test /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.status.1 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.status.2 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.status.3 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.status.4 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.status.5 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.status.6 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.status.7 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stderr.1 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stderr.2 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stderr.3 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stderr.4 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stderr.5 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stderr.6 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stderr.7 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stdout.1 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stdout.2 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stdout.3 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stdout.4 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stdout.5 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stdout.6 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/expected.stdout.7 /usr/tests/usr.bin/bmake/archives/fmt_oldbsd/libtest.a /usr/tests/usr.bin/bmake/archives/Kyuafile /usr/tests/usr.bin/bmake/basic /usr/tests/usr.bin/bmake/basic/t0 /usr/tests/usr.bin/bmake/basic/t0/legacy_test /usr/tests/usr.bin/bmake/basic/t0/Kyuafile /usr/tests/usr.bin/bmake/basic/t0/expected.status.1 /usr/tests/usr.bin/bmake/basic/t0/expected.stderr.1 /usr/tests/usr.bin/bmake/basic/t0/expected.stdout.1 /usr/tests/usr.bin/bmake/basic/t1 /usr/tests/usr.bin/bmake/basic/t1/legacy_test /usr/tests/usr.bin/bmake/basic/t1/Kyuafile /usr/tests/usr.bin/bmake/basic/t1/Makefile.test /usr/tests/usr.bin/bmake/basic/t1/expected.status.1 /usr/tests/usr.bin/bmake/basic/t1/expected.stderr.1 /usr/tests/usr.bin/bmake/basic/t1/expected.stdout.1 /usr/tests/usr.bin/bmake/basic/t2 /usr/tests/usr.bin/bmake/basic/t2/legacy_test /usr/tests/usr.bin/bmake/basic/t2/Kyuafile /usr/tests/usr.bin/bmake/basic/t2/Makefile.test /usr/tests/usr.bin/bmake/basic/t2/expected.status.1 /usr/tests/usr.bin/bmake/basic/t2/expected.stderr.1 /usr/tests/usr.bin/bmake/basic/t2/expected.stdout.1 /usr/tests/usr.bin/bmake/basic/t3 /usr/tests/usr.bin/bmake/basic/t3/legacy_test /usr/tests/usr.bin/bmake/basic/t3/Kyuafile /usr/tests/usr.bin/bmake/basic/t3/expected.status.1 /usr/tests/usr.bin/bmake/basic/t3/expected.stderr.1 /usr/tests/usr.bin/bmake/basic/t3/expected.stdout.1 /usr/tests/usr.bin/bmake/basic/Kyuafile /usr/tests/usr.bin/bmake/execution /usr/tests/usr.bin/bmake/execution/ellipsis /usr/tests/usr.bin/bmake/execution/ellipsis/legacy_test /usr/tests/usr.bin/bmake/execution/ellipsis/Kyuafile /usr/tests/usr.bin/bmake/execution/ellipsis/Makefile.test /usr/tests/usr.bin/bmake/execution/ellipsis/expected.status.1 /usr/tests/usr.bin/bmake/execution/ellipsis/expected.stderr.1 /usr/tests/usr.bin/bmake/execution/ellipsis/expected.stdout.1 /usr/tests/usr.bin/bmake/execution/empty /usr/tests/usr.bin/bmake/execution/empty/legacy_test /usr/tests/usr.bin/bmake/execution/empty/Kyuafile /usr/tests/usr.bin/bmake/execution/empty/Makefile.test /usr/tests/usr.bin/bmake/execution/empty/expected.status.1 /usr/tests/usr.bin/bmake/execution/empty/expected.stderr.1 /usr/tests/usr.bin/bmake/execution/empty/expected.stdout.1 /usr/tests/usr.bin/bmake/execution/joberr /usr/tests/usr.bin/bmake/execution/joberr/legacy_test /usr/tests/usr.bin/bmake/execution/joberr/Kyuafile /usr/tests/usr.bin/bmake/execution/joberr/Makefile.test /usr/tests/usr.bin/bmake/execution/joberr/expected.status.1 /usr/tests/usr.bin/bmake/execution/joberr/expected.stderr.1 /usr/tests/usr.bin/bmake/execution/joberr/expected.stdout.1 /usr/tests/usr.bin/bmake/execution/plus /usr/tests/usr.bin/bmake/execution/plus/legacy_test /usr/tests/usr.bin/bmake/execution/plus/Kyuafile /usr/tests/usr.bin/bmake/execution/plus/Makefile.test /usr/tests/usr.bin/bmake/execution/plus/expected.status.1 /usr/tests/usr.bin/bmake/execution/plus/expected.stderr.1 /usr/tests/usr.bin/bmake/execution/plus/expected.stdout.1 /usr/tests/usr.bin/bmake/execution/Kyuafile /usr/tests/usr.bin/bmake/shell /usr/tests/usr.bin/bmake/shell/builtin /usr/tests/usr.bin/bmake/shell/builtin/legacy_test /usr/tests/usr.bin/bmake/shell/builtin/Kyuafile /usr/tests/usr.bin/bmake/shell/builtin/Makefile.test /usr/tests/usr.bin/bmake/shell/builtin/expected.status.1 /usr/tests/usr.bin/bmake/shell/builtin/expected.status.2 /usr/tests/usr.bin/bmake/shell/builtin/expected.stderr.1 /usr/tests/usr.bin/bmake/shell/builtin/expected.stderr.2 /usr/tests/usr.bin/bmake/shell/builtin/expected.stdout.1 /usr/tests/usr.bin/bmake/shell/builtin/expected.stdout.2 /usr/tests/usr.bin/bmake/shell/builtin/sh /usr/tests/usr.bin/bmake/shell/meta /usr/tests/usr.bin/bmake/shell/meta/legacy_test /usr/tests/usr.bin/bmake/shell/meta/Kyuafile /usr/tests/usr.bin/bmake/shell/meta/Makefile.test /usr/tests/usr.bin/bmake/shell/meta/expected.status.1 /usr/tests/usr.bin/bmake/shell/meta/expected.status.2 /usr/tests/usr.bin/bmake/shell/meta/expected.stderr.1 /usr/tests/usr.bin/bmake/shell/meta/expected.stderr.2 /usr/tests/usr.bin/bmake/shell/meta/expected.stdout.1 /usr/tests/usr.bin/bmake/shell/meta/expected.stdout.2 /usr/tests/usr.bin/bmake/shell/meta/sh /usr/tests/usr.bin/bmake/shell/path /usr/tests/usr.bin/bmake/shell/path/legacy_test /usr/tests/usr.bin/bmake/shell/path/Kyuafile /usr/tests/usr.bin/bmake/shell/path/Makefile.test /usr/tests/usr.bin/bmake/shell/path/expected.status.1 /usr/tests/usr.bin/bmake/shell/path/expected.status.2 /usr/tests/usr.bin/bmake/shell/path/expected.stderr.1 /usr/tests/usr.bin/bmake/shell/path/expected.stderr.2 /usr/tests/usr.bin/bmake/shell/path/expected.stdout.1 /usr/tests/usr.bin/bmake/shell/path/expected.stdout.2 /usr/tests/usr.bin/bmake/shell/path/sh /usr/tests/usr.bin/bmake/shell/path_select /usr/tests/usr.bin/bmake/shell/path_select/legacy_test /usr/tests/usr.bin/bmake/shell/path_select/Kyuafile /usr/tests/usr.bin/bmake/shell/path_select/Makefile.test /usr/tests/usr.bin/bmake/shell/path_select/expected.status.1 /usr/tests/usr.bin/bmake/shell/path_select/expected.status.2 /usr/tests/usr.bin/bmake/shell/path_select/expected.stderr.1 /usr/tests/usr.bin/bmake/shell/path_select/expected.stderr.2 /usr/tests/usr.bin/bmake/shell/path_select/expected.stdout.1 /usr/tests/usr.bin/bmake/shell/path_select/expected.stdout.2 /usr/tests/usr.bin/bmake/shell/path_select/shell /usr/tests/usr.bin/bmake/shell/replace /usr/tests/usr.bin/bmake/shell/replace/legacy_test /usr/tests/usr.bin/bmake/shell/replace/Kyuafile /usr/tests/usr.bin/bmake/shell/replace/Makefile.test /usr/tests/usr.bin/bmake/shell/replace/expected.status.1 /usr/tests/usr.bin/bmake/shell/replace/expected.status.2 /usr/tests/usr.bin/bmake/shell/replace/expected.stderr.1 /usr/tests/usr.bin/bmake/shell/replace/expected.stderr.2 /usr/tests/usr.bin/bmake/shell/replace/expected.stdout.1 /usr/tests/usr.bin/bmake/shell/replace/expected.stdout.2 /usr/tests/usr.bin/bmake/shell/replace/shell /usr/tests/usr.bin/bmake/shell/select /usr/tests/usr.bin/bmake/shell/select/legacy_test /usr/tests/usr.bin/bmake/shell/select/Kyuafile /usr/tests/usr.bin/bmake/shell/select/Makefile.test /usr/tests/usr.bin/bmake/shell/select/expected.status.1 /usr/tests/usr.bin/bmake/shell/select/expected.status.2 /usr/tests/usr.bin/bmake/shell/select/expected.stderr.1 /usr/tests/usr.bin/bmake/shell/select/expected.stderr.2 /usr/tests/usr.bin/bmake/shell/select/expected.stdout.1 /usr/tests/usr.bin/bmake/shell/select/expected.stdout.2 /usr/tests/usr.bin/bmake/shell/Kyuafile /usr/tests/usr.bin/bmake/suffixes /usr/tests/usr.bin/bmake/suffixes/basic /usr/tests/usr.bin/bmake/suffixes/basic/legacy_test /usr/tests/usr.bin/bmake/suffixes/basic/Kyuafile /usr/tests/usr.bin/bmake/suffixes/basic/Makefile.test /usr/tests/usr.bin/bmake/suffixes/basic/TEST1.a /usr/tests/usr.bin/bmake/suffixes/basic/expected.status.1 /usr/tests/usr.bin/bmake/suffixes/basic/expected.stderr.1 /usr/tests/usr.bin/bmake/suffixes/basic/expected.stdout.1 /usr/tests/usr.bin/bmake/suffixes/src_wild1 /usr/tests/usr.bin/bmake/suffixes/src_wild1/legacy_test /usr/tests/usr.bin/bmake/suffixes/src_wild1/Kyuafile /usr/tests/usr.bin/bmake/suffixes/src_wild1/Makefile.test /usr/tests/usr.bin/bmake/suffixes/src_wild1/TEST1.a /usr/tests/usr.bin/bmake/suffixes/src_wild1/TEST2.a /usr/tests/usr.bin/bmake/suffixes/src_wild1/expected.status.1 /usr/tests/usr.bin/bmake/suffixes/src_wild1/expected.stderr.1 /usr/tests/usr.bin/bmake/suffixes/src_wild1/expected.stdout.1 /usr/tests/usr.bin/bmake/suffixes/src_wild2 /usr/tests/usr.bin/bmake/suffixes/src_wild2/legacy_test /usr/tests/usr.bin/bmake/suffixes/src_wild2/Kyuafile /usr/tests/usr.bin/bmake/suffixes/src_wild2/Makefile.test /usr/tests/usr.bin/bmake/suffixes/src_wild2/TEST1.a /usr/tests/usr.bin/bmake/suffixes/src_wild2/TEST2.a /usr/tests/usr.bin/bmake/suffixes/src_wild2/expected.status.1 /usr/tests/usr.bin/bmake/suffixes/src_wild2/expected.stderr.1 /usr/tests/usr.bin/bmake/suffixes/src_wild2/expected.stdout.1 /usr/tests/usr.bin/bmake/suffixes/Kyuafile /usr/tests/usr.bin/bmake/syntax /usr/tests/usr.bin/bmake/syntax/directive-t0 /usr/tests/usr.bin/bmake/syntax/directive-t0/legacy_test /usr/tests/usr.bin/bmake/syntax/directive-t0/Kyuafile /usr/tests/usr.bin/bmake/syntax/directive-t0/Makefile.test /usr/tests/usr.bin/bmake/syntax/directive-t0/expected.status.1 /usr/tests/usr.bin/bmake/syntax/directive-t0/expected.stderr.1 /usr/tests/usr.bin/bmake/syntax/directive-t0/expected.stdout.1 /usr/tests/usr.bin/bmake/syntax/enl /usr/tests/usr.bin/bmake/syntax/enl/legacy_test /usr/tests/usr.bin/bmake/syntax/enl/Kyuafile /usr/tests/usr.bin/bmake/syntax/enl/Makefile.test /usr/tests/usr.bin/bmake/syntax/enl/expected.status.1 /usr/tests/usr.bin/bmake/syntax/enl/expected.status.2 /usr/tests/usr.bin/bmake/syntax/enl/expected.status.3 /usr/tests/usr.bin/bmake/syntax/enl/expected.status.4 /usr/tests/usr.bin/bmake/syntax/enl/expected.status.5 /usr/tests/usr.bin/bmake/syntax/enl/expected.stderr.1 /usr/tests/usr.bin/bmake/syntax/enl/expected.stderr.2 /usr/tests/usr.bin/bmake/syntax/enl/expected.stderr.3 /usr/tests/usr.bin/bmake/syntax/enl/expected.stderr.4 /usr/tests/usr.bin/bmake/syntax/enl/expected.stderr.5 /usr/tests/usr.bin/bmake/syntax/enl/expected.stdout.1 /usr/tests/usr.bin/bmake/syntax/enl/expected.stdout.2 /usr/tests/usr.bin/bmake/syntax/enl/expected.stdout.3 /usr/tests/usr.bin/bmake/syntax/enl/expected.stdout.4 /usr/tests/usr.bin/bmake/syntax/enl/expected.stdout.5 /usr/tests/usr.bin/bmake/syntax/funny-targets /usr/tests/usr.bin/bmake/syntax/funny-targets/legacy_test /usr/tests/usr.bin/bmake/syntax/funny-targets/Kyuafile /usr/tests/usr.bin/bmake/syntax/funny-targets/Makefile.test /usr/tests/usr.bin/bmake/syntax/funny-targets/expected.status.1 /usr/tests/usr.bin/bmake/syntax/funny-targets/expected.status.2 /usr/tests/usr.bin/bmake/syntax/funny-targets/expected.stderr.1 /usr/tests/usr.bin/bmake/syntax/funny-targets/expected.stderr.2 /usr/tests/usr.bin/bmake/syntax/funny-targets/expected.stdout.1 /usr/tests/usr.bin/bmake/syntax/funny-targets/expected.stdout.2 /usr/tests/usr.bin/bmake/syntax/semi /usr/tests/usr.bin/bmake/syntax/semi/legacy_test /usr/tests/usr.bin/bmake/syntax/semi/Kyuafile /usr/tests/usr.bin/bmake/syntax/semi/Makefile.test /usr/tests/usr.bin/bmake/syntax/semi/expected.status.1 /usr/tests/usr.bin/bmake/syntax/semi/expected.status.2 /usr/tests/usr.bin/bmake/syntax/semi/expected.stderr.1 /usr/tests/usr.bin/bmake/syntax/semi/expected.stderr.2 /usr/tests/usr.bin/bmake/syntax/semi/expected.stdout.1 /usr/tests/usr.bin/bmake/syntax/semi/expected.stdout.2 /usr/tests/usr.bin/bmake/syntax/Kyuafile /usr/tests/usr.bin/bmake/sysmk /usr/tests/usr.bin/bmake/sysmk/t0 /usr/tests/usr.bin/bmake/sysmk/t0/2 /usr/tests/usr.bin/bmake/sysmk/t0/2/1 /usr/tests/usr.bin/bmake/sysmk/t0/2/1/legacy_test /usr/tests/usr.bin/bmake/sysmk/t0/2/1/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t0/2/1/Makefile.test /usr/tests/usr.bin/bmake/sysmk/t0/2/1/expected.status.1 /usr/tests/usr.bin/bmake/sysmk/t0/2/1/expected.stderr.1 /usr/tests/usr.bin/bmake/sysmk/t0/2/1/expected.stdout.1 /usr/tests/usr.bin/bmake/sysmk/t0/2/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t0/mk /usr/tests/usr.bin/bmake/sysmk/t0/mk/sys.mk /usr/tests/usr.bin/bmake/sysmk/t0/mk/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t0/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t1 /usr/tests/usr.bin/bmake/sysmk/t1/2 /usr/tests/usr.bin/bmake/sysmk/t1/2/1 /usr/tests/usr.bin/bmake/sysmk/t1/2/1/legacy_test /usr/tests/usr.bin/bmake/sysmk/t1/2/1/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t1/2/1/cleanup /usr/tests/usr.bin/bmake/sysmk/t1/2/1/expected.status.1 /usr/tests/usr.bin/bmake/sysmk/t1/2/1/expected.stderr.1 /usr/tests/usr.bin/bmake/sysmk/t1/2/1/expected.stdout.1 /usr/tests/usr.bin/bmake/sysmk/t1/2/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t1/mk /usr/tests/usr.bin/bmake/sysmk/t1/mk/sys.mk /usr/tests/usr.bin/bmake/sysmk/t1/mk/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t1/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t2 /usr/tests/usr.bin/bmake/sysmk/t2/2 /usr/tests/usr.bin/bmake/sysmk/t2/2/1 /usr/tests/usr.bin/bmake/sysmk/t2/2/1/legacy_test /usr/tests/usr.bin/bmake/sysmk/t2/2/1/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t2/2/1/cleanup /usr/tests/usr.bin/bmake/sysmk/t2/2/1/expected.status.1 /usr/tests/usr.bin/bmake/sysmk/t2/2/1/expected.stderr.1 /usr/tests/usr.bin/bmake/sysmk/t2/2/1/expected.stdout.1 /usr/tests/usr.bin/bmake/sysmk/t2/2/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t2/mk /usr/tests/usr.bin/bmake/sysmk/t2/mk/sys.mk /usr/tests/usr.bin/bmake/sysmk/t2/mk/Kyuafile /usr/tests/usr.bin/bmake/sysmk/t2/Kyuafile /usr/tests/usr.bin/bmake/sysmk/Kyuafile /usr/tests/usr.bin/bmake/variables /usr/tests/usr.bin/bmake/variables/modifier_M /usr/tests/usr.bin/bmake/variables/modifier_M/legacy_test /usr/tests/usr.bin/bmake/variables/modifier_M/Kyuafile /usr/tests/usr.bin/bmake/variables/modifier_M/Makefile.test /usr/tests/usr.bin/bmake/variables/modifier_M/expected.status.1 /usr/tests/usr.bin/bmake/variables/modifier_M/expected.stderr.1 /usr/tests/usr.bin/bmake/variables/modifier_M/expected.stdout.1 /usr/tests/usr.bin/bmake/variables/modifier_t /usr/tests/usr.bin/bmake/variables/modifier_t/legacy_test /usr/tests/usr.bin/bmake/variables/modifier_t/Kyuafile /usr/tests/usr.bin/bmake/variables/modifier_t/Makefile.test /usr/tests/usr.bin/bmake/variables/modifier_t/expected.status.1 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.status.2 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.status.3 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.stderr.1 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.stderr.2 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.stderr.3 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.stdout.1 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.stdout.2 /usr/tests/usr.bin/bmake/variables/modifier_t/expected.stdout.3 /usr/tests/usr.bin/bmake/variables/opt_V /usr/tests/usr.bin/bmake/variables/opt_V/legacy_test /usr/tests/usr.bin/bmake/variables/opt_V/Kyuafile /usr/tests/usr.bin/bmake/variables/opt_V/Makefile.test /usr/tests/usr.bin/bmake/variables/opt_V/expected.status.1 /usr/tests/usr.bin/bmake/variables/opt_V/expected.status.2 /usr/tests/usr.bin/bmake/variables/opt_V/expected.stderr.1 /usr/tests/usr.bin/bmake/variables/opt_V/expected.stderr.2 /usr/tests/usr.bin/bmake/variables/opt_V/expected.stdout.1 /usr/tests/usr.bin/bmake/variables/opt_V/expected.stdout.2 /usr/tests/usr.bin/bmake/variables/t0 /usr/tests/usr.bin/bmake/variables/t0/legacy_test /usr/tests/usr.bin/bmake/variables/t0/Kyuafile /usr/tests/usr.bin/bmake/variables/t0/Makefile.test /usr/tests/usr.bin/bmake/variables/t0/expected.status.1 /usr/tests/usr.bin/bmake/variables/t0/expected.stderr.1 /usr/tests/usr.bin/bmake/variables/t0/expected.stdout.1 /usr/tests/usr.bin/bmake/variables/Kyuafile /usr/tests/usr.bin/bmake/Kyuafile /usr/tests/usr.bin/bmake/common.sh /usr/tests/usr.bin/bmake/test-new.mk /usr/tests/usr.bin/calendar /usr/tests/usr.bin/calendar/legacy_test /usr/tests/usr.bin/calendar/Kyuafile /usr/tests/usr.bin/calendar/calendar.calibrate /usr/tests/usr.bin/calendar/regress.a1.out /usr/tests/usr.bin/calendar/regress.a2.out /usr/tests/usr.bin/calendar/regress.a3.out /usr/tests/usr.bin/calendar/regress.a4.out /usr/tests/usr.bin/calendar/regress.a5.out /usr/tests/usr.bin/calendar/regress.b1.out /usr/tests/usr.bin/calendar/regress.b2.out /usr/tests/usr.bin/calendar/regress.b3.out /usr/tests/usr.bin/calendar/regress.b4.out /usr/tests/usr.bin/calendar/regress.b5.out /usr/tests/usr.bin/calendar/regress.s1.out /usr/tests/usr.bin/calendar/regress.s2.out /usr/tests/usr.bin/calendar/regress.s3.out /usr/tests/usr.bin/calendar/regress.s4.out /usr/tests/usr.bin/calendar/regress.sh /usr/tests/usr.bin/calendar/regress.w0-1.out /usr/tests/usr.bin/calendar/regress.w0-2.out /usr/tests/usr.bin/calendar/regress.w0-3.out /usr/tests/usr.bin/calendar/regress.w0-4.out /usr/tests/usr.bin/calendar/regress.w0-5.out /usr/tests/usr.bin/calendar/regress.w0-6.out /usr/tests/usr.bin/calendar/regress.w0-7.out /usr/tests/usr.bin/calendar/regress.wn-1.out /usr/tests/usr.bin/calendar/regress.wn-2.out /usr/tests/usr.bin/calendar/regress.wn-3.out /usr/tests/usr.bin/calendar/regress.wn-4.out /usr/tests/usr.bin/calendar/regress.wn-5.out /usr/tests/usr.bin/calendar/regress.wn-6.out /usr/tests/usr.bin/calendar/regress.wn-7.out /usr/tests/usr.bin/comm /usr/tests/usr.bin/comm/legacy_test /usr/tests/usr.bin/comm/Kyuafile /usr/tests/usr.bin/comm/regress.00.out /usr/tests/usr.bin/comm/regress.00a.in /usr/tests/usr.bin/comm/regress.00b.in /usr/tests/usr.bin/comm/regress.01.out /usr/tests/usr.bin/comm/regress.01a.in /usr/tests/usr.bin/comm/regress.01b.in /usr/tests/usr.bin/comm/regress.02.out /usr/tests/usr.bin/comm/regress.02a.in /usr/tests/usr.bin/comm/regress.02b.in /usr/tests/usr.bin/comm/regress.sh /usr/tests/usr.bin/file2c /usr/tests/usr.bin/file2c/legacy_test /usr/tests/usr.bin/file2c/Kyuafile /usr/tests/usr.bin/file2c/regress.1.out /usr/tests/usr.bin/file2c/regress.2.out /usr/tests/usr.bin/file2c/regress.3.out /usr/tests/usr.bin/file2c/regress.4.out /usr/tests/usr.bin/file2c/regress.5.out /usr/tests/usr.bin/file2c/regress.6.out /usr/tests/usr.bin/file2c/regress.7.out /usr/tests/usr.bin/file2c/regress.8.out /usr/tests/usr.bin/file2c/regress.9.out /usr/tests/usr.bin/file2c/regress.in /usr/tests/usr.bin/file2c/regress.sh /usr/tests/usr.bin/join /usr/tests/usr.bin/join/legacy_test /usr/tests/usr.bin/join/Kyuafile /usr/tests/usr.bin/join/regress.1.in /usr/tests/usr.bin/join/regress.2.in /usr/tests/usr.bin/join/regress.out /usr/tests/usr.bin/join/regress.sh /usr/tests/usr.bin/jot /usr/tests/usr.bin/jot/legacy_test /usr/tests/usr.bin/jot/Kyuafile /usr/tests/usr.bin/jot/regress.ascii.out /usr/tests/usr.bin/jot/regress.block.out /usr/tests/usr.bin/jot/regress.dddd.out /usr/tests/usr.bin/jot/regress.dddh.out /usr/tests/usr.bin/jot/regress.ddhd.out /usr/tests/usr.bin/jot/regress.ddhd2.out /usr/tests/usr.bin/jot/regress.ddhh.out /usr/tests/usr.bin/jot/regress.ddhh2.out /usr/tests/usr.bin/jot/regress.dhdd.out /usr/tests/usr.bin/jot/regress.dhdh.out /usr/tests/usr.bin/jot/regress.dhhd.out /usr/tests/usr.bin/jot/regress.dhhd2.out /usr/tests/usr.bin/jot/regress.dhhh.out /usr/tests/usr.bin/jot/regress.dhhh2.out /usr/tests/usr.bin/jot/regress.ed.out /usr/tests/usr.bin/jot/regress.grep.out /usr/tests/usr.bin/jot/regress.hddd.out /usr/tests/usr.bin/jot/regress.hddd2.out /usr/tests/usr.bin/jot/regress.hddh.out /usr/tests/usr.bin/jot/regress.hddh2.out /usr/tests/usr.bin/jot/regress.hdhd.out /usr/tests/usr.bin/jot/regress.hdhd2.out /usr/tests/usr.bin/jot/regress.hdhh.out /usr/tests/usr.bin/jot/regress.hdhh2.out /usr/tests/usr.bin/jot/regress.hhdd.out /usr/tests/usr.bin/jot/regress.hhdd2.out /usr/tests/usr.bin/jot/regress.hhdh.out /usr/tests/usr.bin/jot/regress.hhdh2.out /usr/tests/usr.bin/jot/regress.hhhd.out /usr/tests/usr.bin/jot/regress.hhhd2.out /usr/tests/usr.bin/jot/regress.hhhh.out /usr/tests/usr.bin/jot/regress.hhhh2.out /usr/tests/usr.bin/jot/regress.n21.out /usr/tests/usr.bin/jot/regress.rand1.out /usr/tests/usr.bin/jot/regress.rand2.out /usr/tests/usr.bin/jot/regress.sh /usr/tests/usr.bin/jot/regress.stutter.out /usr/tests/usr.bin/jot/regress.stutter2.out /usr/tests/usr.bin/jot/regress.tabs.out /usr/tests/usr.bin/jot/regress.wX1.out /usr/tests/usr.bin/jot/regress.wXl.out /usr/tests/usr.bin/jot/regress.wc.out /usr/tests/usr.bin/jot/regress.wdl.out /usr/tests/usr.bin/jot/regress.wdn.out /usr/tests/usr.bin/jot/regress.we.out /usr/tests/usr.bin/jot/regress.wf.out /usr/tests/usr.bin/jot/regress.wg.out /usr/tests/usr.bin/jot/regress.wgd.out /usr/tests/usr.bin/jot/regress.wo.out /usr/tests/usr.bin/jot/regress.wp1.out /usr/tests/usr.bin/jot/regress.wp2.out /usr/tests/usr.bin/jot/regress.wp3.out /usr/tests/usr.bin/jot/regress.wp4.out /usr/tests/usr.bin/jot/regress.wp5.out /usr/tests/usr.bin/jot/regress.wp6.out /usr/tests/usr.bin/jot/regress.wu.out /usr/tests/usr.bin/jot/regress.wwe.out /usr/tests/usr.bin/jot/regress.wx.out /usr/tests/usr.bin/jot/regress.wxn.out /usr/tests/usr.bin/jot/regress.x.out /usr/tests/usr.bin/jot/regress.xaa.out /usr/tests/usr.bin/jot/regress.yes.out /usr/tests/usr.bin/lastcomm /usr/tests/usr.bin/lastcomm/legacy_test /usr/tests/usr.bin/lastcomm/Kyuafile /usr/tests/usr.bin/lastcomm/v1-amd64-acct.in /usr/tests/usr.bin/lastcomm/v1-amd64.out /usr/tests/usr.bin/lastcomm/v1-i386-acct.in /usr/tests/usr.bin/lastcomm/v1-i386.out /usr/tests/usr.bin/lastcomm/v1-sparc64-acct.in /usr/tests/usr.bin/lastcomm/v1-sparc64.out /usr/tests/usr.bin/lastcomm/v2-amd64-acct.in /usr/tests/usr.bin/lastcomm/v2-amd64.out /usr/tests/usr.bin/lastcomm/v2-i386-acct.in /usr/tests/usr.bin/lastcomm/v2-i386.out /usr/tests/usr.bin/lastcomm/v2-sparc64-acct.in /usr/tests/usr.bin/lastcomm/v2-sparc64.out /usr/tests/usr.bin/m4 /usr/tests/usr.bin/m4/legacy_test /usr/tests/usr.bin/m4/Kyuafile /usr/tests/usr.bin/m4/args.m4 /usr/tests/usr.bin/m4/args2.m4 /usr/tests/usr.bin/m4/comments.m4 /usr/tests/usr.bin/m4/esyscmd.m4 /usr/tests/usr.bin/m4/eval.m4 /usr/tests/usr.bin/m4/ff_after_dnl.m4.uu /usr/tests/usr.bin/m4/gnueval.m4 /usr/tests/usr.bin/m4/gnuformat.m4 /usr/tests/usr.bin/m4/gnupatterns.m4 /usr/tests/usr.bin/m4/gnupatterns2.m4 /usr/tests/usr.bin/m4/gnuprefix.m4 /usr/tests/usr.bin/m4/gnusofterror.m4 /usr/tests/usr.bin/m4/includes.aux /usr/tests/usr.bin/m4/includes.m4 /usr/tests/usr.bin/m4/m4wrap3.m4 /usr/tests/usr.bin/m4/patterns.m4 /usr/tests/usr.bin/m4/quotes.m4 /usr/tests/usr.bin/m4/redef.m4 /usr/tests/usr.bin/m4/regress.args.out /usr/tests/usr.bin/m4/regress.args2.out /usr/tests/usr.bin/m4/regress.comments.out /usr/tests/usr.bin/m4/regress.esyscmd.out /usr/tests/usr.bin/m4/regress.eval.out /usr/tests/usr.bin/m4/regress.ff_after_dnl.out /usr/tests/usr.bin/m4/regress.gnueval.out /usr/tests/usr.bin/m4/regress.gnuformat.out /usr/tests/usr.bin/m4/regress.gnupatterns.out /usr/tests/usr.bin/m4/regress.gnupatterns2.out /usr/tests/usr.bin/m4/regress.gnuprefix.out /usr/tests/usr.bin/m4/regress.gnusofterror.out /usr/tests/usr.bin/m4/regress.gnutranslit2.out /usr/tests/usr.bin/m4/regress.includes.out /usr/tests/usr.bin/m4/regress.m4wrap3.out /usr/tests/usr.bin/m4/regress.patterns.out /usr/tests/usr.bin/m4/regress.quotes.out /usr/tests/usr.bin/m4/regress.redef.out /usr/tests/usr.bin/m4/regress.sh /usr/tests/usr.bin/m4/regress.strangequotes.out /usr/tests/usr.bin/m4/regress.translit.out /usr/tests/usr.bin/m4/regress.translit2.out /usr/tests/usr.bin/m4/strangequotes.m4.uu /usr/tests/usr.bin/m4/translit.m4 /usr/tests/usr.bin/m4/translit2.m4 /usr/tests/usr.bin/ncal /usr/tests/usr.bin/ncal/legacy_test /usr/tests/usr.bin/ncal/Kyuafile /usr/tests/usr.bin/ncal/regress.b-3m200901-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200901-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200902-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200902-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200903-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200903-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200904-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200904-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200905-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200905-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200906-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200906-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200907-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200907-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200908-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200908-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200909-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200909-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200910-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200910-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200911-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200911-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200912-jd-nhl.out /usr/tests/usr.bin/ncal/regress.f-3A-nhl.out /usr/tests/usr.bin/ncal/regress.b-3m200912-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2008-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2008-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2009-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2009-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2010-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2010-md-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2011-jd-nhl.out /usr/tests/usr.bin/ncal/regress.b-y2011-md-nhl.out /usr/tests/usr.bin/ncal/regress.f-3AB-nhl.out /usr/tests/usr.bin/ncal/regress.f-3B-nhl.out /usr/tests/usr.bin/ncal/regress.f-3gy-nhl.out /usr/tests/usr.bin/ncal/regress.f-3y-nhl.out /usr/tests/usr.bin/ncal/regress.f-mgm-nhl.out /usr/tests/usr.bin/ncal/regress.sh /usr/tests/usr.bin/ncal/regress.f-yA-nhl.out /usr/tests/usr.bin/ncal/regress.f-yAB-nhl.out /usr/tests/usr.bin/ncal/regress.f-yB-nhl.out /usr/tests/usr.bin/ncal/regress.f-ygm-nhl.out /usr/tests/usr.bin/ncal/regress.f-ym-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200901-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200901-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200902-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200902-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200903-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200903-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200904-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200904-md-nhl.out /usr/tests/usr.bin/ncal/regress.s-b-3-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200905-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200905-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200906-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200906-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200907-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200907-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200908-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200908-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200909-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200909-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200910-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200910-md-nhl.out /usr/tests/usr.bin/ncal/regress.s-b-A-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200911-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200911-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200912-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-3m200912-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2008-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2008-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2009-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2009-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2010-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2010-md-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2011-jd-nhl.out /usr/tests/usr.bin/ncal/regress.r-y2011-md-nhl.out /usr/tests/usr.bin/ncal/regress.s-b-AB-nhl.out /usr/tests/usr.bin/ncal/regress.s-b-B-nhl.out /usr/tests/usr.bin/ncal/regress.s-b-gmgy-nhl.out /usr/tests/usr.bin/ncal/regress.s-b-m-nhl.out /usr/tests/usr.bin/ncal/regress.s-b-mgy-nhl.out /usr/tests/usr.bin/ncal/regress.s-r-3-nhl.out /usr/tests/usr.bin/ncal/regress.s-r-A-nhl.out /usr/tests/usr.bin/ncal/regress.s-r-AB-nhl.out /usr/tests/usr.bin/ncal/regress.s-r-B-nhl.out /usr/tests/usr.bin/ncal/regress.s-r-gmgy-nhl.out /usr/tests/usr.bin/ncal/regress.s-r-m-nhl.out /usr/tests/usr.bin/ncal/regress.s-r-mgy-nhl.out /usr/tests/usr.bin/printf /usr/tests/usr.bin/printf/legacy_test /usr/tests/usr.bin/printf/Kyuafile /usr/tests/usr.bin/printf/regress.b.out /usr/tests/usr.bin/printf/regress.d.out /usr/tests/usr.bin/printf/regress.f.out /usr/tests/usr.bin/printf/regress.l1.out /usr/tests/usr.bin/printf/regress.l2.out /usr/tests/usr.bin/printf/regress.m1.out /usr/tests/usr.bin/printf/regress.m2.out /usr/tests/usr.bin/printf/regress.m3.out /usr/tests/usr.bin/printf/regress.m4.out /usr/tests/usr.bin/printf/regress.m5.out /usr/tests/usr.bin/printf/regress.missingpos1.out /usr/tests/usr.bin/printf/regress.s.out /usr/tests/usr.bin/printf/regress.sh /usr/tests/usr.bin/printf/regress.zero.out /usr/tests/usr.bin/sed /usr/tests/usr.bin/sed/regress.multitest.out /usr/tests/usr.bin/sed/regress.multitest.out/Kyuafile /usr/tests/usr.bin/sed/regress.multitest.out/1.1 /usr/tests/usr.bin/sed/regress.multitest.out/1.10 /usr/tests/usr.bin/sed/regress.multitest.out/1.11 /usr/tests/usr.bin/sed/regress.multitest.out/1.12 /usr/tests/usr.bin/sed/regress.multitest.out/1.13 /usr/tests/usr.bin/sed/regress.multitest.out/1.14 /usr/tests/usr.bin/sed/regress.multitest.out/1.15 /usr/tests/usr.bin/sed/regress.multitest.out/1.16 /usr/tests/usr.bin/sed/regress.multitest.out/1.17 /usr/tests/usr.bin/sed/regress.multitest.out/1.18 /usr/tests/usr.bin/sed/regress.multitest.out/1.2 /usr/tests/usr.bin/sed/regress.multitest.out/1.3 /usr/tests/usr.bin/sed/regress.multitest.out/1.4 /usr/tests/usr.bin/sed/regress.multitest.out/1.4.1 /usr/tests/usr.bin/sed/regress.multitest.out/1.5 /usr/tests/usr.bin/sed/regress.multitest.out/1.6 /usr/tests/usr.bin/sed/regress.multitest.out/1.7 /usr/tests/usr.bin/sed/regress.multitest.out/1.8 /usr/tests/usr.bin/sed/regress.multitest.out/1.9 /usr/tests/usr.bin/sed/regress.multitest.out/2.1 /usr/tests/usr.bin/sed/regress.multitest.out/2.10 /usr/tests/usr.bin/sed/regress.multitest.out/2.11 /usr/tests/usr.bin/sed/regress.multitest.out/2.12 /usr/tests/usr.bin/sed/regress.multitest.out/2.13 /usr/tests/usr.bin/sed/regress.multitest.out/2.14 /usr/tests/usr.bin/sed/regress.multitest.out/2.15 /usr/tests/usr.bin/sed/regress.multitest.out/2.16 /usr/tests/usr.bin/sed/regress.multitest.out/2.17 /usr/tests/usr.bin/sed/regress.multitest.out/2.18 /usr/tests/usr.bin/sed/regress.multitest.out/2.19 /usr/tests/usr.bin/sed/regress.multitest.out/2.2 /usr/tests/usr.bin/sed/regress.multitest.out/2.20 /usr/tests/usr.bin/sed/regress.multitest.out/2.21 /usr/tests/usr.bin/sed/regress.multitest.out/2.22 /usr/tests/usr.bin/sed/regress.multitest.out/2.3 /usr/tests/usr.bin/sed/regress.multitest.out/2.4 /usr/tests/usr.bin/sed/regress.multitest.out/2.5 /usr/tests/usr.bin/sed/regress.multitest.out/2.6 /usr/tests/usr.bin/sed/regress.multitest.out/2.7 /usr/tests/usr.bin/sed/regress.multitest.out/2.8 /usr/tests/usr.bin/sed/regress.multitest.out/2.9 /usr/tests/usr.bin/sed/regress.multitest.out/3.1 /usr/tests/usr.bin/sed/regress.multitest.out/3.2 /usr/tests/usr.bin/sed/regress.multitest.out/3.3 /usr/tests/usr.bin/sed/regress.multitest.out/3.4 /usr/tests/usr.bin/sed/regress.multitest.out/4.1 /usr/tests/usr.bin/sed/regress.multitest.out/4.2 /usr/tests/usr.bin/sed/regress.multitest.out/4.3 /usr/tests/usr.bin/sed/regress.multitest.out/4.4 /usr/tests/usr.bin/sed/regress.multitest.out/4.5 /usr/tests/usr.bin/sed/regress.multitest.out/4.6 /usr/tests/usr.bin/sed/regress.multitest.out/4.7 /usr/tests/usr.bin/sed/regress.multitest.out/4.8 /usr/tests/usr.bin/sed/regress.multitest.out/5.1 /usr/tests/usr.bin/sed/regress.multitest.out/5.2 /usr/tests/usr.bin/sed/regress.multitest.out/5.3 /usr/tests/usr.bin/sed/regress.multitest.out/5.4 /usr/tests/usr.bin/sed/regress.multitest.out/5.5 /usr/tests/usr.bin/sed/regress.multitest.out/5.6 /usr/tests/usr.bin/sed/regress.multitest.out/5.7 /usr/tests/usr.bin/sed/regress.multitest.out/5.8 /usr/tests/usr.bin/sed/regress.multitest.out/6.1 /usr/tests/usr.bin/sed/regress.multitest.out/6.2 /usr/tests/usr.bin/sed/regress.multitest.out/6.3 /usr/tests/usr.bin/sed/regress.multitest.out/6.4 /usr/tests/usr.bin/sed/regress.multitest.out/6.5 /usr/tests/usr.bin/sed/regress.multitest.out/6.6 /usr/tests/usr.bin/sed/regress.multitest.out/7.1 /usr/tests/usr.bin/sed/regress.multitest.out/7.2 /usr/tests/usr.bin/sed/regress.multitest.out/7.3 /usr/tests/usr.bin/sed/regress.multitest.out/7.4 /usr/tests/usr.bin/sed/regress.multitest.out/7.5 /usr/tests/usr.bin/sed/regress.multitest.out/7.6 /usr/tests/usr.bin/sed/regress.multitest.out/7.7 /usr/tests/usr.bin/sed/regress.multitest.out/7.8 /usr/tests/usr.bin/sed/regress.multitest.out/8.1 /usr/tests/usr.bin/sed/regress.multitest.out/8.10 /usr/tests/usr.bin/sed/regress.multitest.out/8.11 /usr/tests/usr.bin/sed/regress.multitest.out/8.12 /usr/tests/usr.bin/sed/regress.multitest.out/8.13 /usr/tests/usr.bin/sed/regress.multitest.out/8.14 /usr/tests/usr.bin/sed/regress.multitest.out/8.15 /usr/tests/usr.bin/sed/regress.multitest.out/8.16 /usr/tests/usr.bin/sed/regress.multitest.out/8.17 /usr/tests/usr.bin/sed/regress.multitest.out/8.18 /usr/tests/usr.bin/sed/regress.multitest.out/8.19 /usr/tests/usr.bin/sed/regress.multitest.out/8.2 /usr/tests/usr.bin/sed/regress.multitest.out/8.20 /usr/tests/usr.bin/sed/regress.multitest.out/8.21 /usr/tests/usr.bin/sed/regress.multitest.out/8.22 /usr/tests/usr.bin/sed/regress.multitest.out/8.23 /usr/tests/usr.bin/sed/regress.multitest.out/8.3 /usr/tests/usr.bin/sed/regress.multitest.out/8.4 /usr/tests/usr.bin/sed/regress.multitest.out/8.5 /usr/tests/usr.bin/sed/regress.multitest.out/8.6 /usr/tests/usr.bin/sed/regress.multitest.out/8.7 /usr/tests/usr.bin/sed/regress.multitest.out/8.8 /usr/tests/usr.bin/sed/regress.multitest.out/8.9 /usr/tests/usr.bin/sed/regress.multitest.out/9.1 /usr/tests/usr.bin/sed/regress.multitest.out/9.10 /usr/tests/usr.bin/sed/regress.multitest.out/9.11 /usr/tests/usr.bin/sed/regress.multitest.out/9.12 /usr/tests/usr.bin/sed/regress.multitest.out/9.13 /usr/tests/usr.bin/sed/regress.multitest.out/9.14 /usr/tests/usr.bin/sed/regress.multitest.out/9.15 /usr/tests/usr.bin/sed/regress.multitest.out/9.16 /usr/tests/usr.bin/sed/regress.multitest.out/9.17 /usr/tests/usr.bin/sed/regress.multitest.out/9.18 /usr/tests/usr.bin/sed/regress.multitest.out/9.2 /usr/tests/usr.bin/sed/regress.multitest.out/9.19 /usr/tests/usr.bin/sed/regress.multitest.out/9.20 /usr/tests/usr.bin/sed/regress.multitest.out/9.21 /usr/tests/usr.bin/sed/regress.multitest.out/9.22 /usr/tests/usr.bin/sed/regress.multitest.out/9.23 /usr/tests/usr.bin/sed/regress.multitest.out/9.24 /usr/tests/usr.bin/sed/regress.multitest.out/9.25 /usr/tests/usr.bin/sed/regress.multitest.out/9.26 /usr/tests/usr.bin/sed/regress.multitest.out/9.27 /usr/tests/usr.bin/sed/regress.multitest.out/9.28 /usr/tests/usr.bin/sed/regress.multitest.out/9.29 /usr/tests/usr.bin/sed/regress.multitest.out/9.3 /usr/tests/usr.bin/sed/regress.multitest.out/9.30 /usr/tests/usr.bin/sed/regress.multitest.out/9.31 /usr/tests/usr.bin/sed/regress.multitest.out/9.4 /usr/tests/usr.bin/sed/regress.multitest.out/9.5 /usr/tests/usr.bin/sed/regress.multitest.out/9.6 /usr/tests/usr.bin/sed/regress.multitest.out/9.7 /usr/tests/usr.bin/sed/regress.multitest.out/9.8 /usr/tests/usr.bin/sed/regress.multitest.out/9.9 /usr/tests/usr.bin/sed/Kyuafile /usr/tests/usr.bin/sed/hanoi.sed /usr/tests/usr.bin/sed/math.sed /usr/tests/usr.bin/sed/regress.G.out /usr/tests/usr.bin/sed/regress.P.out /usr/tests/usr.bin/sed/regress.b2a.out /usr/tests/usr.bin/sed/regress.bcb.out /usr/tests/usr.bin/sed/regress.c0.out /usr/tests/usr.bin/sed/regress.c1.out /usr/tests/usr.bin/sed/regress.c2.out /usr/tests/usr.bin/sed/regress.c3.out /usr/tests/usr.bin/sed/regress.hanoi.out /usr/tests/usr.bin/sed/regress.icase1.out /usr/tests/usr.bin/sed/regress.icase2.out /usr/tests/usr.bin/sed/regress.icase3.out /usr/tests/usr.bin/sed/regress.icase4.out /usr/tests/usr.bin/sed/regress.in /usr/tests/usr.bin/sed/regress.math.out /usr/tests/usr.bin/sed/regress.not.out /usr/tests/usr.bin/sed/regress.psl.out /usr/tests/usr.bin/sed/regress.s3.out /usr/tests/usr.bin/sed/regress.s4.out /usr/tests/usr.bin/sed/regress.s5.out /usr/tests/usr.bin/sed/regress.sg.out /usr/tests/usr.bin/sed/regress.sh /usr/tests/usr.bin/sed/regress.y.out /usr/tests/usr.bin/sed/legacy_test /usr/tests/usr.bin/sed/multi_test /usr/tests/usr.bin/sed/inplace_race_test /usr/tests/usr.bin/tr /usr/tests/usr.bin/tr/legacy_test /usr/tests/usr.bin/tr/Kyuafile /usr/tests/usr.bin/tr/regress.00.out /usr/tests/usr.bin/tr/regress.01.out /usr/tests/usr.bin/tr/regress.02.out /usr/tests/usr.bin/tr/regress.03.out /usr/tests/usr.bin/tr/regress.04.out /usr/tests/usr.bin/tr/regress.05.out /usr/tests/usr.bin/tr/regress.06.out /usr/tests/usr.bin/tr/regress.07.out /usr/tests/usr.bin/tr/regress.08.out /usr/tests/usr.bin/tr/regress.09.out /usr/tests/usr.bin/tr/regress.0a.out /usr/tests/usr.bin/tr/regress.0b.out /usr/tests/usr.bin/tr/regress.0c.out /usr/tests/usr.bin/tr/regress.0d.out /usr/tests/usr.bin/tr/regress.in /usr/tests/usr.bin/tr/regress.sh /usr/tests/usr.bin/tr/regress2.in /usr/tests/usr.bin/truncate /usr/tests/usr.bin/truncate/truncate_test /usr/tests/usr.bin/truncate/Kyuafile /usr/tests/usr.bin/units /usr/tests/usr.bin/units/basics_test /usr/tests/usr.bin/units/Kyuafile /usr/tests/usr.bin/uudecode /usr/tests/usr.bin/uudecode/legacy_test /usr/tests/usr.bin/uudecode/Kyuafile /usr/tests/usr.bin/uudecode/regress.base64.in /usr/tests/usr.bin/uudecode/regress.out /usr/tests/usr.bin/uudecode/regress.sh /usr/tests/usr.bin/uudecode/regress.traditional.in /usr/tests/usr.bin/uuencode /usr/tests/usr.bin/uuencode/legacy_test /usr/tests/usr.bin/uuencode/Kyuafile /usr/tests/usr.bin/uuencode/regress.base64.out /usr/tests/usr.bin/uuencode/regress.in /usr/tests/usr.bin/uuencode/regress.sh /usr/tests/usr.bin/uuencode/regress.traditional.out /usr/tests/usr.bin/xargs /usr/tests/usr.bin/xargs/legacy_test /usr/tests/usr.bin/xargs/Kyuafile /usr/tests/usr.bin/xargs/regress.0.in /usr/tests/usr.bin/xargs/regress.0.out /usr/tests/usr.bin/xargs/regress.0I.out /usr/tests/usr.bin/xargs/regress.0J.out /usr/tests/usr.bin/xargs/regress.0L.out /usr/tests/usr.bin/xargs/regress.I.out /usr/tests/usr.bin/xargs/regress.J.out /usr/tests/usr.bin/xargs/regress.L.out /usr/tests/usr.bin/xargs/regress.R.out /usr/tests/usr.bin/xargs/regress.in /usr/tests/usr.bin/xargs/regress.n1.out /usr/tests/usr.bin/xargs/regress.n2.out /usr/tests/usr.bin/xargs/regress.n3.out /usr/tests/usr.bin/xargs/regress.normal.out /usr/tests/usr.bin/xargs/regress.quotes.in /usr/tests/usr.bin/xargs/regress.quotes.out /usr/tests/usr.bin/xargs/regress.sh /usr/tests/usr.bin/yacc /usr/tests/usr.bin/yacc/yacc /usr/tests/usr.bin/yacc/yacc/big_b.output /usr/tests/usr.bin/yacc/yacc/big_l.error /usr/tests/usr.bin/yacc/yacc/big_l.output /usr/tests/usr.bin/yacc/yacc/calc.error /usr/tests/usr.bin/yacc/yacc/calc.output /usr/tests/usr.bin/yacc/yacc/calc.tab.c /usr/tests/usr.bin/yacc/yacc/calc.tab.h /usr/tests/usr.bin/yacc/yacc/calc1.error /usr/tests/usr.bin/yacc/yacc/calc1.output /usr/tests/usr.bin/yacc/yacc/calc1.tab.c /usr/tests/usr.bin/yacc/yacc/calc1.tab.h /usr/tests/usr.bin/yacc/yacc/calc2.error /usr/tests/usr.bin/yacc/yacc/calc2.output /usr/tests/usr.bin/yacc/yacc/calc2.tab.c /usr/tests/usr.bin/yacc/yacc/calc2.tab.h /usr/tests/usr.bin/yacc/yacc/calc3.error /usr/tests/usr.bin/yacc/yacc/calc3.output /usr/tests/usr.bin/yacc/yacc/calc3.tab.c /usr/tests/usr.bin/yacc/yacc/calc3.tab.h /usr/tests/usr.bin/yacc/yacc/code_calc.code.c /usr/tests/usr.bin/yacc/yacc/code_calc.error /usr/tests/usr.bin/yacc/yacc/code_calc.output /usr/tests/usr.bin/yacc/yacc/code_calc.tab.c /usr/tests/usr.bin/yacc/yacc/code_calc.tab.h /usr/tests/usr.bin/yacc/yacc/code_error.code.c /usr/tests/usr.bin/yacc/yacc/code_error.error /usr/tests/usr.bin/yacc/yacc/code_error.output /usr/tests/usr.bin/yacc/yacc/code_error.tab.c /usr/tests/usr.bin/yacc/yacc/code_error.tab.h /usr/tests/usr.bin/yacc/yacc/empty.error /usr/tests/usr.bin/yacc/yacc/empty.output /usr/tests/usr.bin/yacc/yacc/empty.tab.c /usr/tests/usr.bin/yacc/yacc/empty.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax1.error /usr/tests/usr.bin/yacc/yacc/err_syntax1.output /usr/tests/usr.bin/yacc/yacc/err_syntax1.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax1.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax10.error /usr/tests/usr.bin/yacc/yacc/err_syntax10.output /usr/tests/usr.bin/yacc/yacc/err_syntax10.tab.c /usr/tests/usr.bin/yacc/yacc/no_p_opt1.output /usr/tests/usr.bin/yacc/yacc/err_syntax10.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax11.error /usr/tests/usr.bin/yacc/yacc/err_syntax11.output /usr/tests/usr.bin/yacc/yacc/err_syntax11.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax11.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax12.error /usr/tests/usr.bin/yacc/yacc/err_syntax12.output /usr/tests/usr.bin/yacc/yacc/err_syntax12.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax12.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax13.error /usr/tests/usr.bin/yacc/yacc/err_syntax13.output /usr/tests/usr.bin/yacc/yacc/err_syntax13.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax13.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax14.error /usr/tests/usr.bin/yacc/yacc/err_syntax14.output /usr/tests/usr.bin/yacc/yacc/err_syntax14.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax14.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax15.error /usr/tests/usr.bin/yacc/yacc/err_syntax15.output /usr/tests/usr.bin/yacc/yacc/err_syntax15.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax15.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax16.error /usr/tests/usr.bin/yacc/yacc/err_syntax16.output /usr/tests/usr.bin/yacc/yacc/err_syntax16.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax16.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax17.error /usr/tests/usr.bin/yacc/yacc/err_syntax17.output /usr/tests/usr.bin/yacc/yacc/err_syntax17.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax17.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax18.error /usr/tests/usr.bin/yacc/yacc/err_syntax18.output /usr/tests/usr.bin/yacc/yacc/err_syntax18.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax18.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax19.error /usr/tests/usr.bin/yacc/yacc/err_syntax19.output /usr/tests/usr.bin/yacc/yacc/err_syntax19.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax19.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax2.error /usr/tests/usr.bin/yacc/yacc/err_syntax2.output /usr/tests/usr.bin/yacc/yacc/err_syntax2.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax2.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax20.error /usr/tests/usr.bin/yacc/yacc/err_syntax20.output /usr/tests/usr.bin/yacc/yacc/err_syntax20.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax20.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax21.error /usr/tests/usr.bin/yacc/yacc/err_syntax21.output /usr/tests/usr.bin/yacc/yacc/err_syntax21.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax21.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax22.error /usr/tests/usr.bin/yacc/yacc/err_syntax22.output /usr/tests/usr.bin/yacc/yacc/err_syntax22.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax22.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax23.error /usr/tests/usr.bin/yacc/yacc/err_syntax23.output /usr/tests/usr.bin/yacc/yacc/err_syntax23.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax23.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax24.error /usr/tests/usr.bin/yacc/yacc/err_syntax24.output /usr/tests/usr.bin/yacc/yacc/err_syntax24.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax24.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax25.error /usr/tests/usr.bin/yacc/yacc/err_syntax25.output /usr/tests/usr.bin/yacc/yacc/err_syntax25.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax25.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax26.error /usr/tests/usr.bin/yacc/yacc/err_syntax26.output /usr/tests/usr.bin/yacc/yacc/err_syntax26.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax26.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax27.error /usr/tests/usr.bin/yacc/yacc/err_syntax27.output /usr/tests/usr.bin/yacc/yacc/err_syntax27.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax27.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax3.error /usr/tests/usr.bin/yacc/yacc/err_syntax3.output /usr/tests/usr.bin/yacc/yacc/err_syntax3.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax3.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax4.error /usr/tests/usr.bin/yacc/yacc/err_syntax4.output /usr/tests/usr.bin/yacc/yacc/err_syntax4.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax4.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax5.error /usr/tests/usr.bin/yacc/yacc/err_syntax5.output /usr/tests/usr.bin/yacc/yacc/err_syntax5.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax5.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax6.error /usr/tests/usr.bin/yacc/yacc/err_syntax6.output /usr/tests/usr.bin/yacc/yacc/err_syntax6.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax6.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax7.error /usr/tests/usr.bin/yacc/yacc/err_syntax7.output /usr/tests/usr.bin/yacc/yacc/err_syntax7.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax7.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax7a.error /usr/tests/usr.bin/yacc/yacc/err_syntax7a.output /usr/tests/usr.bin/yacc/yacc/err_syntax7a.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax7a.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax7b.error /usr/tests/usr.bin/yacc/yacc/err_syntax7b.output /usr/tests/usr.bin/yacc/yacc/err_syntax7b.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax7b.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax8.error /usr/tests/usr.bin/yacc/yacc/err_syntax8.output /usr/tests/usr.bin/yacc/yacc/err_syntax8.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax8.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax8a.error /usr/tests/usr.bin/yacc/yacc/err_syntax8a.output /usr/tests/usr.bin/yacc/yacc/err_syntax8a.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax8a.tab.h /usr/tests/usr.bin/yacc/yacc/err_syntax9.error /usr/tests/usr.bin/yacc/yacc/err_syntax9.output /usr/tests/usr.bin/yacc/yacc/err_syntax9.tab.c /usr/tests/usr.bin/yacc/yacc/err_syntax9.tab.h /usr/tests/usr.bin/yacc/yacc/error.error /usr/tests/usr.bin/yacc/yacc/error.output /usr/tests/usr.bin/yacc/yacc/error.tab.c /usr/tests/usr.bin/yacc/yacc/error.tab.h /usr/tests/usr.bin/yacc/yacc/grammar.dot /usr/tests/usr.bin/yacc/yacc/grammar.error /usr/tests/usr.bin/yacc/yacc/grammar.output /usr/tests/usr.bin/yacc/yacc/grammar.tab.c /usr/tests/usr.bin/yacc/yacc/grammar.tab.h /usr/tests/usr.bin/yacc/yacc/help.error /usr/tests/usr.bin/yacc/yacc/help.output /usr/tests/usr.bin/yacc/yacc/no_b_opt.error /usr/tests/usr.bin/yacc/yacc/no_b_opt.output /usr/tests/usr.bin/yacc/yacc/no_opts.error /usr/tests/usr.bin/yacc/yacc/no_opts.output /usr/tests/usr.bin/yacc/yacc/no_output2.error /usr/tests/usr.bin/yacc/yacc/no_output2.output /usr/tests/usr.bin/yacc/yacc/no_p_opt.error /usr/tests/usr.bin/yacc/yacc/no_p_opt.output /usr/tests/usr.bin/yacc/yacc/nostdin.error /usr/tests/usr.bin/yacc/yacc/nostdin.output /usr/tests/usr.bin/yacc/yacc/ok_syntax1.error /usr/tests/usr.bin/yacc/yacc/ok_syntax1.output /usr/tests/usr.bin/yacc/yacc/ok_syntax1.tab.c /usr/tests/usr.bin/yacc/yacc/ok_syntax1.tab.h /usr/tests/usr.bin/yacc/yacc/pure_calc.error /usr/tests/usr.bin/yacc/yacc/pure_calc.output /usr/tests/usr.bin/yacc/yacc/pure_calc.tab.c /usr/tests/usr.bin/yacc/yacc/pure_calc.tab.h /usr/tests/usr.bin/yacc/yacc/pure_error.error /usr/tests/usr.bin/yacc/yacc/pure_error.output /usr/tests/usr.bin/yacc/yacc/pure_error.tab.c /usr/tests/usr.bin/yacc/yacc/pure_error.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc-s.error /usr/tests/usr.bin/yacc/yacc/quote_calc-s.output /usr/tests/usr.bin/yacc/yacc/quote_calc-s.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc-s.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc.error /usr/tests/usr.bin/yacc/yacc/quote_calc.output /usr/tests/usr.bin/yacc/yacc/quote_calc.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc2-s.error /usr/tests/usr.bin/yacc/yacc/quote_calc2-s.output /usr/tests/usr.bin/yacc/yacc/quote_calc2-s.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc2-s.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc2.error /usr/tests/usr.bin/yacc/yacc/quote_calc2.output /usr/tests/usr.bin/yacc/yacc/quote_calc2.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc2.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc3-s.error /usr/tests/usr.bin/yacc/yacc/quote_calc3-s.output /usr/tests/usr.bin/yacc/yacc/quote_calc3-s.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc3-s.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc3.error /usr/tests/usr.bin/yacc/yacc/quote_calc3.output /usr/tests/usr.bin/yacc/yacc/quote_calc3.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc3.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc4-s.error /usr/tests/usr.bin/yacc/yacc/quote_calc4-s.output /usr/tests/usr.bin/yacc/yacc/quote_calc4-s.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc4-s.tab.h /usr/tests/usr.bin/yacc/yacc/quote_calc4.error /usr/tests/usr.bin/yacc/yacc/quote_calc4.output /usr/tests/usr.bin/yacc/yacc/quote_calc4.tab.c /usr/tests/usr.bin/yacc/yacc/quote_calc4.tab.h /usr/tests/usr.bin/yacc/yacc/rename_debug.c /usr/tests/usr.bin/yacc/yacc/rename_debug.error /usr/tests/usr.bin/yacc/yacc/rename_debug.h /usr/tests/usr.bin/yacc/yacc/rename_debug.i /usr/tests/usr.bin/yacc/yacc/rename_debug.output /usr/tests/usr.bin/yacc/yacc/varsyntax_calc1.error /usr/tests/usr.bin/yacc/yacc/varsyntax_calc1.output /usr/tests/usr.bin/yacc/yacc/varsyntax_calc1.tab.c /usr/tests/usr.bin/yacc/yacc/varsyntax_calc1.tab.h /usr/tests/usr.bin/yacc/yacc/no_b_opt1.error /usr/tests/usr.bin/yacc/yacc/no_b_opt1.output /usr/tests/usr.bin/yacc/yacc/no_code_c.error /usr/tests/usr.bin/yacc/yacc/no_code_c.output /usr/tests/usr.bin/yacc/yacc/no_defines.error /usr/tests/usr.bin/yacc/yacc/no_defines.output /usr/tests/usr.bin/yacc/yacc/no_graph.error /usr/tests/usr.bin/yacc/yacc/no_graph.output /usr/tests/usr.bin/yacc/yacc/no_include.error /usr/tests/usr.bin/yacc/yacc/no_include.output /usr/tests/usr.bin/yacc/yacc/no_output.error /usr/tests/usr.bin/yacc/yacc/no_output.output /usr/tests/usr.bin/yacc/yacc/no_output1.error /usr/tests/usr.bin/yacc/yacc/no_output1.output /usr/tests/usr.bin/yacc/yacc/no_p_opt1.error /usr/tests/usr.bin/yacc/yacc/big_b.error /usr/tests/usr.bin/yacc/yacc/no_verbose.error /usr/tests/usr.bin/yacc/yacc/no_verbose.output /usr/tests/usr.bin/yacc/run_test /usr/tests/usr.bin/yacc/yacc_tests /usr/tests/usr.bin/yacc/btyacc_calc1.y /usr/tests/usr.bin/yacc/btyacc_demo.y /usr/tests/usr.bin/yacc/calc.y /usr/tests/usr.bin/yacc/calc1.y /usr/tests/usr.bin/yacc/calc2.y /usr/tests/usr.bin/yacc/calc3.y /usr/tests/usr.bin/yacc/code_calc.y /usr/tests/usr.bin/yacc/code_debug.y /usr/tests/usr.bin/yacc/code_error.y /usr/tests/usr.bin/yacc/empty.y /usr/tests/usr.bin/yacc/err_inherit1.y /usr/tests/usr.bin/yacc/err_inherit2.y /usr/tests/usr.bin/yacc/err_inherit3.y /usr/tests/usr.bin/yacc/err_inherit4.y /usr/tests/usr.bin/yacc/err_inherit5.y /usr/tests/usr.bin/yacc/err_syntax1.y /usr/tests/usr.bin/yacc/err_syntax10.y /usr/tests/usr.bin/yacc/err_syntax11.y /usr/tests/usr.bin/yacc/err_syntax12.y /usr/tests/usr.bin/yacc/error.y /usr/tests/usr.bin/yacc/err_syntax13.y /usr/tests/usr.bin/yacc/err_syntax14.y /usr/tests/usr.bin/yacc/err_syntax15.y /usr/tests/usr.bin/yacc/err_syntax16.y /usr/tests/usr.bin/yacc/err_syntax17.y /usr/tests/usr.bin/yacc/err_syntax18.y /usr/tests/usr.bin/yacc/err_syntax19.y /usr/tests/usr.bin/yacc/err_syntax2.y /usr/tests/usr.bin/yacc/err_syntax20.y /usr/tests/usr.bin/yacc/err_syntax21.y /usr/tests/usr.bin/yacc/err_syntax22.y /usr/tests/usr.bin/yacc/err_syntax23.y /usr/tests/usr.bin/yacc/err_syntax24.y /usr/tests/usr.bin/yacc/err_syntax25.y /usr/tests/usr.bin/yacc/err_syntax26.y /usr/tests/usr.bin/yacc/err_syntax27.y /usr/tests/usr.bin/yacc/err_syntax3.y /usr/tests/usr.bin/yacc/err_syntax4.y /usr/tests/usr.bin/yacc/err_syntax5.y /usr/tests/usr.bin/yacc/err_syntax6.y /usr/tests/usr.bin/yacc/err_syntax7.y /usr/tests/usr.bin/yacc/err_syntax7a.y /usr/tests/usr.bin/yacc/err_syntax7b.y /usr/tests/usr.bin/yacc/err_syntax8.y /usr/tests/usr.bin/yacc/err_syntax8a.y /usr/tests/usr.bin/yacc/err_syntax9.y /usr/tests/usr.bin/yacc/grammar.y /usr/tests/usr.bin/yacc/inherit0.y /usr/tests/usr.bin/yacc/inherit1.y /usr/tests/usr.bin/yacc/inherit2.y /usr/tests/usr.bin/yacc/ok_syntax1.y /usr/tests/usr.bin/yacc/pure_calc.y /usr/tests/usr.bin/yacc/pure_error.y /usr/tests/usr.bin/yacc/quote_calc.y /usr/tests/usr.bin/yacc/quote_calc2.y /usr/tests/usr.bin/yacc/quote_calc3.y /usr/tests/usr.bin/yacc/quote_calc4.y /usr/tests/usr.bin/yacc/varsyntax_calc1.y /usr/tests/usr.bin/yacc/Kyuafile /usr/tests/usr.bin/Kyuafile /usr/tests/usr.bin/regress.m4 /usr/tests/usr.bin/mkimg /usr/tests/usr.bin/mkimg/img-1x1-4096-apm.raw /usr/tests/usr.bin/mkimg/img-1x1-4096-apm.vhd /usr/tests/usr.bin/mkimg/img-1x1-4096-apm.vhdf /usr/tests/usr.bin/mkimg/img-1x1-4096-apm.vmdk /usr/tests/usr.bin/mkimg/img-1x1-4096-bsd.qcow /usr/tests/usr.bin/mkimg/img-1x1-4096-bsd.raw /usr/tests/usr.bin/mkimg/img-1x1-4096-bsd.vhd /usr/tests/usr.bin/mkimg/img-1x1-4096-bsd.vhdf /usr/tests/usr.bin/mkimg/img-1x1-4096-bsd.vmdk /usr/tests/usr.bin/mkimg/img-1x1-4096-ebr.qcow /usr/tests/usr.bin/mkimg/img-1x1-4096-ebr.raw /usr/tests/usr.bin/mkimg/img-1x1-4096-ebr.vhd /usr/tests/usr.bin/mkimg/img-1x1-4096-ebr.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-ebr.vhd /usr/tests/usr.bin/mkimg/img-1x1-512-pc98.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-ebr.vmdk /usr/tests/usr.bin/mkimg/img-1x1-4096-gpt.qcow /usr/tests/usr.bin/mkimg/img-1x1-4096-gpt.raw /usr/tests/usr.bin/mkimg/img-1x1-4096-gpt.vhd /usr/tests/usr.bin/mkimg/img-1x1-4096-gpt.vhdf /usr/tests/usr.bin/mkimg/img-1x1-4096-gpt.vmdk /usr/tests/usr.bin/mkimg/img-1x1-4096-mbr.qcow /usr/tests/usr.bin/mkimg/img-1x1-4096-mbr.raw /usr/tests/usr.bin/mkimg/img-1x1-4096-mbr.vhd /usr/tests/usr.bin/mkimg/img-1x1-4096-mbr.vhdf /usr/tests/usr.bin/mkimg/img-1x1-4096-mbr.vmdk /usr/tests/usr.bin/mkimg/img-1x1-4096-pc98.qcow /usr/tests/usr.bin/mkimg/img-1x1-4096-pc98.raw /usr/tests/usr.bin/mkimg/img-1x1-4096-pc98.vhd /usr/tests/usr.bin/mkimg/img-1x1-4096-pc98.vhdf /usr/tests/usr.bin/mkimg/img-1x1-4096-pc98.vmdk /usr/tests/usr.bin/mkimg/img-1x1-4096-vtoc8.qcow /usr/tests/usr.bin/mkimg/img-1x1-4096-vtoc8.raw /usr/tests/usr.bin/mkimg/img-1x1-4096-vtoc8.vhd /usr/tests/usr.bin/mkimg/img-1x1-4096-vtoc8.vhdf /usr/tests/usr.bin/mkimg/img-1x1-4096-vtoc8.vmdk /usr/tests/usr.bin/mkimg/img-1x1-512-apm.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-apm.raw /usr/tests/usr.bin/mkimg/img-1x1-512-apm.vhd /usr/tests/usr.bin/mkimg/img-1x1-512-apm.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-apm.vmdk /usr/tests/usr.bin/mkimg/img-1x1-512-bsd.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-bsd.raw /usr/tests/usr.bin/mkimg/img-1x1-512-bsd.vhd /usr/tests/usr.bin/mkimg/img-1x1-512-bsd.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-bsd.vmdk /usr/tests/usr.bin/mkimg/img-1x1-512-ebr.qcow /usr/tests/usr.bin/mkimg/mkimg /usr/tests/usr.bin/mkimg/img-1x1-512-ebr.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-ebr.vmdk /usr/tests/usr.bin/mkimg/img-1x1-512-gpt.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-gpt.vhd /usr/tests/usr.bin/mkimg/img-1x1-512-gpt.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-gpt.vmdk /usr/tests/usr.bin/mkimg/img-1x1-512-mbr.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-mbr.raw /usr/tests/usr.bin/mkimg/img-1x1-512-mbr.vhd /usr/tests/usr.bin/mkimg/img-1x1-512-mbr.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-mbr.vmdk /usr/tests/usr.bin/mkimg/img-1x1-512-pc98.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-pc98.raw /usr/tests/usr.bin/mkimg/img-63x255-512-vtoc8.raw /usr/tests/usr.bin/mkimg/img-1x1-512-mbr.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-apm.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-pc98.vhd /usr/tests/usr.bin/mkimg/img-1x1-512-pc98.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-pc98.vmdk /usr/tests/usr.bin/mkimg/img-1x1-512-vtoc8.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-vtoc8.raw /usr/tests/usr.bin/mkimg/img-1x1-512-vtoc8.vhd /usr/tests/usr.bin/mkimg/img-1x1-512-vtoc8.vhdf /usr/tests/usr.bin/mkimg/img-1x1-512-vtoc8.vmdk /usr/tests/usr.bin/mkimg/img-63x255-4096-apm.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-apm.vhd /usr/tests/usr.bin/mkimg/img-63x255-4096-apm.vhdf /usr/tests/usr.bin/mkimg/img-63x255-4096-apm.vmdk /usr/tests/usr.bin/mkimg/img-63x255-4096-bsd.qcow /usr/tests/usr.bin/mkimg/img-63x255-4096-bsd.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-mbr.vhdf /usr/tests/usr.bin/mkimg/img-63x255-4096-bsd.vhd /usr/tests/usr.bin/mkimg/img-63x255-4096-bsd.vhdf /usr/tests/usr.bin/mkimg/img-63x255-4096-bsd.vmdk /usr/tests/usr.bin/mkimg/img-63x255-4096-ebr.qcow /usr/tests/usr.bin/mkimg/img-63x255-4096-ebr.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-ebr.vhd /usr/tests/usr.bin/mkimg/img-63x255-4096-ebr.vhdf /usr/tests/usr.bin/mkimg/img-63x255-4096-ebr.vmdk /usr/tests/usr.bin/mkimg/img-63x255-4096-gpt.qcow /usr/tests/usr.bin/mkimg/img-63x255-4096-gpt.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-gpt.vhd /usr/tests/usr.bin/mkimg/img-63x255-4096-gpt.vhdf /usr/tests/usr.bin/mkimg/img-63x255-4096-gpt.vmdk /usr/tests/usr.bin/mkimg/img-63x255-4096-mbr.qcow /usr/tests/usr.bin/mkimg/img-1x1-512-ebr.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-mbr.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-mbr.vhd /usr/tests/usr.bin/mkimg/img-63x255-4096-mbr.vmdk /usr/tests/usr.bin/mkimg/img-63x255-4096-pc98.qcow /usr/tests/usr.bin/mkimg/img-63x255-4096-pc98.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-pc98.vhd /usr/tests/usr.bin/mkimg/img-63x255-4096-pc98.vhdf /usr/tests/usr.bin/mkimg/img-63x255-4096-pc98.vmdk /usr/tests/usr.bin/mkimg/img-63x255-4096-vtoc8.qcow /usr/tests/usr.bin/mkimg/img-63x255-4096-vtoc8.raw /usr/tests/usr.bin/mkimg/img-63x255-4096-vtoc8.vhd /usr/tests/usr.bin/mkimg/img-63x255-4096-vtoc8.vhdf /usr/tests/usr.bin/mkimg/img-63x255-4096-vtoc8.vmdk /usr/tests/usr.bin/mkimg/img-63x255-512-pc98.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-apm.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-apm.raw /usr/tests/usr.bin/mkimg/img-63x255-512-apm.vhd /usr/tests/usr.bin/mkimg/img-63x255-512-apm.vhdf /usr/tests/usr.bin/mkimg/img-63x255-512-apm.vmdk /usr/tests/usr.bin/mkimg/img-63x255-512-bsd.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-bsd.raw /usr/tests/usr.bin/mkimg/img-63x255-512-bsd.vhd /usr/tests/usr.bin/mkimg/img-63x255-512-bsd.vhdf /usr/tests/usr.bin/mkimg/img-63x255-512-bsd.vmdk /usr/tests/usr.bin/mkimg/img-63x255-512-ebr.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-ebr.raw /usr/tests/usr.bin/mkimg/img-63x255-512-ebr.vhd /usr/tests/usr.bin/mkimg/img-63x255-512-ebr.vhdf /usr/tests/usr.bin/mkimg/img-63x255-512-ebr.vmdk /usr/tests/usr.bin/mkimg/img-63x255-512-gpt.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-gpt.raw /usr/tests/usr.bin/mkimg/img-63x255-512-gpt.vhd /usr/tests/usr.bin/mkimg/img-63x255-512-gpt.vhdf /usr/tests/usr.bin/mkimg/img-63x255-512-gpt.vmdk /usr/tests/usr.bin/mkimg/img-63x255-512-mbr.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-mbr.raw /usr/tests/usr.bin/mkimg/img-63x255-512-mbr.vhd /usr/tests/usr.bin/mkimg/img-63x255-512-mbr.vhdf /usr/tests/usr.bin/mkimg/img-63x255-512-mbr.vmdk /usr/tests/usr.bin/mkimg/img-63x255-512-pc98.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-512-pc98.raw /usr/tests/usr.bin/mkimg/img-63x255-512-pc98.vhd /usr/tests/usr.bin/mkimg/img-63x255-512-pc98.vhdf /usr/tests/usr.bin/mkimg/img-63x255-512-pc98.vmdk /usr/tests/usr.bin/mkimg/img-63x255-512-vtoc8.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-vtoc8.vhd /usr/tests/usr.bin/mkimg/img-63x255-512-vtoc8.vhdf /usr/tests/usr.bin/mkimg/img-63x255-512-vtoc8.vmdk /usr/tests/usr.bin/mkimg/img-1x1-4096-apm.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-bsd.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-ebr.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-gpt.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-mbr.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-pc98.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-4096-vtoc8.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-512-apm.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-512-bsd.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-512-ebr.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-512-gpt.qcow2 /usr/tests/usr.bin/mkimg/img-1x1-512-gpt.raw /usr/tests/usr.bin/mkimg/Kyuafile /usr/tests/usr.bin/mkimg/img-1x1-512-vtoc8.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-apm.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-bsd.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-ebr.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-gpt.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-mbr.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-pc98.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-vtoc8.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-512-apm.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-512-bsd.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-512-ebr.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-512-gpt.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-512-mbr.qcow2 /usr/tests/usr.bin/mkimg/img-63x255-4096-apm.qcow /usr/tests/usr.bin/mkimg/img-63x255-512-vtoc8.qcow2 /usr/tests/usr.bin/basename /usr/tests/usr.bin/basename/basename_test /usr/tests/usr.bin/basename/Kyuafile /usr/tests/usr.bin/cmp /usr/tests/usr.bin/cmp/cmp_test /usr/tests/usr.bin/cmp/Kyuafile /usr/tests/usr.bin/cut /usr/tests/usr.bin/cut/cut_test /usr/tests/usr.bin/cut/Kyuafile /usr/tests/usr.bin/cut/d_basic.out /usr/tests/usr.bin/cut/d_cut.in /usr/tests/usr.bin/cut/d_dflag.out /usr/tests/usr.bin/cut/d_dsflag.out /usr/tests/usr.bin/cut/d_latin1.in /usr/tests/usr.bin/cut/d_sflag.out /usr/tests/usr.bin/cut/d_utf8.in /usr/tests/usr.bin/dirname /usr/tests/usr.bin/dirname/dirname_test /usr/tests/usr.bin/dirname/Kyuafile /usr/tests/usr.bin/grep /usr/tests/usr.bin/grep/grep_test /usr/tests/usr.bin/grep/Kyuafile /usr/tests/usr.bin/grep/d_basic.out /usr/tests/usr.bin/grep/d_begin_end_a.out /usr/tests/usr.bin/grep/d_begin_end_b.out /usr/tests/usr.bin/grep/d_binary.out /usr/tests/usr.bin/grep/d_context2_a.out /usr/tests/usr.bin/grep/d_context2_b.out /usr/tests/usr.bin/grep/d_context2_c.out /usr/tests/usr.bin/grep/d_context_a.in /usr/tests/usr.bin/grep/d_context_a.out /usr/tests/usr.bin/grep/d_context_b.in /usr/tests/usr.bin/grep/d_context_b.out /usr/tests/usr.bin/grep/d_context_c.out /usr/tests/usr.bin/grep/d_context_d.out /usr/tests/usr.bin/grep/d_egrep.out /usr/tests/usr.bin/grep/d_file_exp.in /usr/tests/usr.bin/grep/d_file_exp.out /usr/tests/usr.bin/grep/d_ignore_case.out /usr/tests/usr.bin/grep/d_input /usr/tests/usr.bin/grep/d_invert.in /usr/tests/usr.bin/grep/d_invert.out /usr/tests/usr.bin/grep/d_recurse.out /usr/tests/usr.bin/grep/d_recurse_symlink.err /usr/tests/usr.bin/grep/d_recurse_symlink.out /usr/tests/usr.bin/grep/d_whole_line.out /usr/tests/usr.bin/grep/d_word_regexps.out /usr/tests/usr.bin/grep/d_zgrep.out /usr/tests/usr.bin/gzip /usr/tests/usr.bin/gzip/gzip_test /usr/tests/usr.bin/gzip/Kyuafile /usr/tests/usr.bin/timeout /usr/tests/usr.bin/timeout/timeout /usr/tests/usr.bin/timeout/Kyuafile /usr/tests/usr.sbin /usr/tests/usr.sbin/etcupdate /usr/tests/usr.sbin/etcupdate/always_test /usr/tests/usr.sbin/etcupdate/conflicts_test /usr/tests/usr.sbin/etcupdate/fbsdid_test /usr/tests/usr.sbin/etcupdate/ignore_test /usr/tests/usr.sbin/etcupdate/preworld_test /usr/tests/usr.sbin/etcupdate/tests_test /usr/tests/usr.sbin/etcupdate/tzsetup_test /usr/tests/usr.sbin/etcupdate/Kyuafile /usr/tests/usr.sbin/newsyslog /usr/tests/usr.sbin/newsyslog/legacy_test /usr/tests/usr.sbin/newsyslog/Kyuafile /usr/tests/usr.sbin/sa /usr/tests/usr.sbin/sa/legacy_test /usr/tests/usr.sbin/sa/Kyuafile /usr/tests/usr.sbin/sa/v1-amd64-sav.in /usr/tests/usr.sbin/sa/v1-amd64-sav.out /usr/tests/usr.sbin/sa/v1-amd64-u.out /usr/tests/usr.sbin/sa/v1-amd64-usr.in /usr/tests/usr.sbin/sa/v1-amd64-usr.out /usr/tests/usr.sbin/sa/v1-i386-sav.in /usr/tests/usr.sbin/sa/v1-i386-sav.out /usr/tests/usr.sbin/sa/v1-i386-u.out /usr/tests/usr.sbin/sa/v1-i386-usr.in /usr/tests/usr.sbin/sa/v1-i386-usr.out /usr/tests/usr.sbin/sa/v1-sparc64-sav.in /usr/tests/usr.sbin/sa/v1-sparc64-sav.out /usr/tests/usr.sbin/sa/v1-sparc64-u.out /usr/tests/usr.sbin/sa/v1-sparc64-usr.in /usr/tests/usr.sbin/sa/v1-sparc64-usr.out /usr/tests/usr.sbin/sa/v2-amd64-sav.in /usr/tests/usr.sbin/sa/v2-amd64-u.out /usr/tests/usr.sbin/sa/v2-amd64-usr.in /usr/tests/usr.sbin/sa/v2-i386-sav.in /usr/tests/usr.sbin/sa/v2-i386-u.out /usr/tests/usr.sbin/sa/v2-i386-usr.in /usr/tests/usr.sbin/sa/v2-sparc64-sav.in /usr/tests/usr.sbin/sa/v2-sparc64-u.out /usr/tests/usr.sbin/sa/v2-sparc64-usr.in /usr/tests/usr.sbin/Kyuafile /usr/tests/usr.sbin/pw /usr/tests/usr.sbin/pw/pw_delete /usr/tests/usr.sbin/pw/Kyuafile /usr/tests/usr.sbin/pw/group /usr/tests/usr.sbin/pw/helper_functions.shin /usr/tests/usr.sbin/pw/master.passwd /usr/tests/usr.sbin/pw/pw_modify /usr/tests/usr.sbin/nmtree /usr/tests/usr.sbin/nmtree/nmtree_test /usr/tests/usr.sbin/nmtree/Kyuafile /usr/tests/usr.sbin/nmtree/mtree_d_create.out /usr/tests/usr.sbin/nmtree/netbsd6_d_create.out /usr/tests/usr.sbin/nmtree/d_convert.in /usr/tests/usr.sbin/nmtree/d_convert_C.out /usr/tests/usr.sbin/nmtree/d_convert_C_S.out /usr/tests/usr.sbin/nmtree/d_convert_D.out /usr/tests/usr.sbin/nmtree/d_convert_D_S.out /usr/tests/usr.sbin/nmtree/d_merge.in /usr/tests/usr.sbin/nmtree/d_merge_C_M.out /usr/tests/usr.sbin/nmtree/d_merge_C_M_S.out /usr/tests/Kyuafile /usr/tests/local From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 23:08:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 977D4636 for ; Fri, 31 Oct 2014 23:08:57 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D8B6125 for ; Fri, 31 Oct 2014 23:08:57 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 428151B916; Fri, 31 Oct 2014 16:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1414796937; x=1414811337; bh=3juowC+eK3lG8u5bAtnsctAjMdn9WkAgmaXTLXbT3Bc=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=dwObJV/8iElp7ulq8PVI1CaXSn/N2N6GttOMzVNE0O7h7o4zbdfTfHreA29U9XE0y Fgv4x9QIhyX94iWRftlh2knk7IiKhXrERy5aaCYNJKm33h8y04u52xemO9Y7OtrFaP kEa9Xty0EpWKZOkRyRYlTp8GqKrNpJqTdUmzJAEY= Message-ID: <54541688.8010404@delphij.net> Date: Fri, 31 Oct 2014 16:08:56 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: "O. Hartmann" , FreeBSD CURRENT Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> In-Reply-To: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 23:08:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The problem should have been corrected by r273919. Please update your system and update /etc/ with mergemaster. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUVBaIAAoJEJW2GBstM+nsDHIP/jEgsdtn8ZWbwSHCh8RBXhM7 rr7wdRXcti0h8G0htXTaWWrEaJ1Y7LKGVBjqrUqTJU/g7mRha/p2BrEsYMGBwFbT uqPDYIiHvfVIDH6wAO5qi1CvPG8UhsGG3IV+RXEazeBFlNUA50ZRhyhYtvuywoWw 9izOCtc1y3pEuR3i7Ybpors6oulyYWIpd/tuafkVWmhrLblvCLNv6wrmwxAcXtNN UC92bvH320nqA49AC1jAD0zrZ5uc6fPBgcSXi1SZvmnuxnODRrV/O0yD67fUHKtm 59x7woa4tMaVNtP+eQ2QSZv75oko5HmZqfAV4urTQjfb44wDj42uFOKN8WHmMNbe RxZ/b7dhbU9BMKhnf117IIg2P96o2Hj9jwBN6+PaPoPw2UGSgiJf7/bf3RnEZCoM TISlyv3fAvbNg7yuGAZsm8onjUPIfjlriOUhUeiKzNDhQDRW8eKWDPEio8IapyJW wYLtNPjARYUfIswAVMRn5NuNzjqloPKLjXf2YOtREb/c3K1UZMRLTc98zPhJ7za+ 6EzIe/CuY7X55ajwK8Fqmqh/G3TiaSomwiVzZrtl2ggdeXsMsWfeaV0E9gtspVwb Qaprmo1Qx/vZUhHPy8L/OHqvCF39z4RC4N/4ryc7gt5gpW9jkeWzyYvGD/wCdV7b bHxbVZR+Ukuz2B4aUFH5 =J3ap -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 23:17:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1CDFC3A for ; Fri, 31 Oct 2014 23:17:15 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC00A219 for ; Fri, 31 Oct 2014 23:17:15 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XkLRP-003PMu-LE>; Sat, 01 Nov 2014 00:17:11 +0100 Received: from f052009172.adsl.alicedsl.de ([78.52.9.172] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XkLRP-0044DJ-J5>; Sat, 01 Nov 2014 00:17:11 +0100 Date: Sat, 1 Nov 2014 00:17:06 +0100 From: "O. Hartmann" To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! Message-ID: <20141101001706.43ac0d8b.ohartman@zedat.fu-berlin.de> In-Reply-To: <86a94c9bn3.fsf@nine.des.no> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/2q4HCGQB0I8erfgkcuHYwVm"; protocol="application/pgp-signature" X-Originating-IP: 78.52.9.172 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 23:17:16 -0000 --Sig_/2q4HCGQB0I8erfgkcuHYwVm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Fri, 31 Oct 2014 22:23:28 +0100 Dag-Erling Sm=C3=B8rgrav schrieb: > Can you all please tell me which revision(s) you were running before you > upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" > should do the trick. >=20 > DES r273800 was the last (obviously) working on one box, r273872 seems to have = the problem: /var/log/messages:Oct 30 05:53:45 <0.2> gate kernel: FreeBSD 11.0-CURRENT #= 0 r273800: Tue Oct 28 21:24:08 CET 2014 /var/log/messages:Oct 31 05:32:25 <0.2> gate kerne= l: FreeBSD 11.0-CURRENT #1 r273872: Thu Oct 30 22:32:59 CET 2014 /var/log/messages:Oct= 31 19:59:55 <0.2> gate kernel: FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET= 2014 r273746: Mon Oct 27 21:43:42 CET 2014 is the one I'm sure it worked flawles= s. I did the past two days daily builds. --Sig_/2q4HCGQB0I8erfgkcuHYwVm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUVBh2AAoJEOgBcD7A/5N8zgsH/3C36NKXj2VDEgflZ6hc13mu aTpzSQgrAQnWRyXaP8dmafEp9SWlOlK3pcqLzVER/SbvEsHEMfdkoFqARNidW4nb KPGudhsp31tAjxcxlMEwWMDGqi5SNubwv+Q8EkOmt4RGQgURDNNkCLRfg/Af8xeB itim8Pa2ShqieAMeq0AcqR5cx9JWLM8Ru21EQIrS3MEKjqCQvEgpsrrcdaZFCQU0 pIEnyIqIlNYEp0gn6op6drzEGQIub4w43pZMuk4OOH2PvU7ZQdcutmAeGBTYU9aP g9hJg/0goYpU4vX0uoFEj6I4slNfhGpWJ+bB0FMIuwFO8qHjkrV9Q6VGPGSKMvk= =QC4J -----END PGP SIGNATURE----- --Sig_/2q4HCGQB0I8erfgkcuHYwVm-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 23:19:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4240D70 for ; Fri, 31 Oct 2014 23:19:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C2D3022A for ; Fri, 31 Oct 2014 23:19:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 27B2B5C3 for ; Fri, 31 Oct 2014 23:19:52 +0000 (UTC) Date: Fri, 31 Oct 2014 23:19:51 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1535194959.22.1414797591824.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <260264135.21.1414787018889.JavaMail.jenkins@jenkins-9.freebsd.org> References: <260264135.21.1414787018889.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #163 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 23:19:51 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 23:23:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67328102; Fri, 31 Oct 2014 23:23:18 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AECE307; Fri, 31 Oct 2014 23:23:18 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id ft15so8042374pdb.25 for ; Fri, 31 Oct 2014 16:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0sQBY8b3RndHA9SrER62lP8g3mFgu3oHwljczle9lW0=; b=Qu3l6f7jHeo6Jz6blRMiT7T1fmNVIUlSuzjJ9alrWq2/Fm/akGDBxuIr4L6km83DqM z8ahXMPQNF64bAAh/u6P9khvangWZtCjWfW6wBcfb6y0AipaC2yzZqUY/Wo4p227IqAl AiN3iDV0ePvK+STan2hrzhE64S3g9yk4jrtW/Zm1hFa+kdItPHtYesYsdGlVpcHV5SVc n/bXfGRflDQuwIliYC6MyJ3VCVFkIVy2cJU9brz8ZpFVAh6mGfgF51XcKLRTcvAhSJ1o zNfsjgZbvJq+DIlDmjykdW3EyT+3tJnKsHMoGX303rv0M/omnppxS2pYUktiZOacPfJY OnQg== X-Received: by 10.67.16.106 with SMTP id fv10mr27959498pad.47.1414797797580; Fri, 31 Oct 2014 16:23:17 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:34d4:4abd:64bb:590a? ([2601:8:ab80:7d6:34d4:4abd:64bb:590a]) by mx.google.com with ESMTPSA id t11sm10861792pdj.89.2014.10.31.16.23.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 16:23:17 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2AA508F5-14F7-4EE7-93C2-72B089663C2E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161 From: Garrett Cooper In-Reply-To: <333534ED-2753-48DC-98F7-4B4853A1CFEB@gmail.com> Date: Fri, 31 Oct 2014 16:23:15 -0700 Message-Id: References: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> <333534ED-2753-48DC-98F7-4B4853A1CFEB@gmail.com> To: "jenkins-admin@freebsd.org" , Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 23:23:18 -0000 --Apple-Mail=_2AA508F5-14F7-4EE7-93C2-72B089663C2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 31, 2014, at 10:12, Garrett Cooper wrote: >> On Oct 31, 2014, at 10:04, jenkins-admin@freebsd.org wrote: >>=20 >> See = >=20 > Hi Craig, > I have a potential fix for this on my github branch (I ATFified the = testcase and fixed some broken assumptions; I'll find the PR later). Now = that boot is fixed on head I can upgrade, and will see about testing out = the fix. If I don't get to it today, I'll look at fixing it when I'm = down at MeetBSD. > Thank you, Given the discussion on one of the FreeBSD IRC channels about /dev/md0 = being mounted at boot due to potential fallout from the random(4) = rewrite (until r273919, potentially=85), this is probably a symptom of = this PR I filed a while back: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191191 . I'll take = ownership in getting the fix in this weekend/early next week. Thanks! --Apple-Mail=_2AA508F5-14F7-4EE7-93C2-72B089663C2E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUVBnjAAoJEMZr5QU6S73emCQH/R5uQSCRwhr+t+SimilbLU8+ bqINyZghPcYoFLZP4s3GDnaZZpMqXMs8xSog3kebN8xMzqOtc1OjpknEwTwsLBl8 B7z7aXoZJOabwS0SVr3cgSBdNyl5UOcjdOSOHIYH6LJiXW0B79+klWnL6UOs1F5n rJ11wtwmb7Ue9VrLIDrWYhjgXuLDI6bxeScGwfNEwfY4FuB8pKsmRR6I4dgSwzLJ 5YF8r9ODtlkIRMHoR594aMTHZhukFjF2bmp+wklLQoz4gOvYXqY8/ACC7TU+fn8V iOLIGz0hZ7raCYyMsxQRds4rdvvtB4j+Wa9coq25GtsQBwzXSuQocRsFlX46YYQ= =ZHgK -----END PGP SIGNATURE----- --Apple-Mail=_2AA508F5-14F7-4EE7-93C2-72B089663C2E-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 23:27:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF6984CC for ; Fri, 31 Oct 2014 23:27:51 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E0AD33C for ; Fri, 31 Oct 2014 23:27:51 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id ft15so8096767pdb.7 for ; Fri, 31 Oct 2014 16:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UR37uNHgYCP4eh87TWgU68LiQzPVjXA2ZLy96GJ7m2U=; b=OZ8a7eq3r4Y1T8Ovtp2dvnCqXeisDMHr11WHIDIkypOwV5kiEtHH/jZJdAkNTUW/WI IVT0fkhwKHvfh562b2hCr+m2tRVDZPZwPAqlztF1+8E3KrG7slKRaMfsJQLY1u//Ui+6 wF4ccXE+EaO0jngJmIKvAuPFn7+ZzmqgeHLDBPahxdYzUZB9Uz6J7urzlazyhoTmeStu KYb6AZAFchnkt09jdigapug4vXxLIGA6pZan2vpF0EUsPIaPkfwdtY1wk4IDziG0NgNp IP7hYl0I+GW9wHuWeG8rR1znmhkwqCJQ8YAvqAsTT2OgW3jDZYJrh1SDCtDlL0m6dM3y wC/A== X-Received: by 10.66.157.161 with SMTP id wn1mr27645522pab.40.1414798071077; Fri, 31 Oct 2014 16:27:51 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:34d4:4abd:64bb:590a? ([2601:8:ab80:7d6:34d4:4abd:64bb:590a]) by mx.google.com with ESMTPSA id h6sm10898531pdk.38.2014.10.31.16.27.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 16:27:50 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EE9447E2-C8AD-47C0-8ADA-426AEB7E96ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! From: Garrett Cooper In-Reply-To: <54540EB4.80207@orange.fr> Date: Fri, 31 Oct 2014 16:27:49 -0700 Message-Id: <87BC147E-61E5-45C8-9763-D15929BED9B5@gmail.com> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <54540442.4070204@orange.fr> <54540EB4.80207@orange.fr> To: martin.mato@orange.fr X-Mailer: Apple Mail (2.1878.6) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 31 Oct 2014 23:27:51 -0000 --Apple-Mail=_EE9447E2-C8AD-47C0-8ADA-426AEB7E96ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 31, 2014, at 15:35, Martin MATO wrote: > Le 31/10/2014 22:50, Martin MATO a =E9crit : >> Le 31/10/2014 22:23, Dag-Erling Sm=F8rgrav a =E9crit : >>> Can you all please tell me which revision(s) you were running before = you >>> upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" >>> should do the trick. >>>=20 >>> DES >> Absolutely >> here it is >>=20 >> /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 = r273863: Thu Oct 30 16:55:16 CET 2014 >>=20 >> ps: there is no filesystem corruption (first thing i checked twice.) ... > the is one thing i noticed: > there is a new directory under /usr called "tests" containing several = directories and files > maybe something goes wrong in the 'make installworld' part ? MK_TESTS has been yes by default for some time. This isn=92t unexpected=85= I did however fix a faux pas I accidentally introduced in r273803 in = r273810, which may have resulted in more files being installed under = /usr/tests . > the timestamps are more or less when i tried to upgrade world. >=20 > i'm reverting back to 273863 to see if i get a system functionnal. Cheers! -Garrett --Apple-Mail=_EE9447E2-C8AD-47C0-8ADA-426AEB7E96ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUVBr1AAoJEMZr5QU6S73eo9AIAKzNamG2CzQpJ5/J7IBm3Lqy lqyzXA/tPLtObwP/hzCzojVx0bIPStmeVfkt5eKnvjQyYj4+jgH8tUvQAy6+JU0L Qx0M2keL8cd23Sv0jKBJEI7HcWrKo3tDe2yrwDqe14LJzrgoJr6IXzKeZ2M0b02z ubHvqBmN+w8OYIDDWHe5T9v2nCLM0QVsFcnZVExLIFn483RVZ1ZtlgecBNL7j3v5 NeXvLOnstGOEVedTp15bQkEBllIepkmpHhD+h/ziqVBt+V1yS9fjBY+3XgGvdlIA bZ1pSi37JD221is0TgX7Ulq6J4vOIT8VdRK/dkROzXILYenoJeODXyAo1E0A8uE= =fd+C -----END PGP SIGNATURE----- --Apple-Mail=_EE9447E2-C8AD-47C0-8ADA-426AEB7E96ED-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 23:41:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDCCFC51 for ; Fri, 31 Oct 2014 23:41:03 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id 4A10961F for ; Fri, 31 Oct 2014 23:41:02 +0000 (UTC) Received: from pcgyver.mooo.com ([92.145.139.71]) by mwinf5d10 with ME id 9zgu1p00B1Yd4kC03zgujM; Sat, 01 Nov 2014 00:40:55 +0100 X-ME-Helo: pcgyver.mooo.com X-ME-Auth: bWFydGluLm1hdG9Ab3JhbmdlLmZy X-ME-Date: Sat, 01 Nov 2014 00:40:55 +0100 X-ME-IP: 92.145.139.71 Received: from [192.168.0.3] (lincoln.humanidyne.net [192.168.0.3]) by pcgyver.mooo.com (8.14.9/8.14.9) with ESMTP id s9VNer1A001095; Sat, 1 Nov 2014 00:40:54 +0100 (CET) (envelope-from martin.mato@orange.fr) Message-ID: <54541DA9.8080902@orange.fr> Date: Sat, 01 Nov 2014 00:39:21 +0100 From: Martin MATO Reply-To: martin.mato@orange.fr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , freebsd-current@freebsd.org Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <54540442.4070204@orange.fr> <54540EB4.80207@orange.fr> In-Reply-To: <54540EB4.80207@orange.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.18-1 Precedence: 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, 31 Oct 2014 23:41:04 -0000 Le 31/10/2014 23:35, Martin MATO a écrit : > Le 31/10/2014 22:50, Martin MATO a écrit : >> Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : >>> Can you all please tell me which revision(s) you were running before >>> you >>> upgraded? Something like "bzgrep 11.0-CURRENT /var/log/messages*" >>> should do the trick. >>> >>> DES >> Absolutely >> here it is >> >> /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 >> r273863: Thu Oct 30 16:55:16 CET 2014 >> >> ps: there is no filesystem corruption (first thing i checked twice.) >> >> _______________________________________________ >> 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" > the is one thing i noticed: > there is a new directory under /usr called "tests" containing several > directories and files > maybe something goes wrong in the 'make installworld' part ? > > the timestamps are more or less when i tried to upgrade world. > > i'm reverting back to 273863 to see if i get a system functionnal. > > find /usr/tests/ > /usr/tests/ > /usr/tests/bin > /usr/tests/bin/chown > ... snip... > > > _______________________________________________ > 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" Reverted back userland AND kernel to r273863 and all things working as before for me. otherwise keeping the last revision kernel and reverting back the operating system to r273863 results in crashes, coredumps and filesystem corruption. From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 00:00:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3DBDEE1 for ; Sat, 1 Nov 2014 00:00:18 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 82E9993B for ; Sat, 1 Nov 2014 00:00:18 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 1D53CA220; Sat, 1 Nov 2014 00:00:17 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 12A3D109EC; Sat, 1 Nov 2014 01:00:18 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "O. Hartmann" Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <20141101001706.43ac0d8b.ohartman@zedat.fu-berlin.de> Date: Sat, 01 Nov 2014 01:00:18 +0100 In-Reply-To: <20141101001706.43ac0d8b.ohartman@zedat.fu-berlin.de> (O. Hartmann's message of "Sat, 1 Nov 2014 00:17:06 +0100") Message-ID: <86k33f94dp.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 00:00:18 -0000 "O. Hartmann" writes: > r273800 was the last (obviously) working on one box, r273872 seems to > have the problem: Are you sure? If I understand Manfred correctly, r273905 was running fine for him. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 00:33:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1030A372 for ; Sat, 1 Nov 2014 00:33:10 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C30B3BC5 for ; Sat, 1 Nov 2014 00:33:09 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 61443A253; Sat, 1 Nov 2014 00:33:08 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id E0CC8109F4; Sat, 1 Nov 2014 01:33:09 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Manfred Antar Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> Date: Sat, 01 Nov 2014 01:33:09 +0100 In-Reply-To: <201410312231.s9VMVsT1002148@pozo.com> (Manfred Antar's message of "Fri, 31 Oct 2014 15:31:54 -0700") Message-ID: <86fve392uy.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Andreas Tobler , Oliver Hartmann , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 00:33:10 -0000 Manfred Antar writes: > Then for some reason /var started to being mounted mfs. > so for me i think it has something to do with the new rc.d startup files. > If I have varmfs=3D"NO" and cleanvar_enable=3D"NO" everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all "early" file systems, /var is not writeable. > Writing entropy file:random: unblocking device. > > takes a little longer=20 > I changed to entropy_save_sz=3D"4096" in /etc/rc.conf, maybe thats why. That shouldn't make any difference. Our /dev/random never blocks once it's seeded, and reading 4096 bytes won't take noticeably longer than reading 2048 bytes. But it should already be unblocked by then - this is on shutdown, right? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 01:52:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5174A47A; Sat, 1 Nov 2014 01:52:46 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FB9B6DF; Sat, 1 Nov 2014 01:52:45 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id l4so263020lbv.12 for ; Fri, 31 Oct 2014 18:52:43 -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:message-id:subject :from:to:cc:content-type; bh=aQgDdmtEe6ezxZEHdTgu7Y4ufI0aiNrDJ9P6jGhcYRo=; b=HGuRb9jjQf4uuBhAko9rxh1AQUOR0QFpHuWoN2abTCEeLnmw+Dm/J+laKvjmT9Cm22 +3GgYGMRRcJDdQrPHsdkFAjyNI7Bu1ELCg7CyZCr6hreXsFdZ5euQIv5sLi0ZQu5jNlO IJbuwzQdTU/g+7SoAiRiZPE3O68jobVVxJb8Y4WNWOmxkgl3HHE9kC1cE2HT3QaJ7yBE nh+pmsj5CwkXiYISEZO40fMhMW+JYS2iy2XdPCAVmsqQAfzPPmn1ZjxXK2gBc5m5Axo+ pDO+lyM7NqqdObjjAckOUk5y8wSjv5yN+CtFWYlNeh2Qx2ttIi8/+WcvfB/cZ80g6w9i 627w== MIME-Version: 1.0 X-Received: by 10.112.170.99 with SMTP id al3mr29186670lbc.17.1414806763334; Fri, 31 Oct 2014 18:52:43 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Fri, 31 Oct 2014 18:52:43 -0700 (PDT) In-Reply-To: <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> Date: Fri, 31 Oct 2014 18:52:43 -0700 X-Google-Sender-Auth: MZWZwhM-tt8RGulFfCbkrFYVFJU Message-ID: Subject: Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161 From: Craig Rodrigues To: "jenkins-admin@freebsd.org" , Mateusz Guzik Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 01:52:46 -0000 On Fri, Oct 31, 2014 at 10:04 AM, wrote: > See > > Mateusz, Can you take a look at: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ The last successful pass was GRN r273871. I'm not sure, but you made a bunch of commits under /usr/src/sys/kern at about the time when things started failing. Thanks. -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 02:01:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DED57623; Sat, 1 Nov 2014 02:01:02 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1392A781; Sat, 1 Nov 2014 02:01:01 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so2605143wid.10 for ; Fri, 31 Oct 2014 19:01:00 -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=ThlxHthRMIOKfNXQOxeFMdQbqw0uDJnoB4NiRQkRaro=; b=jXVCntvuu2Iejfof/G7ODfmcwGRo09XM/BwjwfEANNpDC96Vc2c2mAceyb8dDyaBJ0 IPbAs67fb8zBnQnF1vQXIQU/Zc5sqERdtYRFPTpTbtU6LLU6UkGvhlqef25ZMWG0RlK5 f2CriGBoA9MvXjpDjIsSoF8MwlLSq1bNWNsZCC8+T3Ur8Ddhf2pN+H25iNkmrLVP1II/ pB/P8cbiqf0TZCspiVuJkxEINKMMRRLds//+a2ITJXzhnvJLlTCgL5LIb7VAoPEHrhLM YwHig1Lri38c6+Sdm/CHsx6ElrypE8l3Y9OAJK578vanOS+ruiZ864gt9CPAgnpWa0Mp QLrA== X-Received: by 10.180.99.163 with SMTP id er3mr999966wib.18.1414807260336; Fri, 31 Oct 2014 19:01:00 -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 m6sm492395wiy.16.2014.10.31.19.00.58 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 31 Oct 2014 19:00:59 -0700 (PDT) Date: Sat, 1 Nov 2014 03:00:57 +0100 From: Mateusz Guzik To: Craig Rodrigues Subject: Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161 Message-ID: <20141101020056.GA2229@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Craig Rodrigues , "jenkins-admin@freebsd.org" , freebsd-current Current References: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Current , "jenkins-admin@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 02:01:03 -0000 On Fri, Oct 31, 2014 at 06:52:43PM -0700, Craig Rodrigues wrote: > On Fri, Oct 31, 2014 at 10:04 AM, wrote: > > > See > > > > > Mateusz, > > Can you take a look at: > https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ > > The last successful pass was GRN r273871. I'm not sure, but you made a > bunch of commits > under /usr/src/sys/kern at about the time when things started failing. > There was a regression after commits related to new random code which resulted in /dev/md0 being created and mounted to /var. Looks like the test in question assumes it always gets /dev/md0. The test works for me not what the regression is fixed. I guess jenkins didn't catch up to it yet. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 02:13:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64E447B6; Sat, 1 Nov 2014 02:13:31 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27BBF8EB; Sat, 1 Nov 2014 02:13:31 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y10so8305175pdj.28 for ; Fri, 31 Oct 2014 19:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=eKhqBDV2dA5bKZKx/qTdxi95cek40EvV1E7KX1RelAg=; b=MqfrBQImhtCUZ15ImI13Cv7V/TtrhLnvXMMzMXX1+QqSLg3nAXFQ7mxEKYJoEffmsY /+O3aF9P2nJYKAJEpVmeiNlQbClWZSaFetGaMuRqAsIffHL8i6TU2qQ191O7iYmFPmr2 2MYX/LLWSIV1dueWgddlfn+VX6o64b40JkuDvDu9bVsghJwiTeoExkCZdM873skX2bPf ocC21ss3b9bMDS1Q6gU/txb6kKAlgHH0yP36KsmCHQS+VxLan2kD0g1EAdP7HCZHuF5b irCHjRTdCjLBBl6PYOWm4wRoFDZwMp+nHtgZtv+bYcTo1VYOq2jJ30zdHRsyVArWfBdZ Kyig== X-Received: by 10.67.30.72 with SMTP id kc8mr28689770pad.13.1414808010749; Fri, 31 Oct 2014 19:13:30 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:34d4:4abd:64bb:590a? ([2601:8:ab80:7d6:34d4:4abd:64bb:590a]) by mx.google.com with ESMTPSA id zf5sm11048667pbc.44.2014.10.31.19.13.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 19:13:30 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_895CF8A8-7A1D-47A0-AED6-1C82295C4A3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161 From: Garrett Cooper In-Reply-To: <20141101020056.GA2229@dft-labs.eu> Date: Fri, 31 Oct 2014 19:13:29 -0700 Message-Id: References: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> <20141101020056.GA2229@dft-labs.eu> To: Mateusz Guzik X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , freebsd-current Current , "jenkins-admin@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 02:13:31 -0000 --Apple-Mail=_895CF8A8-7A1D-47A0-AED6-1C82295C4A3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 31, 2014, at 19:00, Mateusz Guzik wrote: > On Fri, Oct 31, 2014 at 06:52:43PM -0700, Craig Rodrigues wrote: >> On Fri, Oct 31, 2014 at 10:04 AM, wrote: >>=20 >>> See = >>>=20 >>>=20 >> Mateusz, >>=20 >> Can you take a look at: >> https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ >>=20 >> The last successful pass was GRN r273871. I'm not sure, but you made = a >> bunch of commits >> under /usr/src/sys/kern at about the time when things started = failing. >>=20 >=20 > There was a regression after commits related to new random code which > resulted in /dev/md0 being created and mounted to /var. >=20 > Looks like the test in question assumes it always gets /dev/md0. >=20 > The test works for me not what the regression is fixed. I guess = jenkins > didn't catch up to it yet. Correct. sbin/mdconfig/tests/legacy_test.sh always assumes /dev/md0 is = available, which is wrong in a lot of cases and fixed by my enhancement. --Apple-Mail=_895CF8A8-7A1D-47A0-AED6-1C82295C4A3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUVEHJAAoJEMZr5QU6S73ePU8H/iUra/J2Lchij1JLFmR6RhkI aTVLo1FYr/9KExmjJyUIR6c0j+5HKscXVIMfo0dxzOsfDzMpkw1kS5aSy+V3pDsu apvbuInYYaFDdt3P36QJrNwkEogvGS1XOHNPGQuDPguYRKaafUdg2sNdy7oz/Asl 0Mjer/XU0nSOFz1ccHF3ZEQ+xNJHJZtTP6AhHABOFpgHaP/4Y5OYivodG818l3B+ kkc17esoLR2Ht0ON1xTQn/pfCfVbcV7FzGF3GDKy0W3AvjO3ecDpNIIMUOAzoxSD g78WOB/7e9HuRFcwW1O/IJCQnkMOS5D1iH1WvOZLpwtBSHfWEcGHiqrS9KnNO0Y= =LXG5 -----END PGP SIGNATURE----- --Apple-Mail=_895CF8A8-7A1D-47A0-AED6-1C82295C4A3F-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 02:42:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A990A90 for ; Sat, 1 Nov 2014 02:42:08 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 096A7B18 for ; Sat, 1 Nov 2014 02:42:08 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1AD98603 for ; Sat, 1 Nov 2014 02:42:08 +0000 (UTC) Date: Sat, 1 Nov 2014 02:42:08 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1652401401.23.1414809728043.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1535194959.22.1414797591824.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1535194959.22.1414797591824.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #164 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 02:42:08 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 04:11:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A20A84D5; Sat, 1 Nov 2014 04:11:56 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE263352; Sat, 1 Nov 2014 04:11:55 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id gd6so5895144lab.20 for ; Fri, 31 Oct 2014 21:11:52 -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:message-id:subject :from:to:content-type; bh=Xird0tLYYspERVAPFwFzpEyWcMdv+s2/tt5CdktlHzc=; b=gjrYl+s8O3zj0i9E1idQSqunqhS8bM06dbJu4+tNhoJMWFSZhYhK6sDoe0oQQ7vmjp /9SVxsyLGUkioOKvGRm9nY6P5pu26zugeihALK4TMQj2qlxWRv2RnEgvKQMjAgKhemfA 1TD/oUNdDc2UX00tjt+G2E47txYFXgliywl9S8zqwv/FBH7D0WBPV4j5dUEGoB6wYRHx T+epxdCKD7Qw2pN3KmedOdsBIWJbYPOorhcVrev4R5gv8ryuLQkB9AxYmH4uOVMdSt6n xgk1QSm1F8wlAOkh6AiZe+eGuqBCIyKS3ZaAxsxccVHnc78vFrfjS97UJM29NybAV7/Q jATg== MIME-Version: 1.0 X-Received: by 10.112.57.227 with SMTP id l3mr30728593lbq.68.1414815112644; Fri, 31 Oct 2014 21:11:52 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Fri, 31 Oct 2014 21:11:52 -0700 (PDT) Received: by 10.112.84.197 with HTTP; Fri, 31 Oct 2014 21:11:52 -0700 (PDT) In-Reply-To: <20141101020056.GA2229@dft-labs.eu> References: <2136673332.19.1414765732565.JavaMail.jenkins@jenkins-9.freebsd.org> <924594177.20.1414775069872.JavaMail.jenkins@jenkins-9.freebsd.org> <20141101020056.GA2229@dft-labs.eu> Date: Fri, 31 Oct 2014 21:11:52 -0700 X-Google-Sender-Auth: KrRGdxVxQOAY9blR2fAl6geTRGU Message-ID: Subject: Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161 From: Craig Rodrigues To: freebsd-current Current , jenkins-admin@freebsd.org, Mateusz Guzik Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 04:11:56 -0000 On Oct 31, 2014 7:01 PM, "Mateusz Guzik" wrote: > > There was a regression after commits related to new random code which > resulted in /dev/md0 being created and mounted to /var. > > Looks like the test in question assumes it always gets /dev/md0. > > The test works for me not what the regression is fixed. I guess jenkins > didn't catch up to it yet. Thanks for the analysis. Looks like things are OK as of https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/164/ . -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 06:36:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 581B3A99 for ; Sat, 1 Nov 2014 06:36:05 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6CF7C33 for ; Sat, 1 Nov 2014 06:36:04 +0000 (UTC) Received: from fortune.joker.local (180-198-225-68.nagoya1.commufa.jp [180.198.225.68]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.3/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id sA16Zu54046685 for ; Sat, 1 Nov 2014 15:35:56 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 1 Nov 2014 15:35:54 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! Message-Id: <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> In-Reply-To: <86fve392uy.fsf@nine.des.no> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> Organization: Junchoon corps X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 06:36:05 -0000 On Sat, 01 Nov 2014 01:33:09 +0100 Dag-Erling Sm$B".(Brgrav wrote: > Manfred Antar writes: > > Then for some reason /var started to being mounted mfs. > > so for me i think it has something to do with the new rc.d startup files. > > If I have varmfs="NO" and cleanvar_enable="NO" everything works fine. > > Not really. The default for varmfs is AUTO, which mounts a memory file > system on /var if, after mounting all "early" file systems, /var is not > writeable. For me, Manfred's workaround actually helped. VirtualBox VM [head, r273922, amd64] on stable/10 host [r273847, amd64]. In my case, /var is NOT a mount point (root only partition, mounted rw), but empty mfsvar is forcibly used without Manfred's workaround in multi user mode. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) > > Writing entropy file:random: unblocking device. > > > > takes a little longer > > I changed to entropy_save_sz="4096" in /etc/rc.conf, maybe thats why. > > That shouldn't make any difference. Our /dev/random never blocks once > it's seeded, and reading 4096 bytes won't take noticeably longer than > reading 2048 bytes. But it should already be unblocked by then - this > is on shutdown, right? For me, it takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. > > DES > -- > Dag-Erling Sm$B".(Brgrav - des@des.no > _______________________________________________ > 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" -- $B@DLZ(B $BCNL@(B [Tomoaki AOKI] junchoon@dec.sakura.ne.jp MXE02273@nifty.com From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 10:39:04 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A82F3712 for ; Sat, 1 Nov 2014 10:39:04 +0000 (UTC) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57D69688 for ; Sat, 1 Nov 2014 10:39:03 +0000 (UTC) Received: from [66.196.81.172] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2014 10:38:57 -0000 Received: from [98.139.212.249] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2014 10:38:57 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 01 Nov 2014 10:38:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 416569.7705.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 14421 invoked by uid 60001); 1 Nov 2014 10:32:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1414837936; bh=P+0ZkG9fbxt3a8cLDCtqmWTzWB6Q5xJ6dJ8cHHu0FnE=; h=Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=fkdi81wZQAi09hAjCzEMD1t5lW1AIL16nP81Hy5HjZlmsX/IBujm70G/7oSenoYmib429fhJNedaLhBCfu/K4kJ7mDYsPRpljJUa0OX52837nfSxc0v2vWnonFwQBDNeH2nTHBfvl1mOE6NrusEffXfq8Z0+T/4seo1MjSX+R+M= X-YMail-OSG: dwxqg5cVM1ls5ac.TQnuWOyfhDi.vbkC7qfOpSgk4OhUGZK rl.hfa5fHvQAn63OZmHkaO8EsyKx48FWxWdvw7l0swYnLfV7GwTJaWCPl7jm Qb48V0xl_MADE_aK7USsusk_wylyLn.WUmlx3aEVAzXj0L0t8BDTNrSk2IE6 iRHC9gYde83r6QOuu7MhdC_3C9vK1tmN.EDooxM2LDtjCR9I0fZgEsktp9Bc hBACGFzK8bDDEN_rHZDFl3WMhoAIm2pvFhD2.b71LY.OkDPlE6hx9NvjXMwz rDDC4dFf._EyZfvwRv8R4Q8xRlekR1Mlq09re8oMpGjIMms88cr1yPN8e8r_ fF1Yl6UJx_5BjKdYIdA2AsWK4pHGSSmvisYBEvx00JzHoa6dGTIHFeksQOqn KmelK_VzlexFDPZzrBCLzJFEQC3Sjd9APWc7uo7e8Ph9tjvRFknCpSZcv.MO oiaVQmdj3KKuO7b_Pk7Tjqii3yd04FLiwMNQG9iZr0T68JKJxb35BkhAd6X2 Bd5.c763J7fOLjkkIxi.U39WTMMW.efp_K3JwAOgdRkqycNn0_cQdNiXXDTV lTz5avJfUuWYZ86CZteknqBTlw6W3tXwk5.LT6oph5P9bjePg.H4EwPy4CvF t.icueeqnn4ofeELoHpnGNnJe.gmg_bCXmyZsBHWPFRNNsw-- Received: from [66.92.43.99] by web140901.mail.bf1.yahoo.com via HTTP; Sat, 01 Nov 2014 03:32:16 PDT X-Rocket-MIMEInfo: 002.001, Tm90IGluaXRpYWxseSB3ZWxjb21pbmcgdGhpcyBuZXcgZWZmb3J0Li4uIA0KZXhwbGFuYXRpb24gYW5kIG90aGVyIFBLRyBwcm9ibGVtcyB0YWtpbmcgcHJlY2VkZW5jZS4uLg0KDQoNCkkndmUgYSBmZXcgc2NyaXB0cyB3aGljaCB1c2UgdGhlIHNtYWxsZXIgZmlsZXMsIGFuZCBoYXZlIHVzZWQgdGhlbQ0KZXh0ZW5zaXZlbHkgaW4gcGlwZXMuICBTeW50YXggd2l0aGluIHRoZSBNYWtlZmlsZSB3b3VsZCBtYWtlIHRob3NlDQpjb3VudGVyaW50dWl0aXZlLiAgICAgICAgSSB3b3VsZCB3b25kZXIgYWxzbyBpZiABMAEBAQE- X-Mailer: YahooMailClassic/810 YahooMailWebService/0.8.203.733 Message-ID: <1414837936.42754.YahooMailBasic@web140901.mail.bf1.yahoo.com> Date: Sat, 1 Nov 2014 03:32:16 -0700 From: Jeffrey Bouquet Subject: RE: RE: reducing the size of the ports tree To: ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 01 Nov 2014 10:59:35 +0000 Cc: pkg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 10:39:04 -0000 Not initially welcoming this new effort... explanation and other PKG problems taking precedence... I've a few scripts which use the smaller files, and have used them extensively in pipes. Syntax within the Makefile would make those counterintuitive. I would wonder also if it would break port infrastructure like the Mk and Tools and "make search" and portsearch (etc -- ports ) ... essentially breaking more things than would be solved. Indeed, I've many ideas for MORE small files for people crafting shell scripts that would be of more use down the road, and incorporated someday into additional port tools, portmasters, portupgrades, etc... So as far as this particular suggestion, maybe if someone wants it bad enough one should build a prototype and test locally several years with many ports and upgrades to determine what it breaks... and how to write new tools. But I conjecture that effort would be better spent with PR backlogs, fixing pkg2ng (which fails here on one machine ) etc... and making pkg more robust... (complete recovery if the database is hosed, with a something local_sqlite_hosed_reuild_sh.sh etc etc And the documentation. Many many more examples of everyday usage over the course of a year and UPDATING scenarious would be appreciated... and also streamlining pkg so it works better on low power machines with many ports installed. Including less segfaults... As an aside, I am now on a machine which never had the problem before, after a failed pkg2ng conversion, A... pkg install -f nettle wants to install csound! what file is telling it that? The database ??? ... and seven others I had just deinstalled B... make install ( proceeds with "Child process terminated abnomally... segmentation fault) before the install. Not known if anything was running beforehand. Not problems with the install. But it keeps occuring... What process? Something in the background wanting that nettle >> csound dependency? Pkg working before the make command? Part of the make command infrastructure now more buggy? Thankfully that machine is not the primary one here, and all the programs installed still work on it as far as I know. But its registration data is not exact and pkg-devel as installed on it could be debugged more... as well as pkg2ng retested to work on v9 more precisely... It failed three times to convert that machine. (not installed unless desinstalling direct from the port, so could not upgrade.. or pkg info the port) From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 13:45:46 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27ABF839; Sat, 1 Nov 2014 13:45:46 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E107C92B; Sat, 1 Nov 2014 13:45:45 +0000 (UTC) Received: from labrat.home.serebryakov.spb.ru (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 85BCA56403; Sat, 1 Nov 2014 16:45:38 +0300 (MSK) Message-ID: <5454E400.5010906@FreeBSD.org> Date: Sat, 01 Nov 2014 16:45:36 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Baptiste Daroussin , ports@FreeBSD.org, current@FreeBSD.org Subject: Re: pkg 1.4 freeze please test test test! References: <20141028231933.GG26796@ivaldir.etoilebsd.net> In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 13:45:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29/10/2014 02:19, Baptiste Daroussin wrote: > We are starting the release process of pkg 1.4, we want to have a > better release process than with every single previous version of > pkg. For that we will need you help! > > pkg-devel has been updated to the latest version of pkg as of > alpha2. I have 1.4.0.p.a16 installed and have two problems now: (1) Latest 11:amd64 package repository doesn't have newest package (2) this package thinks, that 1.4.0.p.a16 is newer than 1.4.0.a4: lev@labrat:~% pkg version -vIL= ... pkg-devel-1.4.0.p.a16 > succeeds index (index has 1.4.0.a4) ... lev@labrat:~% sudo pkg -4 upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (216 candidates): 37% pkg-devel~ports-mgmt/pkg-devel has no direct installation candidates, change it to pkg-devel~ports-mgmt/pkg-devel? [Y/n]: y Checking for upgrades (216 candidates): 100% Processing candidates (216 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. lev@labrat:~% - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUVOQAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP1EUQALM9Hs2X1F3Zoa94RwpHK4XI 0H8/VWB/NA9J//UGqW1btikXpbSDRSA2DsjL3wzfk0Z0SNQrExrUlwthkv3n/llh OPTthShVOijOGTuvE+voBuc0aGNDOfAodNaJKHncF/qai/6P3WqqGnxsuEGegZm4 JD0bM0OQfnoQz/xECWFOwJA6EFPgneAzCthpNkCFUbe0d7/hk9uDD3I6rmJPzT4T pMRizelSZxNyMc0kVJZjfa/Zlj6h818R6puzbb3ErX0SyijyzyOKI1pAZ5mmSgl4 vPbMWELHQWVRRQS1KcvGfNJMgpYB0UG93flZ+E9M3h/ScBqdZc+2OqYUEd+ZiE/T kPJ0oQw9t283banasA0k8Ej59478ZN1CxnmO766x96lqCTlbqbl3KFwgpNORCvas /WBjV0T8ZgSf1gCh5WnFQDF0rmpfql4Ol0ynY4A8ToKtJsAUpQ+vwR8WieHRKWf9 28fqmq/+ZewX5mS/7/eZ/DZdlqgKSmWv7JbETVYR3IAkF1a3s38DrU1ZZ5TnUrPM xWqvFC8hfW7aiMtzQ8OWW8WIFMC02/0oyxEqnFsVh/+IIsvXtTQOmPFd+tNlU3Xq FjkqFJRmVBqLS2eXtNvF5WzOJrEJmAOkkYVzGAlpYQVAVie+UZHKu3D1A8B8+EPO 3PfdV96CUGhS56H9Z8R3 =v9Qt -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 14:21:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70B8E143 for ; Sat, 1 Nov 2014 14:21:56 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2F62AC89 for ; Sat, 1 Nov 2014 14:21:55 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id DEBC6ADBF; Sat, 1 Nov 2014 14:21:46 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2B12110A69; Sat, 1 Nov 2014 15:21:48 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tomoaki AOKI Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> Date: Sat, 01 Nov 2014 15:21:48 +0100 In-Reply-To: <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> (Tomoaki AOKI's message of "Sat, 1 Nov 2014 15:35:54 +0900") Message-ID: <86y4rv6lxf.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 14:21:56 -0000 Tomoaki AOKI writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Manfred Antar writes: > > > Then for some reason /var started to being mounted mfs. [...] If > > > I have varmfs=3D"NO" and cleanvar_enable=3D"NO" everything works fine. > > Not really. The default for varmfs is AUTO, which mounts a memory > > file system on /var if, after mounting all "early" file systems, > > /var is not writeable. > For me, Manfred's workaround actually helped. It helped that particular issue, more or less by accident. It was not in any way a correct fix or even a correct workaround. > In single user mode, actual /var (in root partition) appears as > before. So there can be some mis-ordering within rc scripts. > (Remounting of / is delayed? Check for /var too early?) Exactly right; the check for a writeable /var occurred before / was mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. > For me, [unblocking /dev/random] takes nearly 2 minutes each boot > after r273872. No specific rc.conf setting for it. That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 14:34:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE01B2D5 for ; Sat, 1 Nov 2014 14:34:02 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C2E2D55 for ; Sat, 1 Nov 2014 14:34:01 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XkZkX-0008Mb-O5; Sat, 01 Nov 2014 14:33:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA1EXqC4087551; Sat, 1 Nov 2014 08:33:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+1op1nQ76Repk5BBo0yhKa X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86y4rv6lxf.fsf@nine.des.no> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 01 Nov 2014 08:33:51 -0600 Message-ID: <1414852431.17308.210.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA1EXqC4087551 Cc: Tomoaki AOKI , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 14:34:02 -0000 On Sat, 2014-11-01 at 15:21 +0100, Dag-Erling Sm=F8rgrav wrote: > Tomoaki AOKI writes: > > Dag-Erling Sm=F8rgrav writes: > > > Manfred Antar writes: > > > > Then for some reason /var started to being mounted mfs. [...] I= f > > > > I have varmfs=3D"NO" and cleanvar_enable=3D"NO" everything works = fine. > > > Not really. The default for varmfs is AUTO, which mounts a memory > > > file system on /var if, after mounting all "early" file systems, > > > /var is not writeable. > > For me, Manfred's workaround actually helped. >=20 > It helped that particular issue, more or less by accident. It was not > in any way a correct fix or even a correct workaround. >=20 > > In single user mode, actual /var (in root partition) appears as > > before. So there can be some mis-ordering within rc scripts. > > (Remounting of / is delayed? Check for /var too early?) >=20 > Exactly right; the check for a writeable /var occurred before / was > mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. >=20 > > For me, [unblocking /dev/random] takes nearly 2 minutes each boot > > after r273872. No specific rc.conf setting for it. >=20 > That means we're not getting enough entropy during early boot, or we're > underestimating the amount of entropy we're getting. We added entropy > harvesting to device_attach() about a year ago, which in most cases > provides enough entropy to unblock /dev/random before we even run > init(8). >=20 > DES And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). -- Ian From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 14:59:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A267073C; Sat, 1 Nov 2014 14:59:31 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 60352EFA; Sat, 1 Nov 2014 14:59:30 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 576D4AE1B; Sat, 1 Nov 2014 14:59:30 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 9760A10A6F; Sat, 1 Nov 2014 15:59:32 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no> <1414852431.17308.210.camel@revolution.hippie.lan> Date: Sat, 01 Nov 2014 15:59:32 +0100 In-Reply-To: <1414852431.17308.210.camel@revolution.hippie.lan> (Ian Lepore's message of "Sat, 01 Nov 2014 08:33:51 -0600") Message-ID: <86tx2j6k6j.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Tomoaki AOKI , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 14:59:31 -0000 Ian Lepore writes: > Dag-Erling Sm=C3=B8rgrav writes: > > That means we're not getting enough entropy during early boot, or > > we're underestimating the amount of entropy we're getting. We added > > entropy harvesting to device_attach() about a year ago, which in > > most cases provides enough entropy to unblock /dev/random before we > > even run init(8). > And I vaguely remember being promised that things like that would > NEVER happen, even on systems with little or no entropy available > during early startup (which describes quite nicely the embedded > systems we build at work). I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. VMs have the additional problem of divergence between clones: if you clone a VM, all clones will start out with the exact same state and won't diverge until they've all reseeded after gathering entropy independently of eachother. I don't really know how to solve this. One possibility, assuming you have guest additions installed and that they can tell you that you've been suspended, is to block on resume. It won't help VMs that were cloned while shut down, but they should diverge to some extent during boot. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 15:13:44 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CA449D1 for ; Sat, 1 Nov 2014 15:13:44 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7FA8ED for ; Sat, 1 Nov 2014 15:13:43 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so3344318wid.4 for ; Sat, 01 Nov 2014 08:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:date:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=ITTc5gfKDHmGR+wjyPhZrg3VmZr6p5C6idrTzf0O1vs=; b=KWbluCiNAKnJUDR857x2zZiXwRxshE8+7/3sDAWXKePXYS6MoV+bv0szIGT8P9AV2P nctXS2WDtyXnY6XDtZNuj0PeCwxqMPdKkbYkWlqTF9Z7DJxzThr7FJfci3FQ3eiEogpt bREaCc+hFWELgt0coNzG8osCFb3o+i5NCtgWCsyxY/MF1fz/oMsFWWZVt3+y/qJiEsz8 zvApS8/8JIb+pkP9rGkbFIgWqdXFlo7lRhduQS3WITLN+dY2WE3gBohdI3Z+hR7T8kDH x+Lx1+/aUfrdNdsYPq/HpdBe3E7JYAQo/QgPMD3WEkMsWjkLA1f8YhXAFBkADWnlx8Oi NPmg== X-Received: by 10.180.100.129 with SMTP id ey1mr4618804wib.28.1414854822199; Sat, 01 Nov 2014 08:13:42 -0700 (PDT) Received: from ubm.strangled.net (ipb219cb25.dynamic.kabel-deutschland.de. [178.25.203.37]) by mx.google.com with ESMTPSA id bg10sm15605696wjc.47.2014.11.01.08.13.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 08:13:41 -0700 (PDT) From: Marc UBM X-Google-Original-From: Marc "UBM" Bocklet Date: Sat, 1 Nov 2014 16:13:32 +0100 To: current@FreeBSD.org Subject: Re: pkg 1.4 freeze please test test test! Message-Id: <20141101161332.b9c8fc19bf9fc54f73bc5c00@gmail.com> In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 15:13:44 -0000 On Wed, 29 Oct 2014 00:19:33 +0100 Baptiste Daroussin wrote: > Hi all, > > We are starting the release process of pkg 1.4, we want to have a better release > process than with every single previous version of pkg. For that we will need > you help! > > pkg-devel has been updated to the latest version of pkg as of alpha2. > > Changes you can expect in pkg 1.4 are the following: > - Loads of bug fixes > - Stricter checking of the path passed via the plist > - Removal of the bundled libyaml > - new --raw-format to chose the output format for info -R and search -R > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64) > the old ABI is available as a fallback in ALTABI > - pkg check now support a quiet mode > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging > configuration files > - new @config keyword to mark a file as a config file (during > upgrade/reinstallation it will try to merge the configuration with the one the > user may have modified) an option AUTOMERGE is available to prevent > automerging if automerge fails a .pkgnew file will be created along with the > untouched user version of the configuration > - The update procedure has been improved and speed up a lot (in particular for > machine with low resources) > - The unique identifier has been modified to be pkgname meaning now ports can be > moved in new categories without having to be considered a different package > - Only libraries starting by lib* are added to the provided libraries > - General speed up of all operations > > We need help in testing, but we also need help in writing regression tests ! > The more we have tests the more stable the releases will be. > > The release will also allow to be able to package base! > > regards, > Bapt The update is failing for me with: .../usr/ports/ports-mgmt/pkg-devel# make all install clean ===> Installing for pkg-1.4.0.a3 ===> Checking if pkg already installed pkg-static: sqlite error while executing DROP INDEX packages_unique;CREATE UNIQUE INDEX packages_unique ON packages(name); in file pkgdb.c:2246: UNIQUE constraint failed: packages.name *** Error code 74 Stop. make[1]: stopped in /usr/ports/ports-mgmt/pkg-devel *** Error code 1 Stop. make: stopped in /usr/ports/ports-mgmt/pkg-devel portmaster fails with: root@ubm:/usr/ports/ports-mgmt/pkg-devel# portmaster -d pkg ===>>> No ORIGIN in /var/db/pkg/pkgconf-0.9.7/+CONTENTS ===>>> Cannot continue ===>>> Aborting update ===>>> Killing background jobs Terminated ===>>> Exiting make.conf related options: #enable pkgng (might be superfluous) WITH_PKGNG=yes #enable PKGNG devel WITH_PKGNG=devel Am I doing something wrong? Bye Marc -- Marc "UBM" Bocklet From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 16:10:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64655488 for ; Sat, 1 Nov 2014 16:10:07 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3199E791 for ; Sat, 1 Nov 2014 16:10:06 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XkbFd-0008yJ-4a; Sat, 01 Nov 2014 16:10:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA1GA237087666; Sat, 1 Nov 2014 10:10:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+pN9E1kavdbFbUBxvxQV0W X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86tx2j6k6j.fsf@nine.des.no> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no> <1414852431.17308.210.camel@revolution.hippie.lan> <86tx2j6k6j.fsf@nine.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 01 Nov 2014 10:10:02 -0600 Message-ID: <1414858202.17308.214.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA1GA237087666 Cc: Tomoaki AOKI , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 16:10:07 -0000 On Sat, 2014-11-01 at 15:59 +0100, Dag-Erling Sm=F8rgrav wrote: > Ian Lepore writes: > > Dag-Erling Sm=F8rgrav writes: > > > That means we're not getting enough entropy during early boot, or > > > we're underestimating the amount of entropy we're getting. We adde= d > > > entropy harvesting to device_attach() about a year ago, which in > > > most cases provides enough entropy to unblock /dev/random before we > > > even run init(8). > > And I vaguely remember being promised that things like that would > > NEVER happen, even on systems with little or no entropy available > > during early startup (which describes quite nicely the embedded > > systems we build at work). >=20 > I think you misremember. It is impossible to guarantee that the system > will always have enough entropy right from the start. Servers, desktop= s > and laptops will be fine, but embedded systems and VMs might not be abl= e > to unblock until they've seen some network traffic or loaded a chunk of > pre-generated entropy (which is what /etc/rc.d/random does). This is > especially true for embedded systems that don't have enumerable buses > and rely on fdt(4) to create the device tree at boot time. >=20 And what about devices that are not connected to a network? We've been over this, I stressed again and again that we have an absolute requirement to start up reliably when there is NO ENTROPY. Saved entropy is great, if you've got some saved. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. -- Ian > VMs have the additional problem of divergence between clones: if you > clone a VM, all clones will start out with the exact same state and > won't diverge until they've all reseeded after gathering entropy > independently of eachother. I don't really know how to solve this. On= e > possibility, assuming you have guest additions installed and that they > can tell you that you've been suspended, is to block on resume. It > won't help VMs that were cloned while shut down, but they should diverg= e > to some extent during boot. >=20 > DES From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 17:03:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EF6EE33; Sat, 1 Nov 2014 17:03:03 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CF740C7D; Sat, 1 Nov 2014 17:03:02 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5F87FAFAB; Sat, 1 Nov 2014 17:03:01 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id A971C10A82; Sat, 1 Nov 2014 18:03:03 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no> <1414852431.17308.210.camel@revolution.hippie.lan> <86tx2j6k6j.fsf@nine.des.no> <1414858202.17308.214.camel@revolution.hippie.lan> Date: Sat, 01 Nov 2014 18:03:03 +0100 In-Reply-To: <1414858202.17308.214.camel@revolution.hippie.lan> (Ian Lepore's message of "Sat, 01 Nov 2014 10:10:02 -0600") Message-ID: <86h9yi7t14.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Tomoaki AOKI , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 17:03:03 -0000 Ian Lepore writes: > Dag-Erling Sm=C3=B8rgrav writes: > > I think you misremember. It is impossible to guarantee that the > > system will always have enough entropy right from the start. > > Servers, desktops and laptops will be fine, but embedded systems and > > VMs might not be able to unblock until they've seen some network > > traffic or loaded a chunk of pre-generated entropy (which is what > > /etc/rc.d/random does). This is especially true for embedded > > systems that don't have enumerable buses and rely on fdt(4) to > > create the device tree at boot time. > And what about devices that are not connected to a network? They still get entropy from interrupts and disk I/O. > Oh well, I'm sure I'll be able to find some hacks to undo whatever > y'all have done now, and we'll just have to carry them as local diffs > forever. How about you take a ****ing chill pill and read what I wrote earlier: this is a regression which we will try to fix. But the bottom line is that the entropy has to come from *somewhere* and if whatever dinky device you're playing with doesn't provide any, that's not our fault. Buy http://www.amazon.com/dp/0833030477 and type it in, or something. We're engineers, not magicians. (or maybe you can do something constructive, like write code to harvest entropy from background noise in ADCs, unused WiFi / 4G / BT radios or whatever else is available and submit a patch) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 18:26:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C7E2610 for ; Sat, 1 Nov 2014 18:26:58 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2154863D for ; Sat, 1 Nov 2014 18:26:57 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id sA1IQod5004443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 1 Nov 2014 19:26:50 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id sA1IQoO4004440 for ; Sat, 1 Nov 2014 19:26:50 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sat, 1 Nov 2014 19:26:50 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! In-Reply-To: <86h9yi7t14.fsf@nine.des.no> Message-ID: References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no> <1414852431.17308.210.camel@revolution.hippie.lan> <86tx2j6k6j.fsf@nine.des.no> <1414858202.17308.214.camel@revolution.hippie.lan> <86h9yi7t14.fsf@nine.des.no> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 18:26:58 -0000 On Sat, 1 Nov 2014 18:03+0100, Dag-Erling Smørgrav wrote: > Ian Lepore writes: > > Dag-Erling Smørgrav writes: > > > I think you misremember. It is impossible to guarantee that the > > > system will always have enough entropy right from the start. > > > Servers, desktops and laptops will be fine, but embedded systems and > > > VMs might not be able to unblock until they've seen some network > > > traffic or loaded a chunk of pre-generated entropy (which is what > > > /etc/rc.d/random does). This is especially true for embedded > > > systems that don't have enumerable buses and rely on fdt(4) to > > > create the device tree at boot time. > > And what about devices that are not connected to a network? > > They still get entropy from interrupts and disk I/O. > > > Oh well, I'm sure I'll be able to find some hacks to undo whatever > > y'all have done now, and we'll just have to carry them as local diffs > > forever. > > How about you take a ****ing chill pill and read what I wrote earlier: > this is a regression which we will try to fix. But the bottom line is > that the entropy has to come from *somewhere* and if whatever dinky > device you're playing with doesn't provide any, that's not our fault. > Buy http://www.amazon.com/dp/0833030477 and type it in, or something. > We're engineers, not magicians. Sirs, please control your temper, at least while on a public mailing list. What good does the file /entropy do if boot up is delayed everytime during "Writing entropy file:"? > (or maybe you can do something constructive, like write code to harvest > entropy from background noise in ADCs, unused WiFi / 4G / BT radios or > whatever else is available and submit a patch) -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 18:35:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE85184B for ; Sat, 1 Nov 2014 18:35:17 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8C9174E for ; Sat, 1 Nov 2014 18:35:17 +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.9/8.14.9) with ESMTP id sA1IZFb9006581; Sat, 1 Nov 2014 14:35:15 -0400 (EDT) (envelope-from lidl@pix.net) Message-ID: <545527E2.1030109@pix.net> Date: Sat, 01 Nov 2014 14:35:14 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: pkg 1.4 freeze please test test test! References: <20141028231933.GG26796@ivaldir.etoilebsd.net> In-Reply-To: <20141028231933.GG26796@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 18:35:18 -0000 I upgraded one of my machines to have pkg-devel on it (1.4.0.alpha4), and attempted to recreate my test repo with it. Version : 1.4.0.alpha4 PKG_DBDIR = "/tmp/pkg.tmp.67648"; PKG_CACHEDIR = "/var/cache/pkg"; PORTSDIR = "/usr/ports"; INDEXDIR = ""; INDEXFILE = "INDEX-9"; HANDLE_RC_SCRIPTS = false; ASSUME_ALWAYS_YES = true; REPOS_DIR [ "/usr/local/etc/pkg/repos", ] PLIST_KEYWORDS_DIR = ""; SYSLOG = true; ABI = "FreeBSD:9:amd64"; ALTABI = "freebsd:9:x86:64"; DEVELOPER_MODE = false; VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.bz2"; FETCH_RETRY = 3; PKG_PLUGINS_DIR = "/usr/local/lib/pkg/"; PKG_ENABLE_PLUGINS = true; PLUGINS [ ] DEBUG_SCRIPTS = false; PLUGINS_CONF_DIR = "/usr/local/etc/pkg/"; PERMISSIVE = false; REPO_AUTOUPDATE = false; NAMESERVER = ""; EVENT_PIPE = ""; FETCH_TIMEOUT = 30; UNSET_TIMESTAMP = false; SSH_RESTRICT_DIR = ""; PKG_ENV { } PKG_SSH_ARGS = ""; DEBUG_LEVEL = 0; ALIAS { } CUDF_SOLVER = ""; SAT_SOLVER = ""; RUN_SCRIPTS = true; CASE_SENSITIVE_MATCH = false; LOCK_WAIT = 1; LOCK_RETRIES = 5; SQLITE_PROFILE = false; WORKERS_COUNT = 0; READ_LOCK = false; PLIST_ACCEPT_DIRECTORIES = false; IP_VERSION = 0; AUTOMERGE = true; Repositories: XXXXX: { url : "pkg+http://XXXXX/FreeBSD:9:amd64/latest", enabled : yes, mirror_type : "SRV" } Updating XXXXX repository catalogue... Fetching meta.txz... done Fetching packagesite.txz... done Processing entries... done XXXXX repository update completed. 506 packages processed pkg: sqlite error while executing INSERT INTO pkg_search SELECT id, name || '-' || version, origin FROM packages;CREATE INDEX packages_origin ON packages(origin COLLATE NOCASE);CREATE INDEX packages_name ON packages(name COLLATE NOCASE);CREATE INDEX packages_uid_nocase ON packages(name COLLATE NOCASE, origin COLLATE NOCASE);CREATE INDEX packages_version_nocase ON packages(name COLLATE NOCASE, version);CREATE INDEX packages_uid ON packages(name, origin);CREATE INDEX packages_version ON packages(name, version);CREATE UNIQUE INDEX packages_digest ON packages(manifestdigest); in file pkgdb.c:2246: UNIQUE constraint failed: packages.manifestdigest Creating repository in /usr/obj/usr/src/release/packages/FreeBSD:9:amd64... done Packing files for repository... done Creating repository in /usr/obj/usr/src/release/packages/FreeBSD:9:amd64... done Packing files for repository... done -Kurt From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 20:14:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C55DBF64 for ; Sat, 1 Nov 2014 20:14:30 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EF81FBB for ; Sat, 1 Nov 2014 20:14:30 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Xkf49-00086l-Rv for freebsd-current@freebsd.org; Sat, 01 Nov 2014 13:14:29 -0700 Date: Sat, 1 Nov 2014 13:14:29 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1414872869859-5961642.post@n5.nabble.com> Subject: version number error with ports 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.18-1 Precedence: 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, 01 Nov 2014 20:14:30 -0000 There seems to be a problem with certain ports detecting the OS version. * This happens with emulators/i386-wine-devel; it's unable to detect the version and exits. * Poudriere shows below message: make: "/usr/ports/Mk/bsd.port.mk" line 1216: warning: "/usr/bin/awk '/^#define[[:blank:]]__FreeBSD_version/ {print $3}' < /usr/include/sys/param.h" exited on a signal make: "/usr/ports/Mk/bsd.port.mk" line 1228: UNAME_r (11.0-CURRENT) and OSVERSION () do not agree on major version number. uname > FreeBSD 11.0-CURRENT #0 r272601M: Mon Oct 6 ... amd64 Will upgrade as soon as recent buildworld / clang error is fixed. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/version-number-error-with-ports-tp5961642.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 20:29:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20E2A825 for ; Sat, 1 Nov 2014 20:29:40 +0000 (UTC) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 935A4172 for ; Sat, 1 Nov 2014 20:29:38 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ge10so7670564lab.22 for ; Sat, 01 Nov 2014 13:29:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pndtcpF/t7mKC3Y+2grEjCglBiA0Paf01w2MT9+yH8E=; b=KHAg+CFKH2BxRVYS3m+al98KuqoCwTgiGTWuz2pJIAjlTRz760QA256IHue1/krQpk zLOzd0LsB+6To6jPqDpOenjl4D3IqZU8E1KY0Rg/SzLrlDMeqI0UAUK9UCUrsEffq8re hEXLu3CbUg+ecE66XpCWAZ2E88UNFakJLRA+57GxxNGoDOxKXNeJHpCEfXLhDip6ETcv Aac9ZYlOW8ozk1Uy7UJn2ibWQSgCP/5JSk7Y/IVR2/GRTkTie1jOQaDq26YvoCUMDC/d 0JbzoteTxEikNbg3NxJmNcP46KPA5F6ggzQlgKU3o6HFH1oj1SSIrgAfGFJl11WI67q9 Biyg== X-Gm-Message-State: ALoCoQkDPCYoRB+HbPAcjMzunoJib20Y/9BRsKqoUJMFK7iQ6NEZKxA6UE24Ord7OnYhwYhAV5GE X-Received: by 10.152.203.139 with SMTP id kq11mr37196224lac.63.1414873771506; Sat, 01 Nov 2014 13:29:31 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id ny6sm654856lbb.2.2014.11.01.13.29.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Nov 2014 13:29:30 -0700 (PDT) Message-ID: <545542AA.6090702@freebsd.org> Date: Sat, 01 Nov 2014 23:29:30 +0300 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?VHJvbmQgRW5kcmVzdMO4bA==?= , FreeBSD current Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no> <1414852431.17308.210.camel@revolution.hippie.lan> <86tx2j6k6j.fsf@nine.des.no> <1414858202.17308.214.camel@revolution.hippie.lan> <86h9yi7t14.fsf@nine.des.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 20:29:40 -0000 On 01.11.2014 21:26, Trond Endrestøl wrote: > What good does the file /entropy do if boot up is delayed everytime > during "Writing entropy file:"? Probably some entropy is needed before saved file is loaded. As raw guessing of alternative solution it is possible to make some part of previously saved entropy as kld module always loaded with the kernel. -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 22:45:54 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 795A2EEC for ; Sat, 1 Nov 2014 22:45:54 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D2B1F8F for ; Sat, 1 Nov 2014 22:45:53 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id d1so3821270wiv.13 for ; Sat, 01 Nov 2014 15:45:52 -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=shfWRixpKsx/AnYcRTz2gw29UiPxLW3JX6UJBy396y0=; b=gabMGUdoUIAL/MPhX8Jw9fea01iV20IfWS//OnCiVU2HMn+1nTb63ZhlV34ZvcZOkD 3c1rumGvSyPg3kJTh7vYdVw40wObLDmTg7ggKgvqe+y5Ih9iIa36aFGm/K7eFxc9YA/r 38m+EA0/8LA7UbFTK8HP1LSnErgNMYIh1DdTAPC24PzuwyiCEoIzLm+Nj4R5s6AWIYCF xh7WgPXn3ZnpC7QUMHM3On2xqfeLsHIS5HiHJYbtEZFVrth1KQMLIvRGm1p6k+saDZ21 8fPn7ZO46nkOO9BhBQfkQ08LIhIVvgre69T0wc/+HyvlAOfTzp/rMfxip3f0Nwvcx9fL gUFg== X-Received: by 10.180.76.199 with SMTP id m7mr6128951wiw.62.1414881952361; Sat, 01 Nov 2014 15:45:52 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fx2sm16655930wjb.37.2014.11.01.15.45.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Nov 2014 15:45:51 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 1 Nov 2014 23:45:49 +0100 From: Baptiste Daroussin To: Marc UBM Subject: Re: pkg 1.4 freeze please test test test! Message-ID: <20141101224549.GG15967@ivaldir.etoilebsd.net> References: <20141028231933.GG26796@ivaldir.etoilebsd.net> <20141101161332.b9c8fc19bf9fc54f73bc5c00@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DWg365Y4B18r8evw" Content-Disposition: inline In-Reply-To: <20141101161332.b9c8fc19bf9fc54f73bc5c00@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 01 Nov 2014 22:45:54 -0000 --DWg365Y4B18r8evw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 01, 2014 at 04:13:32PM +0100, Marc UBM wrote: > On Wed, 29 Oct 2014 00:19:33 +0100 > Baptiste Daroussin wrote: >=20 > > Hi all, > >=20 > > We are starting the release process of pkg 1.4, we want to have a bette= r release > > process than with every single previous version of pkg. For that we wil= l need > > you help! > >=20 > > pkg-devel has been updated to the latest version of pkg as of alpha2. > >=20 > > Changes you can expect in pkg 1.4 are the following: > > - Loads of bug fixes > > - Stricter checking of the path passed via the plist > > - Removal of the bundled libyaml > > - new --raw-format to chose the output format for info -R and search -R > > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10= :amd64) > > the old ABI is available as a fallback in ALTABI > > - pkg check now support a quiet mode > > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerg= ing > > configuration files > > - new @config keyword to mark a file as a config file (during > > upgrade/reinstallation it will try to merge the configuration with th= e one the > > user may have modified) an option AUTOMERGE is available to prevent > > automerging if automerge fails a .pkgnew file will be created along w= ith the > > untouched user version of the configuration > > - The update procedure has been improved and speed up a lot (in particu= lar for > > machine with low resources) > > - The unique identifier has been modified to be pkgname meaning now por= ts can be > > moved in new categories without having to be considered a different p= ackage > > - Only libraries starting by lib* are added to the provided libraries > > - General speed up of all operations > >=20 > > We need help in testing, but we also need help in writing regression te= sts ! > > The more we have tests the more stable the releases will be. > >=20 > > The release will also allow to be able to package base! > >=20 > > regards, > > Bapt >=20 > The update is failing for me with: >=20 > .../usr/ports/ports-mgmt/pkg-devel# make all install clean > =3D=3D=3D> Installing for pkg-1.4.0.a3 > =3D=3D=3D> Checking if pkg already installed > pkg-static: sqlite error while executing DROP INDEX > packages_unique;CREATE UNIQUE INDEX packages_unique ON packages(name); > in file pkgdb.c:2246: UNIQUE constraint failed: packages.name *** Error > code 74 >=20 > Stop. > make[1]: stopped in /usr/ports/ports-mgmt/pkg-devel > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/ports-mgmt/pkg-devel >=20 >=20 >=20 > portmaster fails with: > root@ubm:/usr/ports/ports-mgmt/pkg-devel# portmaster -d pkg > =3D=3D=3D>>> No ORIGIN in /var/db/pkg/pkgconf-0.9.7/+CONTENTS >=20 >=20 > =3D=3D=3D>>> Cannot continue > =3D=3D=3D>>> Aborting update >=20 > =3D=3D=3D>>> Killing background jobs > Terminated > =3D=3D=3D>>> Exiting >=20 > make.conf related options: >=20 > #enable pkgng (might be superfluous) > WITH_PKGNG=3Dyes > #enable PKGNG devel > WITH_PKGNG=3Ddevel >=20 > Am I doing something wrong? You are doing nothing wrong but that probably means you have ancient packag= es that never got upgraded (in the old time it was allowed to have 2 packages installed with the same name) we have fixed that over the time and that is = why we had unicity set to origin as a hack for a while, we are now moving to un= ique name so you have to make sure that all your installed packages are up to da= te before moving to new pkg. At least make sure you do not have 2 packages with the same name. Concerning portmaster I have no idea why it now thinks you are not using pkg :( regards, Bapt --DWg365Y4B18r8evw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRVYp0ACgkQ8kTtMUmk6ExhlwCgj0RGIn1smg9i4S8/bQ0dr7OB K/IAn1BsI8+71zL4pzFy8BJxe+xaTnAS =4cvG -----END PGP SIGNATURE----- --DWg365Y4B18r8evw--