(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
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
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.
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
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
Well, I did not create JeOS-raspberrypi2 that way. ;) And my
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
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.
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!
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.
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. :)
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(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org