I thought we should have skipped F15, but I do agree we are probably
going to have to skip one release. Even if say armv5 does 16 and armv7
does 17 then a unified 18.
Is there a way to check all the arm source repositories for changes
that have been made to verify they made it into the mainline
f15/f16/rawhide packages?
If say some of the F15 changes didn't make it to F16 or rawhide, this
may save quite a bit of time moving forward.
If possible, it would be nice to just have this run as once a month
type of verification tool. It doesn't sound extremely useful if
everything is going correctly, but it does verify the whole process.
Someone had a one off tool for the F15 srpm's, maybe start there and
flesh it out, or is there a "better way"?
Quoting Peter Robinson <pbrobinson(a)gmail.com>:
2011/10/19 Henrik Nordström <henrik(a)henriknordstrom.net>:
> tis 2011-10-18 klockan 22:09 -0500 skrev Dennis Gilmore:
>
>> So ive done some thinking, and talked with some of the stakeholders.
>> Ive come to the conclusion that we should skip f16 and shoot straight
>> for rawhide.
>
> +1 from me. It's already late to start on F16. F17 is a more realistic
> goal.
>
> Related to this FTBFS issues needs to be tracked more closely. There
> have been quite many mainline FTBFS issues seen in the F15 rebuild which
> is not even fixed in rawhide. And when moving to rawhide a number of new
> FTBFS issues will arise.
Well the patches used for f-15 packages should have ultimately been
commited to mainline F-15/16/rawhide as they were found so we wouldn't
have this problem. I was doing that with all the fixes I made to F-14
so at least those will be mainline.
> Just not sure if that jump from F15 to rawhide should be done by trying
> moving forward in koji, or as a two stage rebuild like done for
> armv5tel. Depends largely on how good the shadowing scripts are at
> ordering build dependencies or how complex it is in koji to reshake
> packages that need to be rebuilt because of build ordering issues
> resulting in broken builds.
koji-shadow is pretty good, but it can be slow (this might be
incentive enough to improve it!) and we will likely end up with a
chunk of f-15/16 built as part of it, but we'd end up with that
anyway. F-15 was the last mass rebuild so technically there should be
no need for anything before that. I think we start asap using the f-15
builds and actually get things moving forwards and fix as we go rather
than messing about all over again with staging it. I have a rough
build order I did in koji to get f-14 bootstrapped with F-13 and will
gladly help out to push them through so we can get a decent build
chain to kick of koji-shadow.
> Even with the limited package churn we have had in armv7hl there have
> been quite many packages with bad builds due to dependencies changing,
> and quite likely is some left still. But as the mock building is all
> "scratch" builds it's then only a matter or rescheduling the same
builds
> again. How is this handled when building in koji?
koji-shadow will go down the dep chain and build deps, and dep's deps.
>> I suspect there are some pieces of f16 we will need to build to get
>> things right. and if we get caught up quickly and can follow the
>> branching from rawhide to f17 there is no reason we cant back track
>> around and do f16 i just feel that once we get f15 done we should get
>> moving towards parity. and showing that arm works and can keep up and
>> follow along.
well if you look at f-17 its still composed of a lot of f16 and even
f15 (f15 being the last mass rebuild) but the build chain is still not
to far removed from F-15 in that gcc is still 4.6, python is still 2.7
etc. Basically I think we need to start with the F-15 we have and kick
it off and run and fix. If we wait until its all perfect we'll never
start.
Peter
> A double rebuild is a very powerful tool for shaking out any build
> issues. You will be left pretty much with a set of good packages and a
> set of FTBFS packages. And package maintainers have rason to look into
> FTBFS issues.
>
> Regards
> Henrik
>
> _______________________________________________
> arm mailing list
> arm(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/arm
>
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
--
"The information in this email, and attachment(s) thereto, is strictly
confidential and may be legally privileged. It is intended solely for
the named recipient(s), and access to this e-mail, or any
attachment(s) thereto, by anyone else is unauthorized. Violations
hereof may result in legal actions. Any attachment(s) to this e-mail
have been checked for viruses, but please rely on your own
virus-checker and procedures. If you contact us by e-mail, we will
store your name and address to facilitate communications in the matter
concerned. If you do not consent to us storing your name and address
for above stated purpose, please notify the sender promptly. Also, if
you are not the intended recipient please inform the sender by
replying to this transmission, and delete the e-mail, its
attachment(s), and any copies of it without, disclosing it."