From nobody Mon Nov 15 01:57:23 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D8BB184CC6C for ; Mon, 15 Nov 2021 01:57:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4HsslN2pn4z586F for ; Mon, 15 Nov 2021 01:57:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636941449; bh=DT4M08usTEA/B8HZeygPrbB+zZhk9zXY/60cYo/6Zuk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=aQOjd9UhZj+MzQGodhAYluggO9d8cqpMImGqXW0Lz4+8LQVpdCtJ0G7QLQsRDi/ZbsVQc2xRn9hJvI4XyJe9Zy1V0nYmkSr3sqaBSA1e+sF7iOTe12cOOTmL643z/lh3+LCE6nupo+atfSzABnrYxtLZ4FOWKRLWQisubcFOyifkn93ruHrZK2CreKa6RUBsfZSD5RXnbNUtUv6+LZ2TI0HPD4g5QZn5T6suLLvqIQXxao7rX+FWNbiyWzFV7B4MG1j3MHqmi9I2+A+s367evxQLoVOPycy4RKEFG2k0IP6OLVeiYIAVjeGvU0d2UqBLwvRbJ7lG41bpag3hD3RL0A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636941449; bh=+E/EfFUOdfZ87ZSAEzhKZoC8dv3qSXgPxEQjpZ+BT6O=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=AWjdea7j3fvmeQTTqJn67Pj6h+5E0HUwZoZGUqL02hMj6LrQm0NRppKp1vmzo/vWvay4iffxOKqM6SCQFzTKEFIosoSc1tc5VN1RcR3dnw9b6Ktieks9fyqyefiLSbMw03Cu8YiTkP9kS9lpqfSp5NcK9zgHBNH4yQ3LW3XoQxcyRTjXjX52qr/wtUqhN5NaYBovduMsGunk4n+ENvuAVdFHclWnemR3VvccOK4Z5i1rCeRVrk9c6KBXdBYsQ5jP7olr860OTlBFEzLuMO5BNBvi+xXUx9hM2lNSJfd+Uo9Lsm/i/HFc0kiYfhBYp/ptUEmjEIQIuWNJxnPO14WriQ== X-YMail-OSG: u5IA.8kVM1mgPJkQxcrlmPkoqPDMSP1myVEODuk6su75INK6R5ijs_C2xC71Wue ZbflIt8V7Wl3ZyzISgBht1MsVpsUUopFJR9OO38FBU9jhKO.deD2DSCVzx6OSkrhj.4CMcvcFmaQ fyfJvEApI769o9QU.ZcNocN3cQKC.iShU7KTq5okEhsJEDarud_m.N.LT2zpzkmN7c84q6MdGaIK AqhG5VLgQmg6WdM9Vl4Io2salX_P5y7lZW4JzGC7yMZdTa7nbMJfng.xW_kRahJjwI6Daz4deiJa .q5yKnlZBgztI9EW6tKGmQL9bOoCtrTdh8rxi12sM.1ARfA0LxE7.QkL9zEnX7pUaJV0dWwsozv. j7baMfNM5iRRA.yVA_O7emBtmNgb_HcFk5LqWjK1VRvsOEgEmOQvvWzpKgSBUeXzAC2JoJYN6YO1 LoRaVL3WWBxYPDPFbNHWGFvhvzZS3Wf1DMTCJD8Kgct.ynF0WtdtzzZ_L3vC.2sAgndfgUf7I7YL LNkQIRiShcdKImyu3j3YASg9rf.HyDVk6iTZtRT0aW_84Mqh7cym1jGA0wirxhFudOoKagu.CPlv KFk2xTN_RLEEOiCjLNlTxc_clsecZrC.iEn70IoMw4EotNVjthX74GEuYsDAvisNBYTgJvdxkA0i LEUYhkahR1CTPRQB.pJjhW0aKKkiBqI6x3kN5GSwjH9TFs_D1w810HBZIlbSzfOTd8viUVhuTSYU iYwH0dLfqwNOix3Xnbf7018HsyS8mDFO7LKJHT7IJ5sp9_wG11Qz_Qh9AYejkU7bTVzdUzRixO4y ZQ09etMQDpxbViV9i5F2DRbpxA73H.FUoTlZ4k4_Rbo7c1FBrUl3Xa8jAI.1EFg7EsSN6oh7OIEg V6PI5Eg9PtohTLZtWI6Ln1lGko1iNwhDEir1uoVqBEtg.6xPtufI4XXau7585SSUZJP8sfbJA_wF wIwMkGHsVRO4dJDQjhf4OtgCir6CRkr2Vbppghsg5c2mwS9vMCnzAMzPot5K26kHjHy6I70wzIZF ro7OUBbBMsXyMyZiQDPDY674xa7TQ9etDsoILBlo5BHYkW4BYZu1tot2MHi8.rSS8jcdjIcJ3V5I dYRipjXni9hGcXme_yromVs21Jll5NxKMUWE3rJ9okwsuYuvUME8NrhrtowNVElBIohs9.qAf02A 092rg2E0B4UhrNJtODBR0AHitwPos0CQB2tty.rHx1mXiFwHfNwhXQdTsde0a0hXxul1o6ZWroF7 L64lS7wbhg5OAmbn94EiSsMH.SzJt70rYWUOcG7Pzp3wVKEASEtNmp2kO6Lf1E0nSDYygeHD8XOX dkxgscuGw4nPA6RVAyoMsa58Hq11jEPYLqR94DWHJwPoa_hEifLctqQczVr83bclCLujhhc9iyiN 2arOjS7j37oQobHaHOz6axB5tBQpI8w0bcmyUJKsdI2bUCSGU3mD0xNPG5fEIntKdBFIa8_h1Q6m 8inetEtRuOT3a6IgoEk1wBNVh96FZym4iZ7llBdHZcuPPLabIMz2ZeviFYVPXiX6Punmcq96bAO1 9KuBJbc.YLh9cMrIG10jS7xx5s_iz22.Jj53WmPuyjb.ZG5TsLHkkeFyGoRfraUmO6rwAcspYE5A oTRimH4s6nFSDW1HcPSfaCMXOyjoE6SnF_FSrlbmDm4NP2snrVFBziT9l5izHE0B2JuB2DcnUZii kSHWztYf_SCEl8Bnkerlc_z55eNOGV1BUaLV6J.4kD5tS2QToaCmnqJ1Lsvh4zlY2_q3tR0UGp6B P.dI5M7_mER1MDJjM_MPkjMfDiuDDye5a5S8JTXhGRhesct5pDUttEliL69IhkQ7FjLtgwxJo6HO jige_9IZEDPVJa5ZDXqomKQipuXM4jaCaF0fTo5jIeByoc_LesalC58OvwVS94mvhbv4n4SW86kO xji7Qzjz_rdohGKoHroYk1WKAdMbVfokT2Q3.pJUp97TXlS7I1bI2APdFOFLBkoFWrt5EFJg1TIh TEsz5SB.Ag5.1AjFUWH9EWlC1X8q0srgvXM22OHQbSx54jS5qvB9nUXwztfRyKDwn6Lk2EYok0BR flbqPZbUG54wymeGpRQV9mtKM_IXp1s3YzSF3AR5f1gyy8N3ipD_mNY21wI79OCJPQkVtQhtpP5c Vy1mw8zQJ31L6JkdU3nZd7kljA3M_JFlIOg5hvv5yYSy1R4D1xrLwqXWeWvDJUAdUnr1sotmiqRy LNHwNqcJfrPHowtDlmvXw_DR2kDxk5YmFgKOw5yazzuife9OM3XHUvpvzOnh_XFohobELzU9ozYq J1Hx5VIZOykA0l8qrK4MHDgE4Bwbc1gbsmA46D.c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 01:57:29 +0000 Received: by kubenode538.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b0e3868ec0a0eae78e9191fa07892cc5; Mon, 15 Nov 2021 01:57:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: automake config failure for autoconf test failure (poudriere based build activity) Message-Id: <9CAF2D2A-6C52-4584-AA63-C42B7921BF43@yahoo.com> Date: Sun, 14 Nov 2021 17:57:23 -0800 To: "tijl@freebsd.org" , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <9CAF2D2A-6C52-4584-AA63-C42B7921BF43.ref@yahoo.com> X-Rspamd-Queue-Id: 4HsslN2pn4z586F X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aQOjd9Uh; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N poudriere output: [00:24:23] [09] [00:01:20] Saved devel/automake | automake-1.16.4 wrkdir = to: = /usr/local/poudriere/data/wrkdirs/13_0R-CA72-default/default/automake-1.16= .4.tbz [00:24:23] [09] [00:01:20] Finished devel/automake | automake-1.16.4: = Failed: configure . . . logs/errors/automake-1.16.4.log : . . . checking whether autoconf is installed... yes checking whether autoconf works... no configure: error: The installed version of autoconf does not work. Please check config.log for error messages before this one. =3D=3D=3D> Script "configure" failed unexpectedly. Please report the problem to tijl@FreeBSD.org [maintainer] and attach = the "/wrkdirs/usr/ports/devel/automake/work/automake-1.16.4/config.log" = including the output of the failure of your make command. Also, it might be a good = idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make: stopped in /usr/ports/devel/automake =3D>> Cleaning up wrkdir =3D=3D=3D> Cleaning for automake-1.16.4 build of devel/automake | automake-1.16.4 ended at Sun Nov 14 17:01:21 = PST 2021 build time: 00:01:09 !!! build failure encountered !!! work/automake-1.16.4/config.log : . . . configure:3650: checking whether autoconf is installed configure:3656: autoconf --version autoconf (GNU Autoconf) 2.69 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+/Autoconf: GNU GPL version 3 or later , = This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. configure:3659: $? =3D 0 configure:3667: result: yes configure:3674: checking whether autoconf works configure:3684: cd conftest && autoconf -o /dev/null conftest.ac gm4:/usr/local/share/autoconf-2.69/autoconf/autoconf.m4f:1: expecting = character `V' in frozen file autom4te-2.69: /usr/local/bin/gm4 failed with exit status: 1 configure:3687: $? =3D 1 configure:3696: result: no configure:3700: error: The installed version of autoconf does not work. Please check config.log for error messages before this one. . . . For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 # cd /usr/ports/ # ~/fbsd-based-on-what-commit.sh=20 branch: main merge-base: 057c0c3c0645c0b237bb2a96dda440e0426ca983 merge-base: CommitDate: 2021-11-14 23:41:22 +0000 057c0c3c0645 (HEAD -> main, freebsd/main, freebsd/HEAD) [NEW] = security/snowflake-tor: Pluggable Transport using WebRTC inspired by = Flashproxy n566061 (--first-parent --count for merge-base) Note(s): My amd64 FreeBSD context using the same sources (by content) did not have this problem. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 08:42:16 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3A4FF185B7BC for ; Mon, 15 Nov 2021 08:42:02 +0000 (UTC) (envelope-from freebsd@ohreally.nl) Received: from rambler.ohreally.nl (rambler.ohreally.nl [51.15.8.63]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ht2k20Wqcz3C7C; Mon, 15 Nov 2021 08:42:01 +0000 (UTC) (envelope-from freebsd@ohreally.nl) Received: from authenticated-user by rambler.ohreally.nl (Postfix) with ESMTPSA id 04EE11D77A90; Mon, 15 Nov 2021 09:41:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ohreally.nl; s=dkim; t=1636965720; r=y; bh=R95i46oSoK0w08Ez+T+wvzO1PJaw8xCVEGrHK9W18vc=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=e1D90jdj9X7FCfNhOxYgK3+e2nzT5tY60lCkMrDwe6hhZhGK1yGx8Vf7lxF/X4lPh p40VZ6arF3Lxf35oegjmWetH+wYOjp6bF0v60q02rVyQBWnS9FqOMEjkrtsFlOUw2R 2lEVCvdGsEPfmO5S/H/EJv1bYjcq8tWgjG3g/22s= Message-ID: <455ffbd8-2406-7c75-718c-759da5bab52c@ohreally.nl> Date: Mon, 15 Nov 2021 09:42:16 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Subject: Re: Adding functionality to a port Content-Language: en-US To: Guido Falsi , Kurt Jaeger Cc: "freebsd-ports@FreeBSD.org" References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <480b44f5-0674-e645-8413-a1a368cfc393@ohreally.nl> From: Rob LA LAU In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.104.0 at rambler.ohreally.nl X-Virus-Status: Clean X-Rspamd-Queue-Id: 4Ht2k20Wqcz3C7C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, On 14/11/2021 20:49, Guido Falsi wrote: > You talk about "adding a periodic script". That is not even a real > modification to the upstream software IMHO. Just adding some glue code > for FreeBSD. If the script does what it advertises, and has no malicious > intent I see nothing wrong with it. If it is broken fixing it is the > logical thing to do. Imagine a daemon, an rc script and a periodic script. And imagine that we decided to separate all 3 into separate ports. When fitting these ports into the ports tree, we would make the daemon depend on the rc script, because the daemon needs the rc script to start and stop (and starting and stopping could be considered core functionality). But we would make the periodic script depend on the daemon, because the daemon runs fine without the periodic script, but the periodic script is useless without the daemon. To me this would mean that the daemon and the rc script should be published together as a single port, making the rc script an acceptable FreeBSD-specific addition. (Which does not mean that the addition should not be reported to upstream; the goal should also be to have the rc script included in the upstream project, just like the systemd unit that is already included.) The periodic script, however, should be considered new functionality, and published in a separate port. And to contradict the above, one could now plead that external libraries that the daemon depends on should also be packaged together with the daemon, but the difference obviously is that no other package will ever depend on the daemon's rc script, while those libraries have been created to allow multiple applications to use them. And there will always be exceptions. Things are not always black and white, and they shouldn't be. And obviously, I'm the outsider here. I'm not trying to tell anyone what to do and how to do it. I'm just making sure that this subject has not been overlooked. > Being a son of two lawyers, and having a lot of friends who are lawyers, > and also clients who are law firms, my informed (by having had a lot of > arguments with all these people about this very subject) opinion is that > there is no such thing in the world as a "clear and simple" set of rules. Nobody is trying to write a legal document here. The goal is just to assure that the ports in the ports collection still function as intended by the upstream developers, preferably with no functionality removed, and definitely with no functionality added. Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/ https://github.com/ohreally/ From nobody Mon Nov 15 09:21:46 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E8EAD1854673 for ; Mon, 15 Nov 2021 09:21:48 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ht3bw6CbKz3PnL; Mon, 15 Nov 2021 09:21:48 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from [172.24.42.13] (host-79-51-17-182.retail.telecomitalia.it [79.51.17.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 518CC22C80; Mon, 15 Nov 2021 09:21:48 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <0415769b-ac3d-86d0-54c4-1f0a74db0b13@FreeBSD.org> Date: Mon, 15 Nov 2021 10:21:46 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Adding functionality to a port Content-Language: en-US To: Rob LA LAU , Kurt Jaeger Cc: "freebsd-ports@FreeBSD.org" References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <480b44f5-0674-e645-8413-a1a368cfc393@ohreally.nl> <455ffbd8-2406-7c75-718c-759da5bab52c@ohreally.nl> From: Guido Falsi In-Reply-To: <455ffbd8-2406-7c75-718c-759da5bab52c@ohreally.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 15/11/21 09:42, Rob LA LAU wrote: > Hi, > > On 14/11/2021 20:49, Guido Falsi wrote: >> You talk about "adding a periodic script". That is not even a real >> modification to the upstream software IMHO. Just adding some glue code >> for FreeBSD. If the script does what it advertises, and has no >> malicious intent I see nothing wrong with it. If it is broken fixing >> it is the logical thing to do. > > Imagine a daemon, an rc script and a periodic script. > And imagine that we decided to separate all 3 into separate ports. > When fitting these ports into the ports tree, we would make the daemon > depend on the rc script, because the daemon needs the rc script to start > and stop (and starting and stopping could be considered core > functionality). > But we would make the periodic script depend on the daemon, because the > daemon runs fine without the periodic script, but the periodic script is > useless without the daemon. > To me this would mean that the daemon and the rc script should be > published together as a single port, making the rc script an acceptable > FreeBSD-specific addition. (Which does not mean that the addition should > not be reported to upstream; the goal should also be to have the rc > script included in the upstream project, just like the systemd unit that > is already included.) > The periodic script, however, should be considered new functionality, > and published in a separate port. > > And to contradict the above, one could now plead that external libraries > that the daemon depends on should also be packaged together with the > daemon, but the difference obviously is that no other package will ever > depend on the daemon's rc script, while those libraries have been > created to allow multiple applications to use them. > > And there will always be exceptions. Things are not always black and > white, and they shouldn't be. > > And obviously, I'm the outsider here. I'm not trying to tell anyone what > to do and how to do it. I'm just making sure that this subject has not > been overlooked. > I don't follow you. The example is too abstract for any useful purpose. You intentionally mix the concept of "depending on" with the concept of "packaging together". Even following your example all the practices you describe could be acceptable and at the same time debatable. The variety of software is too broad to create a strict rule set. Such matters need to be handled on a case by case basis anyway We do have some principles to guide us, which have been stated to you. One of these is classic POLA, for example. This gives us an idea. You have to consider how the original software is packaged upstream and usually packaged for other OSes. Considerable differences from the rest of the world best practices would be "astonishing". Also you have to consider upstream documentation. If that suggests doing things in a certain way and the port did things in a different way that would be astonishing too. In the end you also seem to forget or intentionally ignore that FreeBSD is also a community of developers and users. You do things the best you think, but it can happen that users or other developer will tell you you are wrong, maybe suggesting better solutions. Ideally this is done in a polite and constructive way; unluckily it sometimes gets aggressive and unpleasant, and this is definitely something we should avoid. You can then modify your work and make it better based on this feedback., No technical choice is set in stone. >> Being a son of two lawyers, and having a lot of friends who are >> lawyers, and also clients who are law firms, my informed (by having >> had a lot of arguments with all these people about this very subject) >> opinion is that there is no such thing in the world as a "clear and >> simple" set of rules. > > Nobody is trying to write a legal document here. > The goal is just to assure that the ports in the ports collection still > function as intended by the upstream developers, preferably with no > functionality removed, and definitely with no functionality added. You look too worried by the "functionality added" part. If the added functionality is only a script needed for integration with the system it's not added, but something strictly needed by the porting effort. For example I maintain some ports (asterisk, ntopng) which are run as daemons. Upstream does provide startup scripts for linux, but none for FreeBSD. The ports contain startup script I made because they are needed for proper usage of the port. (and some bugs have happened in those scripts, I have fixed those to the best of my ability) Users are not force to use the startup script I (or upstream for that matter) provides. They are disabled by default. Nothing stops the users from writing their own rc scripts, or using a different method of starting them (cron @reboot or something like supervisor for example). Those scripts are "added" but not mandatory for anyone, they don't detract anything from the upstream software. I don't know which port periodic script you are talking about, but I guess it's not enabled by default, and in the unfortunate case the maintainer went out of his way to make it such, it should be possible to disable it, and then you can script your own or use something else for that part of the port. This for startup and rc scripts...other more convoluted cases require case by case analysis. A more general reply is impossible. -- Guido Falsi From nobody Mon Nov 15 11:01:57 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F020188B14D for ; Mon, 15 Nov 2021 11:02:07 +0000 (UTC) (envelope-from SRS0=cjAb=QC=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ht5qd6B3Zz4fmG for ; Mon, 15 Nov 2021 11:02:05 +0000 (UTC) (envelope-from SRS0=cjAb=QC=klop.ws=ronald-lists@realworks.nl) Date: Mon, 15 Nov 2021 12:01:57 +0100 (CET) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=klop.ws; s=rw1; t=1636974117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O1yOcS3S8mUQvV50TeP5CSY2RLV+QWL5V+uOGPqhS/Q=; b=whI1sG3qCExXkg9AaZBZr+PTz16Mmr2l5usfkhUTNyuNl+/U/Abe7eVTSQ9BfqCR6b8t2H NH5B8eqs52/QssAQ== To: freebsd-ports@freebsd.org Message-ID: <1027702627.3.1636974117639@mailrelay> In-Reply-To: <0730c6f7-ca23-d40f-c395-d20bc1be6816@ohreally.nl> References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <0730c6f7-ca23-d40f-c395-d20bc1be6816@ohreally.nl> Subject: Re: Adding functionality to a port List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2_194974015.1636974117624" X-Mailer: Realworks (585.1296.bdcec4b) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Ht5qd6B3Zz4fmG X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw1 header.b=whI1sG3q; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=cjAb=QC=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=cjAb=QC=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-1.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=cjAb=QC=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.109.157.24:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=cjAb=QC=klop.ws=ronald-lists@realworks.nl] Reply-To: ronald-lists@klop.ws From: Ronald Klop via freebsd-ports X-Original-From: Ronald Klop X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_2_194974015.1636974117624 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Rob LA LAU Datum: zondag, 14 november 2021 16:56 Aan: ronald-lists@klop.ws, freebsd-ports@freebsd.org Onderwerp: Re: Adding functionality to a port > > Thanks Ronald. But I'm not asking how or where to report bugs. > > Allow me to rephrase my question. > > If and when I am a FreeBSD port maintainer, can I just add any scripts or other files to the port I maintain if I think they may be practical, even if those files are not part of the upstream project? > Yes you can. But: 1. As a (starting) maintainer you can't commit the changes yourself. A committer will check and commit your changes. 2. All additions are open and verifiable. It is hard to sneak something into it. And even more to do that anonymously. There are probably some more checks and balances to this process. It has proven itself pretty solid. Regards, Ronald. > Thanks, > Rob > > > On 14/11/2021 16:40, Ronald Klop via freebsd-ports wrote: > > On Sun, 14 Nov 2021 16:26:23 +0100, Rob LA LAU wrote: > > > >> Hello list, > >> > >> I'm wondering what the rules/guidelines are for adding functionality >> to a port, that is not in the upstream package. I can't find anything >> about this in the porters' documentation. > >> > >> Background: > >> I'm not a porter myself (planning to be one, but that's irrelevant for >> my current question). > >> I ran into a buggy `periodic' script. And when looking for the port >> maintainer to report the bug, I found that this script is not part of >> the upstream package, but was added to the port by the port maintainer. > >> So I'm wondering now whether I should report the bug in the `periodic' >> script, or ask the maintainer to remove the script from the port (and >> maybe submit it as a separate port). > >> > >> And in more general it would be interesting to know when changes made >> to a port are considered too drastic, and when port maintainers should >> be asked to join the upstream development team instead of (or in >> addition to) maintaining the port. > >> > >> Thanks for any and all replies. > >> > >> Cheers, > >> Rob > > > > > > You can file a bug report on https://bugs.freebsd.org/ . If you use a > summary like 'www/firefox: Unable to use microphone with ALSA backend' > it is automatically assigned to the maintainer of the port. So ' portname>: short description of bug'. You can also upload a patch if you > have it. > > > > If a bug report is not possible you can also just mail the maintainer > and see what the reaction is. > > > > Regards, > > Ronald. > > > > -- > > https://www.librobert.net/ > https://www.ohreally.nl/category/nerd-stuff/ > ------=_Part_2_194974015.1636974117624-- From nobody Mon Nov 15 11:15:39 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 906611891561 for ; Mon, 15 Nov 2021 11:15:41 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ht67K3V6kz4kWr; Mon, 15 Nov 2021 11:15:41 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from [172.24.42.13] (host-79-51-17-182.retail.telecomitalia.it [79.51.17.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 002B32399B; Mon, 15 Nov 2021 11:15:40 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: Date: Mon, 15 Nov 2021 12:15:39 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Adding functionality to a port Content-Language: en-US To: ronald-lists@klop.ws, freebsd-ports@freebsd.org References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <0730c6f7-ca23-d40f-c395-d20bc1be6816@ohreally.nl> <1027702627.3.1636974117639@mailrelay> From: Guido Falsi In-Reply-To: <1027702627.3.1636974117639@mailrelay> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 15/11/21 12:01, Ronald Klop via freebsd-ports wrote: > > Van: Rob LA LAU > Datum: zondag, 14 november 2021 16:56 > Aan: ronald-lists@klop.ws, freebsd-ports@freebsd.org > Onderwerp: Re: Adding functionality to a port >> >> Thanks Ronald. But I'm not asking how or where to report bugs. >> >> Allow me to rephrase my question. >> >> If and when I am a FreeBSD port maintainer, can I just add any scripts >> or other files to the port I maintain if I think they may be >> practical, even if those files are not part of the upstream project? >> > > > Yes you can. But: > > 1. As a (starting) maintainer you can't commit the changes yourself. A > committer will check and commit your changes. > 2. All additions are open and verifiable. It is hard to sneak something > into it. And even more to do that anonymously. > > There are probably some more checks and balances to this process. It has > proven itself pretty solid. This all implies: 3) there is no shield from community verification, getting criticized in the mailing lists or bugs reports, and having to change your mind about your assumptions, revert things, discuss alternative solutions, etc. Hopefully this happens in a civil and constructive manner, but sadly sometimes things become "unpleasant" (please anyone avoid being the one bringing unpleasantness) -- Guido Falsi