Re: [opensuse-arm] armv7l tw updates?

On 05/23/2018 02:42 PM, Adrian Schröter wrote:

On Mittwoch, 23. Mai 2018, 14:35:35 CEST wrote Alexander Graf:

...

On 05/23/2018 09:09 AM, guillaume.gardet@free.fr wrote:

...

----- Alexander Graf a écrit :

...

...

Am 22.05.2018 um 19:47 schrieb Dirk Müller :

Hi,

...

> http://download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/ > > Last update was snapshot 20180319 but no updates since then. Same is true for armv7... > Anything got stuck? Any updates on this? We managed to publish it once manually, currently we have massive performance issues due to to-test-manager waiting for ftp trees for armv6,armv7 and aarch64 plus all the live images (with KDE and GNOME flavors) to build which basically never finishes.

I've reduced the refreshing to twice a week, we might have to go down to once a week or remove some images. Does anyone care strongly about GNOME or KDE images? What I would much rather prefer is to trim the other dimension.

What if we could take the efi image builds as build input in OBS? Then we could just apply the few u-boot additions ad hoc and automatically create a board specific image without all of the image building overhead. It would be awesome! :) Is kiwi ready for such a thing? I think this would have to happen outside of kiwi. So kiwi would produce for example a JeOS-efi image. A different build job could create a JeOS-pine64 out of that then.

I don't think we have the logic to do that in OBS quite yet though. If we could convince someone to add the few missing like I believe we could dramatically reduce build times. hm, could you just use the post kiwi build hook of the build script?

Means you need to build an rpm which provides some executable

/usr/lib/build/kiwi_post_run

and you just require that package in your prjconf.

So you could basically run anything there and modify or produce more images.

That sounds pretty much like one way to do it, yes. We'd lose parallelism, but given that everything is at least "cache hot" (files are on the local disk) that might make up for it. Guillaume, do you want to take a look at this and see how far you can get with that approach? I guess we really just need to copy the {JeOS,GNOME,XFCE,...}-efi image to a temporary one, run the uboot-image-install script part on that and compress the result back into a new image. The biggest problem I can see would be that we have a few package overlays as well. So how can we get the target specific u-boot packages into the build environment to install them in the post run step? They're conflicting each other IIRC. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org