[opensuse-arm] Raspberry Pi JeOS cleanups
Hello, Here's a quick heads-up about some cleanups I've been doing for our Kiwi images. The relationships of the images have been slightly tweaked and there are two new experimental images. Rough overview over the new _link relations (E20, LXQT, XFCE left out): openSUSE:Factory:ARM/JeOS |`- openSUSE:Factory:ARM/JeOS-raspberrypi |`- home:a_faerber:branches:openSUSE:Factory:ARM/JeOS-raspberrypi2 (NEW) | (=> to be created in openSUSE:Factory:ARM - still without USB) |`- devel:ARM:Factory:Contrib:HEAD/JeOS (new) | |`- devel:ARM:Factory:Contrib:HEAD/JeOS-efi.aarch64 | | (previously a direct _link to openSUSE:Factory:ARM) | `- devel:ARM:Factory:Contrib:HEAD/JeOS-raspberrypi3 (NEW) |`- devel:ARM:Factory:Contrib:RaspberryPi/JeOS-raspberrypi |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi2 | (previously a direct _link to openSUSE:Factory:ARM, broken) |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi3 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi3 | (previously a direct _link to openSUSE:Factory:ARM) `- devel:ARM:Factory:Contrib:RaspberryPi3/JeOS-raspberrypi3_aarch64 Main motivation was to facilitate testing of openSUSE kernel based Raspberry Pi 2 and 3 images (help needed with debugging: why no USB?!) and to simplify maintenance of derived Contrib images. While most of the .kiwi[.in] changes merge just fine, any .tgz updates require manual conflict resolution - the above scheme should require less such merges. Note: These changes are independent of the ext4 fixes on the U-Boot level that Stefan has been working on - no functional changes yet. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 12.09.2016 um 02:22 schrieb Andreas Färber:
Hello,
Here's a quick heads-up about some cleanups I've been doing for our Kiwi images. The relationships of the images have been slightly tweaked [...].
Rough overview over the new _link relations (E20, LXQT, XFCE left out):
Update: openSUSE:Factory:ARM/JeOS |`- openSUSE:Factory:ARM/JeOS-raspberrypi |`- home:a_faerber:branches:openSUSE:Factory:ARM/JeOS-raspberrypi2 |`- devel:ARM:Factory:Contrib:HEAD/JeOS | `- devel:ARM:Factory:Contrib:HEAD/JeOS-raspberrypi3 |`- devel:ARM:Factory:Contrib:RaspberryPi/JeOS-raspberrypi |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 | |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi3 | | (previously a direct _link to openSUSE:Factory:ARM) | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi2 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi3 | (previously a _link to devel:ARM:Factory:Contrib:RaspberryPi2) `- devel:ARM:Factory:Contrib:RaspberryPi3/JeOS-raspberrypi3_aarch64 In short: With the exception of my raspberrypi2 home branch and raspberrypi3 Contrib:HEAD, both soon to be deleted, there is only one JeOS link diff per project now. Once again this reduces the number of projects to touch for conflict resolution. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Andreas, I'd appreciate if you could check with the maintainer before changing links in a project that you're always pointing out that you're not maintaining, *especially* in non-Staging projects that are supposed to be stable. if you want to do a change, you're welcome to try it out in the Staging project.
|`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 | |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi3 | | (previously a direct _link to openSUSE:Factory:ARM) | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi2 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi3 | (previously a _link to devel:ARM:Factory:Contrib:RaspberryPi2)
I think this violates the rule that "JeOS-flavor link diff should be empty" rule. What I would have liked to see here instead is the creation of a JeOS main package that the others linked to, e.g. devel:ARM:Factory:Contrib:RaspberryPi2/JeOS - link to openSUSE:Factory:ARM / JeOS | ' devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 - link to devel:ARM:Factory:Contrib:RaspberryPi2 / JeOS this way the JeOS-raspberrypi2 is empty and doesn't require a link diff and hence no "manual conflict resolution". In any case the linkdiff in devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 was supposed to be temporary, and perhaps we should have just gotten rid of that link diff instead of making the setup now confusing and complex. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Dirk, Am 18.10.2016 um 10:25 schrieb Dirk Müller:
I'd appreciate if you could check with the maintainer before changing links in a project that you're always pointing out that you're not maintaining, *especially* in non-Staging projects that are supposed to be stable. if you want to do a change, you're welcome to try it out in the Staging project.
There is nothing to try out in a Staging project here, this is all about creating JeOS-raspberrypi2 and JeOS-raspberrypi3 in Factory! Which conflicts by name with any Contrib projects it is deprecating, whomever may have maintained them previously. As you may have read, Guillaume and me tested out images from my home project before I flipped the switch for :Factory:ARM. Same idea for Pine64 for instance - therefore my urge to separate the packages cleanly there, so that we can get things into hardware, Base:System or whatever devel project and out of Contrib once it goes upstream.
|`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 | |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi3 | | (previously a direct _link to openSUSE:Factory:ARM) | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi2 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi3 | (previously a _link to devel:ARM:Factory:Contrib:RaspberryPi2)
I think this violates the rule that "JeOS-flavor link diff should be empty" rule.
Well, I did not create JeOS-raspberrypi2 that way. ;) And my point was about "one", not literal "JeOS".
What I would have liked to see here instead is the creation of a JeOS main package that the others linked to, e.g.
devel:ARM:Factory:Contrib:RaspberryPi2/JeOS - link to openSUSE:Factory:ARM / JeOS | ' devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 - link to devel:ARM:Factory:Contrib:RaspberryPi2 / JeOS
this way the JeOS-raspberrypi2 is empty and doesn't require a link diff and hence no "manual conflict resolution".
Good idea, if we disable the JeOS package like I did in :Contrib:HEAD. You're free to further improve things yourself, that was the goal of my original cleanups mail, but no one took action or even replied. :(
In any case the linkdiff in devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 was supposed to be temporary, and perhaps we should have just gotten rid of that link diff instead of making the setup now confusing and complex.
No, in order to have an official JeOS-raspberrypi2 in :Factory:ARM this is _not_ temporary. As is in Factory today, the image is working okay via serial, but no network or keyboard/mouse via USB; with Kernel:HEAD and Kernel:stable that gets resolved. Later today my raspberrypi2 home branch can be switched back from default to lpae. The discussion I was having with Alex is about the following: I believe the :Factory:ARM JeOS package should not contain unnecessary cruft for Contribs *whenever* there are upstream images. In that case IMO the Contribs should be abandoned as soon as the upstream images are usable - which for rpi2 will be the case with vc4 and USB. You are free to keep maintaining a Contrib package, but don't complain about the burden the duplication poses then. One could argue it wastes build power and causes confusion for users. Any link diff in the XML rather than tgz shouldn't cause problems. See also Fabian's discussion of .tgz. Alex however suggested that we might rename the downstream images after an upstream image exists, so that they can be maintained in parallel in :Factory:ARM with no link diffs in the other projects. However, I was fighting against the awkward list of IS_FLAVOR_raspberrypi3 || IS_FLAVOR_raspberrypi3_tralala, so the only sane way around it would be to reuse my $flavor vs. $flavor_type trick as for _aarch64, together with some other #define where really needed to distinguish; the kernel name can be already checked today to distinguish upstream and downstream for anything but raspberrypi3_aarch64. It just doesn't allow to distinguish Staging from non-Staging downstream, and wouldn't the whole point of Staging be to test the same, not just similar code paths? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Andreas, 2016-10-18 12:21 GMT+02:00 Andreas Färber <afaerber@suse.de>:
There is nothing to try out in a Staging project here, this is all about creating JeOS-raspberrypi2 and JeOS-raspberrypi3 in Factory!
That is completely unrelated. The point is that you're changing a project that is supposed to be stable without agreeing on a consensus *before* doing so and then expect the maintainer to clean that stuff up. This is the part htat is upsetting me.
conflicts by name with any Contrib projects it is deprecating, whomever may have maintained them previously. As you may have read, Guillaume and me tested out images from my home project before I flipped the switch for :Factory:ARM.
again, I'm not talking about Factory:ARM.
I think this violates the rule that "JeOS-flavor link diff should be empty" rule. Well, I did not create JeOS-raspberrypi2 that way. ;) And my point was about "one", not literal "JeOS".
I explained why it was created that way by me.
What I would have liked to see here instead is the Good idea, if we disable the JeOS package like I did in :Contrib:HEAD.
That is unrelated, it doesn't have to be disabled. when it is enabled you can look at the build result as well. Why did you choose to use two different solutions for two contrib projects? if the point was to cleaning it up, then make it more similar than before. now its just awkward imho.
No, in order to have an official JeOS-raspberrypi2 in :Factory:ARM this is _not_ temporary.
3rd time. I do not talk about Factory:ARM at all.
I believe the :Factory:ARM JeOS package should not contain unnecessary cruft for Contribs *whenever* there are upstream images. In that case IMO the Contribs should be abandoned as soon as the upstream images are usable - which for rpi2 will be the case with vc4 and USB.
Which is fine by me. my point is that we don't make contribs more complicated than they are now or change non-staging projects without testing things in Staging first. I personally spent already way too many nights on fixing the random regression because someone thought some change somewhere would not affect anything else, but it did.
to keep maintaining a Contrib package, but don't complain about the burden the duplication poses then.
Why is it so complicated to discuss things before they are done?
Alex however suggested that we might rename the downstream images after an upstream image exists, so that they can be maintained in parallel in :Factory:ARM with no link diffs in the other projects.
I think we should just always have a -Contrib- in the image name when it is a contrib image. this way the occassional mail chatter about "well, which image exactly did you use from where?" is solved.
fighting against the awkward list of IS_FLAVOR_raspberrypi3 || IS_FLAVOR_raspberrypi3_tralala, so the only sane way around it would be to reuse my $flavor vs. $flavor_type trick as for _aarch64, together with some other #define where really needed to distinguish; the kernel name can be already checked today to distinguish upstream and downstream for anything but raspberrypi3_aarch64. It just doesn't allow to distinguish Staging from non-Staging downstream, and wouldn't the whole point of Staging be to test the same, not just similar code paths?
I don't think you need to do anything in that area, this can be done automatically by the build service rather those crude hacks. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Dirk, (Note that I did not receive your email myself yet.) Am 18.10.2016 um 13:19 schrieb Dirk Müller:
2016-10-18 12:21 GMT+02:00 Andreas Färber <afaerber@suse.de>:
There is nothing to try out in a Staging project here, this is all about creating JeOS-raspberrypi2 and JeOS-raspberrypi3 in Factory!
That is completely unrelated. The point is that you're changing a project that is supposed to be stable without agreeing on a consensus *before* doing so and then expect the maintainer to clean that stuff up. This is the part htat is upsetting me.
I really have no clue what you are complaining about here. I staged changed _in my home branch_ for multiple weeks. I tested them. Then I submitted them. This broke some Contribs and I had the decency to fix the "broken" status in those projects - that only works as commits. dtb-source changes again were build-tested in home branches before submitting them. As long as the Contribs link against :Factory:ARM/JeOS (whether or not you are talking about Factory is irrelevant because the link is a fact) we will see breakage in Contribs when performing valid changes for Factory. Same discussion as with Pine64 recently.
conflicts by name with any Contrib projects it is deprecating, whomever may have maintained them previously. As you may have read, Guillaume and me tested out images from my home project before I flipped the switch for :Factory:ARM.
again, I'm not talking about Factory:ARM.
... but I am. Factory is what we should all be working on and which should have priority over any downstream Contrib project.
I think this violates the rule that "JeOS-flavor link diff should be empty" rule. Well, I did not create JeOS-raspberrypi2 that way. ;) And my point was about "one", not literal "JeOS".
I explained why it was created that way by me.
No, not to me. JeOS-raspberrypi2 links exactly the way as before, I did not delete any "JeOS" package in your Contrib project. So any links I simplified was an improvement, and if you want to add an extra "JeOS" package then go ahead. I don't understand why you complain about me not doing _more_ cleanups for you.
What I would have liked to see here instead is the Good idea, if we disable the JeOS package like I did in :Contrib:HEAD.
That is unrelated, it doesn't have to be disabled. when it is enabled you can look at the build result as well.
I feel that building a JeOS package in every Contrib is burning build power for no real reason. You'd get a different kernel in the rootfs but no matching rootfs, so what is the benefit?
Why did you choose to use two different solutions for two contrib projects? if the point was to cleaning it up, then make it more similar than before. now its just awkward imho.
I don't understand what you mean here: What two approaches???
No, in order to have an official JeOS-raspberrypi2 in :Factory:ARM this is _not_ temporary.
3rd time. I do not talk about Factory:ARM at all.
Again, I do. No counting of yours will change that.
I believe the :Factory:ARM JeOS package should not contain unnecessary cruft for Contribs *whenever* there are upstream images. In that case IMO the Contribs should be abandoned as soon as the upstream images are usable - which for rpi2 will be the case with vc4 and USB.
Which is fine by me. my point is that we don't make contribs more complicated than they are now or change non-staging projects without testing things in Staging first. I personally spent already way too many nights on fixing the random regression because someone thought some change somewhere would not affect anything else, but it did.
How would I test a Factory change in your Staging project? Again, this is about avoiding/fixing "broken" packages as a result of changes _in Factory_. And by keeping the diff small, we minimize future breakages.
to keep maintaining a Contrib package, but don't complain about the burden the duplication poses then.
Why is it so complicated to discuss things before they are done?
Discuss what? I sent an email, you didn't bother to reply, so I went ahead and replied to myself. This is in context of the internal discussion we had with Jay and of upcoming 4.8 kernel. Had Alex done these changes back when we worked on U-Boot EFI patches, I wouldn't have needed to bother making and testing these changes myself. So I think I deserve a thank-you!
Alex however suggested that we might rename the downstream images after an upstream image exists, so that they can be maintained in parallel in :Factory:ARM with no link diffs in the other projects.
I think we should just always have a -Contrib- in the image name when it is a contrib image. this way the occassional mail chatter about "well, which image exactly did you use from where?" is solved.
Fine with me. Feel free to tweak Images.kiwi.in everywhere.
fighting against the awkward list of IS_FLAVOR_raspberrypi3 || IS_FLAVOR_raspberrypi3_tralala, so the only sane way around it would be to reuse my $flavor vs. $flavor_type trick as for _aarch64, together with some other #define where really needed to distinguish; the kernel name can be already checked today to distinguish upstream and downstream for anything but raspberrypi3_aarch64. It just doesn't allow to distinguish Staging from non-Staging downstream, and wouldn't the whole point of Staging be to test the same, not just similar code paths?
I don't think you need to do anything in that area, this can be done automatically by the build service rather those crude hacks.
If you have ideas how to handle it better, please propose SRs. :) Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Johannes, Am 18.10.2016 um 20:37 schrieb Johannes Kastl:
On 18.10.16 16:30 Andreas Färber wrote:
[context: how/where/when/whom-by fixing someone else's Contrib project]
So I think I deserve a thank-you!
Don't want to take any side here (as I am missing the knowledge about the internals), but I think all of you working on non-x86 deserve a big thank you.
Here is mine:
THANK YOU!
I hope it was clear that users were not what this was about. But many thanks for speaking up! :) Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
participants (3)
-
Andreas Färber -
Dirk Müller -
Johannes Kastl