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

Re: no networking in riscv-qemu... use pppd?



2017-04-19 11:30 GMT+02:00 Luke Kenneth Casson Leighton <lkcl@lkcl.net>:
> On Wed, Apr 19, 2017 at 10:12 AM, Manuel A. Fernandez Montecelo
> <manuel.montezelo@gmail.com> wrote:
>> The userspace ABI is stable, but the toolchain is in flux, for example
>> the recent changes in floating point size will probably cause some
>> problems, and I see inconsistencies between gcc and binutils every
>> time that I attempt new versions.
>
>  ohh yeah that sounds familiar, from reading the archive earlier today.

In fact, the Fedora folks stopped the work on their port for this
reason, until things are more stable.  I guess/hope that they continue
soon.


>> I think that I should publish my work so far, maybe it's useful to
>> you.
>
>  yes please.

OK, should be done in the next few days (not sure if today).


> *sigh* the last time i watched someone do a port i urged them to do it
> as an automatically-reproducible published build script or process of
> some description.  that was... i think it was the armhf guy.  it was a
> long time ago.  the suggestion was... not well received as it was not
> believed that the work was worthwhile reproducing (or having someone
> else even be involved)
>
>  since then we've had *at least* three totally separate and new debian
> ports, so the value of making the porting process automat-able and
> reproducible is, i feel, now being understood (great to see
> rebootstrap exists).

Maybe that's wookey and the rebootstrap thing?  He started mentoring
the rebootstrap thing in a GSoC edition, I think.

IIRC, last news on this is that since glibc and linux-headers are not
upstreamed, Helmut didn't want to carry over large patches in
rebootstrap.  (Since glibc and linux debian packages carry a lot of
patches, I suppose that this is a bit complicate to maintain over
time).

The good thing is that rebootstrap already sorts out most of the
issues for many arches, so even if nothing specific is done for riscv*
ones, it always advances.

I NMU some packages now and then, but I admit that I didn't do too
much.  It requires quite a lot of focus and knowing what other people
are doing and the state of the jobs in general, and I couldn't keep up
in the last few months.

Also, in my experience, some of the cross-compiled packages didn't
work properly (e.g. things as fundamental as bash and make); and
anyway to uncover some of the problems of the toolchain one needs to
start working natively.


>  even for what you're attempting, manuel, with riscv potentially
> changing (not immediately but potentially) and people creating
> hardware that could be slightly subtly different, and maybe someone
> wanting to do a 32-bit port, *and* binutils being in flux...
>
>  ... just for you *alone* - with binutils in flux an automated process
> where you can just leave it to run for a few days, unattended...

Yeah, that's the idea of rebootstrap, although I think that it's not
"complete" even for arches with full toolchain support and people
dedicating time on it for years.

https://wiki.debian.org/HelmutGrohne/rebootstrap

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=rebootstrap;users=helmutg@debian.org


>> I meant to be do it months ago, but $REAL_LIFE happened in
>> betweeen... :)
>
>  :)
>
>  yes please.  i can make an anonftp account available on my server,
> and then rsync it onto phil hands's server if that would help.

Thanks for the offer.  That part is covered.

It's more things like sorting out the packages that were compiled
cleanly and those who needed hacks to be compiled.  Some hacks are as
stupid as ignoring documentation files, creating a dir here and there
so the compilation can continue etc; but I should not publish things
that cannot be reproduced.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>


Reply to: