From owner-freebsd-current@freebsd.org Sun Apr 17 08:56:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73813AEE6D4 for ; Sun, 17 Apr 2016 08:56:52 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35C2A19AB for ; Sun, 17 Apr 2016 08:56:51 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ariVc-000frX-NF>; Sun, 17 Apr 2016 10:56:48 +0200 Received: from x5ce12745.dyn.telefonica.de ([92.225.39.69] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1ariVc-002myy-EA>; Sun, 17 Apr 2016 10:56:48 +0200 Date: Sun, 17 Apr 2016 10:57:41 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r298143: something wrong with autofs? Message-ID: <20160417105741.170f6f14.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/+94AFKZG2Hj1LzlwtBL/iCf"; protocol="application/pgp-signature" X-Originating-IP: 92.225.39.69 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 08:56:52 -0000 --Sig_/+94AFKZG2Hj1LzlwtBL/iCf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Running FreeBSD 11.0-CURRENT #32 r298143: Sun Apr 17 09:48:26 CEST 2016 am= d64, on both server and client, reveals today that AUTOFS seems not to work. Did somethi= ng changed unnoticed? I realized, that no exported filesystem is bound so far. On the server's si= de, all daemons necessary are configured as they were before in a working state and= as I can see so far, they are up and running and also listening to their sockets/IPs.=20 Any hint? Thanks in advance, O. Hartmann --Sig_/+94AFKZG2Hj1LzlwtBL/iCf Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXE1AGAAoJEOgBcD7A/5N8NAsIAJ3AbuLbuBbJnatDnieJO6xR L8z1ArFGPffAVQlT8/piL/Uq9fsqi1edXqPnHP/+XNyYvu64q2DyUV6x9vKgunAp t3egFxsT9SyYHWFcnOXaIpXC/Gzf5/j3fuJwZdpf9AvY98EOeO+730TkQ9vlQEan 42rkhO5qO9aDNXmnf7JlWsL4UijJzvp26iikA3ct4LuFNVunutJ0y3+IL7IGDKmN ZFTgXZwXs/klMcd+oAUhuqjg31hfSYl6q3BYBpLRByX9980BsDy9NvroDhsfr1Kg vHlktCRbobN82o91LB+Cn3oGVFjYpkdhs6NC/9m0YQg5TYpq4cZ1Sc6J0/DyOTY= =kCNb -----END PGP SIGNATURE----- --Sig_/+94AFKZG2Hj1LzlwtBL/iCf-- From owner-freebsd-current@freebsd.org Sun Apr 17 09:05:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25875AEEBEE for ; Sun, 17 Apr 2016 09:05:13 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FE8B1DA8 for ; Sun, 17 Apr 2016 09:05:12 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id a140so82059028wma.0 for ; Sun, 17 Apr 2016 02:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=Hu1LXqttYTiBncHl8N/PvhM2H5zucKJN4fdpkkP9nnI=; b=DwefhClSHFieKZXg4KJ5P7udGCbaKoy0uMYAU9iblnUFSrojWZ46I5561mp5aVYqod BAR2ZPmE/uXjZquKawg0EK4fdY9/ClcPp3tZTFRyWMlWSEAJ/qLGtwns4dv7ij80gRJA boeSK/iS+nrKxTy1zDweIB1DCVvDrTp2dmVSvuh1ZhXC7UZdxYSG7H6wMbXh6/MZpllv iiZYKmWRo8CG1T+Vy0ykLhTP3GUPH9tswqkEQsHzfig3M61bazvWyVCfUxNPZVYU3Nwe f4KPV7VBZX+hEChuwoUYZLngvfrgDhPzgI+1PnvYCuRQSS61JFOqEQNgU5MfNFUqT8u7 4QGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Hu1LXqttYTiBncHl8N/PvhM2H5zucKJN4fdpkkP9nnI=; b=fXXeU9+R+d4DrzJ8OD8rR9XHJwTISp60DiiSuG/gSG6dnij3U8xEO81zX2uOgXkEmC sfg/45wAKlf79JrvSNTdYKNc4JLIxeNpzCaAC5sboQKK1Df+TutjXJ456YUN2k20fytT PvHqxiFD5nafgFxbwNzbzDJldrBtV3TWFb4fHU4Wl5ZU+ZyRK4u8jw1kGquIthzHgtaX 6ne8tV0ZJLznmkO+UcYesyY2oWiPbt4qb+8m9pBN2yYkjQhCNBGkCGAlh9CpBnXT8AG0 L9HZRz+0jpn85rXEevqn7b38FQ4bBW52WdY1OLqu5KZHrAdyQgk4zp7K6yTJd2jZoYal CqxA== X-Gm-Message-State: AOPr4FVTwmnu2eWVHjVS3sOhH9BZ/jmHCRRBX/bYcagGigcLhfO4VelCw7UIYQ1AOUwJ173/e9NehpHGQJRMzg== MIME-Version: 1.0 X-Received: by 10.28.145.205 with SMTP id t196mr12498541wmd.60.1460883910094; Sun, 17 Apr 2016 02:05:10 -0700 (PDT) Received: by 10.28.4.210 with HTTP; Sun, 17 Apr 2016 02:05:09 -0700 (PDT) Date: Sun, 17 Apr 2016 12:05:09 +0300 Message-ID: Subject: OCZ ssdpx-1rvd0120 REVODRIVE support From: Pavel Timofeev To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=001a1145a91285673d0530aa8a2b X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 09:05:13 -0000 --001a1145a91285673d0530aa8a2b Content-Type: text/plain; charset=UTF-8 HI! I've recently got a SSD device. Yes, not a disk, but a device. It's called, i. e. one of the first REVODRIVEs. It's a PCI-express card with two embedded ssd disks about ~ 55GB size. And it's a raid card. Fake software raid. You can set it up as a RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured or set it as JBOD or something else. You just won't be able to boot from this device in that case. So, I tried to install FreeBSD on it. Actually two fbsd version: FreeBSD 10.3-RELEASE amd64 and FreeBSD-CURRENT amd64 based on r297561 . . I used RAID0, RAID1 and CONCATENATION raid configurations and UFS and ZFS (stripe) filesystems. The deivce is seen as raid/r0 and I installed fbsd on it. Here is the result of different attemps. FreeBSD 11-CURRENT r297561 amd64 RAID0 UFS MBR - during installation I immediately get 'unknown error -559038242' GPT - the same and 'Error installing partcode on r0p1' message ZFS MBR - 'Invalid argument' during installation. GPT - 'Invalid argument' during installation. RAID1 UFS MBR - installs and boots w/o problem GPT - installs and boots w/o problem ZFS MBR - 'Invalid argument' during installation. GPT - 'Invalid argument' during installation. CONCATENATION UFS MBR - 'unknown error -559038242' during installation GPT - 'unknown error -559038242' during installation ZFS MBR - 'Invalid argument' during installation. GPT - 'Invalid argument' during installation. FreeBSD 10.3-RELEASE amd64 RAID0 UFS MBR - installs and boots w/o problem GPT - installs, but doesn't boot. I can see on the screen: gptboot: error lba 1280 gptboot: No /boot/loader on 0:ad(0p2) gptboot: No /boot/kernel/kernel on 0:ad(0p2) ZFS MBR - 'Invalid argument' during installation. GPT - 'Invalid argument' during installation. RAID1 UFS MBR - installs and boots w/o problem GPT - installs and boots w/o problem ZFS MBR - 'Invalid argument' during installation. GPT - hangs during installation CONCATENATION UFS MBR - installs, but panics during boot GPT - the same, but also I see the following messages on the screen durin boot gpterror 1 lba 234458719 unable to read gpt header ZFS MBR - 'Invalid argument' during installation. GPT - 'Invalid argument' during installation. Also I've attached dmesg and 'geom disk list' output. I'm ready to try some patches and help to solve this problem! --001a1145a91285673d0530aa8a2b Content-Type: application/octet-stream; name=conc0_dmesg Content-Disposition: attachment; filename=conc0_dmesg Content-Transfer-Encoding: base64 X-Attachment-Id: f_in48iivo0 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMS4wLUNVUlJFTlQgIzAgcjI5NzU2MTogTW9uIEFw ciAgNCAyMjo0MjowMCBNU0sgMjAxNgogICAgdGltcEBmYnNkMTE6L3Vzci9vYmovdXNyL3NyYy9z eXMvR0VORVJJQyBhbWQ2NApGcmVlQlNEIGNsYW5nIHZlcnNpb24gMy44LjAgKHRhZ3MvUkVMRUFT RV8zODAvZmluYWwgMjYyNTY0KSAoYmFzZWQgb24gTExWTSAzLjguMCkKV0FSTklORzogV0lUTkVT UyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClZUKHZnYSk6IHJl c29sdXRpb24gNjQweDQ4MApDUFU6IEludGVsKFIpIENvcmUoVE0pIGkzLTIxMjAgQ1BVIEAgMy4z MEdIeiAoMzI5Mi41OS1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbj0iR2VudWluZUludGVsIiAg SWQ9MHgyMDZhNyAgRmFtaWx5PTB4NiAgTW9kZWw9MHgyYSAgU3RlcHBpbmc9NwogIEZlYXR1cmVz PTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxN VFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0Us U1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDFkOWFlM2JmPFNTRTMsUENMTVVMUURR LERURVM2NCxNT04sRFNfQ1BMLFZNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLFBDSUQs U1NFNC4xLFNTRTQuMixQT1BDTlQsVFNDRExULFhTQVZFLE9TWFNBVkUsQVZYPgogIEFNRCBGZWF0 dXJlcz0weDI4MTAwODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgx PExBSEY+CiAgWFNBVkUgRmVhdHVyZXM9MHgxPFhTQVZFT1BUPgogIFZULXg6IFBBVCxITFQsTVRG LFBBVVNFLEVQVCxVRyxWUElECiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ug c3RhdGlzdGljcwpyZWFsIG1lbW9yeSAgPSA4NTg5OTM0NTkyICg4MTkyIE1CKQphdmFpbCBtZW1v cnkgPSA4MjA3MTcxNTg0ICg3ODI2IE1CKQpFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgNjAw CkFDUEkgQVBJQyBUYWJsZTogPEFMQVNLQSBBIE0gST4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vz c29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCAy IGNvcmUocykgeCAyIGhhcmR3YXJlIHRocmVhZHMKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMg MC0yMyBvbiBtb3RoZXJib2FyZApyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVy ZmFjZQprYmQxIGF0IGtiZG11eDAKbmV0bWFwOiBsb2FkZWQgbW9kdWxlCm1vZHVsZV9yZWdpc3Rl cl9pbml0OiBNT0RfTE9BRCAodmVzYSwgMHhmZmZmZmZmZjgwZjA1ZWIwLCAwKSBlcnJvciAxOQp2 dHZnYTA6IDxWVCBWR0EgZHJpdmVyPiBvbiBtb3RoZXJib2FyZApjcnlwdG9zb2Z0MDogPHNvZnR3 YXJlIGNyeXB0bz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IDxBTEFTS0EgQSBNIEk+IG9uIG1vdGhl cmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApj cHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGlt ZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBF VCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVyICJIUEVUIiBm cmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA1NTAKRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVx dWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQyIiBmcmVxdWVu Y3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQ0IiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSA0NDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3 MC0weDc3IGlycSA4IG9uIGFjcGkwCmF0cnRjMDogV2FybmluZzogQ291bGRuJ3QgbWFwIEkvTy4K RXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMAphdHRpbWVyMDog PEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNwaTAKVGltZWNv dW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIg Imk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApUaW1lY291bnRlciAiQUNQ SS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAphY3BpX3RpbWVyMDogPDI0 LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMApwY2li MDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQp2 Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGUwMDAtMHhlMGZmIG1lbSAw eGUwMDAwMDAwLTB4ZWZmZmZmZmYsMHhmN2UwMDAwMC0weGY3ZTNmZmZmIGlycSAxNiBhdCBkZXZp Y2UgMC4wIG9uIHBjaTEKdmdhcGNpMDogQm9vdCB2aWRlbyBkZXZpY2UKaGRhYzA6IDxBVEkgKDB4 YWFiMCkgSERBIENvbnRyb2xsZXI+IG1lbSAweGY3ZTYwMDAwLTB4ZjdlNjNmZmYgaXJxIDE3IGF0 IGRldmljZSAwLjEgb24gcGNpMQpoZGFjMDogaGRhY19nZXRfY2FwYWJpbGl0aWVzOiBJbnZhbGlk IGNvcmIgc2l6ZSAoMCkKZGV2aWNlX2F0dGFjaDogaGRhYzAgYXR0YWNoIHJldHVybmVkIDYKeGhj aTA6IDxJbnRlbCBQYW50aGVyIFBvaW50IFVTQiAzLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMDAw MDAtMHhmN2YwZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIwLjAgb24gcGNpMAp4aGNpMDogMzIgYnl0 ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCnhoY2kwOiBQb3J0IHJvdXRpbmcgbWFzayBzZXQg dG8gMHhmZmZmZmZmZgp1c2J1czAgb24geGhjaTAKcGNpMDogPHNpbXBsZSBjb21tcz4gYXQgZGV2 aWNlIDIyLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKZWhjaTA6IDxJbnRlbCBQYW50aGVyIFBvaW50 IFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMTgwMDAtMHhmN2YxODNmZiBpcnEgMTYgYXQg ZGV2aWNlIDI2LjAgb24gcGNpMAp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMxIG9uIGVo Y2kwCmhkYWMwOiA8SW50ZWwgUGFudGhlciBQb2ludCBIREEgQ29udHJvbGxlcj4gbWVtIDB4Zjdm MTAwMDAtMHhmN2YxM2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApwY2liMjogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8UENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBk ZXZpY2UgMC4wIG9uIHBjaTIKcGNpMzogPFBDSSBidXM+IG9uIHBjaWIzCnNpaXMwOiA8U2lJMzEy NCBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhkMDAwLTB4ZDAwZiBtZW0gMHhmN2Q4ODAwMC0weGY3 ZDg4MDdmLDB4ZjdkODAwMDAtMHhmN2Q4N2ZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kz CnNpaXNjaDA6IDxTSUlTIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBzaWlzMApzaWlzY2gxOiA8 U0lJUyBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gc2lpczAKc2lpc2NoMjogPFNJSVMgY2hhbm5l bD4gYXQgY2hhbm5lbCAyIG9uIHNpaXMwCnNpaXNjaDM6IDxTSUlTIGNoYW5uZWw+IGF0IGNoYW5u ZWwgMyBvbiBzaWlzMApwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZp Y2UgMjguNCBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CmFoY2kwOiA8QVNN ZWRpYSBBU00xMDYxIEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4YzA1MC0weGMwNTcsMHhj MDQwLTB4YzA0MywweGMwMzAtMHhjMDM3LDB4YzAyMC0weGMwMjMsMHhjMDAwLTB4YzAxZiBtZW0g MHhmN2MwMDAwMC0weGY3YzAwMWZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTQKYWhjaTA6 IEFIQ0kgdjEuMjAgd2l0aCAyIDZHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgc3VwcG9ydGVk CmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAphaGNpY2gxOiA8 QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTAKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNQpyZTA6IDxSZWFsVGVrIDgxNjgvODExMSBCL0MvQ1AvRC9EUC9FL0YvRyBQQ0ll IEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHhiMDAwLTB4YjBmZiBtZW0gMHhmMDAwNDAwMC0weGYw MDA0ZmZmLDB4ZjAwMDAwMDAtMHhmMDAwM2ZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2k1 CnJlMDogVXNpbmcgMSBNU0ktWCBtZXNzYWdlCnJlMDogQ2hpcCByZXYuIDB4MmM4MDAwMDAKcmUw OiBNQUMgcmV2LiAweDAwMTAwMDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiByZTAKcmdlcGh5MDog PFJUTDgxNjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9u IG1paWJ1czAKcmdlcGh5MDogIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMGJhc2VULUZE WC1mbG93LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMGJhc2VUWC1GRFgtZmxvdywgMTAw MGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAxMDAwYmFzZVQtRkRYLW1h c3RlciwgMTAwMGJhc2VULUZEWC1mbG93LCAxMDAwYmFzZVQtRkRYLWZsb3ctbWFzdGVyLCBhdXRv LCBhdXRvLWZsb3cKcmUwOiBVc2luZyBkZWZhdWx0cyBmb3IgVFNPOiA2NTUxOC8zNS8yMDQ4CnJl MDogRXRoZXJuZXQgYWRkcmVzczogYmM6NWY6ZjQ6Mzc6NDM6ZWYKcmUwOiBuZXRtYXAgcXVldWVz L3Nsb3RzOiBUWCAxLzI1NiwgUlggMS8yNTYKZWhjaTE6IDxJbnRlbCBQYW50aGVyIFBvaW50IFVT QiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMTcwMDAtMHhmN2YxNzNmZiBpcnEgMjMgYXQgZGV2 aWNlIDI5LjAgb24gcGNpMAp1c2J1czI6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMyIG9uIGVoY2kx CnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2k2 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZp Y2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphaGNpMTogPEludGVsIFBh bnRoZXIgUG9pbnQgQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhmMDcwLTB4ZjA3NywweGYw NjAtMHhmMDYzLDB4ZjA1MC0weGYwNTcsMHhmMDQwLTB4ZjA0MywweGYwMjAtMHhmMDNmIG1lbSAw eGY3ZjE2MDAwLTB4ZjdmMTY3ZmYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYWhjaTE6 IEFIQ0kgdjEuMzAgd2l0aCA2IDZHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgbm90IHN1cHBv cnRlZAphaGNpY2gyOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTEKYWhjaWNo MzogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kxCmFoY2ljaDQ6IDxBSENJIGNo YW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMQphaGNpY2g1OiA8QUhDSSBjaGFubmVsPiBhdCBj aGFubmVsIDMgb24gYWhjaTEKYWhjaWNoNjogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9u IGFoY2kxCmFoY2ljaDc6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNpMQphaGNp ZW0wOiA8QUhDSSBlbmNsb3N1cmUgbWFuYWdlbWVudCBicmlkZ2U+IG9uIGFoY2kxCmFjcGlfYnV0 dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcHBjMTogPFBhcmFsbGVsIHBvcnQ+IHBvcnQg MHgzNzgtMHgzN2YsMHg3NzgtMHg3N2YgaXJxIDUgZHJxIDMgb24gYWNwaTAKcHBjMTogU01DLWxp a2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMTog RklGTyB3aXRoIDE2LzE2LzkgYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQg YnVzPiBvbiBwcGMxCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRy aXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMAp1YXJ0MDogPDE2NTUwIG9y IGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApv cm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2ZmZmYsMHhkMDAwMC0w eGQ0ZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQg cG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRr YmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IGNhbm5vdCBy ZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5 IENvbnRyb2w+IG9uIGNwdTAKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MQplc3QyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9s PiBvbiBjcHUyCmVzdDM6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTMKKG5vcGVyaXBoOnNpaXNjaDA6MDotMTpmZmZmZmZmZik6IHJlc2NhbiBhbHJlYWR5IHF1 ZXVlZAoobm9wZXJpcGg6c2lpc2NoMTowOi0xOmZmZmZmZmZmKTogcmVzY2FuIGFscmVhZHkgcXVl dWVkCnVzYnVzMDogNS4wR2JwcyBTdXBlciBTcGVlZCBVU0IgdjMuMApUaW1lY291bnRlcnMgdGlj ayBldmVyeSAxLjAwMCBtc2VjCmhkYWNjMDogPFJlYWx0ZWsgQUxDNjYyIEhEQSBDT0RFQz4gYXQg Y2FkIDAgb24gaGRhYzAKaGRhYTA6IDxSZWFsdGVrIEFMQzY2MiBBdWRpbyBGdW5jdGlvbiBHcm91 cD4gYXQgbmlkIDEgb24gaGRhY2MwCnBjbTA6IDxSZWFsdGVrIEFMQzY2MiAoUmVhciBBbmFsb2cp PiBhdCBuaWQgMjAgYW5kIDI0LDI2IG9uIGhkYWEwCnBjbTE6IDxSZWFsdGVrIEFMQzY2MiAoRnJv bnQgQW5hbG9nKT4gYXQgbmlkIDI3IGFuZCAyNSBvbiBoZGFhMAp1c2J1czE6IDQ4ME1icHMgSGln aCBTcGVlZCBVU0IgdjIuMAp1c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2Vu MC4xOiA8MHg4MDg2PiBhdCB1c2J1czAKdWh1YjA6IDwweDgwODYgWEhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMi4xOiA8SW50ZWw+ IGF0IHVzYnVzMgp1aHViMTogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1 YjI6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMxCnNlczAgYXQgYWhjaWVtMCBidXMgMCBzY2J1czEyIHRhcmdldCAwIGx1biAw CnNlczA6IDxBSENJIFNHUElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4wMCBk ZXZpY2UKc2VzMDogU0VNQiBTRVMgRGV2aWNlCmFkYTAgYXQgc2lpc2NoMCBidXMgMCBzY2J1czAg dGFyZ2V0IDAgbHVuIDAKYWRhMDogPE9DWi1SRVZPRFJJVkUgMS4zNz4gQVRBOC1BQ1MgU0FUQSAy LnggZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1iZXIgT0NaLTRJMEIxN1EwSDJLNzk5ME0KYWRhMDog MzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFk YTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiA1NzI0MU1CICgxMTcyMzE0MDggNTEy IGJ5dGUgc2VjdG9ycykKYWRhMSBhdCBzaWlzY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4g MAphZGExOiA8T0NaLVJFVk9EUklWRSAxLjM3PiBBVEE4LUFDUyBTQVRBIDIueCBkZXZpY2UKYWRh MTogU2VyaWFsIE51bWJlciBPQ1otNTEzWTkzMU5MUzhMNzlLWQphZGExOiAzMDAuMDAwTUIvcyB0 cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMTogQ29tbWFuZCBR dWV1ZWluZyBlbmFibGVkCmFkYTE6IDU3MjQxTUIgKDExNzIzMTQwOCA1MTIgYnl0ZSBzZWN0b3Jz KQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNNUDog QVAgQ1BVICMyIExhdW5jaGVkIQpHRU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTE5Mjk6IEFycmF5IFNp SS0xNjA0MDYyMTE5MjkgY3JlYXRlZC4KVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAx NjQ2Mjk2OTU2IEh6IHF1YWxpdHkgMTAwMApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVk LCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KR0VPTV9SQUlEOiBTaUktMTYwNDA2MjExOTI5 OiBEaXNrIGFkYTAgc3RhdGUgY2hhbmdlZCBmcm9tIE5PTkUgdG8gQUNUSVZFLgpHRU9NX1JBSUQ6 IFNpSS0xNjA0MDYyMTE5Mjk6IFN1YmRpc2sgU2lJIENvbmNhdGVuYXRpbzowLWFkYTAgc3RhdGUg Y2hhbmdlZCBmcm9tIE5PTkUgdG8gU1RBTEUuClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZz Oi9kZXYvdWZzL0ZyZWVCU0RfSW5zdGFsbCBbcm8sbm9hdGltZV0uLi4KR0VPTV9SQUlEOiBTaUkt MTYwNDA2MjExOTI5OiBEaXNrIGFkYTEgc3RhdGUgY2hhbmdlZCBmcm9tIE5PTkUgdG8gQUNUSVZF LgpHRU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTE5Mjk6IFN1YmRpc2sgU2lJIENvbmNhdGVuYXRpbzox LWFkYTEgc3RhdGUgY2hhbmdlZCBmcm9tIE5PTkUgdG8gU1RBTEUuCkdFT01fUkFJRDogU2lJLTE2 MDQwNjIxMTkyOTogQXJyYXkgc3RhcnRlZC4KR0VPTV9SQUlEOiBTaUktMTYwNDA2MjExOTI5OiBT dWJkaXNrIFNpSSBDb25jYXRlbmF0aW86MC1hZGEwIHN0YXRlIGNoYW5nZWQgZnJvbSBTVEFMRSB0 byBBQ1RJVkUuCkdFT01fUkFJRDogU2lJLTE2MDQwNjIxMTkyOTogU3ViZGlzayBTaUkgQ29uY2F0 ZW5hdGlvOjEtYWRhMSBzdGF0ZSBjaGFuZ2VkIGZyb20gU1RBTEUgdG8gQUNUSVZFLgpHRU9NX1JB SUQ6IFNpSS0xNjA0MDYyMTE5Mjk6IFZvbHVtZSBTaUkgQ29uY2F0ZW5hdGlvIHN0YXRlIGNoYW5n ZWQgZnJvbSBTVEFSVElORyB0byBPUFRJTUFMLgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiBHUkFJ RCB1c2J1czIgdXNidXMxIHVzYnVzMApHRU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTE5Mjk6IFByb3Zp ZGVyIHJhaWQvcjAgZm9yIHZvbHVtZSBTaUkgQ29uY2F0ZW5hdGlvIGNyZWF0ZWQuCnVodWIwOiA4 IHBvcnRzIHdpdGggOCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRo IDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMiB1c2J1czEgdXNi dXMwCnVnZW4wLjI6IDx2ZW5kb3IgMHgwNDA5PiBhdCB1c2J1czAKdWh1YjM6IDx2ZW5kb3IgMHgw NDA5IHByb2R1Y3QgMHgwMDVhLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMwCnVnZW4yLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czIKdWh1YjQ6IDx2ZW5kb3Ig MHg4MDg3IHByb2R1Y3QgMHgwMDI0LCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4g b24gdXNidXMyCnVnZW4xLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czEKdWh1YjU6IDx2ZW5k b3IgMHg4MDg3IHByb2R1Y3QgMHgwMDI0LCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIg Mj4gb24gdXNidXMxCnVodWIzOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJl ZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czIgdXNidXMxIHVzYnVzMAp1Z2VuMC4zOiA8 dmVuZG9yIDB4MDQwMj4gYXQgdXNidXMwCnVodWI0OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1aHViNTogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMyIHVzYnVzMSB1c2J1czAKdWdlbjAuNDog PHZlbmRvciAweDA0ZDk+IGF0IHVzYnVzMAp1a2JkMDogPHZlbmRvciAweDA0ZDkgVVNCIEtleWJv YXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzMuMTAsIGFkZHIgMz4gb24gdXNidXMwCmtiZDIgYXQg dWtiZDAKdWdlbjIuMzogPHZlbmRvciAweDA5M2E+IGF0IHVzYnVzMgpSb290IG1vdW50IHdhaXRp bmcgZm9yOiB1c2J1czEKdWdlbjEuMzogPEtpbmdzdG9uPiBhdCB1c2J1czEKdW1hc3MwOiA8S2lu Z3N0b24gRGF0YVRyYXZlbGVyTWluaSwgY2xhc3MgMC8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDM+ IG9uIHVzYnVzMQp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweGMxMDAK dW1hc3MwOjEzOjA6IEF0dGFjaGVkIHRvIHNjYnVzMTMKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAg c2NidXMxMyB0YXJnZXQgMCBsdW4gMApkYTA6IDxLaW5nc3RvbiBEYXRhVHJhdmVsZXJNaW5pIFBN QVA+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNDU0kgZGV2aWNlCmRhMDogU2VyaWFsIE51bWJl ciA1Qjc0MTA3MzAwNDQKZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IDE5NjhNQiAoNDAz MDQ2NCA1MTIgYnl0ZSBzZWN0b3JzKQpkYTA6IHF1aXJrcz0weDI8Tk9fNl9CWVRFPgpHRU9NOiBk YTA6IHRoZSBzZWNvbmRhcnkgR1BUIGhlYWRlciBpcyBub3QgaW4gdGhlIGxhc3QgTEJBLgpHRU9N OiBkaXNraWQvRElTSy01Qjc0MTA3MzAwNDQ6IHRoZSBzZWNvbmRhcnkgR1BUIGhlYWRlciBpcyBu b3QgaW4gdGhlIGxhc3QgTEJBLgptb3VudHJvb3Q6IHdhaXRpbmcgZm9yIGRldmljZSAvZGV2L3Vm cy9GcmVlQlNEX0luc3RhbGwuLi4KR0VPTTogZGlza2lkL0RJU0stNUI3NDEwNzMwMDQ0OiB0aGUg c2Vjb25kYXJ5IEdQVCBoZWFkZXIgaXMgbm90IGluIHRoZSBsYXN0IExCQS4KcmFuZG9tOiB1bmJs b2NraW5nIGRldmljZS4KcmUwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKdW1zMDogPHZlbmRv ciAweDA5M2EgVVNCIE9QVElDQUwgTU9VU0UsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMS4wMCwgYWRk ciAzPiBvbiB1c2J1czIKdW1zMDogNSBidXR0b25zIGFuZCBbWFlaVF0gY29vcmRpbmF0ZXMgSUQ9 MAp1aGlkMDogPHZlbmRvciAweDA0ZDkgVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEw LzMuMTAsIGFkZHIgMz4gb24gdXNidXMwCg== --001a1145a91285673d0530aa8a2b Content-Type: application/octet-stream; name=geom_disk_list Content-Disposition: attachment; filename=geom_disk_list Content-Transfer-Encoding: base64 X-Attachment-Id: f_in48iiwf1 R2VvbSBuYW1lOiBhZGEwClByb3ZpZGVyczoKMS4gTmFtZTogYWRhMAogICBNZWRpYXNpemU6IDYw MDIyNDgwODk2ICg1NkcpCiAgIFNlY3RvcnNpemU6IDUxMgogICBNb2RlOiByMXcxZTEKICAgZGVz Y3I6IE9DWi1SRVZPRFJJVkUKICAgbHVuaWQ6IDVlODNhOTdmODM3YmQwN2IKICAgaWRlbnQ6IE9D Wi00STBCMTdRMEgySzc5OTBNCiAgIHJvdGF0aW9ucmF0ZTogMAogICBmd3NlY3RvcnM6IDYzCiAg IGZ3aGVhZHM6IDE2CgpHZW9tIG5hbWU6IGFkYTEKUHJvdmlkZXJzOgoxLiBOYW1lOiBhZGExCiAg IE1lZGlhc2l6ZTogNjAwMjI0ODA4OTYgKDU2RykKICAgU2VjdG9yc2l6ZTogNTEyCiAgIE1vZGU6 IHIxdzFlMQogICBkZXNjcjogT0NaLVJFVk9EUklWRQogICBsdW5pZDogNWU4M2E5N2ZmMmY3MTFj MwogICBpZGVudDogT0NaLTUxM1k5MzFOTFM4TDc5S1kKICAgcm90YXRpb25yYXRlOiAwCiAgIGZ3 c2VjdG9yczogNjMKICAgZndoZWFkczogMTYKCkdlb20gbmFtZTogZGEwClByb3ZpZGVyczoKMS4g TmFtZTogZGEwCiAgIE1lZGlhc2l6ZTogMjA2MzU5NzU2OCAoMS45RykKICAgU2VjdG9yc2l6ZTog NTEyCiAgIE1vZGU6IHIxdzBlMQogICBkZXNjcjogS2luZ3N0b24gRGF0YVRyYXZlbGVyTWluaQog ICBpZGVudDogNUI3NDEwNzMwMDQ0CiAgIHJvdGF0aW9ucmF0ZTogdW5rbm93bgogICBmd3NlY3Rv cnM6IDYzCiAgIGZ3aGVhZHM6IDI1NQoK --001a1145a91285673d0530aa8a2b Content-Type: application/octet-stream; name=raid0_dmesg Content-Disposition: attachment; filename=raid0_dmesg Content-Transfer-Encoding: base64 X-Attachment-Id: f_in48iiwq2 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMS4wLUNVUlJFTlQgIzAgcjI5NzU2MTogTW9uIEFw ciAgNCAyMjo0MjowMCBNU0sgMjAxNgogICAgdGltcEBmYnNkMTE6L3Vzci9vYmovdXNyL3NyYy9z eXMvR0VORVJJQyBhbWQ2NApGcmVlQlNEIGNsYW5nIHZlcnNpb24gMy44LjAgKHRhZ3MvUkVMRUFT RV8zODAvZmluYWwgMjYyNTY0KSAoYmFzZWQgb24gTExWTSAzLjguMCkKV0FSTklORzogV0lUTkVT UyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClZUKHZnYSk6IHJl c29sdXRpb24gNjQweDQ4MApDUFU6IEludGVsKFIpIENvcmUoVE0pIGkzLTIxMjAgQ1BVIEAgMy4z MEdIeiAoMzI5Mi41OS1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbj0iR2VudWluZUludGVsIiAg SWQ9MHgyMDZhNyAgRmFtaWx5PTB4NiAgTW9kZWw9MHgyYSAgU3RlcHBpbmc9NwogIEZlYXR1cmVz PTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxN VFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0Us U1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDFkOWFlM2JmPFNTRTMsUENMTVVMUURR LERURVM2NCxNT04sRFNfQ1BMLFZNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLFBDSUQs U1NFNC4xLFNTRTQuMixQT1BDTlQsVFNDRExULFhTQVZFLE9TWFNBVkUsQVZYPgogIEFNRCBGZWF0 dXJlcz0weDI4MTAwODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgx PExBSEY+CiAgWFNBVkUgRmVhdHVyZXM9MHgxPFhTQVZFT1BUPgogIFZULXg6IFBBVCxITFQsTVRG LFBBVVNFLEVQVCxVRyxWUElECiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ug c3RhdGlzdGljcwpyZWFsIG1lbW9yeSAgPSA4NTg5OTM0NTkyICg4MTkyIE1CKQphdmFpbCBtZW1v cnkgPSA4MjA3MTcxNTg0ICg3ODI2IE1CKQpFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgNjAw CkFDUEkgQVBJQyBUYWJsZTogPEFMQVNLQSBBIE0gST4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vz c29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCAy IGNvcmUocykgeCAyIGhhcmR3YXJlIHRocmVhZHMKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMg MC0yMyBvbiBtb3RoZXJib2FyZApyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVy ZmFjZQprYmQxIGF0IGtiZG11eDAKbmV0bWFwOiBsb2FkZWQgbW9kdWxlCm1vZHVsZV9yZWdpc3Rl cl9pbml0OiBNT0RfTE9BRCAodmVzYSwgMHhmZmZmZmZmZjgwZjA1ZWIwLCAwKSBlcnJvciAxOQp2 dHZnYTA6IDxWVCBWR0EgZHJpdmVyPiBvbiBtb3RoZXJib2FyZApjcnlwdG9zb2Z0MDogPHNvZnR3 YXJlIGNyeXB0bz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IDxBTEFTS0EgQSBNIEk+IG9uIG1vdGhl cmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApj cHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGlt ZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBF VCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVyICJIUEVUIiBm cmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA1NTAKRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVx dWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQyIiBmcmVxdWVu Y3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQ0IiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSA0NDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3 MC0weDc3IGlycSA4IG9uIGFjcGkwCmF0cnRjMDogV2FybmluZzogQ291bGRuJ3QgbWFwIEkvTy4K RXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMAphdHRpbWVyMDog PEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNwaTAKVGltZWNv dW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIg Imk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApUaW1lY291bnRlciAiQUNQ SS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAphY3BpX3RpbWVyMDogPDI0 LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMApwY2li MDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQp2 Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGUwMDAtMHhlMGZmIG1lbSAw eGUwMDAwMDAwLTB4ZWZmZmZmZmYsMHhmN2UwMDAwMC0weGY3ZTNmZmZmIGlycSAxNiBhdCBkZXZp Y2UgMC4wIG9uIHBjaTEKdmdhcGNpMDogQm9vdCB2aWRlbyBkZXZpY2UKaGRhYzA6IDxBVEkgKDB4 YWFiMCkgSERBIENvbnRyb2xsZXI+IG1lbSAweGY3ZTYwMDAwLTB4ZjdlNjNmZmYgaXJxIDE3IGF0 IGRldmljZSAwLjEgb24gcGNpMQpoZGFjMDogaGRhY19nZXRfY2FwYWJpbGl0aWVzOiBJbnZhbGlk IGNvcmIgc2l6ZSAoMCkKZGV2aWNlX2F0dGFjaDogaGRhYzAgYXR0YWNoIHJldHVybmVkIDYKeGhj aTA6IDxJbnRlbCBQYW50aGVyIFBvaW50IFVTQiAzLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMDAw MDAtMHhmN2YwZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIwLjAgb24gcGNpMAp4aGNpMDogMzIgYnl0 ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCnhoY2kwOiBQb3J0IHJvdXRpbmcgbWFzayBzZXQg dG8gMHhmZmZmZmZmZgp1c2J1czAgb24geGhjaTAKcGNpMDogPHNpbXBsZSBjb21tcz4gYXQgZGV2 aWNlIDIyLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKZWhjaTA6IDxJbnRlbCBQYW50aGVyIFBvaW50 IFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMTgwMDAtMHhmN2YxODNmZiBpcnEgMTYgYXQg ZGV2aWNlIDI2LjAgb24gcGNpMAp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMxIG9uIGVo Y2kwCmhkYWMwOiA8SW50ZWwgUGFudGhlciBQb2ludCBIREEgQ29udHJvbGxlcj4gbWVtIDB4Zjdm MTAwMDAtMHhmN2YxM2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApwY2liMjogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8UENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBk ZXZpY2UgMC4wIG9uIHBjaTIKcGNpMzogPFBDSSBidXM+IG9uIHBjaWIzCnNpaXMwOiA8U2lJMzEy NCBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhkMDAwLTB4ZDAwZiBtZW0gMHhmN2Q4ODAwMC0weGY3 ZDg4MDdmLDB4ZjdkODAwMDAtMHhmN2Q4N2ZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kz CnNpaXNjaDA6IDxTSUlTIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBzaWlzMApzaWlzY2gxOiA8 U0lJUyBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gc2lpczAKc2lpc2NoMjogPFNJSVMgY2hhbm5l bD4gYXQgY2hhbm5lbCAyIG9uIHNpaXMwCnNpaXNjaDM6IDxTSUlTIGNoYW5uZWw+IGF0IGNoYW5u ZWwgMyBvbiBzaWlzMApwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZp Y2UgMjguNCBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CmFoY2kwOiA8QVNN ZWRpYSBBU00xMDYxIEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4YzA1MC0weGMwNTcsMHhj MDQwLTB4YzA0MywweGMwMzAtMHhjMDM3LDB4YzAyMC0weGMwMjMsMHhjMDAwLTB4YzAxZiBtZW0g MHhmN2MwMDAwMC0weGY3YzAwMWZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTQKYWhjaTA6 IEFIQ0kgdjEuMjAgd2l0aCAyIDZHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgc3VwcG9ydGVk CmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAphaGNpY2gxOiA8 QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTAKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNQpyZTA6IDxSZWFsVGVrIDgxNjgvODExMSBCL0MvQ1AvRC9EUC9FL0YvRyBQQ0ll IEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHhiMDAwLTB4YjBmZiBtZW0gMHhmMDAwNDAwMC0weGYw MDA0ZmZmLDB4ZjAwMDAwMDAtMHhmMDAwM2ZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2k1 CnJlMDogVXNpbmcgMSBNU0ktWCBtZXNzYWdlCnJlMDogQ2hpcCByZXYuIDB4MmM4MDAwMDAKcmUw OiBNQUMgcmV2LiAweDAwMTAwMDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiByZTAKcmdlcGh5MDog PFJUTDgxNjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9u IG1paWJ1czAKcmdlcGh5MDogIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMGJhc2VULUZE WC1mbG93LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMGJhc2VUWC1GRFgtZmxvdywgMTAw MGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAxMDAwYmFzZVQtRkRYLW1h c3RlciwgMTAwMGJhc2VULUZEWC1mbG93LCAxMDAwYmFzZVQtRkRYLWZsb3ctbWFzdGVyLCBhdXRv LCBhdXRvLWZsb3cKcmUwOiBVc2luZyBkZWZhdWx0cyBmb3IgVFNPOiA2NTUxOC8zNS8yMDQ4CnJl MDogRXRoZXJuZXQgYWRkcmVzczogYmM6NWY6ZjQ6Mzc6NDM6ZWYKcmUwOiBuZXRtYXAgcXVldWVz L3Nsb3RzOiBUWCAxLzI1NiwgUlggMS8yNTYKZWhjaTE6IDxJbnRlbCBQYW50aGVyIFBvaW50IFVT QiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMTcwMDAtMHhmN2YxNzNmZiBpcnEgMjMgYXQgZGV2 aWNlIDI5LjAgb24gcGNpMAp1c2J1czI6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMyIG9uIGVoY2kx CnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2k2 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZp Y2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphaGNpMTogPEludGVsIFBh bnRoZXIgUG9pbnQgQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhmMDcwLTB4ZjA3NywweGYw NjAtMHhmMDYzLDB4ZjA1MC0weGYwNTcsMHhmMDQwLTB4ZjA0MywweGYwMjAtMHhmMDNmIG1lbSAw eGY3ZjE2MDAwLTB4ZjdmMTY3ZmYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYWhjaTE6 IEFIQ0kgdjEuMzAgd2l0aCA2IDZHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgbm90IHN1cHBv cnRlZAphaGNpY2gyOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTEKYWhjaWNo MzogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kxCmFoY2ljaDQ6IDxBSENJIGNo YW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMQphaGNpY2g1OiA8QUhDSSBjaGFubmVsPiBhdCBj aGFubmVsIDMgb24gYWhjaTEKYWhjaWNoNjogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9u IGFoY2kxCmFoY2ljaDc6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNpMQphaGNp ZW0wOiA8QUhDSSBlbmNsb3N1cmUgbWFuYWdlbWVudCBicmlkZ2U+IG9uIGFoY2kxCmFjcGlfYnV0 dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcHBjMTogPFBhcmFsbGVsIHBvcnQ+IHBvcnQg MHgzNzgtMHgzN2YsMHg3NzgtMHg3N2YgaXJxIDUgZHJxIDMgb24gYWNwaTAKcHBjMTogU01DLWxp a2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMTog RklGTyB3aXRoIDE2LzE2LzkgYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQg YnVzPiBvbiBwcGMxCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRy aXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMAp1YXJ0MDogPDE2NTUwIG9y IGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApv cm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2ZmZmYsMHhkMDAwMC0w eGQ0ZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQg cG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRr YmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IGNhbm5vdCBy ZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5 IENvbnRyb2w+IG9uIGNwdTAKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MQplc3QyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9s PiBvbiBjcHUyCmVzdDM6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTMKKG5vcGVyaXBoOnNpaXNjaDA6MDotMTpmZmZmZmZmZik6IHJlc2NhbiBhbHJlYWR5IHF1 ZXVlZAoobm9wZXJpcGg6c2lpc2NoMTowOi0xOmZmZmZmZmZmKTogcmVzY2FuIGFscmVhZHkgcXVl dWVkCnVzYnVzMDogNS4wR2JwcyBTdXBlciBTcGVlZCBVU0IgdjMuMApUaW1lY291bnRlcnMgdGlj ayBldmVyeSAxLjAwMCBtc2VjCmhkYWNjMDogPFJlYWx0ZWsgQUxDNjYyIEhEQSBDT0RFQz4gYXQg Y2FkIDAgb24gaGRhYzAKaGRhYTA6IDxSZWFsdGVrIEFMQzY2MiBBdWRpbyBGdW5jdGlvbiBHcm91 cD4gYXQgbmlkIDEgb24gaGRhY2MwCnBjbTA6IDxSZWFsdGVrIEFMQzY2MiAoUmVhciBBbmFsb2cp PiBhdCBuaWQgMjAgYW5kIDI0LDI2IG9uIGhkYWEwCnBjbTE6IDxSZWFsdGVrIEFMQzY2MiAoRnJv bnQgQW5hbG9nKT4gYXQgbmlkIDI3IGFuZCAyNSBvbiBoZGFhMAp1c2J1czE6IDQ4ME1icHMgSGln aCBTcGVlZCBVU0IgdjIuMAp1c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2Vu MC4xOiA8MHg4MDg2PiBhdCB1c2J1czAKdWh1YjA6IDwweDgwODYgWEhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMi4xOiA8SW50ZWw+ IGF0IHVzYnVzMgp1aHViMTogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1 YjI6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMxCnNlczAgYXQgYWhjaWVtMCBidXMgMCBzY2J1czEyIHRhcmdldCAwIGx1biAw CnNlczA6IDxBSENJIFNHUElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4wMCBk ZXZpY2UKc2VzMDogU0VNQiBTRVMgRGV2aWNlCmFkYTAgYXQgc2lpc2NoMCBidXMgMCBzY2J1czAg dGFyZ2V0IDAgbHVuIDAKYWRhMDogPE9DWi1SRVZPRFJJVkUgMS4zNz4gQVRBOC1BQ1MgU0FUQSAy LnggZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1iZXIgT0NaLTRJMEIxN1EwSDJLNzk5ME0KYWRhMDog MzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFk YTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiA1NzI0MU1CICgxMTcyMzE0MDggNTEy IGJ5dGUgc2VjdG9ycykKYWRhMSBhdCBzaWlzY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4g MAphZGExOiA8T0NaLVJFVk9EUklWRSAxLjM3PiBBVEE4LUFDUyBTQVRBIDIueCBkZXZpY2UKYWRh MTogU2VyaWFsIE51bWJlciBPQ1otNTEzWTkzMU5MUzhMNzlLWQphZGExOiAzMDAuMDAwTUIvcyB0 cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMTogQ29tbWFuZCBR dWV1ZWluZyBlbmFibGVkCmFkYTE6IDU3MjQxTUIgKDExNzIzMTQwOCA1MTIgYnl0ZSBzZWN0b3Jz KQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNNUDog QVAgQ1BVICMyIExhdW5jaGVkIQpHRU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTMxMTQ6IEFycmF5IFNp SS0xNjA0MDYyMTMxMTQgY3JlYXRlZC4KVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAx NjQ2Mjk3MzEwIEh6IHF1YWxpdHkgMTAwMApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVk LCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KR0VPTV9SQUlEOiBTaUktMTYwNDA2MjEzMTE0 OiBEaXNrIGFkYTAgc3RhdGUgY2hhbmdlZCBmcm9tIE5PTkUgdG8gQUNUSVZFLgpHRU9NX1JBSUQ6 IFNpSS0xNjA0MDYyMTMxMTQ6IFN1YmRpc2sgU2lJIFJhaWQwIFNldDowLWFkYTAgc3RhdGUgY2hh bmdlZCBmcm9tIE5PTkUgdG8gU1RBTEUuCkdFT01fUkFJRDogU2lJLTE2MDQwNjIxMzExNDogRGlz ayBhZGExIHN0YXRlIGNoYW5nZWQgZnJvbSBOT05FIHRvIEFDVElWRS4KVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi91ZnMvRnJlZUJTRF9JbnN0YWxsIFtybyxub2F0aW1lXS4uLgpH RU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTMxMTQ6IFN1YmRpc2sgU2lJIFJhaWQwIFNldDoxLWFkYTEg c3RhdGUgY2hhbmdlZCBmcm9tIE5PTkUgdG8gU1RBTEUuCkdFT01fUkFJRDogU2lJLTE2MDQwNjIx MzExNDogQXJyYXkgc3RhcnRlZC4KR0VPTV9SQUlEOiBTaUktMTYwNDA2MjEzMTE0OiBTdWJkaXNr IFNpSSBSYWlkMCBTZXQ6MC1hZGEwIHN0YXRlIGNoYW5nZWQgZnJvbSBTVEFMRSB0byBBQ1RJVkUu CkdFT01fUkFJRDogU2lJLTE2MDQwNjIxMzExNDogU3ViZGlzayBTaUkgUmFpZDAgU2V0OjEtYWRh MSBzdGF0ZSBjaGFuZ2VkIGZyb20gU1RBTEUgdG8gQUNUSVZFLgpHRU9NX1JBSUQ6IFNpSS0xNjA0 MDYyMTMxMTQ6IFZvbHVtZSBTaUkgUmFpZDAgU2V0IHN0YXRlIGNoYW5nZWQgZnJvbSBTVEFSVElO RyB0byBPUFRJTUFMLgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiBHUkFJRCB1c2J1czIgdXNidXMx IHVzYnVzMApHRU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTMxMTQ6IFByb3ZpZGVyIHJhaWQvcjAgZm9y IHZvbHVtZSBTaUkgUmFpZDAgU2V0IGNyZWF0ZWQuCnVodWIwOiA4IHBvcnRzIHdpdGggOCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJv b3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMiB1c2J1czEgdXNidXMwCnVnZW4wLjI6IDx2ZW5k b3IgMHgwNDA5PiBhdCB1c2J1czAKdWh1YjM6IDx2ZW5kb3IgMHgwNDA5IHByb2R1Y3QgMHgwMDVh LCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4yLjI6IDx2 ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czIKdWh1YjQ6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgw MDI0LCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMyCnVnZW4xLjI6 IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czEKdWh1YjU6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3Qg MHgwMDI0LCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMxCnVodWIz OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRp bmcgZm9yOiB1c2J1czIgdXNidXMxIHVzYnVzMAp1Z2VuMC4zOiA8dmVuZG9yIDB4MDQwMj4gYXQg dXNidXMwCnVodWI0OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHVi NTogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0 aW5nIGZvcjogdXNidXMyIHVzYnVzMSB1c2J1czAKdWdlbjAuNDogPHZlbmRvciAweDA0ZDk+IGF0 IHVzYnVzMAp1a2JkMDogPHZlbmRvciAweDA0ZDkgVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJl diAxLjEwLzMuMTAsIGFkZHIgMz4gb24gdXNidXMwCmtiZDIgYXQgdWtiZDAKdWdlbjIuMzogPHZl bmRvciAweDA5M2E+IGF0IHVzYnVzMgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEKdWdl bjEuMzogPEtpbmdzdG9uPiBhdCB1c2J1czEKdW1hc3MwOiA8S2luZ3N0b24gRGF0YVRyYXZlbGVy TWluaSwgY2xhc3MgMC8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDM+IG9uIHVzYnVzMQp1bWFzczA6 ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweGMxMDAKdW1hc3MwOjEzOjA6IEF0dGFj aGVkIHRvIHNjYnVzMTMKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXMxMyB0YXJnZXQgMCBs dW4gMApkYTA6IDxLaW5nc3RvbiBEYXRhVHJhdmVsZXJNaW5pIFBNQVA+IFJlbW92YWJsZSBEaXJl Y3QgQWNjZXNzIFNDU0kgZGV2aWNlCmRhMDogU2VyaWFsIE51bWJlciA1Qjc0MTA3MzAwNDQKZGEw OiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IDE5NjhNQiAoNDAzMDQ2NCA1MTIgYnl0ZSBzZWN0 b3JzKQpkYTA6IHF1aXJrcz0weDI8Tk9fNl9CWVRFPgpHRU9NOiBkYTA6IHRoZSBzZWNvbmRhcnkg R1BUIGhlYWRlciBpcyBub3QgaW4gdGhlIGxhc3QgTEJBLgpHRU9NOiBkaXNraWQvRElTSy01Qjc0 MTA3MzAwNDQ6IHRoZSBzZWNvbmRhcnkgR1BUIGhlYWRlciBpcyBub3QgaW4gdGhlIGxhc3QgTEJB Lgptb3VudHJvb3Q6IHdhaXRpbmcgZm9yIGRldmljZSAvZGV2L3Vmcy9GcmVlQlNEX0luc3RhbGwu Li4KR0VPTTogZGlza2lkL0RJU0stNUI3NDEwNzMwMDQ0OiB0aGUgc2Vjb25kYXJ5IEdQVCBoZWFk ZXIgaXMgbm90IGluIHRoZSBsYXN0IExCQS4KcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KcmUw OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKdW1zMDogPHZlbmRvciAweDA5M2EgVVNCIE9QVElD QUwgTU9VU0UsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMS4wMCwgYWRkciAzPiBvbiB1c2J1czIKdW1z MDogNSBidXR0b25zIGFuZCBbWFlaVF0gY29vcmRpbmF0ZXMgSUQ9MAp1aGlkMDogPHZlbmRvciAw eDA0ZDkgVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzMuMTAsIGFkZHIgMz4gb24g dXNidXMwCnJlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KcmUwOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gVVAK --001a1145a91285673d0530aa8a2b Content-Type: application/octet-stream; name=raid1_dmesg Content-Disposition: attachment; filename=raid1_dmesg Content-Transfer-Encoding: base64 X-Attachment-Id: f_in48iiwx3 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMS4wLUNVUlJFTlQgIzAgcjI5NzU2MTogTW9uIEFw ciAgNCAyMjo0MjowMCBNU0sgMjAxNgogICAgdGltcEBmYnNkMTE6L3Vzci9vYmovdXNyL3NyYy9z eXMvR0VORVJJQyBhbWQ2NApGcmVlQlNEIGNsYW5nIHZlcnNpb24gMy44LjAgKHRhZ3MvUkVMRUFT RV8zODAvZmluYWwgMjYyNTY0KSAoYmFzZWQgb24gTExWTSAzLjguMCkKV0FSTklORzogV0lUTkVT UyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClZUKHZnYSk6IHJl c29sdXRpb24gNjQweDQ4MApDUFU6IEludGVsKFIpIENvcmUoVE0pIGkzLTIxMjAgQ1BVIEAgMy4z MEdIeiAoMzI5Mi41OS1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbj0iR2VudWluZUludGVsIiAg SWQ9MHgyMDZhNyAgRmFtaWx5PTB4NiAgTW9kZWw9MHgyYSAgU3RlcHBpbmc9NwogIEZlYXR1cmVz PTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxN VFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0Us U1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDFkOWFlM2JmPFNTRTMsUENMTVVMUURR LERURVM2NCxNT04sRFNfQ1BMLFZNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLFBDSUQs U1NFNC4xLFNTRTQuMixQT1BDTlQsVFNDRExULFhTQVZFLE9TWFNBVkUsQVZYPgogIEFNRCBGZWF0 dXJlcz0weDI4MTAwODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgx PExBSEY+CiAgWFNBVkUgRmVhdHVyZXM9MHgxPFhTQVZFT1BUPgogIFZULXg6IFBBVCxITFQsTVRG LFBBVVNFLEVQVCxVRyxWUElECiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ug c3RhdGlzdGljcwpyZWFsIG1lbW9yeSAgPSA4NTg5OTM0NTkyICg4MTkyIE1CKQphdmFpbCBtZW1v cnkgPSA4MjA3MTcxNTg0ICg3ODI2IE1CKQpFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgNjAw CkFDUEkgQVBJQyBUYWJsZTogPEFMQVNLQSBBIE0gST4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vz c29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCAy IGNvcmUocykgeCAyIGhhcmR3YXJlIHRocmVhZHMKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMg MC0yMyBvbiBtb3RoZXJib2FyZApyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVy ZmFjZQprYmQxIGF0IGtiZG11eDAKbmV0bWFwOiBsb2FkZWQgbW9kdWxlCm1vZHVsZV9yZWdpc3Rl cl9pbml0OiBNT0RfTE9BRCAodmVzYSwgMHhmZmZmZmZmZjgwZjA1ZWIwLCAwKSBlcnJvciAxOQp2 dHZnYTA6IDxWVCBWR0EgZHJpdmVyPiBvbiBtb3RoZXJib2FyZApjcnlwdG9zb2Z0MDogPHNvZnR3 YXJlIGNyeXB0bz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IDxBTEFTS0EgQSBNIEk+IG9uIG1vdGhl cmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApj cHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGlt ZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBF VCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVyICJIUEVUIiBm cmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA1NTAKRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVx dWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQyIiBmcmVxdWVu Y3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQ0IiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSA0NDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3 MC0weDc3IGlycSA4IG9uIGFjcGkwCmF0cnRjMDogV2FybmluZzogQ291bGRuJ3QgbWFwIEkvTy4K RXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMAphdHRpbWVyMDog PEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNwaTAKVGltZWNv dW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIg Imk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApUaW1lY291bnRlciAiQUNQ SS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAphY3BpX3RpbWVyMDogPDI0 LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMApwY2li MDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQp2 Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGUwMDAtMHhlMGZmIG1lbSAw eGUwMDAwMDAwLTB4ZWZmZmZmZmYsMHhmN2UwMDAwMC0weGY3ZTNmZmZmIGlycSAxNiBhdCBkZXZp Y2UgMC4wIG9uIHBjaTEKdmdhcGNpMDogQm9vdCB2aWRlbyBkZXZpY2UKaGRhYzA6IDxBVEkgKDB4 YWFiMCkgSERBIENvbnRyb2xsZXI+IG1lbSAweGY3ZTYwMDAwLTB4ZjdlNjNmZmYgaXJxIDE3IGF0 IGRldmljZSAwLjEgb24gcGNpMQpoZGFjMDogaGRhY19nZXRfY2FwYWJpbGl0aWVzOiBJbnZhbGlk IGNvcmIgc2l6ZSAoMCkKZGV2aWNlX2F0dGFjaDogaGRhYzAgYXR0YWNoIHJldHVybmVkIDYKeGhj aTA6IDxJbnRlbCBQYW50aGVyIFBvaW50IFVTQiAzLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMDAw MDAtMHhmN2YwZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIwLjAgb24gcGNpMAp4aGNpMDogMzIgYnl0 ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCnhoY2kwOiBQb3J0IHJvdXRpbmcgbWFzayBzZXQg dG8gMHhmZmZmZmZmZgp1c2J1czAgb24geGhjaTAKcGNpMDogPHNpbXBsZSBjb21tcz4gYXQgZGV2 aWNlIDIyLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKZWhjaTA6IDxJbnRlbCBQYW50aGVyIFBvaW50 IFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMTgwMDAtMHhmN2YxODNmZiBpcnEgMTYgYXQg ZGV2aWNlIDI2LjAgb24gcGNpMAp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMxIG9uIGVo Y2kwCmhkYWMwOiA8SW50ZWwgUGFudGhlciBQb2ludCBIREEgQ29udHJvbGxlcj4gbWVtIDB4Zjdm MTAwMDAtMHhmN2YxM2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApwY2liMjogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8UENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBk ZXZpY2UgMC4wIG9uIHBjaTIKcGNpMzogPFBDSSBidXM+IG9uIHBjaWIzCnNpaXMwOiA8U2lJMzEy NCBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhkMDAwLTB4ZDAwZiBtZW0gMHhmN2Q4ODAwMC0weGY3 ZDg4MDdmLDB4ZjdkODAwMDAtMHhmN2Q4N2ZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kz CnNpaXNjaDA6IDxTSUlTIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBzaWlzMApzaWlzY2gxOiA8 U0lJUyBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gc2lpczAKc2lpc2NoMjogPFNJSVMgY2hhbm5l bD4gYXQgY2hhbm5lbCAyIG9uIHNpaXMwCnNpaXNjaDM6IDxTSUlTIGNoYW5uZWw+IGF0IGNoYW5u ZWwgMyBvbiBzaWlzMApwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZp Y2UgMjguNCBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CmFoY2kwOiA8QVNN ZWRpYSBBU00xMDYxIEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4YzA1MC0weGMwNTcsMHhj MDQwLTB4YzA0MywweGMwMzAtMHhjMDM3LDB4YzAyMC0weGMwMjMsMHhjMDAwLTB4YzAxZiBtZW0g MHhmN2MwMDAwMC0weGY3YzAwMWZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTQKYWhjaTA6 IEFIQ0kgdjEuMjAgd2l0aCAyIDZHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgc3VwcG9ydGVk CmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAphaGNpY2gxOiA8 QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTAKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNQpyZTA6IDxSZWFsVGVrIDgxNjgvODExMSBCL0MvQ1AvRC9EUC9FL0YvRyBQQ0ll IEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHhiMDAwLTB4YjBmZiBtZW0gMHhmMDAwNDAwMC0weGYw MDA0ZmZmLDB4ZjAwMDAwMDAtMHhmMDAwM2ZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2k1 CnJlMDogVXNpbmcgMSBNU0ktWCBtZXNzYWdlCnJlMDogQ2hpcCByZXYuIDB4MmM4MDAwMDAKcmUw OiBNQUMgcmV2LiAweDAwMTAwMDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiByZTAKcmdlcGh5MDog PFJUTDgxNjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9u IG1paWJ1czAKcmdlcGh5MDogIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMGJhc2VULUZE WC1mbG93LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMGJhc2VUWC1GRFgtZmxvdywgMTAw MGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAxMDAwYmFzZVQtRkRYLW1h c3RlciwgMTAwMGJhc2VULUZEWC1mbG93LCAxMDAwYmFzZVQtRkRYLWZsb3ctbWFzdGVyLCBhdXRv LCBhdXRvLWZsb3cKcmUwOiBVc2luZyBkZWZhdWx0cyBmb3IgVFNPOiA2NTUxOC8zNS8yMDQ4CnJl MDogRXRoZXJuZXQgYWRkcmVzczogYmM6NWY6ZjQ6Mzc6NDM6ZWYKcmUwOiBuZXRtYXAgcXVldWVz L3Nsb3RzOiBUWCAxLzI1NiwgUlggMS8yNTYKZWhjaTE6IDxJbnRlbCBQYW50aGVyIFBvaW50IFVT QiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjdmMTcwMDAtMHhmN2YxNzNmZiBpcnEgMjMgYXQgZGV2 aWNlIDI5LjAgb24gcGNpMAp1c2J1czI6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMyIG9uIGVoY2kx CnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2k2 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZp Y2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphaGNpMTogPEludGVsIFBh bnRoZXIgUG9pbnQgQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhmMDcwLTB4ZjA3NywweGYw NjAtMHhmMDYzLDB4ZjA1MC0weGYwNTcsMHhmMDQwLTB4ZjA0MywweGYwMjAtMHhmMDNmIG1lbSAw eGY3ZjE2MDAwLTB4ZjdmMTY3ZmYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYWhjaTE6 IEFIQ0kgdjEuMzAgd2l0aCA2IDZHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgbm90IHN1cHBv cnRlZAphaGNpY2gyOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTEKYWhjaWNo MzogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kxCmFoY2ljaDQ6IDxBSENJIGNo YW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMQphaGNpY2g1OiA8QUhDSSBjaGFubmVsPiBhdCBj aGFubmVsIDMgb24gYWhjaTEKYWhjaWNoNjogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9u IGFoY2kxCmFoY2ljaDc6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNpMQphaGNp ZW0wOiA8QUhDSSBlbmNsb3N1cmUgbWFuYWdlbWVudCBicmlkZ2U+IG9uIGFoY2kxCmFjcGlfYnV0 dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcHBjMTogPFBhcmFsbGVsIHBvcnQ+IHBvcnQg MHgzNzgtMHgzN2YsMHg3NzgtMHg3N2YgaXJxIDUgZHJxIDMgb24gYWNwaTAKcHBjMTogU01DLWxp a2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMTog RklGTyB3aXRoIDE2LzE2LzkgYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQg YnVzPiBvbiBwcGMxCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRy aXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMAp1YXJ0MDogPDE2NTUwIG9y IGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApv cm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2ZmZmYsMHhkMDAwMC0w eGQ0ZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQg cG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRr YmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IGNhbm5vdCBy ZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5 IENvbnRyb2w+IG9uIGNwdTAKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MQplc3QyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9s PiBvbiBjcHUyCmVzdDM6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTMKKG5vcGVyaXBoOnNpaXNjaDA6MDotMTpmZmZmZmZmZik6IHJlc2NhbiBhbHJlYWR5IHF1 ZXVlZAoobm9wZXJpcGg6c2lpc2NoMTowOi0xOmZmZmZmZmZmKTogcmVzY2FuIGFscmVhZHkgcXVl dWVkCnVzYnVzMDogNS4wR2JwcyBTdXBlciBTcGVlZCBVU0IgdjMuMApUaW1lY291bnRlcnMgdGlj ayBldmVyeSAxLjAwMCBtc2VjCmhkYWNjMDogPFJlYWx0ZWsgQUxDNjYyIEhEQSBDT0RFQz4gYXQg Y2FkIDAgb24gaGRhYzAKaGRhYTA6IDxSZWFsdGVrIEFMQzY2MiBBdWRpbyBGdW5jdGlvbiBHcm91 cD4gYXQgbmlkIDEgb24gaGRhY2MwCnBjbTA6IDxSZWFsdGVrIEFMQzY2MiAoUmVhciBBbmFsb2cp PiBhdCBuaWQgMjAgYW5kIDI0LDI2IG9uIGhkYWEwCnBjbTE6IDxSZWFsdGVrIEFMQzY2MiAoRnJv bnQgQW5hbG9nKT4gYXQgbmlkIDI3IGFuZCAyNSBvbiBoZGFhMAp1c2J1czE6IDQ4ME1icHMgSGln aCBTcGVlZCBVU0IgdjIuMAp1c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2Vu MC4xOiA8MHg4MDg2PiBhdCB1c2J1czAKdWh1YjA6IDwweDgwODYgWEhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMi4xOiA8SW50ZWw+ IGF0IHVzYnVzMgp1aHViMTogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1 YjI6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMxCnNlczAgYXQgYWhjaWVtMCBidXMgMCBzY2J1czEyIHRhcmdldCAwIGx1biAw CnNlczA6IDxBSENJIFNHUElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4wMCBk ZXZpY2UKc2VzMDogU0VNQiBTRVMgRGV2aWNlCmFkYTAgYXQgc2lpc2NoMCBidXMgMCBzY2J1czAg dGFyZ2V0IDAgbHVuIDAKYWRhMDogPE9DWi1SRVZPRFJJVkUgMS4zNz4gQVRBOC1BQ1MgU0FUQSAy LnggZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1iZXIgT0NaLTRJMEIxN1EwSDJLNzk5ME0KYWRhMDog MzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFk YTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiA1NzI0MU1CICgxMTcyMzE0MDggNTEy IGJ5dGUgc2VjdG9ycykKYWRhMSBhdCBzaWlzY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4g MAphZGExOiA8T0NaLVJFVk9EUklWRSAxLjM3PiBBVEE4LUFDUyBTQVRBIDIueCBkZXZpY2UKYWRh MTogU2VyaWFsIE51bWJlciBPQ1otNTEzWTkzMU5MUzhMNzlLWQphZGExOiAzMDAuMDAwTUIvcyB0 cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMTogQ29tbWFuZCBR dWV1ZWluZyBlbmFibGVkCmFkYTE6IDU3MjQxTUIgKDExNzIzMTQwOCA1MTIgYnl0ZSBzZWN0b3Jz KQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNNUDog QVAgQ1BVICMyIExhdW5jaGVkIQpHRU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTI0NTA6IEFycmF5IFNp SS0xNjA0MDYyMTI0NTAgY3JlYXRlZC4KVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAx NjQ2Mjk2MDU0IEh6IHF1YWxpdHkgMTAwMApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVk LCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KR0VPTV9SQUlEOiBTaUktMTYwNDA2MjEyNDUw OiBEaXNrIGFkYTAgc3RhdGUgY2hhbmdlZCBmcm9tIE5PTkUgdG8gQUNUSVZFLgpUcnlpbmcgdG8g bW91bnQgcm9vdCBmcm9tIHVmczovZGV2L3Vmcy9GcmVlQlNEX0luc3RhbGwgW3JvLG5vYXRpbWVd Li4uCkdFT01fUkFJRDogU2lJLTE2MDQwNjIxMjQ1MDogU3ViZGlzayBTaUkgUmFpZDEgU2V0OjAt YWRhMCBzdGF0ZSBjaGFuZ2VkIGZyb20gTk9ORSB0byBBQ1RJVkUuCkdFT01fUkFJRDogU2lJLTE2 MDQwNjIxMjQ1MDogRGlzayBhZGExIHN0YXRlIGNoYW5nZWQgZnJvbSBOT05FIHRvIEFDVElWRS4K R0VPTV9SQUlEOiBTaUktMTYwNDA2MjEyNDUwOiBTdWJkaXNrIFNpSSBSYWlkMSBTZXQ6MS1hZGEx IHN0YXRlIGNoYW5nZWQgZnJvbSBOT05FIHRvIEFDVElWRS4KR0VPTV9SQUlEOiBTaUktMTYwNDA2 MjEyNDUwOiBBcnJheSBzdGFydGVkLgpHRU9NX1JBSUQ6IFNpSS0xNjA0MDYyMTI0NTA6IFZvbHVt ZSBTaUkgUmFpZDEgU2V0IHN0YXRlIGNoYW5nZWQgZnJvbSBTVEFSVElORyB0byBPUFRJTUFMLgpS b290IG1vdW50IHdhaXRpbmcgZm9yOiBHUkFJRCB1c2J1czIgdXNidXMxIHVzYnVzMApHRU9NX1JB SUQ6IFNpSS0xNjA0MDYyMTI0NTA6IFByb3ZpZGVyIHJhaWQvcjAgZm9yIHZvbHVtZSBTaUkgUmFp ZDEgU2V0IGNyZWF0ZWQuCkdFT006IHJhaWQvcjA6IGNvcnJ1cHQgb3IgaW52YWxpZCBHUFQgZGV0 ZWN0ZWQuCkdFT006IHJhaWQvcjA6IEdQVCByZWplY3RlZCAtLSBtYXkgbm90IGJlIHJlY292ZXJh YmxlLgp1aHViMDogOCBwb3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIyOiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1 czIgdXNidXMxIHVzYnVzMAp1Z2VuMC4yOiA8dmVuZG9yIDB4MDQwOT4gYXQgdXNidXMwCnVodWIz OiA8dmVuZG9yIDB4MDQwOSBwcm9kdWN0IDB4MDA1YSwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMi4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMyCnVo dWI0OiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyNCwgY2xhc3MgOS8wLCByZXYgMi4wMC8w LjAwLCBhZGRyIDI+IG9uIHVzYnVzMgp1aHViMzogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKdWdlbjEuMjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMQp1aHViNTogPHZl bmRvciAweDgwODcgcHJvZHVjdCAweDAwMjQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRk ciAyPiBvbiB1c2J1czEKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMyIHVzYnVzMSB1c2J1 czAKdWdlbjAuMzogPHZlbmRvciAweDA0MDI+IGF0IHVzYnVzMAp1aHViNDogNiBwb3J0cyB3aXRo IDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMiB1c2J1czEgdXNi dXMwCnVnZW4wLjQ6IDx2ZW5kb3IgMHgwNGQ5PiBhdCB1c2J1czAKdWtiZDA6IDx2ZW5kb3IgMHgw NGQ5IFVTQiBLZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMS4xMC8zLjEwLCBhZGRyIDM+IG9uIHVz YnVzMAprYmQyIGF0IHVrYmQwCnVnZW4yLjM6IDx2ZW5kb3IgMHgwOTNhPiBhdCB1c2J1czIKUm9v dCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxCnVnZW4xLjM6IDxLaW5nc3Rvbj4gYXQgdXNidXMx CnVtYXNzMDogPEtpbmdzdG9uIERhdGFUcmF2ZWxlck1pbmksIGNsYXNzIDAvMCwgcmV2IDIuMDAv MS4wMCwgYWRkciAzPiBvbiB1c2J1czEKdW1hc3MwOiAgU0NTSSBvdmVyIEJ1bGstT25seTsgcXVp cmtzID0gMHhjMTAwCnVtYXNzMDoxMzowOiBBdHRhY2hlZCB0byBzY2J1czEzCmRhMCBhdCB1bWFz cy1zaW0wIGJ1cyAwIHNjYnVzMTMgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8S2luZ3N0b24gRGF0YVRy YXZlbGVyTWluaSBQTUFQPiBSZW1vdmFibGUgRGlyZWN0IEFjY2VzcyBTQ1NJIGRldmljZQpkYTA6 IFNlcmlhbCBOdW1iZXIgNUI3NDEwNzMwMDQ0CmRhMDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEw OiAxOTY4TUIgKDQwMzA0NjQgNTEyIGJ5dGUgc2VjdG9ycykKZGEwOiBxdWlya3M9MHgyPE5PXzZf QllURT4KR0VPTTogZGEwOiB0aGUgc2Vjb25kYXJ5IEdQVCBoZWFkZXIgaXMgbm90IGluIHRoZSBs YXN0IExCQS4KR0VPTTogZGlza2lkL0RJU0stNUI3NDEwNzMwMDQ0OiB0aGUgc2Vjb25kYXJ5IEdQ VCBoZWFkZXIgaXMgbm90IGluIHRoZSBsYXN0IExCQS4KbW91bnRyb290OiB3YWl0aW5nIGZvciBk ZXZpY2UgL2Rldi91ZnMvRnJlZUJTRF9JbnN0YWxsLi4uCkdFT006IGRpc2tpZC9ESVNLLTVCNzQx MDczMDA0NDogdGhlIHNlY29uZGFyeSBHUFQgaGVhZGVyIGlzIG5vdCBpbiB0aGUgbGFzdCBMQkEu CnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuCnJlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQ CnVtczA6IDx2ZW5kb3IgMHgwOTNhIFVTQiBPUFRJQ0FMIE1PVVNFLCBjbGFzcyAwLzAsIHJldiAx LjEwLzEuMDAsIGFkZHIgMz4gb24gdXNidXMyCnVtczA6IDUgYnV0dG9ucyBhbmQgW1hZWlRdIGNv b3JkaW5hdGVzIElEPTAKdWhpZDA6IDx2ZW5kb3IgMHgwNGQ5IFVTQiBLZXlib2FyZCwgY2xhc3Mg MC8wLCByZXYgMS4xMC8zLjEwLCBhZGRyIDM+IG9uIHVzYnVzMAo= --001a1145a91285673d0530aa8a2b-- From owner-freebsd-current@freebsd.org Sun Apr 17 10:39:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B43DB10059 for ; Sun, 17 Apr 2016 10:39:51 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B130F1E61 for ; Sun, 17 Apr 2016 10:39:50 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id a140so16996310wma.2 for ; Sun, 17 Apr 2016 03:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=trhnJ1x44egpf76fPqccweMHkyqrNc6zGKk7AAobk6Q=; b=bSL+H41HUzPRCt6lPsjhjTwbDPCYnpkuMoDvorCjCdOrl/DmLPQH/4/8e794grgJ9U 413MT394UJQVllAwKvevgxQaRJ91O7l041Sru8f8uR0rgaVDV6bzPJG0SVzrdZkDCrIR 8u0B13FcYNWONVCEcoFPoUUWX/MufyHlEqxcfGLRq7m5xIc7nGMby0mVvnwTQNyERo67 Zvw5EMvx+qC/h2dPhSn55YU0xHnK9NveKb1heAnj/IEUGkKJGY9JufkulzXIM8RIy3ai 3NBv1ArEBZ+dIHGKaa0Eod7f+Mvr5068IFAKq/S2EZ1+z1DHLP223LTbXTQeQJjj5gUL yULQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=trhnJ1x44egpf76fPqccweMHkyqrNc6zGKk7AAobk6Q=; b=BsA4gD9GKdbADNezd6J50lesdky0z0pQuK2fD+8lxM93h8rLx/4C+SMv9R99TIFeDY 2NhsEcnfpiaaXV0uJWusluyvbJl5litB1JkuUtB5YLXH8TZZbmmTxmZBxY25BV8NVi4G 8moLuDtIddkPapVFXNIhTw5o/+ra+SD0+qne9Mrfp9dtTAIPdW3+ngbz8QXjDLZAWlJT 06sicH2pHZSsONJ3jZXAQGIeOn9yG6XPHaZcIjwCDsIXsQ9dnSc3L3LHP65orsmPcB1e eeF90Iu5+ofKxIc5bnOuZiZ8pZBj2nyH2Rij2t0mX56xHAP27pM4uaVs9MmNnoobOpoH /bVA== X-Gm-Message-State: AOPr4FW/0ITf9Hv7kNFY0FUBQ1tL4bqwGVT5/d04d5YkqEmh/tiHSCvzCmRNvsv/8MrFsA== X-Received: by 10.194.104.135 with SMTP id ge7mr30263752wjb.15.1460889588513; Sun, 17 Apr 2016 03:39:48 -0700 (PDT) Received: from brick.home (adjj154.neoplus.adsl.tpnet.pl. [79.184.217.154]) by smtp.gmail.com with ESMTPSA id gk4sm58112897wjd.7.2016.04.17.03.39.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Apr 2016 03:39:47 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 17 Apr 2016 12:39:44 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "O. Hartmann" Cc: FreeBSD CURRENT Subject: Re: r298143: something wrong with autofs? Message-ID: <20160417103944.GA30972@brick.home> Mail-Followup-To: "O. Hartmann" , FreeBSD CURRENT References: <20160417105741.170f6f14.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160417105741.170f6f14.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 10:39:51 -0000 On 0417T1057, O. Hartmann wrote: > > Running FreeBSD 11.0-CURRENT #32 r298143: Sun Apr 17 09:48:26 CEST 2016 amd64, on both > server and client, reveals today that AUTOFS seems not to work. Did something changed > unnoticed? > > I realized, that no exported filesystem is bound so far. On the server's side, all "Bound"? > daemons necessary are configured as they were before in a working state and as I can see > so far, they are up and running and also listening to their sockets/IPs. Could you describe in more detail what are you seeing? Also, the usual autofs debugging technique ("pkill automountd && while :; do automountd -d; done") might sched some light. From owner-freebsd-current@freebsd.org Sun Apr 17 10:45:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D0C4B1032E for ; Sun, 17 Apr 2016 10:45:31 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id E45D012EB for ; Sun, 17 Apr 2016 10:45:30 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Sun, 17 Apr 2016 12:44:17 +0200 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 1BA05EC7-4E81-4516-9EDC-7409AB533D98.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Sun, 17 Apr 2016 12:44:14 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: OCZ ssdpx-1rvd0120 REVODRIVE support From: Rainer Duffner In-Reply-To: Date: Sun, 17 Apr 2016 12:44:12 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pavel Timofeev X-Mailer: Apple Mail (2.3124) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=13 total_conn=1 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 102, bad: 0, connections: 261, history: 102, asn_score: 35, asn_connections: 43, asn_good: 35, asn_bad: 0, pass:all_good, asn, asn_all_good, relaying X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 10:45:31 -0000 > Am 17.04.2016 um 11:05 schrieb Pavel Timofeev : >=20 > HI! I've recently got a SSD device. Yes, not a disk, but a device. > It's called, i. e. one of the first REVODRIVEs. > It's a PCI-express card with two embedded ssd disks about ~ 55GB size. > And it's a raid card. Fake software raid. You can set it up as a > RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured > or set it as JBOD or something else. > You just won't be able to boot from this device in that case. >=20 It says =E2=80=9ELinux support planned=E2=80=9C=E2=80=A6 on the product page. Tried loading the nvme(4) driver at the countdown? https://www.freebsd.org/cgi/man.cgi?query=3Dnvme&sektion=3D4 I=E2=80=99d suspect the Intel SSD 750 series would be a better choice=E2=80= =A6 Rainer= From owner-freebsd-current@freebsd.org Sun Apr 17 19:11:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EF43B12B2E for ; Sun, 17 Apr 2016 19:11:07 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 D8DCE10CB for ; Sun, 17 Apr 2016 19:11:06 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=M8VIWg+gg0SMz8BnXzWD6cxJurDmT1gWT9zfjq9//FI=; b=K1rXP2uO1KnsSeNLTIiRHglySt6N57HGGLTEkKArq4L6vxkdVmjEJt9wrunVPcbQO9ya1WK1zLzN6zSmISFdSxYRI0ZFBwR9/db4VtbnPSvM8aQeSY2YYazGdUD3FhgFqalaO6Zv/gOSHjd0GxiwpQXsOBBiy5uxDgCSgPSNL/s=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1ars5x-0007zb-Cu ; Sun, 17 Apr 2016 22:10:57 +0300 Date: Sun, 17 Apr 2016 22:10:53 +0300 From: Ivan Klymenko To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: Heads up Message-ID: <20160417221053.5ed43f41@nonamehost.local> In-Reply-To: References: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 19:11:07 -0000 On Thu, 14 Apr 2016 16:42:33 -0600 Warner Losh wrote: > The CAM I/O scheduler has been committed to current. This work is > described in > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the > default scheduler doesn't change the default (old) behavior. > > One possible issue, however, is that it also enables NCQ Trims on ada > SSDs. There are a few rogue drives that claim support for this > feature, but actually implement data corrupt instead of queued trims. > The list of known rogues is believed to be complete, but some caution > is in order. > > Warner Hi. i386 arch build error r298145: ... --- cam_iosched.o --- /usr/local/libexec/ccache/world/cc -target i386-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -march=native -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/k11/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/k11 -MD -MF.depend.cam_iosched.o -MTcam_iosched.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Ofast -fvectorize -fslp-vectorize -fblocks -fcolor-diagnostics -mno-aes -mno-avx -std =iso9899:1999 -c /usr/src/sys/modules/cam/../../cam/cam_iosched.c -o cam_iosched.o /usr/src/sys/modules/cam/../../cam/cam_iosched.c:612:8: error: format specifies type 'long' but the argument has type 'unsigned long long' [-Werror,-Wformat] ((uint64_t)1000000 * (uint32_t)lat) >> 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. *** [cam_iosched.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/cam 1 error make[4]: stopped in /usr/src/sys/modules/cam *** [all_subdir_cam] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_bxe --- --- bxe_elink.o --- ctfconvert -L VERSION -g bxe_elink.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/bxe *** [all_subdir_bxe] Error code 2 make[3]: stopped in /usr/src/sys/modules 2 errors make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/k11 1 error make[2]: stopped in /usr/obj/usr/src/sys/k11 *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Press any key to continue... From owner-freebsd-current@freebsd.org Mon Apr 18 06:52:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 725BCB1231D for ; Mon, 18 Apr 2016 06:52:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 37CBD183D; Mon, 18 Apr 2016 06:52:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 95A9F1FE023; Mon, 18 Apr 2016 08:52:55 +0200 (CEST) Subject: Re: CFR: extend use of nitems() macro in the kernel. To: Pedro Giffuni , FreeBSD Current References: <57128385.6090307@FreeBSD.org> From: Hans Petter Selasky Message-ID: <5714850C.6000106@selasky.org> Date: Mon, 18 Apr 2016 08:56:12 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <57128385.6090307@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 06:52:58 -0000 On 04/16/16 20:25, Pedro Giffuni wrote: > M sys/dev/usb/input/ukbd.c > M sys/dev/usb/serial/u3g.c > M sys/dev/usb/serial/uchcom.c > M sys/dev/usb/serial/umcs.c > M sys/dev/usb/serial/uplcom.c Approved. Maybe you can remove the superfluous pair of parenthesis after the substitution? --HPS From owner-freebsd-current@freebsd.org Mon Apr 18 11:40:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A858B11A5E for ; Mon, 18 Apr 2016 11:40:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 094F71726 for ; Mon, 18 Apr 2016 11:40:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9DE311FE023 for ; Mon, 18 Apr 2016 13:40:21 +0200 (CEST) To: FreeBSD Current From: Hans Petter Selasky Subject: qsort() documentation Message-ID: <5714C86A.8050204@selasky.org> Date: Mon, 18 Apr 2016 13:43:38 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 11:40:24 -0000 Hi, Are there any objections adding the following as part of documenting our kernel's qsort function? Index: sys/libkern/qsort.c =================================================================== --- sys/libkern/qsort.c (revision 298202) +++ sys/libkern/qsort.c (working copy) @@ -45,6 +45,10 @@ /* * Qsort routine from Bentley & McIlroy's "Engineering a Sort Function". + * + * NOTE: This implementation of qsort() was designed to not have the + * worst case complexity of N**2, as seen with the regular quick sort + * functions as described by Wikipedia. */ --HPS From owner-freebsd-current@freebsd.org Mon Apr 18 12:17:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0F74B11899 for ; Mon, 18 Apr 2016 12:17:31 +0000 (UTC) (envelope-from afiskon@devzen.ru) Received: from relay11.nicmail.ru (relay11.nicmail.ru [195.208.3.7]) (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 792A21DD2 for ; Mon, 18 Apr 2016 12:17:30 +0000 (UTC) (envelope-from afiskon@devzen.ru) Received: from [109.70.25.215] (port=51051 helo=fujitsu) by f06.mail.nic.ru with esmtp (Exim 5.55) (envelope-from ) id 1as87U-000HCn-0d; Mon, 18 Apr 2016 15:17:36 +0300 Received: from [93.174.131.138] (account afiskon@devzen.ru HELO fujitsu) by proxy02.mail.nic.ru (Exim 5.55) with id 1as87D-0000Da-7E; Mon, 18 Apr 2016 15:17:19 +0300 Date: Mon, 18 Apr 2016 15:16:39 +0300 From: Aleksander Alekseev To: Hans Petter Selasky Cc: FreeBSD Current Subject: Re: qsort() documentation Message-ID: <20160418151639.634d571d@fujitsu> In-Reply-To: <5714C86A.8050204@selasky.org> References: <5714C86A.8050204@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 12:17:31 -0000 Hello. I suggest also add a short description of how it was achieved (randomization?). On Mon, 18 Apr 2016 13:43:38 +0200 Hans Petter Selasky wrote: > Hi, > > Are there any objections adding the following as part of documenting > our kernel's qsort function? > > Index: sys/libkern/qsort.c > =================================================================== > --- sys/libkern/qsort.c (revision 298202) > +++ sys/libkern/qsort.c (working copy) > @@ -45,6 +45,10 @@ > > /* > * Qsort routine from Bentley & McIlroy's "Engineering a Sort > Function". > + * > + * NOTE: This implementation of qsort() was designed to not have the > + * worst case complexity of N**2, as seen with the regular quick sort > + * functions as described by Wikipedia. > */ > > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > -- Best regards, Aleksander Alekseev http://eax.me/ From owner-freebsd-current@freebsd.org Mon Apr 18 13:06:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0106B13291 for ; Mon, 18 Apr 2016 13:06:30 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 7E96B1789 for ; Mon, 18 Apr 2016 13:06:30 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0CEC11FE023; Mon, 18 Apr 2016 15:06:27 +0200 (CEST) Subject: Re: qsort() documentation To: Aleksander Alekseev References: <5714C86A.8050204@selasky.org> <20160418151639.634d571d@fujitsu> Cc: FreeBSD Current From: Hans Petter Selasky Message-ID: <5714DC98.7090208@selasky.org> Date: Mon, 18 Apr 2016 15:09:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160418151639.634d571d@fujitsu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:06:30 -0000 On 04/18/16 14:16, Aleksander Alekseev wrote: > I suggest also add a short description of how it was achieved > (randomization?). I think the algorithm is switching to mergesort. I'll look up the paper and add that correctly before commit. --HPS From owner-freebsd-current@freebsd.org Mon Apr 18 13:25:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF1FDB13A83 for ; Mon, 18 Apr 2016 13:25:41 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AAB0135B for ; Mon, 18 Apr 2016 13:25:41 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-io0-x230.google.com with SMTP id g185so194299083ioa.2 for ; Mon, 18 Apr 2016 06:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ody5dmvZ3KG20f/KvlmYiirtNa4+vg089xBJ+eJrhCE=; b=sJsbZGqzASKnZW1FrHAv3EjvNFvwI53FXP2cx4+qKyWvLWX5xwsALLxjXE/ZMG87hs T2rbIeygOb6GD1TmDqD02Orw4pBiDo0Dnfgv+xWSGYK+ZRGMs91Nnik19ANc0tagVWFZ xp9GUYVQ770mnLnd6KSlnm1H5DznhA/PCRyzgjPB41Vx8GVoMGrchuhq7t1my3rhYvFL 5RmNNnz+Y6s/JjVqLKVPa6WMq9bSDF5YaDZSV+nOFqxXuTdQ8/1nAT9U2l97giiZUsUW HF/gKWkUgYuQWhE8NqSjKgIHK4R9RQqn/ruQ6FAwThyAxCTYwX+sttaRCZJi+KDXndbv ZP5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ody5dmvZ3KG20f/KvlmYiirtNa4+vg089xBJ+eJrhCE=; b=QD6KaXScbF6URfElr0TbY6H8ecPRpgH+9MCnAaXz5VWwdHQ/afO61EpHa1/iS3Hvev 57C+JGb/5DygAiVFvT2dsb9gxAdv2X4taIaCwYM6rElpjepmfrviKTWG6V53Yxk2oeRB jnMj8DWffuXInM5/jQQk9/WBEarmuFfOhl2JKUVPPYMPtieycRKsAdBCeMaLqN7Uk0jW KBeJ3bz9Mq+5KUUj7PvtuippNCB4a9JcBT04Jeu3qVqhccYaN2FG7XvlqoaUjd4edxdt wfmq1LwSSI0DF/ts9Qkw7ROHLxMEtoG3AZaFXURW+XCTwI2Oh9SdIb+wmpM4eq6+4JWn l7CA== X-Gm-Message-State: AOPr4FVTxMltxUaTW7TJr7j1qyvHIP1NJ9TOWsm53wm6a4qDixb3yK9iE7isRQ2OAunn13ssKvs/Ghw61gYmXA== MIME-Version: 1.0 X-Received: by 10.107.159.137 with SMTP id i131mr33986800ioe.29.1460985940988; Mon, 18 Apr 2016 06:25:40 -0700 (PDT) Received: by 10.107.133.162 with HTTP; Mon, 18 Apr 2016 06:25:40 -0700 (PDT) In-Reply-To: <5714DC98.7090208@selasky.org> References: <5714C86A.8050204@selasky.org> <20160418151639.634d571d@fujitsu> <5714DC98.7090208@selasky.org> Date: Mon, 18 Apr 2016 09:25:40 -0400 Message-ID: Subject: Re: qsort() documentation From: Ryan Stone To: Hans Petter Selasky Cc: Aleksander Alekseev , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:25:41 -0000 On Mon, Apr 18, 2016 at 9:09 AM, Hans Petter Selasky wrote > I think the algorithm is switching to mergesort. I'll look up the paper > and add that correctly before commit. > No, it switches to insertion sort, assuming that it's acting on an already sorted array. If that assumption is wrong you still get O(n**2) complexity. From owner-freebsd-current@freebsd.org Mon Apr 18 14:00:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D4BDB11FEE; Mon, 18 Apr 2016 14:00:54 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-ig0-x244.google.com (mail-ig0-x244.google.com [IPv6:2607:f8b0:4001:c05::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 29F2218F1; Mon, 18 Apr 2016 14:00:54 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-ig0-x244.google.com with SMTP id fn8so11012245igb.2; Mon, 18 Apr 2016 07:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-transfer-encoding; bh=9pugJovbhlrI3aewCAYmKEhvwvYgI0gCxjd7UsYC1Rc=; b=q7Dc7JnCVf8dhNXGm2KCnJ2C/01glqm5BUJS994bZQro4dR7vobgl6rUv3TZiwwDgx lhwmOoZaLnzmsvacc9HOMkEBCrCnHpEuNvRqFKvAm+DhgtkgYRdr8we6+cl2psMVcwRj mrCK1FgO381nmLl5xMYRd2v/pxgz/4LDSsQezWJ0a+RGW+G+O8kYDj7w2aGfZ8NyUdhS lBT/evaMau4D9ZujEM3wCJlQPdZ8xEqWhAigU0WxFptVGFswqdu6Qpn68gOGu5Wre9Jf lcx1zL527Xd7p2F2mdbWraNkUHrBYQEIFGF0LiUkt44LttM2Jq8wOjgNLa6/tREgVTZI ahgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-transfer-encoding; bh=9pugJovbhlrI3aewCAYmKEhvwvYgI0gCxjd7UsYC1Rc=; b=dkKOQ4jkCUxJsMU38TfRy/cjsbGHaNm5eID40UJINI1g33M2vhIn9teicGVRhyN6L6 +szBN9LKDom6EfkwaivfujLWt6VxWDkIjkEIVd7JsFqdp1CATx7SMzC9ZMAg3zpmjGQ+ T6+nS8qCBdwSPPb6/k/dhP8zsCQjPu9/mHRjYo7ewbUAWG1H9Szdy3EJwDJpXDnKhiRJ VZnSy4HmzeApvUhomLczKLVVaBaflm/g+M1sUNiToe5JGMEVmLh9HQ0O3kum4tS7n1SY pEsIABwmpcXfzttWcM58Fdj+g57LHvvp/i2L67q5yOntxiysEj9lRymGo/XntX2Z/q6T Dxfg== X-Gm-Message-State: AOPr4FWiiayceyq+ga5ycv08HoG2jz2rNDjsmjHok5Tma6e+tHZHJmT05C9iwvEW7h7R3g== X-Received: by 10.50.118.225 with SMTP id kp1mr20283406igb.9.1460988052634; Mon, 18 Apr 2016 07:00:52 -0700 (PDT) Received: from [10.0.10.3] (cpe-76-190-244-6.neo.res.rr.com. [76.190.244.6]) by smtp.googlemail.com with ESMTPSA id s8sm38024167iod.40.2016.04.18.07.00.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 07:00:51 -0700 (PDT) Message-ID: <5714E89A.8000807@gmail.com> Date: Mon, 18 Apr 2016 10:00:58 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: questions@freebsd.org, freebsd-current@freebsd.org Subject: 11.0-RELEASE pkg base & base.txz file Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:00:54 -0000 11.0 will have pkg base, thats ok, but what does than mean for the base.txz file? It it going to stay as part of FBSD install? I have many scripts for creating jails which depend on the base.txz file. From owner-freebsd-current@freebsd.org Mon Apr 18 14:05:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E930EB124AE; Mon, 18 Apr 2016 14:05:14 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 D7F8E1E89; Mon, 18 Apr 2016 14:05:14 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id EEE6623943F; Mon, 18 Apr 2016 10:05:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.1 Received: from [127.0.0.1] (vnat600.ejoco.com [166.108.32.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 60531239420; Mon, 18 Apr 2016 10:05:13 -0400 (EDT) Subject: Re: 11.0-RELEASE pkg base & base.txz file To: Ernie Luzar References: <5714E89A.8000807@gmail.com> Cc: freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Nikolai Lifanov Message-ID: Date: Mon, 18 Apr 2016 10:05:12 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5714E89A.8000807@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:05:15 -0000 On 04/18/16 10:00, Ernie Luzar wrote: > 11.0 will have pkg base, thats ok, but what does than mean for the > base.txz file? > > It it going to stay as part of FBSD install? > > I have many scripts for creating jails which depend on the base.txz file. It's even easier now: # mkdir -p /usr/jails/new # pkg -r /usr/jails/new install -r base -g '*' - Nikolai Lifanov From owner-freebsd-current@freebsd.org Mon Apr 18 14:15:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D371B12BA7; Mon, 18 Apr 2016 14:15:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3EA61203; Mon, 18 Apr 2016 14:14:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1as9x0-000ONd-QX; Mon, 18 Apr 2016 17:14:54 +0300 Date: Mon, 18 Apr 2016 17:14:54 +0300 From: Slawa Olhovchenkov To: Nikolai Lifanov Cc: Ernie Luzar , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: 11.0-RELEASE pkg base & base.txz file Message-ID: <20160418141454.GX4841@zxy.spb.ru> References: <5714E89A.8000807@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:15:00 -0000 On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > On 04/18/16 10:00, Ernie Luzar wrote: > > 11.0 will have pkg base, thats ok, but what does than mean for the > > base.txz file? > > > > It it going to stay as part of FBSD install? > > > > I have many scripts for creating jails which depend on the base.txz file. > > It's even easier now: > > # mkdir -p /usr/jails/new > # pkg -r /usr/jails/new install -r base -g '*' And where /etc now? From owner-freebsd-current@freebsd.org Mon Apr 18 14:16:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81DE4B12C7D; Mon, 18 Apr 2016 14:16:07 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 176DB134B; Mon, 18 Apr 2016 14:16:07 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id a140so25046439wma.2; Mon, 18 Apr 2016 07:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EcmHjKMjvqyj8T6BSdjYS+FMRGeN6Yz+FnGduCIOV1g=; b=a3WTL8A8kkRMKF/zL5IHUHsH4PdJYUn8uReZRKAFJsSMPf53uCRpLPwEHCTsagb+6F 8XcG/v056vGZENMZSe8HLf5lAbejqWdH7JntzFvskMUpvS1GUsPsyBeJWmj+BjX0URFY /urAWOoeWe3UvmYZTTAdOE4eSV8ktSFHByt19kjaABUnwOsmDBS/6LwLTR1Tmon6I0JX V1/X4PNEnVLBM7CNw5Rerhinyae6c+Q5C+XmsJQVYJXQnqMMFScqA+IqyPETR/wFXmrE ecXXwFpmn/Bq61rQDOi+LCPUImy9uhVQ4WPCi8l3w6EDWnhS0CqHb5rB2h0YbNP/s12U 8VGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=EcmHjKMjvqyj8T6BSdjYS+FMRGeN6Yz+FnGduCIOV1g=; b=iwV/67ReZih/YDOnWYVQkZF9YzMfsaEl5NyYgPoIqdVW5dM+zoFw1uF8zewCm1izEJ 7sk6wyCKy5LtVyGxeMgsGU7K1N78Alp5DGgx5TXXCMYUxIYLx6jqGHgT7vyH9TYz4UuR gGo0EVjLiPPDojoDevQ5NbVufzfN8NUOagzOvVIkZff02QrHDkmywnlr7+g5ay4ROn1X firRev2b50KyJmI55LQxHbS/7vJS55RvkuknhgVjPDc41MiMjPSy7SmZ8b9hHjrd868x /cyTKk1G+108fvSlDDiSVMf+H7uUjrAbpnmRgR5PtitJRyus0AMLLEgJXPQefPhcTn3l bjww== X-Gm-Message-State: AOPr4FWLU8fYBnb/LBBStHj5aL5IkNzebPdotr1uY056Yf05GZ67jucqicMw+mmhnTxvBw== X-Received: by 10.194.81.135 with SMTP id a7mr6476130wjy.170.1460988965186; Mon, 18 Apr 2016 07:16:05 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id g78sm53953644wme.21.2016.04.18.07.16.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Apr 2016 07:16:03 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 18 Apr 2016 16:16:01 +0200 From: Baptiste Daroussin To: Slawa Olhovchenkov Cc: Nikolai Lifanov , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org, Ernie Luzar Subject: Re: 11.0-RELEASE pkg base & base.txz file Message-ID: <20160418141601.GA26116@ivaldir.etoilebsd.net> References: <5714E89A.8000807@gmail.com> <20160418141454.GX4841@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20160418141454.GX4841@zxy.spb.ru> User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:16:07 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: >=20 > > On 04/18/16 10:00, Ernie Luzar wrote: > > > 11.0 will have pkg base, thats ok, but what does than mean for the > > > base.txz file? > > >=20 > > > It it going to stay as part of FBSD install? > > >=20 > > > I have many scripts for creating jails which depend on the base.txz f= ile. > >=20 > > It's even easier now: > >=20 > > # mkdir -p /usr/jails/new > > # pkg -r /usr/jails/new install -r base -g '*' >=20 > And where /etc now? What do you mean? Bapt --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFOwhAAoJEGOJi9zxtz5a/ZIQAJ0IJmkeMU0RwnOFEoCWPIrk tykfTAXicF+RS2XcKjjJbSQgrQ6IoeFd+JAHsNWdTTCtj0HKF5KaNIv1lZ4YsqNu o0sbpEYAxmBGUARkWQyxMELmT2RhSlR0yV9geCDjb7NC9pPopfFimUx0vXZ/wFwi D64hrQ6xpUO8lAIe5pgYLarGiTyVEyg/UOSFuqGpi1MFK9LZuAiPnz3l8qb9KOmi RE6WRbbDxeaOopUDIxeXdaXh/Bgd3R86QQ0vwegg4MjfN4Mu8QIx7WMTcIz5vQGk gH8UMPqKNmM9HCb5/5gx+OCahhdGVCqn5tUT7mcVCAW2/Mzj7/TfBKyLDGE+Nl5i d/NOm0wpviS9BOkmrTnxENMQvPPdSa0oIUJ3Vugomag2x4vozzIFR70ElNzC9QPM 3MF3FNgQvWd/V7cXem/GHKSQ3N+5e2EDNlFExq75n7tS9z2uF2vVtD8YRA7t/lcG vDpIKI6U2oY1VIeSeWQzgKxXZg5OFRkd/+9RowugamKjSgzjBBMSdfmwbeklH7Th YkUdREwj/JmSQeAlfCu5Eo1LfmVXQaW5EtbHorHdE2uzmB5pswfYQrlCQqI2JGA0 YLVlE77Bi83JbuG0JGFW2gjQ5N8BJIzutVjeFoZnt1UJDgoQnW2sj0cbGxtd7bJJ LfZ/L3fmqhM3uPf4kJUK =4nR9 -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-current@freebsd.org Mon Apr 18 14:27:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 426A5B130E9; Mon, 18 Apr 2016 14:27:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03F041AB0; Mon, 18 Apr 2016 14:27:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asA8r-000OiV-Ru; Mon, 18 Apr 2016 17:27:09 +0300 Date: Mon, 18 Apr 2016 17:27:09 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Cc: Nikolai Lifanov , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org, Ernie Luzar Subject: Re: 11.0-RELEASE pkg base & base.txz file Message-ID: <20160418142709.GY4841@zxy.spb.ru> References: <5714E89A.8000807@gmail.com> <20160418141454.GX4841@zxy.spb.ru> <20160418141601.GA26116@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160418141601.GA26116@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:27:08 -0000 On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: > On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > > > > > On 04/18/16 10:00, Ernie Luzar wrote: > > > > 11.0 will have pkg base, thats ok, but what does than mean for the > > > > base.txz file? > > > > > > > > It it going to stay as part of FBSD install? > > > > > > > > I have many scripts for creating jails which depend on the base.txz file. > > > > > > It's even easier now: > > > > > > # mkdir -p /usr/jails/new > > > # pkg -r /usr/jails/new install -r base -g '*' > > > > And where /etc now? > > What do you mean? At Jan 27 no package containing files from distributeworld. r298107 change this? From owner-freebsd-current@freebsd.org Mon Apr 18 13:59:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AEB1B11C23 for ; Mon, 18 Apr 2016 13:59:38 +0000 (UTC) (envelope-from renato@netgate.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA201695 for ; Mon, 18 Apr 2016 13:59:38 +0000 (UTC) (envelope-from renato@netgate.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3CF43B11C22; Mon, 18 Apr 2016 13:59:38 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CA05B11C20 for ; Mon, 18 Apr 2016 13:59:38 +0000 (UTC) (envelope-from renato@netgate.com) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 041111694 for ; Mon, 18 Apr 2016 13:59:37 +0000 (UTC) (envelope-from renato@netgate.com) Received: by mail-qg0-x234.google.com with SMTP id f105so116225603qge.2 for ; Mon, 18 Apr 2016 06:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=iwu5YMak8wpgsRR5zeZN5WwKvNElQKkYAffR8592Fgo=; b=JauCL3VntxHCBsB3nHekqEQUNjEanh6kFb7fMV6jkMX5tOGwSWw4cTLrqye6yb6AFC MdfXix79G2E/kqaZ7D18Lc6oejVOyxN6us5+CxjcF1dfaAPTGWfxYblGhQlgTC3fnwhF XYAnn5QjtgrTIb96+1JcHxQBgBOIt5GCAQS3U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=iwu5YMak8wpgsRR5zeZN5WwKvNElQKkYAffR8592Fgo=; b=IX4qGA/nSjWj+vu3mzvS9+cpSmHh0A7JO3X5Nvx3CovmNDyVNRGfBOd33dfIvV0Y/q k3tuEgtSa9zr/LQxPKV15qb1VnWSPGNzSYXPcWNGldzWYOO95bawDG5Uv6izirIeMzbW gS0Ny0iEkVX+XhoR/ZVXMzF/qlertBcgDknRRUqifkDM7EkeuHNORZIuT9b70lMRpvhz WXWMPyjIR/HN9lOUv7L0ZX5EwJg1qM9kD69kDB3MU06U3diKAZbGgZP08xli40Yc/QqO NZfqE7z5D5WgtfGakWCfepEsN3fTklikg5biEBM6/oiIVn72ubMUP0OT5H/GBhWnmLVL kE1Q== X-Gm-Message-State: AOPr4FURc+bQeSWpdFBQr7HzfspIPszAZ4dS8viS9dqNanvghmE1XnZ+2p1DesYbsM4V0OtI X-Received: by 10.140.93.166 with SMTP id d35mr42309926qge.29.1460987976983; Mon, 18 Apr 2016 06:59:36 -0700 (PDT) Received: from mbp.home (179-125-142-141.desktop.com.br. [179.125.142.141]) by smtp.gmail.com with ESMTPSA id b2sm5283420qgb.37.2016.04.18.06.59.35 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 06:59:36 -0700 (PDT) From: Renato Botelho do Couto Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: objcopy exit with signal 10 trying to update to recent -CURRENT Message-Id: Date: Mon, 18 Apr 2016 10:59:39 -0300 To: current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Mon, 18 Apr 2016 14:40:18 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:59:38 -0000 I=E2=80=99m trying to upgrade a -CURRENT amd64 installation from r297492 = to r298203 and got: c++ -O2 -pipe = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/utils/TableGen = -I. = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments = -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dc++11 -fno-exceptions = -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -static = -L/usr/obj/usr/src/tmp/legacy/usr/lib -o llvm-tblgen.full = AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o Attributes.o = CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o = CodeGenDAGPatterns.o CodeGenInstruction.o CodeGenMapTable.o = CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o = DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o = DAGISelMatcherOpt.o DFAPacketizerEmitter.o DisassemblerEmitter.o = FastISelEmitter.o FixedLenDecoderEmitter.o InstrInfoEmitter.o = IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmitter.o = RegisterInfoEmitter.o SubtargetEmitter.o TableGen.o = X86DisassemblerTables.o X86ModRMFilters.o X86RecognizableInstr.o = /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/= libllvmtablegen/libllvmtablegen.a = /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/= libllvmsupport/libllvmsupport.a -lncursesw -lpthread -legacy objcopy --only-keep-debug llvm-tblgen.full llvm-tblgen.debug objcopy --strip-debug --add-gnu-debuglink=3Dllvm-tblgen.debug = llvm-tblgen.full llvm-tblgen *** Signal 10 I=E2=80=99ve already tried a fresh build after remove /usr/obj, same = problem. Any ideas? -- Renato Botelho do Couto Software Engineer Netgate, Inc. From owner-freebsd-current@freebsd.org Mon Apr 18 14:49:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96F7AB13C2B for ; Mon, 18 Apr 2016 14:49:14 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A75C10B4 for ; Mon, 18 Apr 2016 14:49:14 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x230.google.com with SMTP id j74so26876371ywg.1 for ; Mon, 18 Apr 2016 07:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9+LjQk5YJnG21+NLngKYgQu8hwRS1PjSQbXIozuuwe0=; b=AYuys/6nAGus6uaJ9YN3arvxRILKViXwnEez9M3gjR9CNwoyJe2O2Ty/R+/KX46Rch 46JpdJ2nkFDYBDn44NJZq5LkPv8g6GVt2T59BJYt0Q1Q5FX3likR2TcGzbJufA3y3IzM aywso07utGNAU2XjIGC1TOL9ATYTW6ZaSeqGAJYxX0k3Wh4USMRVDr/OVwtI1bn2TQ/n fuqNP+3FnHYoHqldCduYGwXAWeh6Wvu65vQ+EDYPKWxRwaJ0RuFjxl4DO2+bEwDGStb0 WtB+HwgGafIo6iYpnhC//IDK6oQ8XxxElYLSDFY+pFFlOYD6ZiYpAeTo4ekLiKvOgqaU ekXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9+LjQk5YJnG21+NLngKYgQu8hwRS1PjSQbXIozuuwe0=; b=Y0qt1ImJS3MAes0FO3hcaXhwmhJY061Rq7FOiIMvMrbIm0LSyR0F+k72kcyLJRRwJI BeAJCFow/nWYxp7UqbBFA9/Bx41SkmYfsUay3ZCFBckbXL9C5MGjwW8+W7LP7F+VFWzP OtMLQynfk9I2UqB6+Psdd1VglHjSzOunKu3aF7GM9OFQUZBDRSydRK5JFfYO+niXFWui +S6trdHExWwZ6jQpDNFYQjFIxYmqQlrZsjcrkafVC9xKip+GZmrPNQyXzCE9xezgtBqV zaswQslB5jFhMH7qL4subqA3loCl0nh8JKxV1uK5nRfslimtnsKDoz5e+5TKwcOpZq7C uy1w== X-Gm-Message-State: AOPr4FVYg0DKj5l/YA/0FqElqwM/xNpL1VBaGw65C580ulgm+xHD+lAXF+zI31MF5EZNDA9AfQnBUDjZ45KdCA== MIME-Version: 1.0 X-Received: by 10.13.211.71 with SMTP id v68mr18787687ywd.310.1460990953367; Mon, 18 Apr 2016 07:49:13 -0700 (PDT) Received: by 10.129.148.6 with HTTP; Mon, 18 Apr 2016 07:49:13 -0700 (PDT) In-Reply-To: <5714DC98.7090208@selasky.org> References: <5714C86A.8050204@selasky.org> <20160418151639.634d571d@fujitsu> <5714DC98.7090208@selasky.org> Date: Mon, 18 Apr 2016 16:49:13 +0200 Message-ID: Subject: Re: qsort() documentation From: Ed Schouten To: Hans Petter Selasky Cc: Aleksander Alekseev , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:49:14 -0000 2016-04-18 15:09 GMT+02:00 Hans Petter Selasky : > On 04/18/16 14:16, Aleksander Alekseev wrote: >> I suggest also add a short description of how it was achieved >> (randomization?). > > I think the algorithm is switching to mergesort. I'll look up the paper and > add that correctly before commit. As a Dutch person, I know the answer to this. Instead of picking a fixed pivot or choosing one at random, it uses an approach called linear time median finding to find a pivot that is 'approximately median'. There are a couple of algorithms for this, but I think Bentley's qsort() uses this: https://en.wikipedia.org/wiki/Dutch_national_flag_problem -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Mon Apr 18 15:00:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF496B13018 for ; Mon, 18 Apr 2016 15:00:19 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFCA1837 for ; Mon, 18 Apr 2016 15:00:19 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9A905B13017; Mon, 18 Apr 2016 15:00:19 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A329B13016 for ; Mon, 18 Apr 2016 15:00:19 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54FA21836 for ; Mon, 18 Apr 2016 15:00:19 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qk0-x236.google.com with SMTP id x7so28932834qkd.3 for ; Mon, 18 Apr 2016 08:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=SccZy92o2kjDEFDDq8vTHsla8dHtGOiMJdlBdx2aVjI=; b=XPq1jNw5/mvM/ntyN17RwR3RlXB5tIzqehiG9UjGaYlZ4uOZwgL/i+jIfFqbmRy+L5 F+EJxLRxp2ard6ykXolwkrgkbTAOVJRuLLnen+sVUymyrX+rOtgx5VWi0nKSPachJUML x5620Kec4vJQxKLnb9IUAbVXurMJuRj3MCZ74+F15YIvdPt0e5nlp3LQJdrkNAqKIrG3 szQV1scrcDqkDi4Rz77EBtDzfDoJQuejAip5hxKXtZimtBq1wRJV6UquCunQX0HhfFan NBrsUIGXkK2zdJEsss5LyqDM8VnH5pLghaT7474zNp4K4/LcDZpF+jcU2pvajcITuk/7 PMZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:content-transfer-encoding:message-id:references:to; bh=SccZy92o2kjDEFDDq8vTHsla8dHtGOiMJdlBdx2aVjI=; b=gxvG5QgMgoBbjcfuWnQ2Z/JtW4PChvoI1MAHBzoQbJgTR4D1GcD1Q10umMiSlISXCy NRpGzKdstcsR+XVug2OlxFRKKxBv9leEeDjWzzWTz2w6RH8JRra8gkzqasVdmZ5sEdMV tO7guoMxpvNTq4EJUhgdOZkmxaePbDCHO5aI4fJzH6QUMyI7ZXcns8I6ExTZNhlNvdz/ 7Y3zx5Zf9bnK3lF2D6JuG7ZALN+uX8ySZjCWoKaqcNwx5crwHdO41mWADibRWbeodTmy 6Y7sIVPnmEzd+kpjSMH6WFa8Mg/QvCPxdQHXKqINk5idyHxj3m5/dzJZ1kLsgjZ3NcOj lVww== X-Gm-Message-State: AOPr4FWjpm1We+XmvBN4WwSQ87W/+3edkCALAmQtT2gFKrpC4W4+v6Fv4+LQfuJSt3ptDA== X-Received: by 10.55.77.12 with SMTP id a12mr45098522qkb.44.1460991618250; Mon, 18 Apr 2016 08:00:18 -0700 (PDT) Received: from mbp.home (179-125-142-141.desktop.com.br. [179.125.142.141]) by smtp.gmail.com with ESMTPSA id 126sm4757637qkh.19.2016.04.18.08.00.16 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 08:00:17 -0700 (PDT) Sender: Renato Botelho Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: objcopy exit with signal 10 trying to update to recent -CURRENT From: Renato Botelho In-Reply-To: Date: Mon, 18 Apr 2016 12:00:19 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84ADE723-6ACB-4EBE-892B-7C2A4561C399@FreeBSD.org> References: To: current@FreeBSD.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 15:00:19 -0000 > On Apr 18, 2016, at 10:59, Renato Botelho do Couto = wrote: >=20 > I=E2=80=99m trying to upgrade a -CURRENT amd64 installation from = r297492 to r298203 and got: >=20 > c++ -O2 -pipe = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/utils/TableGen = -I. = -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments = -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dc++11 -fno-exceptions = -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -static = -L/usr/obj/usr/src/tmp/legacy/usr/lib -o llvm-tblgen.full = AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o Attributes.o = CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o = CodeGenDAGPatterns.o CodeGenInstruction.o CodeGenMapTable.o = CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o = DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o = DAGISelMatcherOpt.o DFAPacketizerEmitter.o DisassemblerEmitter.o = FastISelEmitter.o FixedLenDecoderEmitter.o InstrInfoEmitter.o = IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmitter.o = RegisterInfoEmitter.o SubtargetEmitter.o TableGen.o = X86DisassemblerTables.o X86ModRMFilters.o X86RecognizableInstr.o = /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/= libllvmtablegen/libllvmtablegen.a = /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/llvm-tblgen/../../../lib/clang/= libllvmsupport/libllvmsupport.a -lncursesw -lpthread -legacy > objcopy --only-keep-debug llvm-tblgen.full llvm-tblgen.debug > objcopy --strip-debug --add-gnu-debuglink=3Dllvm-tblgen.debug = llvm-tblgen.full llvm-tblgen > *** Signal 10 >=20 > I=E2=80=99ve already tried a fresh build after remove /usr/obj, same = problem. Any ideas? Fixed after I manually rebuilt usr.bin/elfcopy -- Renato Botelho From owner-freebsd-current@freebsd.org Mon Apr 18 15:03:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2106B13277; Mon, 18 Apr 2016 15:03:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A47311F66; Mon, 18 Apr 2016 15:03:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asAhx-000Pdx-LJ; Mon, 18 Apr 2016 18:03:25 +0300 Date: Mon, 18 Apr 2016 18:03:25 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Cc: freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org, Ernie Luzar Subject: Re: 11.0-RELEASE pkg base & base.txz file Message-ID: <20160418150325.GZ4841@zxy.spb.ru> References: <5714E89A.8000807@gmail.com> <20160418141454.GX4841@zxy.spb.ru> <20160418141601.GA26116@ivaldir.etoilebsd.net> <20160418142709.GY4841@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160418142709.GY4841@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 15:03:24 -0000 On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote: > On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: > > > On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > > > > > > > On 04/18/16 10:00, Ernie Luzar wrote: > > > > > 11.0 will have pkg base, thats ok, but what does than mean for the > > > > > base.txz file? > > > > > > > > > > It it going to stay as part of FBSD install? > > > > > > > > > > I have many scripts for creating jails which depend on the base.txz file. > > > > > > > > It's even easier now: > > > > > > > > # mkdir -p /usr/jails/new > > > > # pkg -r /usr/jails/new install -r base -g '*' > > > > > > And where /etc now? > > > > What do you mean? > > At Jan 27 no package containing files from distributeworld. At Mar 02 > r298107 change this? > > _______________________________________________ > freebsd-pkgbase@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase > To unsubscribe, send any mail to "freebsd-pkgbase-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Apr 18 15:10:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF19FB13589 for ; Mon, 18 Apr 2016 15:10:12 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CFF91836 for ; Mon, 18 Apr 2016 15:10:12 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id o126so197557312iod.0 for ; Mon, 18 Apr 2016 08:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=6hOLfLX2nCBu5gsZG26fpcLS1mhf5oR8zcVarlDzfzE=; b=gvOZ3vnKK6tBGv5wlIJ6jaXaRuJQzda1q4H57B5dvRcC3UP+ZyofESPBoRS3EnnRkk 0gbee1u1GUs0i7Mi1K14Q7M7QbXn0CQoRoJa8RI5w0TVy2xKEmj9tpxny0sEENdgEXHF F2U7sOgxP++uz5GfOyO3ytu6cCD8PvYpDnn4ST4OF8UmrUijtI+DBLJ4MHmU/lUYbDAh TJYvRuN1OqH4Vn5EC49xTdFN4ENxL+pjj1UlFa9UY4tyNencTYmpzyX0wlo+bTSACn3G plhYNmfiaQybp2nisVUA+sDB+O/A44y76Bt4ZboKx5b+brQmehhXL2sFQOfTiZe2nd7l 6k/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=6hOLfLX2nCBu5gsZG26fpcLS1mhf5oR8zcVarlDzfzE=; b=dDBW05CHVfD3RpZKEQdgsLjgSI5C9wlQW2n4kHyNPHrGFZZ7MgglC89zeFFelSYbOd UFFFoX2QdNeA9dldc4VUtG/N7Kjdfd2D/NTOFNVEa1JdWHIfV7YqEo8lV1nCrYwyP7if RPyGES+e8h6I1YNHPPY71FIKE77DGteu9o80arONMzyq5wjS7QxwTDEqV99py2HyP7ba MQ1ksKdobO4I3nzxw6Jzb3t4aSZa5ml9PG6a9txrTz0rwt546Sl1xNTPMUXr5tD4K2TH h22HXY/f1lUm3StfITbRyKbOk4HTlKHaSUES9bXMUxUR0DdplVWRan7VGHkHTmQCkm2e YxlQ== X-Gm-Message-State: AOPr4FVJKekMORWH1byxYumypOqJeWTrDHuMOQBYMw8TJ040xO7XjeAQzKptZxDvkp/+7LlzqbXTij2MtUOSQA== MIME-Version: 1.0 X-Received: by 10.107.7.23 with SMTP id 23mr34833204ioh.64.1460992212076; Mon, 18 Apr 2016 08:10:12 -0700 (PDT) Received: by 10.50.128.133 with HTTP; Mon, 18 Apr 2016 08:10:12 -0700 (PDT) Date: Mon, 18 Apr 2016 23:10:12 +0800 Message-ID: Subject: Mis-use of BUS_PASS_ORDER_MIDDLE From: Howard Su To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 15:10:12 -0000 I noticed several places there are code like this, especially in some arm low level drivers. EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); =E2=80=8BI feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are an= other macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. =E2=80=8B --=20 -Howard From owner-freebsd-current@freebsd.org Mon Apr 18 16:10:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B631FB131B2 for ; Mon, 18 Apr 2016 16:10:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 8242810C5 for ; Mon, 18 Apr 2016 16:10:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3687E1FE023; Mon, 18 Apr 2016 18:09:59 +0200 (CEST) Subject: Re: qsort() documentation To: Ed Schouten References: <5714C86A.8050204@selasky.org> <20160418151639.634d571d@fujitsu> <5714DC98.7090208@selasky.org> Cc: Aleksander Alekseev , FreeBSD Current From: Hans Petter Selasky Message-ID: <5715079B.9010408@selasky.org> Date: Mon, 18 Apr 2016 18:13:15 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 16:10:03 -0000 On 04/18/16 16:49, Ed Schouten wrote: > 2016-04-18 15:09 GMT+02:00 Hans Petter Selasky : >> On 04/18/16 14:16, Aleksander Alekseev wrote: >>> I suggest also add a short description of how it was achieved >>> (randomization?). >> >> I think the algorithm is switching to mergesort. I'll look up the paper and >> add that correctly before commit. > > As a Dutch person, I know the answer to this. > > Instead of picking a fixed pivot or choosing one at random, it uses an > approach called linear time median finding to find a pivot that is > 'approximately median'. There are a couple of algorithms for this, but > I think Bentley's qsort() uses this: > > https://en.wikipedia.org/wiki/Dutch_national_flag_problem > Hi, Ryan: Yes, there is quadratic behaviour still, but I believe the order is limited. For the matter of the topic I added a counter for the swap() code in the insertion fallback algorithm, and for a set of 2048 integers I never saw the swap() count exceed this number. For a pre-sorted array, values around ~2047 and reverse sorted ~2043. For random input far less. Citing the document "bentley93engineering.pdf", a footnote says: Of course, quadratic behavior is still possible. One can generate fiendish inputs by bugging Quicksort: Con- sider key values to be unknown initially. In the code for selecting a partition element, assign values in increas- ing order as unknown keys are encountered. In the partitioning code, make unknown keys compare high. Did anyone try to generate such a fiendish set of data, and see how quadratic the FreeBSD's qsort() becomes? Another thread, possibly related: http://postgresql.nabble.com/Why-do-we-still-perform-a-check-for-pre-sorted-input-within-qsort-variants-td5746526.html --HPS From owner-freebsd-current@freebsd.org Mon Apr 18 17:02:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 819D7B135E8 for ; Mon, 18 Apr 2016 17:02:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 4C23212E2 for ; Mon, 18 Apr 2016 17:02:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id u185so200842507iod.3 for ; Mon, 18 Apr 2016 10:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iWZDA9T3+eXyG+15tekDVvLzPoxYnd1ryMvYECMxnXw=; b=b7PC23eook9dYNmWKc6U61405mFRyGJDMwL5TG9aJTLY5od9hmEXYTJmqyLrLwXRvp d5dN81eKGj69HSwy4poJtIWmzmP+2iq8U7BA91hxXYDLj6OqEg8Nok04bo89LK4dkpcl NeBvFhrAgP9m6daKrx0JV2NJsjTUphEbBPG0cUQUKdvaPbWvPlz2V0kmfzy6QL3n8p/X 2/EoAdHHcrRVxq1U2XPzylD8j54bdIe1wLkFCZ/wh2AtRdEO3ltni+PJ1jfea0UCNp0r C3QBeKThaUnZnuIUtzqAQmPM9NyHEz8t7QXDU7EjZFakzUfFKEzx5/V6cWQ1VenmBCfK vmRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iWZDA9T3+eXyG+15tekDVvLzPoxYnd1ryMvYECMxnXw=; b=TneAo3IigZcDq1P5M54zV3KojhYa9WXW6ShnzAaHQlEVd3u4m6VcOAQC43xxA43y3T x75yjqHisAS1vFjT/YwPJi+lW64gOXckwOM2Pw0Qd9pk9dd5FIyZ3cfGcU1X1trSH2P9 8fK5nR8YmzEoN2EplyTskMSakvtaF8aYGz0BI0cIZic5sEpAaH/uow7cXHusMGz3di7E KvtgSv8sO8E0VJ1nm3aiGnxxSkV55su4KtOquBTgWri31kg6iLD/YFiQukNwPzz96jXz 8sDiFnwPnN6LB8UMYvplnohu93FWJpVazrLY74G0iLAYWFHXcqhQRaib/jBlh7elarX4 g3cA== X-Gm-Message-State: AOPr4FUNLjvSke+oLkSdFu2hU7ec/E7SQ601EJxvLxos09Ak+xOiFiQm60/x2gKR2dByt6g3vyBxT2SUXBfTDQ== MIME-Version: 1.0 X-Received: by 10.107.175.104 with SMTP id y101mr29373457ioe.113.1460998926461; Mon, 18 Apr 2016 10:02:06 -0700 (PDT) Received: by 10.107.133.162 with HTTP; Mon, 18 Apr 2016 10:02:06 -0700 (PDT) In-Reply-To: <5715079B.9010408@selasky.org> References: <5714C86A.8050204@selasky.org> <20160418151639.634d571d@fujitsu> <5714DC98.7090208@selasky.org> <5715079B.9010408@selasky.org> Date: Mon, 18 Apr 2016 13:02:06 -0400 Message-ID: Subject: Re: qsort() documentation From: Ryan Stone To: Hans Petter Selasky Cc: Ed Schouten , Aleksander Alekseev , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:02:07 -0000 On Mon, Apr 18, 2016 at 12:13 PM, Hans Petter Selasky wrote: > Did anyone try to generate such a fiendish set of data, and see how > quadratic the FreeBSD's qsort() becomes? > Not me, but it has been done: http://calmerthanyouare.org/2014/06/11/algorithmic-complexity-attacks-and-libc-qsort.html From owner-freebsd-current@freebsd.org Mon Apr 18 17:36:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4F6EB131D6 for ; Mon, 18 Apr 2016 17:36:13 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F6031F5B for ; Mon, 18 Apr 2016 17:36:13 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1461000972; bh=2h2F5dwKwHDuoVZN+1c0Tnj5PngUoj9xP1joSTVftag=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=n6+q6tvnlG+vGTOftkcgT25Al8umNrIClXzU/u7jA+g5x9esW0bvaWjlTZOkl7Fhp50HyBdvWM+ej7u9h6InWIFEXu6rp96MFD2LjnHJXZH1INBFfDRKZaxrTw+jyTXSth6gcQfIbAVO9zgTBZ2fJh3ipZ5J1CJNgTmMzctx1w6ZkspzOvFVcC+0Fa6NMBFImSoTe7b1PiO6ZRBvB/a6Pdgk09jCl8Pp628EZ7eWTe6Bbay76QQBXok1wQVl64GDbPLE61UkJDYI6HtINOZgNkpQ+seE55RkgMrsBonpzW9vvQSQeVeG9jfbjJHP/9nvReHr9uaUrBk5M2qn2C2Hbg== Received: from [98.139.170.178] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2016 17:36:12 -0000 Received: from [98.139.211.199] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2016 17:36:12 -0000 Received: from [127.0.0.1] by smtp208.mail.bf1.yahoo.com with NNFMP; 18 Apr 2016 17:36:12 -0000 X-Yahoo-Newman-Id: 315135.96304.bm@smtp208.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: j.X3gI4VM1kTfJsDSxkPQK5UsZ8BkQ6j.XhCITTTd5HRYzt SJjoqmP45iLcKG7nRn.Mw9HUHYB.gGzPwVY5Fw1ComEKt1htSi8vW1ZxJlDL ZIrO84887kTTp6tiM6TqT_Ntjo8mOesEZvzJWvU9i4UbJcRtGYMWdXuiYSfB s_lqBQIBWnwVFJApFgzaLIbcj86.3fNSIiGyV_6.xyc.jhQU2LK4zIr2e_Vs PAECmAnMLuapN1dck9Nz9lu0w5IMtsl_ZNo3BiMVP4gGq1a6SYUnhyuClHmK DPhiXyYx7GWEwSKCzUA33yGwvcNwknbYMo.PqlVlhm2JPtiKJWcHa2kJaFc4 .Dc0iUhFEQRpQjC5zFRcauDuem9J8DN0_uT65irii0Ch5y8dPmzEwvJFnRE4 KEP6OytzBf1Ic9e.CubbtI4qrLlGQ8TmwJjyZ8d5ePxh3xuMewEgLL7gLGVj FNK3o2v5Qs.3JI.KuXnz.wTyaNVNq2fslBY8mFSUraaoX26hxs7FlraC_LZj fZjVO_m1v1S4ojYM8wgCqqMYWkdkCqJA- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: CFR: extend use of nitems() macro in the kernel. To: Hans Petter Selasky , FreeBSD Current References: <57128385.6090307@FreeBSD.org> <5714850C.6000106@selasky.org> From: Pedro Giffuni Message-ID: <57151B0D.2040104@FreeBSD.org> Date: Mon, 18 Apr 2016 12:36:13 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5714850C.6000106@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:36:13 -0000 On 04/18/16 01:56, Hans Petter Selasky wrote: > On 04/16/16 20:25, Pedro Giffuni wrote: >> M sys/dev/usb/input/ukbd.c >> M sys/dev/usb/serial/u3g.c >> M sys/dev/usb/serial/uchcom.c >> M sys/dev/usb/serial/umcs.c >> M sys/dev/usb/serial/uplcom.c > > Approved. Maybe you can remove the superfluous pair of parenthesis after > the substitution? > Thanks: I'll look at improving the script. FWIW, I already have a roundup2/rounddown2 semantic patch but it is slow. Pedro. From owner-freebsd-current@freebsd.org Mon Apr 18 18:52:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28472B12E4D; Mon, 18 Apr 2016 18:52:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id A11AC1982; Mon, 18 Apr 2016 18:52:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id C1A417E8; Mon, 18 Apr 2016 21:52:28 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> To: Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <57152CE5.5050500@FreeBSD.org> Date: Mon, 18 Apr 2016 21:52:21 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160302235429.GD75641@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XtIdACha8xTfvoG8FgjBstUvU774Ajm8B" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:52:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XtIdACha8xTfvoG8FgjBstUvU774Ajm8B Content-Type: multipart/mixed; boundary="FdWJfP2PF2txj1CjoXQmWiav8p6mf9jkD" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Message-ID: <57152CE5.5050500@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> In-Reply-To: <20160302235429.GD75641@FreeBSD.org> --FdWJfP2PF2txj1CjoXQmWiav8p6mf9jkD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03.03.2016 02:54, Glen Barber wrote: > At present, the base system consists of 755 packages with the default > build (empty src.conf(5) and make.conf(5)) for amd64. The number of > packages depends on several factors, but for most cases a runtime binar= y > is split into several components. In particular, most shared libraries= > are individually packaged, in addition to debugging symbols, profiling > libraries, and 32-bit packaged separately. I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 packages?! WHY?! What are reasons and goals to split base in such enormous number of packages? I understand debug symbols as separate package (one for almost whole base, except several "contrib" parts), I could understand separate package with all static libs (again, ONE package for all system static libraries) and headers. I could understand separate packages for SEVERAL "contrib" chunks: sendmail (it is often replaced by postfix / exim now), kerberos, toolchain and, maybe, unbound. But extract EACH WITH_XXX feature to several separate packages? It looks like nightmare. IMHO, it is very inconvenient for "default" installation and it doesn't look as good replacement to NanoBSD. NanoBSD is much more customized, typically. I don't have THAT number of packages even on "workstation"-like setup with X and some desktop software now, leave sever installation alone. And I don't see, how could this fragmentation could help me, as administrator. But it adds load to "pkg", to many pkg-related scripts, to "pkg version" output, at last! Why, or why, such fine-grained splitting (or should I say "shattering") of base was chosen? Is here good rationale for this? --=20 // Lev Serebryakov --FdWJfP2PF2txj1CjoXQmWiav8p6mf9jkD-- --XtIdACha8xTfvoG8FgjBstUvU774Ajm8B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFSzrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePqvkP/ispXjrrs8C+G2PVPm+btdDU lyxpiMuM0A5cfa+xyJtFhEU+FgVeisjzroyY5g8d1w+nlxD0hUvI3sEKVUWPOfbM rkVFOOddjxcuRSbficcPGM/aVU/4CMaS160DYHri3vaMq1Iiifzwxa9Bi9ihxoji Su9CEhR6sW4hR7QJxRtcTWNvOgxjesg7xKRU7uDO3IJqbXRtSAX7kK4FYhG83i2W VXd6R5JTUy0Kj0t3pSiZIAg+xOTLYhy3cI9BxGIuvHRZceXAEjQJkAyt8DLyVkby RBvbK2J+fvmCWEJD2UwnZbJfHTuBPWxbK8hO0M8RjUzHJUiNI3CpPCwESNwtXssm AQoIxz8nIVlMrxxeHyroZEeC94442e/iGVmJ8onSAGnB9fVF82gK6wzPJF4rwgdO t+gtjhp3CcAUuau3Ah5uMZzHb3tYNsWGoYURwa3wre+u/LFNwH+7mjI4ctGsYckK GktU+W0wh1VZNhjfEDIepEqJCZAH5X4Q4qLG8LBEtx4g4nVM5EEGphyE6gB/f+9N tIVx1JDK6xSFiRFnFheBUdfgpoiUUQ018pybXkbevqMWdQbzntaFLlBoD46TomfA IHe4yZ7jk4Z8EQaLiH0pKOuzC/uRq5XucaJaStTosdERQ7l3pKI/l5ox5iTaIZUD v+VgggtMNW+jcMuAgGas =kbEe -----END PGP SIGNATURE----- --XtIdACha8xTfvoG8FgjBstUvU774Ajm8B-- From owner-freebsd-current@freebsd.org Mon Apr 18 18:53:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 305C2B12F1E for ; Mon, 18 Apr 2016 18:53:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E02231AC3; Mon, 18 Apr 2016 18:53:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D6CCEB972; Mon, 18 Apr 2016 14:53:46 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Pedro Giffuni Subject: Re: CFR: extend use of nitems() macro in the kernel. Date: Mon, 18 Apr 2016 11:27:58 -0700 Message-ID: <1920453.prUgCpdaXV@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <57128385.6090307@FreeBSD.org> References: <57128385.6090307@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 18 Apr 2016 14:53:46 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:53:48 -0000 On Saturday, April 16, 2016 01:25:09 PM Pedro Giffuni wrote: > Hello; > > Using coccinelle, and some hand re-formatting, I generated a patch to > make use of the nitems() macro in sys, which is too big for > phabricator [1]. > > I was careful to exclude anything from the contrib directory or > any code that is shared with userland (as to not have to include > additional headers). > > The patch is big but pretty safe, I think. The changes are small but > still it touches many files[1]. > > I would like some feedback on the convenience of doing such replacement. > If it is a good idea we could do the same for roundup2() and, in fact, > I think DragonFly has already done this. > > Regards, > > Pedro. > > [1] https://people.freebsd.org/~pfg/patches/sys-nitems.diff > > [2] For those too lazy to check [1], here is a list of affected files. > > M sys/amd64/amd64/amd64_mem.c > M sys/amd64/amd64/machdep.c > M sys/amd64/linux/linux_sysvec.c > M sys/amd64/linux32/linux32_sysvec.c > M sys/arm/amlogic/aml8726/aml8726_clkmsr.c > M sys/arm/arm/db_interface.c > M sys/arm/at91/at91_pmc.c > M sys/arm/mv/armadaxp/armadaxp.c > M sys/arm/ti/cpsw/if_cpsw.c > M sys/arm/xscale/ixp425/ixp425.c > M sys/boot/common/part.c > M sys/boot/efi/loader/bootinfo.c > M sys/boot/mips/beri/boot2/boot2.c > M sys/boot/uboot/common/metadata.c > M sys/cam/ata/ata_da.c > M sys/cam/ata/ata_xpt.c I would perhaps remove ata_quirk_table_size entirely and replace its use with nitems() directly. Probably best if that was a separate commit though from the near-mechanical replacement. > M sys/cam/cam.c Same here. num_cam_status_entries is only used in one place and I think directly using nitems() is probably clearer overall. > M sys/cam/scsi/scsi_all.c Possibly the same here with sense_key_table_size. > M sys/cam/scsi/scsi_cd.c > M sys/cam/scsi/scsi_da.c > M sys/cam/scsi/scsi_sa.c > M sys/cam/scsi/scsi_xpt.c Same as for ata_quirk_table_size (ironically this used the size in one place and the expanded form of nitems in another while the ata variant at least used the size in both places). > M sys/cam/scsi/smp_all.c > M sys/compat/linux/linux_socket.c > M sys/ddb/db_variables.c > M sys/dev/adb/adb_kbd.c > M sys/dev/advansys/adv_isa.c > M sys/dev/advansys/advlib.c > M sys/dev/advansys/adw_pci.c Same here for num adw_num_pci_devs (only used once) > M sys/dev/advansys/adwlib.c Probably the same here for adw_num_sync_rates (used twice). > M sys/dev/ae/if_ae.c Same here for AE_DEVS_COUNT (only used once). > M sys/dev/age/if_age.c > M sys/dev/agp/agp.c > M sys/dev/agp/agp_ali.c > M sys/dev/agp/agp_amd64.c > M sys/dev/aha/aha_isa.c > M sys/dev/aic/aic.c > M sys/dev/aic/aic_cbus.c Same here for AIC_ISA_NUMPORTS (only used once). > M sys/dev/aic/aic_isa.c As above. > M sys/dev/ale/if_ale.c > M sys/dev/altera/atse/if_atse.c > M sys/dev/atkbdc/atkbd.c > M sys/dev/atkbdc/atkbdc.c > M sys/dev/atkbdc/psm.c > M sys/dev/bktr/bktr_core.c > M sys/dev/bwi/bwirf.c > M sys/dev/bwn/if_bwn.c > M sys/dev/cardbus/cardbus_cis.c > M sys/dev/digi/digi.c > M sys/dev/digi/digi_isa.c > M sys/dev/dwc/if_dwc.c > M sys/dev/ed/if_ed_hpp.c > M sys/dev/ed/if_ed_isa.c > M sys/dev/ed/if_ed_pci.c > M sys/dev/fb/creator.c Same here for CREATOR_FB_MAP_SIZE (only used once). > M sys/dev/fb/fb.c > M sys/dev/fb/machfb.c > M sys/dev/fb/vesa.c > M sys/dev/fb/vga.c > M sys/dev/flash/mx25l.c > M sys/dev/hatm/if_hatm.c > M sys/dev/hifn/hifn7751.c > M sys/dev/hwpmc/hwpmc_amd.c Same here for amd_event_codes_size (only used twice). > M sys/dev/hwpmc/hwpmc_core.c Same here for niap_events. > M sys/dev/hwpmc/hwpmc_e500.c e500_event_codes_size isn't even used. It should just be removed. > M sys/dev/hwpmc/hwpmc_mips24k.c > M sys/dev/hwpmc/hwpmc_mips74k.c > M sys/dev/hwpmc/hwpmc_mpc7xxx.c Same here for mpc7xxx_event_codes_size. > M sys/dev/hwpmc/hwpmc_octeon.c > M sys/dev/hwpmc/hwpmc_uncore.c Same here for nucp_events. > M sys/dev/hwpmc/hwpmc_xscale.c Same here for xscale_event_codes_size. > M sys/dev/if_ndis/if_ndis.c > M sys/dev/jme/if_jme.c > M sys/dev/kbd/kbd.c > M sys/dev/le/if_le_isa.c > M sys/dev/le/if_le_lebuffer.c Same here for NLEMEDIA (only used once). > M sys/dev/le/if_le_ledma.c > M sys/dev/mlx/mlx.c > M sys/dev/mxge/if_mxge.c > M sys/dev/nand/nand_id.c > M sys/dev/ncr/ncr.c > M sys/dev/nctgpio/nctgpio.c > M sys/dev/nfe/if_nfe.c > M sys/dev/patm/if_patm_attach.c > M sys/dev/pccard/pccard_cis_quirks.c Same here for n_pccard_cis_quirks (only used once). > M sys/dev/rc/rc.c > M sys/dev/re/if_re.c > M sys/dev/rl/if_rl.c > M sys/dev/rndtest/rndtest.c Same here for RNDTEST_NTESTS (only used once). > M sys/dev/sf/if_sf.c > M sys/dev/sge/if_sge.c Same here for 'cnt' (only used once). > M sys/dev/siba/siba.c Same here for 'bound'. I would actually simplify this function even further so it just does 'return (sd)' instead of 'break' in the loop body. This means you can remove the '==' check and just 'return (NULL)' if the loop completes. It also means that 'bound' is then only used once. > M sys/dev/sio/sio.c > M sys/dev/sound/isa/gusc.c > M sys/dev/sound/pci/emu10kx.c Same here for 'n_cards' (it is only used once after each assignment). > M sys/dev/speaker/spkr.c > M sys/dev/stge/if_stge.c > M sys/dev/uart/uart_kbd_sun.c > M sys/dev/uart/uart_subr.c Same here for 'uart_nclasses' (only used once). > M sys/dev/usb/input/ukbd.c > M sys/dev/usb/serial/u3g.c > M sys/dev/usb/serial/uchcom.c Same here for NUM_DIVIDERS (only used once). > M sys/dev/usb/serial/umcs.c > M sys/dev/usb/serial/uplcom.c Same here for N_UPLCOM_RATES (only used once). > M sys/dev/vkbd/vkbd.c > M sys/dev/wbwd/wbwd.c > M sys/fs/autofs/autofs.c > M sys/fs/nfs/nfs_commonkrpc.c > M sys/geom/part/g_part_bsd.c > M sys/geom/part/g_part_ebr.c > M sys/geom/part/g_part_ldm.c > M sys/geom/part/g_part_mbr.c > M sys/i386/i386/i686_mem.c > M sys/i386/i386/machdep.c > M sys/i386/ibcs2/ibcs2_sysvec.c > M sys/i386/linux/linux_sysvec.c > M sys/kern/kern_dump.c > M sys/kern/kern_ffclock.c > M sys/kern/kern_jail.c > M sys/kern/kern_ktrace.c > M sys/kern/subr_hash.c Same here for NPRIMES (only used once). > M sys/kern/subr_witness.c Same here for blessed_count (only used once). > M sys/kern/sysv_msg.c > M sys/kern/sysv_sem.c > M sys/kern/uipc_usrreq.c > M sys/mips/mips/db_interface.c > M sys/mips/nlm/board.c > M sys/mips/nlm/xlp_machdep.c Same here for nreg (only used once). > M sys/mips/rmi/dev/nlge/if_nlge.c Same here for n_gmac_buckers and n_regs (each only used once). > M sys/net/netisr.c I would do the same here for netisr_dispatch_table_len. It is used in three loops, but in all three the code would be: for (i = 0; i < nitems(foo); i++) { /* use foo[i] */ } For that idiom, I think using nitems is clearer to the reader vs one of NFOO, nfoo, foo_size, foo_len, etc. if for no other reason than consistency. I think it is also more explicit. > M sys/net/rtsock.c > M sys/netgraph/atm/ng_atm.c > M sys/netgraph/bluetooth/socket/ng_btsocket.c Same here for ng_btsocket_protosw_size (only used once). > M sys/netgraph/ng_gif_demux.c > M sys/netgraph/ng_iface.c Possibly the same for NUM_FAMILIES in these two files. > M sys/netgraph/ng_socket.c > M sys/netinet/in_proto.c > M sys/netinet/tcp_syncache.c > M sys/netinet6/in6_proto.c > M sys/netipsec/key.c > M sys/netipsec/keysock.c > M sys/netnatm/natm_proto.c > M sys/netsmb/smb_smb.c SMB_DIALECT_MAX isn't used and should just be removed. > M sys/nlm/nlm_prot_impl.c Same here for version_count (only used once). > M sys/pc98/cbus/gdc.c > M sys/pc98/cbus/pckbd.c > M sys/pc98/cbus/scterm-sck.c > M sys/powerpc/powerpc/db_trace.c > M sys/powerpc/pseries/xics.c > M sys/security/audit/audit_bsm_klib.c Same here for aue_open_count and aue_openat_count (each only used once). > M sys/security/audit/bsm_errno.c Same here for bsm_errnos_count (used twice, but both in the for loop idiom). > M sys/security/audit/bsm_fcntl.c Same here for bsm_fcntl_cmd_count (used twice, but both in the for loop idiom). > M sys/security/audit/bsm_socket_type.c Same here for bsm_socket_types_count (used twice, but both in the for loop idiom). > M sys/sparc64/sparc64/db_trace.c > M sys/sparc64/sparc64/elf_machdep.c > M sys/sparc64/sparc64/trap.c > M sys/vm/vm_pager.c Same here for npagers (only used once). > M sys/x86/isa/atpic.c > M sys/x86/x86/identcpu.c > M sys/x86/x86/local_apic.c The changes overall look fine to me. I just think we should take the chance to inline cases where the variable is only ever used once or is only used in the for loop idiom where I think the explicit nitems() is clearer to the reader. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Apr 18 18:53:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 347DBB12F2A for ; Mon, 18 Apr 2016 18:53:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16CA21ACA for ; Mon, 18 Apr 2016 18:53:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 31539B989; Mon, 18 Apr 2016 14:53:48 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Mis-use of BUS_PASS_ORDER_MIDDLE Date: Mon, 18 Apr 2016 10:43:17 -0700 Message-ID: <1611132.EbTME86UTe@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 18 Apr 2016 14:53:48 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:53:49 -0000 On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > I noticed several places there are code like this, especially in some= arm > low level drivers. > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass= , > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); >=20 > =E2=80=8BI feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There = are another > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter= > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. No, this is actually correct. The _ORDERED variants actually accept a SI_ORDER_* value to determine how drivers contained in a single .ko fil= e are registered (in particular if you have several drivers in a .ko file= you typically want the "top-most" driver to attach last so that all the= other drivers are ready once the actual device is attached). --=20 John Baldwin From owner-freebsd-current@freebsd.org Mon Apr 18 18:56:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A204B130CD for ; Mon, 18 Apr 2016 18:56:31 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D1C51F21 for ; Mon, 18 Apr 2016 18:56:30 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u3IIuO38051026 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2016 12:56:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u3IIuOtD051023; Mon, 18 Apr 2016 12:56:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 18 Apr 2016 12:56:24 -0600 (MDT) From: Warren Block To: Hans Petter Selasky cc: FreeBSD Current Subject: Re: qsort() documentation In-Reply-To: <5714C86A.8050204@selasky.org> Message-ID: References: <5714C86A.8050204@selasky.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 18 Apr 2016 12:56:24 -0600 (MDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:56:31 -0000 On Mon, 18 Apr 2016, Hans Petter Selasky wrote: > Hi, > > Are there any objections adding the following as part of documenting our > kernel's qsort function? > > Index: sys/libkern/qsort.c > =================================================================== > --- sys/libkern/qsort.c (revision 298202) > +++ sys/libkern/qsort.c (working copy) > @@ -45,6 +45,10 @@ > > /* > * Qsort routine from Bentley & McIlroy's "Engineering a Sort Function". > + * > + * NOTE: This implementation of qsort() was designed to not have the "was designed to avoid the" > + * worst case complexity of N**2, as seen with the regular quick sort > + * functions as described by Wikipedia. > */ Why Wikipedia, specifically? There are a lot of places that describe quicksort. How about just Note: This implementation of qsort() is designed to avoid the worst-case complexity of N**2 that is often seen with standard versions. From owner-freebsd-current@freebsd.org Mon Apr 18 18:57:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21715B13182; Mon, 18 Apr 2016 18:57:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id DBF2E1069; Mon, 18 Apr 2016 18:57:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 079237ED; Mon, 18 Apr 2016 21:57:34 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> To: Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <57152E1E.5030203@FreeBSD.org> Date: Mon, 18 Apr 2016 21:57:34 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57152CE5.5050500@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ETvTEDXO2bmsQ1BrIeKfG5Q82JcuOUMsJ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 18:57:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ETvTEDXO2bmsQ1BrIeKfG5Q82JcuOUMsJ Content-Type: multipart/mixed; boundary="m9980hDO5palxQPx4lnQ1io8cTqsnxBfr" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Message-ID: <57152E1E.5030203@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> In-Reply-To: <57152CE5.5050500@FreeBSD.org> --m9980hDO5palxQPx4lnQ1io8cTqsnxBfr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18.04.2016 21:52, Lev Serebryakov wrote: > kerberos Ok, kerberos could not be packetized at all, as it is compilation option for many other programs in tree. But 755 packets doesn't solve this problem too. --=20 // Lev Serebryakov --m9980hDO5palxQPx4lnQ1io8cTqsnxBfr-- --ETvTEDXO2bmsQ1BrIeKfG5Q82JcuOUMsJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFS4eXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTBEQAL29UtQCqsUf4YyJlbqm9Lbz Z6UAXxo2KXvI0Y2YaNVREugAB34HG1Zn6NVBRk4hJJSGSsGFUywoF+iMvxyodyqo t1E0vRLQherFi1d8L91e9z4/B9LzF5awpB4zX2xVX361x1Bk3DpLRHWnG/lPEgMv umIS8gCOeKlaNEHtt/qAhzg7emR0Nxl8Y/dz6Irot5uzU2X9fqhOeGlbf9ii6bCD PVWVU5a3o0xd2Cb8rSweQDrH0Jc8QDwpRHAQSuqL8DXVURRPnIp44QxJ7GxkDCTI n5Tc2gIZSzk/tnSjck0mEAgrgHSX3A2+nbBUQEutpYLD0dMYgcyeCKkuRH0FpBVu zXn8+y5IMgJHbg4G0bz2+UkeWpT9ulh9dMVD5X9Zqgo6DeU5xAxSh9h3X5WMUcEj 9fL45U4P/ZCFyaOvc1BqSeZjqdgat7bNMeEkcgPLJzRHH/Og5VWpnTXLFgLYQ2rM Hv6eyxaJo3Kmhp9QtYYD1njJEGWzyEADtd11EKA9mIkKAIRXtFRdchqIgTrzVp3C zkfO1HxQwlxyOFgmdnny7OMn1y8ay0U18rKTzxQJSl/fHuVB0vKwzOc1jEZ6S4lQ 16xp+n78XzZ9sfiSZALwCisMWPl+31L4B4vazacAFjbgZ00Gl6riHHTm3MreF0mN KQK0L+5OP84h/+OLXNm3 =tZDy -----END PGP SIGNATURE----- --ETvTEDXO2bmsQ1BrIeKfG5Q82JcuOUMsJ-- From owner-freebsd-current@freebsd.org Mon Apr 18 19:14:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CCD7B137E8; Mon, 18 Apr 2016 19:14:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4E45D1DE4; Mon, 18 Apr 2016 19:14:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id E8BC31135; Mon, 18 Apr 2016 19:14:26 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 18 Apr 2016 19:14:26 +0000 From: Glen Barber To: Sean Fagan Cc: lev@FreeBSD.org, freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418191425.GW1554@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S4+Kf2w4CfEO117G" Content-Disposition: inline In-Reply-To: <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 19:14:27 -0000 --S4+Kf2w4CfEO117G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > >=20 > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > > packages?! WHY?! What are reasons and goals to split base in such > > enormous number of packages? >=20 > Just a guess, having done the same thing myself: it means that updates c= an be > more targeted. >=20 This is exactly the reason, which has been answered numerous times. Glen --S4+Kf2w4CfEO117G Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFTIRAAoJEAMUWKVHj+KTPp8P+wXhCNMRrVGMZcBMLn0sGoTM 3tTgSTNm7ttAHAJembbM4IvUlan+nn/2yakkcaWFJ2xeJJXiaqphegQGiyagSrrJ TWUhyJsk1a4QBFoMzFy4xVb4DKqn3l59y6Qn2XkUbs2v+cXdR9Rf52qVbDdmgUpY 8ncI7cxWLfqzbiw4rRU1M+K+XLoTAlG+cs15k/OU88JdmQ+Znj4a3aBr6TmfT520 GmxosLNLvjSwRH/GSr558kfhmAahOrw/DHu6mHWOhQEuMWSAmyKyq5RI+dj4xUAB +r5rG8t8E7HRiQu/JeK1sYQwwMe6/Kkx7VROVxb95sThtb5DDlkFLJBcrVbU0LTN PwendbPXiG7rcRSody2LOWPOa6WJhyA4IayrsfaY9CBTkHzkHU2Iwpbz/M3lK28I mb0j1ka3OTPGpEdWY+PIA+8Jr2qsQ+y46snyEd7VTrlPj23xszfuT8gDhEBUzCrZ U/lUv7QnIu17gTpQnFYEtlE7Pw48mm6OHPYP6bqDAuuQMGqGJA6llpLQmHo/b0rf 3DdLWyJ2MhAwAjs2NDVefWaZKp1tnRVP9NdBhjkcU9+dzTViSP1FmH4fR5weX4rG ecne1RKJIuLE+/lbBg7OgTWjvRweHvOD/UHJnejb8ysv2KbJ0paKe63QXfedup+e 2sKyzqiHWPADuiDzGH0b =Qgea -----END PGP SIGNATURE----- --S4+Kf2w4CfEO117G-- From owner-freebsd-current@freebsd.org Mon Apr 18 19:01:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D675B1344A for ; Mon, 18 Apr 2016 19:01:53 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: from barracuda.ixsystems.com (barracuda.ixsystems.com [12.229.62.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AFB416EA for ; Mon, 18 Apr 2016 19:01:53 +0000 (UTC) (envelope-from sef@ixsystems.com) X-ASG-Debug-ID: 1461006108-08ca0417883f8c10001-XDYc8F Received: from zimbra.ixsystems.com ([10.246.0.20]) by barracuda.ixsystems.com with ESMTP id fTa4d3mI6bDuB07Z (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2016 12:01:48 -0700 (PDT) X-Barracuda-Envelope-From: sef@ixsystems.com X-Barracuda-RBL-Trusted-Forwarder: 10.246.0.20 X-ASG-Whitelist: Client Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id B8A38C40551; Mon, 18 Apr 2016 12:01:48 -0700 (PDT) Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3PZ_izt4-_rB; Mon, 18 Apr 2016 12:01:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id E538DC40560; Mon, 18 Apr 2016 12:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at ixsystems.com Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AkRJTASP39-w; Mon, 18 Apr 2016 12:01:47 -0700 (PDT) Received: from [10.250.1.40] (unknown [10.250.1.40]) by zimbra.ixsystems.com (Postfix) with ESMTPSA id B31B1C404DD; Mon, 18 Apr 2016 12:01:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Sean Fagan X-ASG-Orig-Subj: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <57152CE5.5050500@FreeBSD.org> Date: Mon, 18 Apr 2016 12:01:46 -0700 Cc: Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: UNKNOWN[10.246.0.20] X-Barracuda-Start-Time: 1461006108 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://10.246.0.26:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Mailman-Approved-At: Mon, 18 Apr 2016 19:17:39 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 19:01:53 -0000 On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: >=20 > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > packages?! WHY?! What are reasons and goals to split base in such > enormous number of packages? Just a guess, having done the same thing myself: it means that updates = can be more targeted. Sean. From owner-freebsd-current@freebsd.org Mon Apr 18 19:32:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E2FEB130BD; Mon, 18 Apr 2016 19:32:07 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BFDE1BF5; Mon, 18 Apr 2016 19:32:07 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-124.airbears2.berkeley.edu [136.152.142.124]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3IJLSxV012136 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Apr 2016 12:21:28 -0700 Subject: Re: [CFT] packaging the base system with pkg(8) To: Glen Barber , Sean Fagan References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> Cc: lev@freebsd.org, freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org From: Nathan Whitehorn Message-ID: <571533B8.6090109@freebsd.org> Date: Mon, 18 Apr 2016 12:21:28 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160418191425.GW1554@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbZbJpPUwd5jajtYqBeiTkNsO6njAYHiuK1Isz1kVZXtc7cHj5fs3davLqIMiavA7d412y/QwYWTL48wlhwEqKj3cYBblcPSYs= X-Sonic-ID: C;ZsXIv5oF5hGyJ7eqjlfmnQ== M;JEf3v5oF5hGyJ7eqjlfmnQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 19:32:07 -0000 On 04/18/16 12:14, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: >>> I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 >>> packages?! WHY?! What are reasons and goals to split base in such >>> enormous number of packages? >> Just a guess, having done the same thing myself: it means that updates can be >> more targeted. >> > This is exactly the reason, which has been answered numerous times. > > Glen > That's a good reason -- and a very nice outcome of having base system packages -- but I worry that it may be going too far. The most granular updates would be if every file were its own package, which is obviously crazy, and so there is some middle ground. Needing to grab a whole new base.txz is probably too much (60 MB), but splitting that into even 6 or 7 pieces moves the updates to replacements with typical size (a few MB) that are no larger than typical package updates for ports. -Nathan From owner-freebsd-current@freebsd.org Mon Apr 18 19:40:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D233FB13459; Mon, 18 Apr 2016 19:40:11 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BF23610E0; Mon, 18 Apr 2016 19:40:11 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 5EDB21880; Mon, 18 Apr 2016 19:40:11 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 18 Apr 2016 19:40:10 +0000 From: Glen Barber To: Nathan Whitehorn Cc: Sean Fagan , lev@freebsd.org, freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418194010.GX1554@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V6LUty14dADzmtgW" Content-Disposition: inline In-Reply-To: <571533B8.6090109@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 19:40:11 -0000 --V6LUty14dADzmtgW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote: >=20 >=20 > On 04/18/16 12:14, Glen Barber wrote: > >On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > >>On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > >>>I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > >>>packages?! WHY?! What are reasons and goals to split base in such > >>>enormous number of packages? > >>Just a guess, having done the same thing myself: it means that updates= can be > >>more targeted. > >> > >This is exactly the reason, which has been answered numerous times. > > > >Glen > > >=20 > That's a good reason -- and a very nice outcome of having base system > packages -- but I worry that it may be going too far. The most granular > updates would be if every file were its own package, which is obviously > crazy, and so there is some middle ground. Needing to grab a whole new > base.txz is probably too much (60 MB), but splitting that into even 6 or 7 > pieces moves the updates to replacements with typical size (a few MB) that > are no larger than typical package updates for ports. This granularity allows easy removal of things that may not be wanted (such as *-debug*, *-profile*, etc.) on systems with little storage. On one of my testing systems, I removed the tests packages and all debug and profiling, and the number of base system packages is 383. Glen --V6LUty14dADzmtgW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFTgaAAoJEAMUWKVHj+KT5TwQAIKMiIMDD0g6PVp5Cq6m+gBq fEaYR52Xl0kzS7l4smoxu3BQi0SxVp/4ZHG46s/xrdVNM82L+XZnmFEOedoEjKc+ 6zRpjK6Qqyr5pLSZFYVuph0OPbnmM7CtbRZqM/kBQ2/OqpDRl6ePTgpVaahD/5zM urCGlq1q/655Nx2pRzD+/PZIWPrOfSwyGfLMHT0piXuy29OL1Gq3pbX8+GherWnl O4GDf3ngmPinWPw3b9dJHaT12IFxXJ8tjBjKVn0FNgwqkW5S2pwWPLexyPfL+/hL MMVMPuMMM2SWVvRgqDbZM4lymIiSbpXTsh/eY60vJ1yLdeqWaotCc85XalEot8h2 xfAIPGBe/L9KiL8WaxJ3d/2XIOytTWTgelC50ey3U+l+QQpBe6SZBAHnSFO4kYYN VCj0kIOFufyKdrFdCoGzqg6LCK8R/hq6DwJGA/lH9n52KAL+eSlQsqMoROLO+nl4 WZiKSd5aCP4MmCb5Fwj8OzFLj4ID/ywrqykT1v6yFA+UhcTdQMMZ1UQG17dGRPiO +c9eTYK7J2MzIZuilKCIXD9B3ZpyFcTRf3vkGC6C3olMGgRrIK5THwcfOmzb6utR Civ8ORc5vQqFS8qCMRtl4JDW1cQ+z6qecX8YAWROXupELfUIASxDSMu5NwT35PZK 0TmS/QvqLlVGpU4nhZRz =tOGp -----END PGP SIGNATURE----- --V6LUty14dADzmtgW-- From owner-freebsd-current@freebsd.org Mon Apr 18 19:42:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56B01B135D7; Mon, 18 Apr 2016 19:42:01 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-ig0-x241.google.com (mail-ig0-x241.google.com [IPv6:2607:f8b0:4001:c05::241]) (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 1F01C14F3; Mon, 18 Apr 2016 19:42:01 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-ig0-x241.google.com with SMTP id qu10so12222397igc.1; Mon, 18 Apr 2016 12:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=XwTdXNr1N3kNzCG86Gxk9LjxBJW6x6aWT/7m4YQ2/Os=; b=yDmjjh1NaGeoCChF+JWfUmQUQMli0JLIoVxnOT8LXsxAuJzcwz/8cAvF5EenWDoxaM qqIpW/Xd7BZDLaL78Q/srtqxOQ7lzilwwC4l/74HpE1qXG+yG+fm9M0MGi+O6A1vOKg/ xcH2KL9/LoVQ6WcHImSUt7bnrxHIoynLnK+qnFJDiT9mZaFr/CaPQSGLuthBKC/SOhhR jgP6slVMJYRowTCbUTguiZrYxBM7rKrjVotP7CBkj+DHmDONABhhE3qVbtoz29s8UWlH gkv0c9ImoSdacZ9m4v5TITU/ImoXuz7e44ejielwYVHuLLeshlE6qMrppULOv2KbOcjC FcBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=XwTdXNr1N3kNzCG86Gxk9LjxBJW6x6aWT/7m4YQ2/Os=; b=dCK008aguslB3T1oSq2rAqshXWBi0NZfxDnYb3OZuInNBfEmwmY6OmsH14GQB+zg+H yF7h9AR0gW6cD3gcr8xbNpbIPZSt0Bj+MZJSWrqkl9hgbdqif3aZPBnVJIep8YEHODqr Vtp1a7z3lUOBP6rWwcyAULkiFQ74nI1W2GpZ0YYsfLygiKklIswZ4djS60cKngF08y7A 9DCU0cTMyQ6bV2FOVzlszOkokvCVxz+hET840OqQ1uRZS7d2dSDnUtMepCSqUISHkrC7 vP6TOccRtZUjfQfaXdB8eqy1p4IYvpDl7Czab6PHKH9Zn69LnisziEG6N0ClKyNSJMEr OacQ== X-Gm-Message-State: AOPr4FXuhvPp+t9VfEkDk3oLJ8Be7+Xw8TZiFT/ZFMu5dGT2oqX1iThna8cFtthSGX5pmQ== X-Received: by 10.50.93.138 with SMTP id cu10mr20979974igb.96.1461008520280; Mon, 18 Apr 2016 12:42:00 -0700 (PDT) Received: from [10.0.10.3] (cpe-76-190-244-6.neo.res.rr.com. [76.190.244.6]) by smtp.googlemail.com with ESMTPSA id yf9sm209568igc.16.2016.04.18.12.41.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 12:41:59 -0700 (PDT) Message-ID: <5715389C.9090502@gmail.com> Date: Mon, 18 Apr 2016 15:42:20 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Slawa Olhovchenkov CC: Baptiste Daroussin , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org, questions@freebsd.org Subject: Re: 11.0-RELEASE pkg base & base.txz file References: <5714E89A.8000807@gmail.com> <20160418141454.GX4841@zxy.spb.ru> <20160418141601.GA26116@ivaldir.etoilebsd.net> <20160418142709.GY4841@zxy.spb.ru> <20160418150325.GZ4841@zxy.spb.ru> In-Reply-To: <20160418150325.GZ4841@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 19:42:01 -0000 Slawa Olhovchenkov wrote: > On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote: > >> On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: >> >>> On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: >>>> On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: >>>> >>>>> On 04/18/16 10:00, Ernie Luzar wrote: >>>>>> 11.0 will have pkg base, thats ok, but what does than mean for the >>>>>> base.txz file? >>>>>> >>>>>> It it going to stay as part of FBSD install? >>>>>> >>>>>> I have many scripts for creating jails which depend on the base.txz file. >>>>> It's even easier now: >>>>> >>>>> # mkdir -p /usr/jails/new >>>>> # pkg -r /usr/jails/new install -r base -g '*' >>>> And where /etc now? >>> What do you mean? >> At Jan 27 no package containing files from distributeworld. > > At Mar 02 > >> r298107 change this? >> You have NOT answered the original question, what's going to happen to the base.txz file in 11.0? From owner-freebsd-current@freebsd.org Mon Apr 18 20:02:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC9C8B13D91; Mon, 18 Apr 2016 20:02:12 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98C101F6C; Mon, 18 Apr 2016 20:02:12 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asFN6-0006y7-QP; Mon, 18 Apr 2016 23:02:12 +0300 Date: Mon, 18 Apr 2016 23:02:12 +0300 From: Slawa Olhovchenkov To: Glen Barber Cc: Nathan Whitehorn , lev@freebsd.org, freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418200212.GA4841@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160418194010.GX1554@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:02:13 -0000 On Mon, Apr 18, 2016 at 07:40:10PM +0000, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote: > > > > > > On 04/18/16 12:14, Glen Barber wrote: > > >On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > > >>On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > > >>>I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > > >>>packages?! WHY?! What are reasons and goals to split base in such > > >>>enormous number of packages? > > >>Just a guess, having done the same thing myself: it means that updates can be > > >>more targeted. > > >> > > >This is exactly the reason, which has been answered numerous times. > > > > > >Glen > > > > > > > That's a good reason -- and a very nice outcome of having base system > > packages -- but I worry that it may be going too far. The most granular > > updates would be if every file were its own package, which is obviously > > crazy, and so there is some middle ground. Needing to grab a whole new > > base.txz is probably too much (60 MB), but splitting that into even 6 or 7 > > pieces moves the updates to replacements with typical size (a few MB) that > > are no larger than typical package updates for ports. > > This granularity allows easy removal of things that may not be wanted > (such as *-debug*, *-profile*, etc.) on systems with little storage. On > one of my testing systems, I removed the tests packages and all debug > and profiling, and the number of base system packages is 383. Easy select from list of 1k items?! You kidding? From owner-freebsd-current@freebsd.org Mon Apr 18 20:03:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E49D1B13E32; Mon, 18 Apr 2016 20:03:52 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A51EB1107; Mon, 18 Apr 2016 20:03:52 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asFOk-000700-Hx; Mon, 18 Apr 2016 23:03:54 +0300 Date: Mon, 18 Apr 2016 23:03:54 +0300 From: Slawa Olhovchenkov To: Ernie Luzar Cc: Baptiste Daroussin , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org, questions@freebsd.org Subject: Re: 11.0-RELEASE pkg base & base.txz file Message-ID: <20160418200354.GB4841@zxy.spb.ru> References: <5714E89A.8000807@gmail.com> <20160418141454.GX4841@zxy.spb.ru> <20160418141601.GA26116@ivaldir.etoilebsd.net> <20160418142709.GY4841@zxy.spb.ru> <20160418150325.GZ4841@zxy.spb.ru> <5715389C.9090502@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5715389C.9090502@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:03:53 -0000 On Mon, Apr 18, 2016 at 03:42:20PM -0400, Ernie Luzar wrote: > Slawa Olhovchenkov wrote: > > On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote: > > > >> On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: > >> > >>> On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: > >>>> On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > >>>> > >>>>> On 04/18/16 10:00, Ernie Luzar wrote: > >>>>>> 11.0 will have pkg base, thats ok, but what does than mean for the > >>>>>> base.txz file? > >>>>>> > >>>>>> It it going to stay as part of FBSD install? > >>>>>> > >>>>>> I have many scripts for creating jails which depend on the base.txz file. > >>>>> It's even easier now: > >>>>> > >>>>> # mkdir -p /usr/jails/new > >>>>> # pkg -r /usr/jails/new install -r base -g '*' > >>>> And where /etc now? > >>> What do you mean? > >> At Jan 27 no package containing files from distributeworld. > > > > At Mar 02 > > > >> r298107 change this? > >> > > You have NOT answered the original question, what's going to happen to > the base.txz file in 11.0? Spliting to 800 packages, as I understund. From owner-freebsd-current@freebsd.org Mon Apr 18 20:05:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08967B13FB4; Mon, 18 Apr 2016 20:05:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EC7E0134B; Mon, 18 Apr 2016 20:05:06 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 8E1121DD8; Mon, 18 Apr 2016 20:05:06 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 18 Apr 2016 20:05:05 +0000 From: Glen Barber To: Slawa Olhovchenkov Cc: lev@freebsd.org, freebsd-pkgbase@freebsd.org, Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418200505.GY1554@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <20160418200212.GA4841@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VIT1Kna7lLfXMiZV" Content-Disposition: inline In-Reply-To: <20160418200212.GA4841@zxy.spb.ru> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:05:07 -0000 --VIT1Kna7lLfXMiZV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 11:02:12PM +0300, Slawa Olhovchenkov wrote: > > This granularity allows easy removal of things that may not be wanted > > (such as *-debug*, *-profile*, etc.) on systems with little storage. On > > one of my testing systems, I removed the tests packages and all debug > > and profiling, and the number of base system packages is 383. >=20 > Easy select from list of 1k items?! > You kidding? >=20 See the pkg(8) '-g' option. Glen --VIT1Kna7lLfXMiZV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFT3xAAoJEAMUWKVHj+KT6yAP/3Z6tR7QyKXYcH82pq9dEPCQ Ij7cTZN9XbwrxqhUfRKmJMda9C/gK/ZGqUEndSChSqEQkxjz5PnpbciS5OwytYaW AFk1O+p7PeRVV4avsAVDXd4K2G42Z+DhiK2LvXS9pUHhIbtyrYFvP3nyHKu/c30B uFDxnQO6tG+ngsoXomy3fahRCB3Z4pcWpxj+bzCtu0iMt3OoKx2mlNlBtYQbbKUS SrQGqhO+yMiDLdadHQ5/yZLHGNQn1PyclDaNvngXeDkujBOcjcYN9PEaTIKaJAG/ IzSVkCavfOaY13MLppfnFJjDCrcga0ozJ7aa+G7n+Rn973PzWJCgV+cttLo9AxkA sk65Hnkiim9/nbKHxPUXU+qu4xDjcuYiFnGwTgsiCg+BRr+CpQ21PQt0831HhqLQ om+WBxpGSV1464D4PQN5VOr5pjpuzGXkPsEeNx5XjFpYZh2NB8xt9i7HU18NAU4f l8qTjk7rjvc93/iopILzuhXeWisjVZqTou9VPZJXXx+VsfXkIiWOA25i1A795ADJ cM8Xt9Q7rRtC7Zkjx4a3r+cKXDqN9oV4oTHokM87Yo8B9X0j9LmXylck3JX+F8Y1 ycYE29EE+nF9v4gMtOIHOtW1i/+o70ADKMewJ/XDqQEIel8J/HeDtTcKfJSRbyXY a17tLHbsafPDh/wbZ+jM =KKRa -----END PGP SIGNATURE----- --VIT1Kna7lLfXMiZV-- From owner-freebsd-current@freebsd.org Mon Apr 18 20:06:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D9AEB1314F; Mon, 18 Apr 2016 20:06:45 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F26CE17A4; Mon, 18 Apr 2016 20:06:44 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asFRW-00074q-Sp; Mon, 18 Apr 2016 23:06:46 +0300 Date: Mon, 18 Apr 2016 23:06:46 +0300 From: Slawa Olhovchenkov To: Glen Barber Cc: lev@freebsd.org, freebsd-pkgbase@freebsd.org, Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418200646.GC4841@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <20160418200212.GA4841@zxy.spb.ru> <20160418200505.GY1554@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160418200505.GY1554@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:06:45 -0000 On Mon, Apr 18, 2016 at 08:05:05PM +0000, Glen Barber wrote: > On Mon, Apr 18, 2016 at 11:02:12PM +0300, Slawa Olhovchenkov wrote: > > > This granularity allows easy removal of things that may not be wanted > > > (such as *-debug*, *-profile*, etc.) on systems with little storage. On > > > one of my testing systems, I removed the tests packages and all debug > > > and profiling, and the number of base system packages is 383. > > > > Easy select from list of 1k items?! > > You kidding? > > > > See the pkg(8) '-g' option. "You have problem. You decide to use rgexps. Your have two problems" (C) From owner-freebsd-current@freebsd.org Mon Apr 18 20:07:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 945DDB1320C; Mon, 18 Apr 2016 20:07:41 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id D30D41946; Mon, 18 Apr 2016 20:07:40 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 0D86F811; Mon, 18 Apr 2016 23:07:38 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> To: Glen Barber , Nathan Whitehorn Cc: Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <57153E80.4080800@FreeBSD.org> Date: Mon, 18 Apr 2016 23:07:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160418194010.GX1554@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QXX56VuupbqeG3FHHdtl52evqOmHBHmT7" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:07:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QXX56VuupbqeG3FHHdtl52evqOmHBHmT7 Content-Type: multipart/mixed; boundary="oIcJXl8HcarqgCc4adwH8nTDQTiLBvFrf" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Glen Barber , Nathan Whitehorn Cc: Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Message-ID: <57153E80.4080800@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> In-Reply-To: <20160418194010.GX1554@FreeBSD.org> --oIcJXl8HcarqgCc4adwH8nTDQTiLBvFrf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18.04.2016 22:40, Glen Barber wrote: > This granularity allows easy removal of things that may not be wanted > (such as *-debug*, *-profile*, etc.) on systems with little storage. O= n > one of my testing systems, I removed the tests packages and all debug > and profiling, and the number of base system packages is 383. IMHO, granularity like "all base debug", "all base profile" is enough for this. Really, I hardly could imagine why I will need only 1 debug or profile package, say, for csh. On resource-constrained systems NanoBSD is much better anyway (for example, my typical NanoBSD installation is 37MB base system, 12MB /boot and 10 packages), and on developer system where you need profiled libraries it is Ok to install all of them and don't think about 100 packages for them. Idea of "Roles" from old FreeBSD installers looks much better. Again, here are some "contrib" software which have one-to-one replacements in ports, like sendmail, ssh/sshd, ntpd, but split all other FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries. Yes, lib32 on 64 bit system. It seems that it is ideological ("holy war") discussion more than technical one... --=20 // Lev Serebryakov --oIcJXl8HcarqgCc4adwH8nTDQTiLBvFrf-- --QXX56VuupbqeG3FHHdtl52evqOmHBHmT7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFT6IXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePmYQP/A27i8gILE2Hcoo59lnLIcfv ho5ulcODmjWJ+lRww3UtkyNKqEyk6yqw1uPlkBBjV+6upZv1OXv+ESPK+wUNJ85L Z9MTHHup0TYDNjQgLR+j2J9Fxa7hhRR7eE3qr+dFfjx/v+wFwJ6bctjZ52D33Lbz iznOsTxNbTCmRXaxKdVMeR5OS0wGB78Tl0brMj9YBn8stb6OinkituV+dSRDBrDL BBt8yzPdPwGL/iz9zZXTJsvjp3oMhRnyxFZszX5Ko/MoqRUr2GjO916lP8dF4bf3 KaS9QkP9d3Oqpe1FiWOrbbDAzOm4akeCsIev7NG3L5/CpcKhk0KzLb3uYhzC81Zq kd0LWvTb27VelksvJT+umvEYxjQLmn/ssyQafXPUgPyWQYEIE+dIuHU3SKWGQLkM Xdef+4g3zQOMWFHl14ErPwYu2wp8qkFaG0zBDDcAUfm20JkLfSAIsHBCpbiLTmdC qgirfDn8Z/4rN7RTeaXrQAdxNY/MOlgaZ6nVwIf5+0ofyCqB7Z5oxdEKIE3H69iA WVidAK3EQ2VsHGb2Pb03CH2/HT4OXfgt7XvgVKWW3NIdnaIY7AOOSz3Y+6E7pt1x CvpnWRYCTLcOr7LSwuSNL7W5yztY44O5j+UWsW0r46jnbSgabfkkFbOZkfl51EHS B5ooQUEbU1DfHKJCqISq =Oi1L -----END PGP SIGNATURE----- --QXX56VuupbqeG3FHHdtl52evqOmHBHmT7-- From owner-freebsd-current@freebsd.org Mon Apr 18 20:31:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65A7FB13CE3 for ; Mon, 18 Apr 2016 20:31:06 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id B1B531AD0; Mon, 18 Apr 2016 20:31:05 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Mon, 18 Apr 2016 22:30:58 +0200 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id CC110488-26DE-434F-B3E6-566A00118C5B.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Mon, 18 Apr 2016 22:30:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Rainer Duffner In-Reply-To: <57153E80.4080800@FreeBSD.org> Date: Mon, 18 Apr 2016 22:30:48 +0200 Cc: freebsd-current Current Content-Transfer-Encoding: quoted-printable Message-Id: <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.3124) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=13 total_conn=1 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 103, bad: 0, connections: 262, history: 103, asn_score: 36, asn_connections: 44, asn_good: 36, asn_bad: 0, pass:all_good, asn, asn_all_good, relaying X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:31:06 -0000 > Am 18.04.2016 um 22:07 schrieb Lev Serebryakov : >=20 > On 18.04.2016 22:40, Glen Barber wrote: >=20 >> This granularity allows easy removal of things that may not be wanted >> (such as *-debug*, *-profile*, etc.) on systems with little storage. = On >> one of my testing systems, I removed the tests packages and all debug >> and profiling, and the number of base system packages is 383. > IMHO, granularity like "all base debug", "all base profile" is enough > for this. Really, I hardly could imagine why I will need only 1 debug = or > profile package, say, for csh. On resource-constrained systems NanoBSD > is much better anyway (for example, my typical NanoBSD installation is > 37MB base system, 12MB /boot and 10 packages), and on developer system > where you need profiled libraries it is Ok to install all of them and > don't think about 100 packages for them. >=20 > Idea of "Roles" from old FreeBSD installers looks much better. Again, > here are some "contrib" software which have one-to-one replacements in > ports, like sendmail, ssh/sshd, ntpd, but split all other > FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static = libraries. > Yes, lib32 on 64 bit system. >=20 > It seems that it is ideological ("holy war") discussion more than > technical one... =46rom the discussion, I believe it=E2=80=99s primarily driven by the = need/desire to have small packages to make updates easier on the = mirror-servers. I=E2=80=99m really not sure (yet), which is worse: the current system = that pulls down some 14k small files for a system-upgrade - or a system = where the base-system is split into almost 800 packages. freebsd-update is =E2=80=9Eonly" unreliable if - you go through a proxy with authentication - that proxy doesn=E2=80=99t do http-pipelining (or does it bad/is = broken is this respect) (certain version of Sophos UTM for example=E2=80=A6= ) AFAIK. As for the packages: I wouldn=E2=80=99t mind =E2=80=9Efatter=E2=80=9C = packages. I=E2=80=99d mirror them locally anyway (I hope this is = possible - AFAIK, the freebsd-update files are not supposed to be = mirrored), and I don=E2=80=99t have a thousand servers to pull them down = all at once anyway (working on that ;-)). I=E2=80=99m pretty sure the impact on the current FreeBSD delivery = infrastructure would be quite substantial, if updates came in 60MB = chunks - esp. if there was some sort of auto-update mechanism in place. Fast-forward to the future where a lot (millions?) more embedded devices = are based on FreeBSD and pull updates from the FreeBSD infrastructure. Or if the container hype-train reached FreeBSD and people started to = containerize everything, resulting in even more base-package update = downloads. So, I can see both sides. Neither I=E2=80=99m really satisfied with. I hope a way is found to manage these number of packages without losing = sanity and that a normal pkg info doesn=E2=80=99t list them. And that pkg upgrade doesn=E2=80=99t upgrade base-packages. From owner-freebsd-current@freebsd.org Mon Apr 18 20:41:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51A3DB13068 for ; Mon, 18 Apr 2016 20:41:47 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id E07461155 for ; Mon, 18 Apr 2016 20:41:46 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 1DEA281E; Mon, 18 Apr 2016 23:41:43 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> To: Rainer Duffner Cc: freebsd-current Current From: Lev Serebryakov Organization: FreeBSD Message-ID: <57154685.4090300@FreeBSD.org> Date: Mon, 18 Apr 2016 23:41:41 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O8cVHmE8THSNP5MgSLIHkeplwNTaQ3OC3" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:41:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O8cVHmE8THSNP5MgSLIHkeplwNTaQ3OC3 Content-Type: multipart/mixed; boundary="7m9emhQCX2aDmuGitkM3ap4av7pJU6Pwi" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Rainer Duffner Cc: freebsd-current Current Message-ID: <57154685.4090300@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> In-Reply-To: <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> --7m9emhQCX2aDmuGitkM3ap4av7pJU6Pwi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18.04.2016 23:30, Rainer Duffner wrote: > From the discussion, I believe it=E2=80=99s primarily driven by the nee= d/desire to have small packages to make updates easier on the mirror-serv= ers. It is bad driver. Mirror servers are hardware. And this enormous number of packages cause problems for people (system administrators and operations). I've read almost whole thread and looks like people, who raise voice against such fine-grained splitting, are mostly ops of many servers, including legacy ones (and 11 will be legacy in 5 years, too!). Not developers, not code contributors, but "end-users" of server OS. > I hope a way is found to manage these number of packages without > losing sanity and that a normal pkg info doesn=E2=80=99t list them. > And that pkg upgrade doesn=E2=80=99t upgrade base-packages. And there are my (and not only my) worries, too! --=20 // Lev Serebryakov --7m9emhQCX2aDmuGitkM3ap4av7pJU6Pwi-- --O8cVHmE8THSNP5MgSLIHkeplwNTaQ3OC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFUaGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePvbwP/3Wns45auSdeihOiMZvNQT2L NlF1mz+ZIKTRimyecbDXTWX0zK+hmykw1kpmsplQaE99Tc6yOEfWZLhhU4Cn5+j0 uNt6azja8SZuFxJ8yMA1D122f0fvH/Krn6CkOHRkprKXiFJ4QN6qGdOEnX1JptGZ EpAuFuFdMVA5esw4sDXsS854NAiRDRo759n8ruktTvG0cawZdahc4R2L4Y0KflPe rZUPwbCBsqCAl9pLFeG9NmBYe7yFC4K95bLLcntC81K4yNm4DvNq8ZneS9tRzoeb Z5/z+/1J5DbeYXQuIW3kXNg7SiWFwRekiysvDPtCdFq14W4TE03up7SdLlx57cl/ Z8j3BLbiG5b0D77zXMGqYAQfKDdw6o8w6tmnfnJbtM/Nzpz/GKqjMFeNLRC5FQkl yBvgsFLYPzPkYYAYDx5xbUNRPiIjrVgGJ2TyPqgK0S4YOCzUWqayxC/Ur5jEpaWN y6+pFhPj6+pB1yswKCDq8O66DRLys/Q97W9RSFoEoMzKimNNdbsatJoBdTQIIUcW T7LKfQYaKNGCYz/JfYLrI/IyUhk7AfGwzB08k6EYdcOua4D76ATXD8ACNZz7bLw3 MdbfaYZMXmXkb2AV77BmFcyiHXEVXNa+c316kWQk+vNy+E0nqezOhAo9A/X5tweB ilzvWSecUuF/3RMBhqhC =dKv5 -----END PGP SIGNATURE----- --O8cVHmE8THSNP5MgSLIHkeplwNTaQ3OC3-- From owner-freebsd-current@freebsd.org Mon Apr 18 21:29:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D08ACB1333B; Mon, 18 Apr 2016 21:29:23 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B12AA1394; Mon, 18 Apr 2016 21:29:23 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:e40e:f317:bae8:c89e]) by elvis.mu.org (Postfix) with ESMTPSA id A3EA3346DE31; Mon, 18 Apr 2016 14:29:16 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: lev@FreeBSD.org, Glen Barber , Nathan Whitehorn References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> Cc: Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Alfred Perlstein Organization: FreeBSD Message-ID: <571551AB.4070203@freebsd.org> Date: Mon, 18 Apr 2016 14:29:15 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57153E80.4080800@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 21:29:23 -0000 Guys please stop arguing about the number of packages. The high granularity is VERY useful! Managing large groups of small packages is much easier than just having large packages. All this can be done by meta-packages which depend on larger package groups. Later pkg can be augmented to "remove packages not explicitly installed" which would remove leaf packages. Example: you installed "base-debug" which pulls in let's say 50 small packages, later you want all of those removed, you can do something like: "pkg delete --leafs base-debug" which should delete "base-debug" and any dangling packages it pulled in not required by other pkgs. Huge thanks to the team that implemented this! thanks. -Alfred On 4/18/16 1:07 PM, Lev Serebryakov wrote: > On 18.04.2016 22:40, Glen Barber wrote: > >> This granularity allows easy removal of things that may not be wanted >> (such as *-debug*, *-profile*, etc.) on systems with little storage. On >> one of my testing systems, I removed the tests packages and all debug >> and profiling, and the number of base system packages is 383. > IMHO, granularity like "all base debug", "all base profile" is enough > for this. Really, I hardly could imagine why I will need only 1 debug or > profile package, say, for csh. On resource-constrained systems NanoBSD > is much better anyway (for example, my typical NanoBSD installation is > 37MB base system, 12MB /boot and 10 packages), and on developer system > where you need profiled libraries it is Ok to install all of them and > don't think about 100 packages for them. > > Idea of "Roles" from old FreeBSD installers looks much better. Again, > here are some "contrib" software which have one-to-one replacements in > ports, like sendmail, ssh/sshd, ntpd, but split all other > FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries. > Yes, lib32 on 64 bit system. > > It seems that it is ideological ("holy war") discussion more than > technical one... > From owner-freebsd-current@freebsd.org Mon Apr 18 21:43:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93AE3B139B5; Mon, 18 Apr 2016 21:43:09 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54B1B1E99; Mon, 18 Apr 2016 21:43:09 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asGwm-0009Y7-Gp; Tue, 19 Apr 2016 00:43:08 +0300 Date: Tue, 19 Apr 2016 00:43:08 +0300 From: Slawa Olhovchenkov To: Sean Fagan Cc: lev@FreeBSD.org, Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418214308.GC6614@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 21:43:09 -0000 On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > > > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > > packages?! WHY?! What are reasons and goals to split base in such > > enormous number of packages? > > Just a guess, having done the same thing myself: it means that updates can be > more targeted. Realy? I am now try to upgrade test VM from CFT version (from /project) to current. Upgraded only 407 packages. All -lib32- packages don't upgraded. OK, how I do debug this? What system state I am have now? What hapened? What I need to do? From owner-freebsd-current@freebsd.org Mon Apr 18 21:48:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85220B13B9B; Mon, 18 Apr 2016 21:48:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45F8E109B; Mon, 18 Apr 2016 21:48:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asH1x-0009fO-Ax; Tue, 19 Apr 2016 00:48:29 +0300 Date: Tue, 19 Apr 2016 00:48:29 +0300 From: Slawa Olhovchenkov To: Nathan Whitehorn Cc: Glen Barber , Sean Fagan , lev@freebsd.org, freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418214829.GD6614@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <571533B8.6090109@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 21:48:27 -0000 On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote: > > > On 04/18/16 12:14, Glen Barber wrote: > > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > >>> I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > >>> packages?! WHY?! What are reasons and goals to split base in such > >>> enormous number of packages? > >> Just a guess, having done the same thing myself: it means that updates can be > >> more targeted. > >> > > This is exactly the reason, which has been answered numerous times. > > > > Glen > > > > That's a good reason -- and a very nice outcome of having base system > packages -- but I worry that it may be going too far. The most granular > updates would be if every file were its own package, which is obviously Allowing to have one file in multiple packages may be solution: base-11.0.txz have /usr/libexec/sendmail/sendmail base-11.0-p1.txz depends on base-11.0.txz and contains just single /usr/libexec/sendmail/sendmail -- security update. This packages must be installed together and presents /usr/libexec/sendmail/sendmail in both must not be error. > crazy, and so there is some middle ground. Needing to grab a whole new > base.txz is probably too much (60 MB), but splitting that into even 6 or > 7 pieces moves the updates to replacements with typical size (a few MB) > that are no larger than typical package updates for ports. > -Nathan From owner-freebsd-current@freebsd.org Mon Apr 18 21:55:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBA71B13EF4 for ; Mon, 18 Apr 2016 21:55:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7925B165D; Mon, 18 Apr 2016 21:55:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asH92-0009p8-Ap; Tue, 19 Apr 2016 00:55:48 +0300 Date: Tue, 19 Apr 2016 00:55:48 +0300 From: Slawa Olhovchenkov To: Rainer Duffner Cc: lev@FreeBSD.org, freebsd-current Current Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418215548.GE6614@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 21:55:46 -0000 On Mon, Apr 18, 2016 at 10:30:48PM +0200, Rainer Duffner wrote: > > > Am 18.04.2016 um 22:07 schrieb Lev Serebryakov : > > > > On 18.04.2016 22:40, Glen Barber wrote: > > > >> This granularity allows easy removal of things that may not be wanted > >> (such as *-debug*, *-profile*, etc.) on systems with little storage. On > >> one of my testing systems, I removed the tests packages and all debug > >> and profiling, and the number of base system packages is 383. > > IMHO, granularity like "all base debug", "all base profile" is enough > > for this. Really, I hardly could imagine why I will need only 1 debug or > > profile package, say, for csh. On resource-constrained systems NanoBSD > > is much better anyway (for example, my typical NanoBSD installation is > > 37MB base system, 12MB /boot and 10 packages), and on developer system > > where you need profiled libraries it is Ok to install all of them and > > don't think about 100 packages for them. > > > > Idea of "Roles" from old FreeBSD installers looks much better. Again, > > here are some "contrib" software which have one-to-one replacements in > > ports, like sendmail, ssh/sshd, ntpd, but split all other > > FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries. > > Yes, lib32 on 64 bit system. > > > > It seems that it is ideological ("holy war") discussion more than > > technical one... > > > > From the discussion, I believe it’s primarily driven by the need/desire to have small packages to make updates easier on the mirror-servers. > > I’m really not sure (yet), which is worse: the current system that pulls down some 14k small files for a system-upgrade - or a system where the base-system is split into almost 800 packages. Lesser of files is best. 800 packages is better then 14k. 10 packages is better then 800. > freebsd-update is „only" unreliable if > - you go through a proxy with authentication > - that proxy doesn’t do http-pipelining (or does it bad/is broken is this respect) (certain version of Sophos UTM for example…) freebsd-update broken on server side. freebsd-update not relaible on client side. freebsd-update to long even on SSD and 10Gbit connectivity. freebsd-update to long to prepare (4x times longer of one compiling) > AFAIK. > > As for the packages: I wouldn’t mind „fatter“ packages. I’d mirror them locally anyway (I hope this is possible - AFAIK, the freebsd-update files are not supposed to be mirrored), and I don’t have a thousand servers to pull them down all at once anyway (working on that ;-)). > > I’m pretty sure the impact on the current FreeBSD delivery infrastructure would be quite substantial, if updates came in 60MB chunks - esp. if there was some sort of auto-update mechanism in place. > Fast-forward to the future where a lot (millions?) more embedded devices are based on FreeBSD and pull updates from the FreeBSD infrastructure. Hundred of millions iPad and iPhones got update in near-gigabyte chunks. > Or if the container hype-train reached FreeBSD and people started to containerize everything, resulting in even more base-package update downloads. > > So, I can see both sides. Neither I’m really satisfied with. > > I hope a way is found to manage these number of packages without losing sanity and that a normal pkg info doesn’t list them. > And that pkg upgrade doesn’t upgrade base-packages. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Apr 18 22:12:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 063DFB13619; Mon, 18 Apr 2016 22:12:06 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC5DE1204; Mon, 18 Apr 2016 22:12:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asHOp-000ADQ-6h; Tue, 19 Apr 2016 01:12:07 +0300 Date: Tue, 19 Apr 2016 01:12:07 +0300 From: Slawa Olhovchenkov To: Sean Fagan Cc: lev@FreeBSD.org, Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160418221207.GF6614@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418214308.GC6614@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160418214308.GC6614@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 22:12:06 -0000 On Tue, Apr 19, 2016 at 12:43:08AM +0300, Slawa Olhovchenkov wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > > > On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > > > > > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > > > packages?! WHY?! What are reasons and goals to split base in such > > > enormous number of packages? > > > > Just a guess, having done the same thing myself: it means that updates can be > > more targeted. > > Realy? > I am now try to upgrade test VM from CFT version (from /project) to > current. > Upgraded only 407 packages. > All -lib32- packages don't upgraded. > OK, how I do debug this? > What system state I am have now? > What hapened? > What I need to do? Oh. Not only lib32. root@pkg-test:/usr/src # pkg info | grep kernel FreeBSD-kernel-generic-debug-11.0.s20160418211012 FreeBSD GENERIC kernel -debug FreeBSD-kernel-generic-release-11.0.s20160304190332 FreeBSD GENERIC kernel release Realy, I am can't see in list of 756 files what is updated and what not. From owner-freebsd-current@freebsd.org Tue Apr 19 00:09:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7595B13C14; Tue, 19 Apr 2016 00:09:16 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE1B11791; Tue, 19 Apr 2016 00:09:16 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3J09E6M019304 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Apr 2016 17:09:14 -0700 Subject: Re: [CFT] packaging the base system with pkg(8) To: Alfred Perlstein , lev@freebsd.org, Glen Barber References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> Cc: Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Nathan Whitehorn Message-ID: <5715772A.3070306@freebsd.org> Date: Mon, 18 Apr 2016 17:09:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <571551AB.4070203@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZ/dgPMLQpM16vkAMLVK9HCg+UIyu/ixZAbFDyHDlzsetLeFXZftM0iYbVRwTDKGNnUyr2uTQXj2smm+kJOQIeLLCXSzNaPKog= X-Sonic-ID: C;skAt88IF5hGVMLeqjlfmnQ== M;BKp288IF5hGVMLeqjlfmnQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 00:09:17 -0000 On 04/18/16 14:29, Alfred Perlstein wrote: > Guys please stop arguing about the number of packages. The high > granularity is VERY useful! > > Managing large groups of small packages is much easier than just > having large packages. I'm not so sure about these statements. Maintaining groups of packages can be easier, but it can be also be harder. The goal is to find the right level. And I haven't seen a case where an 800-packages level of granularity is helpful. Maybe you can suggest one? I can, however, see the reverse case, where it leads, in addition to system administration hassle, to a balkanization of the base system, the predictability of which is one of FreeBSD's greatest assets. More granularity than we have is good (having the ability to strip debug information, profiling, sendmail, the toolchain, etc.) and it is going to be very nice to have that. But I can name of order 10 packages where that makes sense. I think we will learn to regret 800. Clearly you can have too few (one giant package called "FreeBSD 11" -- although this is a model that works for many organizations) and you can have too many (every file is its own package -- no one does this). I'm not sure where the optimum is, but this seems way too far in the direction of the latter. > All this can be done by meta-packages which depend on larger package > groups. > > Later pkg can be augmented to "remove packages not explicitly > installed" which would remove leaf packages. > > Example: you installed "base-debug" which pulls in let's say 50 small > packages, later you want all of those removed, you can do something > like: "pkg delete --leafs base-debug" which should delete > "base-debug" and any dangling packages it pulled in not required by > other pkgs. But what benefit do you get from the sub-packages? Let's say you have a single package that is the debug files for one library. Why would you ever care about that specific package? I can see why you might want all the debug files as a separate thing, but this seems way too fine-grained to be useful. Put another way, the base system for FreeBSD 11 (I grabbed a powerpc64 distfile because I had it handy) has 11765 files in it, neglecting symlinks. Split into 755 packages, the average package then has just 15 files in it. You are rapidly approaching pkg info resembling ls -R / at that point and managing the system at the individual file level, which totally defeats the concept of packaging things. If you remove files in var, share, etc, and /usr/include from that list (which include things like all the timezone files, which are hopefully packaged together, or all the man pages), this average is 2.1 files per package. > > Huge thanks to the team that implemented this! Yes, of course. Please do not interpret my comments about the level of discretization of packages as in any way reflecting the project in general, which is broader than this issue. We need better tools than tar and patch to manage the system; using pkg is a huge step forward. -Nathan > > thanks. > -Alfred > > On 4/18/16 1:07 PM, Lev Serebryakov wrote: >> On 18.04.2016 22:40, Glen Barber wrote: >> >>> This granularity allows easy removal of things that may not be wanted >>> (such as *-debug*, *-profile*, etc.) on systems with little >>> storage. On >>> one of my testing systems, I removed the tests packages and all debug >>> and profiling, and the number of base system packages is 383. >> IMHO, granularity like "all base debug", "all base profile" is enough >> for this. Really, I hardly could imagine why I will need only 1 debug or >> profile package, say, for csh. On resource-constrained systems NanoBSD >> is much better anyway (for example, my typical NanoBSD installation is >> 37MB base system, 12MB /boot and 10 packages), and on developer system >> where you need profiled libraries it is Ok to install all of them and >> don't think about 100 packages for them. >> >> Idea of "Roles" from old FreeBSD installers looks much better. Again, >> here are some "contrib" software which have one-to-one replacements in >> ports, like sendmail, ssh/sshd, ntpd, but split all other >> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries. >> Yes, lib32 on 64 bit system. >> >> It seems that it is ideological ("holy war") discussion more than >> technical one... >> > From owner-freebsd-current@freebsd.org Tue Apr 19 01:24:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 351FDB14519; Tue, 19 Apr 2016 01:24:19 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 209BA1EE2; Tue, 19 Apr 2016 01:24:19 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie.bitsea.ca ([24.114.43.34]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3J1OHaT053841 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2016 18:24:18 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> To: freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Lyndon Nerenberg Message-ID: <571588BB.2070803@orthanc.ca> Date: Mon, 18 Apr 2016 18:24:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5715772A.3070306@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 01:24:19 -0000 On 2016-04-18 5:09 PM, Nathan Whitehorn wrote: > I'm not so sure about these statements. Maintaining groups of packages > can be easier, but it can be also be harder. The goal is to find the > right level. And I haven't seen a case where an 800-packages level of > granularity is helpful. Not to mention regression testing. The number of combinations of installed packages is going to be choose(1, 800) + chose(2, 800) + ... + choose(800, 800). And while some of those combinations will be non-nonsensical, many(!) won't. There aren't enough seconds in the universe to test all the viable combinations for one single release. If fact, I would suggest a good metric for package granularity be based on the set of combinations that *can* be tested in a realistic timeframe for each release. --lyndon From owner-freebsd-current@freebsd.org Tue Apr 19 02:10:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BB55B12AF2; Tue, 19 Apr 2016 02:10:02 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F412D11A6; Tue, 19 Apr 2016 02:10:01 +0000 (UTC) (envelope-from marquis@roble.com) Date: Mon, 18 Apr 2016 19:01:00 -0700 (PDT) From: Roger Marquis To: Lyndon Nerenberg cc: freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <571588BB.2070803@orthanc.ca> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 02:10:02 -0000 Lyndon Nerenberg wrote: > There aren't enough seconds in the universe to test all the viable > combinations for one single release. Can you explain what would be accomplished by testing all or even a fraction of the possible permutations of base package combinations? We don't do that for ports. Other operating systems don't do that for their base packages. Honestly, some of us are wondering what exactly is behind some of these concerns regarding base packages. Roger Marquis From owner-freebsd-current@freebsd.org Tue Apr 19 02:23:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B82FB1343D; Tue, 19 Apr 2016 02:23:14 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E3671CB5; Tue, 19 Apr 2016 02:23:14 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie.bitsea.ca ([24.114.43.34]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3J2NClG054122 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2016 19:23:13 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> From: Lyndon Nerenberg To: freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Message-ID: <5715968B.303@orthanc.ca> Date: Mon, 18 Apr 2016 19:23:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201604190201.u3J216NQ054020@orthanc.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 02:23:14 -0000 On 2016-04-18 7:01 PM, Roger Marquis wrote: > Can you explain what would be accomplished by testing all or even a > fraction of the possible permutations of base package combinations? We > don't do that for ports. The ports tree isn't a mandatory part of the system. And by definition it could not be tested that way, since it offers so many alternative implementations of specific functionality. > Other operating systems don't do that for > their base packages. I'm pretty sure Solaris had some fairly hard-core regression tests to ensure basic system functionality wouldn't be compromised by 'oddball' selections of packages offered up at install time. > Honestly, some of us are wondering what exactly is > behind some of these concerns regarding base packages. The concern is from all of us UNIX dinosaurs who predate the fine-grained packaging environment, which just worked, and who now rip our (little remaining) hair out due to unsolvable package dependency loops in the Linux machines we are forced to administer in order to pay rent. For me, as a sysadmin, I derive a negative benefit from this optimization. I guess what I'm really asking is: where is the peer reviewed research that shows this actually improves things for the not-1% of FreeBSD users? --lyndon P.S. Don't turn this into a pissing match. I really want to know how this is of net benefit to everyone. But I don't want hyperbole. I have looked at a lot of, e.g., USENIX and ACM, bibliographies and papers for justification for this, and I can't find it. It would really help (me, at least) if someone could take a moment to point me at demonstrable evidence of the benefits of this model. From owner-freebsd-current@freebsd.org Tue Apr 19 03:17:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5B40B1381C; Tue, 19 Apr 2016 03:17:13 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id BEAA61A4F; Tue, 19 Apr 2016 03:17:13 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:d97:1c0:57d4:6aac]) by elvis.mu.org (Postfix) with ESMTPSA id 40E34346DF90; Mon, 18 Apr 2016 20:17:13 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> From: Alfred Perlstein Organization: FreeBSD Message-ID: <5715A338.5060009@freebsd.org> Date: Mon, 18 Apr 2016 20:17:12 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5715968B.303@orthanc.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 03:17:13 -0000 Maybe what the "too many packages" folks need to do is write some code to hide that it's so many packages. :) I think the rule of two feet should be applied here. What we have is people that have worked quite hard to bring us something that we can easily work with, and on the other hand some folks that want something they consider even better. Personally I can't see how having the system less granular is better, since having it MORE granular is actually harder work. Can someone on the "too many packages" campaign here explain to me how having too fine a granularity stops you from making macro packages containing packages? Because honestly I can't see how having granularity hurts at all when if someone wanted to make it less granular all they would have to do is make some meta-packages. -Alfred On 4/18/16 7:23 PM, Lyndon Nerenberg wrote: > On 2016-04-18 7:01 PM, Roger Marquis wrote: >> Can you explain what would be accomplished by testing all or even a >> fraction of the possible permutations of base package combinations? We >> don't do that for ports. > > The ports tree isn't a mandatory part of the system. And by definition > it could not be tested that way, since it offers so many alternative > implementations of specific functionality. > >> Other operating systems don't do that for >> their base packages. > > I'm pretty sure Solaris had some fairly hard-core regression tests to > ensure basic system functionality wouldn't be compromised by 'oddball' > selections of packages offered up at install time. > > > Honestly, some of us are wondering what exactly is > > behind some of these concerns regarding base packages. > > The concern is from all of us UNIX dinosaurs who predate the > fine-grained packaging environment, which just worked, and who now rip > our (little remaining) hair out due to unsolvable package dependency > loops in the Linux machines we are forced to administer in order to > pay rent. For me, as a sysadmin, I derive a negative benefit from > this optimization. > > I guess what I'm really asking is: where is the peer reviewed research > that shows this actually improves things for the not-1% of FreeBSD users? > > --lyndon > > P.S. Don't turn this into a pissing match. I really want to know how > this is of net benefit to everyone. But I don't want hyperbole. I > have looked at a lot of, e.g., USENIX and ACM, bibliographies and > papers for justification for this, and I can't find it. It would > really help (me, at least) if someone could take a moment to point me > at demonstrable evidence of the benefits of this model. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Apr 19 03:24:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 123B6B13CEF; Tue, 19 Apr 2016 03:24:24 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF3FE11C3; Tue, 19 Apr 2016 03:24:23 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie.bitsea.ca ([24.114.43.34]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3J3OMlC054412 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2016 20:24:23 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Subject: Re: [CFT] packaging the base system with pkg(8) To: Alfred Perlstein , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> From: Lyndon Nerenberg Message-ID: <5715A4E1.5090606@orthanc.ca> Date: Mon, 18 Apr 2016 20:24:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5715A338.5060009@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 03:24:24 -0000 On 2016-04-18 8:17 PM, Alfred Perlstein wrote: > Can someone on the "too many packages" campaign here explain to me how > having too fine a granularity stops you from making macro packages > containing packages? > > Because honestly I can't see how having granularity hurts at all when if > someone wanted to make it less granular all they would have to do is > make some meta-packages. It's the *I have to put it back together* part that's annoying. I didn't break something that has worked, forever. It shouldn't be incumbent on me to un-break someone else's work. Now if the system ships with each-file-in-a-package, fine. Just give me gross subsets that make my life as a sysadmin liveable. E.g., base POSIX functionality should be a 'group' package. And I would hope, the default installation package. I would go for the argument that, e.g., the dev stuff (cc, yacc, lex) could be split off, but at least include the headers that match what's in /lib and /usr/lib, in a compiler agnostic set. Since the point of packages is to allow for selections of optional software. --lyndon From owner-freebsd-current@freebsd.org Tue Apr 19 07:03:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91417B14A21 for ; Tue, 19 Apr 2016 07:03:43 +0000 (UTC) (envelope-from erik+lists@cederstrand.dk) Received: from mailrelay3.public.one.com (mailrelay3.public.one.com [195.47.247.221]) (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 01217176E for ; Tue, 19 Apr 2016 07:03:42 +0000 (UTC) (envelope-from erik+lists@cederstrand.dk) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cederstrand.dk; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=vMQ8VbH20BKEXOzFIP4VW3ZQb/SsUKzfsQCOQE6UCFM=; b=YcMG6d/5/XMztRwJxCg6YzyeWWOWIGCv6ek7g0SrRkqgOu8IlioqmKIzDmDXLcvaf8EfDOtaN8GAk GlZwejSVttndPuG2B7aZM7/87WvZsJX4EG73FjWk7RG5H8j6bXE5m1XTmNawGgOMTpg/pwmcPUrQOz PqPcejG1GaFFsieg= X-HalOne-Cookie: 6ea18e367121db6bd172cbeae1a0a69ff1d11cc0 X-HalOne-ID: adec96d6-05fc-11e6-a8e4-b8ca3afa9d73 Received: from [172.20.10.2] (unknown [94.191.186.169]) by smtpfilter1.public.one.com (Halon Mail Gateway) with ESMTPSA; Tue, 19 Apr 2016 07:02:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Erik Cederstrand In-Reply-To: <571588BB.2070803@orthanc.ca> Date: Tue, 19 Apr 2016 09:02:24 +0200 Cc: freebsd-pkgbase@freebsd.org, FreeBSD-Current Content-Transfer-Encoding: quoted-printable Message-Id: <9144F2D3-F039-4F65-9760-AD5B7F47D3E3@cederstrand.dk> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> To: Lyndon Nerenberg X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:03:43 -0000 > Den 19. apr. 2016 kl. 03.24 skrev Lyndon Nerenberg = : >=20 > There aren't enough seconds in the universe to test all the viable = combinations for one single release. We don't even do that with the WITH_FOO/WITHOUT_FOO options now, so why = should that be a criteria? You can use any combination of those build = options today, sure, but if something breaks you're on your own (you're = always on your own, for that matter, since this is open source). Seriously, there arguments put forth here against packaged base are = pretty embarrassing. If you don't like packaged base, don't use it. = Build and install from SVN instead. If you're using freebsd-update = today, you essentially have 14.000 packages and a far less powerful CLI, = so why is packaged base not a step in the right direction? Erik= From owner-freebsd-current@freebsd.org Tue Apr 19 07:24:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D1D4B1304E for ; Tue, 19 Apr 2016 07:24:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8358D1FB2 for ; Tue, 19 Apr 2016 07:24:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-252-92.lns20.per4.internode.on.net [121.45.252.92]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u3J7OZFO016038 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 19 Apr 2016 00:24:39 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> From: Julian Elischer Message-ID: <5715DD2E.903@freebsd.org> Date: Tue, 19 Apr 2016 15:24:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160418191425.GW1554@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:24:41 -0000 On 19/04/2016 3:14 AM, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: >>> I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 >>> packages?! WHY?! What are reasons and goals to split base in such >>> enormous number of packages? >> Just a guess, having done the same thing myself: it means that updates can be >> more targeted. >> > This is exactly the reason, which has been answered numerous times. But I would have thought that to the logical mind, obviously the simle statement "755 packages" is the wrong answer.. more than 10 should be obviously wrong. The only POSSIBLE thing that would make this an OK thing would be to follow that statement with "But to the external user it's really 4 packages unless you elect to split one of them." It would require that all 755 do *NOT show up* in the (standard) list of installed packages. Maybe they could show up in some other special list if you asked for fine grained information. We've managed to keep this disease out of BSD since I started to do it in 1990. First we laughed/fumed at Sun's Solaris when they unbundled the compiler. then we fumed at xorg when hey took a useful package and made 190 odd packages out of it. Please don't force this on us! > Glen > From owner-freebsd-current@freebsd.org Tue Apr 19 07:31:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D99CEB1330D for ; Tue, 19 Apr 2016 07:31:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CAF60141E; Tue, 19 Apr 2016 07:31:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 8A68417BA; Tue, 19 Apr 2016 07:31:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Tue, 19 Apr 2016 07:31:17 +0000 From: Glen Barber To: Julian Elischer Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419073117.GG1554@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <5715DD2E.903@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WetXT0Y5FME7H56p" Content-Disposition: inline In-Reply-To: <5715DD2E.903@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:31:18 -0000 --WetXT0Y5FME7H56p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote: > We've managed to keep this disease out of BSD since I started to do it in > 1990. First we laughed/fumed at Sun's Solaris when they unbundled the > compiler. then we fumed at xorg when hey took a useful package and made 1= 90 > odd packages out of it. Please don't force this on us! >=20 What isn't clear about the *numerous* statements that no one is being *forced* to use packaged base? I will not reply to further emails on this thread until it's clear to me that everyone has read the previous emails. Glen --WetXT0Y5FME7H56p Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFd7FAAoJEAMUWKVHj+KTTjEP/jMbGPHFYuCDMXc+EGUMVh39 SSSnQECwzpGRaRGuMzwEZiJ4OtPR32UcIrvjD5quUNCbDoZG/MCgrH3wWmdyskL3 Ym5Ew++2BLUzUVAd1Cs3ukknpPog6DD5e+L4S+ltvyuctGF9/e3VXJss7eTf7FXX d3cqsFfzJhPDQSfqledURryTaPT7waHUyrA+L55ScAi33m9smEvlbIf4tagTVqGY kQsXm/D0xXvx4w2gV4x0oUMiWryQK0nAVS1sFUfGuIRIaY3SZh+EAYWPbQ7OnsHw o6wAiGJ2osUwCZmmnGfJPhhTCAt13UgWgZS6BNTIS/X1mWkGGFUGf9l5Nyd+Rzfn 8zyR3H93MlTZcf91TcjNeN7JzMFcRE3Wgd8NUSb4sUlMJgqi4U+BXvM2Nb90n0ab IjNeZq2eNT9h59GsExV4/S3ehBMn353P3aGwl581OVq4owNdgUrsI2NFmSVKQjyM Wnus9VkDqQ35LJPLsbJQxUtidMQ2n24hRhMdm1R6KcDzK6lJp1KZ6YgdjKoQ0LPu LYYYLRkhrNtYbqaANohlF0FAH4++q/9TKA5dAEB6+IWCZbMgr7LpqZsF6mAoUU++ n+FxbVra/SfyRVQyRRGzYRv1zpxx37sZmLI5kUxPmkOdl6TkTRzzcyyqNq3KJnlP Ndr8cFW7THGKyN8cmL+r =sD/E -----END PGP SIGNATURE----- --WetXT0Y5FME7H56p-- From owner-freebsd-current@freebsd.org Tue Apr 19 07:32:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5379DB133DB; Tue, 19 Apr 2016 07:32:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15118174F; Tue, 19 Apr 2016 07:32:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asQ9B-000NYS-UY; Tue, 19 Apr 2016 10:32:33 +0300 Date: Tue, 19 Apr 2016 10:32:33 +0300 From: Slawa Olhovchenkov To: Alfred Perlstein Cc: Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419073233.GD4841@zxy.spb.ru> References: <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5715A338.5060009@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:32:33 -0000 On Mon, Apr 18, 2016 at 08:17:12PM -0700, Alfred Perlstein wrote: > Maybe what the "too many packages" folks need to do is write some code > to hide that it's so many packages. > > :) > > I think the rule of two feet should be applied here. > > What we have is people that have worked quite hard to bring us something > that we can easily work with, and on the other hand some folks that want > something they consider even better. Personally I can't see how having > the system less granular is better, since having it MORE granular is > actually harder work. > > Can someone on the "too many packages" campaign here explain to me how > having too fine a granularity stops you from making macro packages > containing packages? > > Because honestly I can't see how having granularity hurts at all when if > someone wanted to make it less granular all they would have to do is > make some meta-packages. Because this is imposible (or very hard) to implement. After last update (realy update) I have partyaly updated system -- some packages updated, some -- not (I am expect all packages must be updated). Imposible to combine 800 packages to less meta-package and distinct improper partial update from proper. And how I am can paste this list of packages? From owner-freebsd-current@freebsd.org Tue Apr 19 07:37:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B729B1380A; Tue, 19 Apr 2016 07:37:30 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D39D1E04; Tue, 19 Apr 2016 07:37:29 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id D750228412; Tue, 19 Apr 2016 09:37:20 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1556728417; Tue, 19 Apr 2016 09:37:19 +0200 (CEST) Message-ID: <5715E02E.4000404@quip.cz> Date: Tue, 19 Apr 2016 09:37:18 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <5715A4E1.5090606@orthanc.ca> In-Reply-To: <5715A4E1.5090606@orthanc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:37:30 -0000 Lyndon Nerenberg wrote on 04/19/2016 05:24: > On 2016-04-18 8:17 PM, Alfred Perlstein wrote: >> Can someone on the "too many packages" campaign here explain to me how >> having too fine a granularity stops you from making macro packages >> containing packages? >> >> Because honestly I can't see how having granularity hurts at all when if >> someone wanted to make it less granular all they would have to do is >> make some meta-packages. Meta-packages doesn't hide anything (in list of packages and problems with dependencies) > It's the *I have to put it back together* part that's annoying. I > didn't break something that has worked, forever. It shouldn't be > incumbent on me to un-break someone else's work. +1 And you made another good point in previous e-mail about reviewed research. I would really like to see some docs about this topic. I have a feeling that some work on FreeBSD is against average users / admins and is good only for vedors of specialized or embedded devices. As many before - I am not against packaging base. It is good, but 10 - 20 packages will be enough. 800+ is too far from my feeling of "this is good feature". This seems like a nightmare to me. This was one of the reasons I don't like other OS distribuitions and I stayed with FreeBSD for more than 15 years. Miroslav Lachman From owner-freebsd-current@freebsd.org Tue Apr 19 07:44:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D620B13E34; Tue, 19 Apr 2016 07:44:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2F0513E2; Tue, 19 Apr 2016 07:44:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-252-92.lns20.per4.internode.on.net [121.45.252.92]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u3J7ilhI016130 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2016 00:44:50 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: [CFT] packaging the base system with pkg(8) To: Alfred Perlstein , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> Cc: Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Julian Elischer Message-ID: <5715E1E9.8060507@freebsd.org> Date: Tue, 19 Apr 2016 15:44:41 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571551AB.4070203@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:44:54 -0000 On 19/04/2016 5:29 AM, Alfred Perlstein wrote: > Guys please stop arguing about the number of packages. The high > granularity is VERY useful! > it's going to make us a laughing stock "look FreeBSD just split into 1.43 million packages" (effectively the same number.. it's bigger than 10) > Managing large groups of small packages is much easier than just > having large packages. err, Alfred, what planet do you live on? when they get out of sync it becomes a nightmare. If you also had a packaging system that was smart enough to manage a hierarchy of packages then "maybe".. > > All this can be done by meta-packages which depend on larger package > groups. Currently Metapackage is a way to make 10 packages look like 11 packages. The framework needs to understand to hide the 10 internal packages if they are part of a metapackage. > > Later pkg can be augmented to "remove packages not explicitly > installed" which would remove leaf packages. > > Example: you installed "base-debug" which pulls in let's say 50 > small packages, later you want all of those removed, you can do > something like: "pkg delete --leafs base-debug" which should delete > "base-debug" and any dangling packages it pulled in not required by > other pkgs. > > Huge thanks to the team that implemented this! I'm sure the work was large and will be useful in the future but we are not ready to have the system installed like this. no-one wants to see 750 packages show up when you do an enquiry on a newly installed system. I could live with: base-utils 11.1 - ktrace uninstalled - tcpdump uninstalled + dd 11.1.1 (CVE-123412 fix) but not {700 packages ) dd 11.1.1 dd with CVE fix {29 more packages} [tcpdump line is not present but you don't notice that] {10 more packages} [ktrace line would be here but you don't notice that either] {15 more packages} In other words, I have no objection to all the utilities coming in the form of little packages. but I have a major objection if that fact is at all obvious to the end user, and certainly if we need to wade through 750 packages to see what's going on. > > thanks. > -Alfred > > On 4/18/16 1:07 PM, Lev Serebryakov wrote: >> On 18.04.2016 22:40, Glen Barber wrote: >> >>> This granularity allows easy removal of things that may not be wanted >>> (such as *-debug*, *-profile*, etc.) on systems with little >>> storage. On >>> one of my testing systems, I removed the tests packages and all debug >>> and profiling, and the number of base system packages is 383. >> IMHO, granularity like "all base debug", "all base profile" is >> enough >> for this. Really, I hardly could imagine why I will need only 1 >> debug or >> profile package, say, for csh. On resource-constrained systems NanoBSD >> is much better anyway (for example, my typical NanoBSD installation is >> 37MB base system, 12MB /boot and 10 packages), and on developer system >> where you need profiled libraries it is Ok to install all of them and >> don't think about 100 packages for them. >> >> Idea of "Roles" from old FreeBSD installers looks much better. >> Again, >> here are some "contrib" software which have one-to-one replacements in >> ports, like sendmail, ssh/sshd, ntpd, but split all other >> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static >> libraries. >> Yes, lib32 on 64 bit system. >> >> It seems that it is ideological ("holy war") discussion more than >> technical one... >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Apr 19 07:55:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 784A0B14415; Tue, 19 Apr 2016 07:55:12 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42F2E1D50; Tue, 19 Apr 2016 07:55:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u3J7sugQ020258 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2016 07:55:02 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: David Chisnall In-Reply-To: <5715E1E9.8060507@freebsd.org> Date: Tue, 19 Apr 2016 08:54:48 +0100 Cc: Alfred Perlstein , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:55:12 -0000 On 19 Apr 2016, at 08:44, Julian Elischer wrote: >=20 >> All this can be done by meta-packages which depend on larger package = groups. > Currently Metapackage is a way to make 10 packages look like 11 = packages. The framework needs to understand to hide the 10 internal = packages if they are part of a metapackage. I agree, and patches to do this are very welcome. Currently, pkg is = short of contributors. I see basically three use cases for a packaged base: 1) People wanting a FreeBSD install to use as a server or workstation. = These people will install the FreeBSD 11 metapackage and not care that = it is a few hundred MBs. It would be nice if the pkg tool could present = this as a single package in list views, but that=E2=80=99s a UI issue = with pkg, not an issue with the number of packages in the base system. 2) People wanting to install embedded systems. Anyone who has tried to = run FreeBSD on a system with a small amount of flash storage will have = encountered the pain of having to use some kind of ad-hoc update. Being = able to manage updates to these systems with the same packaging tool as = you manage big systems is a big improvement. 3) People wanting to install service jails (sorry, containerised = applications). These want the smallest possible attack surface and so = want the smallest amount of the base system that they can have. Here, = small packages are an advantage. It will take a little while for ports = to learn enough about the granularity of the base system for this to = really be useful, but it would be great to be able to install nginx, for = example, in a jail and have only the handful of libraries that it needs. The big advantage of going with small packages initially, however, is = that it will allow us to get some data on what the correct groupings = are. If we have large packages, then it=E2=80=99s very hard to tell = which subsets of the packages people want. That=E2=80=99s exactly the = situation that we=E2=80=99re in now: we know some people don=E2=80=99t = want docs or games, but that=E2=80=99s about all that we know. It=E2=80=99= s easy to move to a model where we have *fewer* packages in the future, = but it=E2=80=99s harder to split them. That also applies to = dependencies. If I know that a port depends on the shell, then it=E2=80=99= s easy to update it from depending on a sh package to depending on a = core system utilities package automatically, but it=E2=80=99s very hard = to do an automatic update in the other direction. David From owner-freebsd-current@freebsd.org Tue Apr 19 08:10:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1936FB14A74; Tue, 19 Apr 2016 08:10:06 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0D15312EA; Tue, 19 Apr 2016 08:10:06 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1BAE91395; Tue, 19 Apr 2016 08:10:06 +0000 (UTC) Date: Tue, 19 Apr 2016 08:10:04 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: eadler@FreeBSD.org, araujo@FreeBSD.org, adrian@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1731721887.39.1461053406054.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2900 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:10:06 -0000 FreeBSD_HEAD_i386 - Build #2900 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2900/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2900/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2900/console Change summaries: 298256 by araujo: Use nitems() from sys/param.h. MFC after: 2 weeks. 298255 by araujo: Use nitems() from sys/param.h. MFC after: 2 weeks. 298254 by eadler: Rename units.lib -> definitions.units - this matches GNU units 2.12 add ISO country codes from units 2.12 298253 by eadler: Rename units.lib -> definitions.units - this matches GNU units 2.12 add ISO country codes from units 2.12 298252 by adrian: Add VHT power envelope parsing to ifconfig. The end of the build log: [...truncated 124934 lines...] --- tset.full --- cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o tset.full map.o misc.o set.o term.o tset.o wrterm.o -lncursesw --- tset.1.gz --- gzip -cn /usr/src/usr.bin/tset/tset.1 > tset.1.gz --- tset.debug --- objcopy --only-keep-debug tset.full tset.debug --- t- objcopy --strip-debug --add-gnu-debuglink=tset.debug tset.full tset --- all_subdir_usr.bin/tsort --- ===> usr.bin/tsort (all) --- .depend --- echo tsort.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- tsort.o --- cc -O2 -pipe -g -MD -MP -MF.depend.tsort.o -MTtsort.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/tsort/tsort.c -o tsort.o --- all_subdir_lib --- --- m_hook.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_hook.po -MTm_hook.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_hook.c -o m_hook.po --- all_subdir_usr.bin --- --- tsort.full --- cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o tsort.full tsort.o --- all_subdir_lib --- --- m_item_cur.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_cur.po -MTm_item_cur.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_cur.c -o m_item_cur.po --- all_subdir_usr.bin --- --- tsort.1.gz --- gzip -cn /usr/src/usr.bin/tsort/tsort.1 > tsort.1.gz --- tsort.debug --- objcopy --only-keep-debug tsort.full tsort.debug --- tsort --- objcopy --strip-debug --add-gnu-debuglink=tsort.debug tsort.full tsort --- all_subdir_usr.bin/tty --- ===> usr.bin/tty (all) --- .depend --- echo tty.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- tty.o --- cc -O2 -pipe -g -MD -MP -MF.depend.tty.o -MTtty.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/tty/tty.c -o tty.o --- tty.full --- cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o tty.full tty.o --- all_subdir_lib --- --- m_item_nam.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_nam.po -MTm_item_nam.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_nam.c -o m_item_nam.po --- all_subdir_usr.bin --- --- tty.1.gz --- gzip -cn /usr/src/usr.bin/tty/tty.1 > tty.1.gz --- tty.debug --- objcopy --only-keep-debug tty.full tty.debug --- tty --- objcopy --strip-debug --add-gnu-debuglink=tty.debug tty.full tty --- all_subdir_usr.bin/uname --- ===> usr.bin/uname (all) --- .depend --- echo uname.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- uname.o --- cc -O2 -pipe -g -MD -MP -MF.depend.uname.o -MTuname.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/uname/uname.c -o uname.o --- all_subdir_lib --- --- m_item_new.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_new.po -MTm_item_new.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_new.c -o m_item_new.po --- all_subdir_usr.bin --- --- uname.full --- cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o uname.full uname.o --- uname.1.gz --- gzip -cn /usr/src/usr.bin/uname/uname.1 > uname.1.gz --- all_subdir_lib --- --- m_item_opt.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_opt.po -MTm_item_opt.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_opt.c -o m_item_opt.po --- all_subdir_usr.bin --- --- uname.debug --- objcopy --only-keep-debug uname.full uname.debug --- uname --- objcopy --strip-debug --add-gnu-debuglink=uname.debug uname.full uname --- all_subdir_usr.bin/unexpand --- ===> usr.bin/unexpand (all) --- .depend --- echo unexpand.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- unexpand.o --- cc -O2 -pipe -g -MD -MP -MF.depend.unexpand.o -MTunexpand.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/unexpand/unexpand.c -o unexpand.o --- all_subdir_lib --- --- m_item_top.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_top.po -MTm_item_top.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_top.c -o m_item_top.po --- all_subdir_usr.bin --- --- unexpand.full --- cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o unexpand.full unexpand.o --- all_subdir_usr.sbin --- --- discovery.o --- cc -O2 -pipe -I/usr/src/usr.sbin/ctld/../../contrib/libucl/include -I/usr/src/usr.sbin/ctld -I/usr/src/usr.sbin/ctld/../../sys -I/usr/src/usr.sbin/ctld/../../sys/cam/ctl -I/usr/src/usr.sbin/ctld/../../sys/dev/iscsi -g -MD -MP -MF.depend.discovery.o -MTdiscovery.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.sbin/ctld/discovery.c -o discovery.o --- all_subdir_usr.bin --- --- unexpand.debug --- objcopy --only-keep-debug unexpand.full unexpand.debug --- unexpand --- objcopy --strip-debug --add-gnu-debuglink=unexpand.debug unexpand.full unexpand --- all_subdir_lib --- --- m_item_use.po --- --- all_subdir_usr.bin --- --- all_subdir_usr.bin/uniq --- ===> usr.bin/uniq (all) --- all_subdir_lib --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_use.po -MTm_item_use.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_use.c -o m_item_use.po --- all_subdir_usr.bin --- --- .depend --- echo uniq.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- uniq.o --- cc -O2 -pipe -g -MD -MP -MF.depend.uniq.o -MTuniq.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/uniq/uniq.c -o uniq.o --- all_subdir_lib --- --- m_item_val.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_val.po -MTm_item_val.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_val.c -o m_item_val.po --- all_subdir_usr.sbin --- --- isns.o --- cc -O2 -pipe -I/usr/src/usr.sbin/ctld/../../contrib/libucl/include -I/usr/src/usr.sbin/ctld -I/usr/src/usr.sbin/ctld/../../sys -I/usr/src/usr.sbin/ctld/../../sys/cam/ctl -I/usr/src/usr.sbin/ctld/../../sys/dev/iscsi -g -MD -MP -MF.depend.isns.o -MTisns.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.sbin/ctld/isns.c -o isns.o --- all_subdir_lib --- --- m_item_vis.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_item_vis.po -MTm_item_vis.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_item_vis.c -o m_item_vis.po --- all_subdir_usr.bin --- --- uniq.full --- cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o uniq.full uniq.o --- uniq.1.gz --- gzip -cn /usr/src/usr.bin/uniq/uniq.1 > uniq.1.gz --- all_subdir_usr.sbin --- --- kernel.o --- cc -O2 -pipe -I/usr/src/usr.sbin/ctld/../../contrib/libucl/include -I/usr/src/usr.sbin/ctld -I/usr/src/usr.sbin/ctld/../../sys -I/usr/src/usr.sbin/ctld/../../sys/cam/ctl -I/usr/src/usr.sbin/ctld/../../sys/dev/iscsi -g -MD -MP -MF.depend.kernel.o -MTkernel.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.sbin/ctld/kernel.c -o kernel.o --- all_subdir_usr.bin --- --- uniq.debug --- objcopy --only-keep-debug uniq.full uniq.debug --- uniq --- objcopy --strip-debug --add-gnu-debuglink=uniq.debug uniq.full uniq --- all_subdir_usr.bin/units --- ===> usr.bin/units (all) --- all_subdir_lib --- --- m_items.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_items.po -MTm_items.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_items.c -o m_items.po --- all_subdir_usr.bin --- --- .depend --- echo units.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libedit.a >> .depend --- units.o --- cc -O2 -pipe -g -MD -MP -MF.depend.units.o -MTunits.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/units/units.c -o units.o --- all_subdir_lib --- --- m_new.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_new.po -MTm_new.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_new.c -o m_new.po --- m_opts.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_opts.po -MTm_opts.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_opts.c -o m_opts.po --- m_pad.po --- cc -pg -O2 -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncursesw -I/usr/src/lib/ncurses/menuw/../ncurses -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu -MD -MP -MF.depend.m_pad.po -MTm_pad.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menuw/../../../contrib/ncurses/menu/m_pad.c -o m_pad.po --- all_subdir_usr.bin --- make[4]: make[4]: don't know how to make units.lib. Stop make[4]: stopped in /usr/src/usr.bin/units *** [all_subdir_usr.bin/units] Error code 2 make[3]: stopped in /usr/src/usr.bin 1 error make[3]: stopped in /usr/src/usr.bin *** [all_subdir_usr.bin] Error code 2 make[2]: stopped in /usr/src --- all_subdir_usr.sbin --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/usr.sbin/ctld *** [all_subdir_usr.sbin/ctld] Error code 2 make[3]: stopped in /usr/src/usr.sbin 1 error make[3]: stopped in /usr/src/usr.sbin *** [all_subdir_usr.sbin] Error code 2 make[2]: stopped in /usr/src --- all_subdir_lib --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/ncurses/menuw *** [all_subdir_lib/ncurses/menuw] Error code 2 make[4]: stopped in /usr/src/lib/ncurses 1 error make[4]: stopped in /usr/src/lib/ncurses *** [all_subdir_lib/ncurses] Error code 2 make[3]: stopped in /usr/src/lib --- all_subdir_lib/atf --- A failure has been detected in another branch of the parallel make make[8]: stopped in /usr/src/lib/atf/libatf-c++/tests/detail *** [text_test] Error code 2 make[7]: stopped in /usr/src/lib/atf/libatf-c++/tests/detail 1 error make[7]: stopped in /usr/src/lib/atf/libatf-c++/tests/detail *** [all_subdir_lib/atf/libatf-c++/tests/detail] Error code 2 make[6]: stopped in /usr/src/lib/atf/libatf-c++/tests 1 error make[6]: stopped in /usr/src/lib/atf/libatf-c++/tests *** [all] Error code 2 make[5]: stopped in /usr/src/lib/atf/libatf-c++ 1 error make[5]: stopped in /usr/src/lib/atf/libatf-c++ *** [all] Error code 2 make[4]: stopped in /usr/src/lib/atf 1 error make[4]: stopped in /usr/src/lib/atf *** [all_subdir_lib/atf] Error code 2 make[3]: stopped in /usr/src/lib 2 errors make[3]: stopped in /usr/src/lib *** [all_subdir_lib] Error code 2 make[2]: stopped in /usr/src 3 errors make[2]: stopped in /usr/src *** [everything] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson4231451396026693289.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Apr 19 08:23:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D7E5B14FFE; Tue, 19 Apr 2016 08:23:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB0131CA3; Tue, 19 Apr 2016 08:22:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asQw1-000Oiz-Qv; Tue, 19 Apr 2016 11:23:01 +0300 Date: Tue, 19 Apr 2016 11:23:01 +0300 From: Slawa Olhovchenkov To: David Chisnall Cc: Julian Elischer , lev@FreeBSD.org, Alfred Perlstein , Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org, Nathan Whitehorn Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419082301.GE4841@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:23:00 -0000 On Tue, Apr 19, 2016 at 08:54:48AM +0100, David Chisnall wrote: > 2) People wanting to install embedded systems. Anyone who has tried > to run FreeBSD on a system with a small amount of flash storage will > have encountered the pain of having to use some kind of ad-hoc > update. Being able to manage updates to these systems with the same > packaging tool as you manage big systems is a big improvement. Not true. For very small system pkg overhead too high and comparable with size of base. NanoBSD anyway don't updated and build by pkg, only by slice swap. > 3) People wanting to install service jails (sorry, containerised > applications). These want the smallest possible attack surface and > so want the smallest amount of the base system that they can have. > Here, small packages are an advantage. It will take a little while > for ports to learn enough about the granularity of the base system > for this to really be useful, but it would be great to be able to > install nginx, for example, in a jail and have only the handful of > libraries that it needs. Too hard to work. nginx+ngx_lua need additional libraries, ngx_lua don't show additional dependeses, ports infrastructure don't tests this dependeses.... > > The big advantage of going with small packages initially, however, > is that it will allow us to get some data on what the correct > groupings are. If we have large packages, then it’s very hard to > tell which subsets of the packages people want. That’s exactly the > situation that we’re in now: we know some people don’t want docs or > games, but that’s about all that we know. It’s easy to move to a > model where we have *fewer* packages in the future, but it’s harder > to split them. That also applies to dependencies. If I know that a > port depends on the shell, then it’s easy to update it from > depending on a sh package to depending on a core system utilities > package automatically, but it’s very hard to do an automatic update > in the other direction. This is too teoretical. In pratical pepole don't want to waste for select from huge list of strange packaes. Also, systems may live after install and managed by different person. This person don't be grateful for docs and manuals absense. Writing docs and HOWTOS will be harder too: for every line you must be write "install package foo", "install package bar"... From owner-freebsd-current@freebsd.org Tue Apr 19 08:39:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0ADEDB114FB for ; Tue, 19 Apr 2016 08:39:12 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C05711248; Tue, 19 Apr 2016 08:39:11 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asRBf-000P6W-OB; Tue, 19 Apr 2016 11:39:11 +0300 Date: Tue, 19 Apr 2016 11:39:11 +0300 From: Slawa Olhovchenkov To: Glen Barber Cc: Julian Elischer , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419083911.GG6614@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <5715DD2E.903@freebsd.org> <20160419073117.GG1554@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160419073117.GG1554@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:39:12 -0000 On Tue, Apr 19, 2016 at 07:31:17AM +0000, Glen Barber wrote: > On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote: > > We've managed to keep this disease out of BSD since I started to do it in > > 1990. First we laughed/fumed at Sun's Solaris when they unbundled the > > compiler. then we fumed at xorg when hey took a useful package and made 190 > > odd packages out of it. Please don't force this on us! > > > > What isn't clear about the *numerous* statements that no one is being > *forced* to use packaged base? Because nowhere present roadmap about co-existing packaged base and traditionsl install. Because nowhere present roadmap of packaged base future. Because package base is show-stoper for 11.0 relese -- this is read as "11.0 switch to package base". From owner-freebsd-current@freebsd.org Tue Apr 19 08:41:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3437BB11699 for ; Tue, 19 Apr 2016 08:41:32 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 24CD01678; Tue, 19 Apr 2016 08:41:32 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id CF8C817DF; Tue, 19 Apr 2016 08:41:31 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Tue, 19 Apr 2016 08:41:29 +0000 From: Glen Barber To: Slawa Olhovchenkov Cc: Julian Elischer , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419084129.GI1554@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <5715DD2E.903@freebsd.org> <20160419073117.GG1554@FreeBSD.org> <20160419083911.GG6614@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XtpQQdSJWUg3xMR5" Content-Disposition: inline In-Reply-To: <20160419083911.GG6614@zxy.spb.ru> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:41:32 -0000 --XtpQQdSJWUg3xMR5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2016 at 11:39:11AM +0300, Slawa Olhovchenkov wrote: > On Tue, Apr 19, 2016 at 07:31:17AM +0000, Glen Barber wrote: >=20 > > On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote: > > > We've managed to keep this disease out of BSD since I started to do i= t in > > > 1990. First we laughed/fumed at Sun's Solaris when they unbundled the > > > compiler. then we fumed at xorg when hey took a useful package and ma= de 190 > > > odd packages out of it. Please don't force this on us! > > >=20 > >=20 > > What isn't clear about the *numerous* statements that no one is being > > *forced* to use packaged base? >=20 > Because nowhere present roadmap about co-existing packaged base and > traditionsl install. > Because nowhere present roadmap of packaged base future. > Because package base is show-stoper for 11.0 relese -- this is read as > "11.0 switch to package base". >=20 And nowhere did it say "buildworld/buildkernel would no longer work." Glen --XtpQQdSJWUg3xMR5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFe80AAoJEAMUWKVHj+KTDroP/0+jh5JtMu6b3K5OOKI+XeO+ rrYt2wtOrv0mWp81wp1ohdkr0D3VbfjtscARQ2vYkecGazbGehL5g2tPFG7Kzn59 g/OOJr37jdl7AJlg9mDPPaNuSx1jVg1gDXQKaDx48UJkxwL6bxBCtfHbiXw8Vxx7 4hM2R/Z+dpnKiZR8rYgg58r6u2gz74kOcrheKtFpSmKl1cMudkMPP4562PUlQjhW WMBW+s/sg6emdTz6lj/coQrrBZ6VnkkQwFPpLHavZGGG6yiPLPs1MUu/HtTFlgZp 68+KHVzk+lbpSOlbOY80+v9fU3dWWZZLVVk0EyTgzbWiX+NLkHikC/c/il2u4tfz Je4GlfF9cfZyNDF9buzOK8GRQKB2Ff6FyzxBrVHAQLsjqc0IqMUD/zWY/1c4BkOD ZpoJcTl/3huqzkApkvhTy+j4Ffo+yYIaXHo+XBKbiSYYF/rFbc0IOxIh16AKyTsA j7xNxol8lukk42grhmmN5J+fGmQ9O9uZdEw+RwAk7etc/Bs+csg47EVPBrWE3Qqr r0UDgpncCmOBD50gROElp9N0Home5u3pcV1cUzFj5xcWaVVkNvoVmKf+Nv9/1RtX sbw9i7Ir/G7Bde9nCVWkm3tjQWJKhH8CbQ1i69vJVbYzTXwfBDCEfKyuAYUx9a5M WrN9PBgEdnqTqRR/p3vT =3vBn -----END PGP SIGNATURE----- --XtpQQdSJWUg3xMR5-- From owner-freebsd-current@freebsd.org Tue Apr 19 08:44:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0021B118F3 for ; Tue, 19 Apr 2016 08:44:23 +0000 (UTC) (envelope-from afiskon@devzen.ru) Received: from relay08.nicmail.ru (relay08.nicmail.ru [195.208.6.4]) (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 A7D1919E2 for ; Tue, 19 Apr 2016 08:44:23 +0000 (UTC) (envelope-from afiskon@devzen.ru) Received: from [109.70.25.225] (port=47293 helo=fujitsu) by f17.mail.nic.ru with esmtp (Exim 5.55) (envelope-from ) id 1asR7o-0006it-41; Tue, 19 Apr 2016 11:35:12 +0300 Received: from [93.174.131.138] (account afiskon@devzen.ru HELO fujitsu) by proxy03.mail.nic.ru (Exim 5.55) with id 1asR7o-0003Iy-56; Tue, 19 Apr 2016 11:35:12 +0300 Date: Tue, 19 Apr 2016 11:34:30 +0300 From: Aleksander Alekseev To: Warren Block Cc: Hans Petter Selasky , FreeBSD Current Subject: Re: qsort() documentation Message-ID: <20160419113430.69e41a0b@fujitsu> In-Reply-To: References: <5714C86A.8050204@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:44:24 -0000 > Why Wikipedia, specifically? There are a lot of places that describe > quicksort. How about just > > Note: This implementation of qsort() is designed to avoid the > worst-case complexity of N**2 that is often seen with standard > versions. I would say that this statement is just false. Worst-case complexity is still N**2. How about something like: """ This implementation of qsort() has worst case complexity of N**2. However measures were taken that make it very unlikely that for some random input N**2 swaps will be made. It's still possible to generate such an input on purpose though. See code below for more details. """ -- Best regards, Aleksander Alekseev http://eax.me/ From owner-freebsd-current@freebsd.org Tue Apr 19 08:57:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE528B1208E for ; Tue, 19 Apr 2016 08:57:43 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF5CB10FF; Tue, 19 Apr 2016 08:57:43 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asRTd-000PVv-Qs; Tue, 19 Apr 2016 11:57:45 +0300 Date: Tue, 19 Apr 2016 11:57:45 +0300 From: Slawa Olhovchenkov To: Glen Barber Cc: Julian Elischer , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419085745.GF4841@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <5715DD2E.903@freebsd.org> <20160419073117.GG1554@FreeBSD.org> <20160419083911.GG6614@zxy.spb.ru> <20160419084129.GI1554@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160419084129.GI1554@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:57:44 -0000 On Tue, Apr 19, 2016 at 08:41:29AM +0000, Glen Barber wrote: > On Tue, Apr 19, 2016 at 11:39:11AM +0300, Slawa Olhovchenkov wrote: > > On Tue, Apr 19, 2016 at 07:31:17AM +0000, Glen Barber wrote: > > > > > On Tue, Apr 19, 2016 at 03:24:30PM +0800, Julian Elischer wrote: > > > > We've managed to keep this disease out of BSD since I started to do it in > > > > 1990. First we laughed/fumed at Sun's Solaris when they unbundled the > > > > compiler. then we fumed at xorg when hey took a useful package and made 190 > > > > odd packages out of it. Please don't force this on us! > > > > > > > > > > What isn't clear about the *numerous* statements that no one is being > > > *forced* to use packaged base? > > > > Because nowhere present roadmap about co-existing packaged base and > > traditionsl install. > > Because nowhere present roadmap of packaged base future. > > Because package base is show-stoper for 11.0 relese -- this is read as > > "11.0 switch to package base". > > > > And nowhere did it say "buildworld/buildkernel would no longer work." buildworld/builkernel is requrement for `make packages`. I am expect of removing installworld/installkernel. Yes, I am don read about this. But in IT I am need to read between the lines. Also, installkernel broken in 10.x for multiple kernels and not planed to fix. Why I need to expect different to this? From owner-freebsd-current@freebsd.org Tue Apr 19 09:21:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F14AB12D92 for ; Tue, 19 Apr 2016 09:21:47 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 54ABC11EA; Tue, 19 Apr 2016 09:21:46 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id DBC02DC0FA; Tue, 19 Apr 2016 12:21:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 19 Apr 2016 12:21:53 +0300 From: dan_partelly To: Glen Barber Cc: Slawa Olhovchenkov , Julian Elischer , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <20160419084129.GI1554@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <5715DD2E.903@freebsd.org> <20160419073117.GG1554@FreeBSD.org> <20160419083911.GG6614@zxy.spb.ru> <20160419084129.GI1554@FreeBSD.org> Message-ID: <81fcc625db2d9eefce05828514ad4a4b@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 09:21:47 -0000 > > And nowhere did it say "buildworld/buildkernel would no longer work." > > Glen It may very well work, but you consider a listing of hundred of packages on a fresh system a sane default ? From owner-freebsd-current@freebsd.org Tue Apr 19 09:25:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8432B12EE8; Tue, 19 Apr 2016 09:25:59 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0D86E13D9; Tue, 19 Apr 2016 09:25:59 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 678F3DC0CD; Tue, 19 Apr 2016 12:17:52 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 19 Apr 2016 12:18:00 +0300 From: dan_partelly To: Julian Elischer Cc: Alfred Perlstein , , Glen Barber , Nathan Whitehorn , Sean Fagan , , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <5715E1E9.8060507@freebsd.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> Message-ID: <4787f50d3f160e606ad55737e93a324a@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 09:25:59 -0000 For what is worth, I agree with Julian Elischer. I do not want to see hundreds of packages over tenths of screen pages. Computers are supposed to make our life simpler. Human time is very expensive. CPU time, almost free. And this include that I really shouldn't have to think for usual work of any grep, sed , regexpes, pkg --leafs whatever. The default high level output of a tool like pkg should be as terse as possible. You guys seen the "Add remove programs" in Windows control panel ? Thats sane. Even now the default output of pkg borders insane, when you have many packages installed. 99% of my time I dont really care about lib-rtyum546.78.9. I care only less than 1% of my time when something goes wrong. The program | filter pipeline of Unix is very powerful. Whats more powerful is SANE DEFAULTS to make filters completely unnecessary. The open source Unix world has a lot to learn from Cupertino and Redmond. Keep things simple please. DO not pollute my screens with unnecessary information. When Ill want that info, Ill ask for it with a command line flag, then maybe filter it if necessary. On Tue, 19 Apr 2016 15:44:41 +0800, Julian Elischer wrote: > On 19/04/2016 5:29 AM, Alfred Perlstein wrote: >> Guys please stop arguing about the number of packages. The high >> granularity is VERY useful! >> > it's going to make us a laughing stock > "look FreeBSD just split into 1.43 million packages" (effectively the > same number.. it's bigger than 10) > > >> Managing large groups of small packages is much easier than just >> having large packages. > err, Alfred, what planet do you live on? when they get out of sync it > becomes a nightmare. > If you also had a packaging system that was smart enough to manage a > hierarchy of packages then "maybe".. > >> >> All this can be done by meta-packages which depend on larger package >> groups. > Currently Metapackage is a way to make 10 packages look like 11 > packages. The framework needs to understand to hide the 10 internal > packages if they are part of a metapackage. >> >> Later pkg can be augmented to "remove packages not explicitly >> installed" which would remove leaf packages. >> >> Example: you installed "base-debug" which pulls in let's say 50 >> small packages, later you want all of those removed, you can do >> something like: "pkg delete --leafs base-debug" which should delete >> "base-debug" and any dangling packages it pulled in not required by >> other pkgs. >> >> Huge thanks to the team that implemented this! > > I'm sure the work was large and will be useful in the future but we > are not ready to have the system installed like this. > no-one wants to see 750 packages show up when you do an enquiry on a > newly installed system. > I could live with: > > base-utils 11.1 > - ktrace uninstalled > - tcpdump uninstalled > + dd 11.1.1 (CVE-123412 fix) > > > > but not > {700 packages ) > dd 11.1.1 dd with CVE fix > {29 more packages} > [tcpdump line is not present but you don't notice that] > {10 more packages} > [ktrace line would be here but you don't notice that either] > {15 more packages} > > > In other words, I have no objection to all the utilities coming in the > form of little packages. > but I have a major objection if that fact is at all obvious to the end > user, > and certainly if we need to wade through 750 packages to see what's going > on. > >> >> thanks. >> -Alfred >> >> On 4/18/16 1:07 PM, Lev Serebryakov wrote: >>> On 18.04.2016 22:40, Glen Barber wrote: >>> >>>> This granularity allows easy removal of things that may not be wanted >>>> (such as *-debug*, *-profile*, etc.) on systems with little >>>> storage. On >>>> one of my testing systems, I removed the tests packages and all debug >>>> and profiling, and the number of base system packages is 383. >>> IMHO, granularity like "all base debug", "all base profile" is >>> enough >>> for this. Really, I hardly could imagine why I will need only 1 >>> debug or >>> profile package, say, for csh. On resource-constrained systems NanoBSD >>> is much better anyway (for example, my typical NanoBSD installation is >>> 37MB base system, 12MB /boot and 10 packages), and on developer system >>> where you need profiled libraries it is Ok to install all of them and >>> don't think about 100 packages for them. >>> >>> Idea of "Roles" from old FreeBSD installers looks much better. >>> Again, >>> here are some "contrib" software which have one-to-one replacements in >>> ports, like sendmail, ssh/sshd, ntpd, but split all other >>> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static >>> libraries. >>> Yes, lib32 on 64 bit system. >>> >>> It seems that it is ideological ("holy war") discussion more than >>> technical one... >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Apr 19 10:23:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D8C5B146B3; Tue, 19 Apr 2016 10:23:04 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 11E7618E2; Tue, 19 Apr 2016 10:23:04 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 30E8B13E7; Tue, 19 Apr 2016 10:23:04 +0000 (UTC) Date: Tue, 19 Apr 2016 10:23:03 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: delphij@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1472673684.43.1461061384139.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1731721887.39.1461053406054.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1731721887.39.1461053406054.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2901 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 10:23:04 -0000 FreeBSD_HEAD_i386 - Build #2901 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2901/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2901/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2901/console Change summaries: 298257 by delphij: Fix build breakage introduced by r298253. From owner-freebsd-current@freebsd.org Tue Apr 19 10:27:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8860BB1486D; Tue, 19 Apr 2016 10:27:56 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FB531B27; Tue, 19 Apr 2016 10:27:55 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id EE0BF6E0081; Tue, 19 Apr 2016 12:27:52 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u3JARquB077740; Tue, 19 Apr 2016 12:27:52 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u3JARpna077438; Tue, 19 Apr 2016 12:27:51 +0200 (CEST) (envelope-from lars) Date: Tue, 19 Apr 2016 12:27:51 +0200 From: Lars Engels To: dan_partelly Cc: Julian Elischer , Alfred Perlstein , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419102751.GM82927@e-new.0x20.net> Mail-Followup-To: Lars Engels , dan_partelly , Julian Elischer , Alfred Perlstein , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <4787f50d3f160e606ad55737e93a324a@rdsor.ro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mkHYMT4O8DyWoHkb" Content-Disposition: inline In-Reply-To: <4787f50d3f160e606ad55737e93a324a@rdsor.ro> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 10:27:56 -0000 --mkHYMT4O8DyWoHkb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2016 at 12:18:00PM +0300, dan_partelly wrote: >=20 > be as terse as possible. You guys seen the "Add remove programs" > in Windows control panel ? Thats sane. Even now the default output =20 > of pkg borders insane, when you have many packages installed. 99% of my > time > I dont really care about lib-rtyum546.78.9. I care only less than 1% of my > time when something=20 > goes wrong.=20 Don't use "pkg info" then. Use "pkg leaf": % pkg info | wc -l 249 % pkg leaf | wc -l 25 "leaf" is an alias for: pkg 'query -e "%a =3D=3D 0" "%n-%v"' And to everyone complaining about the number of packages: How many of you have actually used the packaged base? --mkHYMT4O8DyWoHkb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXFggnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tbAYH/i0yagmypWg+RUKQsTGWg+An hWyFArEGrnLZA71qacmu9hceJL+jMMDIuYTDG5VoMtVctU9xM8EhyuHQ8x7diqCo MS/mfkuPRG319g7/5qkAdmPQYA1DyhRdfpZA4tzWHd9hvu/AvtrJ2HSe6DQbO3g2 aP97b8rfIwT42D7dmBelPXMK+Jt8WhGN+S8EiqQJrsNsvooh0a8LudWTS4+Z/lpO FwE1JTqcOI/VIg1OrhwxDsffX5p8m1Yz5L/i7+ValO8dO/xlxAaR9qhgtqtczwTv hCCjeZYwW8H8bmgHoI6B6HcHmsPg12HvUzKsbcpaDAop58PPrp0CXbyYLFyxRxk= =EMnC -----END PGP SIGNATURE----- --mkHYMT4O8DyWoHkb-- From owner-freebsd-current@freebsd.org Tue Apr 19 11:06:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94662B13B62; Tue, 19 Apr 2016 11:06:36 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 3AC3A1150; Tue, 19 Apr 2016 11:06:36 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id l6so4098077wml.3; Tue, 19 Apr 2016 04:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=x1ymEBMHpeCsbf5v/d71FArGvW0OltRXNRg4APSZ/Mw=; b=Ir/Y5UbvpBfZBvmyHe3/NyqF4vBs9TQNg8hH/spVz42g5kDcabwQJX9eJHSpedw+Oj CqQFEinW/REnZqpblk+QCYc3oJfShFLQGRFynxcVJNLQ2hh42WRhHeMqWTrwLck1QTwe cBnMS8MddXzmfAyLEeQOXQL5UU5xUed1Gd2YAuLf2YO3fjdm6wtuFs8S2TWmJNML3toT kg9CryTDmHS+76PYaEYj1t+gMsEhuCIGhTQWXGSH62GIC48kyx7LiEKfAAuOulGJoG40 YMVMHeE2PC261xvKDPkGbaWx02BOweGVCbD+zMAzX1PJyIO6L5NofHtA1hdS3SyfS5T1 UvZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=x1ymEBMHpeCsbf5v/d71FArGvW0OltRXNRg4APSZ/Mw=; b=DBkH2Tg/+915t2RI9eeD+DX1OdOkp8mHvj5gt0mbTD3/4TZ5rudUBB8FPnH8Rm7P// EoeLdbcr3EXVkJYrQo2AvZYHEuDDWv0BDJOcboE43VfXXpQwvp+hTlzk6uMS86NCAmBF cUWIxnE9OzaDP503PyF44hvUFGIS2jxZ6oZb6GH9k4hBAJlnhZ+Sv/E2mjICCxOKDXRy ys31NKgXI2gjIPDhqFtJaEfjXXblVur3wj7/fFCMFM+fDXBYgMHDHenxuQmUwGtQR8fu +fG6482tAkZ/8ws89dFvyaciOhf3KDkO11QvorzcfEEgiTfxN4RaZxZfVna6rRTkQeiO Tlmg== X-Gm-Message-State: AOPr4FUGc8BZ8khaj1oFJhxl+upjQlJqE8jjBlo8nqv4pk+6vsVElU/tOYbVcDkklabZjA== X-Received: by 10.28.142.197 with SMTP id q188mr25052245wmd.52.1461063994829; Tue, 19 Apr 2016 04:06:34 -0700 (PDT) Received: from brick.home (abpy245.neoplus.adsl.tpnet.pl. [83.8.66.245]) by smtp.gmail.com with ESMTPSA id g141sm3780721wme.0.2016.04.19.04.06.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Apr 2016 04:06:34 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 19 Apr 2016 13:06:31 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Lev Serebryakov Cc: Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419110631.GD5543@brick.home> Mail-Followup-To: Lev Serebryakov , Glen Barber , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57152CE5.5050500@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 11:06:36 -0000 [replying to random post] I have a weird feeling that the main problem with having a lot of packages is that people have bad experiences from other systems. But IMHO the root cause of those problems was not that you had a lot of packages - the root cause was that it was used by distro guys to strip basic functionality off from the system, forcing users and administrators to manually install stuff like scp(1), compiler toolchain, dozens of packages containing includes, or even the separate package with basic man pages. Now, in this case none of this is going to happen. FreeBSD base is staying the way it was. If you want to customize the system, you can do it in a sane way by removing packages, but you don't have to. As for the 'multipage "pkg info" output problem' - on the laptop I'm typing this on there are 1351 packages installed. Packaging base will increase it by about half. And then I'll be hopefully able to remove lpr(1) binaries that conflict with CUPS. And sendmail. From owner-freebsd-current@freebsd.org Tue Apr 19 11:30:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 759F7B147A0; Tue, 19 Apr 2016 11:30:06 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id AF088114D; Tue, 19 Apr 2016 11:30:05 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id B3541D8802; Tue, 19 Apr 2016 14:30:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 19 Apr 2016 14:30:13 +0300 From: dan_partelly To: Lars Engels Cc: Julian Elischer , Alfred Perlstein , , Glen Barber , Nathan Whitehorn , Sean Fagan , , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <20160419102751.GM82927@e-new.0x20.net> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <4787f50d3f160e606ad55737e93a324a@rdsor.ro> <20160419102751.GM82927@e-new.0x20.net> Message-ID: <317dbdbb2c31c17ad70ef213abdcdbf6@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 11:30:06 -0000 I dont know if you missed the point of my message on purpose or not. I never pretended that you can't extract that information. I maintain that having sane defaults would empower me to almost never care about aliases, scripts pipes, filter , regular expressions and what not. It is great that all this power is at my fingertips, in case something goes awfully wrong , not so great when Im forced to use it. And I really don't see how this helps anyway, since number of leafs will increase anyway with package base. Let me reiterate, perhaps clearer this time: It is my opinion that sane defaults beat ANY script, obscure command line arguments, alias, pipe, filter, helper program. > > Don't use "pkg info" then. Use "pkg leaf": > > And to everyone complaining about the number of packages: How many of > you have actually used the packaged base? This question is irrelevant. 1.First of all, many people consider packaging base a great accomplishment, yet maybe not ready for prime-time, given the current way pkg handles this information. I personally love the idea, with the caveats above. 2. The issue is present with all meta-packages in general. The base packaging only exacerbate an existing issue with the sheer number of packages it presents. From owner-freebsd-current@freebsd.org Tue Apr 19 10:50:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9B6BB133C8; Tue, 19 Apr 2016 10:50:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82EB01779; Tue, 19 Apr 2016 10:50:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asTEL-0002Cz-9y; Tue, 19 Apr 2016 13:50:05 +0300 Date: Tue, 19 Apr 2016 13:50:05 +0300 From: Slawa Olhovchenkov To: Lars Engels , dan_partelly , Julian Elischer , Alfred Perlstein , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419105005.GG4841@zxy.spb.ru> References: <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <4787f50d3f160e606ad55737e93a324a@rdsor.ro> <20160419102751.GM82927@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160419102751.GM82927@e-new.0x20.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 19 Apr 2016 11:36:11 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 10:50:07 -0000 On Tue, Apr 19, 2016 at 12:27:51PM +0200, Lars Engels wrote: > On Tue, Apr 19, 2016 at 12:18:00PM +0300, dan_partelly wrote: > > > > be as terse as possible. You guys seen the "Add remove programs" > > in Windows control panel ? Thats sane. Even now the default output > > of pkg borders insane, when you have many packages installed. 99% of my > > time > > I dont really care about lib-rtyum546.78.9. I care only less than 1% of my > > time when something > > goes wrong. > > Don't use "pkg info" then. Use "pkg leaf": > > % pkg info | wc -l > 249 > % pkg leaf | wc -l > 25 > > "leaf" is an alias for: > pkg 'query -e "%a == 0" "%n-%v"' slw@pkg-test:~ % pkg leaf | wc -l 1 slw@pkg-test:~ % pkg leaf pkg-1.7.2 slw@pkg-test:~ % pkg info | wc -l 756 > And to everyone complaining about the number of packages: How many of > you have actually used the packaged base? Wrong question: I am already complain about Xorg spliting. Some servers managed by me have 53 packages, included 29 as p5-libwww. From owner-freebsd-current@freebsd.org Tue Apr 19 14:27:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3336B13AAA; Tue, 19 Apr 2016 14:27:53 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id BE3C71DB2; Tue, 19 Apr 2016 14:27:53 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:8899:e9c:e753:74e4]) by elvis.mu.org (Postfix) with ESMTPSA id 527C6346DFA0; Tue, 19 Apr 2016 07:27:53 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: Julian Elischer , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> Cc: Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Alfred Perlstein Organization: FreeBSD Message-ID: <57164068.8080800@freebsd.org> Date: Tue, 19 Apr 2016 07:27:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5715E1E9.8060507@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:27:54 -0000 Again, the point is that those objecting should put aside the time to implement what you (and I) are suggesting: > I could live with: > > base-utils 11.1 > - ktrace uninstalled > - tcpdump uninstalled > + dd 11.1.1 (CVE-123412 fix) > > > > but not > {700 packages ) > dd 11.1.1 dd with CVE fix > {29 more packages} > [tcpdump line is not present but you don't notice that] > {10 more packages} > [ktrace line would be here but you don't notice that either] > {15 more packages} What should not happen is that this incremental step forward be blocked by those unwilling to hash out the next steps. -Alfred On 4/19/16 12:44 AM, Julian Elischer wrote: > On 19/04/2016 5:29 AM, Alfred Perlstein wrote: >> Guys please stop arguing about the number of packages. The high >> granularity is VERY useful! >> > it's going to make us a laughing stock > "look FreeBSD just split into 1.43 million packages" (effectively the > same number.. it's bigger than 10) > > >> Managing large groups of small packages is much easier than just >> having large packages. > err, Alfred, what planet do you live on? when they get out of sync it > becomes a nightmare. > If you also had a packaging system that was smart enough to manage a > hierarchy of packages then "maybe".. > >> >> All this can be done by meta-packages which depend on larger package >> groups. > Currently Metapackage is a way to make 10 packages look like 11 > packages. The framework needs to understand to hide the 10 internal > packages if they are part of a metapackage. >> >> Later pkg can be augmented to "remove packages not explicitly >> installed" which would remove leaf packages. >> >> Example: you installed "base-debug" which pulls in let's say 50 small >> packages, later you want all of those removed, you can do something >> like: "pkg delete --leafs base-debug" which should delete >> "base-debug" and any dangling packages it pulled in not required by >> other pkgs. >> >> Huge thanks to the team that implemented this! > > I'm sure the work was large and will be useful in the future but we > are not ready to have the system installed like this. > no-one wants to see 750 packages show up when you do an enquiry on a > newly installed system. > I could live with: > > base-utils 11.1 > - ktrace uninstalled > - tcpdump uninstalled > + dd 11.1.1 (CVE-123412 fix) > > > > but not > {700 packages ) > dd 11.1.1 dd with CVE fix > {29 more packages} > [tcpdump line is not present but you don't notice that] > {10 more packages} > [ktrace line would be here but you don't notice that either] > {15 more packages} > > > In other words, I have no objection to all the utilities coming in the > form of little packages. > but I have a major objection if that fact is at all obvious to the end > user, > and certainly if we need to wade through 750 packages to see what's > going on. > >> >> thanks. >> -Alfred >> >> On 4/18/16 1:07 PM, Lev Serebryakov wrote: >>> On 18.04.2016 22:40, Glen Barber wrote: >>> >>>> This granularity allows easy removal of things that may not be wanted >>>> (such as *-debug*, *-profile*, etc.) on systems with little >>>> storage. On >>>> one of my testing systems, I removed the tests packages and all debug >>>> and profiling, and the number of base system packages is 383. >>> IMHO, granularity like "all base debug", "all base profile" is enough >>> for this. Really, I hardly could imagine why I will need only 1 >>> debug or >>> profile package, say, for csh. On resource-constrained systems NanoBSD >>> is much better anyway (for example, my typical NanoBSD installation is >>> 37MB base system, 12MB /boot and 10 packages), and on developer system >>> where you need profiled libraries it is Ok to install all of them and >>> don't think about 100 packages for them. >>> >>> Idea of "Roles" from old FreeBSD installers looks much better. Again, >>> here are some "contrib" software which have one-to-one replacements in >>> ports, like sendmail, ssh/sshd, ntpd, but split all other >>> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries. >>> Yes, lib32 on 64 bit system. >>> >>> It seems that it is ideological ("holy war") discussion more than >>> technical one... >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > From owner-freebsd-current@freebsd.org Tue Apr 19 14:33:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F592B13E80; Tue, 19 Apr 2016 14:33:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2804A1699; Tue, 19 Apr 2016 14:33:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asWi2-00089U-DU; Tue, 19 Apr 2016 17:32:58 +0300 Date: Tue, 19 Apr 2016 17:32:58 +0300 From: Slawa Olhovchenkov To: Alfred Perlstein Cc: Julian Elischer , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419143258.GH4841@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <57164068.8080800@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57164068.8080800@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:33:02 -0000 On Tue, Apr 19, 2016 at 07:27:52AM -0700, Alfred Perlstein wrote: > Again, the point is that those objecting should put aside the time to > implement what you (and I) are suggesting: > > > I could live with: > > > > base-utils 11.1 > > - ktrace uninstalled > > - tcpdump uninstalled > > + dd 11.1.1 (CVE-123412 fix) > > > > > > > > but not > > {700 packages ) > > dd 11.1.1 dd with CVE fix > > {29 more packages} > > [tcpdump line is not present but you don't notice that] > > {10 more packages} > > [ktrace line would be here but you don't notice that either] > > {15 more packages} > > What should not happen is that this incremental step forward be blocked > by those unwilling to hash out the next steps. Teoretical. In practical this is happen with me. From owner-freebsd-current@freebsd.org Tue Apr 19 14:33:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC583B13F7B; Tue, 19 Apr 2016 14:33:31 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 87FB5184D; Tue, 19 Apr 2016 14:33:31 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:8899:e9c:e753:74e4]) by elvis.mu.org (Postfix) with ESMTPSA id 408C0346DF90; Tue, 19 Apr 2016 07:33:31 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: David Chisnall , Julian Elischer References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> Cc: lev@FreeBSD.org, Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Alfred Perlstein Organization: FreeBSD Message-ID: <571641BA.8010205@freebsd.org> Date: Tue, 19 Apr 2016 07:33:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:33:31 -0000 It is very important to understand that a packaged base is extremely useful for those building any sort of distro or appliance distro. So although the concept of "user serviceable" is important, it's not just that. Such a change makes it easy for a distro or appliance making to cherry pick updates to the system without having to pull the entire system forward. One of the huge pains about using FreeBSD at my last work was that the base system as a whole was a bit challenging to pry apart so that an incremental update could happen. Let's say I needed a patch to openssl, well that was HARD even for me. My choices were to update the whole system (which broke things), pull in patches and apply them (hard and scary), figure out a way to pull it from ports instead... super hard as "base" built before ports in "nanobsd". Quite frankly I didn't have the time for it. As someone who laid the foundation for an FreeBSD appliance, I wholeheartedly welcome this, it will be HUGE for appliance builders. I am also confident that we will very easily sort out how to make "micropackages" or some such mechanism within at most 3 months after the code lands. The reason why is because I already see some excellent proposals for such mechanisms in this thread. -Alfred On 4/19/16 12:54 AM, David Chisnall wrote: > On 19 Apr 2016, at 08:44, Julian Elischer wrote: >>> All this can be done by meta-packages which depend on larger package groups. >> Currently Metapackage is a way to make 10 packages look like 11 packages. The framework needs to understand to hide the 10 internal packages if they are part of a metapackage. > I agree, and patches to do this are very welcome. Currently, pkg is short of contributors. > > I see basically three use cases for a packaged base: > > 1) People wanting a FreeBSD install to use as a server or workstation. These people will install the FreeBSD 11 metapackage and not care that it is a few hundred MBs. It would be nice if the pkg tool could present this as a single package in list views, but that’s a UI issue with pkg, not an issue with the number of packages in the base system. > > 2) People wanting to install embedded systems. Anyone who has tried to run FreeBSD on a system with a small amount of flash storage will have encountered the pain of having to use some kind of ad-hoc update. Being able to manage updates to these systems with the same packaging tool as you manage big systems is a big improvement. > > 3) People wanting to install service jails (sorry, containerised applications). These want the smallest possible attack surface and so want the smallest amount of the base system that they can have. Here, small packages are an advantage. It will take a little while for ports to learn enough about the granularity of the base system for this to really be useful, but it would be great to be able to install nginx, for example, in a jail and have only the handful of libraries that it needs. > > The big advantage of going with small packages initially, however, is that it will allow us to get some data on what the correct groupings are. If we have large packages, then it’s very hard to tell which subsets of the packages people want. That’s exactly the situation that we’re in now: we know some people don’t want docs or games, but that’s about all that we know. It’s easy to move to a model where we have *fewer* packages in the future, but it’s harder to split them. That also applies to dependencies. If I know that a port depends on the shell, then it’s easy to update it from depending on a sh package to depending on a core system utilities package automatically, but it’s very hard to do an automatic update in the other direction. > > David > From owner-freebsd-current@freebsd.org Tue Apr 19 14:39:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AA2DB1429E; Tue, 19 Apr 2016 14:39:27 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5276D1CE1; Tue, 19 Apr 2016 14:39:26 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 0EE71232E5; Tue, 19 Apr 2016 17:39:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 19 Apr 2016 17:39:37 +0300 From: dan_partelly To: Alfred Perlstein Cc: Julian Elischer , , Glen Barber , Nathan Whitehorn , Sean Fagan , , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <57164068.8080800@freebsd.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <57164068.8080800@freebsd.org> Message-ID: <78fb431d2d9b568fd488fae51a1b5f23@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:39:27 -0000 > > What should not happen is that this incremental step forward be blocked > by those unwilling to hash out the next steps. > > -Alfred > > While incremental steps forward are great, how do you avoid situations like VNET, where a "good enough" enough implementation, usable in some scenarios lingered for years in kernel, but to this day it suffers from leaks and bugs. Once you go down the path of enabling it in this state, chances are that it will stay that way for more than half a decade. From owner-freebsd-current@freebsd.org Tue Apr 19 14:41:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2BCCB14592; Tue, 19 Apr 2016 14:41:46 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A37791F95; Tue, 19 Apr 2016 14:41:46 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:8899:e9c:e753:74e4]) by elvis.mu.org (Postfix) with ESMTPSA id BAC58346DE30; Tue, 19 Apr 2016 07:41:45 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: dan_partelly References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <57164068.8080800@freebsd.org> <78fb431d2d9b568fd488fae51a1b5f23@rdsor.ro> Cc: Julian Elischer , lev@FreeBSD.org, Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Alfred Perlstein Organization: FreeBSD Message-ID: <571643A8.9020702@freebsd.org> Date: Tue, 19 Apr 2016 07:41:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <78fb431d2d9b568fd488fae51a1b5f23@rdsor.ro> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:41:47 -0000 On 4/19/16 7:39 AM, dan_partelly wrote: >> What should not happen is that this incremental step forward be blocked >> by those unwilling to hash out the next steps. >> >> -Alfred >> >> > While incremental steps forward are great, how do you avoid situations > like VNET, where a "good enough" enough implementation, usable in some > scenarios lingered for years in kernel, but to this day it suffers from > leaks and bugs. Once you go down the path of enabling it in this state, > chances are that it will stay that way for more than half a decade. > > > > > We happened to use VNET at our last company with great success. Had it not existed we would have been much further away from our goals. Maybe you picked a bad example? :) Look, take a look at history and the Linux kernel threads story and its impact on FreeBSD. If you'd like I can talk about it. -Alfred From owner-freebsd-current@freebsd.org Tue Apr 19 14:45:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06F77B147E4 for ; Tue, 19 Apr 2016 14:45:25 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC1681499 for ; Tue, 19 Apr 2016 14:45:24 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u3JEjNOg074554; Tue, 19 Apr 2016 10:45:23 -0400 (EDT) (envelope-from lidl@pix.net) To: FreeBSD-Current From: Kurt Lidl Subject: issue with /etc/rc.d/mountd script Message-ID: <57164483.3040408@pix.net> Date: Tue, 19 Apr 2016 10:45:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:45:25 -0000 Greetings all. I saw something the other day on a machine running 10/stable (but the same code exists in -current), when it was rebooting. The machine acts as a NFS fileserver (to support diskless booting of a few test machines). It only has ZFS filesystems, and only has filesystems that are exported via ZFS properties. So, it has /etc/zfs/exports, but no /etc/exports. When mountd is started up, it emits a error, because the required_files is set to /etc/exports. I think the correct thing is to either remove the required_files setting, or build it from /etc/exports and/or /etc/zfs/exports and only fail if neither of those files exists. (Yes, I could just create an empty /etc/exports file, but that's kinda lame.) -Kurt From owner-freebsd-current@freebsd.org Tue Apr 19 14:46:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBB42B14891 for ; Tue, 19 Apr 2016 14:46:59 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1A50E1704; Tue, 19 Apr 2016 14:46:59 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 3163C232E5; Tue, 19 Apr 2016 17:46:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 19 Apr 2016 17:47:10 +0300 From: dan_partelly To: Alfred Perlstein Cc: Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <571643A8.9020702@freebsd.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <57164068.8080800@freebsd.org> <78fb431d2d9b568fd488fae51a1b5f23@rdsor.ro> <571643A8.9020702@freebsd.org> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:47:00 -0000 > > Look, take a look at history and the Linux kernel threads story and its > impact on FreeBSD. If you'd like I can talk about it. > Please, yes, I would love to hear about it. > -Alfred > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Apr 19 15:18:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD48DB13880 for ; Tue, 19 Apr 2016 15:18:49 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id AE2C112A3 for ; Tue, 19 Apr 2016 15:18:49 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:8899:e9c:e753:74e4]) by elvis.mu.org (Postfix) with ESMTPSA id 9328E346DF92; Tue, 19 Apr 2016 08:18:49 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: dan_partelly References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <57164068.8080800@freebsd.org> <78fb431d2d9b568fd488fae51a1b5f23@rdsor.ro> <571643A8.9020702@freebsd.org> Cc: freebsd-current@freebsd.org From: Alfred Perlstein Organization: FreeBSD Message-ID: <57164C58.8000802@freebsd.org> Date: Tue, 19 Apr 2016 08:18:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:18:49 -0000 On 4/19/16 7:47 AM, dan_partelly wrote: > >> Look, take a look at history and the Linux kernel threads story and its >> impact on FreeBSD. If you'd like I can talk about it. >> > Please, yes, I would love to hear about it. Sure, so back in late 90s, ~1999 sometime after Solaris released kernel threads Linux did as well. It was pretty laughable, it was basically a hacked up version of fork that shared address space, files and a few other things and was horribly unstable and you couldn't use most of libc with it as there were many single-threaded deps in it. It was so "laughably bad" that if you logged into a Linux system with threads and ran "top", it would look very strange as each thread had its own pid. So if you were running something like mysql it would look like you were forkbombed. Now the point of all of this however was to get threads, and also to get threads that did well with disk IO. FreeBSD at the time had threads, but they were "green threads" or "userland threads" which means they were super good for network IO, but nearly useless for disk IO. This made Linux a much better platform for mysql, as mysql performed an order of magnitude better on Linux. In fact not only was FreeBSD slower, but in my experience it was buggier because the green threads implementation, while very cool, was complex and had its own share of bugs. Some years passed and many people migrated to Linux to get the high performance mysql that was available on the platform. Now during those years, as more and more people migrated away, FreeBSD had many, many, many, oh gosh, so many discussions on what to do about threads. So many opinions were had by so many people during which more people moved to Linux as a web platform... Not only were there opinions, but also implementations suggested, but those implementations were shot down in the search for the "one true threading system". Of course there were some loud folks that even insisted that threads were bad (and probably a phase) and we shouldn't even support them). Luckily during that time (~2002) someone made this crazy "Linuxthreads" port which made """Linuxthreads""" available on FreeBSD, it had many of the same problems, but at least mysql was fast. Spoiler: The funny part about calling it "Linuxthreads" was that "Linuxthreads" wound up being the defacto way to do threads across *UNIX* because it was just simple and worked, should have just called it "realthreads" in my opinion. Luckily with the Linuxthreads port the die hards in the FreeBSD community who needed to run mysql for performance (or other software requiring real threads) could stay using FreeBSD while the community sorted out what exactly was to be done. Places like Yahoo moved off of FreeBSD because they "just wanted threads" and if you tell someone to get "good performance with threads, then use Linuxthreads" (and of course make a grumpy face because "it's Linux") then they reason, "geez, why I am not just using Linux anyhow?" which they then migrate to. So some years later (~2005) we went with a far more complex solution than needed called libkse. Libkse offered N:M threads, which didn't work very well for years due to complexity (hats off to those that *tried* to get it working in FreeBSD's political climate) to which finally Sun abandoned its N:M threads because they themselves could never get it right, and finally FreeBSD switched to 1:1 threads following Solaris. That was probably in 2007 timeline. Now rewind to ~2001, about 2 years after the introduction of the sloppy, weird and strange kernel threads in Linux, and they had a pretty solid implementation. It wouldn't be until nearly 2009 when FreeBSD had a truly solid threads library and even now it suffers due to added complexity because we did things "smarter" than Linux. Moral of the story? My takeaways from this story (and there are many similar ones in our recent history) are: 1) Graciously and rapidly accept steps forward and then contribute to them. Anything else leaves you stagnant and worse for wear. 2) Simple over complex. 3) If something someone else did is working for someone, then copy it and move on, don't waste a huge amount of your customer's time trying to make something better until you are sure that just copying it will not suffice. -Alfred From owner-freebsd-current@freebsd.org Tue Apr 19 15:42:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01FFCB1438A; Tue, 19 Apr 2016 15:42:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id B99C01AD8; Tue, 19 Apr 2016 15:42:30 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 47B4E952; Tue, 19 Apr 2016 18:42:28 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> To: Glen Barber , Sean Fagan Cc: freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <571651DE.1070807@FreeBSD.org> Date: Tue, 19 Apr 2016 18:42:22 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160418191425.GW1554@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ljeGP4pLEkUplE7HT7CMpXWChhljabSEQ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:42:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ljeGP4pLEkUplE7HT7CMpXWChhljabSEQ Content-Type: multipart/mixed; boundary="snq2bEvOeA5uC7M6m1JPhPP9cHOHA7FWf" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Glen Barber , Sean Fagan Cc: freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Message-ID: <571651DE.1070807@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> In-Reply-To: <20160418191425.GW1554@FreeBSD.org> --snq2bEvOeA5uC7M6m1JPhPP9cHOHA7FWf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18.04.2016 22:14, Glen Barber wrote: >>> I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 >>> packages?! WHY?! What are reasons and goals to split base in such >>> enormous number of packages? >> >> Just a guess, having done the same thing myself: it means that update= s can be >> more targeted. >> > This is exactly the reason, which has been answered numerous times. Does somebody noticed, that it looks broken now: https://lists.freebsd.org/pipermail/freebsd-current/2016-April/060687.htm= l https://lists.freebsd.org/pipermail/freebsd-current/2016-April/060690.htm= l And it is exactly concern: it hard to notice such breakage, as there is hundreds of packages. --=20 // Lev Serebryakov --snq2bEvOeA5uC7M6m1JPhPP9cHOHA7FWf-- --ljeGP4pLEkUplE7HT7CMpXWChhljabSEQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFlHjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP+3UP/3KxP8m4aAZWdg37Jg9MVfdB FO/tvICziZZhLigN7HLvbRKJgSibJEQrmO/85AjRtYjXbIpq7Be6fqhPaPcManjS fan5RVgBSk2te6K42gyy7R4HvK9pTvPJ4UAR2nRcFBXt6xKmrujQ3WMp01YspdKW AmfrJr+nbPiQ2lHcM1LtBJkLq/xmV763Gu6VzCOIvvlpFfGlS3mp5L94mLU0Xlzz pzh8n53S7MsWPRCgUGekgXbYsauowqdFRqqpWNFoW3kbKVSwHgs02/C6PFfhMhS5 2/Ownx8tseZcTtyZ4eJb8BM/pFBdhXJ08HMFDY/Pt5m7s7g+UMHIHycoAF5Y3QIp Z5o24cgFaQgcfAA1AAwCfLXwfHnb+wboek966ONknuvh78nJLA41B7RYMhApqFFS q5De3mwAG7AKxnU8U/quTsWyzIEPPyFFL6tNJ33w2/NjgS4TkxxsiBt90DLawzNV YVvaSwrN6dR0OJNR3m2wCFrLM1WIHEebCXUxMLfpIwZVxiYs5vagYR5t8UaYc2zX A6aOA1DbHtiJtPS9cRdHNgbm6Yh5yr/eLdQaHz4bPpt6CavZMpt9/7rR03n26lMM TvpzTn7mdnHl01SJ41isjIAKLNeDVx7FzDBi5DYUnVL17vvxxGqeHZMi1jw5IjGt buMR2vJX2esRN11+0TFr =zFmb -----END PGP SIGNATURE----- --ljeGP4pLEkUplE7HT7CMpXWChhljabSEQ-- From owner-freebsd-current@freebsd.org Tue Apr 19 15:42:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C31A4B143DA for ; Tue, 19 Apr 2016 15:42:50 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F4AC1C1F; Tue, 19 Apr 2016 15:42:50 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mail-io0-x236.google.com with SMTP id u185so22738955iod.3; Tue, 19 Apr 2016 08:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+DYwLR23g26P37YfvBYNKRU1TqAXVF0yRtfzte8MOD4=; b=FeagdeWrNRDcKstrQ79ZtNlWgGE9bt6Gs3+yIoilPeY8/gxk2srbCCo4niBBnxEK0M qspFVw9netWneKW0rLaHLsPlA6Y8V6iSFUo2cwHasCMWSPEkVSqkbA5aD8gO3kQf1Ycu jxOmKShOPMfRCsGMcnl5GKC0ihDtSyA6JOzEdkNlFcUh3xwxcehseFdGE3osuFH9DU5I /szwCjfck4Cg5gCblgN6SmkvSMGQPaHIcQCb6Uy7y8z3NQfEEsLGOehzeLD0QfXNZz6Z Rc/tN0MKKssUposbg++Pbw04JqQQNvIJQLQN3UR+hYxt/qpA5OQ224l+hL/zHIR0FaKi H3dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+DYwLR23g26P37YfvBYNKRU1TqAXVF0yRtfzte8MOD4=; b=fc5rIFoWEGTePDItlLRxq2/3L1sQ2MrQCq+TZKfhC3Df9BuUHAVBvv7T/C69Gd8BYL Eh9I9x0a1MwRbSa9T6oDUo0sh2TQA2qWFTawig0G3uo8h/rLy1PrL/OgojOwWG8aYwtS A1uTysBQUny6IrAUaNpakx9agdLApPkUKQrz0c6w5gutCtL48+EryoktSPffCmTmJuNA mHODXUHsrF0IwTJvMgrXlWGRQpG6kpUUu+mKYu+FL+/Y2tq+J7PZDUk8CobAI7Pmv2lz RD3DfWhoJiBCVX0czyozlvhYoiydwMh6IFa/VuhctBJ6XrrEpoQrk1WxRCJ0GWFNDSBg poYA== X-Gm-Message-State: AOPr4FVzVfANSfkiPs4Xhug1RzbrMgPGtMYAVIydOa63DJFvgeYSJ36fXkJBx/T+joWSmbKMgteoEd5lqxX6LA== X-Received: by 10.107.136.69 with SMTP id k66mr5170829iod.0.1461080569949; Tue, 19 Apr 2016 08:42:49 -0700 (PDT) MIME-Version: 1.0 References: <1611132.EbTME86UTe@ralph.baldwin.cx> In-Reply-To: <1611132.EbTME86UTe@ralph.baldwin.cx> From: Howard Su Date: Tue, 19 Apr 2016 15:42:40 +0000 Message-ID: Subject: Re: Mis-use of BUS_PASS_ORDER_MIDDLE To: John Baldwin , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:42:50 -0000 On Tue, Apr 19, 2016 at 2:53 AM John Baldwin wrote: > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > I noticed several places there are code like this, especially in some a= rm > > low level drivers. > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > =E2=80=8BI feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There ar= e another > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. > > No, this is actually correct. The _ORDERED variants actually accept a > SI_ORDER_* value to determine how drivers contained in a single .ko file > are registered (in particular if you have several drivers in a .ko file > you typically want the "top-most" driver to attach last so that all the > other drivers are ready once the actual device is attached). > Why not use _ORDERED here to achieve same thing? _ORDERED(...., SI_ORDER_LAST, BUS_PASS_BUS)? I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MODULE, TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. If we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. I am plan to do is: in autoconf phase, first load timer, int and some bus, etc low level drivers first, then set cold=3D0, then load other driver to work around the problem that driver needs special handling on cold which is not necessary. of course, this may depends on your change of ap_startup. thoughts? > -- > John Baldwin > --=20 -Howard From owner-freebsd-current@freebsd.org Tue Apr 19 15:43:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6AFAB144B2 for ; Tue, 19 Apr 2016 15:43:31 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8687E1DFE; Tue, 19 Apr 2016 15:43:31 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asXoK-000A0f-1O; Tue, 19 Apr 2016 18:43:32 +0300 Date: Tue, 19 Apr 2016 18:43:31 +0300 From: Slawa Olhovchenkov To: Alfred Perlstein Cc: dan_partelly , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419154331.GH6614@zxy.spb.ru> References: <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <57164068.8080800@freebsd.org> <78fb431d2d9b568fd488fae51a1b5f23@rdsor.ro> <571643A8.9020702@freebsd.org> <57164C58.8000802@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57164C58.8000802@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:43:31 -0000 On Tue, Apr 19, 2016 at 08:18:48AM -0700, Alfred Perlstein wrote: > 1) Graciously and rapidly accept steps forward and then contribute to > them. Anything else leaves you stagnant and worse for wear. > 2) Simple over complex. > 3) If something someone else did is working for someone, then copy it > and move on, don't waste a huge amount of your customer's time trying to > make something better until you are sure that just copying it will not > suffice. What is simple -- split base to 10 packages or split base to 800 packages? I think first. What need for succesufult moved forward after this? I think ability of spliting and mergering packages at upgrade. (clang-base => clang-base-c + clang-base-c++, for example. or clang-base-c + clang-base-c++ => clang-base). What need for security updates? I think ability to have file with common name and different content with multiple installed packages: base-11.0 contains /usr/sbin/ntpd base-11.0-CVE-1234 direct depends to base-11.0 and contains overlaped /usr/sbin/ntpd As result: few packages, compact security updates, ability to repackage base. Optionaly, ability to have packages with "dummy" content, for example no-base-ntp-11.0 have record (w/o actual content) about /usr/sbin/ntpd with size -791552 (negative size) and checksum of actual file, for removing some components. For this feature give ability to have "skins" packages, installed over main package. From owner-freebsd-current@freebsd.org Tue Apr 19 15:46:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C602B1469E; Tue, 19 Apr 2016 15:46:12 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9263F1116; Tue, 19 Apr 2016 15:46:11 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id F30EC95A; Tue, 19 Apr 2016 18:46:09 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <571641BA.8010205@freebsd.org> To: Alfred Perlstein , David Chisnall , Julian Elischer Cc: Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <571652C2.8040106@FreeBSD.org> Date: Tue, 19 Apr 2016 18:46:10 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571641BA.8010205@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="74Gjv9Xtq6aWjqCwB6g6s7gWvCOLpfa28" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:46:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --74Gjv9Xtq6aWjqCwB6g6s7gWvCOLpfa28 Content-Type: multipart/mixed; boundary="k8xGD2h7COWPBDCBvnFdCbEffmxDKD7Fp" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Alfred Perlstein , David Chisnall , Julian Elischer Cc: Glen Barber , Nathan Whitehorn , Sean Fagan , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Message-ID: <571652C2.8040106@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <571641BA.8010205@freebsd.org> In-Reply-To: <571641BA.8010205@freebsd.org> --k8xGD2h7COWPBDCBvnFdCbEffmxDKD7Fp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19.04.2016 17:33, Alfred Perlstein wrote: > I am also confident that we will very easily sort out how to make > "micropackages" or some such mechanism within at most 3 months after th= e > code lands. The reason why is because I already see some excellent > proposals for such mechanisms in this thread. I could see only two proposals: meta-packages (which is not a solution, but kludge, IMHO) from numerous people and proposal from Slawa about "overlapped" and "file-removal" packages, which is not discussed at all (https://lists.freebsd.org/pipermail/freebsd-current/2016-April/060688.ht= ml). I really like Slawa approach, but it requires much more sophisticated pkg, including additional metadata, etc. --=20 // Lev Serebryakov --k8xGD2h7COWPBDCBvnFdCbEffmxDKD7Fp-- --74Gjv9Xtq6aWjqCwB6g6s7gWvCOLpfa28 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFlLCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoTUQAMCCWqY/onXzIYefamja7OUY YGXrj/v2BjZLOlVTMWl606ntFqNpA8tRxQ1skNewo/V/Y/7pD2m1JCvjhM9OtABj M2Zm0/bTkykixp64z1N9CN8Y2eHPlJx4nE3dmG5R9OaqQKpBuVpxPTxPVkilWXxH nDlLYoAaaDgygBV+qFRi0DjvB3pOGe1eb/utAUo+CaPVXAI8es/wVsiKQEDZ5g/g WuPRI81Y608Aiv1JaETzLHFmfMmtN6H6PDl0IDTZ7tmvafTd+p/inxKKzqaeR+Ik kVqI+u+1agjHxpMTuj3uP/AVjIAkWE1e/fWXstRFRfmvclcEA0BM3PDNSvSlIsUS 4Nv4yK4RZYANqzvRI65nR9v7/5qbPaNU0K9lc4IWAIOKcarC5bNJUF+MfzWIHaqI B1HFcpOgw4D4CCUjrOkTYTeJNJ4cBgC5rP9oKvnNB+OK05qbQNs1valtofdAp78g LCyDerJOkYmH0C99TdUp802kNe/rMATKb4grgKbDdomLB6SellwMuZNxwd9LHkPf u7g96yENpZd1FVei8Q+xOnSrAe/d/mauc3GzigoV95Leq9taDyXfC4Yu7Mn6CJqv vrQeD5f/cd1sC6U30f8xf+NtIt/xyS2a8/CgkOOI72XehLzNxE9CKKYYa/xyxFa7 7bD8GY8T9AwMPw2f53y8 =MuMe -----END PGP SIGNATURE----- --74Gjv9Xtq6aWjqCwB6g6s7gWvCOLpfa28-- From owner-freebsd-current@freebsd.org Tue Apr 19 16:28:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C36BB14ABA; Tue, 19 Apr 2016 16:28:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1130516A4; Tue, 19 Apr 2016 16:28:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3JGS1Qu001797 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Apr 2016 09:28:02 -0700 Subject: Re: [CFT] packaging the base system with pkg(8) To: Alfred Perlstein , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> From: Nathan Whitehorn Message-ID: <57165C91.7070005@freebsd.org> Date: Tue, 19 Apr 2016 09:28:01 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5715A338.5060009@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYH7Z0rIag6b4n8X91ajYG+faJ64ENo/i+2uyzHn8zRVZ3TH8eVsa+JdXnpPMHT7fXL2Ididv+DyY8SCCJNDX98gkwgNYmiErM= X-Sonic-ID: C;vjWRr0sG5hGNXLeqjlfmnQ== M;8uTQr0sG5hGNXLeqjlfmnQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 16:28:05 -0000 Well, this discussion has gone pretty far off of the rails. I am of course happy to make a patch that cuts this down to 10 packages, but that's not something that should be committed without agreement -- which we obviously don't have. It would have been good to have had meaningful discussion of this before. There are basically three workable options: 1. Have fewer packages. This is easy to implement and preserves the integrity of the base system (as well as unified versioning so that a system at some particular patch level will have the same global state). I have not seen any meaningful downside suggested to this so far except for marginally higher load on update servers. 2. Have 755 packages. This makes it harder to version the system and makes the user interface significantly worse (my opinion, but shared by others). This is the easiest to implement since it is already implemented. 3. Have ~10 meta packages that just depend on sets of the 755 packages and hide the internal details. This gives the user experience of (1) with the implementation of (2), and is marginally more complex than either. Other things (the overlapping packages idea, for instance) are way too complex and will just lead to breakage. Can anyone provide an argument against (1) or, alternatively, for (2)? (2) seems to add a lot of complexity for no clear gain and I remain pretty confused about why it was chosen. -Nathan On 04/18/16 20:17, Alfred Perlstein wrote: > Maybe what the "too many packages" folks need to do is write some code > to hide that it's so many packages. > > :) > > I think the rule of two feet should be applied here. > > What we have is people that have worked quite hard to bring us > something that we can easily work with, and on the other hand some > folks that want something they consider even better. Personally I > can't see how having the system less granular is better, since having > it MORE granular is actually harder work. > > Can someone on the "too many packages" campaign here explain to me how > having too fine a granularity stops you from making macro packages > containing packages? > > Because honestly I can't see how having granularity hurts at all when > if someone wanted to make it less granular all they would have to do > is make some meta-packages. > > -Alfred > > On 4/18/16 7:23 PM, Lyndon Nerenberg wrote: >> On 2016-04-18 7:01 PM, Roger Marquis wrote: >>> Can you explain what would be accomplished by testing all or even a >>> fraction of the possible permutations of base package combinations? We >>> don't do that for ports. >> >> The ports tree isn't a mandatory part of the system. And by >> definition it could not be tested that way, since it offers so many >> alternative implementations of specific functionality. >> >>> Other operating systems don't do that for >>> their base packages. >> >> I'm pretty sure Solaris had some fairly hard-core regression tests to >> ensure basic system functionality wouldn't be compromised by >> 'oddball' selections of packages offered up at install time. >> >> > Honestly, some of us are wondering what exactly is >> > behind some of these concerns regarding base packages. >> >> The concern is from all of us UNIX dinosaurs who predate the >> fine-grained packaging environment, which just worked, and who now >> rip our (little remaining) hair out due to unsolvable package >> dependency loops in the Linux machines we are forced to administer in >> order to pay rent. For me, as a sysadmin, I derive a negative >> benefit from this optimization. >> >> I guess what I'm really asking is: where is the peer reviewed >> research that shows this actually improves things for the not-1% of >> FreeBSD users? >> >> --lyndon >> >> P.S. Don't turn this into a pissing match. I really want to know >> how this is of net benefit to everyone. But I don't want hyperbole. >> I have looked at a lot of, e.g., USENIX and ACM, bibliographies and >> papers for justification for this, and I can't find it. It would >> really help (me, at least) if someone could take a moment to point me >> at demonstrable evidence of the benefits of this model. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Apr 19 16:36:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D04DDB14F90; Tue, 19 Apr 2016 16:36:39 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B84561E0D; Tue, 19 Apr 2016 16:36:39 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id F1003346DF90; Tue, 19 Apr 2016 09:36:38 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: Nathan Whitehorn , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> From: Alfred Perlstein Organization: FreeBSD Message-ID: <57165E96.4040302@freebsd.org> Date: Tue, 19 Apr 2016 09:36:38 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57165C91.7070005@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 16:36:39 -0000 I don't think we need 100% consensus to proceed on anything and if I've learned anything from 20 years in this community is that forcing that issue does the community a huge disservice as well as turn off the code submitters. See my thread on the missed opportunities in threads, or if you want I can paint the picture of what caused SMP to lag half a decade behind Linux as well. I would say that if someone submitted a patch for /dev/givemeroot, sure that would be righteously shot down but to force the whole, entire, "right" solution the first time around is remarkably blocking and unfair to the community and submitters as well. Why is this even happening in email? If folks want "the right solution" then why aren't they submitting patches or pull requests to the pkg repo (or where ever this is stored?). This seems counter-intuitive, but really actually should be how it works. Specifically: if you like where an idea is going, then don't block the code, submit improvements on top of it. Stone soup it if you will. -Alfred On 4/19/16 9:28 AM, Nathan Whitehorn wrote: > Well, this discussion has gone pretty far off of the rails. I am of > course happy to make a patch that cuts this down to 10 packages, but > that's not something that should be committed without agreement -- > which we obviously don't have. It would have been good to have had > meaningful discussion of this before. > > There are basically three workable options: > 1. Have fewer packages. This is easy to implement and preserves the > integrity of the base system (as well as unified versioning so that a > system at some particular patch level will have the same global > state). I have not seen any meaningful downside suggested to this so > far except for marginally higher load on update servers. > 2. Have 755 packages. This makes it harder to version the system and > makes the user interface significantly worse (my opinion, but shared > by others). This is the easiest to implement since it is already > implemented. > 3. Have ~10 meta packages that just depend on sets of the 755 packages > and hide the internal details. This gives the user experience of (1) > with the implementation of (2), and is marginally more complex than > either. > > Other things (the overlapping packages idea, for instance) are way too > complex and will just lead to breakage. Can anyone provide an argument > against (1) or, alternatively, for (2)? (2) seems to add a lot of > complexity for no clear gain and I remain pretty confused about why it > was chosen. > -Nathan > > On 04/18/16 20:17, Alfred Perlstein wrote: >> Maybe what the "too many packages" folks need to do is write some >> code to hide that it's so many packages. >> >> :) >> >> I think the rule of two feet should be applied here. >> >> What we have is people that have worked quite hard to bring us >> something that we can easily work with, and on the other hand some >> folks that want something they consider even better. Personally I >> can't see how having the system less granular is better, since having >> it MORE granular is actually harder work. >> >> Can someone on the "too many packages" campaign here explain to me >> how having too fine a granularity stops you from making macro >> packages containing packages? >> >> Because honestly I can't see how having granularity hurts at all when >> if someone wanted to make it less granular all they would have to do >> is make some meta-packages. >> >> -Alfred >> >> On 4/18/16 7:23 PM, Lyndon Nerenberg wrote: >>> On 2016-04-18 7:01 PM, Roger Marquis wrote: >>>> Can you explain what would be accomplished by testing all or even a >>>> fraction of the possible permutations of base package >>>> combinations? We >>>> don't do that for ports. >>> >>> The ports tree isn't a mandatory part of the system. And by >>> definition it could not be tested that way, since it offers so many >>> alternative implementations of specific functionality. >>> >>>> Other operating systems don't do that for >>>> their base packages. >>> >>> I'm pretty sure Solaris had some fairly hard-core regression tests >>> to ensure basic system functionality wouldn't be compromised by >>> 'oddball' selections of packages offered up at install time. >>> >>> > Honestly, some of us are wondering what exactly is >>> > behind some of these concerns regarding base packages. >>> >>> The concern is from all of us UNIX dinosaurs who predate the >>> fine-grained packaging environment, which just worked, and who now >>> rip our (little remaining) hair out due to unsolvable package >>> dependency loops in the Linux machines we are forced to administer >>> in order to pay rent. For me, as a sysadmin, I derive a negative >>> benefit from this optimization. >>> >>> I guess what I'm really asking is: where is the peer reviewed >>> research that shows this actually improves things for the not-1% of >>> FreeBSD users? >>> >>> --lyndon >>> >>> P.S. Don't turn this into a pissing match. I really want to know >>> how this is of net benefit to everyone. But I don't want >>> hyperbole. I have looked at a lot of, e.g., USENIX and ACM, >>> bibliographies and papers for justification for this, and I can't >>> find it. It would really help (me, at least) if someone could take >>> a moment to point me at demonstrable evidence of the benefits of >>> this model. >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > From owner-freebsd-current@freebsd.org Tue Apr 19 17:18:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E097CB144F0; Tue, 19 Apr 2016 17:18:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEF01D2B; Tue, 19 Apr 2016 17:18:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 9D125973; Tue, 19 Apr 2016 20:18:35 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57165E96.4040302@freebsd.org> To: Alfred Perlstein , Nathan Whitehorn , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <57166869.90805@FreeBSD.org> Date: Tue, 19 Apr 2016 20:18:33 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57165E96.4040302@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l4LVBCmfFldA5WATWVlHSKsuIiVMlpsOc" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 17:18:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l4LVBCmfFldA5WATWVlHSKsuIiVMlpsOc Content-Type: multipart/mixed; boundary="CinENeBHGIxQO3CnAIpP9T2a8brQOGGlM" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Alfred Perlstein , Nathan Whitehorn , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Message-ID: <57166869.90805@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57165E96.4040302@freebsd.org> In-Reply-To: <57165E96.4040302@freebsd.org> --CinENeBHGIxQO3CnAIpP9T2a8brQOGGlM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19.04.2016 19:36, Alfred Perlstein wrote: > Why is this even happening in email? If folks want "the right solution= " > then why aren't they submitting patches or pull requests to the pkg rep= o > (or where ever this is stored?). This seems counter-intuitive, but > really actually should be how it works.=20 Ops should send patches with non-trivial code? Please, keep it in mind: here are thousands of SYSTEM ADMINISTRATORS / OPS (not fancy and trendy DevOps), who will use (and praise or suffer) new packaged system. Many of them understand, what is good and what is bad for them, but they CAN NOT and SHOULD NOT code in C and "submit patches". Now your, effectively, say "we are interested only in opinions of developers, not end-users". It is wtong-wrong-wrong. It is what Slawa try to tell: not developers will support thousands of servers which will have 755 packages only for base system, but admins and ops, and they have OTHER priorities over developers. And, of course, most of them could not send high-quality patches to such complex pieces of software as pkg or FreeBSD build system. --=20 // Lev Serebryakov --CinENeBHGIxQO3CnAIpP9T2a8brQOGGlM-- --l4LVBCmfFldA5WATWVlHSKsuIiVMlpsOc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFmhpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeProMQAIqL/RH7qQdjgcVLn6uvvXZA 0vXuHOJ9EzaIkdu4fXR4hMBA0nrg2TPoWb9ANnjYmU5p6Bgjc8jPD6ks6bUBBxuK Je9OygMo1oQEJj4i5MZiEaiuSOzcNCl+VuLKgqWi5pf8xcQoyWCN4Mt/xyfN32h9 hDXtMtN6ucnzdOF9OGdTcgoDwpuOJ6cAuz6S5WrI4YiGQL3HVFVY7S7bAwsuz/05 gQ7Y8NMvBswlogRAySwH2M76twEbT5EVsckH+u7C25rZmZjEXROSo87D/j5ASsUK 3ZWyODy6wJMafvb0/3QhN5toaoqrkGQOeCc7RZM2WZHmoNR4O4jcd7SLIP4RQ1W0 qFEKohdAKqoI2Wqn5k6fW3ugPyba9Dt9sI5vo6ogPH+HfjkaQKfqnmnN+KMNYWTU IkoqR7HkxJH4nF4nhIGf28ZK7+ZuFWrl29fJaDK53QZBonj43uzuhvobYulsnVJA y6aIG/ZHXbVVRCrS36B8fM5icuSyF+ovQ5vCMiS95fyNTCUo22naIWXFwiDHP7yp 2KzQTpqm+lVudkji/ynoOTNkUIqVXRE6s7/HzYFropQEJ1pwTKrDFFEpcQjrUHOT A0LESk6isdoyWa4YlZNsW4zmQ9AKMTHhb4GoDYi/ks4oykRufTcF8YlAeY5eimkG Ka/wh61eq7cu59Ys7/9A =08yf -----END PGP SIGNATURE----- --l4LVBCmfFldA5WATWVlHSKsuIiVMlpsOc-- From owner-freebsd-current@freebsd.org Tue Apr 19 17:18:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07CC7B14509; Tue, 19 Apr 2016 17:18:41 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8D60B1D3B; Tue, 19 Apr 2016 17:18:40 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 3E538974; Tue, 19 Apr 2016 20:18:39 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> To: Nathan Whitehorn , Alfred Perlstein , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <57166870.5060104@FreeBSD.org> Date: Tue, 19 Apr 2016 20:18:40 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57165C91.7070005@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ew0eshAVrfxHUBgS5pbvm6NKDmIwikIOT" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 17:18:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ew0eshAVrfxHUBgS5pbvm6NKDmIwikIOT Content-Type: multipart/mixed; boundary="GWcR6C3NuXf1hQsJ9NGDfAwsLRLrDhQpF" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Nathan Whitehorn , Alfred Perlstein , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Message-ID: <57166870.5060104@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> In-Reply-To: <57165C91.7070005@freebsd.org> --GWcR6C3NuXf1hQsJ9NGDfAwsLRLrDhQpF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19.04.2016 19:28, Nathan Whitehorn wrote: > 3. Have ~10 meta packages that just depend on sets of the 755 packages > and hide the internal details. This gives the user experience of (1) > with the implementation of (2), and is marginally more complex than eit= her. How does it help Slawa with his broken system when "pkg upgrade" replace only half of "base" packages? Meta-packages as they are now: "no files, only dependencies" doesn't help here at all. Really, if I want "base but no sendmail" I want easy way to see it after 5 years after installation, and 755 packages, covered or not by meta-packages, will need me to read all list of 754 packages to see, that there is no sendmail, for example. It is trivial example, but it is completely valid. And there are many other such corner cases, which is common for administrators and ops, but not for developers. Please, consider ops and admins, who must support old installations, often made by other, not-reachable, people, and stuff like this, --=20 // Lev Serebryakov --GWcR6C3NuXf1hQsJ9NGDfAwsLRLrDhQpF-- --ew0eshAVrfxHUBgS5pbvm6NKDmIwikIOT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFmhwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePuYoQALRLdJkvrcoeMXTQyMpe/KAf kw31o9zrwP9JuGvgKVV7+iyURkR4r44ha/1oE0cjtCyun1ulRZChwhXHNoRAUES+ EBTHX4HohYcimq9O4jnHumbLQiKkXRwbuXH+/RAjS0dqV1ibZTE148cWtbg06nQe +iLrPl9RPBb4WoHeCc3u51POnSbZNBr+V5+HjTCcogLlQqFWdAACq4ppVRUtcRO3 BYMfrPEjILjDEMfJZ+5tXg/efP7JCHU4ym77T1xSTIiJxJhkhQ++doh01D4VjxqF ebFmjxbLMIdnrNVJUaLiPapcTVXiKYFMo1UM42pF2jn1P/327G1XaYSMGmI3RWyg xcJPBRR5e7692UimDxVhfny7HGyDeLQigOqBZxYZt5HoidSQmwdu4zmRgx66KCHN 4RS0v9qoMJm1gSxF4oeF8xKIXoD0ytq/13f+QIlL1GydiAikbx1aPfpCn/Ct/Yo2 DK07xXVTxyQZR+J7IUEcIwDnbYtdSPxH3nmYjUBTMeF6pRtsavDvJPINyD3ISyg4 q67CDPOWyCj4Lmft1URl8rBH6aXCYpPU8yyVgRL0bpQK5rHovGPCH22ck9wHV91u lcPyxAb0Hsw4De6eWf4P9iP4zo5yB+54U1p/ns/Zn/SGUZS8H9P3KSS/XlqAO2nr m2Fj6b6IMi/pJpX7Hnat =W3jw -----END PGP SIGNATURE----- --ew0eshAVrfxHUBgS5pbvm6NKDmIwikIOT-- From owner-freebsd-current@freebsd.org Tue Apr 19 17:55:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A549DB153B6; Tue, 19 Apr 2016 17:55:37 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DB1719B6; Tue, 19 Apr 2016 17:55:37 +0000 (UTC) (envelope-from marquis@roble.com) Date: Tue, 19 Apr 2016 10:55:36 -0700 (PDT) From: Roger Marquis To: Lev Serebryakov cc: Nathan Whitehorn , Alfred Perlstein , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <57166870.5060104@FreeBSD.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 17:55:37 -0000 > Please, consider ops and admins, who must support old installations, > often made by other, not-reachable, people, and stuff like this, Ops and admins such as myself are exactly the ones who will benefit most from base packages. Being able run to: 1) 'pkg audit' and see that base ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those specific parts of base that need to be updated is far simpler (KIS) and faster than what we go through now. More than a few formerly bsd shops have migrated to linux simply to avoid regular iterations of cd /usr/src; svn up; make cleanworld; make buildworld installworld ... The use cases for granular base packages are more numerous than even these obvious ones. The downside OTOH, seems to consist of not much more than the size of the package list. If I missed other issues please do clarify. Will base packages be improved, sure, but they're already more useful and bugfree than pkgng when it was mandated. In any case, if I'm not mistaken base packages are entirely optional. Roger Marquis From owner-freebsd-current@freebsd.org Tue Apr 19 18:22:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7178B15D44; Tue, 19 Apr 2016 18:22:20 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8363F18E5; Tue, 19 Apr 2016 18:22:20 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3JIMI8I028398 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Apr 2016 11:22:18 -0700 Subject: Re: [CFT] packaging the base system with pkg(8) To: Roger Marquis , Lev Serebryakov References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> Cc: Alfred Perlstein , Lyndon Nerenberg , freebsd-pkgbase@FreeBSD.org, freebsd-current@FreeBSD.org From: Nathan Whitehorn Message-ID: <5716775A.2000401@freebsd.org> Date: Tue, 19 Apr 2016 11:22:18 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <201604191755.u3JHtbfS020358@l.mx.sonic.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYb77rFijGcMFXLAI+hHr6N7qHqYcFivMuSyN4WCgkVzgrujANTWZaFhJgSJKcDhWso/dXR6LcW1HjVSHR5KJeRfEtYL8OuYak= X-Sonic-ID: C;UAwxplsG5hGLLreqjlfmnQ== M;hlFvplsG5hGLLreqjlfmnQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 18:22:20 -0000 On 04/19/16 10:55, Roger Marquis wrote: >> Please, consider ops and admins, who must support old installations, >> often made by other, not-reachable, people, and stuff like this, > > Ops and admins such as myself are exactly the ones who will benefit most > from base packages. Being able run to: 1) 'pkg audit' and see that base > ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those > specific parts of base that need to be updated is far simpler (KIS) and > faster than what we go through now. More than a few formerly bsd shops > have migrated to linux simply to avoid regular iterations of cd > /usr/src; svn up; make cleanworld; make buildworld installworld ... > > The use cases for granular base packages are more numerous than even > these obvious ones. The downside OTOH, seems to consist of not much > more than the size of the package list. If I missed other issues please > do clarify. Will base packages be improved, sure, but they're already > more useful and bugfree than pkgng when it was mandated. > > In any case, if I'm not mistaken base packages are entirely optional. > > Roger Marquis > Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal is really met by having 800 packages, though, or at least I see no particular gain relative to a handful (where things like OpenSSL or sendmail would be discrete things). (Almost) every single individual library in the base system is right now its own single-file package, which is what I am objecting to. The upside of that seems pretty dubious and the downside is that it is much easier to accidentally put the system into an inconsistent state. Is there a reason you want to have such very fine discretization? -Nathan From owner-freebsd-current@freebsd.org Tue Apr 19 19:26:22 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28EEFB14C7D for ; Tue, 19 Apr 2016 19:26:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09337104A for ; Tue, 19 Apr 2016 19:26:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 40E9AB99B; Tue, 19 Apr 2016 15:26:20 -0400 (EDT) From: John Baldwin To: Howard Su Cc: freebsd-current@freebsd.org Subject: Re: Mis-use of BUS_PASS_ORDER_MIDDLE Date: Tue, 19 Apr 2016 09:32:54 -0700 Message-ID: <2291840.VrgKOUFVXv@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <1611132.EbTME86UTe@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 19 Apr 2016 15:26:20 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 19:26:22 -0000 On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote: > On Tue, Apr 19, 2016 at 2:53 AM John Baldwin wrote:= >=20 > > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > > I noticed several places there are code like this, especially in = some arm > > > low level drivers. > > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devc= lass, > > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > > > =E2=80=8BI feel the usage of BUS_PASS_ORDER_MIDDLE is misused. Th= ere are another > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional param= eter > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter.= > > > > No, this is actually correct. The _ORDERED variants actually accep= t a > > SI_ORDER_* value to determine how drivers contained in a single .ko= file > > are registered (in particular if you have several drivers in a .ko = file > > you typically want the "top-most" driver to attach last so that all= the > > other drivers are ready once the actual device is attached). > > > Why not use _ORDERED here to achieve same thing? _ORDERED(...., > SI_ORDER_LAST, BUS_PASS_BUS)? >=20 > I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MO= DULE, > TIMER_DRIVER_MODULE, so that the driver can declare itself in such wa= y. If > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. >=20 > I am plan to do is: in autoconf phase, first load timer, int and some= bus, > etc low level drivers first, then set cold=3D0, then load other drive= r to > work around the problem that driver needs special handling on cold wh= ich is > not necessary. of course, this may depends on your change of ap_start= up. > thoughts? I would like to get to that, but the path on x86 is a bit messier. Ide= ally the order looks something like this: - enumerate the tree (BUS_PASS_BUS) - reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE)= - reserve existing resources that could be moved or disabled if their is a conflict (think PCI BARs programmed by firmware and/or doing an initial pass of BARs) - interrupt controllers (may need resources) (BUS_PASS_INTR) - timers (probably need resources, need interrupts) (BUS_PASS_TIMER) Then all the rest. However, it ends up a bit messier on x86 at least. I have a WIP to at least start doing BUS_PASS_BUS for x86, but I found that I really need some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns o= ut that in some cases we need more granularity than just 'BUS_PASS_xxx'. SI_ORDER_* with ORDERED will not help as all the drivers are registered= at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies), but the device tree is enumerated and attached at SI_SUB_CONFIGURE. And yes, the AP startup stuff is a precursor for this. --=20 John Baldwin From owner-freebsd-current@freebsd.org Tue Apr 19 19:44:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55A1CB0A337 for ; Tue, 19 Apr 2016 19:44:24 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (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 2EA281052 for ; Tue, 19 Apr 2016 19:44:24 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 122) id 029D51602FA; Tue, 19 Apr 2016 12:35:22 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Received: from feyerabend.n1.pinyon.org (h5.esturion.net [65.101.5.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 38C7A1601F8 for ; Tue, 19 Apr 2016 12:35:19 -0700 (MST) Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> From: "Russell L. Carter" Message-ID: <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> Date: Tue, 19 Apr 2016 12:35:18 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5716775A.2000401@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 19:44:24 -0000 On 04/19/16 11:22, Nathan Whitehorn wrote: > > > On 04/19/16 10:55, Roger Marquis wrote: >>> Please, consider ops and admins, who must support old installations, >>> often made by other, not-reachable, people, and stuff like this, >> >> Ops and admins such as myself are exactly the ones who will benefit most >> from base packages. Being able run to: 1) 'pkg audit' and see that base >> ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those >> specific parts of base that need to be updated is far simpler (KIS) and >> faster than what we go through now. More than a few formerly bsd shops >> have migrated to linux simply to avoid regular iterations of cd >> /usr/src; svn up; make cleanworld; make buildworld installworld ... >> >> The use cases for granular base packages are more numerous than even >> these obvious ones. The downside OTOH, seems to consist of not much >> more than the size of the package list. If I missed other issues please >> do clarify. Will base packages be improved, sure, but they're already >> more useful and bugfree than pkgng when it was mandated. >> >> In any case, if I'm not mistaken base packages are entirely optional. >> >> Roger Marquis >> > > Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal > is really met by having 800 packages, though, or at least I see no > particular gain relative to a handful (where things like OpenSSL or > sendmail would be discrete things). (Almost) every single individual > library in the base system is right now its own single-file package, > which is what I am objecting to. The upside of that seems pretty dubious > and the downside is that it is much easier to accidentally put the > system into an inconsistent state. Is there a reason you want to have > such very fine discretization? > -Nathan What is missing from this debate is some perspective from the POV of actually existing packaging systems. I've been maintaining debian-stable + debian-testing systems for over 15 years. The number of packaging glitches I've had I can count on one hand. (I've been running FreeBSD systems since the *very* beginning.) It is much easier to maintain my debian systems than my FreeBSD systems. Actually, pkg + poudriere is like a dream. Better than apt-get, actually. Except right now it doesn't maintain the base system. So, how many packages are actually installed on one of my debian boxes? debian-testing box with fvwm (ie no gnome/kde) userland: rcarter@aristotle> dpkg --list | wc --lines 1571 FreeBSD-10/stable with the same userland packaged from ports: rcarter@feyerabend> pkg info | wc -l 833 The debian system, for basically identical functionality, installs 738 more packages. Obviously the FreeBSD box has no packages for the base system, so that is probably a significant part of the difference in installed packages. And the debian box is dramatically easier to maintain. I typically will drag a debian box across several debian release cycles, i.e., 6+ years, w/o ever doing anything more complicated than doing apt-get update; apt-get dist-upgrade every week or so. Now I much prefer poudriere + pkg over apt-get, because I can tune my package dependencies. What I do is make the implicit meta-packages effectively even more fine grained, by excluding stuff I don't need. My conclusion is that it's not obvious that a large number of packages makes a system harder to maintain. It seems to me, the opposite. Now I watch a few debian lists so I know glitches happen, but not to me very often. I don't have much experience locking down a system to just major releases with only security updates, but I don't think debian-stable has very many issues doing exactly that. In my opinion, what the package team is doing is extremely cool, technically. I run poudriere builds every night, keeping up to date with ports-svn. It's just so much better than debian's kitchen sink one-size-fits-all approach to package dependencies. In a container world, it seems to me this is basically a killer app. Best to all, Russell > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Apr 19 20:04:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1B33B0AC76 for ; Tue, 19 Apr 2016 20:04:58 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC021175 for ; Tue, 19 Apr 2016 20:04:58 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8A605B0AC75; Tue, 19 Apr 2016 20:04:58 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A034B0AC74 for ; Tue, 19 Apr 2016 20:04:58 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 232AD1174 for ; Tue, 19 Apr 2016 20:04:57 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1asbZj-0001gZ-RG for current@freebsd.org; Tue, 19 Apr 2016 21:44:43 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1asbZj-0003Ra-Qs for current@freebsd.org; Tue, 19 Apr 2016 21:44:43 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Tue, 19 Apr 2016 19:44:43 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: Re: [CFT] packaging the base system with pkg(8) Date: Tue, 19 Apr 2016 12:44:43 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <57166870.5060104@FreeBSD.org> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:04:58 -0000 On Tue, 19 Apr 2016 20:18:40 +0300, Lev Serebryakov wrote: > On 19.04.2016 19:28, Nathan Whitehorn wrote: >=20 > > 3. Have ~10 meta packages that just depend on sets of the 755 packages > > and hide the internal details. This gives the user experience of (1) > > with the implementation of (2), and is marginally more complex than eit= her. > How does it help Slawa with his broken system when "pkg upgrade" > replace only half of "base" packages? >=20 > Meta-packages as they are now: "no files, only dependencies" doesn't > help here at all. >=20 > Really, if I want "base but no sendmail" I want easy way to see it > after 5 years after installation, and 755 packages, covered or not by > meta-packages, will need me to read all list of 754 packages to see, > that there is no sendmail, for example. It is trivial example, but it is > completely valid. And there are many other such corner cases, which is > common for administrators and ops, but not for developers. >=20 > Please, consider ops and admins, who must support old installations, > often made by other, not-reachable, people, and stuff like this, >=20 > --=20 > // Lev Serebryakov Thoughts PRO pkg base from here: it can fix a broken installworld that breaks midway rendering the system n= o able to login, not able to compile or install futher, or some other event... Can those failur= es be crafted purposely to show how the could be readily per procedure if a usual installworld fa= ils? Thoughts ANTI pkg base from here: Several, but I have thought of more work required for developers who have = custom kernels and a large amount of code that is BETA and not READY yet and are slowed down= by conforming to additional pkg-base requirements.. hindering creativity ... Sparse initial documentation or at some time not upto par ... *FLOWCHART" demonstrating precisely the relationship between a pure-pkg-ba= se and pure-svn-base system, a mixture of the two, how to migrate parts/all of one to the other= , one edge a desired install or several types of same, the other (two) edges where one starts out from= ... that could be updated over the years for a comprehensive overview. =20=20=20=20=20 [ AS AN ASIDE, ] I always tend to think that as missing already in pkg= , svn, synth, poudriere, jails, chroot, wpa_supplicant, ndisalator, linux-c6, binutils >> << gcc , zfs= , ssh_config, ipfw, pf, geli, gpart, UEFI, xorg.conf, some individual ports, [ I should stop typing = here, because even as I type more things come to mind... problem with a port ? pr OR maintaine= r OR documentation OR... flowchart... etc ] stuff-to-leave-out-or-include-in-a-kernel, buildworld/installworld, pp= p.conf, NOT AS CRITICISM but as "Why is it not at least as good for newbies to each concept or bett= er than a WIKI !!! as not only the simplified explanation sometimes can be made more apparen= t of which cli to issue next, but time spent reading stuff NOT specific to the task at hand is saved= .=20 =20=20=20=20=20 Adequate testing? some breakage bound to happen... fixing such breakage p= rocedures in place? A UPDATING for pkg-base specifically?=20 Again, not wishing to waste one's time, just writing down what I've thought= of so far, freely simply file it away rather than reply online... my answers to any reply could simply r= e-iterate the background to the above (I am NOT well versed in many topics of FreeBSD, just in the more use= ful ones at the installs that I use daily... ).= From owner-freebsd-current@freebsd.org Tue Apr 19 20:09:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C87B8B0ADDA for ; Tue, 19 Apr 2016 20:09:33 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B8097134B for ; Tue, 19 Apr 2016 20:09:33 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id B75E0B0ADD9; Tue, 19 Apr 2016 20:09:33 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6FE2B0ADD8 for ; Tue, 19 Apr 2016 20:09:33 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8259C134A for ; Tue, 19 Apr 2016 20:09:33 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0E8464F57A; Tue, 19 Apr 2016 20:09:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u3JK9UOK076094; Tue, 19 Apr 2016 20:09:30 GMT (envelope-from phk@phk.freebsd.dk) To: jbtakk@iherebuywisely.com cc: "current" Subject: Re: [CFT] packaging the base system with pkg(8) In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <76092.1461096570.1@critter.freebsd.dk> Date: Tue, 19 Apr 2016 20:09:30 +0000 Message-ID: <76093.1461096570@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:09:33 -0000 As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. It's nice to see the level of enthusiasm the FreeBSD project can muster, I just wish it wasn't always enthusiasm for stopping progress. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@freebsd.org Tue Apr 19 20:10:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4DA8B0AE9E for ; Tue, 19 Apr 2016 20:10:30 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C4B6E16DA for ; Tue, 19 Apr 2016 20:10:30 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C40DFB0AE9C; Tue, 19 Apr 2016 20:10:30 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B77B0AE9B for ; Tue, 19 Apr 2016 20:10:30 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD8E16D9 for ; Tue, 19 Apr 2016 20:10:30 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x229.google.com with SMTP id f89so19729110ioi.0 for ; Tue, 19 Apr 2016 13:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=bakpdAO38J79Seb2aJOUX8d4oSs1iWewqGnhl8tEX90=; b=zLIcYhs0h06pPNpfdzKD6JzZNiyMIM8R5XFlpBDPUnhNQzi4dnuGTEnlBoTx7Ag5db iSTes0cGMoRvbe5z1RFjhhbxxCWIhwKQU59ascxoQAVrowZTplFRsX1rDtM7latIvImq I6N/1VA/TH+eFb4AhKqK4Wx4OclYhI/kgk35s+qpqjdnTJNgUaSm4xJziJSfurjwZ1yI LmOedfmsKAvxL/FomC8eDhbT49jRSnOcAnTgHmbF+9ejSDiyNQ/G8GCYojuGILExDEz1 CiuXVHYlNlOKzfcpe1va3Pp0UbcDLSYMrqztkIKH7bTZPd2BPm1v4/rrI0q7r47qLbx7 ImxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bakpdAO38J79Seb2aJOUX8d4oSs1iWewqGnhl8tEX90=; b=Tej7/UpDcYRMk75xqymRq6wAzODCfiPFU7Rnq5rAvP9s3KhKDJxEF0/Ko2peT6ZXtB T2bj9yN6CL87DHTrKhQo4ECexxuvIHVlaTgvG0ui97u7FtVCBf2+IdD48Tax6Erm5lgI n5edm7EKndGPe3PfxlSyWYS92vVPvB4KfD3aMT0Aq1gGJtW5PBFJEoh53P8gQi70IfhR ULrgC1NRUbgXRXMySgZPkTSj445iAh31q2QIjHjxQMmwR/GfULSJia2ZxCUBIL3uqLyz z0W11rzB5jocoodT1KFb7mB56kBVgYHX29SuR+YnZoFkZqop2KqNw/k6oD+nBp/u3dBP DPhw== X-Gm-Message-State: AOPr4FVvfHY/MYh6oY5CIdkZhPTVY4SZSw9YIiCPeDaqiZcoawOkW9QZn+TwMpRbn6eLa9WgwQ+xcqzKyZ9epg== MIME-Version: 1.0 X-Received: by 10.107.162.17 with SMTP id l17mr6622435ioe.42.1461096629982; Tue, 19 Apr 2016 13:10:29 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.6.166 with HTTP; Tue, 19 Apr 2016 13:10:29 -0700 (PDT) In-Reply-To: <76093.1461096570@critter.freebsd.dk> References: <76093.1461096570@critter.freebsd.dk> Date: Tue, 19 Apr 2016 13:10:29 -0700 X-Google-Sender-Auth: -fN-eALhWV-G_6xE_PoVIQz-9Bg Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: "K. Macy" To: Poul-Henning Kamp Cc: "jbtakk@iherebuywisely.com" , current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:10:31 -0000 On Tuesday, April 19, 2016, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. +1 > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > From owner-freebsd-current@freebsd.org Tue Apr 19 20:16:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D37EB14344 for ; Tue, 19 Apr 2016 20:16:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 08ECF1E86 for ; Tue, 19 Apr 2016 20:16:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 04918B14343; Tue, 19 Apr 2016 20:16:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 043EFB14341 for ; Tue, 19 Apr 2016 20:16:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 C125F1E85 for ; Tue, 19 Apr 2016 20:16:11 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8388ef2a-066b-11e6-b8f9-33a5b3560672 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 19 Apr 2016 20:15:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u3JKG2DA036715; Tue, 19 Apr 2016 14:16:02 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1461096962.1232.32.camel@freebsd.org> Subject: Re: [CFT] packaging the base system with pkg(8) From: Ian Lepore To: Poul-Henning Kamp , jbtakk@iherebuywisely.com Cc: current Date: Tue, 19 Apr 2016 14:16:02 -0600 In-Reply-To: <76093.1461096570@critter.freebsd.dk> References: <76093.1461096570@critter.freebsd.dk> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:16:12 -0000 On Tue, 2016-04-19 at 20:09 +0000, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping > progress. > Why is it that anyone who tries to inject some aspect of concensus design into something is automatically labeled anti-progess? Oh yeah, now I remember: Because in freebsd, design is decided by a race to commit rather than by discussion. -- Ian From owner-freebsd-current@freebsd.org Tue Apr 19 20:17:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9498FB14431 for ; Tue, 19 Apr 2016 20:17:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5A00E1008 for ; Tue, 19 Apr 2016 20:17:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 69FFB9B3 for ; Tue, 19 Apr 2016 23:17:23 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> To: freebsd-current@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <5716924C.4060104@FreeBSD.org> Date: Tue, 19 Apr 2016 23:17:16 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nFLEwmfEe7dmeRCaTTHRhI58eGfNA04Gs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:17:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nFLEwmfEe7dmeRCaTTHRhI58eGfNA04Gs Content-Type: multipart/mixed; boundary="vTwx1iF9m2qK7geu06Natnm0wD8DLWNKP" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: freebsd-current@freebsd.org Message-ID: <5716924C.4060104@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> In-Reply-To: --vTwx1iF9m2qK7geu06Natnm0wD8DLWNKP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19.04.2016 23:10, K. Macy wrote: I don't like to see, as some participants of this thread write their messages as if somebody in this thread are against packaging base with pk= g. I don't see anybody, who say "remove this packaging code, it is all completely wrong, BS, whatever". All objections are against mechanical splitting base to 700+ packages, not against packaged base per se. --=20 // Lev Serebryakov --vTwx1iF9m2qK7geu06Natnm0wD8DLWNKP-- --nFLEwmfEe7dmeRCaTTHRhI58eGfNA04Gs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXFpJSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePIpYP/3Cze+d5hHMVnGtYHDp3/ehh Ebkc2whZVGmGN7yASOQjOspgEy0B41/TIp76G7KwRcCiuzn2LuKmEsoMTGX/7iVC 4wPxuo8NJfxyjmtC1mfiISO0i4UUcUfIiPz2D4beurpDL9/cmYO7gl52rkPngvnz cwn59hj83NfENle/3kd5jSsBAa6zik0wgDZYBoD4ydYF06U2FFFIVMvio5EdwIRU 6jbMk8+gPpOc8Sz0QRan4bb1K5Wa8/igIXSHkFmK3omA/S44pqxHT3p5u+vF2JzL cf7OR2Hom8vBvg9jy2b5hyMslU14u3UEX23AEair2z90RB5AuSmzOFTCef0wGFZd k17gx04MjHE489lmUJjbWntsyp+JrqQ2PA88DzsmO8ubZfJZFCh0Q8XoZAoJDkG3 BzGJ6n4acSz8CKyyCzCsyzbg28yNXo1hCkFZzkCzcrGOkF68wOsJGFp+PkiF88X8 pGYpuYNMvcnp1OxRkSar0Swt/gujE2xLtyDvz0D8YFQrN/6j3WC2/tO0WhFX/Ei1 QK69KQVY+1XNas2PXKHu5dNIpU8JgMsyCJTlX0dYl/j/4cSaEFSoSR+11IWa5Hzm 6cfOCNcoqjDzaXFCGXtKAUzuwvXm5ukQN3E07+7RQ80Yxs0iynE4O4FBnGv1JVvC mcdvWMlP5O03BtKtDRoq =61TA -----END PGP SIGNATURE----- --nFLEwmfEe7dmeRCaTTHRhI58eGfNA04Gs-- From owner-freebsd-current@freebsd.org Tue Apr 19 20:26:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85B85B14A01 for ; Tue, 19 Apr 2016 20:26:00 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 485991C0D; Tue, 19 Apr 2016 20:26:00 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1ascDj-000HvO-Mh; Tue, 19 Apr 2016 22:26:03 +0200 Date: Tue, 19 Apr 2016 22:26:03 +0200 From: Kurt Jaeger To: Lev Serebryakov Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419202603.GL2282@home.opsec.eu> References: <76093.1461096570@critter.freebsd.dk> <5716924C.4060104@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5716924C.4060104@FreeBSD.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:26:00 -0000 Hi! > I don't see anybody, who say "remove this packaging code, it is all > completely wrong, BS, whatever". All objections are against mechanical > splitting base to 700+ packages, not against packaged base per se. I also run a bunch of boxes, and I do not have a problem with 700+ base packages on top of the other ones I use. But: I have not tested pkg base yet. I'm just a happy pkg user 8-} -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Tue Apr 19 20:26:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5AAAB14A61 for ; Tue, 19 Apr 2016 20:26:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C4D4D1D6D for ; Tue, 19 Apr 2016 20:26:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id C06F7B14A5F; Tue, 19 Apr 2016 20:26:24 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0106B14A5E for ; Tue, 19 Apr 2016 20:26:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3521D6B; Tue, 19 Apr 2016 20:26:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id B16144FB55; Tue, 19 Apr 2016 20:26:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u3JKQLsV076178; Tue, 19 Apr 2016 20:26:21 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Lepore cc: jbtakk@iherebuywisely.com, current Subject: Re: [CFT] packaging the base system with pkg(8) In-reply-to: <1461096962.1232.32.camel@freebsd.org> From: "Poul-Henning Kamp" References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <76176.1461097581.1@critter.freebsd.dk> Date: Tue, 19 Apr 2016 20:26:21 +0000 Message-ID: <76177.1461097581@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:26:24 -0000 -------- In message <1461096962.1232.32.camel@freebsd.org>, Ian Lepore writes: >Oh yeah, now I remember: Because in freebsd, design is decided by a >race to commit rather than by discussion. No, that's not it. It is because code talks much louder than words. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@freebsd.org Tue Apr 19 20:36:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97011B151BA for ; Tue, 19 Apr 2016 20:36:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 790621967 for ; Tue, 19 Apr 2016 20:36:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 72D22B151B7; Tue, 19 Apr 2016 20:36:30 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 727E0B151B6 for ; Tue, 19 Apr 2016 20:36:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F22B1965; Tue, 19 Apr 2016 20:36:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id g185so31765697ioa.2; Tue, 19 Apr 2016 13:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=CN/kTqaUoV3Cnav66Hqe99EH53lxHbmcZ4wbZ9TxIJY=; b=GdaMNA6CHS9cUt6y/h2Il5FZmUkmTJHucCldBdAeBGFLVYRcI3cyf3P1bTv3WjLLXS +hOS+gyMTrkyY6wDlgKrUTb8aJ8Pz7s8iSftWA60A40bYDnZF8KAtQV3SCsl/rGV227x pVWG35YpUBlNYg4FwGxaYqV0Btxb+/yBk/tpMBuIFHA7MiFLBPl+k0JtCPcmzYzOGDj4 ZRdLPm2ERxkfSU0HPwq2zRhnnVL1qkNXO3OdNngHlCmpH+B6GtuAHWmA/3trURw1QZE9 f3Fai3pRN1aS3IVjSAQR6S1TZvtQqYxJU/xlk0FGxnB1FwUnEs91rPUTE0mo3LkbnWG0 x6/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CN/kTqaUoV3Cnav66Hqe99EH53lxHbmcZ4wbZ9TxIJY=; b=XUq6qI4DyjYejdsKH8nO2vRCHtLPAKEnpw0WjQdjWeNQERiAMSlB/Bh3NdbvixkzmH ennnwaJFrneFGvFeOS4cH4pZxUKmqmzR3lCrxQG6IRCKU0W1kw3xLdfiUmsfSukD6fzp 5aN8nHbRzrX1NIw8D0kT8Jdu13SJFkWBQYh030xjFXybqTmo+4DmRMS3LNOh+AKuB+1p Eb5yij0TsTBYmbDnz6vT/8WxE+zcowha/wIGgo7RSh3HP0oi66mwBHtqB4QzwvfAR4nX BsisZ5v6Ch4ADiewtJgdxJbk+z/GIRpjonn3JY5SMqB3OujFZLys2ESGsLx/vq3yH3SH 3ipA== X-Gm-Message-State: AOPr4FXtayEOywvwZud0EUPvfPUN4KlmCtE2cnS5qyeTFaWUD1lSTTs2ScNh6NAWQbWBx3tIPeUF5Sa9L2PfjQ== MIME-Version: 1.0 X-Received: by 10.107.48.131 with SMTP id w125mr5597359iow.123.1461098189670; Tue, 19 Apr 2016 13:36:29 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Tue, 19 Apr 2016 13:36:29 -0700 (PDT) In-Reply-To: <76177.1461097581@critter.freebsd.dk> References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> <76177.1461097581@critter.freebsd.dk> Date: Tue, 19 Apr 2016 13:36:29 -0700 Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: Adrian Chadd To: Poul-Henning Kamp Cc: Ian Lepore , jbtakk@iherebuywisely.com, current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:36:30 -0000 It's cool. I have positive and negative reactions, and I'm totally happy to let people try it out at a larger scale and learn from mistakes. Because, honestly - fuck it, we've been behind for too long. We need more mature tools and knowledge with this. The irony of course is the people rolling out docker are doing it after finding that OS packages aren't the best granularity, but "whatever the package systems in the software stack we're using, and then tar the whole mess up and distribute it" method. Kinda like FreeBSD.... -adrian From owner-freebsd-current@freebsd.org Tue Apr 19 20:41:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9347B154FD for ; Tue, 19 Apr 2016 20:41:49 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C765A186B for ; Tue, 19 Apr 2016 20:41:49 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C2CA4B154FC; Tue, 19 Apr 2016 20:41:49 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C26C9B154FB for ; Tue, 19 Apr 2016 20:41:49 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B2D51868; Tue, 19 Apr 2016 20:41:49 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x229.google.com with SMTP id g185so31912149ioa.2; Tue, 19 Apr 2016 13:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Zu5UoypJrOx9OOUs5wnopECBHcn2yGRsdO6uYyjfifA=; b=Tzj/UTS2+JSgEQLZDNjJbu5Xe+errwqKceXvX8xof+HKMtlKHmvpx46L5BJMNcWEBf xMthfWNB7xVJSm7GENwZ8Q+IMkWil3sd7QvfhPAxk9pNAc8/iDoeYxUDGB1jiHFZsKAj MtjWEdqBBWRiGWHsClI1iEPt685Coqc3I+Y2ovmAHD9bFDl8YFo+rATJmeOpdUr5M/Nn ukg/ZtM6x4pO3IEltA3VMkKi11IYkIkIHN3ggymIzguIix6vV6EAqP9VFebfATmUDrd6 BwKEb8ZLLs1UVcRt2qW779TOp7UMuIBsatcEFBGvfckIRZodaSW6Sc0RwSAmAi/CjRsf +RsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Zu5UoypJrOx9OOUs5wnopECBHcn2yGRsdO6uYyjfifA=; b=Rx4cV1QMjl0xpRe+1nGMnkAad+7wCxj5+aiqRqaESZQdlUFfJILjUeoOWBEwlhueQR Ldx+UTbHvyrsN3zE11ozMv+ABmVMYYh9oo9BvdrODuPyGOus9+KNafoxRwpWGbhvdsxE jaUSGmvGe08jbOB4lfQJA7/0RLNw4DClasi9B39dTbvWzLH0Sa0KpRnO9INvNxlZBcdM IuaHvgXcK6hoQ6EWF6lUCMpjfQSjcvTkP6hbWUQoO4l7/v9x7U4mrgzfZ6QgS0w1d4qB 8e2j34bTGbvVfDFpR5ZwP07G8Q7s7znChkdO5oJ9/jHhkKIIehwgzyGOQd5y8oDrZ1pM 6Dlg== X-Gm-Message-State: AOPr4FWzOvVgOIHeGpkAkSnnLh4dEX5+beADIh6H04HDK5V0/kD3c/YRHYzVeNJ2n9/b41tVrxxf0fI3xr0Rkw== MIME-Version: 1.0 X-Received: by 10.107.7.170 with SMTP id g42mr4602312ioi.81.1461098509108; Tue, 19 Apr 2016 13:41:49 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.6.166 with HTTP; Tue, 19 Apr 2016 13:41:49 -0700 (PDT) In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> <76177.1461097581@critter.freebsd.dk> Date: Tue, 19 Apr 2016 13:41:49 -0700 X-Google-Sender-Auth: 8YKJIP2Mh9FdCKydLgHgge1izas Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: "K. Macy" To: Adrian Chadd Cc: Poul-Henning Kamp , Ian Lepore , "jbtakk@iherebuywisely.com" , current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:41:50 -0000 On Tuesday, April 19, 2016, Adrian Chadd wrote: > It's cool. I have positive and negative reactions, and I'm totally > happy to let people try it out at a larger scale and learn from > mistakes. > > Because, honestly - fuck it, we've been behind for too long. We need > more mature tools and knowledge with this. > > The irony of course is the people rolling out docker are doing it > after finding that OS packages aren't the best granularity, but > "whatever the package systems in the software stack we're using, and > then tar the whole mess up and distribute it" method. Kinda like > FreeBSD.... > > > Those are different, semi-orthogonal problems. Please restate your last paragraph. I can't interpret your intent. -M > > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > From owner-freebsd-current@freebsd.org Tue Apr 19 20:43:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22EF0B156D5; Tue, 19 Apr 2016 20:43:16 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC5D51CBE; Tue, 19 Apr 2016 20:43:15 +0000 (UTC) (envelope-from marquis@roble.com) Date: Tue, 19 Apr 2016 13:43:15 -0700 (PDT) From: Roger Marquis To: Nathan Whitehorn cc: Lev Serebryakov , Alfred Perlstein , Lyndon Nerenberg , freebsd-pkgbase@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <5716775A.2000401@freebsd.org> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:43:16 -0000 Nathan Whitehorn wrote: > Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal is > really met by having 800 packages, though, or at least I see no particular > gain relative to a handful (where things like OpenSSL or sendmail would be > discrete things). (Almost) every single individual library in the base system > is right now its own single-file package, which is what I am objecting to. Hey Nathan. I admit to not having looked at it with the goal of consolidation. Presumably there will be libs that can be grouped but we should look at each consolidation's pros and cons. Baptiste's rational is the policy we have and, IMO, refinement should start at that (policy) level. The process has no doubt accelerated thanks this thread but aside from debug, profile and a few others it's not clear if there are grouping policies that would significantly bridge the gap between our respective goals. It's critical that we look at other distribution's package systems. My count packages on Linux and monolithinc-base FreeBSD desktops is about 2,500 and 700 respectively. Adding 383 base packages (assuming no debug or profile) would push this 28% ratio to 43% of Linux' package count. Of course servers will be different and our FreeBSD package counts would rise from the low to mid 100s to over 600 which is still only 60-70% of the packages on Linux servers I have access to. Having managed Linux systems with 1000 to 3000 packages I can't say that I have real concerns for pkgng in this regard. The package management tools have to scale of course but on a KIS scale more packages = less time spent for a given level of functionality and security (in my experience). I hope we can look forward to some top-level policy suggestions to further refine the base package schema. Roger From owner-freebsd-current@freebsd.org Tue Apr 19 20:46:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B4A0B158A8 for ; Tue, 19 Apr 2016 20:46:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A49D1015 for ; Tue, 19 Apr 2016 20:46:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3JKa2j0013264 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2016 13:36:03 -0700 Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> <76177.1461097581@critter.freebsd.dk> From: Nathan Whitehorn Message-ID: <571696B2.3070100@freebsd.org> Date: Tue, 19 Apr 2016 13:36:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <76177.1461097581@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbPkfqMRaz/oc77CRZrE/sV7G4pMgXKcD3f20FSD59FuE2XZlBHCrXM2zpdBJ54fzKhf1QiJwfngUPMdoWqwWSeH02RpIEOoEA= X-Sonic-ID: C;Tl5gVW4G5hGTCPjNyE/n4w== M;PrKtVW4G5hGTCPjNyE/n4w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:46:15 -0000 On 04/19/16 13:26, Poul-Henning Kamp wrote: > -------- > In message <1461096962.1232.32.camel@freebsd.org>, Ian Lepore writes: > >> Oh yeah, now I remember: Because in freebsd, design is decided by a >> race to commit rather than by discussion. > No, that's not it. > > It is because code talks much louder than words. > This is kind of a silly argument here since the code change is trivial. There is a potentially large impact on the system that merits discussion. Moreover, there is a whole bunch of other code still needs to be written to make this workable in production that depends to some degree on what choices are made here: what does pkg show for these? How do upgrades work? The installer needs modifications to use pkg instead of tar. It's not clear what the migration path to/from a packaged system is, since the packaging is apparently optional. If it would help, I am happy to generate a patch to make the discussion concrete. -Nathan From owner-freebsd-current@freebsd.org Tue Apr 19 20:55:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB966B15AE9 for ; Tue, 19 Apr 2016 20:55:24 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by mx1.freebsd.org (Postfix) with ESMTP id CE15916E9; Tue, 19 Apr 2016 20:55:24 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 29530171D5; Tue, 19 Apr 2016 13:55:18 -0700 (PDT) Date: Tue, 19 Apr 2016 13:55:18 -0700 From: hiren panchasara To: Nathan Whitehorn Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419205518.GC33164@strugglingcoder.info> References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> <76177.1461097581@critter.freebsd.dk> <571696B2.3070100@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VywGB/WGlW4DM4P8" Content-Disposition: inline In-Reply-To: <571696B2.3070100@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:55:25 -0000 --VywGB/WGlW4DM4P8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/19/16 at 01:36P, Nathan Whitehorn wrote: >=20 >=20 > On 04/19/16 13:26, Poul-Henning Kamp wrote: > > -------- > > In message <1461096962.1232.32.camel@freebsd.org>, Ian Lepore writes: > > > >> Oh yeah, now I remember: Because in freebsd, design is decided by a > >> race to commit rather than by discussion. > > No, that's not it. > > > > It is because code talks much louder than words. > > > This is kind of a silly argument here since the code change is trivial.= =20 > There is a potentially large impact on the system that merits=20 > discussion. Moreover, there is a whole bunch of other code still needs=20 > to be written to make this workable in production that depends to some=20 > degree on what choices are made here: what does pkg show for these? How= =20 > do upgrades work? The installer needs modifications to use pkg instead=20 > of tar. It's not clear what the migration path to/from a packaged system= =20 > is, since the packaging is apparently optional. >=20 > If it would help, I am happy to generate a patch to make the discussion= =20 > concrete. Thank you, Nathan. "code wins" is not the correct argument in this discussion, imo. Fwiw, I feel this is one of the sensible threads where things are being discussed without shouting/yelling/shaming. But thats my opinion. Cheers, Hiren --VywGB/WGlW4DM4P8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJXFpszXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lrmMIAJSCZ5q6GqiM6Y3NLKfSpwhF 4T2dWCaX21SYwcAG83n90PwEh0PF5xghFaVIqP5djGeC1X8/bfxZ9Zs0VHQ0AmwV o0qXTdf0bBaqqJCFmsFTqye4EFbPLtvhrI1DJRUDtRCwClnAlL/OhjMZlou3rNiW RkCgYE1VC/YtHY1dk/FTAyFEsnlGm7SvDkt82PXmK91A4VQAu+mMLksiEYNy7mHp yOvxq8IdWc4Qgf+CdutvZSZubL5Hg6+jgNuo7fvnQ+LvTVcO3TQDqTZ0CvhtquPc mjPCkZyLxKc7ZZXGTW5Y4Wx2Onp3ImDdIibOcE8RV2EazkjJUZQLKVY5p82zEuw= =I9Wu -----END PGP SIGNATURE----- --VywGB/WGlW4DM4P8-- From owner-freebsd-current@freebsd.org Tue Apr 19 21:13:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D10FB14370 for ; Tue, 19 Apr 2016 21:13:53 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B13D17A8; Tue, 19 Apr 2016 21:13:52 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ob0-x230.google.com with SMTP id bg3so21860872obb.1; Tue, 19 Apr 2016 14:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=yMCrela1aN2iVokHA407Kc9I8AuzS3xLG4kz3NFJz8I=; b=ETCW8/6K6PnFeS67tVyYXlZNF6rvs9zgmobXTUA13GF4lLDqsJE4QFwBJp7mmNJj4f OkAE3TnLFYMA20V3Bvm7wXTqCBBHeeMPiDXWCXPXwSd9156aFCve1G6g6w6U5Gqva2N9 BSIcmJk37IqyAz0/wStwvZikrrv6Sp4fjNkbEhrxf9OJ9msN6oHtIX9TroUigcG0RXwX PVTsrnfPrhnfBzeH7vKqWgN0ykea4yTl1w1bJ5B8wBI07COQSwzGiI/0GkDZc9l1A5bU VbTh1yWf4MonN1kaCypw4UkwoXSvDtY4vE9gnG/lTx7as4A/KWe/mPc3+ibRl3rkfv7t bmYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=yMCrela1aN2iVokHA407Kc9I8AuzS3xLG4kz3NFJz8I=; b=pCRe5db3nNCQJoaSTrF4bzdDH2OdKqhIdSpWCAAbj0+Vy8srFSU2TkBHldv/46DfIz i3JIIjH73HxYjODAmlvBrBXHFndUf0t8YDkqyX8T5PjQX+dTjUEqPuIO6KOdxmehlcwa 6mUaUOjpk+WR2XYCFkO6hWFUhO40+496AtVoccgaky7q61nmlDaUlxXb+MFg2IBdLVod NDuyo1pNEXoDkRYcQws3Dy7GrjILnrcaxiqvlEmXeVcqiY7bFbEBOuvPXWydckzgdwVA 4lxDJCW+l6QbqtBVh12/czXcxfBSJEvyTLSZcH0UMVP6hbHxzIN/Jg8p+Asm195T9z7w niBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yMCrela1aN2iVokHA407Kc9I8AuzS3xLG4kz3NFJz8I=; b=UtabA50NljPJFKZpbwm+Gb4nvAhRBkv9FFpGyba9eDasoGsTJpWu/KRXpsKKwrVHPJ Dmvn52zfdtPOi1fAQpL+o/iK9fL37MLIVGzRcRBrqSQkjfRNuMTJrQfy92ad5OHXjoKg D+Oq28Q6hfLXFwxFYZZR0oJuGjxCFyV+w1Tb+NJH2j3hFDqU23POyRBf+ERortXAp2Yr hX9y++LLko6vYx0V1br1DTNi81M8qLaUC7SvE1GWfT3Z+AnIyCehyPKGDonGtGWf8Ss7 uypv7AyVoHPCfKmuEXvxcVyujP9QGXmiMBufdhwWhvK5PART6pvMT3iEtPKy21xWbGQv Zr+A== X-Gm-Message-State: AOPr4FWyCVga8pdG/BztIVnNhPAGhd8GB1ufwfJI50g30B4ZGO3qjR+R9YYOmRtGnODrrH4QpsM9KhurYJovAA== MIME-Version: 1.0 X-Received: by 10.60.18.49 with SMTP id t17mr2304237oed.81.1461100432133; Tue, 19 Apr 2016 14:13:52 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.182.33.8 with HTTP; Tue, 19 Apr 2016 14:13:52 -0700 (PDT) In-Reply-To: <571696B2.3070100@freebsd.org> References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> <76177.1461097581@critter.freebsd.dk> <571696B2.3070100@freebsd.org> Date: Tue, 19 Apr 2016 16:13:52 -0500 X-Google-Sender-Auth: ML8rdJpED5TrYUp2etdQy_QuO6c Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: Justin Hibbits To: Nathan Whitehorn Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 21:13:53 -0000 On Tue, Apr 19, 2016 at 3:36 PM, Nathan Whitehorn wrote: > > > On 04/19/16 13:26, Poul-Henning Kamp wrote: >> >> -------- >> In message <1461096962.1232.32.camel@freebsd.org>, Ian Lepore writes: >> >>> Oh yeah, now I remember: Because in freebsd, design is decided by a >>> race to commit rather than by discussion. >> >> No, that's not it. >> >> It is because code talks much louder than words. > If it would help, I am happy to generate a patch to make the discussion > concrete. > -Nathan Please do. Practical is always better than theory, in practice. It's easier to debate on practical grounds. - Justin From owner-freebsd-current@freebsd.org Tue Apr 19 21:34:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5000B14B0C for ; Tue, 19 Apr 2016 21:34:42 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8BB12A8 for ; Tue, 19 Apr 2016 21:34:42 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: by mailman.ysv.freebsd.org (Postfix) id 99F82B14B0A; Tue, 19 Apr 2016 21:34:42 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99ADAB14B09 for ; Tue, 19 Apr 2016 21:34:42 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29EAC12A6 for ; Tue, 19 Apr 2016 21:34:41 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u3JLHoHm079772 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Apr 2016 23:17:52 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u3JLHoL3023206 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 19 Apr 2016 23:17:50 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.15.2/8.15.2/Submit) id u3JLHoPe023205 for current@freebsd.org; Tue, 19 Apr 2016 23:17:50 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Tue, 19 Apr 2016 23:17:50 +0200 From: Wolfgang Zenker To: current Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160419211750.GA22901@lyxys.ka.sub.org> References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> <76177.1461097581@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: private site User-Agent: Mutt/1.6.0 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Tue, 19 Apr 2016 23:17:52 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 21:34:42 -0000 * Adrian Chadd [160419 22:36]: > It's cool. I have positive and negative reactions, and I'm totally > happy to let people try it out at a larger scale and learn from > mistakes. right, thats what we have CURRENT for. Instead of discussing all the things that could theoretically go wrong or make our live easier/more difficult/whatever, let's just try it out and get a feeling for it. Wolfgang From owner-freebsd-current@freebsd.org Tue Apr 19 22:00:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B20A3B139EB for ; Tue, 19 Apr 2016 22:00:18 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9086712D8 for ; Tue, 19 Apr 2016 22:00:18 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8C31AB139EA; Tue, 19 Apr 2016 22:00:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BCDEB139E9 for ; Tue, 19 Apr 2016 22:00:18 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DF6912D6 for ; Tue, 19 Apr 2016 22:00:18 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ob0-x235.google.com with SMTP id bg3so22442185obb.1 for ; Tue, 19 Apr 2016 15:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=s2kctn0z4RTSXj3ClGXXCVpzAxB5r+6SDo+e8hvNCgY=; b=0HzqXMpFBY3RP124bQCK3ua6GkgGJnpw/yKBUfJqfRYhs3ORn0fkBvVKpRyv+oHcEO EpvYqeRBtbDQQCOS4jQLgX1/JQ9eVVSg3ghHwqDCx4/Jdm9ubuWDmGmrek86OIPuCBTC hjuaThZZ0sOrbxcVTWUfAJUBkzeBqM/7y4FbAaiWINL0hvRoxCZ2FLDUlHKf5jW+UrD1 CWHbgHWRHm3U5UV59nFcxYB+/kqoVUtm9+e27hzocFj9jmAiB6L4vVelk+S7LNdelBvq HEwxcgxT51w0Zzm0EKxk+28a7OtHD1dRWJWddW6G0tPqvsRJGsfNHpcacjY7Y42HSaq/ FL3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=s2kctn0z4RTSXj3ClGXXCVpzAxB5r+6SDo+e8hvNCgY=; b=YR6uQU1KKttDxYemqvTdtf9chWA8+pdW4hL4K8X4TNjAwHLlWWBTs7kE508VCqoLj8 I4LMgSKcJbYiSZM8a77UeBgWKTYmFNSWJPUrXU3ralWAl9Vse4nl79K+YjoqqO/PsLAl wVAbSGy4L7g8usHmOYJ9nYZJUWA1WF6ZRwc8TzgrHkBpcgKVhWzzQtnfmB9nv9KFyevH fG5tt5YwWdWl+VdYodUNNN+wzIEvxwe/n2GFlcatBoaUFUawbjPpubiAebl6WDQ5/KR5 nqGkmR+YDnhBvW2F7lKQJQ2r9LfNzJh7zVK9HsxbcXUSBKWJr4HKuTRIM5ZvTA1vEnl9 aDrg== X-Gm-Message-State: AOPr4FXzY/e8Jtq/hPaICFPg4cOO3izsceSjWXSXmR118pKNvon5nukkZrjSPW5jy8zVlL0VUN3u8yiJVFJTJWzM MIME-Version: 1.0 X-Received: by 10.60.98.169 with SMTP id ej9mr2262666oeb.21.1461103217615; Tue, 19 Apr 2016 15:00:17 -0700 (PDT) Sender: sobomax@sippysoft.com Received: by 10.157.43.202 with HTTP; Tue, 19 Apr 2016 15:00:17 -0700 (PDT) In-Reply-To: <20160419211750.GA22901@lyxys.ka.sub.org> References: <76093.1461096570@critter.freebsd.dk> <1461096962.1232.32.camel@freebsd.org> <76177.1461097581@critter.freebsd.dk> <20160419211750.GA22901@lyxys.ka.sub.org> Date: Tue, 19 Apr 2016 15:00:17 -0700 X-Google-Sender-Auth: sSS4X71d22g5d3gEPNvdxwLmQVQ Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: Maxim Sobolev To: portmgr@freebsd.org Cc: current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 22:00:18 -0000 I am sorry to maybe sound like an old grudge here, but can somebody take a sweep at the bug reports filled against ports-mgt/pkg in the last year or so? Packaging base system is surely challenging and exciting task, and great bikesheed topic too, but there are lot of critical bugs in the code that are pretty trivial and easy to fix. I owe at least one and it had no attention whatsoever for a month or so. Almost to the point where I would put my "no response from: maintainer" asbestos on and start checking in some random patches. Searching bigzilla shows that I might not be alone. ( -Max On Tue, Apr 19, 2016 at 2:17 PM, Wolfgang Zenker wrote: > * Adrian Chadd [160419 22:36]: > > It's cool. I have positive and negative reactions, and I'm totally > > happy to let people try it out at a larger scale and learn from > > mistakes. > > right, thats what we have CURRENT for. Instead of discussing all > the things that could theoretically go wrong or make our live > easier/more difficult/whatever, let's just try it out and get > a feeling for it. > > Wolfgang > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Tue Apr 19 22:19:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74320B1423B for ; Tue, 19 Apr 2016 22:19:16 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 2BAE11EF6 for ; Tue, 19 Apr 2016 22:19:15 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id u3JMAA1U027716 for ; Tue, 19 Apr 2016 17:10:10 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (unknown [172.126.77.65]) by mail.shrew.net (Postfix) with ESMTPSA id BE1DA18CC6B for ; Tue, 19 Apr 2016 17:09:59 -0500 (CDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> From: Matthew Grooms Message-ID: <5716AD65.8070007@shrew.net> Date: Tue, 19 Apr 2016 17:12:53 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <76093.1461096570@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Tue, 19 Apr 2016 17:10:10 -0500 (CDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 22:19:16 -0000 On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. > Maybe I missed an email in this thread, but I don't recall anyone completely rejecting the idea of packaging the base system. What I see is a discussion related to doing it in the best way possible. I suspect that most of the negative reactions people are having is due to the line being blurred between the base system and everything else. Historically there has always been a clear distinction. By packaging base and throwing it in with everything else, you erase that distinction. I suspect that if the 'base is different' concept was preserved in a more fundamental way, there would be less resistance. After all, is there that much difference between trusting freebsd-update to patch X files vs trusting pkg to update X packaged files? What if there were two classes of packages, base and general? To interact with a base package set, perhaps an additional command line argument could be required. If you do a 'pkg info' after an install, an empty package set is shown. If you do a 'pkg info --base' ( or whatever ) instead, you see the base package set installed. If you need to get back to just the base system, you run 'pkg delete *' without the --base arg. In other words, base retains it's distinction and pkg pretty much works the same as it does now ( without the new argument ). -Matthew From owner-freebsd-current@freebsd.org Tue Apr 19 22:48:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2ACE0B14B5F for ; Tue, 19 Apr 2016 22:48:02 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 210871E8C; Tue, 19 Apr 2016 22:48:02 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [192.168.42.104] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B64001B78; Tue, 19 Apr 2016 22:48:01 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Matthew Grooms" Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Date: Tue, 19 Apr 2016 20:15:15 -0230 Message-ID: <578E3975-0B03-40BA-AC27-42B9103B61C1@FreeBSD.org> In-Reply-To: <5716AD65.8070007@shrew.net> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 22:48:02 -0000 On 19 Apr 2016, at 19:42, Matthew Grooms wrote: > I suspect that most of the negative reactions people are having is due > to the line being blurred between the base system and everything else. > Historically there has always been a clear distinction. By packaging > base and throwing it in with everything else, you erase that > distinction. I certainly agree that the distinction is changing, but I wouldn't say it's being erased. In fact, I'd argue that a packaged base system will clarify the conversation around the base/not-base dichotomy by forcing us to think about the underlying distinctions rather than of the delivery mechanism. For instance, I'd say that the biggest blurring between base and ports doesn't come from packages, it comes from vendor branches. If the base system is "an atomic, maintained-by-us snapshot of all the stuff you need to get a computer running and bootstrap your applications"... well, first, stop me here if I'm wrong! Assuming I'm not entirely wrong: we have lots of code in base that is "built by the FreeBSD project" and entirely maintained by "us". However, there is also a lot of code in base that comes from an upstream source and is primarily maintained by "them" (who may overlap with "us"), yet is essential to building or using the FreeBSD base system. This is a necessity of modern life (compilers are good), and yet I'm not entirely clear on the distinction between a lightly-patched compiler that lives in our source tree and a lightly-patched compiler that lives in the ports tree. So, now that the base compiler and a ports compiler will be installed using the same tools, it might be worth thinking about how they're really different (if at all). Not that there are any good answers... Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-current@freebsd.org Wed Apr 20 00:49:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE9D7B1398D for ; Wed, 20 Apr 2016 00:49:33 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7994B1976; Wed, 20 Apr 2016 00:49:33 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id g185so37085712ioa.2; Tue, 19 Apr 2016 17:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6vphQgmHfnET+JyJ0TibVd/XsJ9VoxW8O+1jOzC8dfA=; b=UApYXrt4FUt0RvwbDbaG5VEr/07ciktgDab2tTUv0nZxxdH8uEPnVaw/DCqrU94v2p tll+Pyjh+NTnB0uVwaBqctmPW5GQIItoJsi6zQRCZi1Q3Xa40JtgnCaP4G3zyz7MOjRD j8N+kZdPgZE9Sgr1CEbvx3zTzM+/6auU7gsAjpmYIZkIVINPEVlPxd7QTe1RqvtvSneH yADewGl1ZvX5RB7BVM1QgUjvpNon5j7kaqmuWBa49xsAWFrym5aCYEVrbnfItv7ImSGh LYjlesl8xgDgM8b1vzxWTafyZWas8RpAETeWjeIH6AB3mz+aKtT+RLdDLJXCegMWNvEH o4xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6vphQgmHfnET+JyJ0TibVd/XsJ9VoxW8O+1jOzC8dfA=; b=G9yoqtqQnHPrN1VFJowakX237qoNz6S28x7DUKJL8MseMb3NZ254VoFfoQ93zMBN5n ggl9YXVWUJ03FPFgt6rekInvejpMPwOYY8DiWfp3MSkSOc/JhNtAMaagLPZCGM6MTV+2 +J+/Jr4Epl+2hvePUkCBHOViAd4KibS+RzG44NM25ajfjRxKa6QRRFX6f9by+HGC+xw9 VSMvVwfhCw7CF0OWeESY5fBW3wiSh5+SSngulXK/kcnzNYqpjwKg12vCeEQI/z+5w6fF ud4OI5MFvUzW2MKoEYEaoqs/fk6OZOeeSauofoEka0Ge0W1iIZ55iUIf4HAaWQv1xVxv GPrA== X-Gm-Message-State: AOPr4FX4uf4SnOKoRGlECnc/7fmdK9DR+d1FZMOBI+zdAzdn1OYGjYYzDBztL4p8N3+Hrnw6VwnOvxo/i5McSg== X-Received: by 10.107.132.202 with SMTP id o71mr6363575ioi.118.1461113372972; Tue, 19 Apr 2016 17:49:32 -0700 (PDT) MIME-Version: 1.0 References: <1611132.EbTME86UTe@ralph.baldwin.cx> <2291840.VrgKOUFVXv@ralph.baldwin.cx> In-Reply-To: <2291840.VrgKOUFVXv@ralph.baldwin.cx> From: Howard Su Date: Wed, 20 Apr 2016 00:49:23 +0000 Message-ID: Subject: Re: Mis-use of BUS_PASS_ORDER_MIDDLE To: John Baldwin Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 00:49:33 -0000 Can we only load the bus driver that is required by timer or pic? Then you don't need worry about acpi_pci or pcib. John Baldwin =E4=BA=8E2016=E5=B9=B44=E6=9C=8820=E6=97=A5= =E5=91=A8=E4=B8=89 =E4=B8=8A=E5=8D=883:26=E5=86=99=E9=81=93=EF=BC=9A > On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote: > > On Tue, Apr 19, 2016 at 2:53 AM John Baldwin wrote: > > > > > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > > > I noticed several places there are code like this, especially in > some arm > > > > low level drivers. > > > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, > aw_ccu_devclass, > > > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > > > > > =E2=80=8BI feel the usage of BUS_PASS_ORDER_MIDDLE is misused. Ther= e are > another > > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional paramet= er > > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. > > > > > > No, this is actually correct. The _ORDERED variants actually accept = a > > > SI_ORDER_* value to determine how drivers contained in a single .ko > file > > > are registered (in particular if you have several drivers in a .ko fi= le > > > you typically want the "top-most" driver to attach last so that all t= he > > > other drivers are ready once the actual device is attached). > > > > > Why not use _ORDERED here to achieve same thing? _ORDERED(...., > > SI_ORDER_LAST, BUS_PASS_BUS)? > > > > I am thinking to add some macro like BUS_DRIVER_MODULE, > INT_DRIVER_MODULE, > > TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. > If > > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. > > > > I am plan to do is: in autoconf phase, first load timer, int and some > bus, > > etc low level drivers first, then set cold=3D0, then load other driver = to > > work around the problem that driver needs special handling on cold whic= h > is > > not necessary. of course, this may depends on your change of ap_startup= . > > thoughts? > > I would like to get to that, but the path on x86 is a bit messier. Ideal= ly > the order looks something like this: > > - enumerate the tree (BUS_PASS_BUS) > - reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE) > - reserve existing resources that could be moved or disabled if > their is a conflict (think PCI BARs programmed by firmware and/or > doing an initial pass of BARs) > - interrupt controllers (may need resources) (BUS_PASS_INTR) > - timers (probably need resources, need interrupts) (BUS_PASS_TIMER) > > Then all the rest. > > However, it ends up a bit messier on x86 at least. I have a WIP to at > least start doing BUS_PASS_BUS for x86, but I found that I really need > some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended > up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns out > that in some cases we need more granularity than just 'BUS_PASS_xxx'. > > SI_ORDER_* with ORDERED will not help as all the drivers are registered > at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies), > but the device tree is enumerated and attached at SI_SUB_CONFIGURE. > > And yes, the AP startup stuff is a precursor for this. > > -- > John Baldwin > --=20 -Howard From owner-freebsd-current@freebsd.org Wed Apr 20 02:14:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13C45B15F80 for ; Wed, 20 Apr 2016 02:14:27 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 037AB1B04 for ; Wed, 20 Apr 2016 02:14:27 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 02DEDB15F7F; Wed, 20 Apr 2016 02:14:27 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0280EB15F7E for ; Wed, 20 Apr 2016 02:14:27 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id EA0001B03 for ; Wed, 20 Apr 2016 02:14:26 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (c-98-210-156-29.hsd1.ca.comcast.net [98.210.156.29]) by elvis.mu.org (Postfix) with ESMTPSA id 6B791346DE30; Tue, 19 Apr 2016 19:14:26 -0700 (PDT) Subject: Re: [CFT] packaging the base system with pkg(8) To: Poul-Henning Kamp , jbtakk@iherebuywisely.com References: <76093.1461096570@critter.freebsd.dk> Cc: current From: Alfred Perlstein Organization: FreeBSD Message-ID: <5716E601.4030705@freebsd.org> Date: Tue, 19 Apr 2016 19:14:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <76093.1461096570@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 02:14:27 -0000 On 4/19/16 1:09 PM, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. > +1000 -Alfred From owner-freebsd-current@freebsd.org Wed Apr 20 02:36:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58F55B1575B for ; Wed, 20 Apr 2016 02:36:59 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 49731181A for ; Wed, 20 Apr 2016 02:36:59 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: by mailman.ysv.freebsd.org (Postfix) id 45641B15759; Wed, 20 Apr 2016 02:36:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42C10B15757 for ; Wed, 20 Apr 2016 02:36:59 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id C40241819 for ; Wed, 20 Apr 2016 02:36:58 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 31A961EDD5; Wed, 20 Apr 2016 05:36:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Wed, 20 Apr 2016 05:37:00 +0300 From: dan_partelly To: Poul-Henning Kamp Cc: current Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <76093.1461096570@critter.freebsd.dk> References: <76093.1461096570@critter.freebsd.dk> Message-ID: <7bdb565ea95cd3783957f1de6580bf64@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 02:36:59 -0000 On Tue, 19 Apr 2016 20:09:30 +0000, "Poul-Henning Kamp" wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. Your statement, at least as pertaining to this particular exchange, is unfair by any criteria. I dont think anybody in their right mind would oppose the base packaging project, all I seen where concerns regarding the pkg maturity, and how it handles the sheer number of resulting packages. which, if you think a bit, are legitimate concerns, whatever you agree with this stance or not. Yes, it is high time for progress. It is high time that FreeBSD foundation uses a more sizable chunk of the donations it receives to pay for projects bringing progress in FreeBSD.Maybe it is also high time that companies which make millions using BSD OSes (like Juniper) would give something substantial back. Speaking of progress, somebody should take a look at the autoexec.bat system called rc, and pay (foundation money) to have it rewritten in a modern form , which allows service sane service management and a modern fault reporting interface. Have the FreeBSD foundation pay to port those from Solaris. Also, while here, take a good look at the base system , and use same foundation money to ensure you expose in libraries all critical interfaces to the OS. Next, get a decent IPC system (there is already code there for this in the form of Mach ports in NextBSD. Yeah, FreeBSD needs a better way to do IPC that posix and plain unix domain sockets. Code is speaking lauder than words, so please, use the opportunity created by Hubbard and his NextBSD to get a much needed IPC system in FreeBSD. To be fair, it is needed for progress. Lastly, look in a more timely manner to the summer of code projects which might have produced some useful code. Year after year you hear about new GsoC projects, then nothing. I find it hard to bleive that none of those actually produced any useful code. From owner-freebsd-current@freebsd.org Wed Apr 20 03:15:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A2E4B14B0B for ; Wed, 20 Apr 2016 03:15:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 DED731FEA for ; Wed, 20 Apr 2016 03:15:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id 2so39634609ioy.1 for ; Tue, 19 Apr 2016 20:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:from:in-reply-to:date:cc:message-id :references:to; bh=Bf2vBkEBArnTvGLmE6RB1VfBXAvSxRuk3tCDFrznlIk=; b=R7cdd1WKPNWjOBjTlPJ/x0vxUATiqUhnl+VJ+i/V3ASa0AuZKH+GqQ43eOXJNssjEK YALMNht2rPlROP7Ji3R/K46etmeC4H5EBeaeEWTtBFF4axmEilgR3VNN5VYqjOYqQkcy y+HVVOiftSwfo4I5YI86282UanDFaVu9DXAYmVNa4CE7PKAf68gqJvXTsIjSAcBnubSE JNhpBOwbmEas9sFAiT+sB6/Q1VcgYhND4Xd+1hK+7DON3jH9Pcz6Zu8uLpjxfIn8luwY NwbQJI2FIVfVc4/vxnp/8aewr1cr1wdcv5rtUD8peG16OYhu0lc9z8j/thwz5pB/sLo8 sbzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:from:in-reply-to :date:cc:message-id:references:to; bh=Bf2vBkEBArnTvGLmE6RB1VfBXAvSxRuk3tCDFrznlIk=; b=kvq6zkSKR//b7zbUUk80zFdYEGtB8hQ0VW/rzNyGiDMKAVRNouiKezVITshGCHIJ9k 6urzFkzEgTlcnvtYkNDmQfXtmqKavZUd3slT1nPjzHJzQC/YVBTEoIa6VZ2NcVPP+gUE o3bzh7wORCUpYeS+24daTLsewCy+/6qY/BoHP2HUtttULZLFaM0//eVJBIBuLv0f9KVa CMfv1zDgZvkXmQ+2O2X7AdZvrdrHzvttJgAwPdhZw4YolIkM+N/LDLVfd1EEb7iOMBP+ F1qq71ky8fFhX2xMsO0Y7th81ENq/4ru7Z8KEBe7ppZbHA/Z547H2Yp5B/iYHdMXASFt hIzg== X-Gm-Message-State: AOPr4FUi3TP97Z0jIwHGzjdZdwFET/rZ31Cr1PKxcNcZ0/aM+r8uhjV9eSfFaMzmlr05qw== X-Received: by 10.107.37.12 with SMTP id l12mr6757991iol.138.1461122150113; Tue, 19 Apr 2016 20:15:50 -0700 (PDT) Received: from mac-wired.nflx.bsdimp.com ([50.253.99.174]) by smtp.gmail.com with ESMTPSA id 69sm1761237ioo.20.2016.04.19.20.15.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 20:15:49 -0700 (PDT) Sender: Warner Losh Subject: Re: [CFT] packaging the base system with pkg(8) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9B59112F-620A-4CA1-B4E4-D3C52A22C826"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <5716AD65.8070007@shrew.net> Date: Tue, 19 Apr 2016 21:15:47 -0600 Cc: freebsd-current@freebsd.org Message-Id: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> To: Matthew Grooms X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 03:15:51 -0000 --Apple-Mail=_9B59112F-620A-4CA1-B4E4-D3C52A22C826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 19, 2016, at 4:12 PM, Matthew Grooms wrote: >=20 > On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: >> As far as I know, nobody is taking the source code or the Makefiles >> away, so if somebody doesn't like the system being distributed with >> pkg, they can very well roll their own. >>=20 >> It's nice to see the level of enthusiasm the FreeBSD project can >> muster, I just wish it wasn't always enthusiasm for stopping = progress. >>=20 >=20 > Maybe I missed an email in this thread, but I don't recall anyone = completely rejecting the idea of packaging the base system. What I see = is a discussion related to doing it in the best way possible. Sadly the tenor and tone of the discussion isn=E2=80=99t one where = progress is made. The tone has been a bit toxic and demanding, which = grinds people into dust, rather than motivating them to fix things. You = might call it a discussion, but it reads to me more as a bunch of angry = villagers storming the castle. No good can come from that. Tone down the = outrage by a factor of 100 and try to have the conversation again. Warner --Apple-Mail=_9B59112F-620A-4CA1-B4E4-D3C52A22C826 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXFvRjAAoJEGwc0Sh9sBEAdIsQANVvvNwp/eegfAkWPdiJnL0m Wb0F2F9AFyhYOnfspOJmnlxfqEaZBrVZFXyEgYnmq5444cQYWCcpxqBn8rfhqwrO +BvpHuA6ZHH0j+m56aMIbAFcq77s+HQ26k20yL8XD19XjP11cylttnHP5WASVSAQ /4l9PpwR2fI12Wu1hmzdtFlBjl29mODGILOquD7DMGENJ9bRMWTC3Xaj99NKo7ve wWa4Z6axWshurF5K76nvbz/tL+8Lv2XjgBWPegSxAokxvx23AIvcMJhnZJ/ZetAD P/UCWhknRv4+j+Ev00p92Sk5CrIa1HAahn3EVsIe33udHvlVRhFCny6Q8gKM+KXD bSKTZWOXNq5EK18TsP1rwxpAS9RAy05SgzsbtfLMIEnQGmQQMK3FKEk2T7WuVUja SFQdLKI/bXVB9uXjtCiTqgb19tY5XFCKN+ORPmgcmSSIYN36PEp8U/CYeOAXYPcF NSDgYo/ki3DvuBfirh14E2aCpF8s7dOE1yTEL1xRFVkJdYWNGG6zDDee/gIPg3hq LSt4ABALx34R8AT52bb3UM2LhMNbmal8Btu++gimplhKC3O1x5f48YXh7pvyWqlR uHPL2rIiJ1lpA+CqTTBtlQ50E6kaWk2JMxJ7o2VJesxz96mu4vd2wi0AraAF74d7 5HKqEcHRHEBDoZsQ54Al =How5 -----END PGP SIGNATURE----- --Apple-Mail=_9B59112F-620A-4CA1-B4E4-D3C52A22C826-- From owner-freebsd-current@freebsd.org Wed Apr 20 03:41:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E27F8B1543B for ; Wed, 20 Apr 2016 03:41:38 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF8541E10 for ; Wed, 20 Apr 2016 03:41:38 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3K3favx021295 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2016 20:41:36 -0700 Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> From: Nathan Whitehorn Message-ID: <5716FA70.4080604@freebsd.org> Date: Tue, 19 Apr 2016 20:41:36 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVZmpbnmXs9xQamuAKTEzccinDPW8tt1FJUAMA0pCUvqzaVBH4B9RUpUjsGTVvia0zK5FFgGEwyzIWjX5EeG4ehivx5rPIPYAvY= X-Sonic-ID: C;pGxXyKkG5hGqpreqjlfmnQ== M;2FSayKkG5hGqpreqjlfmnQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 03:41:39 -0000 On 04/19/16 20:15, Warner Losh wrote: >> On Apr 19, 2016, at 4:12 PM, Matthew Grooms wrote: >> >> On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: >>> As far as I know, nobody is taking the source code or the Makefiles >>> away, so if somebody doesn't like the system being distributed with >>> pkg, they can very well roll their own. >>> >>> It's nice to see the level of enthusiasm the FreeBSD project can >>> muster, I just wish it wasn't always enthusiasm for stopping progress. >>> >> Maybe I missed an email in this thread, but I don't recall anyone completely rejecting the idea of packaging the base system. What I see is a discussion related to doing it in the best way possible. > Sadly the tenor and tone of the discussion isn’t one where progress is made. The tone has been a bit toxic and demanding, which grinds people into dust, rather than motivating them to fix things. You might call it a discussion, but it reads to me more as a bunch of angry villagers storming the castle. No good can come from that. Tone down the outrage by a factor of 100 and try to have the conversation again. > > Warner Yes, and that tone raises everyone's defensive hackles, which is never good. I'm going to make a patch for a reduced package count and hopefully we can restart this discussion then. It would also be nice to get a statement of what the intended scope of these patches is from some of the people involved in the project. It's a major change to the system and it would be nice to have some kind of architectural document about what is happening. I'm not sure, for instance, what the release for 11 looks like with these changes, what changes need to be made to the installer (something of particular interest to me), how we build install media now that base is no longer self-contained (due to lack of pkg), what specific problems were intended to be solved, how package dependencies work, etc. Something like a few-page white paper would be *really* helpful for those of us who weren't at the BSDcan where this was discussed. Even a wiki page would help a lot. -Nathan From owner-freebsd-current@freebsd.org Wed Apr 20 03:57:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DFE4B15A62 for ; Wed, 20 Apr 2016 03:57:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEA61981; Wed, 20 Apr 2016 03:57:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 24F4A11CA; Wed, 20 Apr 2016 03:57:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 20 Apr 2016 03:57:50 +0000 From: Glen Barber To: Warner Losh Cc: Matthew Grooms , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420035750.GK1554@FreeBSD.org> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NOC/txXbandKISI8" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 03:57:53 -0000 --NOC/txXbandKISI8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2016 at 09:15:47PM -0600, Warner Losh wrote: >=20 > > On Apr 19, 2016, at 4:12 PM, Matthew Grooms wrote: > >=20 > > On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: > >> As far as I know, nobody is taking the source code or the Makefiles > >> away, so if somebody doesn't like the system being distributed with > >> pkg, they can very well roll their own. > >>=20 > >> It's nice to see the level of enthusiasm the FreeBSD project can > >> muster, I just wish it wasn't always enthusiasm for stopping progress. > >>=20 > >=20 > > Maybe I missed an email in this thread, but I don't recall > > anyone completely rejecting the idea of packaging the base system. > > What I see is a discussion related to doing it in the best way > > possible. >=20 > Sadly the tenor and tone of the discussion isn=E2=80=99t one where progre= ss > is made. The tone has been a bit toxic and demanding, which grinds > people into dust, rather than motivating them to fix things. You > might call it a discussion, but it reads to me more as a bunch of > angry villagers storming the castle. No good can come from that. > Tone down the outrage by a factor of 100 and try to have the > conversation again. >=20 As probably the most demotivated person to read through this onslaught of nonsense, I cannot agree more. Glen --NOC/txXbandKISI8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFv46AAoJEAMUWKVHj+KT25MP/3GnBZeIVB6Kw+EVzY3MuU+d fnVfgLHeTU5rZgnttVo3eZ5VTSFiGBoNl/A6prGiuIrwKXIg5UAzdMa+yVIEHE3s xxi5sl+LsYy1FX8FeJ1UDWGBsg89aUwQUHQt2g11T1DlF2cVnCRqWIbJtRsF+Bto 4HjVM0P6h94kIsxOmILkD3j2Bfc9vV3euwyVVbcZFr2CQcGKfN2wiAPedWeb0mfg qAOYBC/nvPWbWto3+U+AUpAnEBXOMOjOaMHiwaYd8Ym7afevYtCq5SwC+/dkP+aN nKnkYyLRO0im6jKxzairc25ZnmdiIZN6x3YtcLTRRqX4E2PYOIh/IXp5mHJ0fH7G nHrcP9xJPAQPzYwVFfNpPI8Gtkf7yij9ysas73tXn/FgGzN8f7ENyvRwERy9yQsZ nIkioljIkwrc1tXRAQz7VW79eVpynY7vhsjCgTXsdj8uMV2JTnS6JyeoFQVaqEfh guKYAkhqfsWEpX81k+c5LDrWKOL31ZAFZ3DXz2neUMvLZo3SKs6WXOSffcFjfHWT c4wuyBwJ61O/yhlsuegRjpPxRCweX12InlSFGVfV7YkfDXSzVT6xMeqQtbLGT2r9 aV53+jCgXd5HMEcDoP17/dAUKDj03Tjp+rwo+94dynzkPY4xaeH/aQnUQySBv4Pc P6MxFFwLKfEVEBObYT7C =ojLo -----END PGP SIGNATURE----- --NOC/txXbandKISI8-- From owner-freebsd-current@freebsd.org Wed Apr 20 03:59:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0AF1B15B17 for ; Wed, 20 Apr 2016 03:59:35 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id AEAE01ADF for ; Wed, 20 Apr 2016 03:59:35 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 3C2DF1F844; Wed, 20 Apr 2016 06:59:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 20 Apr 2016 06:59:38 +0300 From: dan_partelly To: Warner Losh Cc: Matthew Grooms , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 03:59:36 -0000 > > Sadly the tenor and tone of the discussion isn’t one where progress is > made. The tone has been a bit toxic and demanding, which grinds people into > dust, rather than motivating them to fix things. You might call it a > discussion, but it reads to me more as a bunch of angry villagers storming > the castle. No good can come from that. Tone down the outrage by a factor > of 100 and try to have the conversation again. > I'm frankly perplexed by this statement. Its seldom I perceived so much sorrow and bitterness in 6 lines. There is no castle Warner, unless you want one to exist, one where you can isolate yourself from the indentured peasants and anything they say. Beyond your thick walls you'll be well served, every idea outside your wals will be toned down by a factor of 100 by the time it reaches the lord, becoming total agreement with anything the lord thinks. I cant believe I wrote this shit. But then again, I cant believe you just wrote what you did. From owner-freebsd-current@freebsd.org Wed Apr 20 04:01:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E2D9B15C94 for ; Wed, 20 Apr 2016 04:01:35 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DED471DDA for ; Wed, 20 Apr 2016 04:01:34 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u3K41MLd023977 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Apr 2016 22:01:22 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u3K41KPs023974; Tue, 19 Apr 2016 22:01:21 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 19 Apr 2016 22:01:20 -0600 (MDT) From: Warren Block To: Aleksander Alekseev cc: Hans Petter Selasky , FreeBSD Current Subject: Re: qsort() documentation In-Reply-To: <20160419113430.69e41a0b@fujitsu> Message-ID: References: <5714C86A.8050204@selasky.org> <20160419113430.69e41a0b@fujitsu> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 19 Apr 2016 22:01:22 -0600 (MDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:01:35 -0000 On Tue, 19 Apr 2016, Aleksander Alekseev wrote: >> Why Wikipedia, specifically? There are a lot of places that describe >> quicksort. How about just >> >> Note: This implementation of qsort() is designed to avoid the >> worst-case complexity of N**2 that is often seen with standard >> versions. > > I would say that this statement is just false. Worst-case complexity is > still N**2. How about something like: > > """ > This implementation of qsort() has worst case complexity of N**2. > However measures were taken that make it very unlikely that for some > random input N**2 swaps will be made. It's still possible to generate > such an input on purpose though. See code below for more details. > """ Okay: The quicksort algorithm worst-case is O(N**2), but this implementation has been designed to avoid that for most real data. From owner-freebsd-current@freebsd.org Wed Apr 20 04:07:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3BF0B15EAD for ; Wed, 20 Apr 2016 04:07:12 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C3C4F10B9; Wed, 20 Apr 2016 04:07:12 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 6D2DF1475; Wed, 20 Apr 2016 04:07:12 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 20 Apr 2016 04:07:11 +0000 From: Glen Barber To: dan_partelly Cc: Warner Losh , Matthew Grooms , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420040711.GL1554@FreeBSD.org> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AEwMo+oSrT/VEsTd" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:07:12 -0000 --AEwMo+oSrT/VEsTd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: >=20 > >=20 > > Sadly the tenor and tone of the discussion isn=E2=80=99t one where prog= ress is > > made. The tone has been a bit toxic and demanding, which grinds people > into > > dust, rather than motivating them to fix things. You might call it a > > discussion, but it reads to me more as a bunch of angry villagers > storming > > the castle. No good can come from that. Tone down the outrage by a > factor > > of 100 and try to have the conversation again. > >=20 >=20 > I'm frankly perplexed by this statement. Its seldom I perceived so much= =20 > sorrow and bitterness in 6 lines. There is no castle Warner, unless you > want one to exist, one where you can isolate yourself from the indentured= =20 > peasants and anything they say. Beyond your thick walls you'll be well > served, > every idea outside your wals will be toned down by a factor of 100 by the > time > it reaches the lord, becoming total agreement with anything the lord > thinks.=20 >=20 > I cant believe I wrote this shit. But then again, I cant believe you just > wrote > what you did. >=20 And it's responses like this that are severely demotivating. Glen --AEwMo+oSrT/VEsTd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFwBvAAoJEAMUWKVHj+KTJwoP/Aikt22UaBsSJOEOnrJNnJEj zMANtO31sYF+z8X5iDuXd1UVczj4v4a0+IbYaTNse7R5oPA8oE3bNCan+4zS7rLS 8w5IOdUrFNP7pm0zotv5HpgTSmz+2m0jNtCYCurSmm2qNiCuifiF5UP3R6cbtt15 vHeCxwzPZdlXe9gGqb6V/c3tiv/VxFljDJiDge29FxGoOb7Qbte6sEyY76xxq8V2 i3xGd7ttF7lZ/1o4QD5Ys6liEJQ2svPqNVyBWF8a3pmKYKAJPhOXzti/KQifVPPk d5hIXr7uXkDnZ4zPaYmGt/bGfXDwi8yFVWPoLu0BOV0IZqiHP7U0D97JhOoOleLj CnIPZribbzmk8lwwqQ+uQ29VfjDAw6CfyHBwbmzsp/XyT2ef53oOC0te8Ua8gzUY 4tvrDK1SeJXlfQojlp8NIaMz/z7xF5jWcPSjKxhnWcNDQp/yPTws3NAB8+jmlIPF pdv5uHsChaMWyp2elY2jetY2b4E0TRzC9GtuAYSbyph+dFhwXsJ04x95fowSBUUk sg8Wlvc6bA0GbObktXM93zc5totx4H9jVpggKBvyUBkCez444BEKaBMBjcM2AnLt BkPKEiVE1Za8cwhrXLVUFts6CNbNX8++2MfrbFJcjSoJq4I5Mk44gjdLenjuIOZE nC02HduaXZGR364Jtl/c =4ipB -----END PGP SIGNATURE----- --AEwMo+oSrT/VEsTd-- From owner-freebsd-current@freebsd.org Wed Apr 20 04:11:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B274B0D157 for ; Wed, 20 Apr 2016 04:11:42 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0991113A1 for ; Wed, 20 Apr 2016 04:11:41 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3K4BdS8020528 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2016 21:11:40 -0700 Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <20160420040711.GL1554@FreeBSD.org> From: Nathan Whitehorn Message-ID: <5717017B.4070602@freebsd.org> Date: Tue, 19 Apr 2016 21:11:39 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160420040711.GL1554@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVapAnjnxSsK2T1S6s6wunebsZuSsqyiM9CQmPIx7P99oQ+IvlA1m3alRjZCJgsXui8sRbZmshERF5Yze7JT7FhXQSscfrYz+yI= X-Sonic-ID: C;RtRc+60G5hGZwvjNyE/n4w== M;pOe9+60G5hGZwvjNyE/n4w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:11:42 -0000 On 04/19/16 21:07, Glen Barber wrote: > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: >>> Sadly the tenor and tone of the discussion isn’t one where progress is >>> made. The tone has been a bit toxic and demanding, which grinds people >> into >>> dust, rather than motivating them to fix things. You might call it a >>> discussion, but it reads to me more as a bunch of angry villagers >> storming >>> the castle. No good can come from that. Tone down the outrage by a >> factor >>> of 100 and try to have the conversation again. >>> >> I'm frankly perplexed by this statement. Its seldom I perceived so much >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you >> want one to exist, one where you can isolate yourself from the indentured >> peasants and anything they say. Beyond your thick walls you'll be well >> served, >> every idea outside your wals will be toned down by a factor of 100 by the >> time >> it reaches the lord, becoming total agreement with anything the lord >> thinks. >> >> I cant believe I wrote this shit. But then again, I cant believe you just >> wrote >> what you did. >> > And it's responses like this that are severely demotivating. > > Glen > Yes, this is not helpful. Talking about walls and lords and whatever can only make people angry (or demotivated) and is never persuasive. This is really great work; there is a discussion about some nits in how to distribute the results that corresponds to maybe 1% of the total patch. -Nathan From owner-freebsd-current@freebsd.org Wed Apr 20 04:15:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF8BDB0D479 for ; Wed, 20 Apr 2016 04:15:18 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id B4EE417B1; Wed, 20 Apr 2016 04:15:18 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 42BA71FA20; Wed, 20 Apr 2016 07:15:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 20 Apr 2016 07:15:22 +0300 From: dan_partelly To: Glen Barber Cc: Warner Losh , Matthew Grooms , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <20160420040711.GL1554@FreeBSD.org> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <20160420040711.GL1554@FreeBSD.org> Message-ID: <27b37d3f66ba7ac7df7bf3fd2c4ccd88@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:15:19 -0000 On Wed, 20 Apr 2016 04:07:11 +0000, Glen Barber wrote: > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: >> >> > >> > Sadly the tenor and tone of the discussion isn’t one where progress is >> > made. The tone has been a bit toxic and demanding, which grinds people >> into >> > dust, rather than motivating them to fix things. You might call it a >> > discussion, but it reads to me more as a bunch of angry villagers >> storming >> > the castle. No good can come from that. Tone down the outrage by a >> factor >> > of 100 and try to have the conversation again. >> > >> >> I'm frankly perplexed by this statement. Its seldom I perceived so much >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you >> want one to exist, one where you can isolate yourself from the >> indentured >> peasants and anything they say. Beyond your thick walls you'll be well >> served, >> every idea outside your wals will be toned down by a factor of 100 by the >> time >> it reaches the lord, becoming total agreement with anything the lord >> thinks. >> >> I cant believe I wrote this shit. But then again, I cant believe you just >> wrote >> what you did. >> > > And it's responses like this that are severely demotivating. Such statements, such answers. But Im done with this. It degenerates in emotional outbursts, much to the shame of all parts involved. From owner-freebsd-current@freebsd.org Wed Apr 20 04:18:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53C57B0D5DD for ; Wed, 20 Apr 2016 04:18:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BEC01978 for ; Wed, 20 Apr 2016 04:18:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id 2so40616924ioy.1 for ; Tue, 19 Apr 2016 21:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=n6KLXf6G8FKrcghMuz+orGOVRpgpVeNhIUSc4Josld8=; b=BqLFfOKiR4LTR4pFPe/QMIUBNmhJq7ZsGiqCvDT0QxjrE6GTc4gLcQKToWAnIIOmxw QeOks/LurgG6GsSRHRcsiRWr0G2ta0xxga3bgwaAfMx3su5MlkQma4212Uq7j/Zx8pTX oU5agufZasG4Zqd01bABkG72dEahsn+jeLF1RAXz2dfXTFKrl8a0pDKUTzDS+lMPQ0Z+ JI14OrXzVVS0FYuQ62P+iywYNzeAoRHbpUvGRjYNqHYnIzy8C6q/0idoGk/1saGdtzsc gbPptJTEr9v2m0RQdO16dc2EVLZwpzgFoDjelQqSYxi31ebWhR/YZuSb0A0eUe7Paf95 VNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n6KLXf6G8FKrcghMuz+orGOVRpgpVeNhIUSc4Josld8=; b=m3+Jo78TPD5Sc0xI6ZJOvH0q25QUTxUxFHB/pQgj7b1YD/CZjwmqKHPBT65CjoxfyZ iXI/tQZdqfQ5rXJaFu9chdpR1SDmfEdjbvbt+GEpiYeujCisMKmg0bfpKE03UKwyP6vX bLiEb/L/TBLUamF7JBTG+5FlYV0+5+KeoZA+IiqEV6PccT+zMON91dlFitKzPo0qfXLb NwX2JSt3W62OF4PE3K5ARJaucuwcLgsCbi0c4fXAd+RW9ZUh9u4qSFRmZ06+pVY+2L1l FeN4V2Ql4uyb6tI137r4NlKsAti4h7eTe77pHgj7OCS4of2FNJlDRaDh6JJtvyiGCqE1 RItA== X-Gm-Message-State: AOPr4FVRzg+ZIJ5i9Ve5rE2pqIsmLgK0NISHQkkcTItKB6rS2odm9SvxQ5KFc3xwxo1HtY7f9ILWs3zp7y2n0g== MIME-Version: 1.0 X-Received: by 10.107.192.129 with SMTP id q123mr7352184iof.197.1461125899395; Tue, 19 Apr 2016 21:18:19 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Tue, 19 Apr 2016 21:18:19 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> Date: Tue, 19 Apr 2016 22:18:19 -0600 X-Google-Sender-Auth: JdnjtY1C0mFhByhMrhHl9SsBR-M Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: Warner Losh To: dan_partelly Cc: Matthew Grooms , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:18:20 -0000 On Tue, Apr 19, 2016 at 9:59 PM, dan_partelly wrote= : > > > > > Sadly the tenor and tone of the discussion isn=E2=80=99t one where prog= ress is > > made. The tone has been a bit toxic and demanding, which grinds people > into > > dust, rather than motivating them to fix things. You might call it a > > discussion, but it reads to me more as a bunch of angry villagers > storming > > the castle. No good can come from that. Tone down the outrage by a > factor > > of 100 and try to have the conversation again. > > > > I'm frankly perplexed by this statement. Its seldom I perceived so much > sorrow and bitterness in 6 lines. There is no castle Warner, unless you > want one to exist, one where you can isolate yourself from the indentured > peasants and anything they say. Beyond your thick walls you'll be well > served, > every idea outside your wals will be toned down by a factor of 100 by the > time > it reaches the lord, becoming total agreement with anything the lord > thinks. > > I cant believe I wrote this shit. But then again, I cant believe you just > wrote > what you did. > "I've given your response all the consideration that I think it's due. Please have a nice day." Warner From owner-freebsd-current@freebsd.org Wed Apr 20 04:22:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 262DDB0D7FE for ; Wed, 20 Apr 2016 04:22:33 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACFE1DA8; Wed, 20 Apr 2016 04:22:33 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id A8B66181D; Wed, 20 Apr 2016 04:22:32 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 20 Apr 2016 04:22:31 +0000 From: Glen Barber To: dan_partelly Cc: Warner Losh , Matthew Grooms , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420042231.GA5035@FreeBSD.org> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <20160420040711.GL1554@FreeBSD.org> <27b37d3f66ba7ac7df7bf3fd2c4ccd88@rdsor.ro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <27b37d3f66ba7ac7df7bf3fd2c4ccd88@rdsor.ro> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:22:33 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2016 at 07:15:22AM +0300, dan_partelly wrote: > On Wed, 20 Apr 2016 04:07:11 +0000, Glen Barber wrote: > > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: > >>=20 > >> >=20 > >> > Sadly the tenor and tone of the discussion isn=E2=80=99t one where p= rogress > is > >> > made. The tone has been a bit toxic and demanding, which grinds > people > >> into > >> > dust, rather than motivating them to fix things. You might call it a > >> > discussion, but it reads to me more as a bunch of angry villagers > >> storming > >> > the castle. No good can come from that. Tone down the outrage by a > >> factor > >> > of 100 and try to have the conversation again. > >> >=20 > >>=20 > >> I'm frankly perplexed by this statement. Its seldom I perceived so much >=20 > >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you > >> want one to exist, one where you can isolate yourself from the > >> indentured > >> peasants and anything they say. Beyond your thick walls you'll be well > >> served, > >> every idea outside your wals will be toned down by a factor of 100 by > the > >> time > >> it reaches the lord, becoming total agreement with anything the lord > >> thinks.=20 > >>=20 > >> I cant believe I wrote this shit. But then again, I cant believe you > just > >> wrote > >> what you did. > >>=20 > >=20 > > And it's responses like this that are severely demotivating. >=20 > Such statements, such answers. But Im done with this. It degenerates > in emotional outbursts, much to the shame of all parts involved. >=20 You're absolutely right. I apologize for offending you and the countless hours spent on getting this new model correct. What was I thinking? Glen --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFwQHAAoJEAMUWKVHj+KT7kEQAJ8Ol0JI9EhvXx0WsglKcDC3 jvZDG3UMrtuOJsdknnpasZrnfc6/l7tskY80ayIeQu+bSRIHoBcF3NcO/9QkLNCi IE9uKz9KQ5Urx7wXXoKed9ClpgDTeaBK12nKBeoY9muO3foRk8Sa4Bya/kCfkMQE bmeCKCZ2NDNF3dIrGJ1CFxu2SABqZ9FeD2CeyYpdx3CTso3mROHeIVvBqbWAn3Uw kdRSgM4ndw/pBr8yzgo3oOywmDq5coWwCa+iQxguTtScRjRHTUZ+n/kF0clh+0Nu J6n3WjYou1H7cb6a5NOSXDn9X3QICjm4D9EBJdoNNWXLA6ZOdcLFdz0d6rR0TPvL lwPtfmpLe20QdEdIi+a9w29hwxszDMNiNJQKnCT+v+MsPsxrWw7iSLUoZ6F4HpWD s0fn6w1VQPhU6rLKVIIjiUF289Hwk+srIGPkUoLeN15lhNEFoE3RAFbCUBeZU7Xs EiYSrjjDH8KcVuvY/MASh56zKkQYFtXrcTwOfqComFbPKiQ0Ngd12NMbY/L+3SvG jPXFshY/1NnOQEIh8BgRrqzgCjP4ugVatbXCwrvrOX4vS7SZozXOrPdSbJl00tm3 Fv4e8/IDq+MIJhj8V12VrThQ4d01+w5aQkO3D0AuekcahR7lC5rEvEsZk+2BF6Vl j9D0UzjKZqjWP9OkLLuR =1fvl -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-current@freebsd.org Wed Apr 20 04:23:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E156B0D913 for ; Wed, 20 Apr 2016 04:23:50 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 523CD1EEB for ; Wed, 20 Apr 2016 04:23:49 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 890E8DC06E; Wed, 20 Apr 2016 07:23:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Wed, 20 Apr 2016 07:23:53 +0300 From: dan_partelly To: Warner Losh Cc: Matthew Grooms , FreeBSD Current Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> Message-ID: <4e92a9d602e70e305a6f8dd3cb55d632@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:23:50 -0000 > > "I've given your response all the consideration that I think it's due. > Please have > a nice day." Thank you, Warner. Knowing you did, brings warm feelings in my hearth. Please have a nice day. From owner-freebsd-current@freebsd.org Wed Apr 20 04:24:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE1CCB0D9B5 for ; Wed, 20 Apr 2016 04:24:42 +0000 (UTC) (envelope-from current@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3A8102D for ; Wed, 20 Apr 2016 04:24:42 +0000 (UTC) (envelope-from current@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 98F0DB0D9B4; Wed, 20 Apr 2016 04:24:42 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98981B0D9B3 for ; Wed, 20 Apr 2016 04:24:42 +0000 (UTC) (envelope-from current@freebsd.org) Received: from s17162571.onlinehome-server.info (s17162571.onlinehome-server.info [IPv6:2001:8d8:826:2400::e:fa1b]) (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 63214102C for ; Wed, 20 Apr 2016 04:24:42 +0000 (UTC) (envelope-from current@freebsd.org) X-No-Auth: unauthenticated sender Received: from lyrbaxty (s17162571.onlinehome-server.info [127.0.0.1]) by s17162571.onlinehome-server.info (Postfix) with SMTP id A5C503C4D9D for ; Wed, 20 Apr 2016 05:47:06 +0200 (CEST) Message-ID: Reply-To: "ammanakuw-7743@yopmail.com" From: "ammanakuw-7743@yopmail.com" To: Subject: =?utf-8?B?0JrQu9C40LXQvdGC0YHQutC40LUg0LHQsNC30Ysg0YLQ?= =?utf-8?B?tdC7ICs3OTEzMzkxMzgzNyAgU2t5cGU6IHByb2Rhd2V6?= =?utf-8?B?Mzg5ICBFbWFpbDogYW1tYW5ha3V3LTc3NDNAeW9wbWFp?= =?utf-8?B?bC5jb20=?= Date: Wed, 20 Apr 2016 09:47:05 +0600 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Content-Transfer-Encoding: base64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:24:42 -0000 0KHQvtCx0LXRgNC10Lwg0LTQu9GPINCS0LDRgSDQv9C+INC40L3RgtC10YDQvdC10YIg0LHQsNC3 0YMg0LTQsNC90L3Ri9GFINC/0L7RgtC10L3RhtC40LDQu9GM0L3Ri9GFINC60LvQuNC10L3RgtC+ 0LIg0LTQu9GPINCS0LDRiNC10LPQviDQkdC40LfQvdC10YHQsC4NCtCf0L4g0LHQsNC30LUg0LzQ vtC20L3QviDQt9Cy0L7QvdC40YLRjCwg0L/QuNGB0LDRgtGMLCDRgdC70LDRgtGMINGE0LDQutGB 0Ysg0LggZW1haWwsIA0K0LLQtdGB0YLQuCDQu9GO0LHRi9C1INC/0YDRj9C80YvQtSDQsNC60YLQ uNCy0L3Ri9C1INC/0YDQvtC00LDQttC4INCS0LDRiNC40YUg0YLQvtCy0LDRgNC+0LIg0Lgg0YPR gdC70YPQsw0K0KPQt9C90LDQudGC0LUg0L/QvtC00YDQvtCx0L3QtdC1INC/0L4gDQrRgtC10Lsg Kzc5MTMzOTEzODM3ICh3aGF0c2FwcCx2aWJlcix0ZWxlZ3JhbSkgDQpTa3lwZTogcHJvZGF3ZXoz ODkgDQpFbWFpbDogYW1tYW5ha3V3LTc3NDNAeW9wbWFpbC5jb20NCg== From owner-freebsd-current@freebsd.org Wed Apr 20 04:25:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 818EDB0DA7E for ; Wed, 20 Apr 2016 04:25:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 70631117E for ; Wed, 20 Apr 2016 04:25:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6FB41B0DA7B; Wed, 20 Apr 2016 04:25:09 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F60DB0DA79 for ; Wed, 20 Apr 2016 04:25:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58AF7117D for ; Wed, 20 Apr 2016 04:25:08 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 2F648264; Tue, 19 Apr 2016 23:25:02 -0500 (CDT) Date: Tue, 19 Apr 2016 23:25:01 -0500 From: Mark Linimon To: dan_partelly Cc: Poul-Henning Kamp , current Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420042500.GA27553@lonesome.com> References: <76093.1461096570@critter.freebsd.dk> <7bdb565ea95cd3783957f1de6580bf64@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bdb565ea95cd3783957f1de6580bf64@rdsor.ro> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:25:09 -0000 On Wed, Apr 20, 2016 at 05:37:00AM +0300, dan_partelly wrote: > Year after year you hear about new GsoC projects, then nothing. I find > it hard to believe that none of those actually produced any useful code. The goal of GSoC is to introduce new people to FreeBSD more than it is to produce committable code. It's designed as a learning experience. Sometimes, it has the pleasant property of producing code that can be committed without rework, but not that often. mcl From owner-freebsd-current@freebsd.org Wed Apr 20 05:06:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8987DB149CB for ; Wed, 20 Apr 2016 05:06:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7D31959; Wed, 20 Apr 2016 05:06:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-252-92.lns20.per4.internode.on.net [121.45.252.92]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u3K56jPR021216 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2016 22:06:48 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: [CFT] packaging the base system with pkg(8) To: Nathan Whitehorn , freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> From: Julian Elischer Message-ID: <57170E5D.1090701@freebsd.org> Date: Wed, 20 Apr 2016 13:06:37 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5716FA70.4080604@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 05:06:56 -0000 On 20/04/2016 11:41 AM, Nathan Whitehorn wrote: > > > On 04/19/16 20:15, Warner Losh wrote: >>> On Apr 19, 2016, at 4:12 PM, Matthew Grooms >>> wrote: >>> >>> On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: >>>> As far as I know, nobody is taking the source code or the Makefiles >>>> away, so if somebody doesn't like the system being distributed with >>>> pkg, they can very well roll their own. >>>> >>>> It's nice to see the level of enthusiasm the FreeBSD project can >>>> muster, I just wish it wasn't always enthusiasm for stopping >>>> progress. >>>> >>> Maybe I missed an email in this thread, but I don't recall anyone >>> completely rejecting the idea of packaging the base system. What I >>> see is a discussion related to doing it in the best way possible. >> Sadly the tenor and tone of the discussion isn’t one where progress >> is made. The tone has been a bit toxic and demanding, which grinds >> people into dust, rather than motivating them to fix things. You >> might call it a discussion, but it reads to me more as a bunch of >> angry villagers storming the castle. No good can come from that. >> Tone down the outrage by a factor of 100 and try to have the >> conversation again. >> >> Warner > > Yes, and that tone raises everyone's defensive hackles, which is > never good. I'm going to make a patch for a reduced package count > and hopefully we can restart this discussion then. > > It would also be nice to get a statement of what the intended scope > of these patches is from some of the people involved in the project. > It's a major change to the system and it would be nice to have some > kind of architectural document about what is happening. I'm not > sure, for instance, what the release for 11 looks like with these > changes, what changes need to be made to the installer (something of > particular interest to me), how we build install media now that base > is no longer self-contained (due to lack of pkg), what specific > problems were intended to be solved, how package dependencies work, > etc. Something like a few-page white paper would be *really* helpful > for those of us who weren't at the BSDcan where this was discussed. > Even a wiki page would help a lot. > -Nathan > my problem with 400 packages is that is is hard to decide what you are actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? you have no way to tell exactly what you have without comparing all the packages to a known list. uname doesn't mean much, nor does "__FreeBSD_version" if everything comes with its own versions. the 'leaf' concept in pkg helps with this a bit, but we've always considered FreeBSD bas as a sort of monalithic entity that moves forward together. you are running 10.1p8 pr 10.2p1 that tells you all you need to know. If you now need to take into account 400 different dimensions you have a much harder way to describe what you have.. I mentioned this before but I think hte answer is to make a change on the way that "meta packages" are displayed by default in pkg. If I install the meta package, I really don't want to see all the sub packages tat are unchanged unless I add '-v'. On the other hand if I upgrade a sub package I want to see that in the context of the metapackage. Similarly if I uninstall of the subpackages. so something like this would remove most of my objections: # pkg info ===== system packages==== FreeBSD-networking-11.0.2_1 FreeBSD networking subsystem and commands - ipfw-11.0.2-1 ipfw tools (uninstalled) - fbsd-tcpdump-11.0.2-1 Built in tcpdump tools (uninstalled) * openssl-11.0.2-2 Openssl support (upgraded CVE-123456 FreeBSD-base-base-11.0.2-1 The absolute minimum booting base system [...] ==== external packages ====== apache22-2.2.31 Version 2.2.x of Apache web server with prefork MPM. apr-1.5.2.1.5.4 Apache Portability Library autoconf-2.69 Automatically configure source code on many Un*x platforms autoconf-wrapper-20131203 Wrapper script for GNU autoconf [...] Maybe I uninstalled ipfw because I use pf and I install the ports tcpdump so I can remove the built in one. I have installed a new openssl due to a bugfix.. This gives me a real instant feel for what I'm running.. if I add -v then I see all 400 packages, but I really don't want to see them 99.99% of the time I believe the "leaf" method gives close to this but if we could get the above I'd have absolutely no objections. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Wed Apr 20 05:22:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94BD6B15087 for ; Wed, 20 Apr 2016 05:22:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 530E613C1 for ; Wed, 20 Apr 2016 05:22:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u3K5CCZO007717; Wed, 20 Apr 2016 01:12:12 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 20 Apr 2016 01:12:12 -0400 (EDT) Date: Wed, 20 Apr 2016 01:12:12 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: "Russell L. Carter" cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> Message-ID: References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 05:22:50 -0000 On Tue, 19 Apr 2016, Russell L. Carter wrote: > > What is missing from this debate is some perspective from the POV of > actually existing packaging systems. I've been maintaining > debian-stable + debian-testing systems for over 15 years. The number > of packaging glitches I've had I can count on one hand. (I've been > running FreeBSD systems since the *very* beginning.) > > It is much easier to maintain my debian systems than my FreeBSD > systems. Actually, pkg + poudriere is like a dream. Better than > apt-get, actually. Except right now it doesn't maintain the base > system. > > So, how many packages are actually installed on one of my debian > boxes? > > debian-testing box with fvwm (ie no gnome/kde) userland: > > rcarter@aristotle> dpkg --list | wc --lines > 1571 > > FreeBSD-10/stable with the same userland packaged from ports: > > rcarter@feyerabend> pkg info | wc -l > 833 > > The debian system, for basically identical functionality, installs 738 > more packages. Obviously the FreeBSD box has no packages for the base > system, so that is probably a significant part of the difference in > installed packages. And the debian box is dramatically easier to > maintain. I typically will drag a debian box across several debian > release cycles, i.e., 6+ years, w/o ever doing anything more > complicated than doing apt-get update; apt-get dist-upgrade every week > or so. For one of our Solaris 11 boxes, which also serves as a VNC thin client server and NFS server, we have: [sol11] $ pkg list | wc -l 968 That server includes the gnome desktop, firefox, thunderbird, perl, python, wireshark, CDR tools, etc. So arguably, it is comparable to my FreeBSD desktop at home with KDE, firefox, thunderbird, and similar tools. For that FreeBSD box, and just for ports packages (since I don't have base pkg'd): [freebsd11] $ pkg info | wc -l 865 [And it really bothers me that FreeBSD 'pkg list' behaves like 'pkg files' or similar should. It seems intuitive that 'pkg list' should list the packages, not all the files in all the packages.] If you add in 750+ FreeBSD base packages (1600+), that seems like a very large number of packages. And upgrading ports packages is not always painless. For the 865 FreeBSD packages I have installed, only 27 of them are explicit - the rest are dependencies. I do not look forward to updating my packages, even with poudriere. There is usually manual intervention required. So it is with this experience that I do sort of cringe at having 750+ FreeBSD base packages. I do like maintaining Solaris 11 boxes much better with their pkg management, much better than the old patchadm. -- DE From owner-freebsd-current@freebsd.org Wed Apr 20 05:23:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3621CB150F2 for ; Wed, 20 Apr 2016 05:23:35 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2D201663 for ; Wed, 20 Apr 2016 05:23:34 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id k142so30564539oib.1 for ; Tue, 19 Apr 2016 22:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to; bh=dkWuCiZG9Fht7b3yt9TBfOj9K3ZOLZiOSf+yYgrTbfA=; b=oV5o57iblGuN2m/fv240z8TuUR74VGIQixfMu34aclKzY3oS6z1vEV87OQ6xQRY8vS 1bCeatYtk/jhqDDuGup5PfoZW1WtYAWlbv6/0DmYOOJtoMRddYHC9k9P1A8JPBUsod+C 6y4JxKPVwZbMP3adcLJdaF/AyardTnGb5jf1Z/DQ+HZU2DLXomW+VutkK8hs2dXY/iyU hQEBWAryKeZl+veZLM5Xzbqcm+BGcYmgEEET1WbVJZrv3RVdaTFfYgEhmi65bG8NVZuX JQ4hJuX+yt+dzNepgJg8LV/HMYdWhkl50TsRVPZxaRbiOg+DVGcflrbndNYse2I42WQF tlUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to; bh=dkWuCiZG9Fht7b3yt9TBfOj9K3ZOLZiOSf+yYgrTbfA=; b=lmV/i3BIjKiYabkP1CDVSZA0ZzaH9LuFvu/l5Kde3jSp/1nTVM4FyR4iuKbJT/ftsp G2sAXEKnOrZnj2JK6vvEkzAYWPi4jGzbQiGt/QTBF2DVif0j4c/SMNbwuztLVVGoIBWD HcJ8PlPOtOcQpu4Xv8dmRwWhnfsnplss+jS+JDCVM4hyYLyDfGzugtqAtELRrWyV2rhr 8FSSs0P40wwPlUrFJoiJWbWx0sW6p22VLtYh0EX83GmIUV3CA79HiT/PerqIcV6YDC35 /81m3NG+/fsREGDiEtGzJLenCMrmWYp8qgJZTrn48Smvv683gEsg9ASD+n8mS9rwwhUv q5Pg== X-Gm-Message-State: AOPr4FVnKQ+r+ZS2lEVmAXlMxqYHFMxlisB9mpfMEPp1YfCzGsDFt1mxMkFwTUGWsoN/ma998iqsXkBrmkHEdg== MIME-Version: 1.0 X-Received: by 10.157.13.98 with SMTP id 89mr3156908oti.194.1461129814190; Tue, 19 Apr 2016 22:23:34 -0700 (PDT) Received: by 10.182.156.65 with HTTP; Tue, 19 Apr 2016 22:23:34 -0700 (PDT) Reply-To: araujo@FreeBSD.org Date: Wed, 20 Apr 2016 13:23:34 +0800 Message-ID: Subject: Use MAX()/MIN() macros in world. From: Marcelo Araujo To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 05:23:35 -0000 Hey, As there is a kind of effort to clean up and do some cosmetic changes in our source base. I'm wondering if there is any objection to switch some codes to use MAX() and MIN() macros from sys/param.h. It will simplify code(readable), most of changes will be cosmetic changes and not functional. Thoughts? Best, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-current@freebsd.org Wed Apr 20 05:27:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4334B15621 for ; Wed, 20 Apr 2016 05:27:46 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2E42197B; Wed, 20 Apr 2016 05:27:46 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u3K5Rjnc014446; Wed, 20 Apr 2016 01:27:45 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 20 Apr 2016 01:27:45 -0400 (EDT) Date: Wed, 20 Apr 2016 01:27:45 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Julian Elischer cc: Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <57170E5D.1090701@freebsd.org> Message-ID: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 05:27:47 -0000 On Wed, 20 Apr 2016, Julian Elischer wrote: > > my problem with 400 packages is that is is hard to decide what you are > actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? > you have no way to tell exactly what you have without comparing all the > packages to a known list. > uname doesn't mean much, nor does "__FreeBSD_version" if everything comes > with its own versions. And perhaps I missed it in the large number of missives on pkg'ing base, but we should be able to list just base packages or host port packages. I don't know if that is on or off the table. > the 'leaf' concept in pkg helps with this a bit, but we've always considered > FreeBSD bas as a sort of monalithic entity that moves forward together. > > you are running 10.1p8 pr 10.2p1 that tells you all you need to know. > If you now need to take into account 400 different dimensions you have a much > harder way to describe what you have.. Solaris base packages seem to use the OS version in their pkg version number, for instance: sol11 $ pkg list | grep 0.5.11 | grep system/library system/library 0.5.11-0.175.3.1.0.3.0 system/library/boot-management 0.5.11-0.175.3.0.0.30.0 system/library/c++-runtime 0.5.11-0.175.3.0.0.24.0 system/library/c++/sunpro 0.5.11-0.168 system/library/iconv/unicode-core 0.5.11-0.175.3.0.0.26.2 system/library/iconv/utf-8 0.5.11-0.175.3.0.0.26.2 system/library/install 0.5.11-0.175.3.0.0.30.0 system/library/install/libinstzones 0.5.11-0.175.3.0.0.30.0 system/library/liblayout 0.5.11-0.175.3.0.0.26.2 system/library/libv12n 0.5.11-0.175.3.0.0.30.0 system/library/math 0.5.11-0.175.3.0.0.19.0 system/library/mmheap 0.5.11-0.175.3.0.0.7.0 system/library/openmp 0.5.11-0.175.3.0.0.2.0 system/library/platform 0.5.11-0.175.3.0.0.30.0 system/library/policykit 0.5.11-0.175.3.0.0.30.0 system/library/processor 0.5.11-0.175.3.0.0.30.0 system/library/security/crypto 0.5.11-0.175.3.1.0.4.0 system/library/security/gss 0.5.11-0.175.3.0.0.30.0 system/library/security/gss/diffie-hellman 0.5.11-0.175.3.0.0.30.0 system/library/security/gss/spnego 0.5.11-0.175.3.0.0.30.0 system/library/security/libsasl 0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11 0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11_kernel 0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11_softtoken 0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11_tpm 0.5.11-0.175.3.0.0.30.0 system/library/security/rpcsec 0.5.11-0.175.3.0.0.30.0 system/library/storage/libdiskmgt 0.5.11-0.175.3.0.0.30.0 system/library/storage/libfcoe 0.5.11-0.175.3.0.0.30.0 system/library/storage/scsi-plugins 0.5.11-0.175.3.0.0.30.0 system/library/storage/snia-hbaapi 0.5.11-0.175.3.0.0.30.0 system/library/storage/snia-ima 0.5.11-0.175.3.0.0.30.0 system/library/storage/snia-mpapi 0.5.11-0.175.3.0.0.30.0 system/library/storage/suri 0.5.11-0.175.3.0.0.30.0 system/library/storage/t11-sm-hba 0.5.11-0.175.3.0.0.30.0 system/library/usb/libusb 0.5.11-0.175.3.0.0.30.0 system/library/usb/libusbugen 0.5.11-0.175.3.0.0.30.0 That's Solaris 11.3. I'm assuming the 5.11 is Solaris 11 and the 175.3 is the .3 update. The remaining digits must be the package versions. -- DE From owner-freebsd-current@freebsd.org Wed Apr 20 05:31:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD9D4B15741 for ; Wed, 20 Apr 2016 05:31:03 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 836DD1B0B for ; Wed, 20 Apr 2016 05:31:02 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id EC3F5DB72 for ; Wed, 20 Apr 2016 05:30:55 +0000 (UTC) Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> From: Allan Jude Message-ID: <5717140F.7040808@freebsd.org> Date: Wed, 20 Apr 2016 01:30:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 05:31:03 -0000 On 2016-04-20 01:12, Daniel Eischen wrote: > On Tue, 19 Apr 2016, Russell L. Carter wrote: >> >> What is missing from this debate is some perspective from the POV of >> actually existing packaging systems. I've been maintaining >> debian-stable + debian-testing systems for over 15 years. The number >> of packaging glitches I've had I can count on one hand. (I've been >> running FreeBSD systems since the *very* beginning.) >> >> It is much easier to maintain my debian systems than my FreeBSD >> systems. Actually, pkg + poudriere is like a dream. Better than >> apt-get, actually. Except right now it doesn't maintain the base >> system. >> >> So, how many packages are actually installed on one of my debian >> boxes? >> >> debian-testing box with fvwm (ie no gnome/kde) userland: >> >> rcarter@aristotle> dpkg --list | wc --lines >> 1571 >> >> FreeBSD-10/stable with the same userland packaged from ports: >> >> rcarter@feyerabend> pkg info | wc -l >> 833 >> >> The debian system, for basically identical functionality, installs 738 >> more packages. Obviously the FreeBSD box has no packages for the base >> system, so that is probably a significant part of the difference in >> installed packages. And the debian box is dramatically easier to >> maintain. I typically will drag a debian box across several debian >> release cycles, i.e., 6+ years, w/o ever doing anything more >> complicated than doing apt-get update; apt-get dist-upgrade every week >> or so. > > For one of our Solaris 11 boxes, which also serves as a VNC > thin client server and NFS server, we have: > > [sol11] $ pkg list | wc -l > 968 > > That server includes the gnome desktop, firefox, thunderbird, > perl, python, wireshark, CDR tools, etc. So arguably, it is > comparable to my FreeBSD desktop at home with KDE, firefox, > thunderbird, and similar tools. For that FreeBSD box, and > just for ports packages (since I don't have base pkg'd): > > [freebsd11] $ pkg info | wc -l > 865 > > [And it really bothers me that FreeBSD 'pkg list' behaves > like 'pkg files' or similar should. It seems intuitive > that 'pkg list' should list the packages, not all the files > in all the packages.] > > If you add in 750+ FreeBSD base packages (1600+), that seems > like a very large number of packages. And upgrading ports > packages is not always painless. For the 865 FreeBSD packages > I have installed, only 27 of them are explicit - the rest are > dependencies. I do not look forward to updating my packages, > even with poudriere. There is usually manual intervention > required. So it is with this experience that I do sort of > cringe at having 750+ FreeBSD base packages. > > I do like maintaining Solaris 11 boxes much better with their > pkg management, much better than the old patchadm. > does 'pkg prime-list' give you watch you are looking for? (pkgs you explicitly installed) -- Allan Jude From owner-freebsd-current@freebsd.org Wed Apr 20 06:26:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38A45B154AD for ; Wed, 20 Apr 2016 06:26:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4E011110; Wed, 20 Apr 2016 06:25:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u3K6Pvi6034275; Wed, 20 Apr 2016 02:25:57 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 20 Apr 2016 02:25:57 -0400 (EDT) Date: Wed, 20 Apr 2016 02:25:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Allan Jude cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <5717140F.7040808@freebsd.org> Message-ID: References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> <5717140F.7040808@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:26:00 -0000 On Wed, 20 Apr 2016, Allan Jude wrote: > On 2016-04-20 01:12, Daniel Eischen wrote: >> >> For one of our Solaris 11 boxes, which also serves as a VNC >> thin client server and NFS server, we have: >> >> [sol11] $ pkg list | wc -l >> 968 >> >> That server includes the gnome desktop, firefox, thunderbird, >> perl, python, wireshark, CDR tools, etc. So arguably, it is >> comparable to my FreeBSD desktop at home with KDE, firefox, >> thunderbird, and similar tools. For that FreeBSD box, and >> just for ports packages (since I don't have base pkg'd): >> >> [freebsd11] $ pkg info | wc -l >> 865 >> >> [And it really bothers me that FreeBSD 'pkg list' behaves >> like 'pkg files' or similar should. It seems intuitive >> that 'pkg list' should list the packages, not all the files >> in all the packages.] >> >> If you add in 750+ FreeBSD base packages (1600+), that seems >> like a very large number of packages. And upgrading ports >> packages is not always painless. For the 865 FreeBSD packages >> I have installed, only 27 of them are explicit - the rest are >> dependencies. I do not look forward to updating my packages, >> even with poudriere. There is usually manual intervention >> required. So it is with this experience that I do sort of >> cringe at having 750+ FreeBSD base packages. >> >> I do like maintaining Solaris 11 boxes much better with their >> pkg management, much better than the old patchadm. >> > > does 'pkg prime-list' give you watch you are looking for? (pkgs you > explicitly installed) pkg prime-list does show the explicitly installed packages, not sure how one would know to use 'prime-list' since it doesn't appear in any of the man pages (looking at FreeBSD 10-stable right now). And it doesn't show version information, nor other option arguments that I can tell. pkg help prime-list says it's just an alias for "query -e '%a = 0' '%n'". Seems like "query -e '%a = 0' '%n\t%v\t%o'" is a little nicer, though I'm not sure how to get all the columns to line up nicely. -- DE From owner-freebsd-current@freebsd.org Wed Apr 20 06:31:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA1D6B15640 for ; Wed, 20 Apr 2016 06:31:12 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8488714AA; Wed, 20 Apr 2016 06:31:12 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id C3A544F57A; Wed, 20 Apr 2016 06:31:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u3K6V9Pp092940; Wed, 20 Apr 2016 06:31:09 GMT (envelope-from phk@phk.freebsd.dk) To: araujo@FreeBSD.org, Marcelo Araujo cc: freebsd-current Subject: Re: Use MAX()/MIN() macros in world. In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92938.1461133869.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2016 06:31:09 +0000 Message-ID: <92939.1461133869@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:31:12 -0000 -------- In message , Marcelo Araujo writes: >I'm wondering if there is any objection to switch some codes to use MAX() >and MIN() macros from sys/param.h. IMO We shouldn't pollute with sys/param.h just for a couple of macros. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Wed Apr 20 06:34:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 133B9B157DC for ; Wed, 20 Apr 2016 06:34:28 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD8F918DA for ; Wed, 20 Apr 2016 06:34:27 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id r78so31767391oie.0 for ; Tue, 19 Apr 2016 23:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=syQ193e/PD4D6tQpY9NqsFDnk++7NIfUuCkCi6LTRbE=; b=wyI63fsIiMq5Jtu4hbuFDvXuZOuhxUmeo14mNHzdzilR6Pvq0r5bC3I/0cN7Yb7THL 5k8+89vh/LzLd4Csd9UtQLgHJYGH6FFqh0cs0O2qRs0usCgOVdw5i5Jvu9u801KMvIRo /3/GkBkXmGGfes3z+WG0hFvXToOrGkrAOtuetNNL7QUtFEhLrk3FUPY6ooOFNfozw+LN 4t4nKYC++G5zMkNxdSROWvWUCmCY8Ym/sM77TSaghf9cDnpo7VuGyf1iDTcSFlp96HBw 8KOQU708R+hhiCgNzVsvNw+JhaGGmcdZvg17cVSujXYk9hLrMZxFDfbasPck803SbIM5 uxCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=syQ193e/PD4D6tQpY9NqsFDnk++7NIfUuCkCi6LTRbE=; b=LU92QCxm1AI4++m9meAlzyi1p6tVOH4geg5rJsZSUBIRFM9x9RDmdsx0gbq2yaQQf2 h6UkaOEqUJV14QKD6RWG4NtsEa82DNFoOpWeV7JdmY3dkzoZd2lmrubUXhEvIWX1sxRJ DOXk6QJVoQsgPJbKFlAmYSC1+UmSs6nQRfCRmnLiW2vDMMLWlDgMRkcgdijW/G776mxJ vCYtdRZ1UXcjXGzw8sQ9Fpx+XFNhtuik0zeXA/I6VTz10oJDfyPux9HHidi/cN92ky3t unG/UoZP1YwFReUZj7fORj0Qo+/gotJiXl/7ikcMs0663oD3ATSWG9vyOetIrD1uGL6B +ltA== X-Gm-Message-State: AOPr4FUxbfNYaEi356PimEy0QA0LBqfAC54sFjF3/5oIIWutAquLRMHiq3cNxONr+hTSMnDiwN0AT7nzNE7DWw== MIME-Version: 1.0 X-Received: by 10.202.86.145 with SMTP id k139mr1391396oib.105.1461134067155; Tue, 19 Apr 2016 23:34:27 -0700 (PDT) Received: by 10.182.156.65 with HTTP; Tue, 19 Apr 2016 23:34:27 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <92939.1461133869@critter.freebsd.dk> References: <92939.1461133869@critter.freebsd.dk> Date: Wed, 20 Apr 2016 14:34:27 +0800 Message-ID: Subject: Re: Use MAX()/MIN() macros in world. From: Marcelo Araujo To: Poul-Henning Kamp Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:34:28 -0000 2016-04-20 14:31 GMT+08:00 Poul-Henning Kamp : > -------- > In message DP5k1vxfZ7umKVhb-a_1M4FembpTf5mgHfQdDydQA@mail.gmail.com> > , Marcelo Araujo writes: > > >I'm wondering if there is any objection to switch some codes to use MAX() > >and MIN() macros from sys/param.h. > > IMO We shouldn't pollute with sys/param.h just for a couple of macros. > > All codes that I mention they do have already sys/param.h included. Best, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-current@freebsd.org Wed Apr 20 06:38:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82CAFB15993 for ; Wed, 20 Apr 2016 06:38:38 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 436F31AB2; Wed, 20 Apr 2016 06:38:38 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aslmX-0005ls-Lb; Wed, 20 Apr 2016 09:38:37 +0300 Date: Wed, 20 Apr 2016 09:38:37 +0300 From: Slawa Olhovchenkov To: Glen Barber Cc: dan_partelly , Warner Losh , Matthew Grooms , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420063837.GI6614@zxy.spb.ru> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <20160420040711.GL1554@FreeBSD.org> <27b37d3f66ba7ac7df7bf3fd2c4ccd88@rdsor.ro> <20160420042231.GA5035@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160420042231.GA5035@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:38:38 -0000 On Wed, Apr 20, 2016 at 04:22:31AM +0000, Glen Barber wrote: > On Wed, Apr 20, 2016 at 07:15:22AM +0300, dan_partelly wrote: > > On Wed, 20 Apr 2016 04:07:11 +0000, Glen Barber wrote: > > > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: > > >> > > >> > > > >> > Sadly the tenor and tone of the discussion isn’t one where progress > > is > > >> > made. The tone has been a bit toxic and demanding, which grinds > > people > > >> into > > >> > dust, rather than motivating them to fix things. You might call it a > > >> > discussion, but it reads to me more as a bunch of angry villagers > > >> storming > > >> > the castle. No good can come from that. Tone down the outrage by a > > >> factor > > >> > of 100 and try to have the conversation again. > > >> > > > >> > > >> I'm frankly perplexed by this statement. Its seldom I perceived so much > > > > >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you > > >> want one to exist, one where you can isolate yourself from the > > >> indentured > > >> peasants and anything they say. Beyond your thick walls you'll be well > > >> served, > > >> every idea outside your wals will be toned down by a factor of 100 by > > the > > >> time > > >> it reaches the lord, becoming total agreement with anything the lord > > >> thinks. > > >> > > >> I cant believe I wrote this shit. But then again, I cant believe you > > just > > >> wrote > > >> what you did. > > >> > > > > > > And it's responses like this that are severely demotivating. > > > > Such statements, such answers. But Im done with this. It degenerates > > in emotional outbursts, much to the shame of all parts involved. > > > > You're absolutely right. > > I apologize for offending you and the countless hours spent on getting > this new model correct. > > What was I thinking? Glen, you do hard work and we much appreciated to you. But some don't have fluent english, for examle, I, and I can't create political sentense on english, restrict to pithy and informative sentense. Also, I am to long work with many comercial vendors and have some deformation, for example, when introductin new feature and don't provide direct promise of save old competition functionality -- in near, very near future this functionality will be removed. Please, do direct promise and describe you vision. We only see you commit and nothing more, this is too smal and we worry. Yes, now 11 is -current. But after mont -- this is STABLE and nothing to change w/o POLA violation! Price of flaw now very high (for project in first case). Yes, FreeBSD need new model for update and upgrade. But this tool implemented once have long impact and need have compatible more then base system. I am want cool FreeBSD and try to help this, by my expirens in system maintenance (not only FreeBSD). My expirense talk: change is very expensive. May be need do not put 11 to stable. Or may be schedule to some month. Or except this suvsystem from POLA. I am don't know. What you vision? What main distribution will be used in 11-RELEASE? What status will be have base packaging in 11? From owner-freebsd-current@freebsd.org Wed Apr 20 06:41:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3855CB15AA5 for ; Wed, 20 Apr 2016 06:41:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 01E3F1D7A for ; Wed, 20 Apr 2016 06:41:53 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 884D41FE024; Wed, 20 Apr 2016 08:41:44 +0200 (CEST) Subject: Re: qsort() documentation To: Warren Block , Aleksander Alekseev , FreeBSD Current References: <5714C86A.8050204@selasky.org> <20160419113430.69e41a0b@fujitsu> From: Hans Petter Selasky Message-ID: <5717256C.5080805@selasky.org> Date: Wed, 20 Apr 2016 08:45:00 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:41:54 -0000 On 04/20/16 06:01, Warren Block wrote: > On Tue, 19 Apr 2016, Aleksander Alekseev wrote: > >>> Why Wikipedia, specifically? There are a lot of places that describe >>> quicksort. How about just >>> >>> Note: This implementation of qsort() is designed to avoid the >>> worst-case complexity of N**2 that is often seen with standard >>> versions. >> >> I would say that this statement is just false. Worst-case complexity is >> still N**2. How about something like: >> >> """ >> This implementation of qsort() has worst case complexity of N**2. >> However measures were taken that make it very unlikely that for some >> random input N**2 swaps will be made. It's still possible to generate >> such an input on purpose though. See code below for more details. >> """ > > Okay: > > The quicksort algorithm worst-case is O(N**2), but this implementation > has been designed to avoid that for most real data. Hi, There is something which I don't understand. Why is quicksort falling back to insertion sort which is an O(N**2) algorithm, when there exist a O(log(N)*log(N)*N) algorithms, which I propose as a solution to the "bad" characteristics of qsort. The replacement algorithm I propose does not allocate working memory and it does not recurse and it does not use a significant amount of stack space. Maybe some number theorists want to have a look? I cannot seem to find it anywhere public. See here: https://reviews.freebsd.org/D5241 Local test results w/D5241 running statically in userspace: > Data set size log2(N) qsort w/insert sort qsort w/hpsort mergesort data set > 10 1.28 1.12 1.34 random0 > 11 2.42 2.43 2.83 random0 > 12 5.21 5.2 6.1 random0 > > 10 1.26 1.14 1.44 random1 > 11 2.46 2.46 3.05 random1 > 12 5.28 5.29 6.56 random1 > > 10 10.01 5.1 0.2 bad0 > 11 39.12 12.11 0.33 bad0 > 12 156.54 28.42 0.58 bad0 New algorithm is in the middle column. Times are in seconds. Bad0 data set: > http://calmerthanyouare.org/2014/06/11/algorithmic-complexity-attacks-and-libc-qsort.html --HPS From owner-freebsd-current@freebsd.org Wed Apr 20 06:54:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E530B15F58 for ; Wed, 20 Apr 2016 06:54:19 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D2C512BF; Wed, 20 Apr 2016 06:54:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-252-92.lns20.per4.internode.on.net [121.45.252.92]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u3K6sDZY021685 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2016 23:54:16 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: [CFT] packaging the base system with pkg(8) To: Daniel Eischen , Allan Jude References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> <5717140F.7040808@freebsd.org> Cc: freebsd-current@freebsd.org From: Julian Elischer Message-ID: <5717278F.7030507@freebsd.org> Date: Wed, 20 Apr 2016 14:54:07 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:54:19 -0000 On 20/04/2016 2:25 PM, Daniel Eischen wrote: > On Wed, 20 Apr 2016, Allan Jude wrote: > >> On 2016-04-20 01:12, Daniel Eischen wrote: >>> >>> For one of our Solaris 11 boxes, which also serves as a VNC >>> thin client server and NFS server, we have: >>> >>> [sol11] $ pkg list | wc -l >>> 968 >>> >>> That server includes the gnome desktop, firefox, thunderbird, >>> perl, python, wireshark, CDR tools, etc. So arguably, it is >>> comparable to my FreeBSD desktop at home with KDE, firefox, >>> thunderbird, and similar tools. For that FreeBSD box, and >>> just for ports packages (since I don't have base pkg'd): >>> >>> [freebsd11] $ pkg info | wc -l >>> 865 >>> >>> [And it really bothers me that FreeBSD 'pkg list' behaves >>> like 'pkg files' or similar should. It seems intuitive >>> that 'pkg list' should list the packages, not all the files >>> in all the packages.] >>> >>> If you add in 750+ FreeBSD base packages (1600+), that seems >>> like a very large number of packages. And upgrading ports >>> packages is not always painless. For the 865 FreeBSD packages >>> I have installed, only 27 of them are explicit - the rest are >>> dependencies. I do not look forward to updating my packages, >>> even with poudriere. There is usually manual intervention >>> required. So it is with this experience that I do sort of >>> cringe at having 750+ FreeBSD base packages. >>> >>> I do like maintaining Solaris 11 boxes much better with their >>> pkg management, much better than the old patchadm. >>> >> >> does 'pkg prime-list' give you watch you are looking for? (pkgs you >> explicitly installed) > > pkg prime-list does show the explicitly installed packages, > not sure how one would know to use 'prime-list' since it > doesn't appear in any of the man pages (looking at FreeBSD > 10-stable right now). And it doesn't show version information, > nor other option arguments that I can tell. pkg help prime-list > says it's just an alias for "query -e '%a = 0' '%n'". Seems > like "query -e '%a = 0' '%n\t%v\t%o'" is a little nicer, > though I'm not sure how to get all the columns to line up > nicely. equally missing from help is 'pkg leaf' These show that information needed is available.. it just needs to be presented right. From owner-freebsd-current@freebsd.org Wed Apr 20 07:05:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58141B1445A for ; Wed, 20 Apr 2016 07:05:49 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (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 DB5DE19D6 for ; Wed, 20 Apr 2016 07:05:48 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (liminal.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3636:3bff:fed4:b0d6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 23F50114B1 for ; Wed, 20 Apr 2016 07:05:44 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/23F50114B1; dkim=none; dkim-atps=neutral Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> From: Matthew Seaman Message-ID: <57172A41.4090306@FreeBSD.org> Date: Wed, 20 Apr 2016 08:05:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dSuDCfsfQ3OVp76C50c8QQVJW3liXqgCx" X-Virus-Scanned: clamav-milter 0.99.1 at smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 07:05:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dSuDCfsfQ3OVp76C50c8QQVJW3liXqgCx Content-Type: multipart/mixed; boundary="DPW07pOfsp0j2EeOwa5nNk1Ii5oPobCNd" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <57172A41.4090306@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190201.u3J216NQ054020@orthanc.ca> <5715968B.303@orthanc.ca> <5715A338.5060009@freebsd.org> <57165C91.7070005@freebsd.org> <57166870.5060104@FreeBSD.org> <201604191755.u3JHtbfS020358@l.mx.sonic.net> <5716775A.2000401@freebsd.org> <5d0fa087-e04a-f775-676c-cc81fdf6c0ab@pinyon.org> In-Reply-To: --DPW07pOfsp0j2EeOwa5nNk1Ii5oPobCNd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 20/04/2016 06:12, Daniel Eischen wrote: > [And it really bothers me that FreeBSD 'pkg list' behaves > like 'pkg files' or similar should. It seems intuitive > that 'pkg list' should list the packages, not all the files > in all the packages.] 'pkg list' is one of the aliases defined in the default pkg.conf -- if you want to rename it to 'pkg files' that's trivially easy. If there's any sort of consensus that 'pkg files' would be preferable in general then I'm sure that the sample pkg.conf can be fixed in git. Cheers, Matthew --DPW07pOfsp0j2EeOwa5nNk1Ii5oPobCNd-- --dSuDCfsfQ3OVp76C50c8QQVJW3liXqgCx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJXFypHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATT1AP/ilYBF6U+ccBeQV0yISvzkO9 HSu9a4gEA7buYSYDh8PM1cWFmbfbz+2+5dnZwsBd1NIvJD5oWoY5fRY5rYOgqqaf S9nan5la+Xpy+nO13tbbf8MkhY+NRZ+5WVnZ7vVTYwNQ5l4vDVefNt6xETp4gi4P pA+Y6ySLRpDDw7a5D1KeCgyPJNQyDLTsRJNhUiv3zFvQ2v5cFrjk+u9oe7JnmTXS UOwwnLnytRCG1aVVybHQN5eWcBC6IAaNXJdr6iy4cuBGAKuwE1TUheULSHHu/ls7 L8p1XWBzrnM2wirUvyyQJi+iOgyS1wOGE0PxyUnL174laWssjtlP2FhWadjhf3de 2BtF1fNkkgP56qeeuNL45uu56sG2RBIAla8khyrMBKcKk5nd6vzvO9vxFYwwH+8R Y4/KFwEsjEUTGMZIuQyvKwzhxQb7PF4j/jwJ9hAzI/2qcCIlhp7sy3PaKs254MZ0 /wB0nLN1V+3KXPChhpQ4/2/3W2Z/LAC/t/lnoL+D7YNXQbJC3i3STu6X7GqrRPae 02JaZE7TkkHhY0CCE/G42Af/jEBGPza3S6zy4I/36eBKOo23JRM06quZpbZnn7cJ sSGKeXeDOlEOGpcaEyTdKIiQUf4LA+eztwZDhfxUiFpeFHOMvX4sE+TsC4R0Cm1U AHVkNb/8RQHsd3VCFZsw =gfY3 -----END PGP SIGNATURE----- --dSuDCfsfQ3OVp76C50c8QQVJW3liXqgCx-- From owner-freebsd-current@freebsd.org Wed Apr 20 07:10:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E8AAB145BD for ; Wed, 20 Apr 2016 07:10:40 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 144661BB0 for ; Wed, 20 Apr 2016 07:10:40 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id v188so190451272wme.1 for ; Wed, 20 Apr 2016 00:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MmKiHvXfVY1dd88s2o+aV45KQ0eKgMA99TOCc1ob/NA=; b=AAYQSo6qcPJuFLvHwBQKoPF7bQCoN64vKavx+nq+kPIDXCf4pnLEvh9wSeLvfK9xAq x8ihwRaX5U24Lk+rxolGQrEWH14rtXgy64G5P+/DOjHuIi99ZRm3qUYY7cpbGZncZaXJ n3A388C+D5U6H+fPGXn3WxeKBLIJoWEuiceieA9AFmX09HiCY/gbXGY7UZDXE2oDpft4 sE5hMMSQ/Mvrp/UxOQo2dVFQF902/XBWlrVv0d8q6JS4oEFmcc9mWKaOCcoW97LqliOn n5+1q73RwbT8XYLis7i5dlBxaZIy+EcdNonQEE0/Fjj2l7PHfjOY24MrKJ7aaNZrYFBV th6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MmKiHvXfVY1dd88s2o+aV45KQ0eKgMA99TOCc1ob/NA=; b=mz3SwWOCS8UPJm45DeaiHq9x10SNfeVnLDM3YqZtM94phkCkKXQh/5qb1uQpG5R8ZW de8HVdbVmTi2EtNGOSbMqSDMSyEWS62fiCSiNtkkkIauPerzFNmdNEFNt15zLS5QJWEu SxpKljsbTOcCD/WJL/lRLdtYGgPAyrFQ9C1v/7egkalE2jnugdRAplcuCWhbrS4S+mfo 1kyiHJarDbjBk3o6PlTWTyrkL/n1m6h/MuOe65W2p80j5m3WUyZAFgwcrVqyIc46Tylb l1ISwSY4e8+gDtTap12GRXwQYHl7VNHuVzwRWMPFz4rK27Fz0d6NUjBPjXZe0rrmyHWp kVaA== X-Gm-Message-State: AOPr4FW7ijtR1PjXDvvyW6MxAYVxCiNVgj7s0BDb35uzug/77qXfsLNw7qfXZCP6uDFEnA== X-Received: by 10.28.54.33 with SMTP id d33mr7948917wma.63.1461136238725; Wed, 20 Apr 2016 00:10:38 -0700 (PDT) Received: from Johans-MacBook-Air.local (92-111-79-242.static.chello.nl. [92.111.79.242]) by smtp.googlemail.com with ESMTPSA id wr2sm3949595wjc.49.2016.04.20.00.10.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2016 00:10:38 -0700 (PDT) Subject: Re: Heads up To: Warner Losh References: Cc: freebsd-current@freebsd.org From: Johan Hendriks Message-ID: <0f6a84a9-4bae-4dc1-4f6e-169c16232cf6@gmail.com> Date: Wed, 20 Apr 2016 09:10:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 07:10:40 -0000 Op 15/04/16 om 19:30 schreef Warner Losh: > Also a horrible name. It's a generic I/O scheduler. It can do lots of > things. I keep saying that, and categorically refuse to name the more > expansive scheduler anything that's so limiting. > > Warner Thanks for all the work on this. One question? If the scheduler can do a lot of things what are the defaults set to? Are they set to the Netflix load or more like the behauvier of a standard FreeBSD before this patch. regards Johan From owner-freebsd-current@freebsd.org Wed Apr 20 07:38:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50A32B14DBA; Wed, 20 Apr 2016 07:38:55 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ig0-x241.google.com (mail-ig0-x241.google.com [IPv6:2607:f8b0:4001:c05::241]) (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 1E5211789; Wed, 20 Apr 2016 07:38:55 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ig0-x241.google.com with SMTP id g8so5594933igr.0; Wed, 20 Apr 2016 00:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=OkkAImDXXo36gLktVGYw0UrIwe5beRNR1n0i+6s2MQc=; b=0T4zCgm3iAxzYoMlC4wkXR22hTLKxyJP/9vXYddLA8QzDBAXeWwenRdjw6OC8SiX5K +xwfaCkOO2vclHn2mlsdZc5Rw+TotcXNrw9QiVy8LqWSB4QtwYWuJ5LYftP5Eholb2bd JhP37qUT9eaQuNQff5u/6Gm4nRL64uBVNVtuMWlBGwSWFYF+1MKotaeo2YK/itKeXljP CVYi2fQty1KX75phS7dQHpf1cx9EkCbkgNusZeixAZ8kpCFvj8DUvJm12M4XNzwmhQ8u xl+t9I7DP+2riajjsj1n3zT1mT9dAGyHWkYJxngg4ehJC8XVRP+wa3xeUILzemz/WnZX yPSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc; bh=OkkAImDXXo36gLktVGYw0UrIwe5beRNR1n0i+6s2MQc=; b=PZM9T4VfRwUHHYKEyJ3LTajLbOPBXAU0sHiV0bITS1ZLCHs6+M2AlXbD9fPvaQwh0L nUwtPqXZljyqvrVhhNI28M9Gung4ykbUGbkPMDSV7HOU1RsnAr5+FXYasmXk5TlxswyI PK2GUJvU3e8VzjC1vqmFPfyU+3eiYpH4FFSQYIWMEhIWakvbwoQJrjOc6mUZVEv/WnDF ZT6Xo0Jz585PZ4gYB+SgNZcDxeS23ZET8XOwZF1rV57j2zCKjpGbF1anMekNuaHHNxIk BHNd18g/3SmF2iyT+bIKX0WEcvwDQqN5DX0gSr6Eh2Rn/M7NOKlWu74/3Ro4vfYFuS5v M4+A== X-Gm-Message-State: AOPr4FVnDJENDiMOrltNX8CqNwNwvP49pkyHUwg3BWD4/4gl3njgub4OfGclTFd09069v3LbBdRtL4n+V6hVUA== MIME-Version: 1.0 X-Received: by 10.50.150.42 with SMTP id uf10mr1918519igb.95.1461137934396; Wed, 20 Apr 2016 00:38:54 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.6.166 with HTTP; Wed, 20 Apr 2016 00:38:54 -0700 (PDT) Date: Wed, 20 Apr 2016 00:38:54 -0700 X-Google-Sender-Auth: LclYlj8TeTl5h8UkH72pdyDSqNc Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: "K. Macy" To: Glen Barber Cc: lev@freebsd.org, FreeBSD Current , freebsd-pkgbase@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 07:38:55 -0000 On Mon, Apr 18, 2016 at 12:14 PM, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: >> > >> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 >> > packages?! WHY?! What are reasons and goals to split base in such >> > enormous number of packages? >> >> Just a guess, having done the same thing myself: it means that updates can be >> more targeted. >> > > This is exactly the reason, which has been answered numerous times. I don't know what the "ideal" number of packages is. 755 does seem large. However, I see it being like KSE. In hindsight KSE was overly complicated and M:N threading wasn't the way to go. However, Julian's work brought native threading to FreeBSD. Something it sorely needed. Similarly, the packaging of base FreeBSD is something that has been desperately needed for a long time but the work to get there was simply overwhelming. Initially there will very likely be painful problems, but I'm comfortable that all those involved will course correct and converge on something that most people will be content with. I'm sure there are those with well articulated criteria for a different decomposition of base, with specifics on how and why. Those select individuals can contribute meaningfully to this discussion. Everyone else should just applaud their hard work and get back to work. There are plenty of bugs that could have been fixed in the time it would have taken to digest this whole thread. -M From owner-freebsd-current@freebsd.org Wed Apr 20 08:12:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0167DB15B32 for ; Wed, 20 Apr 2016 08:12:34 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEB0C1A03; Wed, 20 Apr 2016 08:12:32 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u3K8CIsa028159 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2016 08:12:25 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: multipart/signed; boundary="Apple-Mail=_02AD6292-22C4-496C-8686-BD0001F40185"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: David Chisnall In-Reply-To: <57170E5D.1090701@freebsd.org> Date: Wed, 20 Apr 2016 09:12:11 +0100 Cc: Nathan Whitehorn , freebsd-current@freebsd.org Message-Id: <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:12:34 -0000 --Apple-Mail=_02AD6292-22C4-496C-8686-BD0001F40185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 20 Apr 2016, at 06:06, Julian Elischer wrote: >=20 > my problem with 400 packages is that is is hard to decide what you are = actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? > you have no way to tell exactly what you have without comparing all = the packages to a known list. > uname doesn't mean much, nor does "__FreeBSD_version" if everything = comes with its own versions. I think that it=E2=80=99s very important, for the purpose of a = constructive discussion, to separate the two concerns: 1) The number of packages that the base system has. 2) The user interface by which the packages are presented. I believe (and, please, correct me if I=E2=80=99m wrong), that all of = the complaints in this thread have been about the UI, not about the = underlying mechanism. That=E2=80=99s not to say that they=E2=80=99re = unimportant (quite the reverse), but that they can be solved = concurrently with the task of preparing the base system for distribution = in packaged form. Having fine-grained packages makes a lot of things possible that are = difficult otherwise, but we do need to fix the UI. > the 'leaf' concept in pkg helps with this a bit, but we've always = considered FreeBSD bas as a sort of monalithic entity that moves forward = together. >=20 > you are running 10.1p8 pr 10.2p1 that tells you all you need to know. > If you now need to take into account 400 different dimensions you have = a much harder way to describe what you have.. >=20 > I mentioned this before but I think hte answer is to make a change on = the way that "meta packages" are displayed by default in pkg. Part of the problem is that we don=E2=80=99t actually have metapackages. = A metapackage is a package that *contains* other packages. What we = actually have is empty packages that *depend on* other packages. The = package tool has no way of distinguishing a package that you install for = the sole purpose of installing its dependencies from one that you = install because you want it (though having no files inside it might = serve as an heuristic that would work). > If I install the meta package, I really don't want to see all the sub = packages tat are unchanged unless I add '-v'. On the other hand if I = upgrade a sub package I want to see that in the context of the = metapackage. Similarly if I uninstall of the subpackages. Doing this properly also requires the notion of optional default and = non-default subpackages. I should be prevented from uninstalling (at = least, without a lot of -f) non-optional subpackages. For example, on a = small system where I=E2=80=99m not using zfs, I might uninstall the = libzfs subpackage from freebsd-libs, but if I try to uninstall the libc = package then the system should shout at me. >=20 > so something like this would remove most of my objections: >=20 > # pkg info > =3D=3D=3D=3D=3D system packages=3D=3D=3D=3D > FreeBSD-networking-11.0.2_1 FreeBSD networking = subsystem and commands > - ipfw-11.0.2-1 ipfw tools (uninstalled) > - fbsd-tcpdump-11.0.2-1 Built in tcpdump tools = (uninstalled) > * openssl-11.0.2-2 Openssl support (upgraded = CVE-123456 > FreeBSD-base-base-11.0.2-1 The absolute minimum = booting base system > [...] > =3D=3D=3D=3D external packages =3D=3D=3D=3D=3D=3D > apache22-2.2.31 Version 2.2.x of Apache web server with = prefork MPM. > apr-1.5.2.1.5.4 Apache Portability Library > autoconf-2.69 Automatically configure source code on = many Un*x platforms > autoconf-wrapper-20131203 Wrapper script for GNU autoconf > [...] >=20 >=20 > Maybe I uninstalled ipfw because I use pf and I install the ports = tcpdump so I can remove the built in one. > I have installed a new openssl due to a bugfix.. >=20 > This gives me a real instant feel for what I'm running.. > if I add -v then I see all 400 packages, but I really don't want to = see them 99.99% of the time >=20 > I believe the "leaf" method gives close to this but if we could get = the above I'd have absolutely no objections. Thank you for this suggestion. I think that this is the sort of UI that = makes a lot of sense (though having subpackage support would also be = useful for ports). It=E2=80=99s also the kind of thing that I think we = could persuade the Foundation to fund if there is not enough volunteer = time to implement it. David --Apple-Mail=_02AD6292-22C4-496C-8686-BD0001F40185 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDIwMDgxMjExWjAjBgkqhkiG9w0BCQQx FgQUTvMyAdGSwS98Xi5Vxdixug3MZMYwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBAGSAFk+5UBqhMwsdowMY0GeuTYC3kcg1YH8baxhmTTJmDUpSi8IJXlAw hHZuBwuxhPOao3w/RFnxurVXOdlbksEVC6YqKhmZXCfYy6TCWkAiMfS1kDR3mzTGVes+Cmfbwm6b ITemDUYFMQ9+h1l5NJzgX9PeYnsmwylUChPplR24n2KJyhP3PDKX4piLwcaBLuoz3k3vEIs/x/42 HDA1DzRzzxG7BARDGUPMCodvPENN0F95K7zIxpTp90L/whhCSEzXjcP2nkYtCi4glE5ioaKHKYHq hAjWx4FDWRigCF1q0aD5EiB+hF8wDbkC1Xqyzz+qtFWVBBm7LXz/PeRHZDYAAAAAAAA= --Apple-Mail=_02AD6292-22C4-496C-8686-BD0001F40185-- From owner-freebsd-current@freebsd.org Wed Apr 20 08:25:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8902B15EC9 for ; Wed, 20 Apr 2016 08:25:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F0E7E1EED; Wed, 20 Apr 2016 08:25:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA00753; Wed, 20 Apr 2016 11:25:18 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1asnRm-0004wH-Ia; Wed, 20 Apr 2016 11:25:18 +0300 To: FreeBSD Current From: Andriy Gapon Subject: Error: stack underflow Message-ID: Date: Wed, 20 Apr 2016 11:24:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:25:27 -0000 I see this message "Error: stack underflow" when a loader menu is presented. It seems that it comes from ficl. This is on a quite recent (< 2 weeks) head. How can I debug this problem? I have one local modification to forth files, but I'm not sure if the problem is caused by it or by something in my boot configuration files. diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.4th index 9adf30a46b661..813cbf12e9655 100644 --- a/sys/boot/forth/menu-commands.4th +++ b/sys/boot/forth/menu-commands.4th @@ -243,6 +243,21 @@ also menu-namespace also menu-command-helpers TRUE \ loop menu again ; +: toggle_gui ( N -- N TRUE ) + toggle_menuitem + menu-redraw + + \ Now we're going to make the change effective + + dup toggle_stateN @ 0= if + s" inhibit_gui" unsetenv + else + s" set inhibit_gui=1" evaluate + then + + TRUE \ loop menu again +; + \ \ Escape to Prompt \ diff --git a/sys/boot/forth/menu.rc b/sys/boot/forth/menu.rc index 3c7de7138b8ad..ddeccc9679fea 100644 --- a/sys/boot/forth/menu.rc +++ b/sys/boot/forth/menu.rc @@ -126,6 +126,13 @@ set optionsmenu_keycode[6]=118 set optionsansi_caption[6]="^[1mV^[merbose..... ^[34;1mOff^[m" set optionstoggled_ansi[6]="^[1mV^[merbose..... ^[32;7mOn^[m" +set optionsmenu_caption[7]="Inhibit [G]UI. off" +set optionstoggled_text[7]="Inhibit [G]UI. On" +set optionsmenu_command[7]="toggle_gui" +set optionsmenu_keycode[7]=103 +set optionsansi_caption[7]="Inhibit GUI. Off" +set optionstoggled_ansi[7]="Inhibit GUI. On" + \ \ BOOT ENVIRONMENT MENU \ -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Apr 20 09:00:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84AEEB1515E for ; Wed, 20 Apr 2016 09:00:38 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 49C2213A2; Wed, 20 Apr 2016 09:00:37 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.155] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id 4C5BF1F9A7; Wed, 20 Apr 2016 12:00:36 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Dan Partelly In-Reply-To: <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> Date: Wed, 20 Apr 2016 12:00:36 +0300 Cc: Julian Elischer , Nathan Whitehorn , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 09:00:38 -0000 IMO, the number of packages per-se is not a problem as long as you can = manage them without arcane commands, aliases, pipe - filters, or = scripts. (they all have their place, but less , the better) My point is = that I don't really want to keep on my head a Unix hacker hat. I (and = presumably many other humans ) like simple things,which allow me to type = a short command (preferably the whole system should be simple enough to = be explained in one-two pages in handbook) , wait for completion, and = get on with my life.=20 When I said people should pay more attention to Redmond and Cupertino, = this is what I meant. UIs are important. Easy service management, fault = reporting and so on should be automated. We shouldn't waste our time = doing what the computer should do in the first place. Most people want = to get the job done, so they can proceed with what is important for = them. I am very sorry if this is so offensive to some people that they = feel attacked, but unfortunately there aint much I can do to = alleviate this.=20 >=20 > 1) The number of packages that the base system has. > 2) The user interface by which the packages are presented. >=20 > I believe (and, please, correct me if I=E2=80=99m wrong), that all of = the complaints in this thread have been about the UI, not about the = underlying mechanism. That=E2=80=99s not to say that they=E2=80=99re = unimportant (quite the reverse), but that they can be solved = concurrently with the task of preparing the base system for distribution = in packaged form. >=20 From owner-freebsd-current@freebsd.org Wed Apr 20 09:42:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53014B147BF; Wed, 20 Apr 2016 09:42:13 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qg0-x241.google.com (mail-qg0-x241.google.com [IPv6:2607:f8b0:400d:c04::241]) (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 0C06B1E3D; Wed, 20 Apr 2016 09:42:13 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qg0-x241.google.com with SMTP id 7so4255149qgj.0; Wed, 20 Apr 2016 02:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EjqACbNQNUDocwC+rD6nqgCJDQUmKBEYafgg9qtZ3fc=; b=0Ud8ESMQmsl8XVIyaUc1DHTmIFjrmInLO/ElHX2UNTnME+qwmNVFWwWv/6y0DT2587 VlLzBj6cZ1+Yips6zAOjtLQtk7OT5nv2QmxIQf5Tsz9KX8xWxOWFXrPhw2HvYT1Qm79m uF6wgzRTUqhbg4bHf+EFRP6XQA5x3fUy8p61uS+Eg9sDyYqLWFZlmKUdtBrADXVZRmuu FPSyXi1zxmSN00dVxdtiRda7cXihgqr3+gtJR2w/E5/x1iOtf9LnO2/L/V/dZQkSFSXw ucna8FPLRNMkEt3WjRxjoaJ8jqJWvsEw79VHcuKkYyWoFdvPbEHgUvHcF6fvvxqe6tbu hnkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=EjqACbNQNUDocwC+rD6nqgCJDQUmKBEYafgg9qtZ3fc=; b=SveQjxgrqQBjKfcxd8u0UyAfdkSNY7ox7O8fY1SNn0Q38O4nUk7SjKeKRu1ZUQbKFH 5MnsJS7/G500fv7nP4UUQjkHlvIhyuGgQI6xFIrdS3t/kTSTiMtEIgK/K99KBbde5TDA YMR7piUOwWR8dPRwKj1Jup09DUL5UQCfr+Aq2LH9UewSjsrcbfg/WHhUdWcgEc2pyyOV 8s1GYCOHjo69R5fV7rxPyCYmPd8IzDxmDWNkWnFTmAU0hnEjsxNIRxhpR/JFzAzZ4O91 a1lPNrLI1evJ5vwHIWThtS2N4cP8i8ii3PvgwILtwDIaRM2nCY8qrTfF4QUqrnB8tsZW rTYg== X-Gm-Message-State: AOPr4FWaJStVOmAvmoqxW/3C8qoW1A3UeC4WNG72WZvCsks2r4amAQvc0CizFSnFfe/REg== X-Received: by 10.140.181.137 with SMTP id c131mr9967944qha.94.1461145332272; Wed, 20 Apr 2016 02:42:12 -0700 (PDT) Received: from mbp.home (179-125-130-37.desktop.com.br. [179.125.130.37]) by smtp.gmail.com with ESMTPSA id f83sm30978104qkb.25.2016.04.20.02.42.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 02:42:11 -0700 (PDT) Sender: Renato Botelho Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-RELEASE pkg base & base.txz file From: Renato Botelho In-Reply-To: Date: Wed, 20 Apr 2016 06:42:06 -0300 Cc: Slawa Olhovchenkov , questions@freebsd.org, freebsd-pkgbase@freebsd.org, Ernie Luzar , freebsd-current Content-Transfer-Encoding: 7bit Message-Id: <0E16B4D4-DB5D-4ABD-9D00-6AF819452724@FreeBSD.org> References: <5714E89A.8000807@gmail.com> <20160418141454.GX4841@zxy.spb.ru> <20160418141601.GA26116@ivaldir.etoilebsd.net> <20160418142709.GY4841@zxy.spb.ru> <20160418150325.GZ4841@zxy.spb.ru> <5715389C.9090502@gmail.com> <20160418200354.GB4841@zxy.spb.ru> To: krad X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 09:42:13 -0000 > On Apr 20, 2016, at 03:54, krad wrote: > > will it still be buildable though from source? Yes -- Renato Botelho From owner-freebsd-current@freebsd.org Wed Apr 20 09:48:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A02AEB14C48 for ; Wed, 20 Apr 2016 09:48:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5BC14173C; Wed, 20 Apr 2016 09:48:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asoju-000ACk-98; Wed, 20 Apr 2016 12:48:06 +0300 Date: Wed, 20 Apr 2016 12:48:06 +0300 From: Slawa Olhovchenkov To: Dan Partelly Cc: David Chisnall , Julian Elischer , Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420094806.GJ6614@zxy.spb.ru> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 09:48:05 -0000 On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > IMO, the number of packages per-se is not a problem as long as you > can manage them without arcane commands, aliases, pipe - filters, > or scripts. (they all have their place, but less , the better) My > point is that I don't really want to keep on my head a Unix hacker > hat. I (and presumably many other humans ) like simple things,which > allow me to type a short command (preferably the whole system should > be simple enough to be explained in one-two pages in handbook) , > wait for completion, and get on with my life. Yes and no. While number of packages don't see outside internal -- this is irrelevant. After possibility of update individual package -- nuber of packages is impotant. Take fresh 11.0. Before 11.1 update only kernel. What you system have? 11.0? 11.1-RC3? How you name it? How identify it for take support on forum or mail list? How name system, updated all w/o compiler? or only some services? Currently we have simple naming: 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. This is shortly and clearly identify system to anyone. How do this with many packages? I am describe in -pkgbase expirence of updating system. How I am can naming this (my) system? Solaris don't ship new version often and don't have rollover updates. I think, first step may be split to only two package (kernel and world) and resolve many other issuses: distinc base packages from port packages, beadm compatibility, /etc and config updates (/etc/rc.d is not config but currently allowed to editing, this is distinct from plain ports configs) and others. After expirence with this next step will be more clear. > When I said people should pay more attention to Redmond and Cupertino, this is what I meant. UIs are important. Easy service management, fault reporting and so on should be automated. We shouldn't waste our time doing what the computer should do in the first place. Most people want to get the job done, so they can proceed with what is important for them. I am very sorry if this is so offensive to some people that they feel attacked, but unfortunately there aint much I can do to alleviate this. > > > > > 1) The number of packages that the base system has. > > 2) The user interface by which the packages are presented. > > > > I believe (and, please, correct me if I’m wrong), that all of the complaints in this thread have been about the UI, not about the underlying mechanism. That’s not to say that they’re unimportant (quite the reverse), but that they can be solved concurrently with the task of preparing the base system for distribution in packaged form. > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Apr 20 10:43:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55410B16917 for ; Wed, 20 Apr 2016 10:43:13 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (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 C9D71135F for ; Wed, 20 Apr 2016 10:43:12 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from ox-dell39.ox.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id BF1551156E for ; Wed, 20 Apr 2016 10:43:08 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/BF1551156E; dkim=none; dkim-atps=neutral Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> From: Matthew Seaman Message-ID: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> Date: Wed, 20 Apr 2016 11:43:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160420094806.GJ6614@zxy.spb.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ" X-Virus-Scanned: clamav-milter 0.99.1 at smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 10:43:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ Content-Type: multipart/mixed; boundary="SSxxrwF6AJFh2g70qw03vxfxno9NVpXmD" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> In-Reply-To: <20160420094806.GJ6614@zxy.spb.ru> --SSxxrwF6AJFh2g70qw03vxfxno9NVpXmD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/20/16 10:48, Slawa Olhovchenkov wrote: > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? >=20 > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: >=20 > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. >=20 > How do this with many packages? Hmmm.... Good point. At release time, a set of packages will be generated. These will all have the version number of the release eg. 11.0. That's simple and unambiguous. Subsequently adding patches will add a patch level to the version, so 11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel will cause the output of uname(1) to show the new patch level, but updates to user land should be reflected in the output of freebsd-version(1). That's exactly the same as now, and assuming you, as an end user, install the default set of FreeBSD packages and apply all the patches as they come out, then there should be no problem. This implies that /every/ patchset will include an update to the package containing freebsd-version. What packaging base does do is allow you to be selective in the patches you apply. So, for instance if patch -p1 was not relevant to you, you might not install it. So you could end up with a system where you hadn't installed patches -p1 -- -p9 but you did install patch -p10. The freebsd-version(1) output would presumably show the system as 11.0-p10 -- but that's certainly not the same as a system with all of those patches -p1 to -p9 applied. Or you could just install the updated freebsd-version(1) package and have your system blatantly lie about its patching status. So, yes, this does change the meaning of the version number string. It's morally equivalent to tracking the releng/11.0 branch in SVN but compiling your system with various WITH_FOO or WITHOUT_BAR flags, and possible local modifications to the code base to back out certain commits. It's still 11.0-SOMETHING but it's not clear exactly what that something should be. Hopefully people that do such things will be sufficiently technically sophisticated to be able to characterize their problems based on the versions of any relevant FreeBSD packages. On the release of 11.1 there would be a complete new set of system packages generated, and the upgrade process would install the new versions of those packages all round, even if the content of an individual package was identical to the one in 11.0. There's probably a handy optimization where we compare the before and after checksums for package files and don't overwrite on disk what is identical between package versions, but do update all of the bookkeeping in the pkgdb. Cheers, Matthew --SSxxrwF6AJFh2g70qw03vxfxno9NVpXmD-- --tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXF101AAoJEABRPxDgqeTnh1wP/RdWDzk1StzV5FY2apDAa7ww SIhGfCHPnwRE4kGo9R2dTskHkhbLUCGvnhhycUf+XMOG6t1neG3h0esso3pF8WuS 8fl46O+u2gyUSPQ3OdkFvkrb5TMBiI4RdxeiOxS09eQRJZUrnq8n+i3o0l9cymVi vJ7fhm95x8viIZo0jesGX7FvRZsWYNBTPW5ta1cZvLTX4y65JV2zjZoWoarfiJnH xqOyPlgr6LStP5KA+au0og0yHcFWduXtVLX/xALEkoMFHYeWQ5YPk0qLAPi1xv4S AAZ0tAn/y6p3Sc0J7Qs7rGBPZ5rccfcnJ6fEuOMWdEznCN8N0Fn3Q6vD6mpIy1vI GlUKr2L7T1dPZib48gL6R1Z4HB/67y1gR5eCEeOuhTsuep5FhMc+xi7EoEHqCmFJ HIOdZn44aOlqeP4AoupccA+LRSeohxMVX0hkjS8zP+yRgInE+RR/57kbUU4hOEB9 7reXqVxSQ4IByfO80VTa5deme1MpJEs5f2IRuQjp8+fpj2OYIeU3CcX4qkrJVz2k cMYy9KRKhA/YYOQaWJ4OaD0Z1ZINElX5cfoyobCHTFnNsu7cTJGNjIThxJ3KQx2F QdcJMjBWZ+07FeyAsHEEvQYmv/j0cYijoc9PiXTdp7wYTFKGJlg5qnrwiNBn73P0 0Itxg/iANPBzbxcgFBBt =9hRt -----END PGP SIGNATURE----- --tlG9f5Rr7vK7Q3CGVPiHcaTdlfiQi4biJ-- From owner-freebsd-current@freebsd.org Wed Apr 20 08:00:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27C8AB15735 for ; Wed, 20 Apr 2016 08:00:23 +0000 (UTC) (envelope-from Erik.Trulsson.1013@student.uu.se) Received: from cursor.its.uu.se (smtp-out2.uu.se [130.238.7.173]) (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 AC90F1301 for ; Wed, 20 Apr 2016 08:00:22 +0000 (UTC) (envelope-from Erik.Trulsson.1013@student.uu.se) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by cursor.its.uu.se (Postfix) with ESMTP id A318920D; Wed, 20 Apr 2016 09:52:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uu.se; s=centralsmtp; t=1461138752; bh=4Tf5MLauR45bgIc5copgBsb5AkEtIhmQ4J7PItfoJyQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=hQo68tx1Z4ZKL227FgIAT03NBPklnq3Ijs7YSyfRsLyR4kFl2WsV2iZhcjXm4cJbv q1cyZrX/WuBRh7N6reeLzISkU9S2aw+lGzCHjQgZZvyFpyG2JE/YWFPeFXUzSAR33W 0JVO0TG2qgnyMZ+7j2keOFrbWAT+vfgoSuZUu2NU= Received: from lyra.its.uu.se (lyra.its.uu.se [130.238.7.73]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u3K7qWbN016878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2016 09:52:32 +0200 Received: from virgata.its.uu.se (virgata.its.uu.se [130.238.7.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lyra.its.uu.se (Postfix) with ESMTPS id 8E8A9E8135; Wed, 20 Apr 2016 09:52:31 +0200 (CEST) Received: from jubula (localhost.localdomain [127.0.0.1]) by virgata.its.uu.se (8.13.8/8.13.8) with ESMTP id u3K7qTTd025191; Wed, 20 Apr 2016 09:52:29 +0200 Received: from h-197-74.a213.corp.bahnhof.se (h-197-74.a213.corp.bahnhof.se [85.24.197.74]) by webmail.uu.se (Horde Framework) with HTTP; Wed, 20 Apr 2016 09:52:29 +0200 Message-ID: <20160420095229.184641ns20dxu799@webmail.uu.se> Date: Wed, 20 Apr 2016 09:52:29 +0200 From: Erik Trulsson To: Warren Block Cc: Aleksander Alekseev , Hans Petter Selasky , FreeBSD Current Subject: Re: qsort() documentation References: <5714C86A.8050204@selasky.org> <20160419113430.69e41a0b@fujitsu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-uu-se:default, uu-se:default, base:default, @@RPTN) X-Spam-Score: -0.10 () [Tag at 15.00] T_RP_MATCHES_RCVD:-0.1 X-p0f-Info: os=Linux 2.6.x, link=Ethernet or modem X-CanIt-Geo: ip=130.238.7.55; country=SE; region=Uppsala; city=Uppsala; latitude=59.8500; longitude=17.6333; http://maps.google.com/maps?q=59.8500,17.6333&z=6 X-CanItPRO-Stream: outbound-uu-se:outbound (inherits from outbound-uu-se:default, uu-se:default, base:default) X-Canit-Stats-ID: 09QIvQwht - dcf3924f64fd - 20160420 X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?i=09QIvQwht&m=dcf3924f64fd&t=20160420&c=f X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?i=09QIvQwht&m=dcf3924f64fd&t=20160420&c=n X-Antispam-Training-Phish: https://mailfilter.sunet.se/canit/b.php?i=09QIvQwht&m=dcf3924f64fd&t=20160420&c=p X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?i=09QIvQwht&m=dcf3924f64fd&t=20160420&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 130.238.7.55 is neither permitted nor denied by domain Erik.Trulsson.1013@student.uu.se) receiver=e-mailfilter01.sunet.se; client-ip=130.238.7.55; envelope-from=; helo=lyra.its.uu.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 X-Mailman-Approved-At: Wed, 20 Apr 2016 11:07:09 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:00:23 -0000 Quoting Warren Block : > On Tue, 19 Apr 2016, Aleksander Alekseev wrote: > >>> Why Wikipedia, specifically? There are a lot of places that describe >>> quicksort. How about just >>> >>> Note: This implementation of qsort() is designed to avoid the >>> worst-case complexity of N**2 that is often seen with standard >>> versions. >> >> I would say that this statement is just false. Worst-case complexity is >> still N**2. How about something like: >> >> """ >> This implementation of qsort() has worst case complexity of N**2. >> However measures were taken that make it very unlikely that for some >> random input N**2 swaps will be made. It's still possible to generate >> such an input on purpose though. See code below for more details. >> """ > > Okay: > > The quicksort algorithm worst-case is O(N**2), but this implementation > has been designed to avoid that for most real data. Keep in mind that there is no requirement whatsoever that the qsort() function uses the quicksort algorithm, even if that is a common way to implement qsort() Also, worst-case is worst-case, no matter how unlikely. From owner-freebsd-current@freebsd.org Wed Apr 20 11:19:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6617CB15AD9 for ; Wed, 20 Apr 2016 11:19:34 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A07A17E8; Wed, 20 Apr 2016 11:19:33 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 0095628432; Wed, 20 Apr 2016 13:19:25 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B64E928422; Wed, 20 Apr 2016 13:19:23 +0200 (CEST) Message-ID: <571765BB.3050908@quip.cz> Date: Wed, 20 Apr 2016 13:19:23 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> In-Reply-To: <5716FA70.4080604@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 11:19:34 -0000 > It would also be nice to get a statement of what the intended scope of > these patches is from some of the people involved in the project. It's a > major change to the system and it would be nice to have some kind of > architectural document about what is happening. I'm not sure, for > instance, what the release for 11 looks like with these changes, what > changes need to be made to the installer (something of particular > interest to me), how we build install media now that base is no longer > self-contained (due to lack of pkg), what specific problems were > intended to be solved, how package dependencies work, etc. Something > like a few-page white paper would be *really* helpful for those of us > who weren't at the BSDcan where this was discussed. Even a wiki page > would help a lot. I really like FreeBSD, I am using it for more than 15 years on daily basis. FreeBSD had good and bad times (releases / changes) but one thing stays always the same - still bad communication about new features, work in progress etc. I think it is not too hard to publish papers about new base packages. Proposals, current state, ToDo to better inform users about upcoming changes. I think these informations already exist in some private form between developers. If these informations were more public I think there will be less annoyed posts in mailinglist and more constructive critics / ideas / patches. I did a guick search and found only one closely related page about packaged base: https://wiki.freebsd.org/FreeBSD-ng last edited 2014-03-11 Even this old page has "Known problems" mentioning the situation what we have now in this thread (fed-up people on both sides). So I think this was expected and people involved in this project could have do communication better. I had some concerns about it and some of them were explained and canceled after reading more than 100 posts in this thread. (some concerns remain). I believe if it was written in FreeBSD Wiki, there were not be so much dissapointed posts. I don't want to offend anybody on this list or FreeBSD team. I just think that things like this can and should be communicated better next time. Sysadmins and sysdevelopers have different point of view to a lot of things and it is better to talk about it before things are done and cannot be undone. Miroslav Lachman From owner-freebsd-current@freebsd.org Wed Apr 20 11:25:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14FBCB15DCC for ; Wed, 20 Apr 2016 11:25:09 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBBEA1CBE; Wed, 20 Apr 2016 11:25:08 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B888C28436; Wed, 20 Apr 2016 13:25:06 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 101E828432; Wed, 20 Apr 2016 13:25:06 +0200 (CEST) Message-ID: <57176711.6070303@quip.cz> Date: Wed, 20 Apr 2016 13:25:05 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Matthew Seaman , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> In-Reply-To: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 11:25:09 -0000 Matthew Seaman wrote on 04/20/2016 12:43: > On the release of 11.1 there would be a complete new set of system > packages generated, and the upgrade process would install the new > versions of those packages all round, even if the content of an > individual package was identical to the one in 11.0. There's probably a > handy optimization where we compare the before and after checksums for > package files and don't overwrite on disk what is identical between > package versions, but do update all of the bookkeeping in the pkgdb. This will be a really nice feature which can save a lot of bandwidth and storage for backups after upgrade. (but I don't know how many files are usually unchanged between upgrades) Miroslav Lachman From owner-freebsd-current@freebsd.org Wed Apr 20 12:24:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83430B15BF1 for ; Wed, 20 Apr 2016 12:24:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 435291087; Wed, 20 Apr 2016 12:24:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asrAo-000E8P-Jt; Wed, 20 Apr 2016 15:24:02 +0300 Date: Wed, 20 Apr 2016 15:24:02 +0300 From: Slawa Olhovchenkov To: Matthew Seaman Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420122402.GK6614@zxy.spb.ru> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 12:24:02 -0000 On Wed, Apr 20, 2016 at 11:43:00AM +0100, Matthew Seaman wrote: > On 04/20/16 10:48, Slawa Olhovchenkov wrote: > > > While number of packages don't see outside internal -- this is > > irrelevant. > > After possibility of update individual package -- nuber of packages is > > impotant. > > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > > 11.0? 11.1-RC3? How you name it? How identify it for take support on > > forum or mail list? > > > > How name system, updated all w/o compiler? or only some services? > > Currently we have simple naming: > > > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > > This is shortly and clearly identify system to anyone. > > > > How do this with many packages? > > Hmmm.... Good point. > > At release time, a set of packages will be generated. These will all > have the version number of the release eg. 11.0. That's simple and > unambiguous. > > Subsequently adding patches will add a patch level to the version, so > 11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel > will cause the output of uname(1) to show the new patch level, but > updates to user land should be reflected in the output of > freebsd-version(1). That's exactly the same as now, and assuming you, > as an end user, install the default set of FreeBSD packages and apply > all the patches as they come out, then there should be no problem. > > This implies that /every/ patchset will include an update to the package > containing freebsd-version. > > What packaging base does do is allow you to be selective in the patches > you apply. So, for instance if patch -p1 was not relevant to you, you > might not install it. So you could end up with a system where you > hadn't installed patches -p1 -- -p9 but you did install patch -p10. The > freebsd-version(1) output would presumably show the system as 11.0-p10 > -- but that's certainly not the same as a system with all of those > patches -p1 to -p9 applied. Or you could just install the updated > freebsd-version(1) package and have your system blatantly lie about its > patching status. This is about RELENG, what about STABLE and CURRENT? > So, yes, this does change the meaning of the version number string. > It's morally equivalent to tracking the releng/11.0 branch in SVN but > compiling your system with various WITH_FOO or WITHOUT_BAR flags, and > possible local modifications to the code base to back out certain > commits. It's still 11.0-SOMETHING but it's not clear exactly what that > something should be. Hopefully people that do such things will be > sufficiently technically sophisticated to be able to characterize their > problems based on the versions of any relevant FreeBSD packages. > > On the release of 11.1 there would be a complete new set of system > packages generated, and the upgrade process would install the new > versions of those packages all round, even if the content of an > individual package was identical to the one in 11.0. There's probably a > handy optimization where we compare the before and after checksums for > package files and don't overwrite on disk what is identical between > package versions, but do update all of the bookkeeping in the pkgdb. New numbering scheme is very hard problem... From owner-freebsd-current@freebsd.org Wed Apr 20 12:45:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FBF2B165E6 for ; Wed, 20 Apr 2016 12:45:54 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id AA7911051; Wed, 20 Apr 2016 12:45:53 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 90FD6DC135; Wed, 20 Apr 2016 15:45:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Wed, 20 Apr 2016 15:45:56 +0300 From: dan_partelly To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Nathan Whitehorn , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <571765BB.3050908@quip.cz> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> Message-ID: <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 12:45:54 -0000 > If these informations were more public I think there will be less > annoyed posts in mailinglist and more constructive critics / ideas / > patches. > And there other issues arising from the lack of communication: How exactly bugs / incomplete features are treated in FreeBSD ? Many times the public gets the impression that save for the show-stopper bugs, or bugs which affect the employers of FreeBSD developers, they don't get too much priority. If any. I talked before about VIMAGE and the bugs surrounding it. Some of those bugs are there for years. Yes VIMAGE was good enough, and as was told before in this thread a success. I am not contesting that. Yet not even today all those bugs and memory leaks are fixed. Patches for some bugs floated around, some where collected some not, only god knows. I heard that now for FreeBSD 11 the FreeBSD foundation forked some money to get it done. I hope they will. Another example is the autofs mounter. The prject was marked as complete by FreeBSD foundation in 2014. Last I tried it to autmount removable devices, it left directory after directory in the autofs managed directory. This is known behavior. It also did not worked as it should ??? (show it manage removable media correctly ) changing CD/DVD media disks. Presumably In could have somehow manage it to work by making yet another scaffolding of scripts as a questionable glue between devd and automounters. That if devd receives media change notifications. I dont know. If not I could patch the kernel, yeah. But it is just much to simple to not bother at all and use OSx. DRM drivers ? Done, but more or less in the same state by years. At least not important in server space. outlining those issues should not make anyone feel criticized. Things are what they are, maybe its better to think what are the root causes of issues like those outlined before. Does the project lacks manpower ? If it does maybe the developers should do something to attract and nurse more and more potential people. Are those issues you dont want to work on or you dont have an agenda to make them bug free and work orthogonal? No problem, make a statement and say .. we wont ever do this , or it will take 6 years ... or whatever. It is not helpful to complain that people do not appreciate your hard work, becuae ppl do. Also not helpful to complain about tones which should be toned down by 2 orders of magnitude, peasants and castles. It is also not helpful to complain that people oppose progress when you are pointed some issues.It couldn't be further removed from truth, at least in my case. But I think most ppl on this list want progress. At least this is my impression. Too much of Unix is badly stuck in the past. From owner-freebsd-current@freebsd.org Wed Apr 20 12:58:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99A14B1692B for ; Wed, 20 Apr 2016 12:58:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6EB16D9; Wed, 20 Apr 2016 12:58:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 75D26A96; Wed, 20 Apr 2016 15:58:11 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> To: David Chisnall Cc: freebsd-current@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <57177CDC.1010701@FreeBSD.org> Date: Wed, 20 Apr 2016 15:58:04 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GdPbdku6xhpdEUHFtk8mnNAvBUS8c5cSx" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 12:58:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GdPbdku6xhpdEUHFtk8mnNAvBUS8c5cSx Content-Type: multipart/mixed; boundary="LgaeI4LQL5WdCG1hUiwk1bsEPV1MF9qnK" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: David Chisnall Cc: freebsd-current@freebsd.org Message-ID: <57177CDC.1010701@FreeBSD.org> Subject: Re: [CFT] packaging the base system with pkg(8) References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> In-Reply-To: <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> --LgaeI4LQL5WdCG1hUiwk1bsEPV1MF9qnK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20.04.2016 11:12, David Chisnall wrote: > all of the complaints in this thread have been about the UI, not about = the underlying mechanism. =20 Nope. And there are (small) thread in other mailing list with very big concerns about underlying mechanisms, which doesn't have any attention: https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-April/000183.htm= l It is very worrying to see such reports without any reaction from developers in one month before release. If there is one year till release, it is nothing. But in one month we will have code slush, and after that =E2=80=94 release, which should be supported for several years= ! Also, suggested (and totally ignored in discussion) mechanisms with overlay packages is not UI, it is underlying mechanism which could be very useful. Again, I have nothing against good package management for base. But what I see now is scary, if you take one-month-before-release in account!= --=20 // Lev Serebryakov --LgaeI4LQL5WdCG1hUiwk1bsEPV1MF9qnK-- --GdPbdku6xhpdEUHFtk8mnNAvBUS8c5cSx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXF3zhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePv/MQAKzbOlqCjTKR05kdLn0SFNcX 0bktBIgjGJvZpR/8C/yZobAB/cSxL/sGUmgC6SNHJ0Mc1RYoXw46iXeOFPqXUgMP mJDXc7Z1PUmZrkTha2Rm5w9XdB5HEk1HZW8xjyuq79IIMkzq5n7wpYi6Ii8Dd8Df mrAFYlrCNqOuiPfj77TOyybjhuGi3dXCte/tsjNXZz7pmJYDfJHf6r4GAh1G2U3M VUFCHiaxeEnb1pVQ3dtpBgqPdUyNFCYYyq1/ipN7tKRyBlKKnM/t9j4clWjZnEdo yA8AXTknYVMWciEJfcJcgAJRbeWoRtWm0MInMUD0GWAS/SnQqvr+KvJq2lA5gEi6 fLrLRNLpvCTF9a0Tk1Dr/+CKmE6gU1+s8Hu+HYA27mrbKBlnGlNkcFNOYh5Kvr8n MkZdBZDq1gWUC1d0Dtuj0PD8S/9qwAMU//HeXPx2lnnYojUOcdGVWSIa6CQK0v+e /rba1rm9aV4pIFpRKxn/RHFHTzSwCOCuAoOjZoQsh8vBGOpEYzY/XvWU7cMkAic6 PLAXT4UFtiO4iiJl3d9l8FSVaEdmBGJYDuAcm0bNXgiVhQ5UTjzne2CNEQ3gKhAM saa0h1hoy8BMpKkuSGnKhYJ9Wu9iJeByxhix9JI9DOcqT1bS5dqtNX8zHua8N2JW 2LHdyo+9+qDTxuW7/ltu =YFTK -----END PGP SIGNATURE----- --GdPbdku6xhpdEUHFtk8mnNAvBUS8c5cSx-- From owner-freebsd-current@freebsd.org Wed Apr 20 13:16:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93B88B16EC0 for ; Wed, 20 Apr 2016 13:16:44 +0000 (UTC) (envelope-from aberg010@my.HennepinTech.edu) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34B9E10D5 for ; Wed, 20 Apr 2016 13:16:42 +0000 (UTC) (envelope-from aberg010@my.HennepinTech.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myhennepintech.onmicrosoft.com; s=selector1-my-hennepintech-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=awayV+cUrArNwGlapaYDAcmq6vcPlyKbLov3TBrandk=; b=I4naCnlH+/8NxvrgXgSHtWnMwZRPsABUmnJAg/f0Ww43W0lnGXBZ5GYjWI6z4W0eGy1Rg3+UaW7HqcFVt9tSDXEd60SfoX6cv9bWU187G3xb0L/33Q4lJUK0qThFpMaTbytsRb/kvBr4d9cl1s3Q5e3W1Uv2JOB66kNmavHVtUw= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=my.hennepintech.edu; Received: from [IPv6:2601:440:c000:982::1:0] (2601:440:c000:982::1:0) by BLUPR03MB1489.namprd03.prod.outlook.com (10.163.81.19) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 13:16:39 +0000 Subject: Re: [CFT] packaging the base system with pkg(8) To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <57177CDC.1010701@FreeBSD.org> From: Andrew Berg Message-ID: <57178134.5080009@my.hennepintech.edu> Date: Wed, 20 Apr 2016 08:16:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57177CDC.1010701@FreeBSD.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [2601:440:c000:982::1:0] X-ClientProxiedBy: BLUPR14CA0068.namprd14.prod.outlook.com (10.163.209.164) To BLUPR03MB1489.namprd03.prod.outlook.com (10.163.81.19) X-MS-Office365-Filtering-Correlation-Id: 6de6b0bd-9212-4790-5784-08d3691e027e X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB1489; 2:MQJsOlfPhVmJrQZCeK9adWnWBW8jxe1+niFvwZdeNaoaJLXkukLjGM7DVSAeh6Z1HLIX5DUontHXLHAA1Ewx98UXI6HuXzXQAwJMAo7bnlIJcPZaj1TZZLv/G8kmm6PQoADXdLvFAXA8c5ATOTwKer0tIrdshtyNRCkEPX7iQR6mwRTK2ctuG6SoqXGiEMsz; 3:K75WTeEpVMuaZ928+pB7DQpJMcz4yWWjhYz04ZhUNSLn4iu5ymsMl4hwPG644D6RBtMW/bH6Lqu2FkZuDxNdv8a4kwG2FNVaVprjkN5/SKhIYV+wlVg4eO8ZusIU+qmn; 25:mYz5kh8B1KO7jBLNa4DDnEVWJwb/khCEh7PegLaMmMP787VIYaVVm8EdLZ++v+QguNwJRrhZzsrqG5MbeKMY+ZUnXrkgOPGZhOOaUIU2JZ4NwSB5ZlF6rAKXu3OJALDk9QNa4DbVunkQII6i4Rq+AKXXiguCoGGZJkQ96LNmem6zkLA88QFZ5IhdbsZGDQsIqgG8YP90cpezDgLTyEp0ISGxe+9G2d6yjUY902EJLaAV4EkarSECa9pxRTMAYiz8KFZ6wCpKRgblbubtEXIShSUeNqIaneKpeGWKHbt7E4kVWsjLGuJ5hIE3WgjDPGeuFM7rrW2Er3Hrq8g62oZEBA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1489; X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB1489; 20:Hj1qz9b0YjEDqhUSWAHP7/VdL0+ceNBDJ1swdzNBV+ChKYslekHdyUENcCnPR0iIURWqEp6qb57yo3mgG5EifzGHPJbwxdQntZXce6N/hYqIffAIri+k9yAZlSITCLKBoOIpkvPbG+Blv0i3K/DzI4Osa7VUZ2e3eQLR3EwzVi5/HdQ2uvrCI7l2tBK65zKyPtPMJzoVjOrbsqK0D05qTsPRUXO7R0CW76+d+RfmxZ+qnyrTG9HFqmOkHLUT7/vdFR10RKuU+55jdLUBRIc4kVi3/pkv2R13fHqXcXYP12FU9S4GeRBDrMyYsvbF+TZHLBnO5LCNP8+gxaV3HCiZ/iQXpzccGMRZ/NKCYkJvYZbqbolxv9LTPJOL8tH3ZXOztk4lcjxFeaWf8uMt/FlrUGo0VemzDgrhlOf4Hdftr+T/ulhW3AEdyLvjxkgUwIsrWRs/ICoRZ6GDUDJOoGMjSwKPR/cYN/a+1Ye/RQXAyumNN6RYinNc2kJ5HeLcoMTv; 4:RnU5LahiBGldqhzO2dvWfGR405BUgnvatrAuHYIpKB1seg7mySyVzbTMEK2XGIqzH0izYDAD9n4MY79jiEeZ/WkggcIHiaQSm+8PORIINCUxyzJvW94vMjrBgzYqTZ9FQkhHYYKLc271JSSL+FMTlqdx6ONbexX/f6936lbX+Tz99hu/4e/XLfJad3MqZxjQfcyQaD3epTVmeE8JDde3pj5Bj80l7oP5rTxYAw54EfQ+iqVRzbzkV8KQrWUMBoQ79eoyRDteuJV/Oh3dRzJvfoGmj3nl9gOM4ZQmpdVN4C3Iv9hQR0nJKmO2vTi1pTrK+juGz62/eP28iqakZRTtha9zcl6Cgxs75EIdbTfLx2BDSe6qPcdM/552+D2bwNJwFUSmZOaM0gDVJEeQVGbnhw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR03MB1489; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1489; X-Forefront-PRVS: 0918748D70 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(24454002)(2906002)(450100001)(92566002)(110136002)(4001350100001)(189998001)(107886002)(77096005)(65956001)(5004730100002)(2950100001)(6116002)(1096002)(586003)(65806001)(47776003)(65816999)(93886004)(42186005)(54356999)(76176999)(87266999)(81166005)(23676002)(88552002)(75432002)(2870700001)(86362001)(50986999)(89122001)(64126003)(5008740100001)(50466002)(2351001)(117636001)(122286003)(83506001)(89472002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1489; H:[IPv6:2601:440:c000:982::1:0]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjAzTUIxNDg5OzIzOkRpUHVDVDhJMm1YZ3h4b2tBOWpPN1B2bDFC?= =?utf-8?B?cFZLc0VGcFVNZllWOE9sMEFvenJmWk81NE5FNG0zLzBPZXE0NHFiczJ4LzhR?= =?utf-8?B?eXA2aTI1dG1GaHRSekRLbTZmNHpTR2NNbEpPTTBJU1dkZkN2aE9hUGRTc3ZG?= =?utf-8?B?Zlg2UXZuVFlPdHNqbWR2czhxYXFoUG5FZngza040Z2NyOFlKYlBoeUZ0bjlO?= =?utf-8?B?QzdlZldZM0p0ejhHM0laZWV3VGwzUkZhTkJnQzR1UTRHbUpMVXhvZWdzRlNE?= =?utf-8?B?ckxrMEVOWHV2TC91NjcxWHVsN0NIbXpFdkhPbjZzREN6NmFTYVZLVlRZc0ZW?= =?utf-8?B?QXFRRWwzV0dNUTQ1ZWtJWUlUOCtxNS9rd3U4b3ZSVXdrbmdPdFRlWVl6SllQ?= =?utf-8?B?K1RodzR1Z2lhVExNYnVZRERaaFlJRlYrU0JGaS9Rd1JiNHdtclc3Sk1wdnQ5?= =?utf-8?B?THpCL3ZSVWxOeU1CNVRObGdOdmYyY0MxaUhweHdrUStwVHRidVJzblN0dXlV?= =?utf-8?B?NW9FdGlXOUtlUzRzYmZkVmg3QWMzUjNKMnBVUnBtN1RXaEtYZjQwSjJPT1cz?= =?utf-8?B?ckVKWitDVndqVE1VV3hrTW1weHFkK3NzR3dtS3NLQlZWMVJRMXk3Ymt5WTlJ?= =?utf-8?B?U1JoUzBLN3hwY21haWQ3ejlEUHhueHhOMVRLQ2kvRklYQTM2aXVibG9EcmNI?= =?utf-8?B?OVl1MHA1VWFtVHpDYnZkTURzRmw5ejN2NzNza1UxTXNRM2czaWxKQWFUUFNh?= =?utf-8?B?SVlGTXUzWlU1QVlNSEVPWWhqbmhrR2RyUERDbG5vM2V6ZmliU3E4c3B5VHky?= =?utf-8?B?Vi9RemFHK0hndGsyYy9SZkFBWEdaOVlsSGFNUm1aaHJIeGVtZzBIM3lYMzBj?= =?utf-8?B?a0dpNjJOd1pzalBrQVVNaGFHU0JmUGJ1VHgvOGpWcmRPaWVzMWgxdWd1bXNZ?= =?utf-8?B?elVVOG9nVVhIU3dCR2Zrc2xGWTVoZ1NZemRyckcxcUE4MW9nUVNVck12K1pI?= =?utf-8?B?M2RycFFscVhnOTRQYWRHQU5Pa2krUXBsR1J0VEJhZDVNalNDb3BPYjJqYXJX?= =?utf-8?B?b3A2SUVUM1Q5M2JPUXhVL0dOQXNpWmZqODhNSWNHVWVQaVlxeFozdjRQN1JK?= =?utf-8?B?RVlscUdiTENGR3pGdk5UMGZ6Q3k1cENHS1VRWFpERm9LV2pBUHhFZTBzaDBW?= =?utf-8?B?WFF2Zy9sTk9BbVphNWJjSnRiQjY0U3RYbjdnWVFYV3JnOTdMT200RUszMlFv?= =?utf-8?B?NmdXYzR1SGp2OXRMN0k3UUNGNGQrak5UZE9zellybGxleHI2WlNuU2Z3T2pB?= =?utf-8?B?ZEhCUU0wY2d3d3VQanFGL01YNVZvTTlWVWYxZk5uNzR4eEphTkNBSUhqanh5?= =?utf-8?B?aWFJU3dqcTFUTWRVSXEyV3dQM2l4WHVKYjZYS1lHcDdnS2FleGdKTlNINHpt?= =?utf-8?B?aXI4dCtWN21JNG5yVDF2NTIrK08rdGJ6aUZ6MnpBbUN1L1pPZ3Jobm1oejcy?= =?utf-8?B?ejBpUT09?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB1489; 5:JKeUhNnlQR5eKinkeQp4mSrJDm12XAJAAzKpoj9W4x5ai83K2e9BMNbG1Qxd9PXHG20/78xCgtpv4lovusWjAUAINyU8NFa+S8ore9U37KUwU3mBc5cg83oZDGo+C1p+WOpBvZTtyqERlqHgbodoS3fP0f8Rpr2Dr8QNuykt++A0nSw99m+kZ3FiJ5aAMU98; 24:IH5dCTfwEfRMuVCCiUtXLL6t+9reeI65Hh3EmbSRKQr0q/Fbh1hUrsujqdcY7kP9DPsTZkubI6qJNf7YlIkLIe1PrLsaAnOSJmoekHdBBHw=; 7:hRo50h43Z0+xmWA3sOdBiF3SyE2QH3r0JMY5AlRB6GEB862s4BCU/8QOAjKzIsRTkZp30Oe637uZI7FjYpY637pKKOic3qq0UzRWpVhtWb2Cb/5iAoNPvqjapiqPCCjgoFeG91MufNG0cRoeblzgL4u0vTK3lnnj5iXtab5amMfCbZbBQxFKDtTd/l8yYQcxraRXj9Ekm2wyfzT4hLsCyAtfGptRYpRLbNErJeTG7L0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: my.hennepintech.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2016 13:16:39.9734 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1489 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 13:16:44 -0000 On 2016.04.20 07:58, Lev Serebryakov wrote: > It is very worrying to see such reports without any reaction from > developers in one month before release. If there is one year till > release, it is nothing. But in one month we will have code slush, and > after that — release, which should be supported for several years! > > Also, suggested (and totally ignored in discussion) mechanisms with > overlay packages is not UI, it is underlying mechanism which could be > very useful. > > Again, I have nothing against good package management for base. But > what I see now is scary, if you take one-month-before-release in account! > You mention code slush, but keep saying one month before release. Code slush means *new features* are *discouraged*, not "freeze everything and let it sit for months without addressing any issues". Release is not planned until *September*, and if it is not ready in September, then the release will be delayed. In fact, releases are very frequently delayed since the dates are always estimates and never deadlines. Yes, we are getting somewhat close to release, but there is still time. Also, packaged base work was supposed to be complete enough for wide testing much earlier, but development was stalled for a while. Also, how much response do you expect in ~17 hours? Developers need time to sleep, do their day jobs, and formulate a detailed response to a detailed email. There are certainly issues, but this is not something that is going to be rushed into a release in a month to meet a hard deadline as you imply. From owner-freebsd-current@freebsd.org Wed Apr 20 14:53:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39B3CB157C9 for ; Wed, 20 Apr 2016 14:53:15 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 13B311B4C for ; Wed, 20 Apr 2016 14:53:15 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by comcast with SMTP id stTXaR2RN9sFTstVBalv7D; Wed, 20 Apr 2016 14:53:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461163993; bh=U/+6wimtIZ9utyORz6i6wM/Qo+LmsAsbJQUPJJbFmdQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=c4BehaDrKICSNJtHhiPE3sQHncmYlCynY2FpwncfSiJY8m/OHBQeLZ6lcGQRT6Tvj LO5EVPWwdB95oBNtPYAK/5WF2tQDrSJ1StefZICjC3mjCUhDB3g9p/QIGE3D3bfAlm vbUoLFbs6qhG8qZCGE6px/ZYDGDq0r6ap5fdCap93AACJiPzbPGEVKYIYcs8kaBlIT FSgixwkKKvHumN9KpEMHsvT/8WoBctV0n2umwcgcbaRhc+4nlcQ/mvjSeELZ1ZOSyp Xc4W+VT2w3JCIzB8U8+JYBAmNXwR3aUx3tiufR87pOel2vafPtUxOrp7S8Z+v4cL32 pSFWlk1+qLKXA== Received: from [IPv6:2607:b400:24:6002:d4f4:75c1:86a:11f8] ([IPv6:2607:b400:24:6002:d4f4:75c1:86a:11f8]) by resomta-po-06v.sys.comcast.net with comcast id ket21s00R4k9gyM01et7fv; Wed, 20 Apr 2016 14:53:11 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Paul Mather In-Reply-To: Date: Wed, 20 Apr 2016 10:53:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0C8A7C64-8D7C-4B2D-9387-294FBF049941@gromit.dlib.vt.edu> References: To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 14:53:15 -0000 > Message: 20 > Date: Wed, 20 Apr 2016 12:48:06 +0300 > From: Slawa Olhovchenkov > To: Dan Partelly > Cc: David Chisnall , Julian Elischer > , Nathan Whitehorn , > freebsd-current@freebsd.org > Subject: Re: [CFT] packaging the base system with pkg(8) > Message-ID: <20160420094806.GJ6614@zxy.spb.ru> > Content-Type: text/plain; charset=3Dutf-8 >=20 > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: >=20 >> IMO, the number of packages per-se is not a problem as long as you >> can manage them without arcane commands, aliases, pipe - filters, >> or scripts. (they all have their place, but less , the better) My >> point is that I don't really want to keep on my head a Unix hacker >> hat. I (and presumably many other humans ) like simple things,which >> allow me to type a short command (preferably the whole system should >> be simple enough to be explained in one-two pages in handbook) , >> wait for completion, and get on with my life. >=20 > Yes and no. > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? >=20 > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: >=20 > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. Superficially, it does, but in reality it doesn't. I can grab the = source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* = settings in /etc/src.conf and build a kernel and world and end up with a = system that is missing a lot of functionality that is ordinarily present = with an empty /etc/src.conf. That missing functionality could be the = reason for a problem I am having with my "10.3-RELEASE" system. That is the reality of FreeBSD *now* and I still am able to get help on = FreeBSD mailing lists when I have problems. The case of a moving target is truer of those who choose to run -STABLE = or -CURRENT. If I say I'm running 10.3-STABLE three months from now, = what version of the code base am I actually running? Sure, now we have = the SVN revision number to help pinpoint the version of the code being = run (setting aside the effects of /etc/src.conf), but back in the days = when FreeBSD was in CVS we didn't have that nicety and yet people were = still able to get help with problems running -STABLE or -CURRENT on the = mailing lists. A packaged base is just another way of describing the state of the = system. People on mailing lists will still be able to help people fix = their problems, but they'll just use different information to pinpoint = the precise components affected. Arguably, a packaged base will make it easier to help people, because it = makes more explicit the dependencies of different parts of the system. = It's been my experience that the interactions and impact of the various = /etc/src.conf settings are not entirely well known, at least to = end-users. Cheers, Paul.= From owner-freebsd-current@freebsd.org Wed Apr 20 14:54:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A16F1B158B4 for ; Wed, 20 Apr 2016 14:54:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E2C81D36 for ; Wed, 20 Apr 2016 14:54:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1astWC-000HpF-Ks; Wed, 20 Apr 2016 17:54:16 +0300 Date: Wed, 20 Apr 2016 17:54:16 +0300 From: Slawa Olhovchenkov To: Paul Mather Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420145416.GB67390@zxy.spb.ru> References: <5DBC1E44-E562-4A5B-9DD9-47C1C62AFB9D@gromit.dlib.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5DBC1E44-E562-4A5B-9DD9-47C1C62AFB9D@gromit.dlib.vt.edu> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 14:54:20 -0000 On Wed, Apr 20, 2016 at 10:43:08AM -0400, Paul Mather wrote: > > > Message: 20 > > Date: Wed, 20 Apr 2016 12:48:06 +0300 > > From: Slawa Olhovchenkov > > To: Dan Partelly > > Cc: David Chisnall , Julian Elischer > > , Nathan Whitehorn , > > freebsd-current@freebsd.org > > Subject: Re: [CFT] packaging the base system with pkg(8) > > Message-ID: <20160420094806.GJ6614@zxy.spb.ru> > > Content-Type: text/plain; charset=utf-8 > > > > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > > > >> IMO, the number of packages per-se is not a problem as long as you > >> can manage them without arcane commands, aliases, pipe - filters, > >> or scripts. (they all have their place, but less , the better) My > >> point is that I don't really want to keep on my head a Unix hacker > >> hat. I (and presumably many other humans ) like simple things,which > >> allow me to type a short command (preferably the whole system should > >> be simple enough to be explained in one-two pages in handbook) , > >> wait for completion, and get on with my life. > > > > Yes and no. > > While number of packages don't see outside internal -- this is > > irrelevant. > > After possibility of update individual package -- nuber of packages is > > impotant. > > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > > 11.0? 11.1-RC3? How you name it? How identify it for take support on > > forum or mail list? > > > > How name system, updated all w/o compiler? or only some services? > > Currently we have simple naming: > > > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > > This is shortly and clearly identify system to anyone. > > Superficially, it does, but in reality it doesn't. I can grab the > source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* > settings in /etc/src.conf and build a kernel and world and end up > with a system that is missing a lot of functionality that is > ordinarily present with an empty /etc/src.conf. That missing > functionality could be the reason for a problem I am having with my > "10.3-RELEASE" system. Identification of custom builds is another problem and now we do this by contens of src.conf, make.conf options and kernel config file. This is enough and I am don't see necessity for change. > That is the reality of FreeBSD *now* and I still am able to get help on FreeBSD mailing lists when I have problems. > > The case of a moving target is truer of those who choose to run > -STABLE or -CURRENT. If I say I'm running 10.3-STABLE three months > from now, what version of the code base am I actually running? > Sure, now we have the SVN revision number to help pinpoint the > version of the code being run (setting aside the effects of > /etc/src.conf), but back in the days when FreeBSD was in CVS we > didn't have that nicety and yet people were still able to get help > with problems running -STABLE or -CURRENT on the mailing lists. With CVS we use timestamp (as for csup). > A packaged base is just another way of describing the state of the > system. People on mailing lists will still be able to help people > fix their problems, but they'll just use different information to > pinpoint the precise components affected. How identify this systems? By 800-line lists of package versions? > Arguably, a packaged base will make it easier to help people, > because it makes more explicit the dependencies of different parts > of the system. It's been my experience that the interactions and > impact of the various /etc/src.conf settings are not entirely well > known, at least to end-users. Some /etc/src.conf settings is compile-time options and can't be done by packages. Kerberos, for example. From owner-freebsd-current@freebsd.org Wed Apr 20 15:09:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4782FB16240 for ; Wed, 20 Apr 2016 15:09:01 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28B301B3D for ; Wed, 20 Apr 2016 15:09:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from dhcp-10-248-116-179.eduroam.wireless.private.cam.ac.uk (global-5-143.nat-2.net.cam.ac.uk [131.111.5.143]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u3KF8vZ5030150 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2016 15:08:58 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host global-5-143.nat-2.net.cam.ac.uk [131.111.5.143] claimed to be dhcp-10-248-116-179.eduroam.wireless.private.cam.ac.uk Content-Type: multipart/signed; boundary="Apple-Mail=_21B2E831-4953-4AE7-9783-9056CCD8C6B9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: David Chisnall In-Reply-To: <0C8A7C64-8D7C-4B2D-9387-294FBF049941@gromit.dlib.vt.edu> Date: Wed, 20 Apr 2016 16:08:52 +0100 Cc: freebsd-current@freebsd.org Message-Id: <36608F1A-E677-49D5-BE5C-E2BC031DC945@FreeBSD.org> References: <0C8A7C64-8D7C-4B2D-9387-294FBF049941@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:09:01 -0000 --Apple-Mail=_21B2E831-4953-4AE7-9783-9056CCD8C6B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 20 Apr 2016, at 15:53, Paul Mather wrote: >=20 > Arguably, a packaged base will make it easier to help people, because = it makes more explicit the dependencies of different parts of the = system. It's been my experience that the interactions and impact of the = various /etc/src.conf settings are not entirely well known, at least to = end-users. In particular, with libxo output from pkg, we can get a machine-readable = detailed dump of all of the base system packages installed and provide a = single =E2=80=98system dump=E2=80=99 command that includes this, = relevant information from dmesg, and so on for bug triaging. David --Apple-Mail=_21B2E831-4953-4AE7-9783-9056CCD8C6B9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDIwMTUwODUyWjAjBgkqhkiG9w0BCQQx FgQU7AVziIpZYZ6V5ltAZdnW13vqmp8wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBAKU9dKGB8shHCp6fFl7Y0bnoh98BX755aAdpbePpz3fmo43dTkXRdsCP UQ9zG8PfLQ9uV6JyRGyRMLKu7BCR1GY6K0YEDDwP/UOlHbF+IAlSKcV2x3gle8HyBYXyKH7rnTfG WaLLmWHxGanHU2oW3IMJwQnap4dEK508NbsjnzH6gW2tpwS4kJ1STIU/HF+xLLv1e83zPyM16Zjp Z+5SxbTOFxEQfsWxZ3zuhar76W4T1qiU+vlQUtpqLTkJto/C9ic2dEv45zdGfsHn1JXCJ468+0Fa a84GSW8LzCiWRQu3bp16cnQmjHsAb5fiRNIKQBl3HrEmr01r4GWgLGqlBOQAAAAAAAA= --Apple-Mail=_21B2E831-4953-4AE7-9783-9056CCD8C6B9-- From owner-freebsd-current@freebsd.org Wed Apr 20 15:13:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C432DB16490 for ; Wed, 20 Apr 2016 15:13:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x243.google.com (mail-ig0-x243.google.com [IPv6:2607:f8b0:4001:c05::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 954351F48 for ; Wed, 20 Apr 2016 15:13:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x243.google.com with SMTP id fn8so7105599igb.2 for ; Wed, 20 Apr 2016 08:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=1f6BUOa1jn2+Ypqo+Yg8W36OTONJ1cVG77twfT/K5k8=; b=l8q0paVmzutgt+SFZ1yZ5vn+ikUgBzrQrWm3cGzGpdYL4GmAMH8jwQ4qhsnU+9dCar pTcEwPtlIVncUfvYmNeeWEOl78R21ZrW2J1J+evuXXNkg4oul2Qt/lR299BwV9IjbUrb 1FWtRLIrxTEmMZs0QzDiEsEnBIJhdvwpRNzDn193koFT6+R4DHKcfUN5nn/0y6kKeNju 98Rn8n9Jv5QEdiFCt+GvmabQLjFxFlqHJR1BxQ+PYOikAlkpdw79hvnao3se3Qt+tUQa aClWBU5KXpOAOEma+hBZiKG0VY2PAttpYkzzD/wfro/ctRhwa97+hw52G8xbxTVSU4+A cwUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1f6BUOa1jn2+Ypqo+Yg8W36OTONJ1cVG77twfT/K5k8=; b=cyqi/gmk08QR4xJYHxG1d/uZIjBwX0/htwTgyR5XOqpfs3/myRCN/qLdS6HH7CRWAb ujS3JtOWL4pOFWZF1jSce6IVuovwPXdTWSOWoG/nFHrq9ccg52MOKbqD+P6hDAUTHwey fYksKYc8w7xyXQRY1NaqbIn/Dqx8EH3i3bd+iIo/A59weu3SyuhSHvTgjXLbqWoRzmOL iUcXh9T14v7VqtPbtbUFJWlZ9qOZNGoF01+mz5UhLgAEUO3rRd6rPjv/dt3VL4ZXsbhe SKQiS1ZZxHwQvrtR28cErSGOkPh+enu5XW9INQgcwNJCRHRMtGHV9UpRIoq7qvF9QDQ4 Ps4w== X-Gm-Message-State: AOPr4FUiAQmJaPMplpGbhQ+uOMiPfi8naWTOI6BevIvC+O+2QNwca3bGDrFjODbxB19iqyRKFUrUgxdHsv3S5Q== MIME-Version: 1.0 X-Received: by 10.50.150.1 with SMTP id ue1mr4152567igb.52.1461165231584; Wed, 20 Apr 2016 08:13:51 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Wed, 20 Apr 2016 08:13:51 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <0f6a84a9-4bae-4dc1-4f6e-169c16232cf6@gmail.com> References: <0f6a84a9-4bae-4dc1-4f6e-169c16232cf6@gmail.com> Date: Wed, 20 Apr 2016 09:13:51 -0600 X-Google-Sender-Auth: QxAeTWLKgKc9dbyrk4Tx7Jg8_3w Message-ID: Subject: Re: Heads up From: Warner Losh To: Johan Hendriks Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:13:52 -0000 On Wed, Apr 20, 2016 at 1:10 AM, Johan Hendriks wrote: > Op 15/04/16 om 19:30 schreef Warner Losh: > > > Also a horrible name. It's a generic I/O scheduler. It can do lots of > > things. I keep saying that, and categorically refuse to name the more > > expansive scheduler anything that's so limiting. > > > > Warner > Thanks for all the work on this. > > One question? > > If the scheduler can do a lot of things what are the defaults set to? > Are they set to the Netflix load or more like the behauvier of a > standard FreeBSD before this patch. > Mostly neutral. You have to turn on the different steering engines. However, it does favor reads over writes, which may be a problem for write intensive work loads. Warner From owner-freebsd-current@freebsd.org Wed Apr 20 15:34:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 364E8B16D52 for ; Wed, 20 Apr 2016 15:34:42 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C41181092 for ; Wed, 20 Apr 2016 15:34:41 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id u206so88026815wme.1 for ; Wed, 20 Apr 2016 08:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oWoq19UFKvfiqPs8fve7QczteuQdafSn7/qgsqx2SgY=; b=EXCXOguxp9IDxONxlsT5b31sS3woYYnd1CDytbrWv4EfaUY0Hix0fBlIXKqYXEyPWr 5P9aGt+CqHSHfFStMI2x2ZNEeRGXWgssDcxEclwUynm1wnGYPo9gx+NWjpE2i127MYRB 8CqFo6J0QEFDCB3k9bPYxIbYMyGjKg5P+p+f+lo0bGiqqyCjF4O6M6Tf2GsZOf7XCp3D 2zK4wzFLMPO7eYKwbp6bp4Jj9xe1fAFXBSLK+U4eEAhq213Uz/a2XBdIPXK/VVUBnY6R d66ttYgGu7MlyIHDamOQHYX4CH6fCYs8CU1BEeWdL/9MXZ6/LWpRQNb9L8bRpsDdSwQ9 QY3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oWoq19UFKvfiqPs8fve7QczteuQdafSn7/qgsqx2SgY=; b=jtjtBYQcuRSegCUWo4PxdSz4pSysSj4DAN5TLSlVbVB0cu2+vtSVgfwuuqiCToJz9i pI0fJwo/lENwI7u7H5yPGmHc24F395+Q3RqheLzTNMmDIESmKOz5GrREfNQw67Zy9yIa HkeUnZfcka+oHFVlpgs7tQrYtuwPkfBd+0Vc5hjWIK/wXsql+X5W/mkoRynIvmnhAk0x w4Q0AjDh33kCATzk8QoBSWyNq9ZKqXLUJEvNwCWfDoUNzyVdx3oDCn0DXhT4fijT/CD6 mbbXCMrRNX41mrmk0O2wGBQLeMQzXWptpe1qNqUaSyxUTE4VCW6ci7FXfzfmzOjopJDR Ep7A== X-Gm-Message-State: AOPr4FVk6HA7bWI8PGUbKlQt7TZhpIrU+w+PrOJGX0pxpZrjPwyzk2J/Sm+kgYVpFSgZNi8Q4nK+vbb05ylCqA== MIME-Version: 1.0 X-Received: by 10.28.22.65 with SMTP id 62mr3141168wmw.32.1461166480442; Wed, 20 Apr 2016 08:34:40 -0700 (PDT) Received: by 10.28.21.137 with HTTP; Wed, 20 Apr 2016 08:34:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Apr 2016 18:34:40 +0300 Message-ID: Subject: Re: OCZ ssdpx-1rvd0120 REVODRIVE support From: Pavel Timofeev To: Rainer Duffner Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:34:42 -0000 17 =D0=B0=D0=BF=D1=80. 2016 =D0=B3. 13:44 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0= =BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Rainer Duffner" =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > > > Am 17.04.2016 um 11:05 schrieb Pavel Timofeev : > > > > HI! I've recently got a SSD device. Yes, not a disk, but a device. > > It's called, i. e. one of the first REVODRIVEs. > > It's a PCI-express card with two embedded ssd disks about ~ 55GB size. > > And it's a raid card. Fake software raid. You can set it up as a > > RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured > > or set it as JBOD or something else. > > You just won't be able to boot from this device in that case. > > > > > > It says =E2=80=9ELinux support planned=E2=80=9C=E2=80=A6 > > on the product page. FreeBSD is not Linux =3D) Anyway I managed to install Ubuntu on it. Not on all of the configurations though. > > Tried loading the nvme(4) driver at the countdown? > > https://www.freebsd.org/cgi/man.cgi?query=3Dnvme&sektion=3D4 > > It's included into GENERIC. But no /dev/nv* devices are found. > I=E2=80=99d suspect the Intel SSD 750 series would be a better choice=E2= =80=A6 > Well, if I had a choise I wouldn't try to ask someone to help me ;) I'm not a developer, but it seemed to me not a really hard work to add full support of this device to FreeBSD, because it already work partyally and detects by graid. > > > Rainer Probably it's better to attach graid list/status output? From owner-freebsd-current@freebsd.org Wed Apr 20 15:58:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 121CBB15ADC for ; Wed, 20 Apr 2016 15:58:17 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 D90F31F54 for ; Wed, 20 Apr 2016 15:58:16 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id suW3aQAXLpUrhsuW7a3SD0; Wed, 20 Apr 2016 15:58:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461167895; bh=qaW9sGa9onnpAl8KQDRfWqdTmpubaFUMfPF+J93yA9s=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=ChjmmtLDeWTEBBVQyyWuFavvfvTrC17txS89SuhP8m8aNCsMp6dC1jMDivPf00jQw Kzoogw3h1zBMurCEetA2JXxrk2bawr2sehdyGsONu0MxvLlBBoqOmhbtdqF8vXxE/w QRftTHHVYxZ9+J+HHE9Zi9c0+6TeRGpZxwcmfmqHpF5Xl1EtmUYYewkKWL/7swQA4V e/KwR+EX0VY5KG5ZbpekTyLGFbs/iFyaL999A0VFm1WrM2qBDiuzfiIeL/YR6MBf4A thH8Gdp1VZ+8Oluas4QHrnmhimimsTCCmo+ykQYTqAcNc8O/fp4r9dRGkbmQUPhvW4 xNHB4C+prlfww== Received: from [IPv6:2001:468:c80:a103:f944:bead:def6:df3b] ([IPv6:2001:468:c80:a103:f944:bead:def6:df3b]) by resomta-ch2-19v.sys.comcast.net with comcast id kfy01s00e1BqwLc01fy5mH; Wed, 20 Apr 2016 15:58:12 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Paul Mather In-Reply-To: <20160420145416.GB67390@zxy.spb.ru> Date: Wed, 20 Apr 2016 11:57:47 -0400 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5DBC1E44-E562-4A5B-9DD9-47C1C62AFB9D@gromit.dlib.vt.edu> <20160420145416.GB67390@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:58:17 -0000 On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov wrote: >> A packaged base is just another way of describing the state of the >> system. People on mailing lists will still be able to help people >> fix their problems, but they'll just use different information to >> pinpoint the precise components affected. >=20 > How identify this systems? By 800-line lists of package versions? In my experience, troubleshooting usually proceeds from the description = of the symptoms. So, if someone says, "I just updated and Sendmail has = stopped sending e-mails," or "I just updated and I can no longer SSH = into my system," then the logical question is to ask what versions of = the packages they're running that pertain to those binaries. In other = words, you start at the symptom and work outwards from there. In my = experience, it's not necessary to have an exact inventory of a system to = be able to solve a problem with it. A tool like pkg makes it easy to know which package is associated with a = given file and also which packages that package depends upon and which = are dependencies of it. So, pkg makes it relatively painless to zoom in = or out from a given symptom (i.e., binary or library that might have = changed). I don't believe this is possible in the current FreeBSD = setup. This is a huge gain in functionality. Cheers, Paul. From owner-freebsd-current@freebsd.org Wed Apr 20 15:49:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 643A6B15362 for ; Wed, 20 Apr 2016 15:49:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 550DA1A99 for ; Wed, 20 Apr 2016 15:49:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3KFnohx042810 for ; Wed, 20 Apr 2016 15:49:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-current@FreeBSD.org Subject: [Bug 208938] usr.sbin/config does not preserve whitespace in static env Date: Wed, 20 Apr 2016 15:49:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sylvain@sylvaingarrigues.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Apr 2016 16:00:19 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:49:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208938 Sylvain Garrigues changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-current@FreeBSD.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 20 15:50:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0B75B153A8 for ; Wed, 20 Apr 2016 15:50:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 A167B1AA2 for ; Wed, 20 Apr 2016 15:50:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3KFo1hL043204 for ; Wed, 20 Apr 2016 15:50:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-current@FreeBSD.org Subject: [Bug 208938] usr.sbin/config does not preserve whitespace in static env Date: Wed, 20 Apr 2016 15:50:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sylvain@sylvaingarrigues.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Apr 2016 16:00:33 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:50:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208938 Sylvain Garrigues changed: What |Removed |Added ---------------------------------------------------------------------------- Version|10.3-RELEASE |11.0-CURRENT --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 20 16:02:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 962A2B15F43 for ; Wed, 20 Apr 2016 16:02:47 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 696431966 for ; Wed, 20 Apr 2016 16:02:47 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by comcast with SMTP id suYjaFJXu2R4wsuaUaP4Mx; Wed, 20 Apr 2016 16:02:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461168166; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=k1rRRMGwBg4PBY61P6ptGjc90lFEQnQ9GIB8dpUr2SSnsdaJfG9zktrNpZrgZelef DV3TkfaJ3TbNY9WCdUWJXp2LDkwJUSF18HZz9UKINWHVCWWestbwR1+3vOOzqsu93g 80ejd6RzNWfa2DOwM/Ln9Y9RKjXwGFjQTUFHaAMXxNMAzdQq+pdktk0PHRkcZfmC51 smSUlFX+67MU9MzlfnvH1b7ewIikkVFLFUFtB5anL/iR1qUuJrc2rjhwPeMAp/y/Eo NafqKm5Zf1aAqVL7oHn9IwtQXaNqAEau7b+qtOZF41/aBIn+V6MEiBxvkaMp6vnV3D P0AV8LH9w8dPg== Received: from [IPv6:2001:468:c80:a103:f944:bead:def6:df3b] ([IPv6:2001:468:c80:a103:f944:bead:def6:df3b]) by resomta-ch2-16v.sys.comcast.net with comcast id kg2Z1s0011BqwLc01g2dkP; Wed, 20 Apr 2016 16:02:43 +0000 Content-Type: text/plain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Paul Mather In-Reply-To: <20160420145416.GB67390@zxy.spb.ru> Date: Wed, 20 Apr 2016 12:02:32 -0400 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <3F4F9450-7EE0-4277-BE57-76601ABA8A5C@gromit.dlib.vt.edu> References: <5DBC1E44-E562-4A5B-9DD9-47C1C62AFB9D@gromit.dlib.vt.edu> <20160420145416.GB67390@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:02:47 -0000 From owner-freebsd-current@freebsd.org Wed Apr 20 16:06:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26CCCB16103 for ; Wed, 20 Apr 2016 16:06:10 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 115021CE6 for ; Wed, 20 Apr 2016 16:06:10 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 103D1B16102; Wed, 20 Apr 2016 16:06:10 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F858B16101 for ; Wed, 20 Apr 2016 16:06:10 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EAC41CE2 for ; Wed, 20 Apr 2016 16:06:08 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1asudh-0008Cn-8o for current@freebsd.org; Wed, 20 Apr 2016 18:06:05 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1asudh-0006kZ-8F for current@freebsd.org; Wed, 20 Apr 2016 18:06:05 +0200 MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Wed, 20 Apr 2016 16:06:05 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: jpg attached, unsure if will go though... libc build error, svn of today Date: Wed, 20 Apr 2016 09:06:05 -0700 (PDT) X-Mailer: RMM6 Message-Id: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:06:10 -0000 unistd /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function b= ody after function declarator int execl( ................................. 332:46:=20=20=20=20 same... stops libc otherwise clang36 seems to be building so far, if it builds unsure about in= stallworld= From owner-freebsd-current@freebsd.org Wed Apr 20 16:28:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87BE8B169BE for ; Wed, 20 Apr 2016 16:28:31 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB941B39 for ; Wed, 20 Apr 2016 16:28:30 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 93386DC1D for ; Wed, 20 Apr 2016 16:28:29 +0000 (UTC) Subject: Re: jpg attached, unsure if will go though... libc build error, svn of today To: freebsd-current@freebsd.org References: From: Allan Jude Message-ID: <5717AE2D.3030406@freebsd.org> Date: Wed, 20 Apr 2016 12:28:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:28:31 -0000 On 2016-04-20 12:06, Jeffrey Bouquet wrote: > unistd > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function body after function declarator > int execl( ................................. > 332:46: > same... > > stops libc > otherwise clang36 seems to be building so far, if it builds unsure about installworld > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > The mailing list strips attachments. Can you upload it somewhere and provide a link -- Allan Jude From owner-freebsd-current@freebsd.org Wed Apr 20 16:32:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BD61B16BD2 for ; Wed, 20 Apr 2016 16:32:30 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D8451F84 for ; Wed, 20 Apr 2016 16:32:30 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1asv3H-000KX4-Hv; Wed, 20 Apr 2016 19:32:31 +0300 Date: Wed, 20 Apr 2016 19:32:31 +0300 From: Slawa Olhovchenkov To: Paul Mather Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160420163231.GC67390@zxy.spb.ru> References: <5DBC1E44-E562-4A5B-9DD9-47C1C62AFB9D@gromit.dlib.vt.edu> <20160420145416.GB67390@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:32:30 -0000 On Wed, Apr 20, 2016 at 11:57:47AM -0400, Paul Mather wrote: > On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov wrote: > > >> A packaged base is just another way of describing the state of the > >> system. People on mailing lists will still be able to help people > >> fix their problems, but they'll just use different information to > >> pinpoint the precise components affected. > > > > How identify this systems? By 800-line lists of package versions? > > > In my experience, troubleshooting usually proceeds from the > description of the symptoms. So, if someone says, "I just updated > and Sendmail has stopped sending e-mails," or "I just updated and I > can no longer SSH into my system," then the logical question is to > ask what versions of the packages they're running that pertain to > those binaries. In other words, you start at the symptom and work > outwards from there. In my experience, it's not necessary to have > an exact inventory of a system to be able to solve a problem with > it. I see you point. Now try this, for some example, semi-hypothetical. Some time ago we have troubles with sshd, fetchmail and other software after r296462. pkg don't show any useful for versions of sshd/fetchmail/etc because root cause will be breakin ABI in libcrypto. For useful information pkg need to show version of quering package and version of all depened packages. Is this allow now by simple command? Also, how to naming individual packages? For port software we have released version, for STABLE -- rollover release. Currently used naming is useless, using svn revision of top-level dir usefull only for two-package case. Using svn revision of individual dirs need addtional patches and addtional rules: /usr/src/sys/modules/aio # svnlite info Path: . Working Copy Root Path: /usr/src URL: svn://svn0.eu.freebsd.org/base/stable/10/sys/modules/aio Relative URL: ^/stable/10/sys/modules/aio Repository Root: svn://svn0.eu.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 295564 Node Kind: directory Schedule: normal Last Changed Author: jhb Last Changed Rev: 185878 Last Changed Date: 2008-12-10 23:56:19 +0300 (Wed, 10 Dec 2008) /usr/src/sys/modules/aio # less Makefile # $FreeBSD: stable/10/sys/modules/aio/Makefile 185878 2008-12-10 20:56:19Z jhb $ .PATH: ${.CURDIR}/../../kern KMOD= aio SRCS= vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h EXPORT_SYMS= aio_init_aioinfo aio_aqueue .include i.e. actual revision is max(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h) or even max(deps(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h)) Is this posible? > A tool like pkg makes it easy to know which package is associated > with a given file and also which packages that package depends upon > and which are dependencies of it. So, pkg makes it relatively > painless to zoom in or out from a given symptom (i.e., binary or > library that might have changed). I don't believe this is possible > in the current FreeBSD setup. This is a huge gain in functionality. You are lost may point. I am not against of pkg, I am just try more planing before implementation. Changing in distribution scheme is very expensive. From owner-freebsd-current@freebsd.org Wed Apr 20 16:39:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53A07B16D4A for ; Wed, 20 Apr 2016 16:39:33 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (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 477A81175; Wed, 20 Apr 2016 16:39:33 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [64.201.244.132] (port=52807 helo=[10.0.0.105]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asmpM-0002aG-By; Wed, 20 Apr 2016 00:45:36 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Error: stack underflow From: Devin Teske In-Reply-To: Date: Wed, 20 Apr 2016 09:39:27 -0700 Cc: FreeBSD Current , Devin Teske Content-Transfer-Encoding: quoted-printable Message-Id: <82BDB7D2-B803-404B-90C8-88050B41F5B4@freebsd.org> References: To: Andriy Gapon X-Mailer: Apple Mail (2.2104) Sender: devin@shxd.cx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:39:33 -0000 > On Apr 20, 2016, at 1:24 AM, Andriy Gapon wrote: >=20 >=20 > I see this message "Error: stack underflow" when a loader menu is = presented. > It seems that it comes from ficl. This is on a quite recent (< 2 = weeks) head. > How can I debug this problem? >=20 > I have one local modification to forth files, but I'm not sure if the = problem is > caused by it or by something in my boot configuration files. >=20 > diff --git a/sys/boot/forth/menu-commands.4th = b/sys/boot/forth/menu-commands.4th > index 9adf30a46b661..813cbf12e9655 100644 > --- a/sys/boot/forth/menu-commands.4th > +++ b/sys/boot/forth/menu-commands.4th > @@ -243,6 +243,21 @@ also menu-namespace also menu-command-helpers > TRUE \ loop menu again > ; >=20 > +: toggle_gui ( N -- N TRUE ) > + toggle_menuitem > + menu-redraw > + > + \ Now we're going to make the change effective > + > + dup toggle_stateN @ 0=3D if > + s" inhibit_gui" unsetenv > + else > + s" set inhibit_gui=3D1" evaluate > + then > + > + TRUE \ loop menu again > +; > + > \ > \ Escape to Prompt > \ > diff --git a/sys/boot/forth/menu.rc b/sys/boot/forth/menu.rc > index 3c7de7138b8ad..ddeccc9679fea 100644 > --- a/sys/boot/forth/menu.rc > +++ b/sys/boot/forth/menu.rc > @@ -126,6 +126,13 @@ set optionsmenu_keycode[6]=3D118 > set optionsansi_caption[6]=3D"^[1mV^[merbose..... ^[34;1mOff^[m" > set optionstoggled_ansi[6]=3D"^[1mV^[merbose..... ^[32;7mOn^[m" >=20 > +set optionsmenu_caption[7]=3D"Inhibit [G]UI. off" > +set optionstoggled_text[7]=3D"Inhibit [G]UI. On" > +set optionsmenu_command[7]=3D"toggle_gui" > +set optionsmenu_keycode[7]=3D103 > +set optionsansi_caption[7]=3D"Inhibit =1B[1mG=1B[37mUI. = =1B[34;1mOff=1B[37m" > +set optionstoggled_ansi[7]=3D"Inhibit =1B[1mG=1B[37mUI. = =1B[32;7mOn=1B[0;37m" > + > \ > \ BOOT ENVIRONMENT MENU > \ >=20 I'll look into this. Thanks for bring it to our/my attention. --=20 Cheers, Devin= From owner-freebsd-current@freebsd.org Wed Apr 20 18:13:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA7D0B1557D for ; Wed, 20 Apr 2016 18:13:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 9ADCB1E25 for ; Wed, 20 Apr 2016 18:13:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3KIDCuO073880 for ; Wed, 20 Apr 2016 18:13:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-current@FreeBSD.org Subject: [Bug 208938] usr.sbin/config does not preserve whitespace in static env Date: Wed, 20 Apr 2016 18:13:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sylvain@sylvaingarrigues.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Apr 2016 18:27:28 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:13:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208938 Sylvain Garrigues changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #169494|0 |1 is obsolete| | --- Comment #1 from Sylvain Garrigues --- Created attachment 169500 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D169500&action= =3Dedit Preserve spaces and tabs between quotes in /usr/sbin/config Correct patch attached --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Wed Apr 20 20:06:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBB94B163DD; Wed, 20 Apr 2016 20:06:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BFB4F1227; Wed, 20 Apr 2016 20:06:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B559218FE; Wed, 20 Apr 2016 20:06:16 +0000 (UTC) Date: Wed, 20 Apr 2016 20:06:13 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: kib@FreeBSD.org, avos@FreeBSD.org, emaste@FreeBSD.org, wma@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <506456011.2.1461182776603.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2909 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 20:06:17 -0000 FreeBSD_HEAD_i386 - Build #2909 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2909/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2909/cha= nges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2909/cons= ole Change summaries: 298361 by emaste: elfcopy: map all !alnum characters to '_' in binary input symbol names This matches bfd and gold. Obtained from:=09ELF Tool Chain r3445 Sponsored by:=09The FreeBSD Foundation 298360 by avos: net80211 (trivial, noop): remove duplicate check from hostap_recv_mgmt() Differential Revision:=09https://reviews.freebsd.org/D5483 298359 by avos: net80211: replace internal LE_READ_*/LE_WRITE_* macro with system le*dec / le*enc functions. Replace net80211 specific macros with system-wide bytestream encoding/decoding functions: - LE_READ_2 -> le16dec - LE_READ_4 -> le32dec - LE_WRITE_2 -> le16enc - LE_WRITE_4 -> le32enc + drop ieee80211_input.h include, where it was included for these operations only. Reviewed by:=09adrian Differential Revision:=09https://reviews.freebsd.org/D6030 298358 by wma: Fix KGDB backtrace on ARM Modify trapframe decoding to properly analyze trapframe. Provide method for fixup_pc. It happens, that in some kernel functions, the GDB stack frame decoder cannot determine both func name and frame size. This is because these functions either contain invalid instruction, or their format does not match standard schema. Detect that scenarios and move PC accordingly to jump into known function schema, which GDB is able to parse. Obtained from: Semihalf Sponsored by: Juniper Networks Reviewed by: kib, zbb Differential Revision: https://reviews.freebsd.org/D5976 298357 by wma: Fix MFS symbol redefinition with clang 3.8.0 Newest CLANG objcpy uses different name parsing. Modify regexp to match (i.e. avoid substitution of "/" or "-" with "_"). Obtained from: Semihalf Sponsored by: Juniper Networks Reviewed by: hselasky, zbb Differential Revision: https://reviews.freebsd.org/D5873 298356 by kib: Arm and arm64 both have fueword() implemented for some time. Correct the comment. Sponsored by:=09The FreeBSD Foundation The end of the build log: [...truncated 89252 lines...] --- all_subdir_lib --- --- h_snprintf.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_snprintf.full h_snprintf.o =20 --- h_snprintf.debug --- objcopy --only-keep-debug h_snprintf.full h_snprintf.debug --- all_subdir_gnu --- --- trgt.o --- --- all_subdir_lib --- --- h_snprintf --- --- all_subdir_gnu --- cc -O2 -pipe -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEB= UGDIR=3D\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/kgdb/../arch/i386= -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/usr/src/gnu/usr.b= in/gdb/kgdb/../../binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/gdb/kgdb/../.= ./../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib= /gdb/gdb/config -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutil= s/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -= I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -I/usr/obj/= usr/src/gnu/usr.bin/gdb/kgdb/../../../lib/libreadline/readline/.. -g -MD -M= P -MF.depend.trgt.o -MTtrgt.o -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sig= n -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-taut= ological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-fu= nction -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-swit= ch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/gnu/us= r.bin/gdb/kgdb/trgt.c -o trgt.o --- all_subdir_lib --- objcopy --strip-debug --add-gnu-debuglink=3Dh_snprintf.debug h_snprintf.fu= ll h_snprintf --- h_sprintf --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=3D.depend.h_sprintf NO_SUBD= IR=3D1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=3Dt P= ROG=3Dh_sprintf ) --- .depend.h_sprintf --- echo h_sprintf.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_spri= ntf --- h_sprintf.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_sprintf.h_sprintf.o -MTh_sprintf.o = -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2= k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int= -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wn= o-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unuse= d-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -= Qunused-arguments -c /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_sprintf.= c -o h_sprintf.o --- h_sprintf.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_sprintf.full h_sprintf.o =20 --- h_sprintf.debug --- objcopy --only-keep-debug h_sprintf.full h_sprintf.debug --- h_sprintf --- objcopy --strip-debug --add-gnu-debuglink=3Dh_sprintf.debug h_sprintf.full= h_sprintf --- h_stpcpy --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=3D.depend.h_stpcpy NO_SUBDI= R=3D1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=3Dt PR= OG=3Dh_stpcpy ) --- .depend.h_stpcpy --- echo h_stpcpy.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_stpcp= y --- h_stpcpy.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_stpcpy.h_stpcpy.o -MTh_stpcpy.o -st= d=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -= Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -W= no-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-p= arentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-l= ocal-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qun= used-arguments -c /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_stpcpy.c -o= h_stpcpy.o --- h_stpcpy.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_stpcpy.full h_stpcpy.o =20 --- h_stpcpy.debug --- objcopy --only-keep-debug h_stpcpy.full h_stpcpy.debug --- h_stpcpy --- objcopy --strip-debug --add-gnu-debuglink=3Dh_stpcpy.debug h_stpcpy.full h= _stpcpy --- h_stpncpy --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=3D.depend.h_stpncpy NO_SUBD= IR=3D1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=3Dt P= ROG=3Dh_stpncpy ) --- .depend.h_stpncpy --- echo h_stpncpy.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_stpn= cpy --- h_stpncpy.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_stpncpy.h_stpncpy.o -MTh_stpncpy.o = -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2= k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int= -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wn= o-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unuse= d-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -= Qunused-arguments -c /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_stpncpy.= c -o h_stpncpy.o --- h_stpncpy.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_stpncpy.full h_stpncpy.o =20 --- all_subdir_gnu --- --- trgt_i386.o --- cc -O2 -pipe -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEB= UGDIR=3D\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/kgdb/../arch/i386= -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/usr/src/gnu/usr.b= in/gdb/kgdb/../../binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/gdb/kgdb/../.= ./../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib= /gdb/gdb/config -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutil= s/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -= I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -I/usr/obj/= usr/src/gnu/usr.bin/gdb/kgdb/../../../lib/libreadline/readline/.. -g -MD -M= P -MF.depend.trgt_i386.o -MTtrgt_i386.o -std=3Dgnu99 -fstack-protector-stro= ng -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-p= ointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable= -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno= -unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch= -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/= src/gnu/usr.bin/gdb/kgdb/trgt_i386.c -o trgt_i386.o --- all_subdir_lib --- --- h_stpncpy.debug --- objcopy --only-keep-debug h_stpncpy.full h_stpncpy.debug --- h_stpncpy --- objcopy --strip-debug --add-gnu-debuglink=3Dh_stpncpy.debug h_stpncpy.full= h_stpncpy --- h_strcat --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=3D.depend.h_strcat NO_SUBDI= R=3D1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=3Dt PR= OG=3Dh_strcat ) --- .depend.h_strcat --- echo h_strcat.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_strca= t --- h_strcat.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_strcat.h_strcat.o -MTh_strcat.o -st= d=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -= Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -W= no-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-p= arentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-l= ocal-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qun= used-arguments -c /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_strcat.c -o= h_strcat.o --- h_strcat.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_strcat.full h_strcat.o =20 --- h_strcat.debug --- objcopy --only-keep-debug h_strcat.full h_strcat.debug --- h_strcat --- objcopy --strip-debug --add-gnu-debuglink=3Dh_strcat.debug h_strcat.full h= _strcat --- h_strcpy --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=3D.depend.h_strcpy NO_SUBDI= R=3D1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=3Dt PR= OG=3Dh_strcpy ) --- .depend.h_strcpy --- echo h_strcpy.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_strcp= y --- h_strcpy.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_strcpy.h_strcpy.o -MTh_strcpy.o -st= d=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -= Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -W= no-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-p= arentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-l= ocal-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qun= used-arguments -c /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_strcpy.c -o= h_strcpy.o --- all_subdir_rescue --- 5 warnings generated. --- zfs_iter.o --- cc -O2 -pipe -I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/li= b/libzpool/common -I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris= /include -I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/lib/libu= mem -I/usr/src/cddl/sbin/zfs/../../../sys/cddl/compat/opensolaris -I/usr/sr= c/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/sbin= /zfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/= sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -I/usr/src/cdd= l/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzfs_core/common -I/usr/= src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libumem/common -I/u= sr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr= /src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/= src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -= I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sy= s -I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/common/zfs= -DNEED_SOLARIS_BOOLEAN -DRESCUE -MD -MP -MF.depend.zfs_iter.o -MTzfs_ite= r.o -std=3Dgnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-unknown-pr= agmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-= tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unuse= d-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-= switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-argument= s -c /usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/cmd/zfs/zfs_= iter.c -o zfs_iter.o --- all_subdir_lib --- --- h_strcpy.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_strcpy.full h_strcpy.o =20 --- h_strcpy.debug --- objcopy --only-keep-debug h_strcpy.full h_strcpy.debug --- h_strcpy --- objcopy --strip-debug --add-gnu-debuglink=3Dh_strcpy.debug h_strcpy.full h= _strcpy --- h_strncat --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=3D.depend.h_strncat NO_SUBD= IR=3D1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=3Dt P= ROG=3Dh_strncat ) --- all_subdir_gnu --- --- kgdb.full --- cc -O2 -pipe -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=3D1 -DTUI=3D1 -DDEBUGD= IR=3D\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/kgdb/../arch/i386 -I= /usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/usr/src/gnu/usr.bin/= gdb/kgdb/../../binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/gdb/kgdb/../../.= ./../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gd= b/gdb/config -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/i= nclude -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/u= sr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -I/usr/obj/usr= /src/gnu/usr.bin/gdb/kgdb/../../../lib/libreadline/readline/.. -g -std=3Dgn= u99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k= -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno= -parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused= -local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qu= nused-arguments -o kgdb.full main.o kld.o kthr.o trgt.o trgt_i386.o /usr/= obj/usr/src/gnu/usr.bin/gdb/kgdb/../../gdb/libgdb/libgdb.a /usr/obj/usr/src= /gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/libbfd.a /usr/obj/usr/src/gnu/u= sr.bin/gdb/kgdb/../../binutils/libopcodes/libopcodes.a /usr/obj/usr/src/gn= u/usr.bin/gdb/kgdb/../../binutils/libiberty/libiberty.a -lm -L/usr/obj/usr= /src/gnu/lib/libreadline/readline -L/usr/obj/usr/src/gnu/lib/libreadline/re= adline -lreadline -lncursesw -lncursesw -lncursesw -lgnuregex -lkvm --- all_subdir_lib --- --- .depend.h_strncat --- echo h_strncat.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_strn= cat --- h_strncat.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_strncat.h_strncat.o -MTh_strncat.o = -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2= k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int= -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wn= o-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unuse= d-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -= Qunused-arguments -c /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_strncat.= c -o h_strncat.o --- h_strncat.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_strncat.full h_strncat.o =20 --- h_strncat.debug --- objcopy --only-keep-debug h_strncat.full h_strncat.debug --- h_strncat --- objcopy --strip-debug --add-gnu-debuglink=3Dh_strncat.debug h_strncat.full= h_strncat --- h_strncpy --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=3D.depend.h_strncpy NO_SUBD= IR=3D1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=3Dt P= ROG=3Dh_strncpy ) --- .depend.h_strncpy --- echo h_strncpy.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_strn= cpy --- h_strncpy.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_strncpy.h_strncpy.o -MTh_strncpy.o = -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2= k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int= -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wn= o-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unuse= d-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -= Qunused-arguments -c /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_strncpy.= c -o h_strncpy.o --- all_subdir_gnu --- main.o: In function `main': /usr/src/gnu/usr.bin/gdb/kgdb/main.c:478: undefined reference to `kgdb_trgt= _pc_fixup' --- all_subdir_lib --- --- h_strncpy.full --- cc -O2 -pipe -g -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wal= l -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno= -string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-= unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve= rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promo= ted-parameter -Qunused-arguments -o h_strncpy.full h_strncpy.o =20 --- all_subdir_kerberos5 --- --- kpasswdd.full --- cc -O2 -pipe -I/usr/src/kerberos5/libexec/kpasswdd/../../../crypto/heimdal/= lib/roken -I../../lib/libhdb -DHAVE_CONFIG_H -I/usr/src/kerberos5/libexec/k= passwdd/../../include -g -std=3Dgnu99 -fstack-protector-strong -Qunused-arg= uments -o kpasswdd.full kpasswdd.o -lkadm5srv -lhdb -lkrb5 -lroken -= L/usr/obj/usr/src/kerberos5/lib/libvers -lvers -lasn1 --- all_subdir_gnu --- cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** [kgdb.full] Error code 1 make[6]: stopped in /usr/src/gnu/usr.bin/gdb/kgdb 1 error make[6]: stopped in /usr/src/gnu/usr.bin/gdb/kgdb *** [all] Error code 2 make[5]: stopped in /usr/src/gnu/usr.bin/gdb 1 error make[5]: stopped in /usr/src/gnu/usr.bin/gdb *** [all_subdir_gnu/usr.bin/gdb] Error code 2 make[4]: stopped in /usr/src/gnu/usr.bin 1 error make[4]: stopped in /usr/src/gnu/usr.bin *** [all_subdir_gnu/usr.bin] Error code 2 make[3]: stopped in /usr/src/gnu 1 error make[3]: stopped in /usr/src/gnu *** [all_subdir_gnu] Error code 2 make[2]: stopped in /usr/src --- all_subdir_lib --- A failure has been detected in another branch of the parallel make make[7]: stopped in /usr/src/lib/libc/tests/ssp *** [h_strncpy] Error code 2 make[6]: stopped in /usr/src/lib/libc/tests/ssp 1 error make[6]: stopped in /usr/src/lib/libc/tests/ssp *** [all_subdir_lib/libc/tests/ssp] Error code 2 make[5]: stopped in /usr/src/lib/libc/tests 1 error make[5]: stopped in /usr/src/lib/libc/tests *** [all] Error code 2 make[4]: stopped in /usr/src/lib/libc 1 error make[4]: stopped in /usr/src/lib/libc *** [all_subdir_lib/libc] Error code 2 make[3]: stopped in /usr/src/lib 1 error make[3]: stopped in /usr/src/lib *** [all_subdir_lib] Error code 2 make[2]: stopped in /usr/src --- all_subdir_rescue --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/cddl/sbin/zfs *** [zfs_make] Error code 2 make[5]: stopped in /usr/obj/usr/src/rescue/rescue 1 error make[5]: stopped in /usr/obj/usr/src/rescue/rescue *** [objs] Error code 2 make[4]: stopped in /usr/src/rescue/rescue 1 error make[4]: stopped in /usr/src/rescue/rescue *** [all] Error code 2 make[3]: stopped in /usr/src/rescue 1 error make[3]: stopped in /usr/src/rescue *** [all_subdir_rescue] Error code 2 make[2]: stopped in /usr/src --- all_subdir_kerberos5 --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/kerberos5/libexec/kpasswdd *** [all_subdir_kerberos5/libexec/kpasswdd] Error code 2 make[4]: stopped in /usr/src/kerberos5/libexec 1 error make[4]: stopped in /usr/src/kerberos5/libexec *** [all_subdir_kerberos5/libexec] Error code 2 make[3]: stopped in /usr/src/kerberos5 1 error make[3]: stopped in /usr/src/kerberos5 *** [all_subdir_kerberos5] Error code 2 make[2]: stopped in /usr/src 4 errors make[2]: stopped in /usr/src *** [everything] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson6020333059444055659.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Wed Apr 20 20:40:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1985FB16160 for ; Wed, 20 Apr 2016 20:40:48 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9E8E1B04 for ; Wed, 20 Apr 2016 20:40:47 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u3KKIJZI052661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Apr 2016 06:18:25 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u3KKIBIS031023 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Apr 2016 06:18:11 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u3KKI9Zr031022; Thu, 21 Apr 2016 06:18:09 +1000 (AEST) (envelope-from peter) Date: Thu, 21 Apr 2016 06:18:09 +1000 From: Peter Jeremy To: Hans Petter Selasky Cc: FreeBSD Current Subject: Re: qsort() documentation Message-ID: <20160420201809.GA46988@server.rulingia.com> References: <5714C86A.8050204@selasky.org> <20160419113430.69e41a0b@fujitsu> <5717256C.5080805@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <5717256C.5080805@selasky.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Thu, 21 Apr 2016 06:18:26 +1000 (AEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 20:40:48 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Apr-20 08:45:00 +0200, Hans Petter Selasky wrote: >There is something which I don't understand. Why is quicksort falling=20 >back to insertion sort which is an O(N**2) algorithm, when there exist a= =20 >O(log(N)*log(N)*N) algorithms, which I propose as a solution to the=20 >"bad" characteristics of qsort. O() notation just describes the (normally, worst case) ratio of input size to runtime for a given algorithm: Increasing the input size by (say) 100=D7 means an insertion sort will take about 10000=D7 as long to run, whilst the "best" algorithms would take about 2000=D7 as long. It says nothing about = how fast sorting (say) 1000 items takes with either sort or how they behave on "typical" inputs. In general, the fancier algorithms might have better worst-case O() numbers but they have higher overheads and may not perform any better on typical inputs - so, for small inputs, insertion sort or bubble sort may be faster. IMO: - If you're only sorting a small number of items and/or doing it infrequent= ly, the sort performance doesn't really matter and you can use any algorithm. - If you're sorting lots of items and sort performance is a real issue, you need to examine the performance of a variety of algorithms on your input data and may need to roll your own implementation. As long as qsort() behaves reasonably and its behaviour is documented sufficiently well that someone can decide whether or not to rule it out for their specific application, that is (IMHO) sufficient. --=20 Peter Jeremy --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXF+QBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0S/0P/0ZJGxcT1MXsZ6toqSKXfjcJ Sh+ZXRx/OMP/kiF2MI575njiY9KNtUOz52DTTBQAuw7yJR/mnHaqujdvnSOuzFHq k+mv+0RPb7gDBlMp4TxS177xKF0h6Tnlg4MBWpmLtvb4ZpZR/byRx+LvwvYS+Fff GU4Fa3eQKKzlAyFHt3Fgd8+zJH+SLAMCgJvZX3v3KZajK20NEKsi1I6eyV3lN2VI vpVmECDMEueTEBx5H2vlNEgzKYM/yOmvMtBuB80d6ps5UBiV/ASz87AOR69eN/6M YaVaKxt4HUGGSoWsR741Ng2gDw2ET0GdXWri3lwkgL4YZVo63Pa+krqkyQ2uWVvD l6ylZSZb0z2oIwZhfdxzb5eoLtJBwRYz/etxAWZHb6gwDDmoxbXHSJPyeARqWBzP jlXON6Q3qTNHfa6X4VnV0Ax/Wwa1fG7kcHDBDm8ikg/y6+nHGYVxH/7BMautQsTG nmztkEE4nxc1Me8gdhYc3kd9PYbWpVzrQGpBrdieYJuT/AML4bWATRxPeCkHUOnR MdPiuvh/d53G8w3f+mACJ/pK8fAXT0XXxMaxOsHc+ddLjOUEQURrlVQtS3ujDZxY qs+ROXB96C0HjuXLr4Zkc3mmqpkXeQnjlHSZcon2UJ1BFEzdP3o25+10XCRtD6n7 K5OPAtxMGK+1o7DV5oeo =/9mq -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-current@freebsd.org Thu Apr 21 00:37:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D41DB15DFD for ; Thu, 21 Apr 2016 00:37:25 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 137A41B27; Thu, 21 Apr 2016 00:37:24 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1at2cO-0001ha-26; Thu, 21 Apr 2016 02:37:16 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1at2cO-0007TO-1i; Thu, 21 Apr 2016 02:37:16 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Thu, 21 Apr 2016 00:37:16 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "Allan Jude" CC: "freebsd-current" Subject: [WAS:libc build error] installworld result not satisfactory yet... Date: Wed, 20 Apr 2016 17:37:16 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <5717AE2D.3030406@freebsd.org> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 00:37:25 -0000 On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude wrot= e: > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > unistd > >=20 > >=20 > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected functi= on body after function declarator > > int execl( ................................. > > 332:46:=20=20= =20=20 > > same... > >=20 > > stops libc > > otherwise clang36 seems to be building so far, if it builds unsure abou= t installworld > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > >=20 >=20 > The mailing list strips attachments. Can you upload it somewhere and > provide a link >=20 > --=20 > Allan Jude > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Well, it is now r298350 Wed Apr 20... However several problems SINGLE-USER BOOT PROBLEMS 1... usual boot fails, this is single-user adjusted, but I cannot add swap = (swapon? swapctl?) 1a... the last time, it was fixed with using the old /kernel ...=20 multi-user boot problems 2... the last usual boot dumped with vm_pager or something, verbose boot t= imes out with xpt_config not completing. 2a.... could be a wrong setting is loader.conf, the nvidia.ko not yet updat= ed (which it now is ) for the latter case I have yet to reboot to test 2b... Reboot to test takes longer, /rescue/mount each filesystem indivi= dually...=20 As one might surmise, I'd rather see buildworld made more foolproof than ot= her recent improvements=20 (pkg, zfs, ...) From owner-freebsd-current@freebsd.org Thu Apr 21 01:37:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3903FB161B9 for ; Thu, 21 Apr 2016 01:37:49 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 260D418CA for ; Thu, 21 Apr 2016 01:37:49 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 256C8B161B8; Thu, 21 Apr 2016 01:37:49 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 250C4B161B7 for ; Thu, 21 Apr 2016 01:37:49 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF9D318C9 for ; Thu, 21 Apr 2016 01:37:48 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1at3Yv-0007N0-5y; Thu, 21 Apr 2016 03:37:45 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1at3Yv-000201-5W; Thu, 21 Apr 2016 03:37:45 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Thu, 21 Apr 2016 01:37:45 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" CC: "kernel" Subject: Re: [WAS:libc build error] it is HALF solved bw-iw cycle Date: Wed, 20 Apr 2016 18:37:45 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 01:37:49 -0000 On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 >=20 > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude wr= ote: >=20 > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > unistd > > >=20 > > >=20 > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected func= tion body after function declarator > > > int execl( ................................. > > > 332:46:=20= =20=20=20 > > > same... > > >=20 > > > stops libc > > > otherwise clang36 seems to be building so far, if it builds unsure ab= out installworld > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" > > >=20 > >=20 > > The mailing list strips attachments. Can you upload it somewhere and > > provide a link > >=20 > > --=20 > > Allan Jude > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 >=20 > Well, it is now r298350 Wed Apr 20... > However several problems >=20 > SINGLE-USER BOOT PROBLEMS > 1... usual boot fails, this is single-user adjusted, but I cannot add swa= p (swapon? swapctl?) > 1a... the last time, it was fixed with using the old /kernel ...=20 >=20 > multi-user boot problems >=20 > 2... the last usual boot dumped with vm_pager or something, verbose boot= times out with xpt_config not completing. > 2a.... could be a wrong setting is loader.conf, the nvidia.ko not yet upd= ated (which it now is ) for the latter > case I have yet to reboot to test > 2b... Reboot to test takes longer, /rescue/mount each filesystem indi= vidually...=20 >=20 >=20 > As one might surmise, I'd rather see buildworld made more foolproof than = other recent improvements=20 > (pkg, zfs, ...) =46rom backup, I have r288246 kernel and nvidia.ko (v11) from source, I have world and all except those TWO files at r298350 )(v11),= nvidia (newer) won't load with older kernel A few at-boot scripts no longer work as expected... but no other major prob= lems (swap is present again) (multi-user boot works)=20 Best practice maybe to update the kernel? It is a custom one from way back= in 2004 initially without sound drivers and without debug symbols... and many esoteric lines= added which I cobbled together at first then changed per diffs of GENERIC over the years... Thanks for any known methods J. Bouquet= From owner-freebsd-current@freebsd.org Thu Apr 21 08:01:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A092B16AA7 for ; Thu, 21 Apr 2016 08:01:41 +0000 (UTC) (envelope-from fbsd-lists@dudes.ch) Received: from mail.dudes.ch (mail.dudes.ch [193.73.211.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.dudes.ch", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CBAD1BE1 for ; Thu, 21 Apr 2016 08:01:40 +0000 (UTC) (envelope-from fbsd-lists@dudes.ch) Received: from mwoffice.virtualtec.office ([93.189.66.120]) (authenticated bits=0) by mail.dudes.ch (8.14.7/8.14.7) with ESMTP id u3L7s7Mg006754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Apr 2016 07:54:07 GMT (envelope-from fbsd-lists@dudes.ch) X-Authentication-Warning: mail.dudes.ch: Host [93.189.66.120] claimed to be mwoffice.virtualtec.office Date: Thu, 21 Apr 2016 09:54:06 +0200 From: Markus Wild To: freebsd-current@freebsd.org Subject: Re: OCZ ssdpx-1rvd0120 REVODRIVE support Message-ID: <20160421095406.622a57d4@mwoffice.virtualtec.office> In-Reply-To: References: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 193.73.211.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:01:41 -0000 > > > HI! I've recently got a SSD device. Yes, not a disk, but a device. > > > It's called, i. e. one of the first REVODRIVEs. > > > It's a PCI-express card with two embedded ssd disks about ~ 55GB size. > > > And it's a raid card. Fake software raid. You can set it up as a > > > RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured > > > or set it as JBOD or something else. > > > You just won't be able to boot from this device in that case. I used to have one of these in my workstation (mine was recognized as 4 SATA drives of about 60GB). I had put these into a zfs pool with raidz1 and was able to boot from the card without any issue. BIOS reported them as 4 individual drives. These are pre-NVME, so no NVME driver was necessary. Unfortunately, the card recently died of old age, so I can't provide any more than historic references. The type was OCZSSDPX-1RVDX0240 . Cheers, Markus From owner-freebsd-current@freebsd.org Thu Apr 21 09:57:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DB28B177B7 for ; Thu, 21 Apr 2016 09:57:12 +0000 (UTC) (envelope-from etnapierala@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 C74B61E05; Thu, 21 Apr 2016 09:57:11 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id e201so16262587wme.2; Thu, 21 Apr 2016 02:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=KvheXtgXjPTnUJrHUHz2+KmbSSvdaoVCMB0pJkYKwWs=; b=G+VZ8aZV2M3fq2pBHGOCo1MmtLvMf/is3n+DLSHxqvEs5NARsmFRH9lQKaMQ9mglvm 6ocD0iCJEZpyC+yPcvYDK0Ohxk9ylkrN9pObD/S8ITnvY/ncUdtP7vHmNdcuspfqSvxT McspOrOwtMvj2G0XHlbRrRvv8v45udF2DgJoCeYv6mEq4RyXHp+I58qlEQkJoxm+mlGG +lsNXmtv2/DaxHMOIktYueziLLEB0B60QRG/8odgfYX6mz8Q6eZiEOLM3Vg3Gx9unVFz DcEcfXYu7p9z2Ha7PnpS+vQTUbI6lt7TquZoq/RIN2Jv/mQGBENNJhKiXe8h60XPa6cF kiLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=KvheXtgXjPTnUJrHUHz2+KmbSSvdaoVCMB0pJkYKwWs=; b=Zbjdw+U9DLTOWjjw+n4dVzX9FNyIYSDvuK+8kokkEZRo2WHm6AQ18sOliBPq8Ii1PP tdWQwbMCe8JySaPCpcbsXeSOVZfm279Umt1uF/utbElL2IRYzhZHmcv7laKpcpuXQNzy GcmhlfySAiHze3LWTAZ3nfbdjEkX3gE8Pq1t2oVcGUf8/cORFKUeBDFpbJi+CfC+orq8 eoKGMamnM6c9Coxgqchn4Z/be5REqiFbIleiYAcGx9+9P6MIh7sXzp6THPM/k4+5VPo0 ZXb/GhnJj1dVnMihNeowFXqUaC8tmRqcd8L6P6/KoEsEDEqFTf+woM0Y2QAxtl+TwMTR 8NCw== X-Gm-Message-State: AOPr4FX14H5m+eFJGxPkY0AuNxkjWUVczyW4tNzLSJBD503GmMbeaA5fLtWciN+HJSk9KQ== X-Received: by 10.28.144.20 with SMTP id s20mr14830356wmd.12.1461232630463; Thu, 21 Apr 2016 02:57:10 -0700 (PDT) Received: from brick (evp155.neoplus.adsl.tpnet.pl. [83.20.213.155]) by smtp.gmail.com with ESMTPSA id jr8sm1999434wjb.15.2016.04.21.02.57.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Apr 2016 02:57:09 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 21 Apr 2016 11:57:06 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: dan_partelly Cc: Miroslav Lachman <000.fbsd@quip.cz>, Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160421095706.GA57206@brick> Mail-Followup-To: dan_partelly , Miroslav Lachman <000.fbsd@quip.cz>, Nathan Whitehorn , freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 09:57:12 -0000 On 0420T1545, dan_partelly wrote: [..] > Another example is the autofs mounter. The prject was marked as complete > by FreeBSD foundation in 2014. Last I tried it to autmount removable > devices, it left directory after directory in the autofs managed directory. > This is known behavior. Yup. The problem here is that it's quite hard to fix, there's a risk of breaking existing functionality, and the problem is largely cosmetic. > It also did not worked as it should ??? (show it > manage removable media correctly ) changing CD/DVD media disks. Presumably > In could have somehow manage it to work by making yet another scaffolding > of scripts as a questionable glue between devd and automounters. That if > devd receives media change notifications. I dont know. If not I could patch > the kernel, yeah. But it is just much to simple to not bother at all and > use OSx. Huh, never heard about that. I'd expect the existing mechanism to handle that case just fine. Could you submit a PR? [..] From owner-freebsd-current@freebsd.org Thu Apr 21 04:50:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60B52B1695F for ; Thu, 21 Apr 2016 04:50:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 515491AA6 for ; Thu, 21 Apr 2016 04:50:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3L4oWmR018690 for ; Thu, 21 Apr 2016 04:50:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-current@FreeBSD.org Subject: [Bug 208938] usr.sbin/config does not preserve whitespace in static env Date: Thu, 21 Apr 2016 04:50:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 21 Apr 2016 11:20:31 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 04:50:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208938 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Thu Apr 21 12:05:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8614EB17CF3 for ; Thu, 21 Apr 2016 12:05:45 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 72F721316 for ; Thu, 21 Apr 2016 12:05:45 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6E53AB17CF2; Thu, 21 Apr 2016 12:05:45 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DFA5B17CF1 for ; Thu, 21 Apr 2016 12:05:45 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A15D1315 for ; Thu, 21 Apr 2016 12:05:44 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1atDMb-00010L-3h for current@freebsd.org; Thu, 21 Apr 2016 14:05:41 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1atDMb-0006P7-3O for current@freebsd.org; Thu, 21 Apr 2016 14:05:41 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Thu, 21 Apr 2016 12:05:41 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: Re: limits: setrlimit umtxp: Invalid argument Date: Thu, 21 Apr 2016 05:05:41 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 12:05:45 -0000 On Thu, 10 Mar 2016 07:16:05 +0900, Brendan Sechter wro= te: > > Subject: Re: limits: setrlimit umtxp: Invalid argument > > From: florian.ermisch@alumni.tu-berlin.de > > Date: Wed, 9 Mar 2016 18:45:37 +0100 > > To: eric@vangyzen.net; sgeos@hotmail.com; freebsd-current@freebsd.org > > > > Am 9. M=C3=A4rz 2016 16:59:47 MEZ, schrieb Eric van Gyzen : > >> On 03/09/2016 09:49, Brendan Sechter wrote: > >>> I am running an 11.0-CURRENT VM. > >>> After recently updating, the following appears on startup and > >>> dhclient fails to start. > >>> > >>> Starting dhclient. > >>> limits: setrlimit umtxp: Invalid argument > >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient > >>> > >>> Similar messages appear for the following. > >>> > >>> devd pflog syslogd ntpd powerd sshd sendmail_submit > >>> sendmail_msp_queue cron > >>> > >>> Reverting to the previous kernel did not resolve the issue. > >>> I can manually start dhclient and ntp, but not sshd. > >>> > >>> I do not trust that my uname information is being updated with > >>> with build, but here it is. > >>> > >>> $ uname -vm > >>> FreeBSD 11.0-CURRENT #0 r287598: Thu Sep 10 14:45:48 JST 2015 > >>> root@:/usr/obj/usr/src/sys/MIRAGE_KERNEL amd64 > >> > >> This information comes directly from the running kernel, so it looks > >> like your kernel is not getting updated. This seems consistent > >> with the above error messages, although I haven't tested this > >> case. The userland tools are aware of the newly added umtxp > >> limit, but the kernel is not aware. > >> > >> Eric > > > > I got this problem on my laptop, too. I somehow managed not to > > install the kernel during a recent update so my userland is slightly > > newer than my 11-CURRENT r292755 kernel (and also forgot to > > make proper ZFS snapshots=E2=80=A6). > > > > While I can build a newer kernel but when I boot i.e. r296556 > > `zfs(8)' coredumps and I can't mount anything but the rootfs=E2=80=A6 > > I guess I need to get kernel & userland back in sync to fix this. > > > > I will try to build the userland matching my kernel first as > > I know its revision from `uname -a`. > > If anyone has a better approach or tips, please let me know. >=20 > My userland was up to date. =C2=A0This is what I did to get the kernel > in sync enough to resolve the issue. >=20 > svn up /usr/src # omit if want to use the exact same version as world > cd /usr/src > make buildkernel KERNCONF=3DMYKERNEL > make installkernel KERNCONF=3DMYKERNEL >=20 > I found a problem with my kernel configuration in the process. > The plan is to rebuild everything after the configuration issue is > sorted out. =C2=A0You may wish to use GENERIC just to get things up > and running again. >=20 > Regards, > -Brendan=20=09=09=20=09=20=20=20=09=09=20=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I've a working pf.ko kernel and nvidia.ko from r288246 Sep 26 2015 and an i= nstalled buildworld from yesterday Apr 20 2016. The kernel is custom and I've also = a large-ish loader.conf. I've no wish to run GENERIC with either debugging symbols nor= sound enabled. sendmail_submit is broken, not a showstopper but root gets none of his mail. cron is broken, not a showstopper but one cron I've setup does not run Per this thread which narrowed down the issue of out of sync problems, dhclient devd pflog syslogd ntpd and sshd *if I had them used* would be not functional. Unsure in each case. Given a 2004-ish custom kernel, a GENERIC from this month, and a GENERIC fr= om Sept 2015, is there any not time consuming way to do a diff between two or three of them and br= ing the custom kernel upto par with the GENERIC as far as bootability, considering the pos= sibility that it is a loader.conf setting that is at fault? something like /sbin/kernel-too-old ^^^^^^^^^^^^^^^ " please check foo foo from loader conf " or "please check bar bar from CUS= TOM-K " or even " foo bar from CUSTOM-K is missing... "=20=20 ...a utility that would lessen the need for adding/subtracting blocks of (custom ) kernel stuff to/from generic and recompiling one-by-one, or vice-versa, to/from the custom kernel config, seems like a 40 day project UNLESS someone has run into a similar custom -vs- generic situation as a matter of course = and has a workflow to lessen whatever time and compilation effort it takes, which is basically wh= at I am asking here unless a summer of code expert coder of FreeBSD fame knows that the hypothetical b= inary above could be crafted more easily than not and be a tool for developers as well as sim= ple FreeBSD users such as myself... Thanks PS I encourage anyone with a readily helpful answer to add it to UPDATING a= s a resource for persons other than myself who encounter the same difficulty... From owner-freebsd-current@freebsd.org Thu Apr 21 12:26:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A49F1B15524 for ; Thu, 21 Apr 2016 12:26:06 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 39D541E2A; Thu, 21 Apr 2016 12:26:05 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.155] (unknown [86.125.33.32]) by mail.rdsor.ro (Postfix) with ESMTP id 4FB41C4A3; Thu, 21 Apr 2016 15:26:03 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Dan Partelly In-Reply-To: <20160421095706.GA57206@brick> Date: Thu, 21 Apr 2016 15:26:02 +0300 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 12:26:06 -0000 The scenario is: Let=E2=80=99s say I have autofs_enable , working with media map. If I have a CD in CD drive , all is well and when the system is fully = booted up /media contains a directory through which I can access the content of = the=20 CD-ROM. Now if you eject this CD , and insert a new one, nothing = happens. /media does not contain a new access point for the new disk inserted in = the=20 device. =20 What I would expect is when I change the media in Cd-rom , a new=20 access point for the volume in question should be reated in /media. Perhaps this functionality is exposed differently by the automounter, but them I would not expect the CDrom to be accessible at all though the=20= media map.=20 =20 > he problem here is that it's quite hard to fix, there's a risk > of breaking existing functionality, and the problem is largely = cosmetic. until you have more than 10 of them there, when it largely annoying. anyway, what is the reason it is very hard to fix and it would break = existing functionality. can you please shed some light ? =20 > Huh, never heard about that. I'd expect the existing mechanism to = handle > that case just fine. Could you submit a PR? > On 21 Apr 2016, at 12:57, Edward Tomasz Napiera=C5=82a = wrote: >=20 > On 0420T1545, dan_partelly wrote: >=20 > [..] >=20 >> Another example is the autofs mounter. The prject was marked as = complete >> by FreeBSD foundation in 2014. Last I tried it to autmount removable >> devices, it left directory after directory in the autofs managed = directory. >> This is known behavior. >=20 > Yup. The problem here is that it's quite hard to fix, there's a risk > of breaking existing functionality, and the problem is largely = cosmetic. >=20 >> It also did not worked as it should ??? (show it >> manage removable media correctly ) changing CD/DVD media disks. = Presumably >> In could have somehow manage it to work by making yet another = scaffolding >> of scripts as a questionable glue between devd and automounters. = That if >> devd receives media change notifications. I dont know. If not I could = patch >> the kernel, yeah. But it is just much to simple to not bother at all = and >> use OSx.=20 >=20 > Huh, never heard about that. I'd expect the existing mechanism to = handle > that case just fine. Could you submit a PR? >=20 > [..] >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Apr 21 14:46:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AE91B171E4 for ; Thu, 21 Apr 2016 14:46:02 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5569A10A1 for ; Thu, 21 Apr 2016 14:46:02 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id p188so98605864oih.2 for ; Thu, 21 Apr 2016 07:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=Uw8597LRlP5H7DxHgAJQ/CNBrUiIGUfqC7tvSpashes=; b=bApy94G1BZCF8nkZ4prdrlnw/LUYHYmFlFJdWJijAVlxJv7MsCNEnd9pJWvnt/9eup BjJIhJvR0HK+23OVjwRNOE/QR9AWPaoetqNvcA3EZCjzLD/E4sueIjg7rkAPcBe6JAL7 MyTHpe2IO8+DK1QKJv4SXRyuxQq19g9Pn25Vj8AcjvbMJqTMMiMsGrsOtcSVwH7RgUoh CJrjxw2nM3zrmOYvSUvH2GySpvoVs8fQAapGSzsSp8tKVwlC1koOCo7p4j9ao0MieKtr 70xt6MITZ4nUC9tEa+DO6xvF8oPq8KE06neA0jMq2cERhq1KnZsIG3RGE3dj5m3iyZ1q jNvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Uw8597LRlP5H7DxHgAJQ/CNBrUiIGUfqC7tvSpashes=; b=Q2fFymnw5WDfdrX3gXwe75zPhkzMoHWFQa9054QeeIvOnwRNlBJo4Uagy/27VzU2Bq qMnChuAU8FtEoEQa6JU32LR+4Ip9BfH+fwfSlEALEcTcCyx4NACflE/lrLAWn9bLdvDH CYeQsWKWW07/HzJNBf59IKMLTv2kO6jeJr6/YcbrIn7DIb/m1hfKYEkhkIDx44MIrUUD H2MvOt1P78yhfBujSIlE11kEkA7ZcxL2BzwzFYR5i0YBHjX4oDuv6JoeSc6iiqzWmFwF IYrI+tWHW0gsfSmvw0qmW0BLT4LfL7okkIK9Bo0gmBkFYvfUPq/8l1o6+FXWRmAE7QCK LQUA== X-Gm-Message-State: AOPr4FWcfT6FbpJhEx7bC4fI79+fOXxI/hhXi/Q82H8iY9yqHic+mGv9HzjyiAUsvEf4Y1wKzeOjtMRdls7+tA== MIME-Version: 1.0 X-Received: by 10.157.14.56 with SMTP id c53mr6726736otc.136.1461249961534; Thu, 21 Apr 2016 07:46:01 -0700 (PDT) Received: by 10.202.199.135 with HTTP; Thu, 21 Apr 2016 07:46:01 -0700 (PDT) Date: Thu, 21 Apr 2016 10:46:01 -0400 Message-ID: Subject: extremely slow to get to loader From: Johannes Dieterich To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 14:46:02 -0000 Dear all, with r298385, I observe extremely long times from turning on my laptop to reach loader. This is a regression compared to a roughly 1 week old CURRENT. This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup. Please let me know how I can help to solve this issue. Thanks, Johannes From owner-freebsd-current@freebsd.org Thu Apr 21 15:45:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8864B14482 for ; Thu, 21 Apr 2016 15:45:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B4A761A1F for ; Thu, 21 Apr 2016 15:45:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id B05D7B14481; Thu, 21 Apr 2016 15:45:24 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B001AB14480 for ; Thu, 21 Apr 2016 15:45:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (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 028C81A1E for ; Thu, 21 Apr 2016 15:45:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B2262D6.dip0.t-ipconnect.de [91.34.98.214]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id u3LFhvkO059979 for ; Thu, 21 Apr 2016 17:43:57 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id u3LFjCuE030600 for ; Thu, 21 Apr 2016 17:45:12 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id u3LFj4hk096077 for ; Thu, 21 Apr 2016 17:45:12 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201604211545.u3LFj4hk096077@fire.js.berklix.net> To: current@freebsd.org Subject: some mtree missing in buildworld From: "Julian H. Stacey" Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-URL: http://www.berklix.eu/~jhs/cv/ Date: Thu, 21 Apr 2016 17:45:04 +0200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:45:24 -0000 Hi current@ There seems some invocation of mtree missing in make buildworld, & also an undefined reference to `_libmd* I detected it upgrading a year old current to today's current: ------ uname -a FreeBSD blak.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #11881: Sun Mar 22 19:23:17 CET 2015 jhs@blak.js.berklix.net:/usr/src/sys/amd64/compile/BLAK.small amd64 rm -rf /usr/src mkdir /usr/src cd /usr/src ctm -q /pub/FreeBSD/development/CTM/src-cur/src-cur.12300xEmpty.gz ctm -q /pub/FreeBSD/development/CTM/src-cur/src-*.1[0-9][0-9][0-9][0-9].gz cat .ctm* src-cur 12446 # That's todays latest cat .svn_revision 298360 /etc/src.conf is an empty file ie all commented out make obj make buildworld cc -O2 -pipe -DBERKLIX=YES -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -DDEBUGDIR=\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/kgdb/../arch/amd64 -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/amd64 -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../../lib/libreadline/readline/.. -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-loca! l-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o kgdb.full main.o kld.o kthr.o trgt.o trgt_amd64.o /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../gdb/libgdb/libgdb.a /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/libbfd.a /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libopcodes/libopcodes.a /usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libiberty/libiberty.a -lm -L/usr/obj/usr/src/gnu/lib/libreadline/readline -L/usr/obj/usr/src/gnu/lib/libreadline/readline -lreadline -lncursesw -lncursesw -lncursesw -lgnuregex -lkvm main.o: In function `main': /usr/src/gnu/usr.bin/gdb/kgdb/main.c:478: undefined reference to `kgdb_trgt_pc_fixup' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[6]: stopped in /usr/src/gnu/usr.bin/gdb/kgdb make includes Various breakages repaired by my subsequent manual mkdir eg mkdir -p /usr/include/private/bsdstat make includes ===> lib/libcasper/services (includes) ===> lib/libcasper/services/cap_dns (includes) install -C -o root -g wheel -m 444 /usr/src/lib/libcasper/services/cap_dns/cap_dns.h /usr/include/casper/ install: /usr/include/casper/: No such file or directory *** Error code 71 cd /usr/src/etc/mtree make install cd /etc/mtree vi -c/casper BSD.include.dist cd /usr/src make _worldtmp cd /usr/obj/usr/src/tmp tar cf - . | ( cd / && tar xf - ) ls -la /usr/include/casper total 12 drwxr-xr-x 2 root wheel 512 Apr 21 17:08 ./ drwxr-xr-x 60 root wheel 6656 Apr 21 17:09 ../ cd /usr/src make includes cd /usr/src/gnu/usr.bin/gdb/kgdb ; make Runs for a while cd /usr/src/gnu/usr.bin/gdb/; make Runs for a while make upgrade_checks make buildworld cc -O2 -pipe -DBERKLIX=YES -I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o xinstall.full xinstall.o getid.o -lmd -legacy xinstall.o: In function `digest_init': /usr/src/usr.bin/xinstall/xinstall.c:414: undefined reference to `_libmd_MD5Init' ... /usr/src/usr.bin/xinstall/xinstall.c:470: undefined reference to `_libmd_SHA512_End' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[3]: stopped in /usr/src/usr.bin/xinstall cd /usr/src/lib/libmd ; make ; make install cd /usr/src/usr.bin/xinstall ; make ; make install cd /usr/src; make buildworld Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/ Mail plain text, No quoted-printable, HTML, base64, MS.doc. Prefix old lines '> ' Reply below old, like play script. Break lines by 80. Let Brits in EU vote on Brexit https://petition.parliament.uk/petitions/112142 From owner-freebsd-current@freebsd.org Thu Apr 21 16:02:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 552ACB14D99 for ; Thu, 21 Apr 2016 16:02:53 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D86014ED for ; Thu, 21 Apr 2016 16:02:52 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1461254566; bh=qQ/ioJDEk/73lskgNQmCDWg7Td18dYV2oxy1tHejQjA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=DBiGKLKciBTt70pzF5JogDm+Pt7U1wJyx9CAi0H1rKnClJNSVZZmoazGz388kfMyYF8hFNV9t9DP61bAzpHUgZSYc/LUvib/BKfG3sZlOJLqE41HgS9024Rq1EusTEAqxUe5m5WJDj4Bfh5/ZwXzmnmUTMOopj2YSKmXDi1X3DHXfnhZNhzJWdLvu5uuobQEuLV20qE+gtb0l2KJvV+MhVW9OmJRcovd2Q/6nq7XkjAoggmKKOJjo1N1bzR5iJGUpCPnXDp7DJkaRVFpxw9rRVP8DE/JeTvC5C8aC3bLxw36mT8KPkXyKCaZ5TmHwipPchqBmtT0eWAKGbwk7cUYHA== Received: from [98.139.170.180] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 21 Apr 2016 16:02:46 -0000 Received: from [98.139.211.193] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 21 Apr 2016 16:02:46 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 21 Apr 2016 16:02:46 -0000 X-Yahoo-Newman-Id: 313284.60291.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zj6Cz_8VM1mdONsP4ptGZLh0AmAtuLZQSPZ9B9gGjDdw5PJ YZbGIA76Hdm2XENK1lRHKT8LZ62EmiGPy0jMqKaBD.OtkghXmSFiH1QyVA4F A7.Cdm1L1uxwJg6LFLVG.LjEEaanSD2TdVwIjQB3MqdtHGN7uuRT9GDWG1G7 KyCVpDufYNrQkvi.tZsJUHG_f9JQWnJZDBJWVZ1qyd4c20PrM8eJyhD_YCt7 FDkoIcdQ_7CV0O.jsMu9vVZPFvSHW8U0YekAsq8EjWe1nc7RxakYQ2b_iDwk _6XRR2NM9SG.3iBMLXw1EabVzXlxMMloXfvXOTlxcZW8vKoc3I1W6JVqDKIC mEMgVfO1VlBnherHgGWJyceH0WVclgL63hEUdDm7USU_FKUEKUQnWIRLqrLI k5EN0ny1wRJay5QQvSFV20KIueuZ8iHbwu9hhqCz.HTstiSS6t1L2MZdV6M. qR5E4TxMZXLu2zFYQFRd0ZmIlmE.MdOAWAEzWsggRtoslfKlARkfx764rBGc k02w3CPex.U9kwuTUKxDNsvBkQ_NjDo9d X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: CFR: extend use of nitems() macro in the kernel. To: John Baldwin , freebsd-current@freebsd.org References: <57128385.6090307@FreeBSD.org> <1920453.prUgCpdaXV@ralph.baldwin.cx> From: Pedro Giffuni Message-ID: <8f87b91a-eb69-92fa-1b5b-7cf3f64b3942@FreeBSD.org> Date: Thu, 21 Apr 2016 11:02:52 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1920453.prUgCpdaXV@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:02:53 -0000 On 04/18/16 13:27, John Baldwin wrote: > On Saturday, April 16, 2016 01:25:09 PM Pedro Giffuni wrote: >> Hello; >> >> Using coccinelle, and some hand re-formatting, I generated a patch to >> make use of the nitems() macro in sys, which is too big for >> phabricator [1]. >> >> I was careful to exclude anything from the contrib directory or >> any code that is shared with userland (as to not have to include >> additional headers). >> >> The patch is big but pretty safe, I think. The changes are small but >> still it touches many files[1]. >> >> I would like some feedback on the convenience of doing such replacement. >> If it is a good idea we could do the same for roundup2() and, in fact, >> I think DragonFly has already done this. >> >> Regards, >> >> Pedro. >> >> [1] https://people.freebsd.org/~pfg/patches/sys-nitems.diff >> >> [2] For those too lazy to check [1], here is a list of affected files. >> >> M sys/amd64/amd64/amd64_mem.c >> M sys/amd64/amd64/machdep.c >> M sys/amd64/linux/linux_sysvec.c >> M sys/amd64/linux32/linux32_sysvec.c >> M sys/arm/amlogic/aml8726/aml8726_clkmsr.c >> M sys/arm/arm/db_interface.c >> M sys/arm/at91/at91_pmc.c >> M sys/arm/mv/armadaxp/armadaxp.c >> M sys/arm/ti/cpsw/if_cpsw.c >> M sys/arm/xscale/ixp425/ixp425.c >> M sys/boot/common/part.c >> M sys/boot/efi/loader/bootinfo.c >> M sys/boot/mips/beri/boot2/boot2.c >> M sys/boot/uboot/common/metadata.c >> M sys/cam/ata/ata_da.c >> M sys/cam/ata/ata_xpt.c > > I would perhaps remove ata_quirk_table_size entirely and replace its > use with nitems() directly. Probably best if that was a separate commit > though from the near-mechanical replacement. > >> M sys/cam/cam.c > > Same here. num_cam_status_entries is only used in one place and I think > directly using nitems() is probably clearer overall. > >> M sys/cam/scsi/scsi_all.c > > Possibly the same here with sense_key_table_size. > >> M sys/cam/scsi/scsi_cd.c >> M sys/cam/scsi/scsi_da.c >> M sys/cam/scsi/scsi_sa.c >> M sys/cam/scsi/scsi_xpt.c > > Same as for ata_quirk_table_size (ironically this used the size in one > place and the expanded form of nitems in another while the ata variant > at least used the size in both places). > >> M sys/cam/scsi/smp_all.c >> M sys/compat/linux/linux_socket.c >> M sys/ddb/db_variables.c >> M sys/dev/adb/adb_kbd.c >> M sys/dev/advansys/adv_isa.c >> M sys/dev/advansys/advlib.c >> M sys/dev/advansys/adw_pci.c > > Same here for num adw_num_pci_devs (only used once) > >> M sys/dev/advansys/adwlib.c > > Probably the same here for adw_num_sync_rates (used twice). > >> M sys/dev/ae/if_ae.c > > Same here for AE_DEVS_COUNT (only used once). > >> M sys/dev/age/if_age.c >> M sys/dev/agp/agp.c >> M sys/dev/agp/agp_ali.c >> M sys/dev/agp/agp_amd64.c >> M sys/dev/aha/aha_isa.c >> M sys/dev/aic/aic.c >> M sys/dev/aic/aic_cbus.c > > Same here for AIC_ISA_NUMPORTS (only used once). > >> M sys/dev/aic/aic_isa.c > > As above. > >> M sys/dev/ale/if_ale.c >> M sys/dev/altera/atse/if_atse.c >> M sys/dev/atkbdc/atkbd.c >> M sys/dev/atkbdc/atkbdc.c >> M sys/dev/atkbdc/psm.c >> M sys/dev/bktr/bktr_core.c >> M sys/dev/bwi/bwirf.c >> M sys/dev/bwn/if_bwn.c >> M sys/dev/cardbus/cardbus_cis.c >> M sys/dev/digi/digi.c >> M sys/dev/digi/digi_isa.c >> M sys/dev/dwc/if_dwc.c >> M sys/dev/ed/if_ed_hpp.c >> M sys/dev/ed/if_ed_isa.c >> M sys/dev/ed/if_ed_pci.c >> M sys/dev/fb/creator.c > > Same here for CREATOR_FB_MAP_SIZE (only used once). > >> M sys/dev/fb/fb.c >> M sys/dev/fb/machfb.c >> M sys/dev/fb/vesa.c >> M sys/dev/fb/vga.c >> M sys/dev/flash/mx25l.c >> M sys/dev/hatm/if_hatm.c >> M sys/dev/hifn/hifn7751.c >> M sys/dev/hwpmc/hwpmc_amd.c > > Same here for amd_event_codes_size (only used twice). > >> M sys/dev/hwpmc/hwpmc_core.c > > Same here for niap_events. > >> M sys/dev/hwpmc/hwpmc_e500.c > > e500_event_codes_size isn't even used. It should just be removed. > >> M sys/dev/hwpmc/hwpmc_mips24k.c >> M sys/dev/hwpmc/hwpmc_mips74k.c >> M sys/dev/hwpmc/hwpmc_mpc7xxx.c > > Same here for mpc7xxx_event_codes_size. > >> M sys/dev/hwpmc/hwpmc_octeon.c >> M sys/dev/hwpmc/hwpmc_uncore.c > > Same here for nucp_events. > >> M sys/dev/hwpmc/hwpmc_xscale.c > > Same here for xscale_event_codes_size. > >> M sys/dev/if_ndis/if_ndis.c >> M sys/dev/jme/if_jme.c >> M sys/dev/kbd/kbd.c >> M sys/dev/le/if_le_isa.c >> M sys/dev/le/if_le_lebuffer.c > > Same here for NLEMEDIA (only used once). > >> M sys/dev/le/if_le_ledma.c >> M sys/dev/mlx/mlx.c >> M sys/dev/mxge/if_mxge.c >> M sys/dev/nand/nand_id.c >> M sys/dev/ncr/ncr.c >> M sys/dev/nctgpio/nctgpio.c >> M sys/dev/nfe/if_nfe.c >> M sys/dev/patm/if_patm_attach.c >> M sys/dev/pccard/pccard_cis_quirks.c > > Same here for n_pccard_cis_quirks (only used once). > >> M sys/dev/rc/rc.c >> M sys/dev/re/if_re.c >> M sys/dev/rl/if_rl.c >> M sys/dev/rndtest/rndtest.c > > Same here for RNDTEST_NTESTS (only used once). > >> M sys/dev/sf/if_sf.c >> M sys/dev/sge/if_sge.c > > Same here for 'cnt' (only used once). > >> M sys/dev/siba/siba.c > > Same here for 'bound'. I would actually simplify this function > even further so it just does 'return (sd)' instead of 'break' > in the loop body. This means you can remove the '==' check > and just 'return (NULL)' if the loop completes. It also means > that 'bound' is then only used once. > >> M sys/dev/sio/sio.c >> M sys/dev/sound/isa/gusc.c >> M sys/dev/sound/pci/emu10kx.c > > Same here for 'n_cards' (it is only used once after each assignment). > >> M sys/dev/speaker/spkr.c >> M sys/dev/stge/if_stge.c >> M sys/dev/uart/uart_kbd_sun.c >> M sys/dev/uart/uart_subr.c > > Same here for 'uart_nclasses' (only used once). > >> M sys/dev/usb/input/ukbd.c >> M sys/dev/usb/serial/u3g.c >> M sys/dev/usb/serial/uchcom.c > > Same here for NUM_DIVIDERS (only used once). > >> M sys/dev/usb/serial/umcs.c >> M sys/dev/usb/serial/uplcom.c > > Same here for N_UPLCOM_RATES (only used once). > >> M sys/dev/vkbd/vkbd.c >> M sys/dev/wbwd/wbwd.c >> M sys/fs/autofs/autofs.c >> M sys/fs/nfs/nfs_commonkrpc.c >> M sys/geom/part/g_part_bsd.c >> M sys/geom/part/g_part_ebr.c >> M sys/geom/part/g_part_ldm.c >> M sys/geom/part/g_part_mbr.c >> M sys/i386/i386/i686_mem.c >> M sys/i386/i386/machdep.c >> M sys/i386/ibcs2/ibcs2_sysvec.c >> M sys/i386/linux/linux_sysvec.c >> M sys/kern/kern_dump.c >> M sys/kern/kern_ffclock.c >> M sys/kern/kern_jail.c >> M sys/kern/kern_ktrace.c >> M sys/kern/subr_hash.c > > Same here for NPRIMES (only used once). > >> M sys/kern/subr_witness.c > > Same here for blessed_count (only used once). > >> M sys/kern/sysv_msg.c >> M sys/kern/sysv_sem.c >> M sys/kern/uipc_usrreq.c >> M sys/mips/mips/db_interface.c >> M sys/mips/nlm/board.c >> M sys/mips/nlm/xlp_machdep.c > > Same here for nreg (only used once). > >> M sys/mips/rmi/dev/nlge/if_nlge.c > > Same here for n_gmac_buckers and n_regs (each only used once). > >> M sys/net/netisr.c > > I would do the same here for netisr_dispatch_table_len. It is > used in three loops, but in all three the code would be: > > for (i = 0; i < nitems(foo); i++) { > /* use foo[i] */ > } > > For that idiom, I think using nitems is clearer to the reader vs one of > NFOO, nfoo, foo_size, foo_len, etc. if for no other reason than > consistency. I think it is also more explicit. > >> M sys/net/rtsock.c >> M sys/netgraph/atm/ng_atm.c >> M sys/netgraph/bluetooth/socket/ng_btsocket.c > > Same here for ng_btsocket_protosw_size (only used once). > >> M sys/netgraph/ng_gif_demux.c >> M sys/netgraph/ng_iface.c > > Possibly the same for NUM_FAMILIES in these two files. > ... > > The changes overall look fine to me. I just think we should take the chance > to inline cases where the variable is only ever used once or is only used in > the for loop idiom where I think the explicit nitems() is clearer to the > reader. > Huge thanks for the detailed review. I have done the cleanups related to consts and variables. I would prefer to leave the macros still there, even if they are used only once: in at least one case they actually help driver readability and may generally help understand the author's intent. It may also be that they help upstream (or downstream) maintainers. I am running a buildworld with the final nitems() changes. Regards, Pedro. From owner-freebsd-current@freebsd.org Thu Apr 21 16:16:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3F15B166E3 for ; Thu, 21 Apr 2016 16:16:29 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id C40DB1669 for ; Thu, 21 Apr 2016 16:16:29 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5B92FDB43 for ; Thu, 21 Apr 2016 16:16:23 +0000 (UTC) Subject: Re: extremely slow to get to loader To: freebsd-current@freebsd.org References: From: Allan Jude Message-ID: <5718FCD6.8020605@freebsd.org> Date: Thu, 21 Apr 2016 12:16:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aCkjOeg2Fq40EfDGedaibF861AAvRhEol" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:16:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aCkjOeg2Fq40EfDGedaibF861AAvRhEol Content-Type: multipart/mixed; boundary="0QPwr5nMIc6dINu50h28WLUjaDK2jBgg6" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <5718FCD6.8020605@freebsd.org> Subject: Re: extremely slow to get to loader References: In-Reply-To: --0QPwr5nMIc6dINu50h28WLUjaDK2jBgg6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-04-21 10:46, Johannes Dieterich wrote: > Dear all, >=20 > with r298385, I observe extremely long times from turning on my laptop > to reach loader. This is a regression compared to a roughly 1 week old > CURRENT. >=20 > This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI = setup. >=20 > Please let me know how I can help to solve this issue. >=20 > Thanks, >=20 > Johannes > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Can you describe where exactly it is slow? Once you get to the loader menu (the beastie menu), can you choose the option to go to the loader prompt, and type: bcachestat And provide the output of that. --=20 Allan Jude --0QPwr5nMIc6dINu50h28WLUjaDK2jBgg6-- --aCkjOeg2Fq40EfDGedaibF861AAvRhEol Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJXGPzXAAoJEBmVNT4SmAt+xQ8QAOuV0zo+wycz0h12lCz+hIC8 mbI+mVSAVEh+EZxD+cuQ3vVjjN24y1LaOBXT4YxOasnqwcNIOVpkPtveDnOF8eI/ GZuedmyYY/OR7qQEBPopdwAX2PLn/OamSrIPOC1NZvv+/wDlMBzYEJkX7pvphlY9 IUqF1dyVeNqTQISM+4fc0SIxgQcgas9ufpbymnwDwOyDlB/eTbIn7R/xJgHO+Zg3 PzFYwxu4RChTgA2MxwWHB+wR0DHv/n2JvJb3WQ2CrgQOL/WrjG0fZ3kp4DVMhTCg RvRTcFHww0uD7JkrFUQupo25yA4hVaggysxv25VkScN7BkA3uHXt9hiwHniXRurR wvFtg1zfH2SgBt3XnfqEwA+xeXmXrPP+0pXHw1S5Y8wzQeUeKBaTChLuqUiEl7T9 MgWmYfELy2NqV54cmzMrSWfTxPMguw28POVWLP0M2c+QUy6SMJQ4V33WeF4CLasB ciCVYWY6vVAWuyv3fb8OWjy8SYM0aHMIzbkHH8Pc0S/34wnsSDCGCVj3IAdqWBVZ s1jcNH71eqz+r4XUBvRIQ6+Y+uL8wdiuPptJDKPBk5mVAh0mA6ouM1qlV51eESWc lt1MRpp0I2ch46OfB3+uh5X0OuB24BOtp6JhiRDG+93acd/CcZd2dXOc/RFzsl9Q UIHRMZvYiRbuD7q1nuVf =Stqd -----END PGP SIGNATURE----- --aCkjOeg2Fq40EfDGedaibF861AAvRhEol-- From owner-freebsd-current@freebsd.org Thu Apr 21 20:20:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDD0AB18DCB for ; Thu, 21 Apr 2016 20:20:29 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 8384A12C4 for ; Thu, 21 Apr 2016 20:20:29 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id e201so19904349wme.2 for ; Thu, 21 Apr 2016 13:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=C3UYpmApLeE+8EC3/c7FsdJCzIMphMHuiV4ROu9C+lg=; b=qggebw21SKUWEOG+Y7WorDlmmizyG+kqUTF9/+VWAph8tYkG7pBaShNzFZC00RkA+2 g0vCjlEJ8496cBbDuMbO0KFKoEXdnBbGeHmEXjpCjyw+wCGL7au94zIaze3EtJYwSmNi nFAjlF8ZBZR2enp/jde+9TsPqEL2hVAIx/MufmBYqpo6HteqoPavX+GiiV245FyxHpG2 Mi6gBnNY+2CrvjNkS0B2BsviwO3GdXsKY3+rE4Ijy+RnRezBz+ahUIbVgfletRtd2fgG 6DbC+fiCaGIu5VEnUfpMq21RIRav3jWwhngE5nBPeRaDkgqfumDRfI+i+WRVfirv4OfV 3oYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=C3UYpmApLeE+8EC3/c7FsdJCzIMphMHuiV4ROu9C+lg=; b=UVnoF4RoIj8IDqDljC7P3H+xD2Ebr/W/YPX2R2vrp2f5r5UgdZOTgC3mYL9cUKoEEc bdyodKEes/nhrgtE7/lO7om1+Rb2JrVO6nGAPFuSeqIiDtNxVRO3qSNouuF5K2ZeZMHl zI8qz1SmCd1NnacMOb1YZ2pRSfaXuGjlqP2QY90uPXVv3JRp+c3E9k5GlXRuR3ucc3xf oKGU/MrTxvOZ4h2mnG8vcVbm+3wckdwNH7DB/NeLlRuwbV2R0gNNgKbhqkdTks3X2yV2 dikIU7VUY0HrMn0KfI8fRK522/lA0yjV18KT2Eiq6wtQoUqliCx4oVnpTQHi9b+Ewbye OvrA== X-Gm-Message-State: AOPr4FURTEEjeBzbskcQQ/8kEGPCciDj1OhgEfThdTswflkLSmmn5XayP4oflkxKS7uRmw== X-Received: by 10.194.248.200 with SMTP id yo8mr16362096wjc.38.1461270028130; Thu, 21 Apr 2016 13:20:28 -0700 (PDT) Received: from brick (evp155.neoplus.adsl.tpnet.pl. [83.20.213.155]) by smtp.gmail.com with ESMTPSA id f204sm4897219wmf.22.2016.04.21.13.20.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Apr 2016 13:20:26 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 21 Apr 2016 22:20:23 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Dan Partelly Cc: freebsd-current Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160421202023.GB33506@brick> Mail-Followup-To: Dan Partelly , freebsd-current References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:20:30 -0000 On 0421T1526, Dan Partelly wrote: > The scenario is: > > Let’s say I have autofs_enable , working with media map. > > If I have a CD in CD drive , all is well and when the system is fully booted up > /media contains a directory through which I can access the content of the > CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. > /media does not contain a new access point for the new disk inserted in the > device. > > What I would expect is when I change the media in Cd-rom , a new > access point for the volume in question should be reated in /media. > > Perhaps this functionality is exposed differently by the automounter, > but them I would not expect the CDrom to be accessible at all though the > media map. If by "access point" you mean the directory, then it will, unless the CD doesn't have a label - in that case the device name will be used instead, and since it's the same device, it will be the same name - usually "cd0". However - I've just checked to make sure and it works the way it should. What you're decribing seems like you're missing the part of devd.conf(5) responsible for notifying autofs about media change. Do you? > > he problem here is that it's quite hard to fix, there's a risk > > of breaking existing functionality, and the problem is largely cosmetic. > > until you have more than 10 of them there, when it largely annoying. > anyway, what is the reason it is very hard to fix and it would break existing > functionality. can you please shed some light ? Basically, the autofs doesn't support removing the nodes. It wasn't really required for the usual use case, and it simplified the code a lot. Plan was to pick it up again with my next filesystem project, and simply retrofit the changes back to autofs - but that hasn't happened (yet). [..] From owner-freebsd-current@freebsd.org Thu Apr 21 20:30:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CF71B172DF for ; Thu, 21 Apr 2016 20:30:04 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 56E9319AC for ; Thu, 21 Apr 2016 20:30:04 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 563B8B172DC; Thu, 21 Apr 2016 20:30:04 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5567FB172DB for ; Thu, 21 Apr 2016 20:30:04 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1D4C19A1 for ; Thu, 21 Apr 2016 20:30:03 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1atLEd-0005HY-98; Thu, 21 Apr 2016 22:29:59 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1atLEd-0001mu-8g; Thu, 21 Apr 2016 22:29:59 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Thu, 21 Apr 2016 20:29:59 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" CC: "current" , "kernel" Subject: [Solved] [WAS:libc build error] Mostly all solved bw-iw-ik from 4-20-2016 Date: Thu, 21 Apr 2016 13:29:59 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:30:04 -0000 On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 >=20 > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 > >=20 > >=20 > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude = wrote: > >=20 > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > > unistd > > > >=20 > > > >=20 > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected fu= nction body after function declarator > > > > int execl( ................................. > > > > 332:46:=20= =20=20=20 > > > > same... > > > >=20 > > > > stops libc > > > > otherwise clang36 seems to be building so far, if it builds unsure = about installworld > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" > > > >=20 > > >=20 > > > The mailing list strips attachments. Can you upload it somewhere and > > > provide a link > > >=20 > > > --=20 > > > Allan Jude > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" > >=20 > >=20 > > Well, it is now r298350 Wed Apr 20... > > However several problems > >=20 > > SINGLE-USER BOOT PROBLEMS > > 1... usual boot fails, this is single-user adjusted, but I cannot add s= wap (swapon? swapctl?) > > 1a... the last time, it was fixed with using the old /kernel ...=20 > >=20 > > multi-user boot problems > >=20 > > 2... the last usual boot dumped with vm_pager or something, verbose bo= ot times out with xpt_config not completing. > > 2a.... could be a wrong setting is loader.conf, the nvidia.ko not yet u= pdated (which it now is ) for the latter > > case I have yet to reboot to test > > 2b... Reboot to test takes longer, /rescue/mount each filesystem in= dividually...=20 > >=20 > >=20 > > As one might surmise, I'd rather see buildworld made more foolproof tha= n other recent improvements=20 > > (pkg, zfs, ...) >=20 > From backup, I have r288246 kernel and nvidia.ko (v11) > from source, I have world and all except those TWO files at r298350 )(v11= ), nvidia (newer) won't load with older kernel > A few at-boot scripts no longer work as expected... but no other major pr= oblems (swap is present again) > (multi-user boot works)=20 >=20 > Best practice maybe to update the kernel? It is a custom one from way ba= ck in 2004 initially > without sound drivers and without debug symbols... and many esoteric lin= es added which I cobbled > together at first then changed per diffs of GENERIC over the years... >=20 > Thanks for any known methods >=20 > J. Bouquet > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Updated to a slightly-less-than-full GENERIC. Still dumped core. Moved lo= ader.conf out of the way, works fine. What will take some time now is moving loader.conf ba= ck piece by piece [until/if there is/ever was a utility to do it for us... ] to find the prob= lematic line or two, then resume testing of the install of the custom kernel that also is 'fail' stat= us at this point... unless/until I decide to also test it, THEN resume the loader.conf line-by-line back in.= .. tl;dr loader.conf problematic line and maybe an additional unknown in eit= her kernel text file.= From owner-freebsd-current@freebsd.org Thu Apr 21 20:48:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B74ECB17D0D for ; Thu, 21 Apr 2016 20:48:08 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id D1D1F1AAB; Thu, 21 Apr 2016 20:48:07 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.101] (unknown [79.117.119.78]) by mail.rdsor.ro (Postfix) with ESMTP id E7CA4DC102; Thu, 21 Apr 2016 23:48:00 +0300 (EEST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Dan Partelly In-Reply-To: <20160421202023.GB33506@brick> Date: Thu, 21 Apr 2016 23:48:00 +0300 Cc: freebsd-current Message-Id: <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:48:08 -0000 Yes, you are right it misses the media change handler in devd.conf.=20 maybe it should bementioned somewhere in a man page if it is not already there. Thanks for the pointer. Anyway, if I would have written the system, what I would have done is to consolidate both user mode daemons into one and make this daemon a client of devd, fstyp a library, and handle all removable=20 media inside transparent to the user, without requiring any = modifications to devd.conf, and without relaying on shell scripts.=20 Is there any reason you did not took this approach ? This is not criticism, I am genuinely interested. > and simply > retrofit the changes back to autofs - but that hasn't happened (yet). Please consider doing it. A kevent on /media would allow other programs to see how volumes come and go, and I can imagine several situations=20 where this can be handy. And too many directories left there do become annoying.=20 > On 21 Apr 2016, at 23:20, Edward Tomasz Napiera=C5=82a = wrote: >=20 > On 0421T1526, Dan Partelly wrote: >> The scenario is: >>=20 >> Let=E2=80=99s say I have autofs_enable , working with media map. >>=20 >> If I have a CD in CD drive , all is well and when the system is fully = booted up >> /media contains a directory through which I can access the content of = the=20 >> CD-ROM. Now if you eject this CD , and insert a new one, nothing = happens. >> /media does not contain a new access point for the new disk inserted = in the=20 >> device. =20 >>=20 >> What I would expect is when I change the media in Cd-rom , a new=20 >> access point for the volume in question should be reated in /media. >>=20 >> Perhaps this functionality is exposed differently by the automounter, >> but them I would not expect the CDrom to be accessible at all though = the=20 >> media map.=20 >=20 > If by "access point" you mean the directory, then it will, unless the = CD > doesn't have a label - in that case the device name will be used = instead, > and since it's the same device, it will be the same name - usually = "cd0". >=20 > However - I've just checked to make sure and it works the way it = should. > What you're decribing seems like you're missing the part of = devd.conf(5) > responsible for notifying autofs about media change. Do you? >=20 >>> he problem here is that it's quite hard to fix, there's a risk >>> of breaking existing functionality, and the problem is largely = cosmetic. >>=20 >> until you have more than 10 of them there, when it largely annoying. >> anyway, what is the reason it is very hard to fix and it would break = existing >> functionality. can you please shed some light ? =20 >=20 > Basically, the autofs doesn't support removing the nodes. It wasn't > really required for the usual use case, and it simplified the code a = lot. > Plan was to pick it up again with my next filesystem project, and = simply > retrofit the changes back to autofs - but that hasn't happened (yet). >=20 > [..] From owner-freebsd-current@freebsd.org Thu Apr 21 21:10:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 094E6B1863E for ; Thu, 21 Apr 2016 21:10:46 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E9B8E1962 for ; Thu, 21 Apr 2016 21:10:45 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id E9124B1863D; Thu, 21 Apr 2016 21:10:45 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8B4FB1863C for ; Thu, 21 Apr 2016 21:10:45 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE99C1960 for ; Thu, 21 Apr 2016 21:10:45 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1atLs0-0000mD-PF; Thu, 21 Apr 2016 23:10:40 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1atLs0-0007sG-Ol; Thu, 21 Apr 2016 23:10:40 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Thu, 21 Apr 2016 21:10:40 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" CC: "jbtakk" , "kernel" Subject: Re: Re: Installworld, BW, IK fixed, here are the in > out loader.conf lines Date: Thu, 21 Apr 2016 14:10:40 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 21:10:46 -0000 On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 >=20 > On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 > >=20 > >=20 > > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" wrote: > >=20 > > >=20 > > >=20 > > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude wrote: > > >=20 > > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > > > unistd > > > > >=20 > > > > >=20 > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected = function body after function declarator > > > > > int execl( ................................. > > > > > 332:46:= =20=20=20=20 > > > > > same... > > > > >=20 > > > > > stops libc > > > > > otherwise clang36 seems to be building so far, if it builds unsur= e about installworld > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" > > > > >=20 > > > >=20 > > > > The mailing list strips attachments. Can you upload it somewhere and > > > > provide a link > > > >=20 > > > > --=20 > > > > Allan Jude > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" > > >=20 > > >=20 > > > Well, it is now r298350 Wed Apr 20... > > > However several problems > > >=20 > > > SINGLE-USER BOOT PROBLEMS > > > 1... usual boot fails, this is single-user adjusted, but I cannot add= swap (swapon? swapctl?) > > > 1a... the last time, it was fixed with using the old /kernel ...=20 > > >=20 > > > multi-user boot problems > > >=20 > > > 2... the last usual boot dumped with vm_pager or something, verbose = boot times out with xpt_config not completing. > > > 2a.... could be a wrong setting is loader.conf, the nvidia.ko not yet= updated (which it now is ) for the latter > > > case I have yet to reboot to test > > > 2b... Reboot to test takes longer, /rescue/mount each filesystem = individually...=20 > > >=20 > > >=20 > > > As one might surmise, I'd rather see buildworld made more foolproof t= han other recent improvements=20 > > > (pkg, zfs, ...) > >=20 > > From backup, I have r288246 kernel and nvidia.ko (v11) > > from source, I have world and all except those TWO files at r298350 )(v= 11), nvidia (newer) won't load with older kernel > > A few at-boot scripts no longer work as expected... but no other major = problems (swap is present again) > > (multi-user boot works)=20 > >=20 > > Best practice maybe to update the kernel? It is a custom one from way = back in 2004 initially > > without sound drivers and without debug symbols... and many esoteric l= ines added which I cobbled > > together at first then changed per diffs of GENERIC over the years... > >=20 > > Thanks for any known methods > >=20 > > J. Bouquet > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 >=20 > Updated to a slightly-less-than-full GENERIC. Still dumped core. Moved = loader.conf out of > the way, works fine. What will take some time now is moving loader.conf = back piece by piece > [until/if there is/ever was a utility to do it for us... ] to find the pr= oblematic line or two, then > resume testing of the install of the custom kernel that also is 'fail' st= atus at this point... unless/until > I decide to also test it, THEN resume the loader.conf line-by-line back i= n... >=20 > tl;dr loader.conf problematic line and maybe an additional unknown in e= ither kernel text file. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Half of loader.conf removed. (as below). Custom kernel restored and working. # out snd_pcm_load=3D"YES" # out snd_acm_load=3D"YES" # out kern.msgbufsize=3D"130000" # out kern.ipc.shmmni=3D"1024" # out kern.ipc.shmseg=3D"1024" # out hw.snd.maxautovchans=3D"4" # out hw.snd.targetirqrate=3D"36"=20=20=20=20 # out hint.pcm.0.buffersize=3D"65536"=20 # out hw.snd.verbose=3D"3" # out kern.ipc.semmns=3D"240" # out kern.ipc.semume=3D"40" # out kern.ipc.semmnu=3D"120" # out vfs.read_max=3D"128"=20=20=20=20 # out kern.randompid=3D"1" # out kern.ipc.shmmax=3D"67108864"=20 # out kern.ipc.shmall=3D"32768" # out vm.kmem_size=3D"700M"=20=20=20=20 # out vm.kmem_size_max=3D"700M"=20=20 # out vfs.zfs.arc_max=3D"250M" # out kern.sched.preempt_thresh=3D"224" # out vfs.usermount=3D"1"=20=20=20 # out kern.geom.part.check_integrity=3D"0"=20=20 # out vm.overcommit=3D"1" # out kern.maxfilesperproc=3D"65536" # out kern.ipc.somaxconn=3D"1024" # out kern.ipc.nmbclusters=3D"81920" # out kern.fallback_elf_brand=3D"3" # out vfs.write_behind=3D"0" Quite a lot, as one may see. There is an equal amount non-kern (net...) rem= aining in. Perchance someone sees an obvious problem in a value, and/or is an expert i= n=20 most of them and knows which can be safely restored for furtther testing, a= nd/or which are most useful in a FreeBSD system. Thanks. OTOH this may help others if they also encounter the same problem, and coul= d be included in a future wiki or UPDATING or 'man sysctl' type file somewhere... From owner-freebsd-current@freebsd.org Fri Apr 22 01:56:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0655DB18151 for ; Fri, 22 Apr 2016 01:56:58 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::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 CCD4E18C4; Fri, 22 Apr 2016 01:56:57 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: by mail-oi0-x242.google.com with SMTP id i2so12570670oib.3; Thu, 21 Apr 2016 18:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DBmHBGai4ptZLtASwYKjmFkC6J/DxxKI8HmkY33hdEQ=; b=aGnIj7Fhv//9SNHMaNIsAdKRkP4etDcP7ZE8l0mzC+PR+h7qJZMVr/ip3br6FSYM/A 96FaaXkk+euMaSgiG0w46eC/32NPdcggVQrL872UyuRnfAWHmHzciPBmXbeHlBeNNm3k HmxHKaIxhpL0Rhj5Wx1NB94/v+IYVqOKiRkdkg+ul0S1Hq+zTiljMo5xW5v8Dpt0xC5n yL+kcQ5Tc64rLHtVNGzBhQwdPUyQgCpMJvUgm+edEMkd+hjcrD04jkozTeSNlaOKRAeJ tVGdttzETSJS4cPO45GpzG5xSLpz8aP/ddpk9Z3MXc3aHcA4VA3YKRLBjrfbbISBowHl itGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DBmHBGai4ptZLtASwYKjmFkC6J/DxxKI8HmkY33hdEQ=; b=IfVQO5U+poG4QZHvFdup39UZcILnrVt331zbqhyri4GDXOlU0lYk3X0qxVKThi6WGD iE0f44VY5j7er/7653kAY9PC45D9fDqHTIwJGPcugmsThrxpPONmKy+5Y+LjE53LUIp9 wsHM5SIxE08jQGLtB/wi19EjeXiymM7l0R5f3O2Fc+HFu279VdKlSYobA0BnGkVMyB3c eyL0vKF6BSRLxGbWrGI+RFK0w0KervOD8sdFsAvDRWk6DfhSUctLlmsbj2md1WiUzRSF rXJNSIzMJJEDdo9rwPNjXiFp9coAcxrO3VA9FIPSQcShWyrSwxrAkkzCA5J+5f19OLV8 kL6A== X-Gm-Message-State: AOPr4FUcwgoP+WEqU9jjiW2A1PBgkgEsQlAej5d7vsEzJvLwaoFKfcpT/j0vg2Tdp9vlm0uknMOoV/CIIWN44A== MIME-Version: 1.0 X-Received: by 10.157.14.56 with SMTP id c53mr8021736otc.136.1461290217105; Thu, 21 Apr 2016 18:56:57 -0700 (PDT) Received: by 10.202.199.135 with HTTP; Thu, 21 Apr 2016 18:56:57 -0700 (PDT) In-Reply-To: <5718FCD6.8020605@freebsd.org> References: <5718FCD6.8020605@freebsd.org> Date: Thu, 21 Apr 2016 21:56:57 -0400 Message-ID: Subject: Re: extremely slow to get to loader From: Johannes Dieterich To: Allan Jude Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 01:56:58 -0000 On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude wrote: > On 2016-04-21 10:46, Johannes Dieterich wrote: >> Dear all, >> >> with r298385, I observe extremely long times from turning on my laptop >> to reach loader. This is a regression compared to a roughly 1 week old >> CURRENT. >> >> This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup. >> >> Please let me know how I can help to solve this issue. >> >> Thanks, >> >> Johannes >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > Can you describe where exactly it is slow? Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes before it eventually continues. > Once you get to the loader menu (the beastie menu), can you choose the > option to go to the loader prompt, and type: > bcachestat > > And provide the output of that. Here we go (w/o mistakes I hope...): cache blocks: 32768 cache blocksz: 572 unit cache blocks: 32768 cached units: 1 1162 ops 0 bypasses 12109 hits 739 misses Thanks so much for the response! Johannes From owner-freebsd-current@freebsd.org Fri Apr 22 08:08:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D695B1892D for ; Fri, 22 Apr 2016 08:08:39 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 248DC1E4D; Fri, 22 Apr 2016 08:08:37 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u3M88PUI044077 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2016 08:08:30 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: multipart/signed; boundary="Apple-Mail=_88835969-7560-4F92-BC56-0A666D4ABB7C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: David Chisnall In-Reply-To: <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> Date: Fri, 22 Apr 2016 09:08:19 +0100 Cc: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= , freebsd-current Message-Id: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> To: Dan Partelly X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 08:08:39 -0000 --Apple-Mail=_88835969-7560-4F92-BC56-0A666D4ABB7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 21 Apr 2016, at 21:48, Dan Partelly wrote: >=20 > Yes, you are right it misses the media change handler in devd.conf.=20= > maybe it should bementioned somewhere in a man page if it is not > already there. Thanks for the pointer. >=20 > Anyway, if I would have written the system, what I would have done > is to consolidate both user mode daemons into one and make this > daemon a client of devd, fstyp a library, and handle all removable=20 > media inside transparent to the user, without requiring any = modifications > to devd.conf, and without relaying on shell scripts.=20 >=20 > Is there any reason you did not took this approach ? This is not > criticism, I am genuinely interested. One of the current shortcomings of devd is that it does not provide a = good mechanism for other running processes to request notification of = events dynamically. Ideally, when the automounter daemon starts, it = should connect to devd via an IPC channel and request notification of = the specific events that it wants. This is a known problem (which = extends to more than just the automounter) and there are some tentative = plans to fix it, but they=E2=80=99re not yet concrete and won=E2=80=99t = be in 11.0, though hopefully will appear at some point in the 11.x = series. David --Apple-Mail=_88835969-7560-4F92-BC56-0A666D4ABB7C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD 04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5 UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5 bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0 aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X 7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4 aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71 OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50 IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1 Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm 7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8 wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDIyMDgwODIwWjAjBgkqhkiG9w0BCQQx FgQUY1ZI181o1B63vPEWGyARvvY5oLowgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G CSqGSIb3DQEBAQUABIIBAIj02YBKSLi4Jrlumcf+WxixLkhDIZYa3CMS/SaHK2ApUyVozOdFn21D oSVS2mKgbb/xcsP/0Gid31+tTtYkDcf7iNdgMEUHkZWtV+R8ZaLbplPAjkzW3AQOnzJc1hRH3JhW rH0dPzEziLHh/a6yT47duisPSVsbpheGjRtDhpwax5H9e3plTAdDt/F4l49453204PLzIdX8umsv 6QVRABuDcUkgCCFtNc9J6QOKCC47Kj1ouV5Ort9KlW7ExSZHLmKzajQ8OkpNTfoaEQXv8UdirAGH p8L1nliPSNXlU36cFACmhzKQuRdAypk+h0i5ErmnhE/Y63zmAhBtMyP6d8oAAAAAAAA= --Apple-Mail=_88835969-7560-4F92-BC56-0A666D4ABB7C-- From owner-freebsd-current@freebsd.org Fri Apr 22 08:26:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9619B170C1 for ; Fri, 22 Apr 2016 08:26:00 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE2E1AF8; Fri, 22 Apr 2016 08:26:00 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 106EADC10F; Fri, 22 Apr 2016 11:25:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Fri, 22 Apr 2016 11:26:00 +0300 From: dan_partelly To: David Chisnall Cc: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , freebsd-current Subject: Re: devd limitations -- was [CFT] packaging the base system with pkg(8) In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> Message-ID: <65fc57974095a9fc90ceeb8244f0c219@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 08:26:00 -0000 > Ideally, when the automounter daemon starts, it should > connect to devd via an IPC channel and request notification of the specific > events that it wants I was under the impression that devd.seqpacket.pipe accomplishes this. Am I right in assuming that the issue is that devd forwards ALL events to a client now, and the limitation is that we cannot specify a filter ? Or there is something else more deep and fundamental ? I am planning to use devd for a inhouse tool. >> though hopefully will appearat some point in the 11.x series. There are a lot of daemons IMO which would benefit from a tighter integration with devd, and abolishment of glue scripts or programs between devd and clients is desirable IMO. Fingers crossed. From owner-freebsd-current@freebsd.org Fri Apr 22 08:36:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A95B4B1762A for ; Fri, 22 Apr 2016 08:36:50 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 368C11FC0 for ; Fri, 22 Apr 2016 08:36:50 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id n3so2660737wmn.1 for ; Fri, 22 Apr 2016 01:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ng6bGGRa22pXnjiTVC/YEN4cnaEChKGBW/LQVxvA3Pg=; b=cKq2fVeJeFL4ZEX1sA3B6fnN4JwQQ8J2YoT1VUrfQdX4JYGS6ETXEqKuF992n7HL0g PYN4PzjxDSg1RKPcXHvRwYTdhlfM7dCo75r/QN5G/rI5WqbWV0iQuudoRw8aYRAgANu0 nMChHJIDWK4S+2KzuSxYS1LQRb1ZyW9wkf+1RQWf7cq5rSKJPAS+M99r89Ouczw0cs4/ ShpglS43Pt9mH8Vd5td0nbM949DdCh73W1v1dLf+Md1rX99wn3ylDCcXg+2kuMjnNh8/ /yfubHqBy+8m8e1Mwc1f/Dp9bhYF0kR0JEcrr6A3ZuOD8aG8iyWd+5zaYMW8Cm7SR+Q0 CJOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ng6bGGRa22pXnjiTVC/YEN4cnaEChKGBW/LQVxvA3Pg=; b=goUNkE6T5DOtt10eGIljw1w/Ar84TS2cy9KkZzbM1yT64LE41XQaMzuUU87PcHcUrH a5OKORXiacFYUUFdGH+tQKLy8Qf2FDhk3IULIOzQDAADQjN1F3EB4CCKTytMMiS1dDAG hZ9BIc69oMfL6lTEMaIfV6IRLBuQpk5mHJUlpWjV1bWfhdJkOkuuxZ5wxnlEAXFepMBr 7pL56mojRNG/jY7WDZdeM9HV/ZQ2EQ9eJ6L8TfbLRIb4+D76hRLg4iVN/zfSlbpVxkES im4KzVjXXu3QaYo8S1XRGHfJn45NW37yNoqzWxchGV3T5zS0qRFxuyoYzEYdfYcIPJ/h 6bUw== X-Gm-Message-State: AOPr4FUfCiDaaAfnCNwDM/1wbG9HKrZVW0bOGbcxTNcsW8JO+d7O5WH6oKY7p2RS6t34Rg== X-Received: by 10.28.127.80 with SMTP id a77mr2513236wmd.84.1461314207980; Fri, 22 Apr 2016 01:36:47 -0700 (PDT) Received: from brick (esr141.neoplus.adsl.tpnet.pl. [83.20.137.141]) by smtp.gmail.com with ESMTPSA id w2sm6907475wjg.42.2016.04.22.01.36.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Apr 2016 01:36:46 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 22 Apr 2016 10:36:43 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Dan Partelly Cc: freebsd-current Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160422083643.GA1479@brick> Mail-Followup-To: Dan Partelly , freebsd-current References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 08:36:50 -0000 On 0421T2348, Dan Partelly wrote: > Yes, you are right it misses the media change handler in devd.conf. > maybe it should bementioned somewhere in a man page if it is not > already there. Thanks for the pointer. It's mentioned in a comment in auto_master file. But yeah, mentioning it in a manual page seems like a good idea. > Anyway, if I would have written the system, what I would have done > is to consolidate both user mode daemons into one and make this > daemon a client of devd, fstyp a library, and handle all removable > media inside transparent to the user, without requiring any modifications > to devd.conf, and without relaying on shell scripts. > > Is there any reason you did not took this approach ? This is not > criticism, I am genuinely interested. Yes - I actually like shell scripts. I like being able to provide the glue in a way that's easy to debug and modify, without having to rebuild anything, so that it can be tailored to specific needs by the system administrator. In this case the problem, I think, is not with the shell scripting. It's just that it doesn't "enable itself" when needed, or isn't just enabled by default. > > and simply > > retrofit the changes back to autofs - but that hasn't happened (yet). > > Please consider doing it. A kevent on /media would allow other programs > to see how volumes come and go, and I can imagine several situations > where this can be handy. And too many directories left there do become > annoying. Well, you have devd notifications for this - and it gives you much more flexibility. > > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała wrote: > > > > On 0421T1526, Dan Partelly wrote: > >> The scenario is: > >> > >> Let’s say I have autofs_enable , working with media map. > >> > >> If I have a CD in CD drive , all is well and when the system is fully booted up > >> /media contains a directory through which I can access the content of the > >> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. > >> /media does not contain a new access point for the new disk inserted in the > >> device. > >> > >> What I would expect is when I change the media in Cd-rom , a new > >> access point for the volume in question should be reated in /media. > >> > >> Perhaps this functionality is exposed differently by the automounter, > >> but them I would not expect the CDrom to be accessible at all though the > >> media map. > > > > If by "access point" you mean the directory, then it will, unless the CD > > doesn't have a label - in that case the device name will be used instead, > > and since it's the same device, it will be the same name - usually "cd0". > > > > However - I've just checked to make sure and it works the way it should. > > What you're decribing seems like you're missing the part of devd.conf(5) > > responsible for notifying autofs about media change. Do you? > > > >>> he problem here is that it's quite hard to fix, there's a risk > >>> of breaking existing functionality, and the problem is largely cosmetic. > >> > >> until you have more than 10 of them there, when it largely annoying. > >> anyway, what is the reason it is very hard to fix and it would break existing > >> functionality. can you please shed some light ? > > > > Basically, the autofs doesn't support removing the nodes. It wasn't > > really required for the usual use case, and it simplified the code a lot. > > Plan was to pick it up again with my next filesystem project, and simply > > retrofit the changes back to autofs - but that hasn't happened (yet). > > > > [..] > From owner-freebsd-current@freebsd.org Fri Apr 22 08:41:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8508CB1796A for ; Fri, 22 Apr 2016 08:41:15 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 2943013BE; Fri, 22 Apr 2016 08:41:15 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id e201so2359855wme.2; Fri, 22 Apr 2016 01:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=9POzQtFUMM0+r6uRexiZeQSjtzFbTrOOgC5yvzfMxX0=; b=MoSnYQxZEy05zj2+ma3UHHF82d4hfSjCKfpZRbeqODIJHMLWZZDMSVqProPeEpdFyd hbPRJWfSxiOOZeS9Ozo7OaiESEarCv4NYtinJ4NEXhQg85tyEZdJNln3XB06LsnttDiG LsfAAbBaX1SPV/YeGKYzUAos74nJmua6DmNwXsbg1lth7WSTNPIoqx//zfLPu+2Eyex+ dForNnIw8oI5GTXGv40L5koYz56qa6lTjEfKZV+zXXqSb7eElwzzp42O687bXv169Ly/ 10fPapKFX+/VECtuX4ekoAtr2Wqb6ACgq5YYXC1tWi8XM3FXYFmchF+Vd/yvFgUprqcp LcRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=9POzQtFUMM0+r6uRexiZeQSjtzFbTrOOgC5yvzfMxX0=; b=StC3FLXNwAGAeltPrP+cx3NPvG+pZn58ZDg4n/UchmB8f47Qsp1HBKGbT6GHCmjDwS 1v9YFq6Hp8tZG2kIlewv3tQgQj16eCJ37N+xJgHKaA/iunWQ0tGPgwIsMq5nPKh2grpQ J7J5cxJIS+HSkzu1LJZ42oLHUDtmDbLLFr3jY2wQZWopQF+/u3xYbv8u7IRbSTjI9YU6 xUnfOfy+aMsKusA4PDCK5BLI2xF3IV1bo01Iy6SFKTNNP1QSTH1DIPmTiQKMHG+ZUu4V +dKZtavoLt6tnBMuaufhH26zNCJLG/FBTvY2n0xVFHDOitxwCGSEyODbbyqnScwSGg1B Jhaw== X-Gm-Message-State: AOPr4FUm1mm1/KQqmABb00TDZVXQG8/zWgpa11xZ0KIx9cg/L65BliKGpQKNafhvX5/P2w== X-Received: by 10.194.116.9 with SMTP id js9mr22012643wjb.112.1461314473853; Fri, 22 Apr 2016 01:41:13 -0700 (PDT) Received: from brick (esr141.neoplus.adsl.tpnet.pl. [83.20.137.141]) by smtp.gmail.com with ESMTPSA id i194sm2192582wmf.6.2016.04.22.01.41.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Apr 2016 01:41:13 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 22 Apr 2016 10:41:09 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: David Chisnall Cc: Dan Partelly , freebsd-current Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160422084109.GB1479@brick> Mail-Followup-To: David Chisnall , Dan Partelly , freebsd-current References: <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 08:41:15 -0000 On 0422T0908, David Chisnall wrote: > On 21 Apr 2016, at 21:48, Dan Partelly wrote: > > > > Yes, you are right it misses the media change handler in devd.conf. > > maybe it should bementioned somewhere in a man page if it is not > > already there. Thanks for the pointer. > > > > Anyway, if I would have written the system, what I would have done > > is to consolidate both user mode daemons into one and make this > > daemon a client of devd, fstyp a library, and handle all removable > > media inside transparent to the user, without requiring any modifications > > to devd.conf, and without relaying on shell scripts. > > > > Is there any reason you did not took this approach ? This is not > > criticism, I am genuinely interested. > > One of the current shortcomings of devd is that it does not provide a good mechanism for other running processes to request notification of events dynamically. Ideally, when the automounter daemon starts, it should connect to devd via an IPC channel and request notification of the specific events that it wants. This is a known problem (which extends to more than just the automounter) and there are some tentative plans to fix it, but they’re not yet concrete and won’t be in 11.0, though hopefully will appear at some point in the 11.x series. Well, even if we went this route, this wouldn't quite work, because the automountd daemon actually doesn't need those notifications. It's the "-media" map that does. Other parts of autofs don't have any special code for media handling. From owner-freebsd-current@freebsd.org Fri Apr 22 09:04:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30CDCB1875D for ; Fri, 22 Apr 2016 09:04:14 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id BC3751237; Fri, 22 Apr 2016 09:04:13 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 43A17DC0CD; Fri, 22 Apr 2016 12:04:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Fri, 22 Apr 2016 12:04:20 +0300 From: dan_partelly To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Cc: David Chisnall , freebsd-current Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <20160422084109.GB1479@brick> References: <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> <20160422084109.GB1479@brick> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 09:04:14 -0000 This is one of the issue I perceive with using scripts/ intermediate programs as a glue, a problem which does not exist when the daemons are integrated tighter. You basically give up all the power which arises from inter-operating daemons give to the system. It is also the main problem FreeBSD's rc system presents. Because all is a scaffolding of shell scripts, it basically gives you 0 of the power modern service management offer. Most important are service life cycle management, restart policies, delegated administration and fault reporting. The only thing you gain is easy debugability (no small boon)but it is easily outweighted by all other advantages of a modern service manager. > > Well, even if we went this route, this wouldn't quite work, because > the automountd daemon actually doesn't need those notifications. > It's the "-media" map that does. Other parts of autofs don't have > any special code for media handling. About shell scripts in general as a glue: Yes, they are easily debuggable and customized. Yet I believe that all that power should be hidden,and it should be unnecessary to tap into it for 95% of administrative needs. It is my perception that less and less people are interested in exploring the countless ranges of customization such scaffolding of scripts offer. People are interested in sane defaults, easy to specify policies and fault reporting. Life is too short to explore myriad of customizations, unless you really have to. And most of the time, you dont need to. Thats not to say shell scripts dont have their place. They do. I use them too, both on unixes and tcl scripts for adding fast functionality in csico devices. But as a glue between essential operating system subsystems, it is my oppinion that we are 10 years too late in replacing them. From owner-freebsd-current@freebsd.org Fri Apr 22 12:41:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F28FEB19E84; Fri, 22 Apr 2016 12:41:09 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 196F01527; Fri, 22 Apr 2016 12:41:08 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [193.68.6.100] ([193.68.6.100]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.9/8.14.9) with ESMTP id u3MCFqsw067866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2016 15:15:53 +0300 (EEST) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Daniel Kalchev In-Reply-To: <201604190210.u3J2AHef003299@xt.digsys.bg> Date: Fri, 22 Apr 2016 15:15:52 +0300 Cc: Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <68F587ED-6755-4E40-88B0-E90EAA79B0A4@digsys.bg> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190210.u3J2AHef003299@xt.digsys.bg> To: Roger Marquis X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:41:10 -0000 > On 19.04.2016 =D0=B3., at 5:01, Roger Marquis = wrote: >=20 > Honestly, some of us are wondering what exactly is > behind some of these concerns regarding base packages. >=20 Not taking a side on this discussion, yet=E2=80=A6 but the first thing = that occurred to me is that such way of packaging is traditional for the = Linux =E2=80=9Cdistributions=E2=80=9D. I could imagine people worrying = at subconscious level that FreeBSD is going the Linux way=E2=80=A6 and = that if they wanted such a model, they would be using Linux instead. = Today, people have more choice in packaging =E2=80=94 but if FreeBSD = goes the Linux way, someone else will fill the void =E2=80=94 so no = worries in general. I can see the support nightmare that a packaged base would bring, but as = always =E2=80=94 this is not enough to judge it. The benefits might be = worth it in the long run. I was a long time user of BSD/OS and then switched to FreeBSD when that = OS was killed. In BSD/OS everything was monolithic. It was rock stable. = Very dependable and very easy to support. My first few years with = FreeBSD were spent to get used that the OS was not just one piece, but = you could end up with different installs.. A bit more support efforts. = Not that I am complaining :) As long as packaged base is not mandatory, it is fine by me. Daniel= From owner-freebsd-current@freebsd.org Fri Apr 22 13:22:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0964B17065 for ; Fri, 22 Apr 2016 13:22:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CD51212A5 for ; Fri, 22 Apr 2016 13:22:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id CCA5CB17064; Fri, 22 Apr 2016 13:22:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC495B17063 for ; Fri, 22 Apr 2016 13:22:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65C4E12A0 for ; Fri, 22 Apr 2016 13:22:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1atb24-0003dP-4X for current@freebsd.org; Fri, 22 Apr 2016 15:22:04 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1atb24-0000qj-4G for current@freebsd.org; Fri, 22 Apr 2016 15:22:04 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Fri, 22 Apr 2016 13:22:04 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: new content: [ buildworld fixed ] now network drops out daily Date: Fri, 22 Apr 2016 06:22:04 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:22:14 -0000 ----- Start Forwarded Message ----- Sent: Thu, 21 Apr 2016 14:10:40 -0700 (PDT) From: "Jeffrey Bouquet" To: "current" Subject: Re: Re: Installworld, BW, IK fixed, here are the in > out loader.conf lines On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 >=20 > On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 > >=20 > >=20 > > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" wrote: > >=20 > > >=20 > > >=20 > > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude wrote: > > >=20 > > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > > > unistd > > > > >=20 > > > > >=20 > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected = function body after function declarator > > > > > int execl( ................................. > > > > > 332:46:= =20=20=20=20 > > > > > same... > > > > >=20 > > > > > stops libc > > > > > otherwise clang36 seems to be building so far, if it builds unsur= e about installworld > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" > > > > >=20 > > > >=20 > > > > The mailing list strips attachments. Can you upload it somewhere and > > > > provide a link > > > >=20 > > > > --=20 > > > > Allan Jude > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" > > >=20 > > >=20 > > > Well, it is now r298350 Wed Apr 20... > > > However several problems > > >=20 > > > SINGLE-USER BOOT PROBLEMS > > > 1... usual boot fails, this is single-user adjusted, but I cannot add= swap (swapon? swapctl?) > > > 1a... the last time, it was fixed with using the old /kernel ...=20 > > >=20 > > > multi-user boot problems > > >=20 > > > 2... the last usual boot dumped with vm_pager or something, verbose = boot times out with xpt_config not completing. > > > 2a.... could be a wrong setting is loader.conf, the nvidia.ko not yet= updated (which it now is ) for the latter > > > case I have yet to reboot to test > > > 2b... Reboot to test takes longer, /rescue/mount each filesystem = individually...=20 > > >=20 > > >=20 > > > As one might surmise, I'd rather see buildworld made more foolproof t= han other recent improvements=20 > > > (pkg, zfs, ...) > >=20 > > From backup, I have r288246 kernel and nvidia.ko (v11) > > from source, I have world and all except those TWO files at r298350 )(v= 11), nvidia (newer) won't load with older kernel > > A few at-boot scripts no longer work as expected... but no other major = problems (swap is present again) > > (multi-user boot works)=20 > >=20 > > Best practice maybe to update the kernel? It is a custom one from way = back in 2004 initially > > without sound drivers and without debug symbols... and many esoteric l= ines added which I cobbled > > together at first then changed per diffs of GENERIC over the years... > >=20 > > Thanks for any known methods > >=20 > > J. Bouquet > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 >=20 > Updated to a slightly-less-than-full GENERIC. Still dumped core. Moved = loader.conf out of > the way, works fine. What will take some time now is moving loader.conf = back piece by piece > [until/if there is/ever was a utility to do it for us... ] to find the pr= oblematic line or two, then > resume testing of the install of the custom kernel that also is 'fail' st= atus at this point... unless/until > I decide to also test it, THEN resume the loader.conf line-by-line back i= n... >=20 > tl;dr loader.conf problematic line and maybe an additional unknown in e= ither kernel text file. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Half of loader.conf removed. (as below). Custom kernel restored and working. # out snd_pcm_load=3D"YES" # out snd_acm_load=3D"YES" # out kern.msgbufsize=3D"130000" # out kern.ipc.shmmni=3D"1024" # out kern.ipc.shmseg=3D"1024" # out hw.snd.maxautovchans=3D"4" # out hw.snd.targetirqrate=3D"36"=20=20=20=20 # out hint.pcm.0.buffersize=3D"65536"=20 # out hw.snd.verbose=3D"3" # out kern.ipc.semmns=3D"240" # out kern.ipc.semume=3D"40" # out kern.ipc.semmnu=3D"120" # out vfs.read_max=3D"128"=20=20=20=20 # out kern.randompid=3D"1" # out kern.ipc.shmmax=3D"67108864"=20 # out kern.ipc.shmall=3D"32768" # out vm.kmem_size=3D"700M"=20=20=20=20 # out vm.kmem_size_max=3D"700M"=20=20 # out vfs.zfs.arc_max=3D"250M" # out kern.sched.preempt_thresh=3D"224" # out vfs.usermount=3D"1"=20=20=20 # out kern.geom.part.check_integrity=3D"0"=20=20 # out vm.overcommit=3D"1" # out kern.maxfilesperproc=3D"65536" # out kern.ipc.somaxconn=3D"1024" # out kern.ipc.nmbclusters=3D"81920" # out kern.fallback_elf_brand=3D"3" # out vfs.write_behind=3D"0" Quite a lot, as one may see. There is an equal amount non-kern (net...) rem= aining in. Perchance someone sees an obvious problem in a value, and/or is an expert i= n=20 most of them and knows which can be safely restored for furtther testing, a= nd/or which are most useful in a FreeBSD system. Thanks. OTOH this may help others if they also encounter the same problem, and coul= d be included in a future wiki or UPDATING or 'man sysctl' type file somewhere... _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" ----- End Forwarded Message ----- the network nfe0 seems to disappear requiring a reboot. "service netif res= tart" does not help nor the ifconfig manually. Is there maybe an MTU or ifconfig variable that would fix it; of one of the= sysctls I removed above, or is it similar to the "shaky network stability" very recent thread= ?=20=20=20=20=20 From owner-freebsd-current@freebsd.org Fri Apr 22 13:46:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DF68B17980; Fri, 22 Apr 2016 13:46:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 222CB11AF; Fri, 22 Apr 2016 13:46:00 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 4DB271F159; Fri, 22 Apr 2016 16:45:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Fri, 22 Apr 2016 16:46:10 +0300 From: dan_partelly To: Daniel Kalchev Cc: Roger Marquis , Lyndon Nerenberg , , Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <68F587ED-6755-4E40-88B0-E90EAA79B0A4@digsys.bg> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190210.u3J2AHef003299@xt.digsys.bg> <68F587ED-6755-4E40-88B0-E90EAA79B0A4@digsys.bg> Message-ID: <2fd7eba2f22590befb95825e16de13b9@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:46:01 -0000 > > Not taking a side on this discussion, yet… but the first thing that I do not believe there are sides to take, because I am absolutely positive everybody in this thread wants only whats better for FreeBSD, so there is only one side. It is an aspect which in the heat of emotions some people seem to forget. >> The benefits might be worth it in the long run. The benefits are great and they are immediately available upon release of a packaged base. I am all for it . Yet there issue, such as the UI which doesn't handle well big numbers of packages, mechanism issues and convention issues which where raised in another thread and went unanswered by devs so far. Personally my greatest fear is that what happen to VIMAGE wouldn't happen with this great feature. Namely, that it goes in effect with a "good enough" implementation (which may well be a great success for some uses) and then we have to work with the "good enough" implementation for half a decade before it is made bullet proof and orthogonal. Or that UI issues are never solved, claiming that they are "largely cosmetic" anyway. I wouldn't mind waiting 2 point releases for example to become that way, but look, for VIMAGE takes what ... 6 years ? (Nota bene: I do not contest that VIMAGE is great. ) Pople raised valid concerns, devs imvolved in the project seen them, yet those who spearhead the base pkg project did not found appropriate to make a statement to quell ppl fears regarding their commitment to see to all the issues in a pre-determined time frame. I.E a commitment to make it bullet proof by 11.1 as example. Some felt threatened and unappreciated, which is a problem. Both for them and for us, the user. Because the users of this OS are not only the companies who employ the developers, there are thousand of people scattered through the world, ppl who have a great stake invested in this operating system, by the simple fact that they use it everywhere. Another small issue, is in general the politics of the FreeBSD dev team regarding bug fixes. I personally would be glad to see more commitment from the dev team regarding bug fixes. It is kinda disappointing to see known bugs going on and on for years, "good enough" susbsytems having the same fate, and so on. I beleive the team per-ansamble should make a more solid commitment to fix outstanding issues, and try to outline a policy regarding bugs and implementations which lack orthogonality or are only partially completed (even if this partially means 95% ). > occurred to me is that such way of packaging is traditional for the Linux > “distributions”. I could imagine people worrying at subconscious level that > FreeBSD is going the Linux way… and that if they wanted such a model, they > would be using Linux instead. Today, people have more choice in packaging — > but if FreeBSD goes the Linux way, someone else will fill the void — so no > worries in general. > > I can see the support nightmare that a packaged base would bring, but as > always — this is not enough to judge it. The benefits might be worth it in > the long run. > > I was a long time user of BSD/OS and then switched to FreeBSD when that OS > was killed. In BSD/OS everything was monolithic. It was rock stable. Very > dependable and very easy to support. My first few years with FreeBSD were > spent to get used that the OS was not just one piece, but you could end up > with different installs.. A bit more support efforts. Not that I am > complaining :) > > As long as packaged base is not mandatory, it is fine by me. > > Daniel > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Apr 22 13:59:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0ADCB17EF1 for ; Fri, 22 Apr 2016 13:59:16 +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 D47E21A4D for ; Fri, 22 Apr 2016 13:59:16 +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 u3MDhOlG090594 for ; Fri, 22 Apr 2016 06:43:30 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <76093.1461096570@critter.freebsd.dk> References: , <76093.1461096570@critter.freebsd.dk> From: "Chris H" Subject: Re: [CFT] packaging the base system with pkg(8) Date: Fri, 22 Apr 2016 06:43:30 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <1a545b54f814503fa62c70b3961a3678@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:59:17 -0000 On Tue, 19 Apr 2016 20:09:30 +0000 "Poul-Henning Kamp" wrote > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. Ahem... *always*? ;-) While I *do* have some opinions on the upcoming pkg-base, as well as the pkg system, itself. I'm playing catch-up with my INBOX. So I will only respond to your remark; I don't ever recall having been asked whether a package system should be implemented, and if so, how it should look. *Prior* to it's having been implemented. Tho it may have come up in the IRC channels. It never reached the mailing lists. *This* is the reason that *this* and similar topics become so heated; People who are part of a "community", such as FreeBSD. Want to feel they are part of the "big picture", and immediately feel resentment, when they find they were left out of "big" decisions, like pkg(8). While the conversation may well have been heated. It would *not* have meet *quite* as much adamant, persistent resistance. Because it (pkg) would have been molded into something from the culmination of the "community'" input. This is only from 50 years in the service industry, and the thousands of mailing lists I've been on, talking here. --Chris > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Apr 22 14:27:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BE3FB18C09 for ; Fri, 22 Apr 2016 14:27:28 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id E94441A64 for ; Fri, 22 Apr 2016 14:27:27 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 09B40232EB; Fri, 22 Apr 2016 17:27:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Fri, 22 Apr 2016 17:27:37 +0300 From: dan_partelly To: Chris H , Cc: Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <1a545b54f814503fa62c70b3961a3678@ultimatedns.net> References: , <76093.1461096570@critter.freebsd.dk> <1a545b54f814503fa62c70b3961a3678@ultimatedns.net> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 14:27:28 -0000 It's lack of communication. > *This* is the reason that *this* and similar topics become so heated; > People who are part of a "community", such as FreeBSD. Want to feel > they are part of the "big picture", and immediately feel resentment, It is in fact much more than that. Surely there are such psycho-social effects as you describe, after all we humans are subject to hundred os socio-psycological biases. But there is a much more practical and mundane issue as well: People who use this operating system in their operations have a great stake in it. Such changes affect operations. I welcome change, but at the same time I try to ensure that change goes smoothly. Investing in BSDs by using them in our operation is not a whim, or a decision made drunk under a bridge. It costs us money, time , investment in educating other people to administer those OSEs, continuous education to keep up with change. More than all this, it costs us business reputation when we decide to build an infrastructure for a client on BSDs, and something goes wrong. And I want to keep my customers happy and so far the BSDs delivered this. > when they find they were left out of "big" decisions, like pkg(8). IMO, Its not a problem to be left out of decisions. First, because they are not our decisions to take, and second because I believe decisions are better to be made by small group of persons. What is a problem is the fact that when you discuss those projects and voice your opinions, some label you "anti progress", some " peasant storming a (lord's) castle (with or without a pitchfork,cant remember :P) , others feel that you dont appreciate them and their time, and then they retreat somewhere. You can invalidate the decision made by said group by stoping using the product. Im sure none would care in the unlikely even that I would stop using FreeBSD, but I think they cared when Yahoo stopped using it. Or if they did not, they should have cared :P > People who are part of a "community", such as FreeBSD. Want to feel > they are part of the "big picture", and immediately feel resentment, > when they find they were left out of "big" decisions, like pkg(8). > While the conversation may well have been heated. It would *not* > have meet *quite* as much adamant, persistent resistance. Because > it (pkg) would have been molded into something from the culmination > of the "community'" input. > > This is only from 50 years in the service industry, and the > thousands of mailing lists I've been on, talking here. > > --Chris > >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk@FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by >> incompetence. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Apr 22 14:30:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 539F0B18DB5 for ; Fri, 22 Apr 2016 14:30:33 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD361C13 for ; Fri, 22 Apr 2016 14:30:33 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3B4DCB18DB4; Fri, 22 Apr 2016 14:30:33 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AF29B18DB3 for ; Fri, 22 Apr 2016 14:30:33 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA0F81C11 for ; Fri, 22 Apr 2016 14:30:32 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1atc6H-0005OX-Nu; Fri, 22 Apr 2016 16:30:29 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1atc6H-00028i-Ne; Fri, 22 Apr 2016 16:30:29 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Fri, 22 Apr 2016 14:30:29 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "jbtakk" CC: "current" Subject: Re: new content: [ buildworld fixed ] now network drops out daily Date: Fri, 22 Apr 2016 07:30:29 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 14:30:33 -0000 On Fri, 22 Apr 2016 06:22:04 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 >=20 > ----- Start Forwarded Message ----- > Sent: Thu, 21 Apr 2016 14:10:40 -0700 (PDT) > From: "Jeffrey Bouquet" > To: "current" > Subject: Re: Re: Installworld, BW, IK fixed, here are the in > out > loader.conf lines >=20 >=20 >=20 > On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" wrote: >=20 > >=20 > >=20 > > On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" wrote: > >=20 > > >=20 > > >=20 > > > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" wrote: > > >=20 > > > >=20 > > > >=20 > > > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude wrote: > > > >=20 > > > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > > > > unistd > > > > > >=20 > > > > > >=20 > > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expecte= d function body after function declarator > > > > > > int execl( ................................. > > > > > > 332:46= :=20=20=20=20 > > > > > > same... > > > > > >=20 > > > > > > stops libc > > > > > > otherwise clang36 seems to be building so far, if it builds uns= ure about installworld > > > > > > _______________________________________________ > > > > > > freebsd-current@freebsd.org mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@f= reebsd.org" > > > > > >=20 > > > > >=20 > > > > > The mailing list strips attachments. Can you upload it somewhere = and > > > > > provide a link > > > > >=20 > > > > > --=20 > > > > > Allan Jude > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" > > > >=20 > > > >=20 > > > > Well, it is now r298350 Wed Apr 20... > > > > However several problems > > > >=20 > > > > SINGLE-USER BOOT PROBLEMS > > > > 1... usual boot fails, this is single-user adjusted, but I cannot a= dd swap (swapon? swapctl?) > > > > 1a... the last time, it was fixed with using the old /kernel ...=20 > > > >=20 > > > > multi-user boot problems > > > >=20 > > > > 2... the last usual boot dumped with vm_pager or something, verbos= e boot times out with xpt_config not completing. > > > > 2a.... could be a wrong setting is loader.conf, the nvidia.ko not y= et updated (which it now is ) for the latter > > > > case I have yet to reboot to test > > > > 2b... Reboot to test takes longer, /rescue/mount each filesyste= m individually...=20 > > > >=20 > > > >=20 > > > > As one might surmise, I'd rather see buildworld made more foolproof= than other recent improvements=20 > > > > (pkg, zfs, ...) > > >=20 > > > From backup, I have r288246 kernel and nvidia.ko (v11) > > > from source, I have world and all except those TWO files at r298350 )= (v11), nvidia (newer) won't load with older kernel > > > A few at-boot scripts no longer work as expected... but no other majo= r problems (swap is present again) > > > (multi-user boot works)=20 > > >=20 > > > Best practice maybe to update the kernel? It is a custom one from wa= y back in 2004 initially > > > without sound drivers and without debug symbols... and many esoteric= lines added which I cobbled > > > together at first then changed per diffs of GENERIC over the years... > > >=20 > > > Thanks for any known methods > > >=20 > > > J. Bouquet > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" > >=20 > >=20 > > Updated to a slightly-less-than-full GENERIC. Still dumped core. Move= d loader.conf out of > > the way, works fine. What will take some time now is moving loader.con= f back piece by piece > > [until/if there is/ever was a utility to do it for us... ] to find the = problematic line or two, then > > resume testing of the install of the custom kernel that also is 'fail' = status at this point... unless/until > > I decide to also test it, THEN resume the loader.conf line-by-line back= in... > >=20 > > tl;dr loader.conf problematic line and maybe an additional unknown in= either kernel text file. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 >=20 > Half of loader.conf removed. (as below). Custom kernel restored and worki= ng. > # out snd_pcm_load=3D"YES" > # out snd_acm_load=3D"YES" > # out kern.msgbufsize=3D"130000" > # out kern.ipc.shmmni=3D"1024" > # out kern.ipc.shmseg=3D"1024" > # out hw.snd.maxautovchans=3D"4" > # out hw.snd.targetirqrate=3D"36"=20=20=20=20 > # out hint.pcm.0.buffersize=3D"65536"=20 > # out hw.snd.verbose=3D"3" > # out kern.ipc.semmns=3D"240" > # out kern.ipc.semume=3D"40" > # out kern.ipc.semmnu=3D"120" > # out vfs.read_max=3D"128"=20=20=20=20 > # out kern.randompid=3D"1" > # out kern.ipc.shmmax=3D"67108864"=20 > # out kern.ipc.shmall=3D"32768" > # out vm.kmem_size=3D"700M"=20=20=20=20 > # out vm.kmem_size_max=3D"700M"=20=20 > # out vfs.zfs.arc_max=3D"250M" > # out kern.sched.preempt_thresh=3D"224" > # out vfs.usermount=3D"1"=20=20=20 > # out kern.geom.part.check_integrity=3D"0"=20=20 > # out vm.overcommit=3D"1" > # out kern.maxfilesperproc=3D"65536" > # out kern.ipc.somaxconn=3D"1024" > # out kern.ipc.nmbclusters=3D"81920" > # out kern.fallback_elf_brand=3D"3" > # out vfs.write_behind=3D"0" >=20 > Quite a lot, as one may see. There is an equal amount non-kern (net...) r= emaining in. > Perchance someone sees an obvious problem in a value, and/or is an expert= in=20 > most of them and knows which can be safely restored for furtther testing,= and/or > which are most useful in a FreeBSD system. >=20 > Thanks. > OTOH this may help others if they also encounter the same problem, and co= uld be > included in a future wiki or UPDATING or 'man sysctl' type file somewhere= ... >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >=20 >=20 >=20 > ----- End Forwarded Message ----- >=20 > the network nfe0 seems to disappear requiring a reboot. "service netif r= estart" does not > help nor the ifconfig manually. > Is there maybe an MTU or ifconfig variable that would fix it; of one of t= he sysctls I removed > above, or is it similar to the "shaky network stability" very recent thre= ad?=20=20=20=20=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Don't wish to appear to be spamming the list, but I've learned some things = about the sysctls above [ beta ] that may be useful to others. I decided to set them after boot... ...........................................................................= .............. approx. 7 are loader.conf only approx. 15 have no problem so far, and are loaded via CLI as of now kern.randompid=3D"1" gives a result of 0 > 0 [ maybe does not work after b= oot? or a bug ] ...........................................................................= ............... three are unknown and may have been the main installkernel problem, unsure = [unless typos...] vfs.zfs.arc_max hw.snd.targetirqrate [ though it may only appear after and _load that wa= s removed ] hint.pcm.0.buffersize [ditto] ...........................................................................= ................ This is all hastily typed, so pardon misspellings... If nfe0 stays up until shutdown within an hour or two, that would be [maybe= ] a good sign... for those sysctls anyway. OTOH I am now *not* loading ten or so other sysctls = right at bringing the network up, so a lot of testing would be due here ... So progress at least.=20=20= From owner-freebsd-current@freebsd.org Fri Apr 22 15:28:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F749B19F45 for ; Fri, 22 Apr 2016 15:28:19 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7764B1CD7 for ; Fri, 22 Apr 2016 15:28:19 +0000 (UTC) (envelope-from marquis@roble.com) Date: Fri, 22 Apr 2016 08:28:13 -0700 (PDT) From: Roger Marquis To: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 15:28:19 -0000 Julian Elischer wrote: > I mentioned this before but I think hte answer is to make a change on > the way that "meta packages" are displayed by default in pkg. I like this suggestion both as it applies to base and third party packages and agree that the 'leaf' keyword, once documented, will address the use case fairly well. > If I install the meta package, I really don't want to see all the sub > packages tat are unchanged unless I add '-v'. On the other hand if I > upgrade a sub package I want to see that in the context of the > metapackage. Similarly if I uninstall of the subpackages. Personally I think the behavior of pkg should remain as it now to avoid breaking existing scripts and aliases i.e., base packages would not be shown without specifying a new flag, say '-b'. This base flag could similarly display only base packages and also recognize the leaf concept. Presumably there should also be a flag to display both third party and base packages, especially with the audit flag, but that could be implemented at a future date without significantly reducing the utility of base packages in 11-RELEASE. Roger From owner-freebsd-current@freebsd.org Fri Apr 22 16:06:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3783B1912F; Fri, 22 Apr 2016 16:06:46 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::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 99F0E1384; Fri, 22 Apr 2016 16:06:46 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-io0-x242.google.com with SMTP id x35so3871070ioi.0; Fri, 22 Apr 2016 09:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=7drCFtCT4jvRxZ+EXBdVKjKvbms0zcvwZJhY83NTQ24=; b=LpLaulff6caOiLpO4DwjVq4juvm+0JC8OOmXvrlfwe1Nr+7s66nVKRB1qvag58w5dd WuQcd8HoZYd4ze3lslwIMxnG3/2k4emH2U917Uo7rNtISJKMgJbIw0fqdv2IYRPVazfV p+PWIegq/64w3YObo/jzHJM385i94IgMwMuUI2/rzSIzbur5aYNqDoFhsT/rgsm/XG1L xsXzTH0+OtpSePnBR/qjSzRB1N82ZrGIngpTvJO3N4fFWoOBwoXN31eD6EmtBdObDw8N Kvi2XnT+/ety92pWzEKl0p7inD//fZ2XgcaUSd2Y4MN/fPgM8l+S04lYx5/8Gu16ojRU pmQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=7drCFtCT4jvRxZ+EXBdVKjKvbms0zcvwZJhY83NTQ24=; b=UXu0swfvsowD9VTCV+TtpixUryseeOJH3KmyDaibMvAZMmNTF1jdYKrflS3q5Ow+U+ ZfNB94QjtItVQs/kLM0AJGQAS3k5hmYXnzZpTXMI8Ir5lFLC4DVa0V1qSWU1hzqPfgYh W7lFhoET0ICq6xKJtFyFLaZEJQaZAXqgUcq0esdPqPwCJKvf7HrTgtnMUTChXVFAf4JL h9oCOq6wp28FXANnTmt5b5IHRs4EikN2gMUOZRhRDFluAhJCxY5smLZ8+GKKjThlZiK1 NhEWH/woR5KidVc6yFuZqA3PKsbS6P5KjDPa0giiy9R1h8sCvmO3dU6sxYCcnRuVM2gC miRw== X-Gm-Message-State: AOPr4FVk/PtDWTMjZWheO1BFA27uG4azRsaNlO0r3H10rwvvwPYp468E1qjLEcyfNPuyyA== X-Received: by 10.107.131.12 with SMTP id f12mr24805569iod.126.1461341205950; Fri, 22 Apr 2016 09:06:45 -0700 (PDT) Received: from [10.0.10.3] (cpe-184-56-210-236.neo.res.rr.com. [184.56.210.236]) by smtp.googlemail.com with ESMTPSA id q9sm1876488igr.7.2016.04.22.09.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 09:06:45 -0700 (PDT) Message-ID: <571A4C20.3050409@gmail.com> Date: Fri, 22 Apr 2016 12:06:56 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Daniel Kalchev CC: Roger Marquis , Lyndon Nerenberg , freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190210.u3J2AHef003299@xt.digsys.bg> <68F587ED-6755-4E40-88B0-E90EAA79B0A4@digsys.bg> In-Reply-To: <68F587ED-6755-4E40-88B0-E90EAA79B0A4@digsys.bg> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 16:06:46 -0000 > As long as packaged base is not mandatory, it is fine by me. > +1 on that From owner-freebsd-current@freebsd.org Fri Apr 22 16:25:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1581AB19886 for ; Fri, 22 Apr 2016 16:25:16 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEC581285 for ; Fri, 22 Apr 2016 16:25:15 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1atdtN-0001mA-G8; Fri, 22 Apr 2016 18:25:17 +0200 Date: Fri, 22 Apr 2016 18:25:17 +0200 From: Kurt Jaeger To: dan_partelly Cc: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160422162517.GR2282@home.opsec.eu> References: <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> <571588BB.2070803@orthanc.ca> <201604190210.u3J2AHef003299@xt.digsys.bg> <68F587ED-6755-4E40-88B0-E90EAA79B0A4@digsys.bg> <2fd7eba2f22590befb95825e16de13b9@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fd7eba2f22590befb95825e16de13b9@rdsor.ro> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 16:25:16 -0000 Hi! dan wrote: > Another small issue, is in general the politics of the FreeBSD dev team > regarding bug fixes. I personally would be glad to see more commitment from > the dev team regarding bug fixes. >From what I can see, there's not much politics, but serious work overload, and not much room for more commitment. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Fri Apr 22 18:33:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49E05B187E8 for ; Fri, 22 Apr 2016 18:33:43 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 05A0F1DF7 for ; Fri, 22 Apr 2016 18:33:42 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=UgTsf0czZ2L7MkAl8m3w2gEBvXd0THcpUP9ocrUCJ4A=; b=r43BIRmlb7y5J3POPA+6O9+74nJC1a+79djgleJcuhVEhByyrkZNMBt9cvNhfzyE9xAwCEkrLiF8yjtemMk7S1DclKcXejrIce/s1w4Zb5MAi0HYNw8qodn0AlvOYUmPoseSKcwhLXdIbKck7nt9d1fySG+gNHFBN8pok4Gagaw=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1atftV-000Oe3-AQ ; Fri, 22 Apr 2016 21:33:33 +0300 Date: Fri, 22 Apr 2016 21:33:32 +0300 From: Ivan Klymenko To: Warner Losh Cc: FreeBSD Current Subject: Re: Heads up Message-ID: <20160422213332.7e031073@nonamehost.local> In-Reply-To: References: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 18:33:43 -0000 On Thu, 14 Apr 2016 16:42:33 -0600 Warner Losh wrote: > The CAM I/O scheduler has been committed to current. This work is > described in > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the > default scheduler doesn't change the default (old) behavior. > > One possible issue, however, is that it also enables NCQ Trims on ada > SSDs. There are a few rogue drives that claim support for this > feature, but actually implement data corrupt instead of queued trims. > The list of known rogues is believed to be complete, but some caution > is in order. > > Warner Hi. I have the small issue. I have one hard drive with zfs. If i beginning cloning the hard drive in VirtualBox machine - this process is very slow 1,5-2 hours. Without CAM_NETFLIX_IOSCHED options - this process two or three times faster. With this is possible to do something? Thanks. From owner-freebsd-current@freebsd.org Sat Apr 23 01:20:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35E6CB18079 for ; Sat, 23 Apr 2016 01:20:02 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 239801CBF for ; Sat, 23 Apr 2016 01:20:02 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 22E9FB18078; Sat, 23 Apr 2016 01:20:02 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 228AFB18077 for ; Sat, 23 Apr 2016 01:20:02 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 108621CBE for ; Sat, 23 Apr 2016 01:20:02 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie ([72.143.234.25]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3N1JwTQ022225 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2016 18:20:00 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 22 Apr 2016 18:19:53 -0700 (PDT) From: Lyndon Nerenberg X-X-Sender: lyndon@minnie.bitsea.ca To: Poul-Henning Kamp cc: current Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <76093.1461096570@critter.freebsd.dk> Message-ID: References: <76093.1461096570@critter.freebsd.dk> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 01:20:02 -0000 On Tue, 19 Apr 2016, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. True enough. But I am also wary of decending into what became of X, where a build of the xorg metapackage spends 80% of its time running configure, over and over and over again. How long until a source build becomes a series of 'rpmbuild ...' equivalents? Sadly, if this level of fine grained packaging infects the base, it *will* only be a matter of time ... So no matter what the good intentions, this is going to impact everyone, like it or not. --lyndon From owner-freebsd-current@freebsd.org Sat Apr 23 02:41:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65DEDB1929F for ; Sat, 23 Apr 2016 02:41:49 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D76D1291 for ; Sat, 23 Apr 2016 02:41:49 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie ([72.143.234.25]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3N2fkTd022554 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2016 19:41:47 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 22 Apr 2016 19:41:40 -0700 (PDT) From: Lyndon Nerenberg X-X-Sender: lyndon@minnie.bitsea.ca To: Warner Losh cc: Matthew Grooms , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: Message-ID: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 02:41:49 -0000 On Tue, 19 Apr 2016, Warner Losh wrote: > Sadly the tenor and tone of the discussion isn?t one where progress is > made. The tone has been a bit toxic and demanding, which grinds people > into dust, rather than motivating them to fix things. You might call it > a discussion, but it reads to me more as a bunch of angry villagers > storming the castle. No good can come from that. Tone down the outrage > by a factor of 100 and try to have the conversation again. I agree. Really, I do! But this must work both ways, and I can say unequivocally that my earlier interactions with the 'pkg' people have been unpleasant. Some time ago I asked about how pkg interacts with LOCALBASE!=/usr/local. This because I like to build ports from /usr/ports, but install them under /usr/pkg so as to keep /usr/local free for truly local code. This works fine (after a source rebuild of pkg), but for tools like portupgrade (from ports), which use pkg under the hood to handle dependency checks. pkg against the ports tree vs. pkg against my LOCALBASE=/usr/pkg were conflicting. So I asked some questions about how to resolve this. The response was bizarre. Wanting to use pkg with a different directory seemed almost offensive to the peoploe who answered. There was no thought of even considering the use case. I ended up filing a bugzilla report, but I see that got close with 'works as intended' a couple of days ago. I can't see how pkg as a base package manager would allow me to continue with my ports->/usr/pkg mapping. I really think the biggest problem people have at the moment is the complete and utter lack of respect core and the pkg crew have for the end users of the system. I'm pretty sure we all get WHY this work is being done. We don't all AGREE with why it's being done. And that is the conversation we are trying to have. But every time we try to have it, we get slammed down as a bunch of ungrateful whining non-coders. Lots of people wrote a lot of lines of code for Linux. Is the argument that we should just adopt that? Because it's written, it must be good? You guys need to get over that and come back to the table to have a rational discussion with the vast majority of people who actually USE this OS. All glory to Juniper and Citrix and everyone else who packages the OS into their various 'appliances'. I use both of the above at work, and believe me, for the amount of money they take out of my pocket, they can hire their own release engineers to deal with this internally without inflicting this on everyone else. And I really think THAT is the crux of the argument everyone is trying to make. To reiterate: packages are good. In moderation. As with all other things. But they have to solve the general case, and pkg - both the tool and the methodology in its current and pending incarnations - does not. I, and others, are trying to have a real conversation about this. But the blowback is incredible. Let alone incredulous. --lyndon From owner-freebsd-current@freebsd.org Sat Apr 23 03:17:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D962B19D06 for ; Sat, 23 Apr 2016 03:17:23 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ECF07134B for ; Sat, 23 Apr 2016 03:17:22 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie ([72.143.234.25]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3N3HK56022752 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Apr 2016 20:17:22 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 22 Apr 2016 20:17:15 -0700 (PDT) From: Lyndon Nerenberg X-X-Sender: lyndon@minnie.bitsea.ca To: freebsd-current@freebsd.org Subject: why 100 packages are evil In-Reply-To: <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> Message-ID: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 03:17:23 -0000 Here's a real example. I have n Centos servers. Cron, once or twice a day, updates our local cache of the yum repos. Then nagios comes along and flags 35 packages out of date. An hour later, management comes along asking questions about the security implications of those packages. An hour later we finish trolling through and say 'no worries'. Repeat. Every day. With freebsd-update, an announcement comes out that says 'update'!. So we do. Move from 10.2-p11 to 10.2-p12. There is a very clear track record of why and how this happened. What will be the new update frequency with >100 base packages? How will that impact people running productions systems. I know rebooting the mysql servers is an amount of pain that everyone below the VP level doesn't want to have anything to do with it; explaining to the VP that is. From owner-freebsd-current@freebsd.org Sat Apr 23 03:21:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21C7FB1805A for ; Sat, 23 Apr 2016 03:21:41 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 10DCB1968; Sat, 23 Apr 2016 03:21:41 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C43271518; Sat, 23 Apr 2016 03:21:40 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 23 Apr 2016 03:21:38 +0000 From: Glen Barber To: Lyndon Nerenberg Cc: freebsd-current@freebsd.org Subject: Re: why 100 packages are evil Message-ID: <20160423032138.GB1804@FreeBSD.org> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 03:21:41 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2016 at 08:17:15PM -0700, Lyndon Nerenberg wrote: > With freebsd-update, an announcement comes out that says 'update'!. So we > do. Move from 10.2-p11 to 10.2-p12. There is a very clear track record = of > why and how this happened. >=20 > What will be the new update frequency with >100 base packages? Same as it is now for releases. Packages will be available for SAs/ENs. There is no intention to change this model. Glen --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXGuo9AAoJEAMUWKVHj+KT//cP/1iUyOAKHafj7W7v8RS8Ghy9 p/IX7B3MHnUCoCHgk83p08gXHqdvDmGOoGTtPh7sb9BO4IIpgoErlhQw1Oa+tuaT ZD0zNBA356DtOaoal+QEMLtUHAwE1+bF7NvAd5wbl/vLtj/FsEFSYP9mmCIQgOP5 eOXVZJpj2C3nYikk3aWBKVpZkzwb05/G3nLuAhARV1MrJps/J1aerJDsCPmHJ8AS WKNKud74OHkk2OQkJLws2jdaeJdbNCXVNLKmISh+qGRi+8Wa40C6TicrsPsE5kby Ij6BPwaKCsm5/4oFQmkkpnwd8r3gLU8UuSJPCfrAPdUZzWbi2KPkZtdfg9ubRQwP 9uKVrigCJhWLcb6uz5MywH5QNOVd2LSz6L2HXY8bsbw5qovR7Gs5yPFZ8Kc3D217 Wpwl52jD14Nu3HogzFxmTYglRACGpbt7yEJOevfQ8Xl18eq3Azw3ZqtcWHWzOz/H xiiP9Q2Q44R/0vDo83TXToe3Zq78MrXKHGgNnwtBt5Phs0oKlUc0snuHaiJfYZxD ksr0ZsEl4fFjFz8bF7XZ2CvK+jzSBvLX7SRA9bEDZzIedHGfRs43M2/a7+fTmy87 CffsCgpTQRmZtg179xwcvVSQSDlwG6rPUmPIWM537S7rzMq/qcqYIsvUOt6R+gDh jZQsxTvPRg+yP8UBa9+s =x9Rn -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-current@freebsd.org Sat Apr 23 03:24:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F138B18183 for ; Sat, 23 Apr 2016 03:24:35 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0E8941CAE; Sat, 23 Apr 2016 03:24:35 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C1C791624; Sat, 23 Apr 2016 03:24:34 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 23 Apr 2016 03:24:33 +0000 From: Glen Barber To: Lyndon Nerenberg Cc: freebsd-current@freebsd.org Subject: Re: why 100 packages are evil Message-ID: <20160423032433.GC1804@FreeBSD.org> References: <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> <20160423032138.GB1804@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline In-Reply-To: <20160423032138.GB1804@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 03:24:35 -0000 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 23, 2016 at 03:21:38AM +0000, Glen Barber wrote: > On Fri, Apr 22, 2016 at 08:17:15PM -0700, Lyndon Nerenberg wrote: > > With freebsd-update, an announcement comes out that says 'update'!. So= we > > do. Move from 10.2-p11 to 10.2-p12. There is a very clear track recor= d of > > why and how this happened. > >=20 > > What will be the new update frequency with >100 base packages? >=20 > Same as it is now for releases. Packages will be available for SAs/ENs. >=20 > There is no intention to change this model. >=20 Furthermore, not every package will be updated with an SA/EN; just the one(s) affected. Which is why I find the complaining over 700+ packages to be quite nonsensical, since we're reducing the bandwidth required for a binary update. Glen --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXGurxAAoJEAMUWKVHj+KTaGcP/R3PdJVsui9kXLb479DMrum3 wwwyLxv6JFnCxTeeUr9WvxNSG3hUDfh4SMrkS9XeabjKJsMfASR9a1/nwDjdLeAJ jEnNl5lmz6QeEFhGUQfbeEgV1HOnTEypMV13XP/3BRXVZxhVLRwFLkhsCvoK7Q09 2cCkKvtrEYlqDHPBD2kr1yPeUdj02sCc6H6NmT6GVatL9Au03qIyI+Y0T1sK6+z8 VJb7bRCtGWx5rvz6wlQpKmAr7HaOB4u1burMqUXz31HI310WQV8JmKMHbfU/lc5i 2XZ0ZYJIQSdTHWmlJq9y16v+lP926WuMjeNAUVo30iEwnLwnMtm3ZLiHDBM8pXFS 0AygFpIcoLkDM5KZft49J2mZwgBPMaeuKsyqzA2Db6yCctEPRvuVPR93WneCyQTp +hYeNGBYq0+n+lT5GSRGQlKkUuqorrLYx/wgXge+2s6mpb7Z76mGG+wkMX8YrDR3 whuRPSDeOE5PO4E7IRhPH1pY4KgAFZXcDoXotJX4Z3wzBD9tDuuxN3sYepHznRqy xn/Wka16m6BQIuoE0B2l/VPfZ8/DJEfg8XX6V53GkrAiA47BcEoQY4D67as9XJ4z z3I7U+TY4NAHRleB2qW/y9eB7dPhFXeDm1jb5jr+xFCourP8wM7aKZ9GxayCbb/F +MeWR9E3x+HYCP+L6V4p =tgRO -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- From owner-freebsd-current@freebsd.org Sat Apr 23 03:41:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 686CAB1869C for ; Sat, 23 Apr 2016 03:41:13 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 519101272; Sat, 23 Apr 2016 03:41:13 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie ([72.143.234.25]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3N3fBqa022904 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2016 20:41:12 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 22 Apr 2016 20:41:06 -0700 (PDT) From: Lyndon Nerenberg X-X-Sender: lyndon@minnie.bitsea.ca To: Glen Barber cc: freebsd-current@freebsd.org Subject: Re: why 100 packages are evil In-Reply-To: <20160423032138.GB1804@FreeBSD.org> Message-ID: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> <20160423032138.GB1804@FreeBSD.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 03:41:13 -0000 > Same as it is now for releases. Packages will be available for SAs/ENs. > There is no intention to change this model. I get that. But the dependency base will be huge. Right now I can count on a very limited set of dependencies for anything I ship as a 3rd party package. Doing that for n>100 packages gets to be troubling. I know it can be done, but for a small company like the one I work for, it quickly becomes impractical. From owner-freebsd-current@freebsd.org Sat Apr 23 04:17:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 619F4B19574 for ; Sat, 23 Apr 2016 04:17:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 49BE818B2; Sat, 23 Apr 2016 04:17:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 0A15A115D; Sat, 23 Apr 2016 04:17:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 23 Apr 2016 04:17:42 +0000 From: Glen Barber To: Lyndon Nerenberg Cc: freebsd-current@freebsd.org Subject: Re: why 100 packages are evil Message-ID: <20160423041742.GD1804@FreeBSD.org> References: <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> <20160423032138.GB1804@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="at6+YcpfzWZg/htY" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 04:17:43 -0000 --at6+YcpfzWZg/htY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 22, 2016 at 08:41:06PM -0700, Lyndon Nerenberg wrote: > But the dependency base will be huge. Yet you fail to explain how. > Right now I can count on a very limited set of dependencies for > anything I ship as a 3rd party package. How is this different than the existing model? What do you think happens to everything that depends on OpenSSL when an SA is issued? Glen --at6+YcpfzWZg/htY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXGvdmAAoJEAMUWKVHj+KTJ8kP/iotqW/7Qjg6Zyq98p0UmBRG WzMNg+xr274PVe2Zlu8hvQsR7hWfCcRyt3qqg738PGUV5Xg6LoF4JyB10oRnSPPA 0gWK8tWi1PYvZ5FbQjymNB0NaSNHKfUXV7UY8TAVvDvDkGSflLJ51OCOWNImeRLw hF5g+5LwdjB17BeQ6QEjlgILu2cJazaxgEgzSZMyHde84gP2CLMQqNs6mqS7ANn5 oHKK6a8tWg9II4Sb+AhWBsmMZnye1VqRmxHM/fdHf1fVoal1qZDaQaWYUtsnvOdx Qjlc6W0uBxqdsi1dHm2DtSpQ2Pzs8iqJlHUrXt5Wtpl/f7k58w5GPDJAUHvAR/d2 gjkejiz/2A1bfJEMwlkwYGBdQsNQjdihWiLj/tY5KlQN9VpTZhH8YXnaEN3s/RV9 0mKAAZgezw0DfNrtG+Sm8tNZVzKU6ucN6Xnj1yDjMONTOKflE7liPORUmAhZCuNh I9GbZ3Z00ch0pCFONe76PcEPEL1ykvOsMo9F2AyVogj3j0/SP+/VGBEzTMglkhZ7 KY6+sTdGqtovxgrdHSs+o2+4w3Vz8OtfulcqeFeNLV9suRlEGPhtnM2NUFpzB1H6 VEgfQYH2JBJ0fP2SBnwSeF5RZ+qrktbOV1slzm1tuagdW5hJVtXXOjuYJql70JAn wATwlO/MEqQJxzgGmrih =p/1q -----END PGP SIGNATURE----- --at6+YcpfzWZg/htY-- From owner-freebsd-current@freebsd.org Sat Apr 23 05:46:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E296B19FD8 for ; Sat, 23 Apr 2016 05:46:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39E332000 for ; Sat, 23 Apr 2016 05:46:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id f89so112116821ioi.0 for ; Fri, 22 Apr 2016 22:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=CfFgGG1Pyp32Qfkux4JFwDiWy1kMc7t4cUxy0rUGj1Y=; b=Qg82DbhnO2tBXqwcmz7uL8c2F9JPcsbDZsaeRs223N3ybe/XWarLcoTSPc+AqBd35E 3MyGZhv4QI0im3kd7aHjxJ9dDFCVoEhXULpAgxVLgBO3rnhg+afQxJvSulg9eAEvlOTk 0aCVBLmNpPznF9qyQOSJshnT3SjMUmixX9u8V/sMC0ic6+3NWvymq2NEghDhQaH9Ci5F Ql866Iu668oSOUEQ7XTRIu6iu/YIPX2aD4+Q4w0fVCUMu670DTCQHQYrjqAAFW1nbyb4 C9pXLi5+l8heVcheTu//oIDqxcYuiYmjCwd0d9f4ZMytnpGSiCYynpSanYipZuNmi0OO AAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CfFgGG1Pyp32Qfkux4JFwDiWy1kMc7t4cUxy0rUGj1Y=; b=D0E/wVw0acc/pxAQ4r0nfivImFORyTZMeMqVxYMLe7Egkl95W6o+vWxfXQxPn+dnoZ 2RT5xyXCl4xT1e0Ab0pgGGP50ooM51MyBWL1NQK0tyPdF4K4VgKonclNCsUsDFqf7KsF yDcxQdYyXZLBdBrLnaaotfKnHfQBX8QstOnPfMdTA1FUwjOk/lqdZm50nn4KocC8N96s LYhAO6hH1F5ATXbBwqLJwlmdQpYBZiR1w3JQcSD1eNYMuUYqEp/Vt21uXfDxGqzMwtSE +uj8h+fadE8cz+x9QeyIsN4HVEPkb7hwxmtzkvbjMpgSZEpuulkLmRJKem1m+GhoYCYc 5GtQ== X-Gm-Message-State: AOPr4FUqfpNzXy578vkQFyAo9lvXFPZvKP1kRih/VO0UU2yFV2vSTtOvPHF0rCVlvvBBNegVuYFl4ZZq44YRGA== MIME-Version: 1.0 X-Received: by 10.107.133.151 with SMTP id p23mr27329592ioi.16.1461390373559; Fri, 22 Apr 2016 22:46:13 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Fri, 22 Apr 2016 22:46:13 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> Date: Fri, 22 Apr 2016 23:46:13 -0600 X-Google-Sender-Auth: 9qQug_UlTsxcwfnTxchsyRWhl44 Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: Warner Losh To: Lyndon Nerenberg Cc: Matthew Grooms , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 05:46:14 -0000 On Fri, Apr 22, 2016 at 8:41 PM, Lyndon Nerenberg wrote: > You guys need to get over that and come back to the table to have a > rational discussion with the vast majority of people who actually USE this > OS. All glory to Juniper and Citrix and everyone else who packages the OS > into their various 'appliances'. I use both of the above at work, and > believe me, for the amount of money they take out of my pocket, they can > hire their own release engineers to deal with this internally without > inflicting this on everyone else. > *THAT* is the tone I was complaining about. This is not at all respectful. How can we have a rational discussion with people talking about "all glory to" this or that? I don't think it is possible. I get the point you are trying to make, but it is being made so poorly that I have to point that out. You don't get people to come to a table by being disrespectful and demanding their presence. I sit at whatever table I choose to sit at. You have to convince me to sit, not demand that I sit. I haven't responded well to that since the 70's, and I'm ill inclined to start now. Yelling and screaming isn't going to do it. Jumping up and down isn't going to do it. Nobody wants to chat with the mob carrying pitch forks and torches. People do want to talk to rational people having rational discussions perhaps with a point of view that differs from their own. You can scream all you want, but I doubt it will get the results you want. > And I really think THAT is the crux of the argument everyone is trying to > make. > > To reiterate: packages are good. In moderation. As with all other > things. But they have to solve the general case, and pkg - both the tool > and the methodology in its current and pending incarnations - does not. > > I, and others, are trying to have a real conversation about this. But the > blowback is incredible. Let alone incredulous. That is understood. Being toxic about it isn't going to help. Being disrespectful is not going to help. Being hyperbolic isn't going to help. It isn't a real conversation until that stuff is gone. So far I've seen no evidence of it being gone. I've met personally with Glen, in person. I had a wonderful chat with him. Based on talking to him, it was clear many of the complaints here were overblown. Are there rough edges? Yes. Are there things we don't know? Yes. Is it the end of the world? No. Over the coming weeks, things will get easier. The rough edges will be sanded off. After talking with him, I have complete confidence in him and others that are working on making this happen. I don't need it to be perfect today, because of this confidence. I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. Warner From owner-freebsd-current@freebsd.org Sat Apr 23 05:49:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70D5DB19096 for ; Sat, 23 Apr 2016 05:49:33 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27BD71170 for ; Sat, 23 Apr 2016 05:49:33 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1atqRY-0003iP-9b; Sat, 23 Apr 2016 07:49:24 +0200 Date: Sat, 23 Apr 2016 07:49:24 +0200 From: Kurt Jaeger To: Lyndon Nerenberg Cc: Warner Losh , Matthew Grooms , freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160423054924.GS2282@home.opsec.eu> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 05:49:33 -0000 Hi! > This works fine (after a source rebuild of pkg), but for tools like > portupgrade (from ports), which use pkg under the hood to handle > dependency checks. pkg against the ports tree vs. pkg against my > LOCALBASE=/usr/pkg were conflicting. So I asked some questions about how > to resolve this. > The response was bizarre. Wanting to use pkg with a > different directory seemed almost offensive to the people who answered. It was probably the result of estimating the amount of work necessary to implement this. > There was no thought of even considering the use case. I ended up filing > a bugzilla report, but I see that got close with 'works as intended' a > couple of days ago. As usual, if someone complains about some PR being handled ungraceful, would you please, in the name of reason, name the PR, so that others can check the details without searching the open PR pool for it ? > I can't see how pkg as a base package manager would allow me > to continue with my ports->/usr/pkg mapping. If you analyse the code and fix the places where it needs to be adapted, it would probably work. > I really think the biggest problem people have at the moment is the > complete and utter lack of respect core and the pkg crew have for the end > users of the system. Does it help if I explain to you that there is almost no-one there that can listen to your complaints ? Literally ? There are only a small handful of people that work on core or pkg crew, and they work on so many things that they only skim the lists, because of lack of time ? pkg-crew might be 1-2 folks that try to cope with the flood of requests and try to triage according to "can be solved in less time than...". It has nothing to do with lack of respect. > I'm pretty sure we all get WHY this work is being > done. We don't all AGREE with why it's being done. And that is the > conversation we are trying to have. But every time we try to have it, we > get slammed down as a bunch of ungrateful whining non-coders. Sending this email costs me 10mins or so. Committing 1-2 port updates takes the same amount of time. So, what is my choice ? > Lots of people wrote a lot of lines of code for Linux. Is the argument > that we should just adopt that? Because it's written, it must be good? No, that's not the argument the other side is making. They work as much as possible, but there are too few people to work on it. > You guys need to get over that and come back to the table to have a > rational discussion with the vast majority of people who actually USE this > OS. Suggesting that their behaviour is not rational does not help 8-) > All glory to Juniper and Citrix and everyone else who packages the OS > into their various 'appliances'. I use both of the above at work, and > believe me, for the amount of money they take out of my pocket, they can > hire their own release engineers to deal with this internally without > inflicting this on everyone else. Not even they can do that 8-) If I look at the issues citrix has to solve, they probably are spread thin 8-} If I look at the messages a juniper EX switch sends during an upgrade, some of which look strange, their engineering dept. is probably at some limit, too. > To reiterate: packages are good. In moderation. As with all other > things. But they have to solve the general case, and pkg - both the tool > and the methodology in its current and pending incarnations - does not. >From what I learn, pkg in its current form solves *a lot* of problems, and yes, not 100% of all problems. So let's work on the other ones step by step. > I, and others, are trying to have a real conversation about this. But the > blowback is incredible. Let alone incredulous. Thanks for that attempt. We need to find resources (time, skill, code) to have this conversation, and right now, all of that is in very short supply. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Sat Apr 23 05:59:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D33CB1937A for ; Sat, 23 Apr 2016 05:59:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::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 579C91739 for ; Sat, 23 Apr 2016 05:59:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x244.google.com with SMTP id x35so5619569ioi.0 for ; Fri, 22 Apr 2016 22:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=EIOmM3B8lAH8aaRQxhRKAXAHNq2eZQjeIGmCarPGC+8=; b=p7Jv7KKbajNL0uo+BGRdB7CDzwVImPKlanTnfzb5bLaCFnddXl2o9mwpNOo/WPwYGl da76gQ75b7pq70bNpk6Z3pCrz4Iuie0qwCYrX4fG3QLBd6h4HoEhJm0s1NX48rIKqVkf wLGrpqoPH1ZgBfFLN0OBhk8iReyu8aKVR5ru+bDXX2Db5zQ4xGJUT2tbljjFbzCY3j3h coDO9rwzbBGUI+Bj84mPGZ6HeNnQg8mdmVn7LnROXJUqRaoevk4BARr1sO+mH0fX0bww b1my7M85j/ovrj1SbIgjEp5FCJbq5tqjmS/HE0z5OnlehoTYgfgs2hISgBm6wmelxznm o7Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=EIOmM3B8lAH8aaRQxhRKAXAHNq2eZQjeIGmCarPGC+8=; b=kPmgnPlFEnjKz8TCOU58rH2hpWkT3P6Yp4RU7yNAUeam03DtFNIP2zcClXA66sJ1Rt GmH7ZEzIwO5gjY4PtmYkbKMfbTmk/MubV8ETg+oGo4ffhjLsLM3Q7Q88UHmhN1p5JMHo wz0FsSThbFbNjPqRsoYUYWzL7SOoxFLT1sFp9MzNuZdamioLqnd18m78+S5JDenfx7+X bFEWO/aDDEQopDG/SQUj8cId5yj2LGspLnspjJ0h256EAcnDQv/bAaXG3amdUkeDwnB0 HFKM9y4kcuLt3I1qNpQwF19s55C2OrpGlPfNx3yKcCRf1G+l+V75Hdevpu3gxa7bxMo4 JoPQ== X-Gm-Message-State: AOPr4FVvQ/oNc0e8cdeXh8o0kIJHREJablgzYtKEFQdBOBrZA/YO6LI0eZbiXXdxIQ88Pl0+4g3aaSXZCRtOdQ== MIME-Version: 1.0 X-Received: by 10.107.133.151 with SMTP id p23mr27366054ioi.16.1461391176824; Fri, 22 Apr 2016 22:59:36 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Fri, 22 Apr 2016 22:59:36 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160422213332.7e031073@nonamehost.local> References: <20160422213332.7e031073@nonamehost.local> Date: Fri, 22 Apr 2016 23:59:36 -0600 X-Google-Sender-Auth: s--hURKhu-q_JkPDvTpuvKpdYaY Message-ID: Subject: Re: Heads up From: Warner Losh To: Ivan Klymenko Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 05:59:37 -0000 On Fri, Apr 22, 2016 at 12:33 PM, Ivan Klymenko wrote: > On Thu, 14 Apr 2016 16:42:33 -0600 > Warner Losh wrote: > > > The CAM I/O scheduler has been committed to current. This work is > > described in > > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the > > default scheduler doesn't change the default (old) behavior. > > > > One possible issue, however, is that it also enables NCQ Trims on ada > > SSDs. There are a few rogue drives that claim support for this > > feature, but actually implement data corrupt instead of queued trims. > > The list of known rogues is believed to be complete, but some caution > > is in order. > > > > Warner > > Hi. > > I have the small issue. > I have one hard drive with zfs. > If i beginning cloning the hard drive in VirtualBox machine - this > process is very slow 1,5-2 hours. > Without CAM_NETFLIX_IOSCHED options - this process two or three times > faster. > With this is possible to do something? > I don't know. I've not investigated this in enough detail to know. One thing you might change is the read bias from 300 to 1, which may be more appropriate for your workload. Warner From owner-freebsd-current@freebsd.org Sat Apr 23 06:27:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC90FB19B1D for ; Sat, 23 Apr 2016 06:27:09 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCF81154 for ; Sat, 23 Apr 2016 06:27:08 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.117.119.78]) by mail.rdsor.ro (Postfix) with ESMTP id 3D29123292; Sat, 23 Apr 2016 09:27:02 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Dan Partelly In-Reply-To: Date: Sat, 23 Apr 2016 09:27:02 +0300 Cc: Lyndon Nerenberg , Matthew Grooms , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9BA8C798-C87D-4CA8-9AB3-CEC309AB81A5@rdsor.ro> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> To: Warner Losh X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 06:27:09 -0000 >>=20 >=20 > *THAT* is the tone I was complaining about. This is not at all = respectful. >=20 Respect is a two way street. If you want respect, offer yours. We make = our point very poorly, I get you, but it is the result of what you = and others from the projectdo. Meaning, 0 communication. I dont know if = that means 0 communications skills,or you do not communicate on = purpose. You as a member of the core team, should be one of the first = to address this problem.=20 After all you the core invested time in code of conducts and other = things of questionable value, but at the same time you always avoid to = clearly communicate with your user base. > 've met personally with Glen, in person. I had a wonderful chat with = him. Maybe you did. We did not. Serious mechanism issues regarding pkg went = unanswered on the other list. Look on pkg list, very rational, polite, = and to the subject, 100% rational message about pkg base which is not = responded. So, you complain about tone, and how helpful would be for = ppl to change it. Let me give you a suggestion: start with altering your = own behaviour. Offer respect, be communicative, less sensible on = internet where it is very hard to convey =E2=80=9Ctone=E2=80=9D. You'll = see that it works wonders to indirectly alter the behaviour of the = people you so eloquently compared to peasants daring to disturb the lord = of the castle. You says that everything will be OK. I want to believe you. But giving = the track record VIMAGE has, and how many gugs go on and on with years = Im not so sure that you guys wont do the same with this subsystem, and = leave it with rough edges for half a decade. Because we all know that = everything will be OK in the end. Timeframe is also important. >=20 >=20 >> And I really think THAT is the crux of the argument everyone is = trying to >> make. >>=20 >> To reiterate: packages are good. In moderation. As with all other >> things. But they have to solve the general case, and pkg - both the = tool >> and the methodology in its current and pending incarnations - does = not. >>=20 >> I, and others, are trying to have a real conversation about this. = But the >> blowback is incredible. Let alone incredulous. >=20 >=20 > That is understood. Being toxic about it isn't going to help. Being > disrespectful is not going to help. Being hyperbolic isn't going to = help. > It isn't a real conversation until that stuff is gone. So far I've = seen no > evidence of it being gone. >=20 > I've met personally with Glen, in person. I had a wonderful chat with = him. > Based on talking to him, it was clear many of the complaints here were > overblown. Are there rough edges? Yes. Are there things we don't know? = Yes. > Is it the end of the world? No. Over the coming weeks, things will get > easier. The rough edges will be sanded off. After talking with him, I = have > complete confidence in him and others that are working on making this > happen. I don't need it to be perfect today, because of this = confidence. >=20 > I personally will be refraining from engaging further. I plan on = seeing > what gaps there are by adding support to NanoBSD for packages. I'll be = busy > with that. In talking to Glen and others, we've already identified a = few > easy gaps to fill. Once they've done that, I'll get going on NanoBSD = with > the goal to be able to use it to build a bootable system of any > architecture from packages with no root privs. I expect to find = issues, but > I don't expect to find any issue that's intractable. I expect after = the > issues are resolved, the end product will be better for everybody. >=20 > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Apr 23 11:32:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23B33B1AD0E for ; Sat, 23 Apr 2016 11:32:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 16F3B1E8B; Sat, 23 Apr 2016 11:32:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3C69A311; Sat, 23 Apr 2016 11:32:16 +0000 (UTC) Date: Sat, 23 Apr 2016 11:32:16 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <984291795.17.1461411136062.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1041045088.38.1460346352404.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1041045088.38.1460346352404.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #184 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 11:32:16 -0000 See ------------------------------------------ Started by an SCM change Started by an SCM change > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci.git # timeout=10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci.git > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 Checking out Revision 926429031e0241da821577c12b4b8f7db789e7e1 (refs/remotes/origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 926429031e0241da821577c12b4b8f7db789e7e1 > git rev-list 926429031e0241da821577c12b4b8f7db789e7e1 # timeout=10 [Pipeline] Allocate node : Start Still waiting to schedule task Waiting for next available executor on jenkins-10.freebsd.org Resuming build Resuming build Resuming build Aborted by rodrigc [Pipeline] Allocate node : End [Pipeline] Allocate node : Start Running on master in /usr/local/jenkins/workspace/FreeBSD_HEAD [Pipeline] node { [Pipeline] step From owner-freebsd-current@freebsd.org Sat Apr 23 13:47:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C22DB129AB for ; Sat, 23 Apr 2016 13:47:00 +0000 (UTC) (envelope-from baho-utot@columbus.rr.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by mx1.freebsd.org (Postfix) with ESMTP id 034741A0B for ; Sat, 23 Apr 2016 13:46:59 +0000 (UTC) (envelope-from baho-utot@columbus.rr.com) Received: from [75.187.32.8] ([75.187.32.8:57977] helo=raspberrypi.bildanet.com) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 80/F5-07823-2DC7B175; Sat, 23 Apr 2016 13:46:58 +0000 Received: from [192.168.1.40] (helo=baho-utot.bildanet.com) by raspberrypi.bildanet.com with esmtp (Exim 4.84) (envelope-from ) id 1atxth-0007FK-Ug for freebsd-current@freebsd.org; Sat, 23 Apr 2016 09:46:57 -0400 Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <4787f50d3f160e606ad55737e93a324a@rdsor.ro> <20160419102751.GM82927@e-new.0x20.net> From: Baho Utot Message-ID: <60de15a5-be3f-27d6-caa6-6dfe1942612d@columbus.rr.com> Date: Sat, 23 Apr 2016 09:46:57 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160419102751.GM82927@e-new.0x20.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 13:47:00 -0000 Sorry for hijacking this thread but where can one find the code for 11-CURRENT that handles the packaging of base? I would like to have a look at it so I can form my opinion on packaging base. I moved to FreeBSD from LinuxFromScratch, ( I packaged that with the RPM package manager and it is on Github). From owner-freebsd-current@freebsd.org Sat Apr 23 13:51:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D24F0B12A4D for ; Sat, 23 Apr 2016 13:51:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FCC11D41 for ; Sat, 23 Apr 2016 13:51:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u3NDpdj5035690; Sat, 23 Apr 2016 09:51:39 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Sat, 23 Apr 2016 09:51:39 -0400 (EDT) Date: Sat, 23 Apr 2016 09:51:39 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Warner Losh cc: FreeBSD Current Subject: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8)) In-Reply-To: Message-ID: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 13:51:47 -0000 [CC trimmed] On Fri, 22 Apr 2016, Warner Losh wrote: > > I personally will be refraining from engaging further. I plan on seeing > what gaps there are by adding support to NanoBSD for packages. I'll be busy > with that. In talking to Glen and others, we've already identified a few > easy gaps to fill. Once they've done that, I'll get going on NanoBSD with > the goal to be able to use it to build a bootable system of any > architecture from packages with no root privs. I expect to find issues, but > I don't expect to find any issue that's intractable. I expect after the > issues are resolved, the end product will be better for everybody. Thank you for working on NanoBSD. Do you think it would be possible to add support for optionally building dump(8) images instead of dd? -- DE From owner-freebsd-current@freebsd.org Sat Apr 23 14:41:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73C48B19EDD for ; Sat, 23 Apr 2016 14:41:07 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 468031D9A for ; Sat, 23 Apr 2016 14:41:07 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id f89so117703708ioi.0 for ; Sat, 23 Apr 2016 07:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=O/2VfX2f0Ns09htxd7y3/BPO37eexfX8O4cLXiVYxvM=; b=aWUEaQ2slHQhzraRgaVq0ggGbld3fKEZBnoWSDVTpMhun5vvjD/TSN47kvBwY3vVXG znxxagoTSLwksott3I6X+1Jq/isA+XXsv717V/qqHZwWCIfCmbCygidCUOaoQUp5D5DG 8VofUkmPoPljy1+YsQH0xl/RRxw/99xQ8m6HR1Z6c0PLB5FMXf1xTJNE+aWO9/IXwcGL Drw70adJ+JHLJO1zXvd7bBWvDUG8D5Q5vXDtujrSL5LHIkfAgXDjndxWSARmmyFlEea0 ll7v3z9zWpwqyOOocskgSSuDjFNBJd6kXVokWHhQppUQKN7goBIjgZwWDQ/50XE3lRgn UIvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O/2VfX2f0Ns09htxd7y3/BPO37eexfX8O4cLXiVYxvM=; b=hM041loPEdH6o9HbB2TD9r2plEooJDA0hU7zx/YIMGkXWSsne5z9ILgr8Sa4E4zqwU 5sVh8qDoxRp8xj90e76jRd0WKlTVW2yRAV+XaJLQMWoKOYENwYxIIjKKT11DXbiQUl/b w6M9GvJ1tjkV/t5hyV/JfzvxngNqbLDnuwNayrRPNIJeARYsfMcHOpRPwq4qmAqLNbqz LtZTNEFUy9cImdADl+421dSafgoGt8R7dq4SSqMp5EZd2JhbE8vWML3B81xMNF0PmWmV Ghus7nWmWEwkQB9cyMQVrBJq47aLa8L3lot00N0LLWYZuvVPtvnmzHkFCBjEvBqGt7l6 Agaw== X-Gm-Message-State: AOPr4FXO0ktaPysSmk3n6TKTsnvy3RgKt9YP/BSBkQkgjnTX7E5NGxpop8faeIlwTB+w5gS53f+/ly+GaqEvNg== X-Received: by 10.107.132.194 with SMTP id o63mr10781726ioi.118.1461422466635; Sat, 23 Apr 2016 07:41:06 -0700 (PDT) MIME-Version: 1.0 From: Howard Su Date: Sat, 23 Apr 2016 14:40:57 +0000 Message-ID: Subject: Failed to boot -Current snapshot memstick img with EFI To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 14:41:07 -0000 The issue is partition table in img is wrong so that GEOM cannot discover the partitions. Detailed error: GEOM_PART: last LBA is below first LBA: 0 < 32 GEOM_PART: integrity check failed (da0, MBR) I tried this month and last month memstick img. both has same problem. Any idea on the issue? -Howard -- -Howard From owner-freebsd-current@freebsd.org Sat Apr 23 15:06:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50C7BB1AA36 for ; Sat, 23 Apr 2016 15:06:31 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 43EED1F3A; Sat, 23 Apr 2016 15:06:31 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A10093AA; Sat, 23 Apr 2016 15:06:30 +0000 (UTC) Date: Sat, 23 Apr 2016 15:06:30 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1894019079.0.1461423990383.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <984291795.17.1461411136062.JavaMail.jenkins@jenkins-9.freebsd.org> References: <984291795.17.1461411136062.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD #185 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 15:06:31 -0000 See From owner-freebsd-current@freebsd.org Sat Apr 23 16:19:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65E91B1A710 for ; Sat, 23 Apr 2016 16:19:59 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2D69C1A18 for ; Sat, 23 Apr 2016 16:19:58 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6466D4FB57; Sat, 23 Apr 2016 16:19:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u3NGJuSP034744; Sat, 23 Apr 2016 16:19:56 GMT (envelope-from phk@phk.freebsd.dk) To: Lyndon Nerenberg cc: freebsd-current@freebsd.org Subject: Re: why 100 packages are evil In-reply-to: From: "Poul-Henning Kamp" References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <34742.1461428396.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Apr 2016 16:19:56 +0000 Message-ID: <34743.1461428396@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 16:19:59 -0000 -------- In message , Lyndon = Neren berg writes: >With freebsd-update, an announcement comes out that says 'update'!. So w= e = >do. Move from 10.2-p11 to 10.2-p12. There is a very clear track record = >of why and how this happened. Is freebsd-update going away as result of the new packaging ? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Sat Apr 23 17:52:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 540C9B1A007 for ; Sat, 23 Apr 2016 17:52:37 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (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 CD6171706 for ; Sat, 23 Apr 2016 17:52:36 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (liminal.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3636:3bff:fed4:b0d6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 228829058 for ; Sat, 23 Apr 2016 17:52:33 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/228829058; dkim=none; dkim-atps=neutral Subject: Re: why 100 packages are evil To: freebsd-current@freebsd.org References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> <34743.1461428396@critter.freebsd.dk> From: Matthew Seaman Message-ID: <571BB660.1070107@FreeBSD.org> Date: Sat, 23 Apr 2016 18:52:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <34743.1461428396@critter.freebsd.dk> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U29wnsO23bwwAtcfg6RNSTwaMK79xf9mm" X-Virus-Scanned: clamav-milter 0.99.1 at smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 17:52:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U29wnsO23bwwAtcfg6RNSTwaMK79xf9mm Content-Type: multipart/mixed; boundary="Xkr3av7KLsAxlsvOiinGNOFTdAoTH0aof" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <571BB660.1070107@FreeBSD.org> Subject: Re: why 100 packages are evil References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <57170E5D.1090701@freebsd.org> <5524F499-5042-407E-9180-43D15A53F3F0@FreeBSD.org> <7621BDAB-A409-456A-A3F1-A6CD9B371DBC@rdsor.ro> <20160420094806.GJ6614@zxy.spb.ru> <7c84f388-21dc-419f-70ce-c5369e294dab@freebsd.org> <34743.1461428396@critter.freebsd.dk> In-Reply-To: <34743.1461428396@critter.freebsd.dk> --Xkr3av7KLsAxlsvOiinGNOFTdAoTH0aof Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 23/04/2016 17:19, Poul-Henning Kamp wrote: > -------- > In message , Lynd= on Neren > berg writes: >=20 >> With freebsd-update, an announcement comes out that says 'update'!. S= o we=20 >> do. Move from 10.2-p11 to 10.2-p12. There is a very clear track reco= rd=20 >> of why and how this happened. >=20 > Is freebsd-update going away as result of the new packaging ? Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that's the plan for 11.0-RELEASE. I have no idea if anyone intends to run maintain freebsd-update in parallel for a transition period, but freebsd-update will ultimately be superceded. Cheers, Matthew --Xkr3av7KLsAxlsvOiinGNOFTdAoTH0aof-- --U29wnsO23bwwAtcfg6RNSTwaMK79xf9mm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJXG7ZgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATm/cP/iNAXr4TnW3KP3aYsAlZMU8P w3Wis9Bs4zLqc9SpsfeLe0Hi3fNrSPTI9WMD0qKkzXNrXdD+gkxsQARUklGwHtUC d7tJWOGltRxldcWMVZ1Zspnc4EOFykmo/5ScOAlEXQkVRzfdjj4Sr8j0bsbMQ54d sHI1OUDJ9gsBuNaU73XVU+it01HyDFZoCzW7tnr7KVgdzKDkdtAykwI4MW9Ao3bY LOYYGSw0i2BVVWH8tWsKWLk4FvMP/WISHMCJqC8lnQ4mVMh9FF1c03Dya6Y6MpPp 20t+I7V5BPo857Zyk25DUuD0OtvHmRCG9QORpvo7cPnCRY/7fIzcdeod11aYD2kk u9kK+Uc711lxKG79JCDLhGz8wcTv4CumlORHbERvx1Sz42Ec/2mZNASzyJRcr/yp cCSE7st+hKgco4gXGbX1ogF22qmvURQVDDMPkXwjwKDRCQaAE9F+cB1pDQ1jhzmJ +9FgSSU8WoE6Tdlcmo8YgDmu92VzSmy7c278JVbNfcmce73mC8Za9lPteL/zG9Kz O8E3AnHhhQ71kwVR3kc6iUPj68TOP3/lTz+xnloZ85Zfkowu5rCDsD0Lmtqs2lkT 5+V495cxX9idIl79fDFhrupzmp0St6ApARmzTBRVloHTm4xdILTvZRiYk22heN/E IBiu8/2sjP/rSW1wjr80 =RoQ0 -----END PGP SIGNATURE----- --U29wnsO23bwwAtcfg6RNSTwaMK79xf9mm-- From owner-freebsd-current@freebsd.org Sat Apr 23 18:24:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3D37B1A724 for ; Sat, 23 Apr 2016 18:24:24 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CAD9413B7 for ; Sat, 23 Apr 2016 18:24:24 +0000 (UTC) (envelope-from marquis@roble.com) Date: Sat, 23 Apr 2016 11:24:18 -0700 (PDT) From: Roger Marquis To: freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 18:24:24 -0000 To clarify this proposal a bit better, there are only two flags I think should be added to pkg to accommodate the usability issues introduced by base packages and to do so without breaking existing scripts and aliases: -b) only display base packages -B) display both base and third party packages neither -b nor -B) do not display base packages The implementation could be as simple as a regex or as extensive as adding a new field to the database. That aside there's still the issues of versioning and dependencies. Haven't seen many versioning recommendations but given existing implementations (Solaris') have been carefully researched and tested they should be safe and painless to reuse in pkgng. Dependency checking and tracking will likely to be the most time-consuming delta but, IMO and ldd aside, this can be left until 11.1. For 11.0 it should be sufficient to issue a warning to the effect "'pkg remove [anything in base]' is not currently supported and may break parts of the system", at least for those packages which are not already known by their equavilent 'OPTIONS_UNSET' and 'WITHOUT' build params. IMO, Roger > Personally I think the behavior of pkg should remain as it now to avoid > breaking existing scripts and aliases i.e., base packages would not be > shown without specifying a new flag, say '-b'. This base flag could > similarly display only base packages and also recognize the leaf > concept. Presumably there should also be a flag to display both third > party and base packages, especially with the audit flag, but that could > be implemented at a future date without significantly reducing the > utility of base packages in 11-RELEASE. From owner-freebsd-current@freebsd.org Sat Apr 23 19:41:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5355CB1A987 for ; Sat, 23 Apr 2016 19:41:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2925919BC for ; Sat, 23 Apr 2016 19:41:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id d62so51784278iof.2 for ; Sat, 23 Apr 2016 12:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=JrP/jQSZawrT7WlTFRosm9M6nodPLR2GvECqSdTH5zY=; b=ckjt9CmFSISgxlDOFOEeetS/rawbal2/CW7sIluI1gXu8QMC27w6OOxFTCtLSR0fNt BYOMkmZy0JiLVO+IuoEaifPDsp8VbTOFTN8dMEJ6OhtKWdOpXjg5ztMsnEaPYY20ME0R VfLU2eCvfZ5SIASDLcizqeju2h66arBZdHRvRh3b8wx6IINiujJCpaK+2LO79J7cc7Lm TxvziH/CSDalUGL7LyCGw8eGU4RkQAbvY8stLbDnhSjx/Ha2JJuVfbebKw/OdtnF2Aj6 EZWlMPiRIqIzwdF5rYyd8L5jzxpfbTkPGDVHMNGzg+J1aPU4765Vwu/em/wO1NEnd20D kuKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JrP/jQSZawrT7WlTFRosm9M6nodPLR2GvECqSdTH5zY=; b=QoP0fC9EnAsRA6mGhhVa49cIVVHJzrsJ8X4jGyPfo7gH6s8rwRsBJp679YDU+YyP1G NPy4+cczC/a+7UzpTf1CJaDiEaH7B5aRdJnn0J/en7J/Ons3QPx7xVR4ihL7u/R2AFJc /xir2f0M6209GAIAJ/JrMyUqYH6QhmYJiwBIJbzFchtl6fGNGEPyBsGXPny8BRuhQsko Gu9Bxk1Tj+3Cr4G9wAc58X9GUJ2HlMnJRgEC03Og7tuQulmTqRjIiYfAigJu2+EmVr5X 37Zf2FJ9I65GdJKss21MJNcMSTitmX1WR15jXkpgRyxp0bjOg+u+xDvUE1VTso/Qg4P8 KHfg== X-Gm-Message-State: AOPr4FX9iCNsQOCBT1Eeg9vAqnt0DE0/kJFspGOj5yS9Ge40yW4D8LhfCSIZKTfVT68Inz3kvwrakPn8C+xU6Q== MIME-Version: 1.0 X-Received: by 10.107.133.229 with SMTP id p98mr1785829ioi.16.1461440508287; Sat, 23 Apr 2016 12:41:48 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Sat, 23 Apr 2016 12:41:48 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <9BA8C798-C87D-4CA8-9AB3-CEC309AB81A5@rdsor.ro> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <9BA8C798-C87D-4CA8-9AB3-CEC309AB81A5@rdsor.ro> Date: Sat, 23 Apr 2016 13:41:48 -0600 X-Google-Sender-Auth: _4uD-u2ZEXFldHavhUoFE66NwPI Message-ID: Subject: Re: [CFT] packaging the base system with pkg(8) From: Warner Losh To: Dan Partelly Cc: Lyndon Nerenberg , Matthew Grooms , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 19:41:49 -0000 On Sat, Apr 23, 2016 at 12:27 AM, Dan Partelly wrote: > You says that everything will be OK. I want to believe you. But giving > the track record VIMAGE has, and how many gugs go on and on with years Im > not so sure that you guys wont do the same with this subsystem, and leave > it with rough edges for half a decade. Because we all know that everything > will be OK in the end. Timeframe is also important. I can't help you with your trust issues. I'm saying that feedback has been heard and understood and providing more now while things are in flux to try to address those issues is not likely to be fruitful. Warner From owner-freebsd-current@freebsd.org Sat Apr 23 19:47:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93B1CB1AACA for ; Sat, 23 Apr 2016 19:47:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 5B5701D38 for ; Sat, 23 Apr 2016 19:47:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id f89so121120276ioi.0 for ; Sat, 23 Apr 2016 12:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=xGAIrkW45L/b2sxXZiScEXsw5UBFOJTjV951dC9ywoE=; b=kTqy3ashGJLWliC+AIjR5F1tbNVMRsFPrVTyR9f/40UehsukMyierFEEh4f/FGaDJR vup8QwqokuPFTfHcckPj5QGKiS1IE/GO+KRdhr2k/g5B0pTdnd3QktPWUtPpp2IgKIUg 63lf72jQ/KyOgLVwwF6SVK/m4QsbNCuJHYmm5qiWN2R/iiJQeVRaXW8eU+SCLcpgFSbM M2YhZATPrj1iWfuTgwHgUf9pOYSpdZ9mtvPs23nIP5N91v3gQDERpMpXs96ljxyQW2jF hPwgB/RpT9Wu1T9omm3bL2VRAMc2W9U3GWXRaRGcf7ZCCHbpoJ1aXdd5hYrerPju3Bja 2xeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xGAIrkW45L/b2sxXZiScEXsw5UBFOJTjV951dC9ywoE=; b=c62RD6YzWhluF40sftHcG2vMxirrb/6HrvUMMm/UUTNozy/oQtvD588Ahara9dWDaB l4LVWLTLtqDHlSS4a8QQxmCXZ+iPH/jUi/vFNigdqAM6wHL38N6VsYGBVLHilq34/SJt xGh+Vy9c9TOiaVEXH990lFZbYa2HQyQtnMy670+rOOnXlc2UuI4TLy1pDw1ufgZc08/l 4XFpIq+hrpwpagL3nm4NUDorD0ZH041YAvCGc0UUDTi4zSCnrO09Mt4c1qTjNtj+QjiM f6CsFXfb+/L7LXM+uxx/5o8Nw6v041B0hPa5J/svreIYwcjcsTuQze2Xzf2C6ZSyAvC6 ofrg== X-Gm-Message-State: AOPr4FXR0IPDomrLYOONFZarQSStTtaODXEstOoL50Tyj9eIUn+8MrIsoA8gpe6hD4e2jI4UuE1In14waaBH3Q== MIME-Version: 1.0 X-Received: by 10.107.192.129 with SMTP id q123mr29934179iof.197.1461440874831; Sat, 23 Apr 2016 12:47:54 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Sat, 23 Apr 2016 12:47:54 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> Date: Sat, 23 Apr 2016 13:47:54 -0600 X-Google-Sender-Auth: ggu8TRC01iL-zUiftfTFfSFBE1g Message-ID: Subject: Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8)) From: Warner Losh To: Daniel Eischen Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 19:47:55 -0000 On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen wrote: > [CC trimmed] > > On Fri, 22 Apr 2016, Warner Losh wrote: > >> >> I personally will be refraining from engaging further. I plan on seeing >> what gaps there are by adding support to NanoBSD for packages. I'll be >> busy >> with that. In talking to Glen and others, we've already identified a few >> easy gaps to fill. Once they've done that, I'll get going on NanoBSD with >> the goal to be able to use it to build a bootable system of any >> architecture from packages with no root privs. I expect to find issues, >> but >> I don't expect to find any issue that's intractable. I expect after the >> issues are resolved, the end product will be better for everybody. >> > > Thank you for working on NanoBSD. Do you think it would be possible > to add support for optionally building dump(8) images instead of dd? What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? Warner From owner-freebsd-current@freebsd.org Sat Apr 23 20:31:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43FB0B1A412 for ; Sat, 23 Apr 2016 20:31:06 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 085D11001 for ; Sat, 23 Apr 2016 20:31:05 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id B72241EDCB; Sat, 23 Apr 2016 23:31:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Sat, 23 Apr 2016 23:31:19 +0300 From: dan_partelly To: Warner Losh Cc: Lyndon Nerenberg , Matthew Grooms , FreeBSD Current Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <9BA8C798-C87D-4CA8-9AB3-CEC309AB81A5@rdsor.ro> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 20:31:06 -0000 This was all it was asked. Thanks. > Im saying that feedback has been heard and understood and providing more > now while things are in flux to try to address those issues is not likely > to be fruitful. > Warner > > Links: > ------ > [1] mailto:dan_partelly@rdsor.ro