Good morning,

and sorry for the late reply, our crowdfunding [0] is taking quite some
time from me.

I've created an IPv6-VM and just need a an ssh
key that should have access to it and a person who will be responsible
for it (i.e. who we contact in terms of maintenance or if something is
wrong).

For those of you who want to access it, but don't have IPv6, we do have
an IPv4-IPv6 ssh jumphost that can be used (and proxied through
transparenetly).

Many snowy greetings,

Nico

[0] https://swiss-crowdfunder.com/campaigns/data-center-light-phase-2-wachstum

Daniel Reurich <daniel@???> writes:

> Hi Nico,
>
> Devuan could do with one or 2 more well provisioned amd64 buildhost - ie
> 8GB ram, decent number of vcpu's and ~ 80GB fast (pref ssd) storage.
>
> It would be pretty much idle 99.9% of the time but when it runs it would
> push signficant cpu load.
>
> A local Devuan/Debian mirror would be useful as well to speed up builds
> significantly (the slowest part for most packages is installing all the
> build dependencies.
>

> Regards,
>     Daniel

>
>
>
> On 15/12/18 09:50, Nico Schottelius wrote:
>>
>> Hey mtx,
>>
>> would ungleich providing a beefy(*) VM for kernel builds make your life
>> easier or more productive for Devuan?
>>
>> If so, we might be very open for sponsoring.
>>
>> Best,
>>
>> Nico
>>
>> (*) Not sure if this is still politically correct, otherwise read it as
>> "full of tasty vegetables", please.
>>
>>
>> Enrico Weigelt, metux IT consult <lkml@???> writes:
>>
>>> Hi folks,
>>>
>>>
>>> while trying to build a debian kernel w/ some minor config changes
>>> (actually, just need the gpio keyboard modules), I've stumpled across
>>> several strange problems and finally found out that the patches
>>> haven't been applied on the main tree (in contrast to rt tree) .. this
>>> ate up a lot of time, as the build takes so long (unfortunately, I don't
>>> have the luxory of possessing a 120 core machine ;-)).
>>>
>>> When I look at the build rules, I really wonder why it's all so complex.
>>>
>>> Some things that IMHO contribute to that complexity:
>>>

>>> * several source trees - rt vs none:
>>>   --> can't we do this with one tree ?
>>>   --> if necessary, fixup the rt patches, so they don't do anything in
>>>       non-rt build (eg. proper #ifdef's) ?
>>> * arch specific patches - same story like rt
>>> * auxillary tools
>>>   --> can't we build them completely separately ?
>>>       (IMHO, shouldn't have an hard dependency on currently running
>>>       kernel)

>>>
>>> If it's just a matter of resources, I'd like to join in and do the job.
>>>
>>>
>>> --mtx
>>
>>
>> --
>> Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.
>> _______________________________________________
>> devuan-dev internal mailing list
>> devuan-dev@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>>


--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.