From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build) Date: Tue, 26 Feb 2019 23:29:35 -0800 Message-ID: <874l8pu1sw.fsf@gmail.com> References: <87pnrm76ta.fsf@roquette.mug.biscuolo.net> <20190220214442.GA22965@jasmine.lan> <871s416umx.fsf@roquette.mug.biscuolo.net> <87ef80trpm.fsf@gmail.com> <87a7ik57xs.fsf@roquette.mug.biscuolo.net> <874l8s2ek0.fsf@elephly.net> <8736oc2ebh.fsf@elephly.net> <877edn6hrs.fsf@roquette.mug.biscuolo.net> <87zhqj29ak.fsf@elephly.net> <8736obkhfs.fsf@gnu.org> <87woln27hb.fsf@elephly.net> <87y3634zaa.fsf@roquette.mug.biscuolo.net> <87zhqj81uj.fsf@gmail.com> <87imx651y5.fsf@roquette.mug.biscuolo.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:48506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gytfE-0004Kw-4X for guix-devel@gnu.org; Wed, 27 Feb 2019 02:30:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gytfA-0006Bf-47 for guix-devel@gnu.org; Wed, 27 Feb 2019 02:29:58 -0500 In-Reply-To: <87imx651y5.fsf@roquette.mug.biscuolo.net> (Giovanni Biscuolo's message of "Tue, 26 Feb 2019 10:33:22 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Giovanni Biscuolo Cc: guix-devel@gnu.org, Mathieu Lirzin --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Giovanni, Giovanni Biscuolo writes: > AFAIU the issue is "guix weather" reporting on the availability related > to current master and not of user commit: am I wrong? I'm not sure. That would explain the issue you saw. I haven't checked the code. Maybe you could take a peek? If "guix weather" is using master branch and ignoring the current channel configuration, it seems like it might be unintended behavior. > a little (digression > > anyway even if that is not the issue, users should have some way to > check if a substitute is available for their current commit, so they > can decide if they are willing to locally build or not. >=20=20=20=20=20 > also, it would be useful if "guix package -i/-u" allowed users to > choose to fail (via a flag or a CLI prompt) in case a substitute is > not available; AFAIU "Substitution failure" [1] works when a > substitute *is available* but download fails (and we have "--fallback" > just in case), but there is non way to fail in case substitute in not > available. >=20=20=20=20=20 > in my specific case with ungoogled-chromium, it took about 8 hours on > a 8 cores + 16GB RAM machine (although heavily used) to reach 75% of > the build process... and finally I had to cancel the build since the > machine load reached 40 (since other "heavy" processes started via > cronjobs).) I agree it would be nice if one could control the behavior more easily. However, someone needs to put in the time to design and implement the solution. So far, I think people with time and energy have chosen instead to focus on improving substitute availability, in the hopes that it will prove more useful in the long term. Would you be interesting in working on it? I have sometimes wanted a feature like that, but I do believe substitute availability will help more in the long term. > I posted them yesterday in this thread; they are: > > .ungoogled-chromium.manifest: > > (specifications->manifest > '("ungoogled-chromium")) > > $ guix describe > Generation 3 Feb 19 2019 19:35:54 (current) > guix a4fc802 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: a4fc80254a53b46b33f138d1009ddd044b8cb6be Excellent - thank you. I think I missed this in your emails earlier. I have attempted to reproduce the issue using that information. When I ran "guix pull" to use the same version of Guix you were using (a4fc80254a53b46b33f138d1009ddd044b8cb6be) and then ran "guix weather", I saw the same output as you (i.e., ci.guix.info reported that the substitute was available). However, when I ran... guix package \ --substitute-urls=3Dhttps://ci.guix.info \ -p /tmp/test-profile \ -m /tmp/manifest.scm ...Guix began downloading chromium from ci.guix.info. The contents of /tmp/manifest.scm is the same manifest you provided. So, unfortunately this means I wasn't able to reproduce the issue you experienced. Everything seems to be working correctly on my end. I'm afraid I'm out of time at the moment - I have to go. But if you could the check "guix weather" source code to find out if it respects the current channels, that would be great. I'll try to get around to it if you don't beat me to it. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlx2PF8ACgkQ3UCaFdgi Rp3ZkBAA2SsJQZuxpU/hbFSIEfSm2HUob13rL4uiJUUapx1T03os7Bv5w4SEEeBT WgOvlVUk7jzNGu8I521MggtKoMEzcB+bbLEj/sCVhGq8VHhibDl4nmTZg3llA+z+ c9s0eH8rOEbHxilSkA0sXnqkTNOMRdiCTOGFtSb+5Fejro244vHiAiedauGO2PMy nakkvple70O33YYYfC2ClVQxid3hjoxOWuFnowU0jmQe6eYlSp19YqGAEHflKVQf ZpCZkBFuoeskfPyQX47J8V0Zxk5yPWy9hQPQSneUwQJYzgBeT3sDUJapuhLHFVt/ KfqOV8RT/Jc+nSFHlYGmvHaxQ3m6NJ/eEM2ntJsmX1sZjSqhSL/yiDdQrcL1UsbV 2ccTFZq5PAR6Y9909LA0y8K/nZGvpbtlwuGSm7ubvi5YNS5Se/ghDp4szSob0yhj pyiEawKxQaMr2BWk0clBjLGE0fq4t0C+FQvAGwjaw37xaEgZhgAK8SCXay6OD/S5 UqDyzSNz8om6RAXEzXz5iOF5c+woV/D1ws21GczoS1wKNwNNB8R+MP489eRE2G7N 5cczQC/MhSRoIVdtWKklfE+sIgxx/gm7M+M0pCqChg+iTbGfHdNCgSeOynZB9g9t tTH54wu1lvBLdeNHXFfklXZlmOaM8jBCE+CXSfi3qYD4cqg8oUU= =qTqH -----END PGP SIGNATURE----- --=-=-=--