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, [email protected] wrote:
----- Alexander Graf <[email protected]> a écrit :
Am 22.05.2018 um 19:47 schrieb Dirk Müller <[email protected]>:
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: [email protected]
To contact the owner, e-mail: [email protected]
