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@xxxxxxxxx>: > 2011/10/19 Henrik Nordström <henrik@xxxxxxxxxxxxxxxxxxx>: >> 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@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/arm >> > _______________________________________________ > arm mailing list > arm@xxxxxxxxxxxxxxxxxxxxxxx > 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." _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
