HI!
I'm running an raspberry pi 1 with this repo:
http://download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/
Last update was snapshot 20180319 but no updates since then.
Anything got stuck?
Ciao, Michael.
Hi,
On 09.04.2018 21:21, Michael Ströder wrote:
HI!
I'm running an raspberry pi 1 with this repo:
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?
Best,
Tom
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?
Greetings, Dirk
Dirk Müller wrote:
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?
Personally I only need JEOS images (assuming I can install XFCE later if I really need it).
Ciao, Michael.
Am 22.05.2018 um 19:47 schrieb Dirk Müller dirk@dmllr.de:
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.
Alex
----- Alexander Graf agraf@suse.de a écrit :
Am 22.05.2018 um 19:47 schrieb Dirk Müller dirk@dmllr.de:
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?
Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05/23/2018 09:09 AM, guillaume.gardet@free.fr wrote:
----- Alexander Graf agraf@suse.de a écrit :
Am 22.05.2018 um 19:47 schrieb Dirk Müller dirk@dmllr.de:
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.
Alex
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 agraf@suse.de a écrit :
Am 22.05.2018 um 19:47 schrieb Dirk Müller dirk@dmllr.de:
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.
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 agraf@suse.de a écrit :
Am 22.05.2018 um 19:47 schrieb Dirk Müller dirk@dmllr.de:
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
Hi,
Le 23/05/2018 à 14:48, Alexander Graf a écrit :
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 agraf@suse.de a écrit :
Am 22.05.2018 um 19:47 schrieb Dirk Müller dirk@dmllr.de:
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.
I will give it a try, but after oSC18. :)
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.
Yes, there will be probably some problems. ;)
Guillaume
Alex
On Mai 22 2018, Dirk Müller dirk@dmllr.de wrote:
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.
Why are they in the same repository then?
Andreas.
-
Adrian Schröter -
Alexander Graf -
Andreas Schwab -
Dirk Müller -
Guillaume Gardet -
guillaume.gardet＠free.fr
-
Michael Ströder -
Thomas Bechtold