Josh Stone wrote:
> On 2/13/20 7:26 AM, Kevin Kofler wrote:
>> built only on one of them.) As far as I know, this was implemented that
>> way to make QEMU firmwares work (which are built on and for a specific
>> architecture, and then shipped as noarch packages for all of them so that
>> the archit
Le jeudi 13 février 2020 à 12:00 -0800, Josh Stone a écrit :
> On 2/13/20 11:26 AM, Nicolas Mailhot wrote:
> > Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit :
> > >
> > It is so black and white. If you can not produce bit-perfect
> > identical
> > builds, don’t try to make the result
On 2/13/20 11:26 AM, Nicolas Mailhot wrote:
> Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit :
>>
>> It's not so black and white. In theory, the only thing that should
>> matter is the target triple, but the metadata also hashes the
>> metadata
>> of all its build dependencies. That in
Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit :
>
> It's not so black and white. In theory, the only thing that should
> matter is the target triple, but the metadata also hashes the
> metadata
> of all its build dependencies. That in turn may include procedural
> macros (essentially
On 2/12/20 8:29 AM, Adam Jackson wrote:
> On Tue, 2020-02-11 at 16:21 -0800, Josh Stone wrote:
>
>> Another alternative is to try to remove the host information from the
>> metadata hash, which I've already started upstream[3], but I'm not sure
>> alleviate their concerns about caching and such.
>
On 2/12/20 12:45 AM, Nicolas Mailhot wrote:
> Le 2020-02-12 01:21, Josh Stone a écrit :
>
>> The problem is that those cross-target libraries built by two different
>> host arches will have different metadata hashes in the filenames,
>> because the hash includes the full "rustc -Vv" version output
On 2/13/20 7:26 AM, Kevin Kofler wrote:
> Neal Gompa wrote:
>> My instinct is that this wouldn't work, but I'm not certain. Have you
>> tried this change with a scratch build? Scratch builds run the same
>> checks that normal builds do, and would be a good way to verify if
>> your theory is true.
Neal Gompa wrote:
> My instinct is that this wouldn't work, but I'm not certain. Have you
> tried this change with a scratch build? Scratch builds run the same
> checks that normal builds do, and would be a good way to verify if
> your theory is true.
%ifarch-ing noarch subpackages (note: noarch S
On Tue, 2020-02-11 at 16:21 -0800, Josh Stone wrote:
> Another alternative is to try to remove the host information from the
> metadata hash, which I've already started upstream[3], but I'm not sure
> alleviate their concerns about caching and such.
>
> [3] https://github.com/rust-lang/cargo/pull
Le 2020-02-12 01:21, Josh Stone a écrit :
The problem is that those cross-target libraries built by two different
host arches will have different metadata hashes in the filenames,
because the hash includes the full "rustc -Vv" version output,
including
the host triple.
koji is doing the righ
On Tue, Feb 11, 2020 at 7:22 PM Josh Stone wrote:
>
> When building a normal arch package with noarch subpackages, would it be
> acceptable in Fedora if only *one* of the arches actually took
> responsibility to build those noarch subpackages?
>
> Context: the "rust" package normally builds arch-s
11 matches
Mail list logo
