[libre-riscv-dev] sorry state of ieee754fpu repo -- CI desperately needed

[Frieder Paape]

Hi,

finally I found some time to look into this, I've seen that Jacob
already wrote the CI test and its working fine. My next steps would be
to mark all tests that are currently failing as skipped. And then fix
them one by one.

I am however a bit confused about my tasks because Luke says I should
give priority to the CI logging, which I believe Jacob has already taken
care of in rust. I do know the language so I could help out there as well.

Finally I have access to Jacobs build server now. I'd like to ask again
what my tasks here are. I can see if I can reconfigure gitlab-runner to
limit it's disk space. Also I understood that I should try and install
gitlab on the server?

Frieder

On 2020-04-06 02:59, Jacob Lifshay wrote:
> On Fri, Apr 3, 2020 at 4:10 AM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
>> On Fri, Apr 3, 2020 at 11:52 AM Frieder Paape <frieder at paape.io> wrote:
>>> Alright, it would finally be a chance for me to get a foot in the door
>>> since gitlabs CI is something I know about and fixing tests will lead to
>>> me getting an idea what the code is about.
>> ok great.
>>
>> jacob you good with that?
>>
>> and with frieder helping on the backend server? (will need your ssh
>> pubkey, frieder)
> Sure, sounds good. A warning: gitlab-runner thinks it can use all the
> free disk space, so you may want to figure out how to reconfigure it
> to not use all the space.
>
> I put some manual git syncing code in /home/git-mirroring so you can
> add the new gitlab instance as an additional target repo.
>
> Instructions on https://libre-riscv.org/resources/server-setup/git-mirroring/
>
> Do note that I configured iptables to specifically block all local
> addresses from docker, so if you try to run gitlab inside a docker
> container it will probably not work.
>
>> we can, say, use... EUR 500 from the Purism budget, and see how it goes?
>>
>> one top priority thing, working out how we can archive copies of all
>> messages generated by CI
>>
>> and in particular, recover the ones already generated, even if it
>> means writing a web scraper.
> Should be relatively easy to use gitlab's API.
>
>> we absolutely cannot rely on salsa as an uncontrolled resource.  we
>> are guests on that machine and should in no way rely on that hosting
>> to continue to be provided (and no i am not running gitlab on the 1GB
>> memory allocation vCPU behind libreriscv!)
> Luke, do note that we are currently relying on the combination of
> github and debian salsa to host Kazan's source code, so if they both
> kick us out, we'd have to move all the source. We could probably add
> some more mirrors using the above git-mirroring script since due to
> your selection of port 922 instead of port 22 for ssh, gitlab doesn't
> support push mirroring to libre-riscv.org.
>
> Jacob
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev