[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Build on hurd-i386 and kfreebsd-amd64 ... at home




On 2015-07-21 19:02, Johannes Schauer wrote:
> Hi,
> 
> Quoting gustavo panizzo (gfa) (2015-07-21 08:05:47)
>> On 2015-07-20 16:34, Johannes Schauer wrote:
>>> crossbuilding is not equal to native building. I think Daniel was looking for a
>>> way to test if their packages build natively on hurd-i386 or kfreebsd-amd64.
>>> But crossbuilding from linux (which I'll just assume Daniel runs on their host)
>>> to hurd or kfreebsd will lead to different results than natively building on
>>> these kernels in (probably) most cases.
>> would that make the test useless? I build test using qemu-static-XXXX
>> before upload to debian to avoid FTBFS when the package reach the buildd
>> network
> 
> are you using qemu-static-XXXX to build on linux for hurd or kfreebsd?
no, in the quick test i did it didn't work (their binfmt appears to be
the same)


> 
> The *only* 100% sure way to know if your package builds on the buildds is... to
> upload and build your packages on the buildds.

that's the thing i want to avoid, useless uploads

> 
> The second best way is to build either on real hardware (your own or a
> porterbox) or in a virtual machine which emulates a whole machine, including a
> kernel.
> 
> The third best way is to only emulate the architecture but not the kernel. This
> is what qemu-user does. This will probably let you run into kernel specific
> problems.

[ snip ]

well what I do worked in the test I did, for example trinity 1.5-1 FTBFS
on mips, mipsel and sparc due a missing include header, that i could
catch using qemu-static-XXX.

I agree that more complex interactions between the userspace and the
kernel may not work. I tough that qemu-static-XXX would be better than
you show, but hey! I didn't load a kernel so it is kinda expected


I didn't want to but I think i will create a set of vm, one for each
debian arch, and automate the build on it, I looked how to create a
buildd machine but is think is too much. I will stick to libvirt+scripts
to launch the build on different arch.

:( i didn't want to use more vm, pbuilder is so cool and easy to maintain



> 
> And sure, if your package does noting fancy but just calls cp a couple of times
> to put everything in the right location, then nothing will go wrong with the
> qemu-user method. But if your package is that simple, then you probably also
> don't need to test it.

again, dependencies and includes sometimes are different across arch,
that could be spotted

> 
> cheers, josch
> 

cheers

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa


Reply to: