Re: [fedora-arm] ARMv8 Bootstrap Project
On 11/27/2012 11:28 PM, Jon Masters wrote: On 11/27/2012 06:00 PM, Al Stone wrote: Or, perhaps we can standardize on a location ... ? /srv/nfs-root or something? Please do generate an image assuming something like that. /srv is the FHS location and we should encourage standards at all costs. I would recommend the subpath being something like fedora-armv8-bootstrap or similarly obnoxiously specific, but I won't bikeshed it too much :) Please keep in mind that we (in GES) will need to be able to set this up in the farm, so we probably need to include $USER in the path, or some other way to make it user-specific so we don't step on each other. d.marlin === Then, we can do some generic instructions using a bind mount or whatever folks prefer to have that location point to wherever they actually have the bits stashed. Jon. ___ 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
Wed Nov 28 09:05:01 EST 2012 f17-updates : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 2651 |0 | 268 |1 | 319 | 304 | http://142.204.133.82/jon/koji/kc.f17-updates.diff.html f18 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 12145 |3 | 120 |4 | 293 | 194 | http://142.204.133.82/jon/koji/kc.f18.diff.html f18-updates-testing : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 2673 |3 | 99 |0 | 187 | 106 | http://142.204.133.82/jon/koji/kc.f18-updates-testing.diff.html f19 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 10855 | 18 | 1487 |4 | 324 | 2374 | 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 Wed Nov 28 09:57:58 EST 2012 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Undefined symbol in F18 build
$ emacs emacs: symbol lookup error: /lib/libEGL.so.1: undefined symbol: wl_registry_interface This seems to be due to Wayland being pulled in by something. I've attached the ld.so trace. Andrew. 6690: 6690: file=libgtk-3.so.0 [0]; needed by emacs [0] 6690: file=libgtk-3.so.0 [0]; generating link map 6690: dynamic: 0xb6f03e6c base: 0xb6afe000 size: 0x0040a2a8 6690: entry: 0xb6b52c90 phdr: 0xb6afe034 phnum: 7 6690: 6690: 6690: file=libgdk-3.so.0 [0]; needed by emacs [0] 6690: file=libgdk-3.so.0 [0]; generating link map 6690: dynamic: 0xb6afce70 base: 0xb6a9 size: 0x0006dd98 6690: entry: 0xb6aa1c98 phdr: 0xb6a90034 phnum: 7 6690: 6690: 6690: file=libatk-1.0.so.0 [0]; needed by emacs [0] 6690: file=libatk-1.0.so.0 [0]; generating link map 6690: dynamic: 0xb6a8ef00 base: 0xb6a6c000 size: 0x00023644 6690: entry: 0xb6a72838 phdr: 0xb6a6c034 phnum: 7 6690: 6690: 6690: file=libgio-2.0.so.0 [0]; needed by emacs [0] 6690: file=libgio-2.0.so.0 [0]; generating link map 6690: dynamic: 0xb6a69eb0 base: 0xb6946000 size: 0x00125bdc 6690: entry: 0xb6969950 phdr: 0xb6946034 phnum: 7 6690: 6690: 6690: file=libpangocairo-1.0.so.0 [0]; needed by emacs [0] 6690: file=libpangocairo-1.0.so.0 [0]; generating link map 6690: dynamic: 0xb6944ea8 base: 0xb6934000 size: 0x00011340 6690: entry: 0xb69374e8 phdr: 0xb6934034 phnum: 7 6690: 6690: 6690: file=libgdk_pixbuf-2.0.so.0 [0]; needed by emacs [0] 6690: file=libgdk_pixbuf-2.0.so.0 [0]; generating link map 6690: dynamic: 0xb6932ec8 base: 0xb690d000 size: 0x00026474 6690: entry: 0xb6911a98 phdr: 0xb690d034 phnum: 7 6690: 6690: 6690: file=libcairo-gobject.so.2 [0]; needed by emacs [0] 6690: file=libcairo-gobject.so.2 [0]; generating link map 6690: dynamic: 0xb690be70 base: 0xb68fe000 size: 0xe108 6690: entry: 0xb68ffc30 phdr: 0xb68fe034 phnum: 7 6690: 6690: 6690: file=libpango-1.0.so.0 [0]; needed by emacs [0] 6690: file=libpango-1.0.so.0 [0]; generating link map 6690: dynamic: 0xb68fced8 base: 0xb68b5000 size: 0x0004889c 6690: entry: 0xb68bee80 phdr: 0xb68b5034 phnum: 7 6690: 6690: 6690: file=libcairo.so.2 [0]; needed by emacs [0] 6690: file=libcairo.so.2 [0]; generating link map 6690: dynamic: 0xb68b2e80 base: 0xb67d1000 size: 0x000e353c 6690: entry: 0xb67dd700 phdr: 0xb67d1034 phnum: 7 6690: 6690: 6690: file=libgobject-2.0.so.0 [0]; needed by emacs [0] 6690: file=libgobject-2.0.so.0 [0]; generating link map 6690: dynamic: 0xb67cfee0 base: 0xb6784000 size: 0x0004ca80 6690: entry: 0xb678bcf8 phdr: 0xb6784034 phnum: 7 6690: 6690: 6690: file=libglib-2.0.so.0 [0]; needed by emacs [0] 6690: file=libglib-2.0.so.0 [0]; generating link map 6690: dynamic: 0xb6782ef8 base: 0xb6674000 size: 0x0010fcc4 6690: entry: 0xb6688ce8 phdr: 0xb6674034 phnum: 7 6690: 6690: 6690: file=libSM.so.6 [0]; needed by emacs [0] 6690: file=libSM.so.6 [0]; generating link map 6690: dynamic: 0xb6672ef8 base: 0xb6665000 size: 0xe114 6690: entry: 0xb52c phdr: 0xb6665034 phnum: 7 6690: 6690: 6690: file=libICE.so.6 [0]; needed by emacs [0] 6690: file=libICE.so.6 [0]; generating link map 6690: dynamic: 0xb6661f08 base: 0xb6647000 size: 0x0001d208 6690: entry: 0xb664a4dc phdr: 0xb6647034 phnum: 7 6690: 6690: 6690: file=libtiff.so.5 [0]; needed by emacs [0] 6690: file=libtiff.so.5 [0]; generating link map 6690: dynamic: 0xb6643ed8 base: 0xb65d9000 size: 0x0006d3cc 6690: entry: 0xb65de3e0 phdr: 0xb65d9034 phnum: 7 6690: 6690: 6690: file=libjpeg.so.62 [0]; needed by emacs [0] 6690: file=libjpeg.so.62 [0]; generating link map 6690: dynamic: 0xb65c7ef8 base: 0xb6593000 size: 0x00045248 6690: entry: 0xb6595770 phdr: 0xb6593034 phnum: 7 6690: 6690: 6690: file=libpng15.so.15 [0]; needed by emacs [0] 6690: file=libpng15.so.15 [0]; generating
Re: [fedora-arm] Undefined symbol in F18 build
Andrew Haley píše v St 28. 11. 2012 v 17:31 +: $ emacs emacs: symbol lookup error: /lib/libEGL.so.1: undefined symbol: wl_registry_interface This seems to be due to Wayland being pulled in by something. I've attached the ld.so trace. I think is because old mesa build is in the repositories while new wayland is there too Dan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora ARM weekly status meeting - 2012-11-28
Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday Nov 28th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Current Problem packages 2) F18 ARM Beta - target release date, vfad planning, Raspberry Pi 3) Kirkwood image testing - volunteers? 4) 3.7 Kernel and Device tree - support plan 5) Mirror syncing 6) Your topic here If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting - 2012-11-28
I'm not going to be able to make the meeting. This weeks Fedora ARM status meeting will take place today (Wednesday Nov 28th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Current Problem packages texlive and ruby for both rawhide and F-18 are the current blockers. The former is critical for rawhide and becoming more so for F-18. 2) F18 ARM Beta - target release date, vfad planning, Raspberry Pi The Raspberry is completely unrelated to mainline beta and as a result should be uncoupled from this item. 3) Kirkwood image testing - volunteers? 4) 3.7 Kernel and Device tree - support plan I've a build issue with rc7 that I'm been working with jonmasters on to resolve. Should have rc7 RSN. 5) Mirror syncing 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 - 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? - 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? - 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? Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting - 2012-11-28
On 11/28/2012 02:28 PM, Peter Robinson wrote: 4) 3.7 Kernel and Device tree - support plan I've a build issue with rc7 that I'm been working with jonmasters on to resolve. Should have rc7 RSN. Yea. I'm on the hook for coming back about this before Friday. Hopefully in time for tomorrow. Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting - 2012-11-28
On Wed, Nov 28, 2012 at 7:56 PM, Jon Masters j...@redhat.com wrote: On 11/28/2012 02:28 PM, Peter Robinson wrote: 4) 3.7 Kernel and Device tree - support plan I've a build issue with rc7 that I'm been working with jonmasters on to resolve. Should have rc7 RSN. Yea. I'm on the hook for coming back about this before Friday. Hopefully in time for tomorrow. http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1268171 It's built on all but armv7l which should be the same as armv7hl so I think it's transient to the host.. I'll be pushing a new one soon once I get off this conference call. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora ARM weekly status meeting minutes 2012-11-28
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 Paul ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Regarding Seneca Issues
On 11/28/2012 12:45 PM, Jon Chiappetta wrote: - 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? - 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 common theme here: Issues are coming up and there isn't an obvious way to report them, track them, or otherwise make sure they're resolved, much less documented. We need to fix that. - 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. :/ Don't really understand this. I'm sorry if it seems like I'm not following along here in close detail but our team has various other projects that we are working on simultaneously and sometimes we don't have time to monitor in close detail what exactly is happening in the farm. If you're able to point out specific examples of something failing and highlight all of our names in channel, I will at least definitely be able to see who it is and what is happening, hopefully. This doesn't scale well. The contact names change on a somewhat regular basis and #fedora-arm and #seneca are not support trackers- they're chat channels running 24/7, hours we do not any of us keep. What's needed is a consistent point of contact, whether it be a bot, a web tracker, a separate mailing list, or some other mechanism. Suggestions welcome! -- 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] Regarding Seneca Issues
On 11/28/2012 09:59 PM, Brendan Conoboy wrote: On 11/28/2012 12:45 PM, Jon Chiappetta wrote: - 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? - 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 common theme here: Issues are coming up and there isn't an obvious way to report them, track them, or otherwise make sure they're resolved, much less documented. We need to fix that. Let me jump in here... Thing is, and not speaking for Brendan, but I'm sure he agrees. None of this is personal or meant to detract from the great work being done at Seneca. You guys have been great, and I know that sometimes we all get a bit frustrated, and even ranty on IRC. Let's try this though. As custodians of Koji you get an awesome new project, which is to figure out the best way to do change tracking and notification of outages and the like. Perhaps someone could take that on as a project exercise? Heck, I'd give huge course credit - these are hard problems! :) Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Regarding Seneca Issues
On Wed, 2012-11-28 at 23:17 -0500, Jon Masters wrote: Thing is, and not speaking for Brendan, but I'm sure he agrees. None of this is personal or meant to detract from the great work being done at Seneca. You guys have been great, and I know that sometimes we all get a bit frustrated, and even ranty on IRC. Let's try this though. As custodians of Koji you get an awesome new project, which is to figure out the best way to do change tracking and notification of outages and the like. This isn't that complicated :-) We're going to try a Trac instance connected to our team email - watch for URLs tomorrow. 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
[fedora-arm] precedence of built-in vs. platform trees?
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? Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
