From owner-freebsd-arch@freebsd.org Mon Aug 20 17:09:54 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75A2B1075EAE; Mon, 20 Aug 2018 17:09:54 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17FAF778CF; Mon, 20 Aug 2018 17:09:54 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: brd/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id DDC4823948; Mon, 20 Aug 2018 17:09:53 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 6AC1821DF2; Mon, 20 Aug 2018 13:09:53 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Mon, 20 Aug 2018 13:09:53 -0400 X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E0588433E; Mon, 20 Aug 2018 13:09:52 -0400 (EDT) Message-Id: <1534784992.19285.1480236912.3910D875@webmail.messagingengine.com> From: Brad Davis To: Guido Falsi , freebsd-arch@FreeBSD.org, freebsd-pkgbase@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b72137a In-Reply-To: <840cdf90-373f-91bb-df70-01b6514a65c3@FreeBSD.org> References: <1533167650.2567721.1460524472.3AC8CC35@webmail.messagingengine.com> <13a0c161-5646-1a71-c958-909829fdb6d2@FreeBSD.org> <1533401445.1155223.1463427888.4C7D62DA@webmail.messagingengine.com> <840cdf90-373f-91bb-df70-01b6514a65c3@FreeBSD.org> Date: Mon, 20 Aug 2018 11:09:52 -0600 Subject: Re: pkgbase: Move of head/etc/ files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 17:09:54 -0000 On Sat, Aug 18, 2018, at 11:34 AM, Guido Falsi wrote: > On 8/4/18 7:21 PM, Guido Falsi wrote: > > On 8/4/18 6:50 PM, Brad Davis wrote: > >> On Fri, Aug 3, 2018, at 4:43 AM, Guido Falsi wrote: > >>> On 8/2/18 1:54 AM, Brad Davis wrote: > >>>> Hello, > >>>> > >>>> I want to give some information on what is happening to files in head/etc/ and open a discussion. > >>>> > >>> > >>> Today while updating a pkgbase machine I got this error(with trimmed > >>> debug output): > >>> > >>> The following 1 package(s) will be affected (of 0 checked): > >>> > >>> Installed packages to be UPGRADED: > >>> FreeBSD-runtime: 12.0.s20180725172903 -> 12.0.s20180803092917 > >>> [mpnet-base] > >>> > >>> Number of packages to be upgraded: 1 > >>> > >>> Proceed with this action? [y/N]: y > >>> DBG(1)[71153]> want to upgrade advisory to exclusive lock > >>> [1/1] Upgrading FreeBSD-runtime from 12.0.s20180725172903 to > >>> 12.0.s20180803092917... > >>> [1/1] Extracting FreeBSD-runtime-12.0.s20180803092917: 1% > >>> DBG(1)[71153]> Populating config_file /etc/blacklistd.conf > >>> [1/1] Extracting FreeBSD-runtime-12.0.s20180803092917: 1% > >>> DBG(1)[71153]> Populating config_file /etc/defaults/rc.conf > >>> Segmentation fault (core dumped) > >>> > >>> I'm not sure if it's related to r336845 and r336847, but since those are > >>> the only one touching rc.conf recently it looks possible. > >>> > >>> Anyone has an idea what I've stumbled upon? > >>> > >>> I'm investigating this, but if I can't fix it shortly I'll revert to my > >>> previous pkg set and try again at another time. If some tests are needed > >>> I'll try to perform them as requested. > >> > >> This is a bug in pkg and has to do with these files transitioning from normal files to config files. > >> > >> I will try and work on this in the next week. > > > > Thanks in advance! > > > > For me there's no hurry. I have reverted my machine and will not be > > updating for at least a full week anyway. > > > > If you need testing I'm available though. > > > > Hi I just updated a machine using pkg with this patch added: > > https://github.com/freebsd/pkg/commit/30644237c1c655e43911110198fe23a9c835aa24 > > and it now works fine, so thanks a lot! Great, and I just committed this to ports as pkg 1.10.5_2. Regards, Brad Davis From owner-freebsd-arch@freebsd.org Tue Aug 21 09:13:40 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52BD7108EC05 for ; Tue, 21 Aug 2018 09:13:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.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 BA9CA7A8E0 for ; Tue, 21 Aug 2018 09:13:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from dhcp-10-248-112-19.eduroam.wireless.private.cam.ac.uk (global-5-143.nat-2.net.cam.ac.uk [131.111.5.143]) by mail.baldwin.cx (Postfix) with ESMTPSA id 42B8C10B45E; Tue, 21 Aug 2018 05:13:38 -0400 (EDT) Subject: Re: upstream for contrib/tzcode/stdtme? To: Eitan Adler , "freebsd-arch@freebsd.org" References: <20a85a8f-29a7-0d8f-64d1-9ba005ffe79c@FreeBSD.org> <10e35d23-37d8-edf4-fa3b-9663bfdaa629@FreeBSD.org> <7C8DB02A-8C15-4917-A941-A10DD2F3AB50@trouble.is> <8B61C2A5-DCEC-403A-B8F3-0B5BEF958612@freebsd.org> <20180812233252.GD30769@rincewind.trouble.is> From: John Baldwin Message-ID: <73a079ff-6bfd-150f-c67f-05f0f67b9aa0@FreeBSD.org> Date: Tue, 21 Aug 2018 10:13:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 21 Aug 2018 05:13:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 09:13:40 -0000 On 8/18/18 5:43 AM, Eitan Adler wrote: > On Sun, 12 Aug 2018 at 16:32, Philip Paeps wrote: >> >> On 2018-08-12 15:09:00 (-0700), Eitan Adler wrote: >>> On Sun, 12 Aug 2018 at 06:00, Philip Paeps wrote: >>>> >>>> On 2018-08-12 20:36:23 (+0800), Philip Paeps wrote: >>>> >>>>> On 2018-08-12 20:23:23 (+0800), Eitan Adler wrote: >>>>> >>>>>> On Mon, 18 Jun 2018 at 10:08, John Baldwin wrote: >>>>>>> >>>>>>> On 6/15/18 4:09 PM, Eitan Adler wrote: >>>>>>>> On 15 June 2018 at 11:31, John Baldwin wrote: >>>>>>>> >>>>>>>>> I think this second approach is actually a better plan and is not >>>>>>>>> quite what you >>>>>>>>> were suggesting. >>>>>>>>> >>>>>>>>> That is, import the vendor bits corresponding to our existing code >>>>>>>>> first into >>>>>>>>> the vendor area, >>>>>>>> >>>>>>>>> then svn cp our existing files from libc, zic, etc. into the >>>>>>>>> contrib/stdtime tree in the correct layout and do a single 'svn >>>>>>>>> merge --record-only' >>>>>>>>> merge to initialize the vendor mergeinfo. >>>>>>>>> At that point you should be able to >>>>>>>>> svn diff contrib/stdtime against the vendor/stdtime/dist to >>>>>>>>> determine what local >>>>>>>>> changes we have and start to think about them. >>>>>> >>>>>> Coming back to this. In r337683 and r337684 I imported a recent copy >>>>>> of of TZDB. I was unable to find a copy of the 2010n distribution in >>>>>> the original layout. >>>>> >>>>> That's because we split up the tzcode in our vendor area (for reasons >>>>> I've never understood). As far as I know, there is no 1:1 mapping >>>>> from any tzcode distribution to what we have in our repository. >>>>> >>>>>> The next step, if I understand, is to do the following: >>>>>> cd /srv/srv/freebsd/svn/head/contrib >>>>>> mkdir tzdb >>>>>> cd tzdb >>>>>> svn cp ../tzcode/stdtime/* . >>>>>> svn cp ../tzcode/zic/* . >>>>>> svn cp ../tzdata/* . >>>>>> svn ci >>>>>> (the above ignores duplicated files, but that's just expanding the >>>>>> wildcards appropriately). >>>>>> >>>>>> After that: >>>>>> svn merge --record-only '^/vendor/tzdb' . >>>>>> >>>>>> At this point we'll be able to diff contrib/tzdb and vendor/tzdb to >>>>>> show the most current vendor code compared our, modified old code. >>>>>> >>>>>> Is this correct? Is this the optimal plan? >>> >>> ... >>>> please import tzcode separately and leave tzdata alone. >>> >>> Done in r337693 and r337694. >> >> Thank you! >> >> For the next tzdata import, I'll consider moving vendor/tzdata to >> vendor/tzdb/tzdata before doing the copies to contrib/. >> >>> The next step, if I understand, is to do the following: >>> cd /srv/srv/freebsd/svn/head/contrib >>> mkdir tzdb >>> cd tzdb >>> svn cp ../tzcode/stdtime/* . >>> svn cp ../tzcode/zic/* . >>> svn ci >>> (the above ignores duplicated files, but that's just expanding the >>> wildcards appropriately). >>> >>> After that: >>> svn merge --record-only '^/vendor/tzdb' . >>> >>> At this point we'll be able to diff contrib/tzdb and vendor/tzdb to >>> show the most current vendor code compared our, modified old code. >>> >>> Is this correct? Is this the optimal plan? >> >> I would keep contrib/tzcode (and contrib/tzdata) rather than moving to >> contrib/tzdb. Having them together under vendor/ makes sense because >> it's the same vendor, but under contrib, they're definitely separate. > > I wanted to use a separate directory to make it clearler what's clean > and what's not but lets go with the current directory. > > cd /srv/srv/freebsd/svn/head/ > cd contrib/tzcode > svn mv stdtime/* . > svn cp zic/* . > cd ../.. > $EDITOR usr.sbin/zic/zic/Makefile > $EDITOR usr.sbin/zic/zdump/Makefile > $EDITOR lib/libc/stdtime/Makefile.inc > svn ci > svn merge --record-only '^/vendor/tzcode' . > svn ci > > This will leave contrib with the old code and vendor with the new code > and mergeinfo claiming we're fully merged. Is that the state of > affairs that we want? I don't know subversion well enough to > formulate a better plan. Can't you import the "current" version of tzcode into the vendor area (what we have now) and then diff against that once it is moved to see what local diffs we have that we still need vs don't need, then separately update the vendor area to the latest version and do a "normal" merge? If we can't determine what version we currently have then you can look at the manual diff as a fallback, but if you can find the matching version and import that into vendor first that might be best. -- John Baldwin From owner-freebsd-arch@freebsd.org Thu Aug 23 09:43:48 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9A241087E34 for ; Thu, 23 Aug 2018 09:43:47 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC668A90E for ; Thu, 23 Aug 2018 09:43:47 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: by mailman.ysv.freebsd.org (Postfix) id 247C91087E33; Thu, 23 Aug 2018 09:43:47 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 022021087E32 for ; Thu, 23 Aug 2018 09:43:47 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (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 8B9298A909; Thu, 23 Aug 2018 09:43:46 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.46.172.3] (helo=sslproxy06.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1fsm9Y-00056z-Dk; Thu, 23 Aug 2018 11:43:44 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fsm9Y-000O98-7H; Thu, 23 Aug 2018 11:43:44 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id EEC832A165C; Thu, 23 Aug 2018 11:43:46 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id toTV3S-33h5c; Thu, 23 Aug 2018 11:43:44 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1D42D2A167F; Thu, 23 Aug 2018 11:43:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7M2Qg7nOWnvX; Thu, 23 Aug 2018 11:43:44 +0200 (CEST) Received: from [192.168.96.149] (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTPSA id E28762A165C; Thu, 23 Aug 2018 11:43:43 +0200 (CEST) Subject: Re: C++ in the kernel? To: Eitan Adler , "freebsd-arch@freebsd.org" , David Chisnall , Justin Hibbits , Maxim Sobolev References: From: Sebastian Huber Message-ID: <501127e3-3ff0-3606-4a24-b3ab0b9c11e6@embedded-brains.de> Date: Thu, 23 Aug 2018 11:43:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.1/24865/Thu Aug 23 07:52:53 2018) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 09:43:48 -0000 On 29/06/18 09:59, Eitan Adler wrote: > This was the contents of a conversation on a different list. Figured > it was more appropriate here: > >>> We are experimenting with a C++ library for systems programming and a= re interested in trying it in the FreeBSD kernel. Has anyone managed to = run C++ code in the kernel before and perhaps have patches to make the ke= rnel headers somewhat less C++-hostile that they=E2=80=99d be willing to = share? >>> A friend gave a WIP talk at BSDCan a few years ago doing this very th= ing. You can find his work at https://github.com/adamlsd/libcpp.ko >>> I believe few times I've seen this discussion over the years the main= concerns raised were uncertainty about handling of exceptions and also l= ack of the real stable ABI for the C++. Each compiler seems to have its o= wn conventions, which might vary even between compiler revisions. https:/= /youtu.be/JPQWQfDhICA?t=3D51m55s What might be possible, however, is to h= ave particular C++ "runtime" as a module itself, which is then would be u= sed by the other modules that are compiled with that particular C++ compi= ler. >>> Most kernels that use C++ require -fno-rtti -fno-exceptions, so don=E2= =80=99t rely on a runtime. The ABI concerns were a problem 20 years ago,= but *NIX systems have kept the same C++ ABI since everyone[1] adopted th= e Itanium ABI. [1] Well, almost everyone. AArch32 has a slightly differ= ent ABI, but it has also been stable for a similar length of time. >>> Thanks, the include directory of that repo looks to be exactly what I= need to get the subset of libc++ that I need working. FreeBSD started to use the Concurrency Kit in the kernel. Concurrency=20 Kit seems to be intentionally incompatible to C++: https://github.com/concurrencykit/ck/pull/89 --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= .