[fedora-arm] Fix for Multiplatform F19 kernels
Hi Peter, Please take a look at the attached. Note that the default kernel variant is actually a versatile, and you weren't inheriting that. Also, we need to set the V6_V7 multiplatform option because the current Kconfig logic will otherwise enable AUTO CPU support, which will force us to have a V5 kernel. So take a look. I'll be online later. Tested with a cross compiler only, but it built. Jon. diff --git a/Makefile.config b/Makefile.config index 21143eb..926a323 100644 --- a/Makefile.config +++ b/Makefile.config @@ -44,7 +44,7 @@ temp-armv7: config-armv7 temp-generic temp-arm-generic: config-arm-generic temp-generic perl merge.pl $^ > $@ -temp-armv7l-versatile: config-arm-versatile temp-arm-generic +temp-armv7l-versatile: config-armv7 config-arm-versatile temp-arm-generic perl merge.pl $^ > $@ temp-armv7l-omap: config-arm-omap temp-arm-generic diff --git a/config-armv7 b/config-armv7 index 299e142..6de1654 100644 --- a/config-armv7 +++ b/config-armv7 @@ -1,7 +1,9 @@ # ARM unified arch kernel +CONFIG_CPU_V7=y # CONFIG_ARCH_MULTI_V4 is not set # CONFIG_ARCH_MULTI_V4T is not set # CONFIG_ARCH_MULTI_V6 is not set +CONFIG_ARCH_MULTI_V6_V7=y CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_MVEBU=y CONFIG_ARCH_HIGHBANK=y ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fix for Multiplatform F19 kernels
On 11/29/2012 03:09 AM, Jon Masters wrote: > Please take a look at the attached. Note that the default kernel variant > is actually a versatile, and you weren't inheriting that. Also, we need > to set the V6_V7 multiplatform option because the current Kconfig logic > will otherwise enable AUTO CPU support, which will force us to have a V5 > kernel. So take a look. I'll be online later. > > Tested with a cross compiler only, but it built. http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1271566 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Raspberry Pi Fedora Remix 18
On 11/29/2012 6:20 AM, Chris Tyler wrote: And... just to help clarify who is who and does what here, I've done a long-overdue blog post to introduce the current team members: http://blog.chris.tylers.info/index.php?/archives/268-.html -- Chris ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm Hello, I see on that list that Andrew Green is testing Raspberry Pi Fedora Remix 18. Is this available somewhere? Aditionnaly are there any plans (or limitations) to merge the raspberrypi-kernel and ARM kernel? Thanks, Matthieu ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Regarding Seneca Issues
On Wed, Nov 28, 2012 at 8:45 PM, Jon Chiappetta wrote: >> > 6) Your topic here >> >> Koji: There have been a number of issues over the last couple of weeks >> that have been bought up and I haven't seen any form of update from >> Seneca as to the state: >> >> - DB perf tuning, it was done or at least there was an outage. What >> was the outcome > > * The dump and restore worked in shrinking our db size and cleaning > old entries from our tables. Auto-vacuum seems to be broken or not > working as we expected it but manual vacuum seems to work well on > all of the tables. Excellent, thanks for the update. >> - repo issues (the generally perl based build failures due to repo >> issues). I reported I thought I had found the offending host but the >> issue appears to have come back. Was the host re-enabled, what testing >> has Seneca done? > > * Could you please provide the specific task links as examples or names > of hosts that are causing the problem so we could diagnose the problem > and look into resolving it? No I can't because I don't have time spare to dig through koji builds but I have provided lots of them in the past on the IRC channel but basically if you look through this list: http://arm.koji.fedoraproject.org/koji/tasks?state=failed&view=tree&method=all&order=-id If you get a build like this: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1271590 That has the "BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information" error you're basically guaranteed to find 100s of examples and it covers most of our failures now days. >> - builder issues, seeing issues with things like the disk space on the >> large builders without a resolution, or a resolution being reported. >> What is the status, is it fixed? > > * What are the problems with the large builders? Are there RAM issues, > permission issues, low space issues? Which builders need to be looked at > specifically because it's hard to solve this without the needed info. There's a number of issues that I've pinged on IRC about . I don't have access to the platform (and I'm quite happy to keep it that way) so I see an issue with builders and I normally disable them so they stop causing builds issues and report the builder to the channel with as much detail I can tell from my build experience and what I suspect is wrong and I expect the people in charge of the platform to investigate (I can't and don't want to do everything, I don't scale that well). The large builder channel had issues with the Trimslices due to the HDD partition sizing and some of them dgilmore couldn't access and was questioned "Why do you need access to this". >> - Some people have remote access to the builders via a ssh key but it >> appears that not all build hosts are configured for this. What's the >> steps to resolution so that people can support the platform? > > * We specifically setup bcfg2 across all builders which helps to distribute > our keys to them. If you would like access as you are describing then > please contact one of us and we can generate an ssh key on hongkong so > that you can login to the builders without a password. I believe this option > was offered by one of my co-workers but was denied by a certain person so > ya. :/ I don't want access, I've never requested access and I've never been offered access to it. I'm quite happy with that situation. Dennis has access and always has had access and there were particular build hosts that he couldn't access where he could access others and should be able to access all of them. So this is a corner case for specific hosts which obviously have missing bits in their bcfg2 config or something (pure speculation here). The only real issue I have with all of the above is communication it's the only real problem I've ever had and something I've asked people to be aware of regularly whether it be communication about maintenance, acknowledgement of an issue and who it working on it and when it's fixed. The reason I bought this up is because it seems like a black hole at the moment. This is not directed at anyone in particular but is a general observation. If your not sure what I'm asking please ask me and I'll give you as much information and direction I can to help out. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fix for prelink
And pushed, it should with luck appear in today's compose. Peter On Thu, Nov 29, 2012 at 6:31 AM, Jon Masters wrote: > Hi everyone, > > I have the following interim fix for prelink, until we get upstream > prelink to recognize that there might be two different possible linker > paths on the same architecture. It's trivially correct, and described > within the patch below. Tested. > > Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Raspberry Pi Fedora Remix 18
On Thu, Nov 29, 2012 at 9:03 AM, Matthieu Pupat wrote: > On 11/29/2012 6:20 AM, Chris Tyler wrote: >> >> And... just to help clarify who is who and does what here, I've done a >> long-overdue blog post to introduce the current team members: >> http://blog.chris.tylers.info/index.php?/archives/268-.html -- Chris >> ___ arm mailing list >> arm@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/arm > > > Hello, > > I see on that list that Andrew Green is testing Raspberry Pi Fedora Remix > 18. Is this available somewhere? > > Aditionnaly are there any plans (or limitations) to merge the > raspberrypi-kernel and ARM kernel? No, when all the raspberry pi kernel support lands upstream we will add support for it in the mainline kernel. The first bits of that landed in 3.7 but its not yet usable. I expect it will likely 3.9+ and as I enable more platforms in the mainline kernel I'll be announcing them to the ARM list because I want people to test them :-) Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fix for Multiplatform F19 kernels
On Thu, Nov 29, 2012 at 8:09 AM, Jon Masters wrote: > Hi Peter, > > Please take a look at the attached. Note that the default kernel variant > is actually a versatile, and you weren't inheriting that. Also, we need > to set the V6_V7 multiplatform option because the current Kconfig logic > will otherwise enable AUTO CPU support, which will force us to have a V5 > kernel. So take a look. I'll be online later. > > Tested with a cross compiler only, but it built. A couple of things: This is incorrect as we've uncoupled the unified from the rest of the kernel to simplify and clean up the build. -temp-armv7l-versatile: config-arm-versatile temp-arm-generic +temp-armv7l-versatile: config-armv7 config-arm-versatile temp-arm-generic Apologies for this one as I assumed the V7 multi would depend or automatically set this and it wasn't in the original unified config from Arnd. +CONFIG_CPU_V7=y And I removed this as I assumed "CONFIG_ARCH_MULTI_V7" was all we wanted for a V7 kernel. +CONFIG_ARCH_MULTI_V6_V7=y Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting minutes 2012-11-28
On Wed, Nov 28, 2012 at 10:22 PM, Paul Whalen wrote: > Good day all, > > Thanks to those who were able to join us for the weekly status meeting today. > For those that were unable, the minutes are posted below: > > Minutes: > http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.html > Minutes (text): > http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.txt > Log: > http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.log.html A couple of things: 1) Who has the action item to deal with the texlive build? This is a beta blocker. 2) Mirror sync missing packages: do we have examples? Might be a tagging issue. 3) For F18 the kernel will remain as it is (ie there will be no unified kernel) but that doesn't preclude people from testing the F-19 unified kernels on F-18. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] precedence of built-in vs. platform trees?
On Thu, Nov 29, 2012 at 01:39:56AM -0500, Jon Masters wrote: > Hey guys, > > I apologize if I should have RTFM. If a platform provides a device tree > at boot time, and the kernel also has a tree appended, what behavior is > supposed to happen? i.e. what is the standard that is anticipated here? From the kernel config help on CONFIG_ARM_APPENDED_DTB: <<< This is meant as a backward compatibility convenience for those systems with a bootloader that can't be upgraded to accommodate the documented boot protocol using a device tree. >>> and <<< Do not leave this option active in a production kernel if you don't intend to always append a DTB. >>> Meaning that if the loader supports passing DTB, the kernel shouldn't have an appended one. Apart from that, if you use an appended DTB, this completely overrides any DTB passed by the loader, so (unless you also enable the unholy CONFIG_ARM_ATAG_DTB_COMPAT) you also lose the ability to pass kernel command line options from the loader. / Leif ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting minutes 2012-11-28
On 11/29/2012 03:53 AM, Peter Robinson wrote: On Wed, Nov 28, 2012 at 10:22 PM, Paul Whalen wrote: Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.log.html A couple of things: 1) Who has the action item to deal with the texlive build? This is a beta blocker. 2) Mirror sync missing packages: do we have examples? Might be a tagging issue. The issue I was seeing was unsigned packages on the mirrors, i.e., Package kernel-tegra-3.6.7-5.fc18.armv7hl.rpm is not signed For a normal install, I can work around it (--nogpgcheck), but it causes image creation using livemedia-creator to fail. I saw some missing packages on mirrors a weeks or so ago, but that seems to be resolved. It was probably just a transient issue (caught the mirrors in the middle of a sync). d.marlin === 3) For F18 the kernel will remain as it is (ie there will be no unified kernel) but that doesn't preclude people from testing the F-19 unified kernels on F-18. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Daily Koji Compare Stats
Thu Nov 29 09:05:01 EST 2012 f17-updates : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 2659 |0 | 273 |1 | 320 | 313 | http://142.204.133.82/jon/koji/kc.f17-updates.diff.html f18 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 12176 |4 | 109 |4 | 293 | 181 | http://142.204.133.82/jon/koji/kc.f18.diff.html f18-updates-testing : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 2718 |4 | 81 |0 | 173 | 88 | http://142.204.133.82/jon/koji/kc.f18-updates-testing.diff.html f19 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 10868 | 18 | 1482 |4 | 320 | 2364 | http://142.204.133.82/jon/koji/kc.f19.diff.html ARM Build Status Wiki: https://fedoraproject.org/wiki/Architectures/ARM https://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide Thu Nov 29 09:55:26 EST 2012 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fix for Multiplatform F19 kernels
On 11/29/2012 04:32 AM, Peter Robinson wrote: > On Thu, Nov 29, 2012 at 8:09 AM, Jon Masters wrote: >> Hi Peter, >> >> Please take a look at the attached. Note that the default kernel variant >> is actually a versatile, and you weren't inheriting that. Also, we need >> to set the V6_V7 multiplatform option because the current Kconfig logic >> will otherwise enable AUTO CPU support, which will force us to have a V5 >> kernel. So take a look. I'll be online later. >> >> Tested with a cross compiler only, but it built. > > A couple of things: > > This is incorrect as we've uncoupled the unified from the rest of the > kernel to simplify and clean up the build. > -temp-armv7l-versatile: config-arm-versatile temp-arm-generic > +temp-armv7l-versatile: config-armv7 config-arm-versatile temp-arm-generic But, the unified kernel is the default kernel, right? As in kernel- is the unified kernel? That one is currently a versatile kernel. It is, if you look in Makefile.config pulling its config from the versatile config files per the above, which without explicitly pulling in config-armv7 means that you get whatever versatile turns on for you, and certainly none of the intended config-armv7 bits. Unless I am missing something, there's a bug in the existing config merging that is actually the root cause here. Please explain what you are trying to do with joining these if I am wrong. > Apologies for this one as I assumed the V7 multi would depend or > automatically set this and it wasn't in the original unified config > from Arnd. > +CONFIG_CPU_V7=y It wasn't clear this was always the case from looking at the logic. > And I removed this as I assumed "CONFIG_ARCH_MULTI_V7" was all we > wanted for a V7 kernel. > +CONFIG_ARCH_MULTI_V6_V7=y Yea, that one is definitely something we need to set. Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Issue Tracker for Seneca Infra/RPFR
I've set up a trac instance at Seneca for people to file issues with our Koji, infrastructure, or any other problems that may arise. You can check it out at http://trac.proximity.on.ca/projects/fedoraarm Additonally, I've set up a RPFR Trac instance as well. That is at http://trac.proximity.on.ca/projects/rpfr. If you have any questions, comments or suggestions regarding these instances, let me know. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Issue Tracker for Seneca Infra/RPFR
On 11/29/2012 12:14 PM, Jordan Cwang wrote: I've set up a trac instance at Seneca for people to file issues with our Koji, infrastructure, or any other problems that may arise. You can check it out at http://trac.proximity.on.ca/projects/fedoraarm Additonally, I've set up a RPFR Trac instance as well. That is at http://trac.proximity.on.ca/projects/rpfr. If you have any questions, comments or suggestions regarding these instances, let me know. Please put links to this on the Fedora ARM wiki. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Issue Tracker for Seneca Infra/RPFR
Done and done. From: arm-boun...@lists.fedoraproject.org [arm-boun...@lists.fedoraproject.org] on behalf of Brendan Conoboy [b...@redhat.com] Sent: Thursday, November 29, 2012 3:18 PM To: arm@lists.fedoraproject.org Subject: Re: [fedora-arm] Issue Tracker for Seneca Infra/RPFR On 11/29/2012 12:14 PM, Jordan Cwang wrote: > I've set up a trac instance at Seneca for people to file issues with our > Koji, infrastructure, or any other problems that may arise. You can > check it out at http://trac.proximity.on.ca/projects/fedoraarm > > Additonally, I've set up a RPFR Trac instance as well. That is at > http://trac.proximity.on.ca/projects/rpfr. > > If you have any questions, comments or suggestions regarding these > instances, let me know. Please put links to this on the Fedora ARM wiki. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Issue Tracker for Seneca Infra/RPFR
Hey Jordan, and Chris, and everyone, This is great. Thanks so much! Jon. -- Sent from my phone. Please excuse formatting and brevity. Jordan Cwang wrote: I've set up a trac instance at Seneca for people to file issues with our Koji, infrastructure, or any other problems that may arise. You can check it out at http://trac.proximity.on.ca/projects/fedoraarm Additonally, I've set up a RPFR Trac instance as well. That is at http://trac.proximity.on.ca/projects/rpfr. If you have any questions, comments or suggestions regarding these instances, let me know. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
