From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:55436) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIkI8-0004I9-11 for guix-patches@gnu.org; Sun, 29 Mar 2020 22:36:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIkI6-00046d-NF for guix-patches@gnu.org; Sun, 29 Mar 2020 22:36:43 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:48680) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jIkI6-00045y-Ia for guix-patches@gnu.org; Sun, 29 Mar 2020 22:36:42 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jIkI6-0004mo-FH for guix-patches@gnu.org; Sun, 29 Mar 2020 22:36:42 -0400 Subject: [bug#40267] [PATCH 1/2] gnu: Add unicorn. Resent-Message-ID: Date: Sun, 29 Mar 2020 14:43:51 +0200 From: Jakub =?UTF-8?Q?K=C4=85dzio=C5=82ka?= Message-ID: <20200329124351.dckxah33q6ajb6z2@gravity> References: <20200328005052.22846-1-kuba@kadziolka.net> <20200329034811.GB16918@jasmine.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vzywwqkch572k4rq" Content-Disposition: inline In-Reply-To: <20200329034811.GB16918@jasmine.lan> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Leo Famulari Cc: 40267@debbugs.gnu.org --vzywwqkch572k4rq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2020 at 11:48:11PM -0400, Leo Famulari wrote: > On Sat, Mar 28, 2020 at 01:50:52AM +0100, Jakub K=C4=85dzio=C5=82ka wrote: > > If I package a -rc version, should it have a -next suffix in its name > > even though the "stable" version isn't packaged? >=20 > I think it's best to just call it unicorn. The version says -rc and we > mention it in the synopsis and description. And it's useful under the > hood for guix lint to match the upstream name. Fair enough. > > Maybe I should also package the non-rc unicorn? The test suite for that > > version fails to compile, so it's not entirely trivial. >=20 > Is the previous release useful? As far as I am aware, the non-rc release is not useful beyond avoiding any potential uneasyness about running -rc releases ;) > We normally don't package betas or > release candidates... it depends. Do you have an idea of the release > timeline? Sadly, I have no idea. > Do you think upstream would mind if we packaged the RC? I don't think so? As a datapoint, FreeBSD packages the -rc. > > + ;; NOTE: unicorn ships a bundled QEMU, but with custom modificatio= ns. >=20 > Can you add more detail to this comment? Is it just a patch on a QEMU > tarball or is this not really QEMU anymore? The documentation suggests the changes go quite deep: | Internally, Unicorn reuses the CPU emulation component of QEMU as its | core (with quite a lot of changes to adapt to our design). What do you think about a comment like this? ;; NOTE: unicorn ships a bundled QEMU, but heavily modified. > > + (add-after 'unpack 'install-bindings-to-python-output > > + (lambda* (#:key outputs #:allow-other-keys) > > + ;; python-build-system will build the bindings and instal= l them to > > + ;; the "out" output, so change the build-internal names o= f the > > + ;; outputs. > > + (set-car! (assoc "out" outputs) "lib") > > + (set-car! (assoc "python" outputs) "out") > > + #t)) >=20 > I would wait for advice here. The manual requests we write everything in > a functional style. But I don't know of another way to make > python-build-system install things to alternate outputs without changing > the build system or replacing the install phase. It would be nice to > have a parameter for this somewhere... Yeah, it's not the nicest thing. I think I'll submit a patch to c-u that would add such a parameter (does #:python-output sound good?), and then come back here when it lands. Would this imperative hack be ok as a temporary so= lution? > > + (add-before 'check 'check-library > > + (lambda* (#:key outputs #:allow-other-keys) > > + ;; TODO: running the tests on non-x86 requires a cross-bi= nutils > > + ;; with x86 as target. > > + ,@(if (member (%current-system) '("x86_64-linux" "i686-li= nux")) >=20 > I think the 'when' procedure is more clear than 'if' in cases where the > else branch is empty. The issue is that the else branch contains '(), and is not itself empty. Do you happen to know how to get the value of (%current-system) build-side? Thanks for your review! --vzywwqkch572k4rq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl6AmAEACgkQ4xWnWEYT FWSgFhAAyDaaXmj8Js9BvgjvinyLCQRrB0CVull04a2pIT7O527tsxxlUK3uRM0U WIbLEovk/5dkWILIOkDPKc5/rSQM7tO+xjya6fJCT5Y6i6M0plurrtUKrBnAOdUq EgvjWYfGeOOYnoM5+v86RMSdy/4fRe0pogSQ8hlhsQmfpA0d3m6FnWKExxp97ya+ /SdXp2SQcGV6zJAfa4s+PAqxrPJSEJqOdTS5yY9AGb17sSm/PmsGxaKhtnVtuRS9 Igr9VD4ljfuzRZx9qreg5nwxqZ0hwXqjRaiIPen/CHB+HSqs8p4eOvl9jHAC5XQt oVr0NdB3Fh3Z7jLNhWpWfYENzp72baQftMopXPTM7mBMje75x+bBzr6UZXshnRzU qFG3f+iW2PiAjPGKPrJnLNVJVP84IA09HTdRKxE/OhCwNQ8cMrK5+gCsPJZ4QSB+ +X0F6/QgCuJUcRE3nMz4vrArFw/t/KDGmBxGGEe6pN2yKZx3lC0Stk4W9L2blyrw 5IfEmkPq3pl1fDWLUKw+H2eriA9dHFaWKsl7nXGBtT7giylr0OVTNVzZp0M8AWcB DusOLuCogkKAvs5inBaP0InDttBYN2vZNW27Dbhqz2O4AFMx6p3GD4NxXecilGVQ 5ucITT19Nf/+Y5yXd8PShcIDwEnrJ43YAsUK6RJlySjwYGDfw9Y= =0iAC -----END PGP SIGNATURE----- --vzywwqkch572k4rq--