From owner-freebsd-hackers@freebsd.org Sun Sep 24 21:01:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1309BE0161A for ; Sun, 24 Sep 2017 21:01:18 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0A1733A4 for ; Sun, 24 Sep 2017 21:01:17 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id q8so5207117qtb.5 for ; Sun, 24 Sep 2017 14:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=Tfk+Fwd5WNZuuk1kqFKZJFpVeLyocSbo1WHHq/j9BkU=; b=s3k6cmLtdpyMAOJpUCy517gxeVx4AAyKevWFyxTXT7nIWR1Kr5nAbv79m52qRfhiNX TWx5kR6Vgv1eKboqCZWDjSSkOLCMV5FdLSglcbSCdYtlrkR+Jh1YK4KSn8hOXeOLwghU sTzdlBSG9oX50z5+85cCPuMjZeJBQIopfD/k/siTD8fSeR6vSMF7C0QuZvA53MmZgqGh 5ZQUHtludD+4YutlpRf3dCOoY5CjF/iTWvvocmL+qRqavYnCAOuPS5nw+1Z8Mg0aK0Ud 2BAxNj/PfPnJTf3MyMt4i7gXred1jhUhLI7Jjg/f8lhAD2UnjS59r39xjZOGlW8vDDvY GyNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Tfk+Fwd5WNZuuk1kqFKZJFpVeLyocSbo1WHHq/j9BkU=; b=QGSM5AH0LFWUA17Ma6CwxmSmAJ7GSfII4lgLUvWRBwRrHzFWMXUkeMBEDRMC3F4G0E ydSo238AGXc2/RYaWF/Mru4PQ1xfGnyCKoXhMvPwgsd5zkjb4aSt9J2fYCf8+7Fbc1D/ tYBDvwmfDPwfbcn7mrxGOjuPd49AOUoJgFjEGm0WSoV2EOqyT1p/IYx2S05PqDUyfymv bgWxtWK3OVye41DY/7mRsydy/aUaNu4yVSnJ2xVk+xHYhQ9sp6Cy/sIp9fhkFYIZCdQt VUxhB+wTFZfMHKQMshbZeklSveLTEiGI/0+N7xI56snbSbntOwbne8K0SUK5AmMDaC1J EZwg== X-Gm-Message-State: AHPjjUiOX9D+Z1eD1ulFG0SWDMkwQ+5GDzTe3ajK8oIz/1q0t6hNzzHK +H3LMUpMt3rwTn2mVjIjcmBGmkQH X-Google-Smtp-Source: AOwi7QDLl040mgm2x1asqM+B8LjFweGpWpKxRlNVHXi+vFSd/A2OSIadsN6iESyPqTPpNLO+gO+dBQ== X-Received: by 10.237.33.162 with SMTP id l31mr9027815qtc.255.1506286876543; Sun, 24 Sep 2017 14:01:16 -0700 (PDT) Received: from pc.farhan.codes ([2001:470:8:209::dead:c0de]) by smtp.gmail.com with ESMTPSA id d186sm3809589qkg.46.2017.09.24.14.01.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Sep 2017 14:01:15 -0700 (PDT) To: freebsd-hackers@freebsd.org From: Farhan Khan Subject: Debugging symbols on kernel module Message-ID: Date: Sun, 24 Sep 2017 17:01:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 21:01:18 -0000 Hi all, I am working on a kernel module but am getting some unexpected code execution. Dtrace probes reveal that the kernel executes: "rtwn.ko`r88ee_init_bb+0x219" and then jumps to an unexpected function. I would like to track down exactly which line that is. I compiled the module with this: # make DEBUG_FLAGS=-g3 -C sys/modules/rtwn/ This produced the rtwn.ko.debug and rtwn.ko.full files. But when I load them, I still do not have debugging symbols: $ kgdb rtwn.ko GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from rtwn.ko...Reading symbols from /usr/src/sys/modules/rtwn/rtwn.ko.debug...(no debugging symbols found)...done. (no debugging symbols found)...done. (kgdb) file rtwn.ko.debug Reading symbols from rtwn.ko.debug...(no debugging symbols found)...done. (kgdb) file rtwn.ko.full Reading symbols from rtwn.ko.full...(no debugging symbols found)...done. How do I properly load debugging symbols for the module? Thanks, Farhan Khan From owner-freebsd-hackers@freebsd.org Mon Sep 25 07:50:35 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C52C9E0D313 for ; Mon, 25 Sep 2017 07:50:35 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 579D071A4D for ; Mon, 25 Sep 2017 07:50:35 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by mail-wr0-x243.google.com with SMTP id b9so1332245wra.0 for ; Mon, 25 Sep 2017 00:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=lceoMN2cmgRORcDo5lBUQ7NUK42XdXfvpHPSxvpLqLk=; b=LsznrgyXvJgoRRQM5Dii8ch7j2BcwJ0SzZ7WzRmGOhiK/w3yLatYARQ4tJEhMWee5A R56uvcrYdKjmnYVXY0TR7E9wMQ3m3JhzN1vfufdqInKIjwqqRB8/f/FoJ+TnEj6+rpa2 W59y1xnmVfkrPT3NfnhDQlqLauXmhUvuJOuWFXwqCG90jj3gvNsHqYCgemxol8RErfM6 CcmH+kJ5YGwYP3pIQlirwKI+KPoVdviW29fMp4+K1KEKK3/Yr8hpYY6zMyDBNjDEgK4R IVK6a4SwmV0SY7owdN1zhcWzNn5BiQckDhxRvBsKrdYsSfmGwX7tACMnPVkqMtRb6bNk 381Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=lceoMN2cmgRORcDo5lBUQ7NUK42XdXfvpHPSxvpLqLk=; b=QK8+D7dH2Q9YBQfUBsxduTjrABtTJsrUd0HFsxDzQI9Q9BewRXiz/jcjgtThDIxpXR +dJ/C7HbmyL0lcGSlVyvsfGCrOSjYqd/Wsg1P9JMTC/3o3N38apsmojlnwv679Fz5R3v l+rwPj++HG3LRm4GUqOLcPfJfYuYHeJ3Tozixjjd+HZCtkLt96JGpIoo5kZwxuxpWXyC FVvejSDhyLAAJqiXAZx271I6yyaGVIzDr75PJGGs/j2YHDcQH3Bwso6r0LPrtcmBpzjO bW9wv7U3BTR5Jn4KgnNv9mHvkOR4n7iPeOl4XugvuxKIUHiysx4K8Fnq+BLPHOgnjA1z STxA== X-Gm-Message-State: AHPjjUhwUx0IIOfiftaVanKMUzK5+2ZTu7+1pET4GkXoIUiUziYQglzK pocRQ0DvEQ0AXAZbuihienc= X-Google-Smtp-Source: AOwi7QDgUISYExx3vXGtEZugx8+WDca9evnOoDI8zXhUSI2DHQGsF33fIVOJRld5IXmg41V8MJUwIg== X-Received: by 10.46.83.81 with SMTP id t17mr2250817ljd.180.1506325833712; Mon, 25 Sep 2017 00:50:33 -0700 (PDT) Received: from thinkpad-x220 (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id t20sm1286483ljb.91.2017.09.25.00.50.32 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 25 Sep 2017 00:50:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Farhan Khan" Subject: Re: Debugging symbols on kernel module References: Date: Mon, 25 Sep 2017 10:48:12 +0300 Cc: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 07:50:35 -0000 Hi, for debugging purposes I'm adding next line in make.conf: CFLAGS+= -O0 -g Works for modules but not for the kernel (KSTACK_PAGES needs to be increased for the whole kernel build). > Hi all, > > I am working on a kernel module but am getting some unexpected code > execution. Dtrace probes reveal that the kernel executes: > "rtwn.ko`r88ee_init_bb+0x219" and then jumps to an unexpected function. > > I would like to track down exactly which line that is. I compiled the > module with this: > > # make DEBUG_FLAGS=-g3 -C sys/modules/rtwn/ > > This produced the rtwn.ko.debug and rtwn.ko.full files. But when I load > them, I still do not have debugging symbols: > > $ kgdb rtwn.ko > GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD] > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd12.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from rtwn.ko...Reading symbols from > /usr/src/sys/modules/rtwn/rtwn.ko.debug...(no debugging symbols > found)...done. > (no debugging symbols found)...done. > (kgdb) file rtwn.ko.debug > Reading symbols from rtwn.ko.debug...(no debugging symbols found)...done. > (kgdb) file rtwn.ko.full > Reading symbols from rtwn.ko.full...(no debugging symbols found)...done. > > How do I properly load debugging symbols for the module? > > Thanks, > > Farhan Khan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Tue Sep 26 01:00:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94ABFE27C65 for ; Tue, 26 Sep 2017 01:00:42 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AC886F4F4 for ; Tue, 26 Sep 2017 01:00:42 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-qt0-x244.google.com with SMTP id b1so6118218qtc.0 for ; Mon, 25 Sep 2017 18:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M7hdL+m+2lkSIn42r7AoX5kfz9zKJZm8gFUIZ0GBq/k=; b=ZcKT82ef39WxMqyr+pfqUgOTMORWhNhNMecRa1nC1q1i6eQIjXqjVKNvWB99Lj5bPS Rp6cKWdowgFkcJBduf+auCcLPL17/KjfhsmNvovU5QpOofBjBJRAQ94J+rughY0FG6mW IZHmKx+ylDfUBLbW21xPgKAMwczunXUt1chLdTFwYu3hPPKW3gNgtwHIwZZfjEMpTeTW vdVEasHzZ+IWt+heGWKF8qoWPuE90x1iSFuJQRq3VV8B0q0ZV63n9ZfJ9yPIZcOCmcU9 4GwHvCmaTr7UZxtLQz5lU3FB7/ORz8cB0lfEpShzlEG8VrVmDqyb+JxkTKwREYUwb9Xx GQHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M7hdL+m+2lkSIn42r7AoX5kfz9zKJZm8gFUIZ0GBq/k=; b=bKrYKE1LgXwuLU2KFm/w6NwEBC+USMnfla7pQJ5uMXnbyWawL9zKFrcT4kX68086qf yI3MjAzcTew+p0ObAzTSFrGu1Q04e2pTuUEAMvANtR/b730e5kWfaO9x80AiRtHSj6at 1694oozy1wFNYTxB4pR5YtzQLxWidTUiWRUBTfsEgAfiyUYbvyFOLgcGd1RXpdw4+yVm bWwJTued+MfbvvsJ+C+jPQnaUWtgsJJZYYY7nvO2JaB3y73K0VXkWgs6k4QQCjSQrTzE HG7OVSlZRfNOtZlivETGxkw7/o0VT9T/qN3zksNMW1UDLK1rBIAdizPbZGpdB7oFpUMB 5mlg== X-Gm-Message-State: AHPjjUjXqKzGanmtmfgK34HHjl32t6hAf1Bke/DZxR5YlRB3aMxxL6Uc tZyZfC/eR3nAo2YSYIbMQvNds4aa X-Google-Smtp-Source: AOwi7QCr/hJ5KOAYUybdClSNwIkBJ5OQvCHDA1S37rBY2zGgM4KFezldvRfFKI5N4LZf2ANisJ7PAw== X-Received: by 10.200.4.36 with SMTP id v36mr12941014qtg.110.1506387641128; Mon, 25 Sep 2017 18:00:41 -0700 (PDT) Received: from pc.farhan.codes ([2001:470:8:209::dead:c0de]) by smtp.gmail.com with ESMTPSA id h29sm6002816qtk.29.2017.09.25.18.00.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 18:00:39 -0700 (PDT) Subject: Re: Debugging symbols on kernel module To: Andriy Voskoboinyk Cc: "freebsd-hackers@freebsd.org" References: From: Farhan Khan Message-ID: <64eca59f-f937-cb8e-0a45-0ea8abcf2411@gmail.com> Date: Mon, 25 Sep 2017 21:00:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 01:00:42 -0000 As suggested, I set my /etc/make.conf to this: CFLAGS+= -O0 -g DEBUG_FLAGS+= -g3 And it worked. Thank you, Andriy! On 09/25/2017 03:48 AM, Andriy Voskoboinyk wrote: > Hi, > > for debugging purposes I'm adding next line in make.conf: > > CFLAGS+=    -O0 -g > > Works for modules but not for the kernel > (KSTACK_PAGES needs to be increased for the whole kernel build). > >> Hi all, >> >> I am working on a kernel module but am getting some unexpected code >> execution. Dtrace probes reveal that the kernel executes: >> "rtwn.ko`r88ee_init_bb+0x219" and then jumps to an unexpected function. >> >> I would like to track down exactly which line that is. I compiled the >> module with this: >> >> # make DEBUG_FLAGS=-g3 -C sys/modules/rtwn/ >> >> This produced the rtwn.ko.debug and rtwn.ko.full files. But when I >> load them, I still do not have debugging symbols: >> >> $ kgdb rtwn.ko >> GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD] >> Copyright (C) 2017 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law.  Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "x86_64-portbld-freebsd12.0". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> . >> Find the GDB manual and other documentation resources online at: >> . >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from rtwn.ko...Reading symbols from >> /usr/src/sys/modules/rtwn/rtwn.ko.debug...(no debugging symbols >> found)...done. >> (no debugging symbols found)...done. >> (kgdb) file rtwn.ko.debug >> Reading symbols from rtwn.ko.debug...(no debugging symbols found)...done. >> (kgdb) file rtwn.ko.full >> Reading symbols from rtwn.ko.full...(no debugging symbols found)...done. >> >> How do I properly load debugging symbols for the module? >> >> Thanks, >> >> Farhan Khan >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Sep 27 14:46:52 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F03DE05ECE for ; Wed, 27 Sep 2017 14:46:52 +0000 (UTC) (envelope-from tyler@tysdomain.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E05BC75B88 for ; Wed, 27 Sep 2017 14:46:51 +0000 (UTC) (envelope-from tyler@tysdomain.com) Received: by mail-qt0-x22d.google.com with SMTP id l25so13892939qtf.13 for ; Wed, 27 Sep 2017 07:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tysdomain-com.20150623.gappssmtp.com; s=20150623; h=reply-to:to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=FTl44Xh5/dA+cFucj9LwViz/V5FRQHoTjTAmcxWFgbg=; b=jlumJLKLjL7zsZTKpDy+wDZA0Gssd56Do6k8NON4ZwYHmzQp8v4ZWq2M63s5Z+FYXG KWCHqkYYWXWCa5PMBwSkZ2+LV1fu0tRhbA5cs2KgS+Op/2La6rxwywAgqSqkeARWFLit CaCh2nRPj8OFNpL2AukTjoBph+Urp0PQF9kyEMveDq85pKBpymI5lRhR+YFQW60JOPPp fZWaVNYvpp4FK40plArvthWk3/2ewh3b9fIGva45PPZq7ZBCSP/eZbiPLxRBuTyJ4yKu THpMGP/LFFeNpK0dLdkKdNLkGrXW3IHoAaqemwVrDplvJXlu0L46tz+gZA6gwylKX8lj jGyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:to:from:subject:message-id:date :user-agent:mime-version:content-language; bh=FTl44Xh5/dA+cFucj9LwViz/V5FRQHoTjTAmcxWFgbg=; b=XKscArkbnI8sezZBZRlarsws1GMOsB5tOHhE46MHYJJ/FYS8gu6P3LHZNIQL74AFuu 1TrafrWMDqwuHbmWE0n2giF3bVLyXFOf5mRBo4tozSo9a9a5xB7Fej5pYJdXZzeR1gUo uzyvPjzu2v6P6QIBQ+5B6nGglryRYx7FRuDWjUf3V5ecXwPE3ZImjMzVeuk1NZPuiKJq zUU6xnaE5TYfBAysMoNcSJYIfzWEs1DqbNvVoScDzanSexy+qizrbsNGR7QCYY6/qTDo KP0toCqZBx7tQ7QRiLgYEtkADkmhuA5cekusZMM1lcvgX8TK1xe3nL8cpKaTaHNjg5Jw FIuQ== X-Gm-Message-State: AHPjjUhwbENmkR9EVQTdTUSSWUORgnKBSP4sjefKbaeu3xqkliJUHQmt /L4sdkuOyktVUk/N0aF4pM/w6iwKrjw= X-Google-Smtp-Source: AOwi7QCSwFPuH09GRYwPNPMoDp8/IvwHo2OrWyQKfoJ3y2np2ZLTGrbvL1F24uoqQ31oHhGylM573g== X-Received: by 10.200.42.244 with SMTP id c49mr2244922qta.46.1506523610742; Wed, 27 Sep 2017 07:46:50 -0700 (PDT) Received: from [192.168.88.101] (c-98-229-109-58.hsd1.ma.comcast.net. [98.229.109.58]) by smtp.gmail.com with ESMTPSA id f48sm8796233qtc.49.2017.09.27.07.46.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 07:46:50 -0700 (PDT) Reply-To: tyler@tysdomain.com To: FreeBSD Hackers From: "Littlefield, Tyler" Subject: rsync quickly poudriere packages Message-ID: <7cf77685-bf47-d23f-e4de-5e02e5fe6488@tysdomain.com> Date: Wed, 27 Sep 2017 10:46:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 14:46:52 -0000 All: I'm using the following command to rsync my poudriere packages I use for testing: rsync -azhve ssh --delete -r /usr/local/poudriere/data/packages tyler@foo.bar:/pkg The issue is that there's  a path: packages/11-amd64-default/.real_1506522867/ which doesn't match the .real of any other path (I'm not sure when that changes). so it deletes everything and always reuploads. Is there a workaround to this? I'd like it to ignore/move the stuff in .realXXXXXXXX that is current and send everything that is new. Thanks, -- Take Care, Tyler Littlefield Tyler Littlefield Consulting: website development and business solutions. My personal site My Linkedin @Sorressean on Twitter From owner-freebsd-hackers@freebsd.org Wed Sep 27 23:06:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C993DE12A72; Wed, 27 Sep 2017 23:06:58 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 1AC0B6474C; Wed, 27 Sep 2017 23:06:54 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-8b1ff70000004e42-dd-59cc2dd90556 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 58.1E.20034.9DD2CC95; Wed, 27 Sep 2017 19:01:45 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v8RN1ivs018522; Wed, 27 Sep 2017 19:01:44 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8RN1dKE001435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Sep 2017 19:01:41 -0400 Date: Wed, 27 Sep 2017 18:01:39 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2017 Message-ID: <20170927230138.GB96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HeFlAV5LIbMFYYuh" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPKsWRmVeSWpSXmKPExsUixCmqrXtT90ykwYujWha7rp1mt5jz5gOT xfbN/xgtDjcLObB4zPg0nyWAMYrLJiU1J7MstUjfLoEr4/GbQ+wFixazViz9/YCxgXH9RJYu Rg4OCQETicZPaV2MXBxCAouZJL7NnMkM4WxklNjRN58JwrnKJHHu4QugDk4OFgFViefrFrCD 2GwCahLrV1xjBrFFBOQl9jW9B4szC1hL/HvQCBYXFrCTmHFwJROIzQu0rW35PGYIW1Di5Mwn LBD1ZRKf9qxiA7mIWUBaYvk/DpCwqICyxLx9q9gmMPLNQtIxC0nHLIQOiLC6xJ95l5gxhLUl li18zQxh20qsW/eeZQEj+ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTSTYyg8GZ3 UdrBOPGf1yFGAQ5GJR7eCwtORwqxJpYVV+YeYpTkYFIS5W1UPhMpxJeUn1KZkVicEV9UmpNa fIhRBWjXow2rLzBKseTl56UqifCeZwaq401JrKxKLcqHKZPmYFES590WtCtSSCA9sSQ1OzW1 ILUIJivDwaEkwftbB6hRsCg1PbUiLTOnBCHNxMF5iFGCgwdoeCpIDW9xQWJucWY6RP4UYyxH 14qLf5g4jm26DCQPTLgCJPfdvAMkH924CyTn3ASRm8Dkiv/3gOSG7w/+MAmBXSwlzvsJZKgA yNCM0jy4vaB0KJG9v+YVozgwSIR5k4HJUYgHmErhNr8COooJ6KjeqSdAjipJREhJNTC6V1b9 nmBxaOKR6/84T5n9vmm2U3fBI8uXdklxXKtWKd5K/Z3wyz/mb9q2MyeKfyxwty5t+xhwnWnO gvO776woKHkXMm/JOpUkL8s9bAwMTnxPWtSyCxvn6962OZezLztVI7h8Pdvv6+8kVW+e/BIm rvBLbD/7VuuVbFrCVjLl/lJf64rY1m9XYinOSDTUYi4qTgQAcmBcT2IDAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 23:06:58 -0000 --HeFlAV5LIbMFYYuh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Quarterly Status Report - 2nd Quarter 2017 FreeBSD continues to defy the rumors of its demise. Much of the development work done this quarter was not particularly visible, especially the effort needed to ensure the upcoming 11.1 release has as few regressions as possible. Planning is also well under way for the 10.4 maintenance release which will quickly follow it. Further work focused on moving the arm architectures' support closer to tier-1 status and improving documentation. In addition, large changes were made to the src and ports trees. These projects and others are further detailed below. --Mark Linimon __________________________________________________________________ The deadline for submissions covering the period from July to September 2017 is October 21, 2017. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team * The FreeBSD Foundation * The Postmaster Team Projects * 64-bit Inode Numbers * Capability-Based Network Communication for Capsicum/CloudABI * Ceph on FreeBSD * DTS Updates Kernel * Coda revival * FreeBSD Driver for the Annapurna Labs ENA * Intel 10G Driver Update * pNFS Server Plan B Architectures * FreeBSD on Marvell Armada38x * FreeBSD/arm64 Userland Programs * DTC * Using LLVM's LLD Linker as FreeBSD's System Linker Ports * A New USES Macro for Porting Cargo-Based Rust Applications * GCC (GNU Compiler Collection) * GNOME on FreeBSD * KDE on FreeBSD * New Port: FRRouting * PHP Ports: Help Improving QA * Rust * sndio Support in the FreeBSD Ports Collection * TensorFlow * Updating Port Metadata for non-x86 Architectures * Xfce on FreeBSD Documentation * Absolute FreeBSD, 3rd Edition * Doc Version Strings Improved by Their Absence * New Xen Handbook Section Miscellaneous * BSD Meetups at Rennes (France) Third-Party Projects * HardenedBSD __________________________________________________________________ FreeBSD Team Reports FreeBSD Release Engineering Team Links FreeBSD 11.1-RELEASE Schedule URL: https://www.FreeBSD.org/releases/11.1R/schedule.html FreeBSD Development Snapshots URL: https://download.FreeBSD.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. The FreeBSD 11.1-RELEASE cycle started on May 19, and continued as scheduled. FreeBSD consumers are urged to test whenever possible to help ensure the reliability and stability of the upcoming second release from the stable/11 branch. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team Website URL: https://www.freebsd.org/portmgr/index.html FreeBSD portmgr on Twitter (@freebsd_portmgr) URL: https://twitter.com/freebsd_portmgr/ FreeBSD Ports Management Team on Facebook URL: https://www.facebook.com/portmgr FreeBSD Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: Ren=C3=A9 Ladan Contact: FreeBSD Ports Management Team This quarter, 2017Q2, broke the 30,000 ports landmark for the first time. The PR count is currently just under 2,500, with almost 600 of them unassigned. This quarter saw almost 7,400 commits from 171 committers. More PRs got closed this quarter than last quarter, but also more PRs got sent in, both of which are good to see. Over the past three months, we welcomed four new committers: Bradley T. Hughes (bhughes@), Danilo G. Baio (dbaio@), Jochen Neumeister (joneum@), and Richard Gallamore (ultima@). kan@ re-joined us as a ports committer. One commit bit, that of bf@, was taken in for safekeeping after a long period of inactivity. On the management side, the Ports Management Team welcomed back bapt@, who is working on several new features for the Ports Tree. The Ports Management Team also had its annual real-life meeting during BSDCan. On the infrastructure side, three new USES values were introduced: * cargo, to ease the porting of Rust packages or binaries using the cargo command (also covered separately in this report) * groff, to handle a dependency on the groff document formatting system, that has been removed from the base system for FreeBSD 12 * meson, to provide support for projects based on Meson The default version of PostgreSQL switched from 9.3 to 9.5, and that of Python3 from 3.5 to 3.6. The default generator for ports using cmake has been switched to ninja. Some major version updates are: pkg 1.10.1, Firefox 54.0.1, and Chromium 59.0.3071.115. Behind the scenes, antoine@ ran 36 exp-runs to test version updates, make the CRAN ports platform-independent, test installing bsdgrep(1) as /usr/bin/grep, test LLVM updates, test the ino64 project, and perform Makefile cleanups. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team Core's activities during the second quarter culminated in the introduction of two new initiatives during BSDCan: * Extending FreeBSD Project Membership * The FreeBSD Community Process FreeBSD Project Members FreeBSD Project Membership being extended to more than just committers is a step that enables the Project to recognise and reward people who support us in ways other than by writing code. People that organise conferences or user groups; who are prominent supporters on social media; who triage bug reports and who test changes; and many others who contribute in various ways, are deserving of recognition for the support that they give to the Project. Core hopes that this will both encourage more people to volunteer their time and effort on behalf of the Project, and encourage those who already do to stick with the Project, if not become more deeply involved. The naming for the new group of non-committer Project members took a few tries to get right: having tried, and rejected, "Contributor" and then "Associate", Core took the view that since what they were offerring was formal Project Membership, then that was the right thing to call it. Committers thus become those Project Members with access to commit to the Project's code repositories. Project Members receive an @FreeBSD.org e-mail address, access to various Project hardware, access to internal mailing lists and other communications channels, and invitations to attend Developer Summits in their own right. Committers in addition have commit rights in the Subversion repositories and GitHub, and active Committers can vote in Core team elections. The FreeBSD Community Process This is an idea that has a long pedigree within other projects, and FreeBSD is very consciously modelling its implementation on what has worked elsewhere. When a significantly disruptive or wide-scale change is proposed, we should have a formal mechanism for documenting the change and what it implies. Interested parties can then respond and the change can be evolved into the best fit for all users, or else it can be found to be impracticable and withdrawn. The documentation of the change will remain as a point of reference should the same or a similar proposal come up in the future. Creating a more formal process should help avoid endless sterile arguments about what needs to be done, without anyone feeling they have sufficient investment in the idea nor backing from the majority of the project to justify putting in the work to achieve the desired result. The very first FCP -- FCP 0 -- describes the process itself. At the time of this writing, Core is voting on accepting the initial document, which can be viewed in the Project's Github repository. Two new mailing lists have been created: fcp@FreeBSD.org is the channel for receiving notifications of new FCP proposals and discussing their content, whilst fcp-editors@FreeBSD.org exists to provide help with the process of drafting the FCP documents. Other Core activities Core is delighted to announce that Gordon Tetlow has joined the Security Officer team, and will be working on managing the Security Team caseload, freeing up other members to concentrate on the more technical aspects of vulnerability remediation. In addition, Ed Maste has joined the Security Team and is available to assist the Security Officers where necessary. Although Florian Smeets had to step down, the postmaster team has recruited three new members and is now back up to strength. Considering the desirability of a number of fixes that have been merged into 10-STABLE since the 10.3 release, core has approved a 10.4 release to occur shortly after the 11.1 release. This will be a normal support-lifetime release, unlike the extended lifetime of the 10.3 release, so the overall support lifetime for the 10.x branch will not be significantly extended. During this quarter, Core has approved issuing three new commit bits. Please welcome: * Vladimir Kondratyev (wulf@) * Ryan Libby (rlibby@) * Kyle Evans (kevans@) Also, during this quarter, we had one person give up their commit bit: * Jordan Hubbard (jkh@) It is always unsettling when one of the Project's founding members decides to move on, but Jordan's interests have migrated away from FreeBSD-related projects and he has decided to hang up his bit once and for all. Core would like to thank NTTA (formerly Verio) for providing hosting for a cvsup mirror for many years, and also for their kind offer to provide ongoing hosting for a machine in their Seattle facility. Since we have no need for additional North America hosting, we have declined their offer. As usual, a number of questions have been raised about code licensing and other matters related to intellectual property. Ed Maste has registered "freebsd" on behalf of the FreeBSD Foundation on the Mastodon social media network. The "Unlicense" is suitable for code being imported into libc. We still have some code published under the old 4-clause style BSD license, where the extra clause refers specifically to the University of California. While UC has generally approved removing that clause, we need to check with all copyright holders before changing any remaining 4-clause licensing. Core, along with the Security Team, are monitoring developments concerning the "Stack Clash" vulnerability that hit the headlines during June. Changes to the stack-guard mitigation system are underway as a response to the proof-of-concept published by Qualys. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ FreeBSD Foundation Quarterly Newsletter URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/06/FreeB= SD-Foundation-Q2-2017-Update.pdf Contact: Deb Goodkin Last quarter the Foundation was busy supporting the FreeBSD Project in so many ways! We brought on two interns from the University of Waterloo who were extremely productive, from working on a continuous integration project to adding MSDOS FAT filesystem support to makefs. We continued helping to accelerate OS changes with our internal staff of software developers, as well as funding outside software development projects, and continued promoting FreeBSD by participating in technology conferences around the world. To encourage more commercial users to donate to the Foundation, we launched a new partnership program. The FreeBSD 11.1 release effort has been led by a full-time Foundation employee, to continue keeping releases timely and reliable. Finally, we led the effort to celebrate the newly declared FreeBSD Day, to help raise awareness of FreeBSD around the world! Below, you can read some of the highlights from our Q2 newsletter, and find writeups throughout this status report from Foundation staff members including Ed Maste, Kostik Belousov, and Glen Barber. Don't forget, we are 100% funded by donations. Please take a moment to donate now, so we can continue supporting the FreeBSD Project and community worldwide! Q2 Development Projects Summary Our hard work continues into the 2nd quarter of 2017. Please take a look at the highlights from our more recent Development Projects summaries. April: FreeBSD USB Mass Storage Target Project Update The Foundation awarded a project grant to Edward Tomasz Napiera=C5=82a to develop a USB mass storage target driver, using the FreeBSD CAM Target Layer (CTL) as a backend. This project allows FreeBSD on an embedded platform, such as a BeagleBone Black or Raspberry Pi Zero, to emulate a USB mass storage target, commonly known as a USB flash stick. Read more at https://www.FreeBSDfoundation.org/blog/april-2017-development-project= s-update/. May: Foundation Brings on Co-Op Students At the beginning of May we embarked on a new path in the FreeBSD Foundation, with the hiring of co-operative education (co-op) students from the University of Waterloo. The University of Waterloo is a pioneer and leader in co-operative education, with 100% of Engineering students and a majority of Computer Science students participating in co-op programs. Read more at https://www.FreeBSDfoundation.org/blog/may-2017-development-projects-upd= ate/. June: FreeBSD Foundation 2017 Project Proposal Solicitation (contributed by Ed Maste) One of the ways the Foundation supports FreeBSD is by providing development grants for work on individual projects. These allow developers to propose projects they would like to undertake to improve FreeBSD and request funding to perform that work. The Foundation is always willing to receive proposals, but will occasionally issue a call for proposals to highlight specific areas of focus and to be able to collect and evaluate a group of proposals. The proposal submission deadline was July 14, 2017, but as mentioned above, people are welcome to submit proposals at any time. Although proposals may address any FreeBSD subsystem or infrastructure, we are particularly interested in receiving proposals related to: * Improvements to the security of FreeBSD itself, or of applications running on FreeBSD * New test cases, improved test infrastructure, and quality assurance * Improved software development tools * Projects to improve community collaboration and communication * Improving the FreeBSD "out of the box" experience for new users on various hardware platforms * Establishing FreeBSD as a leader in advancing projects of shared interest (such as ZFS, LLVM, or libarchive) More details can be found at https://www.FreeBSDfoundation.org/blog/FreeBSD-foundation-2017-project-p= roposal-solicitation/. The full project proposal submission guidelines can be found at http://cts.vresp.com/c/?FreeBSDFoundation/d364934d4d/TEST/1b229d9af7. Please do not hesitate to contact proposals@FreeBSDfoundation.org with any questions. Announcing the New Partnership Program (contributed by Deb Goodkin) I'm excited to announce our new FreeBSD Foundation Partnership Program! Our work is 100% supported by donations from individuals and organizations. With a spending budget of $1,500,000, we rely on large donations from our commercial users to help us sustain and increase our support. Recognizing the value of these donations, and putting together a sustainable funding model, we wanted to institute benefits that highlighted this support, and recognize these donors in productive ways. Partnerships are an avenue to assist commercial users by helping them get on board more quickly with FreeBSD, share their needs with the community, and facilitate collaboration with FreeBSD developers. We believe that building these relationships with commercial users will contribute to keeping FreeBSD relevant and help provide a sustainable and healthy ecosystem. You can check out our updated donor pages to see how we are acknowledging our Partners at https://www.FreeBSDfoundation.org/donors/. You can also find out more about this new program at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program= /. When I was in China last week, I had a chance to talk to a few companies about our new partnership program, and it definitely generated more interest in supporting our efforts. We are continuing to reach out to commercial users for help that will enable us to provide more outreach and support for FreeBSD. This includes funding more projects to improve FreeBSD, providing FreeBSD education and training, and recruiting more contributors to the Project. We can only provide the above support with your donations, and we need your help to connect us with your companies. Please consider notifying your organization about our new Partnership Program and helping to connect us with the appropriate contacts at your company. Your donations will help us: * Accelerate improvements and add new features to FreeBSD * Support release engineering efforts full-time * Create and provide FreeBSD educational and training material * Provide face-to-face opportunities for developers to work together * Improve and support FreeBSD infrastructure We need your support to continue improving FreeBSD. Q2 2017 Conference Recaps From sponsoring events to attending conferences, the Foundation continued its mission of advocacy in the second quarter of 2017. Over the past few weeks, members of the Foundation team represented the Project and the Foundation at events around the world. Below are just a few of the conference recaps. FOSSASIA 2017 (contributed by Philip Paeps) The Foundation kindly funded part of my travel from Tokyo to Singapore to attend FOSSASIA. I gave the "FreeBSD is not a Linux Distribution" presentation that Foundation board member George Neville-Neil wrote for Open Source China in December. My presentation was well-attended, and I got a lot of good questions from the primarily Linux-oriented audience. Read more at https://www.FreeBSDfoundation.org/blog/fossasia-2017-trip-report-philip-= paeps/. OSCON 2017 (contributed by Ed Maste) I represented the FreeBSD Foundation at OSCON 2017, which took place May 8-11, 2017, in Austin, TX: https://conferences.oreilly.com/oscon/oscon-tx . The Foundation booth was also staffed by FreeBSD committer Brad Davis and Doug Mcintire from Netgate. We met up Wednesday morning to set up the table. We were part of a "nonprofit pavilion" which consisted of eight or so tables, located between Open Camps and Operation Code. To help attract booth traffic, I brought a Raspberry Pi 3, with a small LCD display attached. As a demo, the Raspberry Pi showed a video of a Gource rendering of changes to the FreeBSD source tree over time (see example at https://www.youtube.com/watch?v=3DvZ8Sspua0Ks). Read more at https://www.FreeBSDfoundation.org/blog/conference-recap-oscon-2017/. Rootconf 2017 (contributed by Philip Paeps) In mid-May I presented at Rootconf 2017 in Bangalore. Rootconf is India's principal conference where systems and operations engineers share real-world knowledge about building reliable systems: https://rootconf.in/2017/. As always, it was interesting to hear the difficulties people face trying to run reliable systems on less reliable platforms. While many of the presentations were very Linux-specific and not very exciting to me, a couple of talks did catch my eye. I particularly enjoyed the talk by Aruna Sankaranarayanan (https://www.youtube.com/watch?v=3DXQJ7YhVoSWI&feature=3Dyoutu.be) explaining how Mapbox takes advantage of Amazon's "spot pricing" mechanism by spawning and shutting down machines at different price points to optimize for cost without compromising availability. Their spotswap https://github.com/mapbox/spotswap/ software has been released under a BSD license. It sounds as though it should be possible to port this to FreeBSD with minimal effort. Read more at https://www.FreeBSDfoundation.org/blog/rootconf-2017-trip-report-philip-= paeps/. BSDCan 2017/FreeBSD Developers Summit (contributed by Deb Goodkin) One of our initiatives is to assist in providing face-to-face knowledge sharing and development opportunities around the world. One way we do this is by sponsoring BSD-related conferences and FreeBSD Developer and Vendor Summits. We recently sponsored both BSDCan 2017 and the FreeBSD Developer and Vendor Summit in Ottawa, Ontario, Canada, which took place June 7-10, 2017. Many of our board and staff members attended the summit and conference to run tutorials, give presentations, lead sessions, work with developers, give demos, and share knowledge. In addition, this year we were pleased to bring our new University of Waterloo interns to the conference where they had the opportunity to demonstrate some of their projects at the Foundation table. Read more at https://www.FreeBSDfoundation.org/blog/conference-recap-bsdcan-2017Fr= eeBSD-developers-summit/. Open Travel Grant Applications The Foundation recognizes the importance of bringing members of the FreeBSD community face-to-face to both further development of the Project and spread the word about FreeBSD. Travel grants are available to community members who need assistance with travel expenses for attending conferences related to FreeBSD development and advocacy. Please note: the travel grant policy has been recently updated. Please carefully review it before submitting your application. More information about travel grants is available at: https://www.FreeBSDfoundation.org/what-we-do/grants/travel-grants/. FreeBSD Day was June 19! (contributed by Anne Dickison) June 19th was declared FreeBSD Day! Thank you to everyone who joined us in honoring the FreeBSD Project's pioneering legacy and continuing impact on technology. Find out more about FreeBSD Day and how we celebrated here at https://www.FreeBSDfoundation.org/blog/happy-FreeBSD-day/. Upcoming Events Find out about upcoming Foundation events at https://www.FreeBSDfoundation.org/news-and-events/upcoming-events/. FreeBSD Journal The May/June 2017 Issue of the FreeBSD Journal is now available. Don't miss articles on FreeBSD's Firewall Feast, CADETS: Blending Tracing and Security on FreeBSD, Toward Oblivious Sandboxing with Capsicum, and more. (https://www.FreeBSDfoundation.org/past-issues/security/) Did you miss the March/April issue? Check out articles on CFEngine, Puppet on FreeBSD, Vagrant, and more! (https://www.FreeBSDfoundation.org/past-issues/configuration-management/) As a recent addition of functionality, browser-based subscribers now have the ability to download and share PDFs of the articles! Sample Issue! If you've ever wanted to read through an entire issue of the FreeBSD Journal, now's your chance. Download the sample issue from https://mydigitalpublication.com/publication/?i=3D296880#{"issue_id":296= 880,"numpages":1,"page":1} and be sure to share with your friends and colleagues. Not a subscriber? Sign up today at https://www.FreeBSDfoundation.org/journal/. More information about the Foundation's doings and goings-on can be found in our own quarterly newsletter, linked above. __________________________________________________________________ The Postmaster Team Links The Postmaster Team URL: https://www.FreeBSD.org/administration.html#t-postmaster Contact: David Wolfskill Contact: Larry Rosenman Contact: Ryan Steinmetz Contact: Eygene Ryabinkin Contact: Remko Lodder Contact: Kurt Jaeger Postmaster handles the mail flow for the FreeBSD project. Clusteradm provides us with four jails: mailman, mailarchive, mx1, and mx2. In addition, there is some part of the setup running on freefall.FreeBSD.org. The system uses postfix, mailman, spamassassin, and some other tools from the ports tree to handle the mail flow. We use a very small, non-public Subversion repository for parts of the configuration. During Q2, Larry Rosenman, Kurt Jaeger, Eygene Ryabinkin, Remko Lodder and Ryan Steinmetz joined the Postmaster Team, and Florian Smeets left the Postmaster Team. Thanks to Florian for his long service in that role! David Wolfskill is planning to leave the role as soon as the new team members are settled. Vsevolod Stakhov plans to provide us with support to integrate rspamd into the setup, as well. The workload for the Postmaster Team is not high, but the complexity of the setup has its own demands. Open tasks: 1. We need to improve our internal documentation of workflows and processes. 2. We should consider adding some monitoring to provide quarterly numbers on the mail flow. __________________________________________________________________ Projects 64-bit Inode Numbers Links Phabricator Review URL: https://reviews.FreeBSD.org/D10439 Contact: Gleb Kurtsou Contact: Konstantin Belousov Contact: Kirk McKusick The 64-bit inode project was completed and merged into FreeBSD 12 on May 23, 2017. It extends the ino_t, dev_t, and nlink_t types to be 64-bit integers. It modifies the struct dirent layout to add a d_off field, increases the size of d_fileno to 64 bits, increases the size of d_namlen to 16 bits, and changes the required alignment of the structure. It increases the struct statfs f_mntfromname[] and f_mntonname[] array lengths from MNAMELEN to 1024. ABI breakage is mitigated by providing compatibility using versioned symbols, ingenious use of the existing padding in structures, and employing various other tricks. Unfortunately, not everything can be fixed, especially outside the base system. For instance, third-party APIs which pass struct stat as parameters are broken in backward- and forward-incompatible ways. The ABI for kinfo-consuming sysctl MIBs is changed in a backward-compatible way, but there is no general mechanism to handle other sysctl MIBS which return structures where the layout has changed. In our consideration, this breakage is either in management interfaces, where we usually allow ABI slippage, or is not important. The layout of struct xvnode changed, and no compatibility shims are provided. For struct xtty, the dev_t tty device member was reduced to be just uint32_t. It was decided that maintaining ABI compatability in this case is more useful than reporting a 64-bit dev_t value, for the sake of pstat. Updating note: strictly follow the instructions in UPDATING. Build and install the new kernel with the COMPAT_FREEBSD11 option enabled, then reboot, and only then install the new world. Credits: The 64-bit inode project, also known as ino64, started life many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick (mckusick) then picked up and updated the patch, and acted as a flag-waver. Feedback, suggestions, and discussions were carried out by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial ports investigation followed by an exp-run by Antoine Brodin (antoine). Essential and all-embracing testing was done by Peter Holm (pho). The heavy lifting of coordinating all these efforts and bringing the project to completion were done by Konstantin Belousov (kib). This project was sponsored by The FreeBSD Foundation (emaste, kib). __________________________________________________________________ Capability-Based Network Communication for Capsicum/CloudABI Links ARPC: GRPC-Like RPC Library That Supports File Descriptor Passing URL: https://github.com/NuxiNL/arpc Flower: A Label-Based Network Backplane URL: https://github.com/NuxiNL/flower Contact: Ed Schouten One of the weaknesses of Capsicum and CloudABI is that it is not easy to develop applications that need to make outgoing network connections, since system calls like connect() and sendto() are disabled. Though we can sometimes work around this by ensuring that the sandboxed process already possesses socket file descriptors on startup, this does not allow the destination process to be restarted, moved to a different network address, be load balanced, etc.. Coming up with a solution for this is quite important for me, as I am currently working on making CloudABI work on top of Kubernetes, Google's open source cluster management suite. The idea is that Kubernetes will schedule CloudABI processes instead of Docker containers. All of these CloudABI processes will have their dependencies on other services in the cluster injected explicitly, making internal communication very secure. All of this is intended to work on FreeBSD as well, of course! To solve this problem, I've been working on a daemon called Flower (read: flow-er) that allows software to register services and connect to them. Servers are identified by a set of labels with values (e.g., {datacenter: 'frankfurt', service: 'mysql'}). Clients can connect these servers by providing the corresponding label(s). Flower's security model is capability-based, just like Capsicum. The ability to bind and connect can be limited by permanently constraining labels to certain values. Flower has been designed not to act as a proxy. It does not copy any data. It merely forwards existing socket file descriptors or creates UNIX socket pairs and hands these out to its clients and servers. To realize this, processes communicate with Flower using an RPC library called ARPC. ARPC is a very simple clone of Google's GRPC, with the special feature that messages (Protobufs) can have file descriptors attached. This project was sponsored by Nuxi, the Netherlands. Open tasks: 1. Finish implementing the Flower code. 2. Integrate Flower with the Kubernetes/CloudABI runtime. 3. Release the Kubernetes/CloudABI runtime as open source software. __________________________________________________________________ Ceph on FreeBSD Links Ceph Main Site URL: http://ceph.com Main Repository URL: https://github.com/ceph/ceph My FreeBSD Fork URL: https://github.com/wjwithagen/ceph Contact: Willem Jan Withagen Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability. * Object Storage Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface that is compatible with applications written for S3 and Swift. * Block Storage Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. * File System Ceph provides a POSIX-compliant network file system that aims for high performance, large data storage, and maximum compatibility with legacy applications. I started looking into Ceph because the HAST solution with CARP and ggate did not really do what I was looking for. I aim to run a Ceph storage cluster of storage nodes that are running ZFS, with user workstations running bhyve on RBD disks that are stored in Ceph. Compiling for FreeBSD will now build most of the tools available in Ceph. The most important changes since the last report are: * Ceph has released release candidate v12.1.0 (aka Luminous); the corresponding packaging is sitting in my tree waiting for Luminous to be actually released. * ceph-fuse works, and allows mounting of cephfs filesystems. The speed is not impressive, but it does work. * rbd-ggate is available to create a Ceph rbd backed device. rbd-ggate was submitted by Mykola Golub. It works in a rather simple fashion: once a cluster is functioning, rbd import and rbd-ggate map are used to create ggate-like devices backed by the Ceph cluster. Other improvements since the previous report: * Some bugs in the init-ceph code (needed for rc.d) are being fixed. * RBD and rados are functioning. * The needed compatability code was written so that FreeBSD and Linux daemons can operate together in a single cluster. * More of the awkward dependancies on Linux-isms are deleted -- only /bin/bash is there to stay. The next forthcoming official release of Ceph is called Luminous (v12.1.0). As soon as it is available from upstream, a port will be provided for FreeBSD. To get things running on a FreeBSD system, run pkg install net/ceph-devel or clone https://github.com/wjwithagen/ceph, check out the wip.freebsd.201707 branch, and build manually by running ./do_freebsd.sh in the checkout root. Parts not (yet) included: * KRBD -- but rbd-ggate is usable in its stead. * BlueStore -- FreeBSD and Linux have different AIO APIs, and that incompatibility needs to be resolved somehow. Additionally, there is discussion in FreeBSD about aio_cancel not working for all device types. Open tasks: 1. Run integration tests to see if the FreeBSD daemons will work with a Linux Ceph platform. 2. Investigate the keystore, which can be embedded in the kernel on Linux and currently prevents building Cephfs and some other parts. The first question is whether it is really required, or if only KRBD requires it. 3. Scheduler information is not used at the moment, because the schedulers work rather differently between Linux and FreeBSD. But at a certain point in time, this will need some attention (in src/common/Thread.cc). 4. Improve the FreeBSD init scripts in the Ceph stack, both for testing purposes and for running Ceph on production machines. Work on ceph-disk and ceph-deploy to make it more FreeBSD- and ZFS-compatible. 5. Build a test cluster and start running some of the teuthology integration tests on it. Teuthology wants to build its own libvirt, and that does not quite work with all the packages FreeBSD already has in place. There are many details to work out here. 6. Design a virtual disk implementation that can be used with bhyve and attached to an RBD image. __________________________________________________________________ DTS Updates Contact: Emmanuel Vadot DTS (Device Tree Source) files provide a human-readable source description of the hardware resources for a given computer system (such as ARM- or MIPS-based embedded boards). The DTS source representation must be compiled into a binary format in order to be linked into the kernel and used to locate devices at runtime. The DTS files in FreeBSD were updated to match the versions from Linux 4.11, to represent more modern devices and provide more accurate representations. __________________________________________________________________ Kernel Coda revival Links GitHub Repository URL: https://github.com/trasz/FreeBSD/tree/coda Contact: Edward Tomasz Napiera=C5=82a Coda is a distributed file system developed as a research project at Carnegie Mellon University, descended from a older version of the Andrew File System. It got dropped from FreeBSD some five years ago, due to not having been adopted for a MPSAFE world. The focus for this current project is to bring it back into sufficiently workable shape that it could return to the kernel. It is currently in a working condition. Work is underway to test it better, fix whatever issues are found, and commit it to 12-CURRENT. This project was sponsored by Chalmers University of Technology. Open tasks: 1. Additional testing. 2. Update the userspace components (net/coda_client and net/coda_server). __________________________________________________________________ FreeBSD Driver for the Annapurna Labs ENA Links Enhanced Networking Guide URL: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networ= king.html Contact: Marcin Wojtas Contact: Michal/ Krawczyk The ENA (Elastic Network Adapter) is a 25G SmartNIC developed by Annapurna Labs and is based on a custom ARMv8 chip. This is a high-performance networking card available in the AWS offerings. It introduces enhancements in network utilization scalability on EC2 machines under the control of various operating systems, in particular FreeBSD. The goal of FreeBSD enablement is to provide top performance and a wide range of monitoring and management features such as: * multiple queue modes * hardware offloads (rx and tx checksum) * an admin queue * asynchronous notifications * robust hardware access * a scalable number of MSI-X vectors * hardware counters * watchdog mechanism * LRO * RSS The driver is available in the kernel source tree as of r318647. This project was sponsored by Annapurna Labs -- an Amazon company. Open tasks: 1. Add RSS configuration from userspace (via sysctls). 2. Add support for LLQ mechanisms. __________________________________________________________________ Intel 10G Driver Update Links Commit Adding X553 ix/ixv Support URL: https://reviews.FreeBSD.org/D11232 Contact: Chris Galazka Contact: Jeb Cramer The ix and ixv network interface drivers support a variety of Intel network interfaces, with line speeds at 10 Gbit/second. This quarter, the drivers gained support for the X553 network interface, which is found on System-on-a-Chip devices based on the Denverton platform. This update should allow FreeBSD to be more useful on a new class of hardware platform. Work is also underway to convert these drivers to use the iflib network driver library, which should ease future maintenance of the drivers, as well as the network subsystem as a whole. __________________________________________________________________ pNFS Server Plan B Links Testing Instructions URL: http://people.FreeBSD.org/~rmacklem/pnfs-planb-setup.txt Contact: Rick Macklem Parallel NFS (pNFS) is an extension to the NFSv4 protocol that allows for file accesses within a single logical mount to be performed against multiple file servers, with the potential for data access to occur in parallel. The pNFS "layout" in use specifies how the division occurs, with metadata operations occurring against the main server, and bulk data operations (read/write/setattr/etc.) occurring via a layout-specific scheme between the client and the data servers. My first attempt at a pNFS server using GlusterFS was a dud. It worked, but performance was so poor that it was not usable. This attempt that I call "Plan B", only uses FreeBSD, with one FreeBSD server handling the metadata operations and multiple FreeBSD servers configured to serve data, is now ready for third-party testing. If testing by third parties goes well, I anticipate the code will be merged into FreeBSD head in time for FreeBSD 12. Fairly recent FreeBSD or Linux systems should be usable as pNFS clients for testing. This server supports the File Layout, which is supported by both of these clients. There is no support for the Flex Files Layout or mirroring at this time. I hope to use the Flex Files Layout to add mirroring support over the next year or so. Striping is not supported, and I have no plans for implementing this at the moment. The patched FreeBSD sources may now be accessed for testing via either Subversion or download of a gzipped tarball. They consist of a patched kernel and nfsd and can be used on any FreeBSD 11 or later system. Open tasks: 1. Testing by others will be needed, now that the code is available. __________________________________________________________________ Architectures FreeBSD on Marvell Armada38x Contact: Marcin Wojtas Contact: Zbigniew Bodek Work proceeds to finalize the process of bringing support for the Marvell Armada38x platform into FreeBSD head. The most important parts of the recent effort are: * Add the network driver (NETA) * Enable coherent busdma operation for all ARMv7 SoCs * Add various low-level optimizations, such as L1 cache prefetch and MBUS quirks * Enable PL310 L2 cache controller * Add SDHCI support * Fixes for the e6000sw driver and a rework of its PHY handling * Support multi-port PCIe operation * Various fixes and enhancements of the common Marvell code * Fix and enable support for performance counters (HWPMC) This project was sponsored by Stormshield, Semihalf, and Netgate. __________________________________________________________________ FreeBSD/arm64 Links FreeBSD arm64 Wiki Page URL: https://wiki.FreeBSD.org/arm64 Contact: Andrew Turner Support for the Privilege Access Never (PAN) feature was added. This stops the kernel from accessing userspace memory, except through specific instructions. This helps security by only allowing access to userspace via the correct accessor functions. This is enabled on all supported CPUs that implement ARMv8.1 or later. The pmap code now supports the Unprivileged execute-never (UXN) and Privileged execute-never (PXN) bits in the page tables. These bits stop userspace and the kernel, respectively, from executing instructions on any marked page. The performance of the pmap layer has been improved. Many of the cache handling function calls have been removed. Some were needed early on to work around other bugs that have now been fixed. The removal of these calls has led to a large performance improvement. The kernel now uses crc32c instructions where appropriate. These are an optional set of instructions to perform crc32c checksumming quickly without using a lookup table.c The VM_MEMATTR_WRITE_THROUGH memory attribute is now supported. This is used to allocate memory for the framebuffer. Previously, the kernel would use cached memory; however, this leads to visual artifacts. The write-through flag fixes these by writing data out to RAM. The default linker on arm64 is now lld. This means that FreeBSD is able to build itself with just the components in the base system, a big milestone! __________________________________________________________________ Userland Programs DTC Contact: Emmanuel Vadot The in-tree DTC (Device Tree Compiler) was switched to use the BSD-licensed version by default. (The previous default DTC is licensed under the GPL.) The current version supports overlays and is able to compile every DTS (Device Tree Source) used by the FreeBSD arm releases. The ports GPL version was updated to the latest release (1.4.4). The in-tree GPL version is still present but the goal is to remove it before FreeBSD 12.0. __________________________________________________________________ Using LLVM's LLD Linker as FreeBSD's System Linker Links FreeBSD lld Wiki Page URL: https://wiki.FreeBSD.org/LLD FreeBSD/LLD Tracking PR (LLVM Bugzilla) URL: http://llvm.org/pr23214 Exp-Run Request Using lld as /usr/bin/ld URL: https://bugs.FreeBSD.org/214864 Contact: Rafael Esp=C3=ADndola Contact: Ed Maste LLD is the linker in the LLVM family of projects. It is a high-performance linker that supports the ELF, COFF and Mach-O object formats. It is broadly compatible with the common linkers used for each file format. For ELF this is the GNU Binary File Descriptor (BFD) ld and GNU gold. However, LLD's authors are not constrained by strict compatibility where it would hamper performance or desired functionality. LLD is now used as the default system linker for FreeBSD/arm64 and can link a working kernel, kernel modules, and userland for FreeBSD/amd64. LLD can also link a working kernel and modules (but not userland) for FreeBSD/arm and FreeBSD/i386. Work is ongoing to address ports that do not build with LLD as the system linker (either by fixing the port, or configuring the port to be linked by GNU ld). For FreeBSD 12.0 we expect to use LLD as the system linker for the same set of architectures that use Clang by default: 32- and 64-bit arm and x86. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Fix libtool to detect LLD and pass the same command line arguments as for GNU ld and gold. 2. Investigate the remaining amd64 and arm64 port build failures. 3. Investigate and improve LLD on i386 and arm, before the creation of the stable/12 branch. 4. Investigate and improve LLD on all other architectures. 5. Extensive testing. __________________________________________________________________ Ports A New USES Macro for Porting Cargo-Based Rust Applications Links Rust Homepage URL: https://www.rust-lang.org/ Cargo Homepage URL: https://crates.io/ Alacritty Homepage URL: https://github.com/jwilm/alacritty Exa Homepage URL: https://the.exa.website/ Ripgrep Homepage URL: https://github.com/BurntSushi/ripgrep Short Screencast About How to Use the USES=3Dcargo Macro URL: https://asciinema.org/a/SM2sOLi6iBUOmGWrxn5W1QI8U Contact: Tobias Kortkamp Support in the Ports Collection for applications written in the Rust programming language that use Rust's package manager Cargo was added, via a new USES=3Dcargo setting. The work is based on the cargo module from the OpenBSD ports tree. This should significantly ease the porting of Rust applications, as previously porters had to create their own tarball of the application's dependencies or find other manual ways of bringing them in. Several new ports were added that use it, for example: * Alacritty, a GPU-accelerated terminal emulator * Exa, a modern replacement for ls * Ripgrep, a line-oriented search tool that combines the usability of The Silver Searcher with the raw speed of GNU grep Open tasks: 1. Add documentation for the new feature. __________________________________________________________________ GCC (GNU Compiler Collection) Links GCC Homepage URL: https://gcc.gnu.org Issue Tracker Entry for the Update to GCC 6 URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D219275 GCC 5 Changelog URL: https://gcc.gnu.org/gcc-5/changes.html GCC 5 Porting Issues URL: https://gcc.gnu.org/gcc-5/porting_to.html Contact: Gerald Pfeifer Contact: Andreas Tobler The default version of GCC in the Ports Collection (the one requested by USE_GCC=3Dyes and various USES=3Dcompiler invocations) has been updat= ed from GCC 4.9.4 to GCC 5.4. This new major version brings many new capabilities and improvements, as well as some changes that may require adjustments. The latter category includes many new compiler warnings, significant improvements to inter-procedural optimizations, and link-time optimization. The default mode for C is now -std=3Dgnu11 instead of -std=3Dgnu89. The = C++ front end has full C++14 language support, including C++14 variable templates, C++14 aggregates with non-static data member initializers, C++14 extended constexpr, and more. The Standard C++ Library (libstdc++) has full C++11 support and experimental full C++14 support. It uses a new ABI by default. The lang/gcc port now is a meta-port that pulls in the respective lang/gccX port (based on the setting of $GCC_DEFAULT) and defines gcc, g++, and gfortran as symlinks to the respective versioned binaries. This is the end of a long journey establishing this infrastructure, which is now similar that used by the python ports, for example. Having the new infrastructure makes upgrading the default, as well as locally adjusting the default version, a lot easier. gcc8-devel has been added, and armv6hf support removed, and we made adjustments for newer versions of FreeBSD. Also of note are various cleanups and changes to improve the robustness of our packages and the addition of support for aarch64 to many ports. Thanks to dim@, jbeich@, tijl@, mat@, miwi@, linimon@ for assisting with this work. Open tasks: 1. The update of the default version of GCC from GCC 5.4 to GCC 6.4 is stalled, unfortunately. The work on the GCC and insfrastructure sides is complete, but unfortunately there are a number of broken ports that need to be adjusted/fixed. Any help is very appreciated; see PR 219275 for details. __________________________________________________________________ GNOME on FreeBSD Links FreeBSD GNOME Website URL: http://www.FreeBSD.org/gnome Development Repository URL: https://github.com/FreeBSD/FreeBSD-ports-gnome Upstream Build Bot URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD USE_GNOME Porter's Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook= /using-gnome.html Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. After a period of not much activity, this quarter we started a little experiment in how we merge ports from the development repo to the FreeBSD Ports Collection. Instead of merging everything in one big commit, we have been updating the GNOME ports one at a time or in small groups. For example, the GTK+ stack and the Evolution Suite were updated as groups, and all the gnome-games components were done in one commit. It might be a bit more work preparing and testing the updates, but on the plus side, it easy to keep track of what is going on, and allows us to pay attention to the details. It should also make it easier to commit smaller changes. This quarter started with the update of GTK+ 3 to 3.22.15, and the underlying libraries to their latest stable versions. After the GTK+ update, work started on getting newer versions of other GNOME applications updated. The webkit2-gtk3 port was first updated to the 2.14 series and later to 2.16.3, which is the latest stable version. This step was needed because 2.16 couldn't be built on FreeBSD 10.3 without some required framework changes. harfbuzz-icu was split off from the main harfbuzz port. This drops the heavy icu dependency from the main harfbuzz port. A longstanding GLib/gio bug was fixed that had previously caused crashes of gnome-shell and other applications when share/applications was modified, as happens on pkg install or deinstall. Many of these updates are based on work previously done in the Gnome development branch by Ruslan Makhmatkhanov, Gustau Perez and Koop Mast. Open tasks: 1. Porting of Mutter/Gnome-shell/GDM 3.24 is complete. Unfortunately, GDM is blocking the update because of a "handoff" bug to the session after login. 2. Fix the printer submenu in gnome-control-center. As a workaround, system-config-printer can be used to configure printers. 3. MATE 1.18 is being QA tested and should arrive in early July. __________________________________________________________________ KDE on FreeBSD Links KDE on FreeBSD Website URL: https://FreeBSD.kde.org/ KDE Ports Staging Area URL: https://FreeBSD.kde.org/area51.php KDE on FreeBSD Wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD Mailing List URL: https://mail.kde.org/mailman/listinfo/kde-FreeBSD Development Repository URL: https://github.com/FreeBSD/FreeBSD-ports-kde KDE's Continous Integration Dashboard URL: https://build.kde.org Blog Post on Using the Ninja CMake Generator URL: https://euroquis.nl/bobulate/?p=3D1600 Contact: KDE on FreeBSD Team The KDE on FreeBSD team focuses on packaging KDE and Qt, and making sure that their experience on FreeBSD is as good as possible. This quarter, in addition to the regular updates to the KDE, Qt, and related ports, there have also been some changes behind the scenes: our development repository has moved to GitHub, and FreeBSD is now part of KDE's official continuous integration (CI infrastructure). After the X.Org and GNOME ports teams, the KDE on FreeBSD team has moved its development repository to GitHub. This should make it easier for others to collaborate with us via pull requests, and by basing all our changes on top of the official ports tree we also hope this reduces the amount of conflicts and churn we need to deal with when landing big updates across the tree. We would like to thank iXsystems for hosting and supporting our area51 Subversion repository for many years. FreeBSD has finally joined KDE's CI (Continuous Integration) system as a tier-1 platform. KDE CI builds all the KDE sources -- 70 frameworks, the KDE Plasma Desktop and a plethora of KDE Applications -- continuously, straight from KDE's git repositories. There is strong commitment from upstream and the downstream KDE-FreeBSD team to reduce the amount of patching in the KDE ports to as little as possible. The first effects are being felt in expanding the set of unit tests to include FreeBSD-specific situations, and in extending Qt to handle FreeBSD filesystems better. In addition to the KDE sysadmins, we would also like to extend our thanks to Adriaan de Groot, who is both a KDE committer and part of our KDE on FreeBSD team, for spearheading these efforts. The following big updates landed in the ports tree this quarter: * CMake was updated to 3.8.0 and 3.8.2 * KDE Frameworks was updated to 5.33, 5.34 and 5.35 * The Calligra office suite was updated to 3.0.1, the first release in the ports tree to be based on KDE Frameworks 5, and the latest stable release upstream * The Konversation IRC client was updated to 1.7.2, the latest upstream release and the first ports version based on KDE Frameworks 5 * KchmViewer was updated to 7.7, which is based on KDE Frameworks 5 * LabPlot was updated to 2.3.0 and 2.4.0, and is now based on KDE Frameworks 5 * QtCreator was upated to 4.2.2 and subsequently to 4.3.0 * py-sip was updated to 4.19.2, PyQt4 to 4.12 and PyQt5 to 5.7.1 * Several fixes for ARMv6 landed in the Qt4 and Qt5 ports -- thanks to Mika=C3=ABl Urankar After several review rounds and exp-runs, Tobias Berner (tcberner@) finally made the Ninja generator the default for CMake-based ports, so that devel/ninja is used instead of (g)make in most cases. This should make most builds faster, even if only by a small margin. Adriaan de Groot also wrote a blog post about the change. __________________________________________________________________ New Port: FRRouting Links FRRouting Home Page URL: https://frrouting.org/ Contact: Olivier Cochard-Labb=C3=A9 FRRouting (FRR), a Quagga fork, is an IP routing protocol suite for Linux and Unix platforms which includes protocol daemons for BGP, IS-IS, OSPF and RIP (LPD and PIM support need to be fixed on FreeBSD). FRR is a Linux Foundation Collaborative Project with contributors including 6WIND, Architecture Technology Corporation, Big Switch Networks, Cumulus Networks, LabN Consulting, NetDEF (OpenSourceRouting), Orange, Volta Networks, and other companies. This project was sponsored by Orange. __________________________________________________________________ PHP Ports: Help Improving QA Links My Patreon Page URL: https://www.patreon.com/TorstenZuehlsdorff Contact: Torsten Z=C3=BChlsdorff As maintainer of the PHP ports, I first want to thank you all for the great feedback and patches I receive, in many forms. You keep my life interesting! In the past few months I learned a lot about various configurations, settings and bugs. Also, sadly, there are always PRs, patches and emails left unanswered, because of missing time on my side. I want to improve the situation by adding more automatic QA testing, but I need help to do so. Please send me your non-standard PHP-configurations or describe your exotic setups! These can be as simple as changed default versions, like LibreSSL instead of OpenSSL or the GCC version used for compiling. I, for example, always use another PostgreSQL-version than the default (and always PHP 7.1). Of course, this also covers port options set in an non-default way or setups that change variables to allow for multiple PHP installations, etc.. I plan to test on all supported FreeBSD versions, so you only need to mention if you are using an unsupported version. Note: Since PHP 7.2 is coming (hopefully on schedule), I will test PHP 7.2 from the onset with all the provided configurations, too. Open tasks: 1. Document the various configurations to be tested. 2. Setup the automatic QA infrastructure. __________________________________________________________________ Rust Links Wiki Portal URL: https://wiki.FreeBSD.org/Rust Guide to Bootstrap Rust on FreeBSD URL: https://gist.github.com/dumbbell/b587da50ef014078da9e732a4331ebad Bug Report to Track Progress on Bootstrapping URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D216143 Upstream Discussion of API/ABI-Breaking Changes URL: https://internals.rust-lang.org/t/pre-rfc-target-extension-dealing= -with-breaking-changes-at-os-level/5289 Contact: FreeBSD Rust team Rust was updated to 1.18.0 and Cargo to 0.19.0, the latest versions at the time of this writing. lang/rust was enabled on FreeBSD/aarch64 and work has continued on devel/cargo to achieve the same. We are also making slow progress to add support for even more platforms. Discussion has started upstream to support API/ABI-breaking changes between major releases of operating systems. For instance, this is required to be able to target both FreeBSD 11.x and 12.x, which have ABI changes involving important structures. Once support is added upstream, it will be possible to target a specific ABI and do cross-compilation. lang/rust-nightly was marked as broken for now. We need to revisit how the port is built so we can use the x.py script as recommended by upstream. Tobias Kortkamp (tobik@) created the USES=3Dcargo setting to make it easy to add Rust applications to the Ports Collection. This is further detailed in a separate entry in this quarterly status report. The compiler, rustc, is crashing sometimes when there is a compilation error. Therefore, there is a bit of work to do to improve its stability. There is some code duplication between the lang/rust* and devel/cargo Makefiles. These all deserve a bit of cleanup, and it might be useful to create a USES=3Drust Makefile helper. Open tasks: 1. Bootstrap Rust on more platforms. 2. Investigate compiler crashes. 3. Investigate how to speed up lang/rust* compilation times. __________________________________________________________________ sndio Support in the FreeBSD Ports Collection Links Sndio Homepage URL: http://www.sndio.org Sndio Paper URL: https://www.openbsd.org/papers/asiabsdcon2010_sndio.pdf Comprehensive and Biased Comparison of OpenBSD and FreeBSD (Section 17) URL: https://www.bsdfrog.org/pub/events/my_bsd_sucks_less_than_yours-As= iaBSDCon2017-paper.pdf Contact: Tobias Kortkamp sndio is a small audio and MIDI framework that is part of the OpenBSD project. It provides a lightweight audio and MIDI server, sndiod. It currently supports OpenBSD, FreeBSD, DragonFly BSD, and Linux. The porting effort to FreeBSD and OSS started last year and the sndio backend support in the FreeBSD Ports Collection can now be considered good enough for daily use. Sndio offers network transparency through sndiod, which provides an easy way to share your audio devices with other machines/VMs/jails on your network. However, applications and libraries need to support playing and recording through it. To that end, I submitted several patches to various ports over the course of the last year. Here's a short selection of ports that now support sndio in the FreeBSD Ports Collection: * Most games, via audio/openal-soft, devel/sdl12, and devel/sdl20. * GStreamer-based applications and WebKit-based browsers through two new GStreamer plugins (audio/gstreamer1-plugins-sndio and audio/gstreamer-plugins-sndio). * Firefox, Firefox ESR, Seamonkey, Chromium, and Iridium. The browsers currently lack or have a non-functional OSS backend. Sndio support provides a BSD-native alternative to the ALSA and PulseAudio backends. * Video players like VLC, Totem, mpv, mplayer, etc.. * Audio players like Clementine, cmus, mpd, mpg123, siren, xmp, etc.. * SoX. * Shairport Sync, through a newly implemented backend. * JACK. * PulseAudio, through audio/pulseaudio-module-sndio. Open tasks: 1. Commit a backport of Kodi's new sndio backend to the Ports Collection. 2. If you maintain or use an audio-related port, consider checking whether it includes an sndio backend, and adding an SNDIO option. Thanks to the OpenBSD developers, several open-source projects already include one, so adding it might be very easy to do. __________________________________________________________________ TensorFlow Links TensorFlow PR URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D219609 Phabricator Review URL: https://reviews.FreeBSD.org/D11194 Prebuilt Packages URL: https://github.com/amutu/tf-FreeBSD-pkg TensorFlow Upstream URL: https://www.tensorflow.org Contact: Jov As described on its website, "TensorFlow(TM) is an open source software library for numerical computation using data flow graphs. Nodes in the graph represent mathematical operations, while the graph edges represent the multidimensional data arrays (tensors) communicated between them. The flexible architecture allows you to deploy computation to one or more CPUs or GPUs in a desktop, server, or mobile device with a single API. TensorFlow was originally developed by researchers and engineers working on the Google Brain Team within Google's Machine Intelligence research organization for the purposes of conducting machine learning and deep neural networks research, but the system is general enough to be applicable in a wide variety of other domains as well." TensorFlow now is the most popular platform/library for machine learning and AI. There are official binaries for Linux, Mac, Windows, and Android, but no official support for FreeBSD. For the last several months, I have done some work to make TensorFlow available on FreeBSD. Some notable items include: * bazel was patched to not depend on /proc at build time. bazel is a build tool made by Google. It uses /proc to get path-to-self when building C++ code, but mounting /proc is usually not allowed when building as an unprivileged user. * TensorFlow can now be built on FreeBSD 10.x by using clang38 as the default bazel cross-build tool. * Patch the bazel workspace files to allow TensorFlow to be built using offline third-party dependencies. This work is needed because the FreeBSD Ports framework does not allow network access except during the fetch stage. * Fix the build on FreeBSD i386. * Make TensorFlow build with either Python 2 or Python 3. * Update to the latest version, which is tensorflow-1.2.0. TensorFlow can now be run on FreeBSD in CPU-only mode. Some functional tests have been performed on some combinations of FreeBSD 10.3-RELEASE and 11.0-RELEASE, amd64 and i386, and Python 2.7 and Python 3.6. This port would not be possible without substantial assistance from bapt@, lwhsu@, mat@, and koobs@ -- thank you for your advice, review, and help! You are very nice and I learned a lot about FreeBSD and the Ports framework from you. Open tasks: 1. Review, test, comment, and most importantly, commit to the Ports Collection. 2. Fix OpenCL (GPU acceleration) support on FreeBSD. 3. Port tensorflow-serving, which is a flexible, high-performance serving system for machine learning models produced by TensorFlow. 4. Set up a CI for TensorFlow on FreeBSD and give early notice to upstream when they break TensorFlow on FreeBSD. __________________________________________________________________ Updating Port Metadata for non-x86 Architectures Links aarch64 Poudriere Machine URL: http://thunderx1.nyi.FreeBSD.org/jail.html?mastername=3D110arm64-d= efault armv6 Poudriere Machine URL: http://beefy8.nyi.FreeBSD.org/jail.html?mastername=3Dhead-armv6-de= fault Contact: Mark Linimon I have been analyzing the error logs from ports builds for all non-x86 architectures, including both the logs published on the package build cluster and also other builds of powerpc64 and sparc64. From this analysis, I have marked almost all the failing ports as either BROKEN or NOT_FOR/ONLY_FOR, as appropriate. The intent of this work is not to make life harder for anyone, but rather, in fact, the opposite. With these definitions in place, it is possible to scan the poudriere bulk build output (the "Ignored ports" portion, in particular) and see quickly what ports are failing to build and why. Previously, finding the exact reason why a build failed needed some research (portsmon only analyzes failure messages on amd64). Additionally, it is extremely difficult to work through several hundred logs that simply say "failed to compile", "failed to link", and so forth. This is part of an effort to identify where we need further work to bring sufficient Ports Collection support to, e.g., armv6 and aarch64 to bring them closer to true Tier-1 status. To further facilitate locating patterns in the Poudriere output, I have begun reworking some existing BROKEN/NOT_FOR/ONLY_FOR messages so that they will sort more easily. This includes sorting the order in which architectures appear in the lists. Many people have been doing great work on fixing the individual ports. I hope that my work makes their jobs somewhat easier. __________________________________________________________________ Xfce on FreeBSD Links FreeBSD Xfce Project URL: https://wiki.FreeBSD.org/Xfce Ports Development Repository URL: https://www.assembla.com/spaces/xfce4/subversion/source Contact: FreeBSD Xfce Team Contact: Olivier Duchateau Xfce is a free software desktop environment for Unix and Unix-like platforms such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. During this quarter, we have kept these applications up-to-date: * audio/xfce4-pulseaudio-plugin (0.2.5, PR219357) * deskutils/xfce4-tumbler (0.1.32, PR219848) * deskutils/xfce4-xkb-plugin (0.8.0, PR220071) * sysutils/garcon (0.6.1, PR219928, and PR219334 for Mk/Uses/xfce.mk) * textproc/xfce4-dict-plugin (0.8.0, PR220266) * x11/xfce4-terminal (0.8.5.1, PR219312) * x11/xfce4-whiskermenu-plugin (1.7.2, PR219347) * x11-wm/xfce4-desktop (4.12.4, PR220290) We have created a new Subversion tag (4.13) in order to follow the unstable releases. The separate tag was necessary in order to support changes in the USES=3Dxfce infrastucture, and due to some incompatible changes to the xfconf API. Ports following the unstable release are: * deskutils/xfce4-tumbler (0.1.92.1) * multimedia/xfce4-parole (0.9.2) * sysutils/xfce4-settings (4.13.1) * x11/libexo (0.11.3) * x11/libxfce4menu (4.13.2) * x11/libxfce4util (4.13.1) * x11/xfce4-conf (4.13.2) * x11/xfce4-dashboard (0.7.2) * x11/xfce4-screenshooter (1.9.1) * x11/xfce4-whiskermenu-plugin (2.1.2) * x11-wm/xfce4-desktop (4.13.1) * x11-wm/xfce4-panel (4.13.0) * x11-wm/xfce4-session (4.13.0) * x11-wm/xfce4-wm (4.13.0) Open tasks: 1. Make the transition to Gtk3 smoother for end users. __________________________________________________________________ Documentation Absolute FreeBSD, 3rd Edition Links Status as of 30 June URL: https://blather.michaelwlucas.com/archives/2972 Second Edition URL: https://www.michaelwlucas.com/os/af2e Trivial Updates URL: https://twitter.com/search?q=3D%23af3e&src=3Dtypd Contact: Michael Lucas I'm working on a third edition of Absolute FreeBSD. This will be a nearly complete rewrite, thanks to the addition of little details like ZFS, GPT, dma, GELI, new boot procedures, disk labeling, pkg(8), blacklistd, jails, etc.. My current (delusional) plan is to have a first draft finished by the end of October 2017, so we can have print copies for BSDCan 2018. Open tasks: 1. Write the remaining 75% of the book. __________________________________________________________________ Doc Version Strings Improved by Their Absence Links FreeBSD Documentation Project Primer URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Get Version Information from Subversion Metadata URL: https://svnweb.freebsd.org/doc/head/share/mk/doc.docbook.mk?r1=3D5= 0233&r2=3D50232&pathrev=3D50233 Contact: Warren Block In retrospect, our $FreeBSD$ strings in source files are kind of weird, like a vestigial tail. The version control system stores all of that information in metadata. Yet here we are, not only allowing the version control system to alter our source files on every commit, but forcing it to do so. The reason for doing so is that the previous version control system did it. Really. Version control strings are a headache for translators using the new PO toolchain. It is an ever-changing string that offers nothing to the translation, yet can cause conflicts with earlier versions of itself. We also had complaints about how the Handbook was always months out of date. It was not, of course... but looking at just the version string in the main, rarely-changing book.xml file gave that impression. We fixed that problem last year, so the build system checks all the source files for the latest commit, but it seems easier to not have to fix the problem at all. Of course, that was really only one aspect of an ongoing problem. Our documentation build system was checking the version string in the source file, not the metadata. In 1973, metadata, like cars not composed chiefly of rust, had not yet been invented. I modified the build system to extract the information from the metadata (and noted, with some surprise, that this is a task at which Git is much better than Subversion). The next step was to remove the $FreeBSD$ strings from the source files and remove the FreeBSD=3D%H property that forces Subversion, against its better judgement, to substitute text in the actual contents of the file. The version information is not lost. It lives in the metadata, so retrieving it is as simple as svn info -- it does not need to be in the source at all. However, as with anything that touches code or processes which have not been touched in living memory, there was some debate over this. At that point, I offered to remove the version strings from the FreeBSD Documentation Project Primer book as a test. The change allowed the zh_TW translation team to turn off the FreeBSD=3D%H property on their translation and continue their work without fighting with the version strings. Rendered versions of the book still display the name of the last committer and the date and revision number of the last commit, but all of that information comes from metadata. As such, it is also more likely to be correct. Since the change, there have not been any complaints, at least not to me. In fairness, the removal of version strings from the FDP Primer alone is a small change in a tiny corner of the project. Looking at it another way, it might be that some things that seem to be necessary are more about the comfort of familiarity than actual utility. At present, this is strictly a change to the documentation build toolchain and a single documentation book. However, there do not appear to be any reason why it could not be extended to the rest of the documents. It might even serve as tiny test of whether the expansion of $FreeBSD$ tags is needed throughout the rest of the FreeBSD tree. __________________________________________________________________ New Xen Handbook Section Links Handbook Section About FreeBSD as a Xen Host URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/virtual= ization-host-xen.html Original Phabricator Review URL: https://reviews.freebsd.org/D10774 Contact: Benedict Reuschling FreeBSD supports the Xen hypervisor, with DomU (guest) support since FreeBSD 8.0 and Dom0 (host) available since FreeBSD 11.0. The FreeBSD Handbook was lacking instructions on how to run a Xen host and VMs. The steps were outlined in the FreeBSD wiki, but needed some extra bits of text from the upstream Xen wiki in order to form a complete guide. The new handbook section briefly explains what Xen is, how it differs from other hypervisors, and what features are currently available in FreeBSD. It then goes on to describe how to set up the Dom0, as well as detailing the guest VM support known as DomU. Reviewers Nikolai Lifanov, Roger Pau Monn=C3=A9, and Warren Block provid= ed valuable feedback on the initial version in Phabricator. Additional corrections were made by Bj=C3=B6rn Heidotting while translating the sec= tion into German. Open tasks: 1. More options for the Dom0 and DomU could be provided. 2. People should test these instructions on their hardware and provide feedback. This would also help us get better testing of the Xen port for FreeBSD. __________________________________________________________________ Miscellaneous BSD Meetups at Rennes (France) Links First Event URL: https://www.meetup.com/fr-FR/Meetup-BSD-Rennes/events/239248155/ Second Event URL: https://www.meetup.com/fr-FR/Meetup-BSD-Rennes/events/240202297/ Contact: Mathieu Kerjouan Two meetups dedicated to BSD systems were held in Rennes, France. The first one was hosted in the OVH office in Rennes and included presentations on multiple subjects: the non-technical history of FreeNAS (presented by olivier@), how OVH is using ZFS, an introduction to jails, and a use case for BGP/bird on FreeBSD. The second meetup, also hosted in the OVH office, presented these subjects: how to create a FreeBSD port (presented by jadawin@), how OVH is using Finite State Machines for managing their storage system, network high-availability with FreeBSD, and a jail tutorial by means of a demonstration running 200 OSPF (using net/bird) routers using jails and vnets on a small PC Engines APU2 system with only 4 CPU cores (1Ghz AMD) and 4GB RAM). This project was sponsored by OVH. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. HardenedBSD Links HardenedBSD Homepage URL: https://hardenedbsd.org/ SafeStack URL: http://clang.llvm.org/docs/SafeStack.html HardenedBSD Tor Hidden Service URL: http://t3a73imee26zfb3d.onion/ Projects HardenedBSD Would Like Help With URL: https://github.com/HardenedBSD/hardenedBSD/issues?q=3Dis%3Aissue+i= s%3Aopen+label%3A%22help+wanted%22 Contact: Shawn Webb Contact: Oliver Pinter HardenedBSD is a derivative of FreeBSD that gives special attention to security-related enhancements and exploit-mitigation technologies. From an initial focus on Address Space Layout Randomization (ASLR), it has now branched out to explore additional exploit mitigation techniques. It has been a long while since HardenedBSD's last entry in a quarterly status report, back in 2015Q4. The intervening year saw HardenedBSD gain new developers Bernard Spil and Franco Fichtner, import LibreSSL and OpenNTPd into base as the default crypto library and NTP client, respectively, and introduce the hbsd-update binary update mechanism for the base system. The secadm application got a rewrite and Trusted Path Execution (TPE). PIE is now enabled for the base system for arm64 and amd64 as well as the bulk of the ports tree, and the ports tree also gained RELRO and BIND_NOW. Integriforce (similar to NetBSD's verified exec, veriexec) was introduced for the base system, as well as SafeStack, a technology for protection against stack-based buffer overflows that's developed by the Clang/LLVM community. SafeStack relies and builds on top of Address Space Layout Randomization (ASLR), and is strengthened by the presence of PaX NOEXEC. Certain high-profile ports also have SafeStack enabled. Extremely generous hardware donations from G2, Inc. have provided for dedicated package building and binary update servers, as well as development and test servers. In March of 2017, we added Control Flow Integrity (CFI) to the base system. CFI is an exploit mitigation technique that helps prevent attackers from modifying the behavior of a program and jumping to undefined or arbitrary memory locations. This type of technique is gaining adoption across the industry -- Microsoft has implemented a variant of CFI, which they term Control Flow Guard, or CFG, and the PaX team has spent the last few years perfecting their Reuse Attack Protector, RAP. Of these, RAP is the most complete and effective implementation, followed by Clang's CFI. RAP would be a great addition to HardenedBSD; however, it requires a GPLv3 toolchain and is patent-pending. CFI can be implemented either on a per-DSO basis, or across all DSOs in a process. Currently only the former is implemented, but we are working hard to enable cross-DSO CFI. As is the case for SafeStack, cross-DSO CFI requires both ASLR and PaX NOEXEC in order to be effective. If an attacker knows the memory layout of an application, the attacker might be able to craft a data-only attack, modifying the CFI control data. The behavior of several system control (sysctl) nodes has been tighened up, limiting write access and introducing additional safety checks for write accesses. Kernel module APIs received a similar treatment. HardenedBSD's PaX SEGVGUARD implementation received a few updates to make it more stable and performant. As of March 2017, HardenedBSD is now accessible through a Tor hidden service. The main website, binary updates, and package distribution are all available over the hidden service. We now maintain our own version of the drm-next branch for updated graphics support. Binary updates are also provided for this branch. HardenedBSD would like to thank all those who have generously donated time, money, or other resources to the project. This project was sponsored by SoldierX, and G2, Inc. Open tasks: 1. Port SafeStack to arm64. 2. Integrate Cross-DSO CFI. 3. Add documentation to the HardenedBSD Handbook. 4. Start porting grsecurity's RBAC. __________________________________________________________________ --HeFlAV5LIbMFYYuh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlnMLcwACgkQKNmm82Tr dRKXUAwgzueor3CCu0VPI+jG5v5NVEewwGB3Q3GMKaykJbRbVQusrHzR1mc3CTLq fIE4UWL/bvnV7IPSbfmX4qhVHU5f/zl100wbke88RT1Og4yzWjgQV/kYVmhrnXPV wFxYuuSoW6XckjHvVEXgSyGKgBSwjy/8/1KCM2tUTaxP1zR+11dFure5BsXKLnvo IVONjg4zQS2qdoB4f+/D6rG4pP+tK/VoMQx8NNPQXuO8L+PzEbs23F8l6WG67I6o eLdVX5q5vgEVZIaCRn0tlipNHTvyJuFaw5dlSU970LOwoZ3ZaUHzHtVehbvB5Jck lgG6gZxbI1ROwy9niyhsWixJ7oAyWt0koo4LxxyT7K3nyzv/r5stHiKeijr5JsRR dDFP95br/4rJ+d41TuU+FAiCeKRI9rywusT4qGJdT5nG8Y2ZbFxHLaBj8+SHx2+j C1zMdnCwv7pPGzmYyeIw1m9CoTf8WdDbdWx/07xXFJ6Pp7Tkn1B+kU4PHNmiUYv3 UzLmeRO29rfdZA== =n+Q+ -----END PGP SIGNATURE----- --HeFlAV5LIbMFYYuh-- From owner-freebsd-hackers@freebsd.org Thu Sep 28 14:34:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C86CE3335C; Thu, 28 Sep 2017 14:34:40 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 BA5D91719; Thu, 28 Sep 2017 14:34:39 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-6efff70000001f28-3c-59cd074a895a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id DB.2B.07976.A470DC95; Thu, 28 Sep 2017 10:29:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v8SETTil012333; Thu, 28 Sep 2017 10:29:30 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8SETQuY012052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Sep 2017 10:29:28 -0400 Date: Thu, 28 Sep 2017 09:29:26 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Call for 2017Q3 quarterly status reports Message-ID: <20170928142925.GG96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixG6nruvFfjbS4PEdSYs5bz4wWWzf/I/R gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZ737pFXTxVOybv4W9gbGJq4uRk0NCwERi5qwfrCC2 kMBiJonmZiCbC8jeyChxe1cblHOVSWLz0c0sIFUsAqoS/w+/YQex2QRUJBq6LzOD2CIC8hL7 mt6DxZmB7F9bm4BsDg5hAUOJfQcyQMK8QMuuXPvEDGELSpyc+YQFolxL4sa/l0wg5cwC0hLL /3GAhEUFlCXm7VvFNoGRbxaSjllIOmYhdCxgZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6GX m1mil5pSuokRHGYuqjsY5/z1OsQowMGoxMN7YcHpSCHWxLLiytxDjJIcTEqivM9YzkYK8SXl p1RmJBZnxBeV5qQWH2KU4GBWEuFdxwaU401JrKxKLcqHSUlzsCiJ824L2hUpJJCeWJKanZpa kFoEk5Xh4FCS4A0HaRQsSk1PrUjLzClBSDNxcIIM5wEa7gA2vLggMbc4Mx0if4pRUUqcdwJI QgAkkVGaB9cLSgMS2ftrXjGKA70izLsUpIoHmELgul8BDWYCGjx54hmQwSWJCCmpBkatY3/P 9m5Rqqr+wRvSrPFDuNsgmX2r4tdZjoU2j2PPJK+T+bmg/WXvmx3Nh7I8JBk3PDXJVr8j3n5p 7fVnNW90jn1y2uTeIq+p4LFWht31VIG9iMzTUovEBsfikJjgTt8f1YX9TDJLJuc33tss8OT5 Mc1t+zRYLaQnnpg9/53Np2M169gSbJRYijMSDbWYi4oTAcrqhj7eAgAA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 14:34:40 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October 21, 2017, for work done in July through September. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself! In particular, the Google Chrome "save as" function does not save the generated output for some reason.) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q3 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html From owner-freebsd-hackers@freebsd.org Fri Sep 29 04:37:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45319E22760 for ; Fri, 29 Sep 2017 04:37:47 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [207.172.210.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D4FEC7D230 for ; Fri, 29 Sep 2017 04:37:46 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::1f] (haymarket.m5p.com [IPv6:2001:470:1f07:15ff::1f]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id v8T4bJjx063989 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 29 Sep 2017 00:37:24 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: freebsd-hackers@FreeBSD.org From: George Mitchell Subject: Best practices: changing ISP Message-ID: <72393abb-f966-c7ca-de1d-b0650bdf98dd@m5p.com> Date: Fri, 29 Sep 2017 00:37:12 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Iidg6rfuOs7nlt8IK7TTF2HXJjvmdo0pF" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]); Fri, 29 Sep 2017 00:37:26 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 04:37:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Iidg6rfuOs7nlt8IK7TTF2HXJjvmdo0pF Content-Type: multipart/mixed; boundary="4oV5xwkaXgG4blpXGNTNPKfHNSoucrnFR"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@FreeBSD.org Message-ID: <72393abb-f966-c7ca-de1d-b0650bdf98dd@m5p.com> Subject: Best practices: changing ISP --4oV5xwkaXgG4blpXGNTNPKfHNSoucrnFR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable So for a while I'll have service from two ISPs, and hopefully anyone who connects to my old external address will get a response from that address, and anyone connects to the new address will get a response from there. Internally, my gateway is a FreeBSD box using "pf" with NAT in the kernel, and my old ISP on one ethernet interface and the new ISP on another one. Has anyone written up a cheat sheet somewhere that I can review? What are the gotchas I'm going to run into? To begin with, I've set all my DNS TTLs to 300 to discourage people from caching the old address for too long. Thanks for any pointers. -- George --4oV5xwkaXgG4blpXGNTNPKfHNSoucrnFR-- --Iidg6rfuOs7nlt8IK7TTF2HXJjvmdo0pF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlnNzfkACgkQwRES3m+p 4flkFw/+KYuXjs3AW3EH8LRMqz2n90RaB2uTWftgYlPpnTHHs077piPv+PRfI+9e 1EuLA6PmSzXKcTnElBgW1b1u+2VMYu1CF0EDjT4prFfarn0mgcAxHFYx+coB0wME ADYhS7H9z/cJ2Q4ergPBVRaP1SHwQreFkR8kOkUX0aKVMnysckl4UN0y7YKb0kCj +/ZsPfU30H7UqpNiSwOhrgxYzga6dYXHsNllmu2R7oHvIZ2L2XK+yhsgJ49qn/Ca RbMhehoWdCDWotm76DGs5bqK7UzyEXxjkvs1/5y2xud7jEWSXijdIyEsy9Wx9oay nnE/QP7qVq32f6lk2iIbc3m+fZXg9cSFW12BiWxtCmsqzLRfHk+MFpMRu3rkbawX gMIBGb1OsvxExPhOkeuLm4AdUGov5RtSE5x8nXCUdcFGbqxTJtsebc4YuOXhvTQZ 0b9GBzoIZjvpi91DQ8gP9hheaLC9ERTFj23GohIfRhhSSEn2I6V4gaXb2FRLTn84 SbfX9GgvsO7rffMIIUyatC9X39FdyCIUG+ix8uZyqJUdXGIJqJTWd5RV68EMMvDD GunSsb/P87dkJjYwdSn/NKqDMjIMCqCYRknvZQ+jku3HqxC5tTH4j4FNDQGutII5 kfmf/VktRGt/uDMzF5gPYC8e7dhWllM3/P7PQ1pX+cm/rOMN/m0= =80mA -----END PGP SIGNATURE----- --Iidg6rfuOs7nlt8IK7TTF2HXJjvmdo0pF-- From owner-freebsd-hackers@freebsd.org Fri Sep 29 14:04:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36A35E2DA58 for ; Fri, 29 Sep 2017 14:04:18 +0000 (UTC) (envelope-from ar.fahimi@gmail.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F40FD672B5 for ; Fri, 29 Sep 2017 14:04:17 +0000 (UTC) (envelope-from ar.fahimi@gmail.com) Received: by mail-it0-x22a.google.com with SMTP id v62so215800itd.0 for ; Fri, 29 Sep 2017 07:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eT1iyCq0Bm46SKFylqt9vxEsoE2p3TrJ5OGodzB3XXU=; b=eU1asjSMzT+xIBbY7XStzW1jx4p+cy45nb96AJzbMLRfWVS0DFRAK3+oHM2c4PbwIM XpW8LtMcp6C4//5W5ae8sCXNLZg943Jj+4NVylk2YWTLQszz+heuuk/DKmabcgg8nuOC UirGCLIpI7EjHE7zFO+YzGjmaZYWYE2qumO9ITDS5Vp2QwILSSbUL0eC1YJHQb/Mywjy 5QfhazrdPpLSB1kF3WwuNyYAdOTn1KMsgL/sQTKfNEIWGnwbaqbKn38oupLbBymj8Xaa 0ay7TL2GZGFy03Sr6hTo/hNawOJsO08tUWREJ64ZdU7kFwhPftmnWhfZlBQH9+zCwuYR K4QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eT1iyCq0Bm46SKFylqt9vxEsoE2p3TrJ5OGodzB3XXU=; b=X9NdWogQc+28s7PBMR3hUiH1G2WYiCODwC6ndAHlQYivVTLs6pKmNEN/CqKOH8Xiss gLkbyimcsd4d972Q9H80V1Oae0fI7+Az8Q1vgLzCnGHzq73CEjY/qhS1AeYXB4RgD/2v 2BKLyIVQ70vjmiM+qHu+xr4ZcqZooVoFjjerw0EP6RakQLeempIgIp1wQ8nI9v0lI2NL LISfdde3lzOoiwn9/P9hloyZ/yjHjXLBh6Ov5oGyCta2q/Cor/t/pVZl7j4sCsdOVKOs xrPTV00FVthLJ9MzzoQZYh6lqXbnp5AHmmNvKWR9QNo92QRI8gOGsTXdchbElp63mTcO 1nwQ== X-Gm-Message-State: AHPjjUhwFP/WbIQEJ15/TlHShwt4HUgLGbYPnkV6/g88Sth9br4dgRmO vbHocK5miEdV74/wPP/7NBtfDfgF8e4DrzhjVmLAyg== X-Google-Smtp-Source: AOwi7QBNS6Oz9+NOFvScJBWnzh/OzFd2a/CRCDjD8BwF0exqkdtFf5xyD+HPoxaAQcqHh+4Zvo2aAuedymH7SKw3S/Q= X-Received: by 10.36.83.20 with SMTP id n20mr7593297itb.120.1506693857029; Fri, 29 Sep 2017 07:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.72 with HTTP; Fri, 29 Sep 2017 07:04:16 -0700 (PDT) From: Ali Reza Fahimi Date: Fri, 29 Sep 2017 16:04:16 +0200 Message-ID: Subject: How can I apply security patches to an offline freebsd machine? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 14:04:18 -0000 *Synopsis*: We would like to use FreeBSD (version 11.0) on one of our products. Once the product leaves the company, it will be disconnected from the Internet for good. However, as part of our support policy, we are bound to provide regular patches including security patches for the OS and the installed software to the customers. *Question*: Is there a way to apply security patches to FreeBSD in an offline machine? *What I have done so far* After googling for days, below is the summary of what people suggest to do: 1. On an online machine exactly similar to the real machine a.k.a the offline machine, fetch the security patches: freebsd-update fetch 1. Transfer the contents of the /var/db/freebsd-update directory from the online machine to the offline machine. 2. Apply the patches on the offline machine: freebsd-update install Provided the OS on the two machines are identical, this is expected to work. But my attempts so far have all been in vain. An error is displayed each time asking me to do the fetching step first by running: freebsd-update fetch I would be grateful if anyone could help me. *Regards* Please consider the environment before printing. From owner-freebsd-hackers@freebsd.org Fri Sep 29 17:33:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9847CE3165C for ; Fri, 29 Sep 2017 17:33:40 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 471DE6EFEC for ; Fri, 29 Sep 2017 17:33:39 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v8THbKeB098174 for ; Fri, 29 Sep 2017 10:37:26 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: From: "Chris H" Subject: Re: How can I apply security patches to an offline freebsd machine? Date: Fri, 29 Sep 2017 10:37:26 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 17:33:40 -0000 I'm not sure how much you might consider "too much", nor do I really have any idea what's at your disposal. But I would like to suggest a couple of things that may better help you cater to your situation: subscribe to the FreeBSD security mailing list(s): o FreeBSD-security-notifications@FreeBSD.org o FreeBSD-security@FreeBSD.org o FreeBSD-announce@FreeBSD.org These are for [the] BASE [system]. Ports are an entirely different matter. It might be easiest to simply "clone" the system that your "supporting". You could simply dump(8) that system to a Flash DISK, or other easily removable media, and then restore(8) it to a disk on a local system. In fact it could be a removable disk. That you can simply plug-in, and then boot to. The point being; that you could then update [at least] the ports tree, and make packages [ pkg(8) ] that you can easily install to your "supported" box, at your convenience. HTH --Chris On Fri, 29 Sep 2017 16:04:16 +0200 Ali Reza Fahimi wrote > *Synopsis*: > > We would like to use FreeBSD (version 11.0) on one of our products. Once > the product leaves the company, it will be disconnected from the Internet > for good. However, as part of our support policy, we are bound to provide > regular patches including security patches for the OS and the installed > software to the customers. > > *Question*: > > Is there a way to apply security patches to FreeBSD in an offline machine? > > *What I have done so far* > > After googling for days, below is the summary of what people suggest to do: > > 1. On an online machine exactly similar to the real machine a.k.a the > offline machine, fetch the security patches: > > freebsd-update fetch > > > 1. > > Transfer the contents of the /var/db/freebsd-update directory from the > online machine to the offline machine. > 2. > > Apply the patches on the offline machine: > > freebsd-update install > > Provided the OS on the two machines are identical, this is expected to > work. But my attempts so far have all been in vain. An error is displayed > each time asking me to do the fetching step first by running: > > freebsd-update fetch > > > I would be grateful if anyone could help me. > > *Regards* > > Please consider the environment before printing. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Fri Sep 29 17:40:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80468E31886 for ; Fri, 29 Sep 2017 17:40:15 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49D1C6F2A7 for ; Fri, 29 Sep 2017 17:40:14 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v8THi1H5098849 for ; Fri, 29 Sep 2017 10:44:07 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: , From: "Chris H" Subject: Re: How can I apply security patches to an offline freebsd machine? Date: Fri, 29 Sep 2017 10:44:07 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 17:40:15 -0000 On Fri, 29 Sep 2017 10:37:26 -0700 "Chris H" wrote > I'm not sure how much you might consider "too much", nor do I > really have any idea what's at your disposal. But I would like > to suggest a couple of things that may better help you cater > to your situation: > subscribe to the FreeBSD security mailing list(s): > > o FreeBSD-security-notifications@FreeBSD.org > o FreeBSD-security@FreeBSD.org > o FreeBSD-announce@FreeBSD.org Sorry. I forgot to also mention... Please read the following FreeBSD security page: https://www.freebsd.org/security/ for more [FreeBSD] security related resources, and information. > > These are for [the] BASE [system]. Ports are an entirely > different matter. It might be easiest to simply "clone" the > system that your "supporting". You could simply dump(8) that > system to a Flash DISK, or other easily removable media, and > then restore(8) it to a disk on a local system. In fact it > could be a removable disk. That you can simply plug-in, and > then boot to. The point being; that you could then update > [at least] the ports tree, and make packages [ pkg(8) ] > that you can easily install to your "supported" box, at your > convenience. > > HTH > > --Chris > > > On Fri, 29 Sep 2017 16:04:16 +0200 Ali Reza Fahimi > wrote > > > *Synopsis*: > > > > We would like to use FreeBSD (version 11.0) on one of our products. Once > > the product leaves the company, it will be disconnected from the Internet > > for good. However, as part of our support policy, we are bound to provide > > regular patches including security patches for the OS and the installed > > software to the customers. > > > > *Question*: > > > > Is there a way to apply security patches to FreeBSD in an offline machine? > > > > *What I have done so far* > > > > After googling for days, below is the summary of what people suggest to do: > > > > 1. On an online machine exactly similar to the real machine a.k.a the > > offline machine, fetch the security patches: > > > > freebsd-update fetch > > > > > > 1. > > > > Transfer the contents of the /var/db/freebsd-update directory from the > > online machine to the offline machine. > > 2. > > > > Apply the patches on the offline machine: > > > > freebsd-update install > > > > Provided the OS on the two machines are identical, this is expected to > > work. But my attempts so far have all been in vain. An error is displayed > > each time asking me to do the fetching step first by running: > > > > freebsd-update fetch > > > > > > I would be grateful if anyone could help me. > > > > *Regards* > > > > Please consider the environment before printing. > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sat Sep 30 17:00:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BF4AE2AD11; Sat, 30 Sep 2017 17:00:37 +0000 (UTC) (envelope-from emss.mail@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD5FB74CFD; Sat, 30 Sep 2017 17:00:36 +0000 (UTC) (envelope-from emss.mail@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id q124so4122356wmb.0; Sat, 30 Sep 2017 10:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:user-agent:date:message-id:mime-version :content-transfer-encoding; bh=3LKRjR2rPny2rB1lgoEIrurySb4PR9tC0Cdo7Fm3U8I=; b=qUvXmfCxpgKdoMH/tbxAZoiGkH20q/zflz0l6oTw1vzlPZx5/oydE5OelVblhZ2pev R2hg6o2WmdiypI8BXoQpUGEJOqNPVu3/h1pZlFMcTj5gKtPx6jcmcJ+zuQNyeRlRtIoK r4vISI222s47yK6qMcYOj4AlOKkKOUdxR6DNH+DSy90BfyClchMmWUfrZCwmXwWhd09U 7+/YA4mN7/o1pXv3R4TG9/K9FTe2hnfozZv3fMB+LVYfP/ioY/cJ2t3phSdyZTom/D8x hUOCEELQkMfuTZ6rJGLmy/rQgUlpArXV2k4Axy2nCMF1mOhyENE/webAl43BUdaE9N05 fL3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=3LKRjR2rPny2rB1lgoEIrurySb4PR9tC0Cdo7Fm3U8I=; b=LoPBgjuJ6cwWwMVVyWP3dUEXuGujxibxnNFzUsQ4jY3ps0kwPCrUHYIfEGgShju45g k0Wf+0S+Gy18p8ithXY4wEHMdQsrL6HciHTvT6VPcB6E09vqDaTvnwoMhDtnFq8AGitF NmzqAWEja+MFRNPl39fKFAoIr62JGXLqeTr5HlmWVkvFpOZHoBAUKzqpyNPHZrEKTOC4 FfVxT7yvVYm/9n1j8ZlJXeMYgEQ2/V/AyK/3bqx2j631AZ3QtnrFcjrIxEzFKsXh4WTk PBSi87rLtyqdQAmoUaqLHPLJo4oFej5/FTzzeDKiE9PihdhmN4fxLSwHnEuhWwWoyUfe ZgMw== X-Gm-Message-State: AHPjjUj9VG1+EV86spJUXtYlQkC0l23gQFO+KS2odF8zwSGVj/d8Gv0A z8+QGD+KoagKkbqTRU2NvI4fjg== X-Google-Smtp-Source: AOwi7QAglKX0kWczPJpE6CrhYRHxsLEbuyDN6KLsm+SoSqmrNf/BacpjQbWqhejxnm1fxCUTTgHjFg== X-Received: by 10.28.58.136 with SMTP id h130mr6162163wma.56.1506790834900; Sat, 30 Sep 2017 10:00:34 -0700 (PDT) Received: from srvbsdfenssv.interne.associated-bears.org (LStLambert-658-1-110-48.w217-128.abo.wanadoo.fr. [217.128.200.48]) by smtp.gmail.com with ESMTPSA id e134sm4794339wma.31.2017.09.30.10.00.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Sep 2017 10:00:34 -0700 (PDT) Sender: Eric Masson Received: from newsrv.interne.associated-bears.org (localhost [127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id 13F61EF5; Sat, 30 Sep 2017 19:00:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at interne.associated-bears.org Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1]) by newsrv.interne.associated-bears.org (newsrv.interne.associated-bears.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em-dC2UYfK0P; Sat, 30 Sep 2017 19:00:31 +0200 (CEST) Received: by srvbsdfenssv.interne.associated-bears.org (Postfix, from userid 1001) id C77BDEEA; Sat, 30 Sep 2017 19:00:31 +0200 (CEST) From: Eric Masson To: Mailing List FreeBSD Questions , Mailing List FreeBSD Hackers Subject: Freeswitch can't stop properly on 11-STABLE User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) X-Operating-System: FreeBSD 11.1-STABLE amd64 Date: Sat, 30 Sep 2017 19:00:31 +0200 Message-ID: <86h8vk86kw.fsf@newsrv.interne.associated-bears.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 17:00:37 -0000 Hello, I'm facing an issue with Freeswitch (1.6.x or 1.8.x, FreeBSD port or manual build from FS git) on 11-Stable (GENERIC or custom configuration make no difference). When closing the application via cli, all modules unload until it gets stuck and has to be SIGKILLed to stop the process. I've gathered information that is available in a ticket on Freeswitch JIRA : https://freeswitch.org/jira/browse/FS-10580 The problem seems to be related to 11-Stable as I can't reproduce the issue with 10.3-RELEASE. Any idea, anyone ? Regards Éric Masson