:: Re: [devuan-dev] Jenkins udisks2/ar…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: golinux
Fecha:  
A: devuan-dev
Asunto: Re: [devuan-dev] Jenkins udisks2/arm64
On 2019-10-16 10:35, Andreas Messer wrote:
> Mark,
>
> On Tue, Oct 15, 2019 at 09:02:47PM +0100, Mark Hindley wrote:
>> Andreas,
>>
>> On Tue, Oct 15, 2019 at 09:28:10PM +0200, Andreas Messer wrote:
>> > Hi,
>> >
>> > I somehow remind a mail from Leepen containing something
>> > about a build issue on Jenkins with udisks2. I have investigated
>> > a little and seen that the last build on 2nd May 2018 has still
>> > failed. Since there has already passed quite some time since then,
>> > I wonder if this is still an issue?
>>
>> The arm64 build isses I reported were with policykit-1. rrq also had
>> the
>> same failure (oom when compressing lzma) with util-linux. I haven't
>> even
>> tried a build of the new udisks2 until this is fixed.o
>
> Thx for correcting me. I just had some faint memory about it.
>
>> If you have any insight into why the arm64 buildhost is running out of
>> memory, please do say.
>
> I had a look at the policykit build. So AFAIK there are two, distinct
> issues:
>
> - Bus Error when testing udisks2 package
> - Out of memory when compressing the archives of different packages
>
> The later seems strange to me. I don't know much about the build nodes
> of
> the CI system neither about the used flow (the build script / Jenkins
> settings). But assuming that the hardware for the arm64 build is an
> Overdrive 1000 machine which is/was shipped with minimum of 8GB RAM,
> I would expect no such problem at all. I'm managing a Jenkins Build /
> Hardware-In-The-Loop test - system at our company which is running
> roughly
> more than 30 gcc/ld/ar/python/zip/whatever instances in parallel during
> build
> and never observed a memory shortage. (Also 8GB RAM in that VM
> instance)
>
> I think to find & tackle this issue, direct access to the machine &
> knowledge
> about the configuration is necessary. Probably only parazyd can do
> this.
>
> The former issue should be reproducible on my Librem 5 devkit without
> further knowledge. I could examine this, but not before this weekend.
>
> Cheers,
> Andreas
>


Hopefully a path to resolve this will be settled at the meet happening
in a hours.

golinux