Content-Type: multipart/signed; boundary="Apple-Mail=_1197AEC6-4775-4585-B679-928F6B9E04AB"; protocol="application/pgp-signature"; micalg=pgp-sha384
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Building community/cargo, build-edge-x86_64 is stuck
From: Jakub Jirutka <jakub@jirutka.cz>
In-Reply-To: <59E82379-9E96-4660-92B2-C595A947852E@jirutka.cz>
Date: Mon, 30 Oct 2017 18:10:49 +0100
Cc: alpine-infra@alpinelinux.org
Message-Id: <1D50574F-CF30-4416-A273-D36F9D0AAD80@jirutka.cz>
References: <700B1EC2-05EB-433D-B8CA-886DDF4CAE70@jirutka.cz> <CA+T2pCE-B2P_Js=hc+X-UjvptJTMizX_nUZ4szzBodHZLi3Ktg@mail.gmail.com> <CB840A20-A016-4344-9F26-5AEDCEC26C93@jirutka.cz> <CA+T2pCE0TpbvdLqAchxHhDpJpnfck-jNM9Gj+fVipStONBxygQ@mail.gmail.com> <59E82379-9E96-4660-92B2-C595A947852E@jirutka.cz>
To: William Pitcock <nenolod@dereferenced.org>


--Apple-Mail=_1197AEC6-4775-4585-B679-928F6B9E04AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>> You could do that, or what I was inferring was that the binary itself =
was still available on distfiles.alpinelinux.org.

There=E2=80=99s only cargo-0.22.0.tar.gz, that=E2=80=99s the source =
tarball from the upstream, not binary=E2=80=A6

Jakub

> On 30. Oct 2017, at 18:07, Jakub Jirutka <jakub@jirutka.cz> wrote:
>=20
>> If this is the case, then it, too, is no longer policy compliant.
>=20
> Said who? These policies are (still) not written anywhere, so I follow =
what I was told by competent people like ncopa or fabled.
>=20
>> Manual intervention on the builders does not seem like a good idea to =
me, which is probably why it=E2=80=99s not compliant with policy.
>=20
> I agree, but I haven=E2=80=99t created this approach.
>=20
>> I suspect the ghc-bootstrap package was dropped because of the =
depsolver bug I solved back in April.
>> The bootstrap package would have a provides entry for the compiler =
with a version of 0.
>> This would allow the real compiler to always =E2=80=9Ewin" the =
preference.
>=20
> No, it was dropped because it was partially broken (I reviewed it) and =
actually not used (per fabled). I remember that quite well, =E2=80=99cause=
 I wasted amount of time trying to figure out how does it work, to be =
then told it=E2=80=99s not used at all.
>=20
>> Instead, lets solve these problems correctly, please.
>=20
> The problem is that I don=E2=80=99t know what is the correct solution. =
That=E2=80=99s why I asked ncopa or fabled.
>=20
>> Indeed, the only thing we have learned today is that Haskell is also =
broken.
>=20
> And maybe even gcc, =E2=80=99cause it also depends on itself=E2=80=A6 =
Or you have just wrong information. gcc is also handled somehow =
specially, if I remember correctly what fabled told me.
>=20
> So please, don=E2=80=99t interfere into it and wait for reaction from =
ncopa or fabled.
>=20
> Jakub
>=20
>> On 30. Oct 2017, at 17:53, William Pitcock <nenolod@dereferenced.org> =
wrote:
>>=20
>> Hello,
>>=20
>> On Mon, Oct 30, 2017 at 11:39 AM, Jakub Jirutka <jakub@jirutka.cz> =
wrote:
>>>> A manual intervention on each builder is not an acceptable =
solution.
>>>> Policy requires that builds be reproducible, in other words, that =
they can build with `abuild rootbld`.
>>>> So this change should not have been pushed to begin with.
>>>=20
>>>=20
>>> No, I thought this too, but it=E2=80=99s not how it really works. =
See below.
>>>=20
>>>> Look at the haskell + cabal packaging for inspiration, it is a =
similar situation, and is policy compliant.
>>>=20
>>> Have *you* looked at ghc (haskell) package? I did some time ago (and =
now), tried hard to figure out how does it build. There is =
`makedepends_build=3D"$pkgname"`, so it depends on itself. There used to =
be package ghc-bootstrap, but it was not used anymore (and even that =
couldn=E2=80=99t work without manual intervention). I asked fabled about =
it and he explained me that ghc-bootstrap was only temporary for initial =
bootstrap, now ghc depends on itself and it must be probably manually =
installed on the builder when bootstrapping.
>>=20
>> I did some time ago, when we had ghc-bootstrap package.
>> If this is the case, then it, too, is no longer policy compliant.
>>=20
>>> The same situation is community/rust. I even mentioned this in my =
email.
>>=20
>> The same situation of being policy non-compliant?
>>=20
>>> Unfortunately the bootstrapping (and cross-compilation) process is =
still not documented anywhere, so I can refer only to information that I =
was told by more competent people like fabled.
>>=20
>> Manual intervention on the builders does not seem like a good idea to
>> me, which is probably why it's not compliant with policy.
>>=20
>> I suspect the ghc-bootstrap package was dropped because of the
>> depsolver bug I solved back in April.
>> The bootstrap package would have a provides entry for the compiler
>> with a version of 0.
>> This would allow the real compiler to always "win" the preference.
>>=20
>>>> A solution would be to take a copy of the cargo package from =
distfiles.alpinelinux.org
>>>=20
>>> This is actually a good idea. I can keep it as it was before, just =
use our cargo binary instead of now non-existence binary from the =
upstream.
>>=20
>> You could do that, or what I was inferring was that the binary itself
>> was still available on distfiles.alpinelinux.org.
>> All the builders copy their sources to that server.
>>=20
>>> fabled or ncopa, could you please explain how is ghc and similar =
packages handled? Ideally directly on wiki, or just via email and I will =
copy it to wiki.
>>=20
>> Instead, lets solve these problems correctly, please.
>> Indeed, the only thing we have learned today is that Haskell is also =
broken.
>>=20
>> William
>>=20
>=20


--Apple-Mail=_1197AEC6-4775-4585-B679-928F6B9E04AB
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-----

iQEzBAEBCQAdFiEEwlgOtm6+gnC7W+06PZeHr2nsdbkFAln3XRkACgkQPZeHr2ns
dbkfcwf/WLlFWCunv0d7AUmMv0Y4+mdSzLdZ6ZjowCyB45k0wKyHBRgxVszmVJ/1
/qmBrLTA2GF7nPtJ6KK3TipQAjJmcfBvqs6KJtmFzhTTrl7rB9gsfvZikAyYhSAZ
7HNUFXxDJ5VMoDRSUKc1fS4zr3pxnPGFodFOuzyrC6oVoaPxNUjrlteR8XJMzLCt
fBAoW0ksoANXXUtt70VEjO4UhHJMiaKC+8OszbeHnDuw8ciSVIlL2Gbv5aUh7NKX
XGRpDCqzejLVPs5OzXEEFzOSec63FaQpY5nLjtzVRgPqug9rQFd8lrICSlbLraZZ
Q7AoCVqj2tI2re20nog8N3fc3ICrlw==
=71k9
-----END PGP SIGNATURE-----

--Apple-Mail=_1197AEC6-4775-4585-B679-928F6B9E04AB--