From nobody Sun Oct 22 04:21:33 2023 X-Original-To: freebsd-arm@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 4SClX02Zxzz4y2Bj for ; Sun, 22 Oct 2023 04:21:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4SClWz6xtdz4Rvb for ; Sun, 22 Oct 2023 04:21:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697948508; bh=yFyOB7Kd+/DzUK3FWZWvVPynzxi0Z5FDNUB0gBQUeCU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OWxO4S8qF//JnX5z5gf8aFoI49GQURBW/6wpGUJe4NpDm0FWBOjtJhBBoYfsVYWMLSPjxPEja7jKJo6ZaVCI+a/v68ew33/lpFM2L1hAh0+PTYKaomitzMIAwQs9h/hC/137+VVsqhcssZTmRYj38CXrtTmy5/mDivOwpCbE6sWz7Lnjnt5ye+Z0aCfH759/XztkblCwuvdwer8QqmDVlAFKRbMYMKVeBzsRhRODxgCFmU0006s/W/RX38JGDfgQNhvnLbRqSRgAAnRYKfLV8TujHOIYjdCnfqVMhA14euEvE1XT6POAY/9zCVcxdM7C5KH0bQhL5BebQBPrrR/H0w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697948508; bh=hLKtv8Dk0RarT2/WTBRNZBXEFYrP32tWqiau6jAASlz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EIcJ5mLOODITzFHC5u1mthKz/Evu24w8U7aZonpWypFxzm9YjVeRXUSFYJVSKaTCrZ1r1B9Ytu1mMZaZtqps9Meq1h1+yRGC/Mhlb/pHbwhKMwJUyqc+Ide1JP7i9hgpN/wQ0ybtD0pjzu7suLQWReKqBIzoPFU50IuhwAdOuRmOX8Yan4Nix8wLB98p3QS8Rbu1ab15ElPPRhleuM3VD2dkStjw34wVF51ibY7UDywC/aLi4FL+tcHmcZjTLULQ1ya3OlIoYl5nsKoHIq0AqHvrBckCSoqWq1PIti5TQs/jIQ6KmZtvkFZR8p3kceeb2BUUuzkkEDoUmOLPmZKolw== X-YMail-OSG: pcDhUX0VM1mS_zU6q15ahlcmbqz7zk5WgdXwKQPCOvvFwms7XbCPF.EfTJjXhp. 0QbHXIWxiJtd2Svdn.Ms2dhUpvNGx5yNvpBivm_A5NKK8tTJJe5lZhRoY9SVXkULaLhFg.mjFYD_ irzUu6m3uYtB6GLfuhw9WWmrIcI36mqQ4z4pR8nWEwSX8TNK2HaEZPYWY32pcCKQyZNUwVedHYNO pFThMjVqrxSbejF4zjlFTtp8H4DDdnOsQbqrpJQFOE3wCiIjQCgkPd59HZj2rxxqbtJaNomIlbvj Kkms2h5R5MaMibggbXWM4z9YqHqxAYgY4ba8FA4InbCiJDaD1yGCV_SwbyLkLjYasfl9pzXuJ6Cj 9J8F4fFinpMJTbbc8gQR1oAQrqPRFEj5o6LvN6G0yWYaXyjtNTGZgNTbc_YTgV9MYENOJWd1WVrg bCYKtBsSjLdZbu69nczz7Zu_4SrZSuWn6SMwlJRx8Rks6NciKlD5JuaHWnJKNIU5s0MjnGgq3hI3 wZa4FOtzY6GYK8P7MsFK4dOhbnVf39i.9ldrqWqbp.zYPv7BbdxmEUlLNJJuVJnN1KRO_EaX8v7V HaeoIgLrRnMagB7_QoGWVWZ7Kd7BRlwyJRVI9YLQKJ_KjapoNv5EHrrY9159xLGzHh.7o1sAPBo9 5CrdsExZwUfsZNXMjJPJcxeNKIKLLh9QVzkDVAnb5JTRZwOxbvjOuud6IoFkA73WIuY3XNXpBWeZ 8kiVCHobbtpGldVXtDOkrVYXSySEZC42Iyr3Indemqxwh50cXawI3veu7w9vORej6mQ8V0CSMqKe caEh4Z9Sb34Qqr0Jpktr5go9fy_j21kpUcEl9OVc9n.GtNgXT7xb6OMuWcNSREWfkmzHOFR38AyC q7z4zAkZKrr9gAVfOtyrfcYKLgV5beXAn1bdZuwkEV5OdNXQg3VZik_4FacLdoJbSJxlYhsg_li. TIRRhHshYkr5WtQgZ5_pvTqsO1cA58n8Ws6W.kaYyG5QaSSTwJmA0151VlF2dfMjbkxRbHfN1qNY 5b6MijGnYdgJ.KtaLmLKRRguLcjoTvjLBSOVgPdeo7dXlnagBXsLFyYmcY0T8_eGON0qMzppN8T8 xsjDWeeS350usMb0dc8Mc7fetDxhqJo.NlCkUZX2jrEDaRmCrU0ETvsTFWCf8Kr44mS4JLW7Kbsd ws1QARbqZSzLhUm7Tkoadv0hhQzhFYr4DDXcFH70A425q0W2HtEUvy1gUdYSY7n8G98n61M0mOzd MOM2JmzIGWqFo4lfr6aj1.eWzSwo59UadK3eMnRZX6xat8IEk4fEm.A6Kg.M_qCCe0akVLp9s4hX KtWQR7_XmGldWfTk7A9l8DnSih3bsCTrTSifBzwYvztLTXss8BhlCBlyCwMsLIHyg70ayoshnQ7y kKuHji1lbr1JDDTqim6v.mU.f5DB1N_6rL2tSLEZ1xVpP9BBJcVYD8sC9V9smBKUdX7904url.Oi 2fWu8yrovbNQUVhvcSTRRMrroLa0JNlZqRBq4sKThX6DmgpYMlsOnulEFkdFQBRo54R47vbsbbVC xyBNfzpbGqHD2bAgbLbbd2NLN4qLDVH_6ZLFwfjqdyZAitvBs94MkVP5_YVoVJNU_DyGUSbTWdsV 1NH.PQxHA5UHPSa6NYF04bfMEpSyjHN.EBz.hRZYTjkkdZ1DZdXvjb4KMbJHYFRvcKtmBVfRLVdB PnR9_4VV6Svb3LjEty3WYhVk_ISMJKZlExlyIB4bklDeWvPQS5MlXVDabo5EwyGX64jy9LV5QhUq MYww9eySH66B14wGvzaiA0K9botbnfroKzitvZ6pVFHv1DZK_l5BUIl18ZLoM1JA5LC.dpYN3bbl bxsQ1a2zHSMccFzEcnaaRFHyOYaI9vektIPgxcw2UecOnzZuuD2TD.PZKUZYI4Kze7EqAuYAqPy4 JsyGT630z.DdGHSNSk0AX6dlqkwDju2MJlK5Wfua5BQAMaz.bdeefKmE2u4XeQNGszxCtnbZug0K nm9GXawjV9c1Q42Ew9MLssgB0v_7vGBQRUfLPfYg8xGkeSFGQSZWjEFuKiVK6XRODaTEN8k24pIZ 8qZGc3Eo13TnfCtlgdxDJDdJbDuOY9L9RSekXCJxVzIVhHgbG2_28hBJlTlrvBS4XqiQ.XBb.ry2 8Cr7qkYTRwwnepCNn24CoP7qsbv1h6et5.CMZQrx22a0SnFRf63qbNdULqK0SmCETonpvlXTIXkV jVaTPWPYNljciKw5aB9eYivtkCx0BHbMmp3alCfzEAgyYLLIfFGus6d.WbiX5zqwDtOiMv84_ScW zuKc- X-Sonic-MF: X-Sonic-ID: 0ec8e152-b18a-4c4c-9cd3-530eb8272bd2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Oct 2023 04:21:48 +0000 Received: by hermes--production-gq1-59f5fd4df5-5sz25 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1f11661efbb60793d5cc2f9b1afa16e7; Sun, 22 Oct 2023 04:21:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Re: rust 1.72.0 in poudriere-devel keeps getting rebuilt From: Mark Millard In-Reply-To: Date: Sat, 21 Oct 2023 21:21:33 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <42EF6FE9-AF6B-46A1-A4EF-86A1EC74DABF@yahoo.com> References: <057159E4-7E05-49A3-8520-3E2815C4A6A0@yahoo.com> To: void X-Mailer: Apple Mail (2.3774.100.2.1.4) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4SClWz6xtdz4Rvb On Oct 21, 2023, at 19:04, void wrote: > > Hello, Hello. > On Sat, 21 Oct 2023, at 23:45, Mark Millard wrote: > >> "... add the precompiled package so poudriere will use it to compile >> packages": So you want a rust to be used that does not track the >> actual ports tree being built: allow the rust used to be out of sync >> with the ports source tree for rust's dependencies, despite that the >> rust version number does not indicate that full ports-source context. >> I'll note that this specific wording is not explicitly asking that >> an updated rust not be built at all. The difference between what is >> installed/used vs. what is built is being mixed in an unclear manor >> for the specific wording. Looks like you actually have a 2 component >> request overall: >> >> A) use of a prebuilt rust >> and at the same time: >> B) lack of doing any build of rust in the bulk run (even if the build >> is not used: otherwise the time would not be avoided) > > I need to say at the start that although I've done *some* testing of the > situation, I've not done *comprehensive* testing. > > I'd like poudriere to download pre-built rust and whatever else rust > needs if poudriere is told to compile ports that require rust, ultimately > incorporating the rust package into the poudriere pkg collection. poudriere's purpose is to build packages based strictly on the dependencies in the ports tree it is working with (plus the options specifications), no deviations. This involves each builder being a clean environment that does not use ports or packages that might be inconsistent with that. (The means of controlling what the rust package is based on is controlling the ports tree content [and options].) > poudriere is not setting any make options for the build outside what > would be there by default. > > I can understand rust needing compiling by poudriere locally, if options > for rust itself have been changed in the local ports tree which deviate > from the default. Or if rust itself has a version change. > That isn't the case here. You have not reported examples of what poudriere reports about why it deletes the pre-existing rust build at various examples, such as: [00:00:10] Deleting rust-1.72.0.pkg: missing dependency: curl-8.3.0_1 or why you think such a delete that it reports should not be necessary at the time. Similar wording applies relative to it not downloading a rust that was based on curl 8.3.0_1 when the prots tree has curl 8.4.0 instead --but there is no messaging about why the download was skipped as far as a know. In some ways that is too bad because skipping a download is analogous to doing the delete of a prior local build. (As stands, rust built based on curl 8.4.0 that was in the ports tree did not exist to download at the time for the above.) For poudriere's purposes that it is designed for, asking for it to ignore the dependencies is a big ask. (So there is no grand scale, detailed control over ways of avoiding tracking dependencies.) > It seems that every time poudriere runs, because the ports list has > some programs requiring rust, the rust pkg gets rebuilt. Ports that use rust (to build or run) are why rust is needed at all but not why rust ends up being rebuilt instead of used as-is/as-available-for-download (given the "needed at all status). Why rust ends up being rebuilt is because some dependency that rust has does not match the ports tree (or options). For example, the downloadable package being still based on use of an older curl than is in the ports tree in my example. There is a time delay between the ports tree update and a matching rust build being available for download. During that time no download matching the ports tree is available. > Same version > as on the pkg servers. The same rust version number does not imply that the older rust build is consistent with the ports tree that is being used in the new build. rust (or other ports') version numbers to not carry that much context information. > I can't understand at the moment why the poudriere download-then-use > works for a thing requiring gcc12 but not rust. All it takes is for rust to depend on 1 or more ports that change more often than any port that gcc12 depends on. There may also/instead be a difference in how often rust is directly updated vs. how often gcc12 is directly updated. Please report historical examples of what poudriere is telling you about that, such as: [00:00:10] Deleting rust-1.72.0.pkg: missing dependency: curl-8.3.0_1 This is the way of figuring out what leads to the updates the most often. It might lead to suggestions for the rust port for avoiding depending on things that change more frequently if there are reasonable alternatives. > The longhand way of doing this without poudriere would be to install > rust from the pkg.freebsd.org using pkg and then make install the port > requiring rust from the ports tree. The last system I tried this on, > the installed rust was used. Why not with poudriere? Because the purpose of poudriere is to not do live updates with live system materials that can-be/do-end-up inconsistent as they are incrementally updated mid the overall build process. poudriere's purpose is to be noticeably more reliable even if it takes extra elapsed time or extra power, and so on. Its criteria are tied to what is good for the official build servers' reliability. This is what gets into the clean environment and the strict dependency tracking as criteria. The ports tree also has tools based on live-system-updates as port builds happen and many folks prefer to use one of those. I have used such in the past. I prefer the poudriere builds despite the time/resource tradeoffs. I've never gotten into the type of nasty problems that I on occasion got into before my poudriere use. I do not claim people should use poudriere. But I have helped someone recover from "live build" related problems repeatedly and ended up recommending that they use poudriere and helped them get started experimenting with it. (I historically have used some platforms that ports-mgmt/synth did not support so I've not experimented with that context in any significant manor: I prefer to stick with a uniform tool set across platforms.) === Mark Millard marklmi at yahoo.com