I propose a VFAD to clean up and reconcile armv5tel/armv7hl pre-koji package sets and prep for koji startup:
When: Nov 14 - 11:00 am EST / 8:00 am PST / 15:00 UTC where: #fedora-arm What: armv5tel-armv7hl package set reconcilliation, koji prep
You us if you can, mail the list with any issues/info if you can't make it.
-- Chris
On Tue, 2011-11-08 at 16:59 -0500, Chris Tyler wrote:
I propose a VFAD to clean up and reconcile armv5tel/armv7hl pre-koji package sets and prep for koji startup:
When: Nov 14 - 11:00 am EST / 8:00 am PST / 15:00 UTC where: #fedora-arm What: armv5tel-armv7hl package set reconcilliation, koji prep
Excellent. I'm there!
Jon.
On Tue, Nov 8, 2011 at 10:23 PM, Jon Masters jcm@redhat.com wrote:
On Tue, 2011-11-08 at 16:59 -0500, Chris Tyler wrote:
I propose a VFAD to clean up and reconcile armv5tel/armv7hl pre-koji package sets and prep for koji startup:
When: Nov 14 - 11:00 am EST / 8:00 am PST / 15:00 UTC where: #fedora-arm What: armv5tel-armv7hl package set reconcilliation, koji prep
Excellent. I'm there!
Me too, in the calendar to remind me
Peter
tis 2011-11-08 klockan 16:59 -0500 skrev Chris Tyler:
I propose a VFAD to clean up and reconcile armv5tel/armv7hl pre-koji package sets and prep for koji startup:
When: Nov 14 - 11:00 am EST / 8:00 am PST / 15:00 UTC where: #fedora-arm What: armv5tel-armv7hl package set reconcilliation, koji prep
You us if you can, mail the list with any issues/info if you can't make it.
I think I can attend. Should arrive home from FSCONS by then.
There is about 20 or so packages which need to get merged mainline somehow, with some notably core ones such as gcc, glibc & java. Are we comfortable with not having these merged mainline before doing the koji build?
mysql also needs a bit of cleanup. some arm changes already mainline, but not all.
regarding the ghc-XXX packages with armv7hl added as supported arch, the proposal here is to ignore them and only include ghc + hscolour (mainline already) in the koji f15 build. The rest will get automatically included in later Fedora ARM releases with no further action needed. But if we want them in F15 ARM then it's a matter of updating the ExclusiveArch tag to use %{ghc_arches} in mainline f15 git on the packages we need (or all ~90?). There is no need to touch f16+ git on these as it's already dealt with there.
In addition to this there is one more gcc patch that should be evaluated, relating to incorrect code generation in volatile bitfields resulting in various subtle runtime errors (bad builds). Not yet included in the gcc in our repositories but test results so far looks very promising. Not entirely comfortable with doing the official mass rebuild without having this fixed first. Unfortunately it is unknown which packages this issue hits. See GCC PR #50521 <gcc.gnu.org/bugzilla/show_bug.cgi?id=50521>. This issue need some help pulling the right GCC people to evaluate the proposed patch. This issue hits mainly arm architecture due to ABI differences to x86 and presumably the other secondary arches as well.
Regards Henrik
On 11/08/2011 02:44 PM, Henrik Nordström wrote:
There is about 20 or so packages which need to get merged mainline somehow, with some notably core ones such as gcc, glibc& java. Are we comfortable with not having these merged mainline before doing the koji build?
It could be weeks before the last gcc patches filter down to F15, if ever. I suggest we start koji with a custom srpm and move on to an update once it becomes available.
In addition to this there is one more gcc patch that should be evaluated, relating to incorrect code generation in volatile bitfields resulting in various subtle runtime errors (bad builds). Not yet included in the gcc in our repositories but test results so far looks very promising. Not entirely comfortable with doing the official mass rebuild without having this fixed first. Unfortunately it is unknown which packages this issue hits. See GCC PR #50521 <gcc.gnu.org/bugzilla/show_bug.cgi?id=50521>. This issue need some help pulling the right GCC people to evaluate the proposed patch. This issue hits mainly arm architecture due to ABI differences to x86 and presumably the other secondary arches as well.
Per our IRC conversation, the second patch in 50521, "patch to honour STRICT_ALIGNMENT," breaks the gcc build. Midway through, xgcc is used to generate an executable which segfaults. The build works with 50521's "proposal patch" however. I have not tested the result.
tis 2011-11-08 klockan 15:05 -0800 skrev Brendan Conoboy:
Per our IRC conversation, the second patch in 50521, "patch to honour STRICT_ALIGNMENT," breaks the gcc build. Midway through, xgcc is used to generate an executable which segfaults. The build works with 50521's "proposal patch" however. I have not tested the result.
It's the first "proposal patch" that I worry about.
As discussed in the PR the second patch is a separate problem and do not belong here and should be moved to a PR of it's own (alignment in general). But it is possible armv5 may need something like this in some cases, I do not know.
Regards Henrik
On Wed, 09 Nov 2011 07:44:02 +0100, Henrik Nordström henrik@henriknordstrom.net wrote:
tis 2011-11-08 klockan 15:05 -0800 skrev Brendan Conoboy:
Per our IRC conversation, the second patch in 50521, "patch to honour STRICT_ALIGNMENT," breaks the gcc build. Midway through, xgcc is used to generate an executable which segfaults. The build works with 50521's "proposal patch" however. I have not tested the result.
It's the first "proposal patch" that I worry about.
As discussed in the PR the second patch is a separate problem and do not belong here and should be moved to a PR of it's own (alignment in general). But it is possible armv5 may need something like this in some cases, I do not know.
Speaking of alignment, armv5 has been in need of a GCC option to force 4-byte alignment of all arrays (including char[] arrays) and structs since forever. Arguably, it should be on by default on arm. But I guess that is unrelated to this particular alignment issue.
Gordan
ons 2011-11-09 klockan 10:05 +0000 skrev Gordan Bobic:
Speaking of alignment, armv5 has been in need of a GCC option to force 4-byte alignment of all arrays (including char[] arrays) and structs since forever. Arguably, it should be on by default on arm. But I guess that is unrelated to this particular alignment issue.
Are you speaking of alignment in allocation or alignment in access?
50521 is about alignment in access when accessing volatile bitfields where the ARM ABI have quite strict rules, plus that the gcc generates bad code when trying to implement those rules via the -fstrict-volatile-bitfields option.
Regards Henrik
Chris,
Thanks for organizing this yesterday. To add to your list of topics, Peter and I discussed the plan for getting to rawhide. He wants to drive this, and that's cool with me. The intention is that as soon as it is possible to begin doing builds, we should begin that activity in parallel. So if we can get Koji going this week, great, and once there is enough built to get rawhide going, that doesn't need to wait.
Jon.
Jon Masters píše v Út 15. 11. 2011 v 04:56 -0500:
Chris,
Thanks for organizing this yesterday. To add to your list of topics, Peter and I discussed the plan for getting to rawhide. He wants to drive this, and that's cool with me. The intention is that as soon as it is possible to begin doing builds, we should begin that activity in parallel. So if we can get Koji going this week, great, and once there is enough built to get rawhide going, that doesn't need to wait.
I think there is a problem with parallel runs of koji-shadow for eg. f15 and rawhide when the "--prefer-new" option (uses the latest available N-V-Rs in buildroot for secondary build instead of exact ones from the primary build) is used. I've had the situation I'll describe below in my head for a while and it happened on s390 right now so IMHO it's real. When there would be an exact match between the buildroots everything would be OK.
The problem is that you can get a build for eg. f16 (because it was used in a buildroot of some dependent build) built with buildroot set from rawhide/f17 packages making it incompatible with the real f16. And a later build with f16 buildroot (which will be queued because it doesn't exist under the f16 tag) will fail because N-V-R must be unique.
The example is the "jd" package (http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=80276 and http://koji.fedoraproject.org/koji/packageinfo?packageID=2157 in primary koji) and as you can see there are *.fc17 packages in the buildroot. The result is also tagged as f17.
Hopefully I haven't mixed the things too much and I'm not completely wrong.
Dan
On Tue, Nov 15, 2011 at 9:56 AM, Jon Masters jcm@redhat.com wrote:
Chris,
Thanks for organizing this yesterday. To add to your list of topics, Peter and I discussed the plan for getting to rawhide. He wants to drive this, and that's cool with me. The intention is that as soon as it is possible to begin doing builds, we should begin that activity in parallel. So if we can get Koji going this week, great, and once there is enough built to get rawhide going, that doesn't need to wait.
Awesome that all the hard work of everyone is starting to come together! Very exciting :)
I started last night going through the list of packages requiring upstreaming. I should have most of it done by the beginning of next week, most of these aren't blockers for core packages required for the start of the koji building and they should both be done in parallel.
Basically the way I see it is that we need to get the native koji build root packages built in koji (gcc/glibc/libtool/rpm/yum etc) for Fedora 15 and then we can kick off the F-15 mass build. Once the core build root is done for F-15 and that mass rebuild is underway there's no reason not to get rawide doing the same.
Peter