Re: XFS rootfs required?
On Mon, 2012-03-19 at 23:52 -0600, Chris Murphy wrote: It's not an option with Fedora-17-Beta-TC2-x86_64-DVD.iso. I don't see anything listed in alpha, beta, or final release criteria that requires it, but it's been a past option. Summary is that mkfs.xfs isn't present on the DVD media, at least for x86_64. Bug here: https://bugzilla.redhat.com/show_bug.cgi?id=804779 For General Tests, Final release level, I see an XFS test case here: https://fedoraproject.org/wiki/QA:Testcase_anaconda_xfs_rootfs_on_disk_partition This is a very close call. The relevant release criterion would be Final: The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above I guess under a strict interpretation, it fails to meet the criterion, because the *consequence* of the bug is that XFS is not 'offered' as a file system by the installer. You could take the view, however, that it's clearly _intended_ to be offered. I'd probably incline to the first view, because the idea behind the criterion is that you shouldn't be able to paint yourself into a corner with the installer - you shouldn't be able to pick an option that doesn't work. But it's a close call. It's probably worth proposing it and having the discussion. In any case, obviously, it should get fixed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
It is time for another episode of: NAME THAT FEDORA RELEASE
Oh, Beefy Miracle, I have relished your name for months, but as your day for widespread consumption (release day) approaches, it is time for the community to choose the name of Fedora 18. This process begins with *you,* dear readers and contributors, as potential names are accepted for submission over the course of the next week, beginning now, March 20th, and ending March 27th (at 23:59:59 UTC, for those of you who can't mustard up any ideas until the last possible second). Frankly, I'm expecting an a-bun-dance of suggestions, and not just from people who cannot take my punni-ness any longer. Rules and guidelines for suggestions, as well as the location in which you may make your name suggestions, are on this wiki page: http://fedoraproject.org/wiki/Name_suggestions_for_Fedora_18 A quick word on details: You *must* follow the guidelines at the page listed above for your name to be considered. These guidelines include the following items: * There must be an is-a link between the name Beefy Miracle (the name of F17) and your suggested name. * That link must be different from any previous links between release names. * Names of living people and well-known trademarks will likely be rejected as well. Schedule details for release naming are also shown on the F18 naming wiki page. I know that it may be hard to *top* Beefy Miracle (ahahahaha, get it? As in toppings!) but I do have every bit of faith that many of you have already thought of name suggestions that may or may not be more mature, or more neutral with regards to dietary restrictions. :) I do look forward to seeing your suggested names and recommend, as always, to have fun. Cheers, -Robyn ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On Mon, 2012-03-19 at 23:06 -0500, Mike Chambers wrote: Does setting emails in your inbox folder to junk working automatically? It seem it doesn't do it automatically and I have to keep selecting them and manually marking them junk. On a fresh install (such as this one), I do a restore from a backup file as I always do, to include doiong the same thing in F16 (that worked just fine) and the settings are there, and set as suppose to be. Also evolution-bogofilter is installed as well. Just for some reason it's not setting them to junk automatically. Any ideas? evolution-bogofilter-3.3.91-1.fc17.x86_64 evolution-3.3.91-1.fc17.x86_64 bogofilter-1.2.2-3.fc17.x86_64 Hi, evolution's backup doesn't contain your bogofilter database, it's stored in a bogofilter private directory, thus I guess you need to train it again? Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
Josh Boyer wrote on 20.03.2012 02:26: On Mon, Mar 19, 2012 at 3:46 PM, Jon Ciesla limburg...@gmail.com wrote: * #830 F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM (limburgher, 18:44:13) * LINK: http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers (nirik, 18:45:42) * AGREED: ask qa, rel-eng, kernel and infra teams to provide feedback on the proposal. Ask fesco members to come up with critera that they would want to add and revisit next week. (+8,-:0,0:0) (limburgher, 19:09:50) It's fairly disappointing this was discussed during this meeting without being on the agenda that was sent out. This is a rather large item that needs a lot of discussion among the various groups in Fedora, and I'm sure that I'm not the only person that wasn't aware it was even going to be in the meeting today. (Even ignoring the fact that the agenda was sent without a proper Subject and easily skipped.) +1 From my point of view the root of the problem is: Crucial information is spread over way to many places which makes it hard to stay on top. If you want to be aware of what happens in Fedora land, that you afaics have to keep an eye on - this list and at least fab-list - parts of the wiki, which is really hard (for example there is afaics no easy way to just follow the pages that are used to track new Features ) - the talk pages to those wiki pages (see yesterdays discussion about the proposed kernel-module, where I missed to look there) - the tickets in trac (like the one for Fesco meetings) - and ideally IRC and some more lists I have no real idea how to fix this, but I tend to say we need to way better make sure that important information and discussion get on this list in a easy consumable way(¹), as that's the only place where everybody looks. Sure, that can lead to a heated discussion, but then let's deal with it. CU knurd (¹) it for example always annoys me a little bit that there are no direct links to the trac tickets in which FESCo tracks the issues it wants to discuss in a meeting -- I know how to find them and it's just one or two additional clicks, but those are a little bit annoying -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 versions of python-celery / django-celery
Hi, I noticed that the versions of python-celery (2.2.8 vs. 2.5.1) and django-celery (2.2.7 vs. 2.5.1) in rawhide/F17 are both far behind the current version. Is there a technical reason for this? -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: rpm 4.10.0 alpha to hit rawhide shortly
As http://fedoraproject.org/wiki/Features/RPM4.10 got accepted in yesterday's FESCo meeting, here come the bits. For details see http://rpm.org/wiki/Releases/4.10.0, but the bottom line is that for business-as-usual operations you shouldn't really notice much anything at all. Well, apart from cleanup-erasure progress being visible if you use rpm cli instead of yum to upgrade packages. Just watch out for anomalies and report them ... as usual. As there's a soname bump involved, the following packages will need a rebuild. It should be just a straightforward bump+rebuild for all these. If a build that succeeds with rpm-4.9.x fails with rpm-4.10.x then its likely a bug in rpm (or then the software is playing with some very dark corners of librpm): abrt-team abrt abrt-team libreport anaconda-maint anaconda athimm apt ensclibextractor fchesystemtap ivaxer opensips jcollie asterisk jdieter deltarpm jsafranenet-snmp kklic libsolv lkundrakovaldi mlichvarrpmreaper mmaslanoperl-RPM2 mprivoznlibvirt-snmp peter openser ppisar perl-RPM-VersionCompare pvrabec openscap pvrabec sectool rhughes PackageKit rhughes zif rmeggins389-ds-base rohara foghorn sharkcz openhpi-subagent - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 versions of python-celery / django-celery
Hi, I filed a ticket 2 months ago, it requires a few dependencies to be updated too (besides some of them brings python3 support) https://bugzilla.redhat.com/show_bug.cgi?id=785607 best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 versions of python-celery / django-celery
On Tue, Mar 20, 2012 at 10:54:41AM +0100, 80 wrote: I filed a ticket 2 months ago, it requires a few dependencies to be updated too (besides some of them brings python3 support) https://bugzilla.redhat.com/show_bug.cgi?id=785607 OK, I filed bugs too now (for python-celery, django-celery, and now also for rabbitmq-server, that is also far behind), as I didn't see yours (only looked in F17, my fault). -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: rpm 4.10.0 alpha to hit rawhide shortly
On 03/20/2012 11:52 AM, Panu Matilainen wrote: As http://fedoraproject.org/wiki/Features/RPM4.10 got accepted in yesterday's FESCo meeting, here come the bits. For details see http://rpm.org/wiki/Releases/4.10.0, but the bottom line is that for business-as-usual operations you shouldn't really notice much anything at all. Well, apart from cleanup-erasure progress being visible if you use rpm cli instead of yum to upgrade packages. Just watch out for anomalies and report them ... as usual. So... first hickup that broke koji: the buildroot now requires deltarpm which needs rebuilding due to to the soname bump before we can proceed. I dont recall this being an issue before but I guess that's called progress :) I've untagged the alpha from rawhide until we get that sorted out. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: rpm 4.10.0 alpha to hit rawhide shortly
On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote: So... first hickup that broke koji: the buildroot now requires deltarpm which needs rebuilding due to to the soname bump before we can proceed. I dont recall this being an issue before but I guess that's called progress :) Why does the buildroot require deltarpm? Are deltarpms now being generated during builds instead of at compose time? Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non responsive maintainer: lkundrak
Hi, Does someone know how to contact lkundrak ? I have requested a jgraphx update (scilab dependency) for months. Account Name: lkundrak Full Name: Lubomir Rintel Email: lkund...@v3.sk IRC Nick: lkundrak Account Status: Active Bug: (open 2011-10-15, ping 2011-10-24, 2011-12-13, 2012-02-09, 2012-03-13) https://bugzilla.redhat.com/show_bug.cgi?id=746391 Direct request for co-maintainer via pkgdg without answer. Direct email without answer. Without response, I would like to take ownership of jgraphx (scilab direct dependency) Clément davidcl DAVID -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On 03/20/2012 01:06 AM, Mike Chambers wrote: Does setting emails in your inbox folder to junk working automatically? It seem it doesn't do it automatically and I have to keep selecting them and manually marking them junk. On a fresh install (such as this one), I do a restore from a backup file as I always do, to include doiong the same thing in F16 (that worked just fine) and the settings are there, and set as suppose to be. Also evolution-bogofilter is installed as well. Just for some reason it's not setting them to junk automatically. Any ideas? evolution-bogofilter-3.3.91-1.fc17.x86_64 evolution-3.3.91-1.fc17.x86_64 bogofilter-1.2.2-3.fc17.x86_64 I have configured a pop3 account for the email of my institution, and I also have to select each spam mail manually because only some of them go to junk automatically... but I use spamassassin. This is irritating, because I have to do it all the time. I also see that you are using Fedora 17. -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive maintainer: lkundrak
On Tue, 2012-03-20 at 13:37 +0100, Clément David wrote: Hi, Does someone know how to contact lkundrak ? $ ./fedora_active_user.py --user lkundrak --email lkund...@v3.sk Last login in FAS: lkundrak 2012-03-20 Last action on koji: Tue, 21 Feb 2012 package list entry created: perl-OpenOffice-UNO in dist-6E-epel by pkgdb [still active] Last package update on bodhi: 2012-02-20 13:33:05 on package perl-Net-IRC-0.79-3.el6 658 bugs assigned or cc to lkund...@v3.sk Bugzilla information: [...] He seems to still be around and based on the number of bugs assigned or cc to him, he might just be busy. When did you request acl on pkgdb? Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive maintainer: lkundrak
On Tue, Mar 20, 2012 at 7:46 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, 2012-03-20 at 13:37 +0100, Clément David wrote: Hi, Does someone know how to contact lkundrak ? $ ./fedora_active_user.py --user lkundrak --email lkund...@v3.sk Last login in FAS: lkundrak 2012-03-20 Last action on koji: Tue, 21 Feb 2012 package list entry created: perl-OpenOffice-UNO in dist-6E-epel by pkgdb [still active] Last package update on bodhi: 2012-02-20 13:33:05 on package perl-Net-IRC-0.79-3.el6 658 bugs assigned or cc to lkund...@v3.sk Bugzilla information: [...] He seems to still be around and based on the number of bugs assigned or cc to him, he might just be busy. When did you request acl on pkgdb? He's usually pretty busy, and has in the past been receptive to co-maintainers. If you need assistance, I doubt he'd object to reasonable actions being taken be provenpackagers. If you need one for that purpose, I can help. -J Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive maintainer: lkundrak
Hi, Right, it was busy. I got the ACLs for co-maintaining jgraphx now. PS: that was just a gentle ACLs reminder :) Clément Le 20/03/2012 13:50, Jon Ciesla a écrit : On Tue, Mar 20, 2012 at 7:46 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, 2012-03-20 at 13:37 +0100, Clément David wrote: Hi, Does someone know how to contact lkundrak ? $ ./fedora_active_user.py --user lkundrak --email lkund...@v3.sk Last login in FAS: lkundrak 2012-03-20 Last action on koji: Tue, 21 Feb 2012 package list entry created: perl-OpenOffice-UNO in dist-6E-epel by pkgdb [still active] Last package update on bodhi: 2012-02-20 13:33:05 on package perl-Net-IRC-0.79-3.el6 658 bugs assigned or cc to lkund...@v3.sk Bugzilla information: [...] He seems to still be around and based on the number of bugs assigned or cc to him, he might just be busy. When did you request acl on pkgdb? He's usually pretty busy, and has in the past been receptive to co-maintainers. If you need assistance, I doubt he'd object to reasonable actions being taken be provenpackagers. If you need one for that purpose, I can help. -J Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gsoc - Need a mentor - Integrate Proxy Settings and Network Connections(Locations)
Hello Folks, Students are starting inquiring about the GSOC project ideas we listed on the wiki[0]. But unfortunately some idea dont have a primary mentor. If any one is interested in following idea[1] which is dealing with networking, please take it. Please treat this request as urgent. The list should be cleared (ideas with no mentors) once the students application period has started. More details about mentoring can be found here[2]. Thanks for the support. [0] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012 [1] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Integrate_Proxy_Settings_and_Network_Connections.28Locations.29 [2] http://www.flossmanuals.net/gsocmentoring/ -- Regards, Buddhike Chandradeepa Kurera(bckurera) Fedora Ambassador Sri Lanka Event Liaison - Design Team Org Admin - Fedora - GSoC 2012 Email: bckur...@fedoraproject.org | IRC: bckurera -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Slow shutdown with big file in /dev/shm
On 3/19/12 11:42 PM, Bojan Smojver wrote: Before I file a bug for this, I need to figure out which component may be doing this. If one creates a large file (several GB) in /dev/shm and shuts down, the system will take many minutes to shut down. Last message before hang is Disabling swap. Not sure which component is doing that and why. The file will be gone on reboot anyway, so why not just nuke it... Presumably because that file got paged out. Think about it. Disabling swap doesn't know that the file exists only on a RAM-based file system, and even if it did, doesn't know that we're about to shut down. So swapoff has to assume that any pages currently in the swap area being disabled might be valuable, and has to read them back into memory. Now as to why we disable swap on shutdown, I'm not really sure. It certainly seems like useless work to me. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Slow shutdown with big file in /dev/shm
Adam Jackson a...@redhat.com wrote: Presumably because that file got paged out. Think about it. Disabling swap doesn't know that the file exists only on a RAM-based file system, and even if it did, doesn't know that we're about to shut down. So swapoff has to assume that any pages currently in the swap area being disabled might be valuable, and has to read them back into memory. Now as to why we disable swap on shutdown, I'm not really sure. It certainly seems like useless work to me. Would it help if all memory based file systems got unmounted before swap gets disabled? That would kill these files, right? -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Slow shutdown with big file in /dev/shm
Adam Jackson wrote: Now as to why we disable swap on shutdown, I'm not really sure. It certainly seems like useless work to me. We want to be sure we'll be able to stop/disassemble any block devices that are underneath it (RAID arrays etc.). Sure, if it's a simple partition, the work is useless. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: /etc/default in Fedora
On 03/19/2012 03:28 PM, Daniel J Walsh wrote: On 03/19/2012 10:36 AM, Michael Cronenworth wrote: Daniel J Walsh wrote: We could put the info into systemd-journal. Back when sendmail and logwatch were part of the default install, it would have been nice to have SELinux activity reported in it. I still use logwatch so it would still be useful for me to see log data there. Unless, of course, logwatch is obsolete and there's some new, flashy systemd mail log that I'm supposed to be using that I wasn't told of. Well setroubleshoot-server does write to syslog when it interprets and AVC. On 03/19/2012 03:37 PM, Michał Piotrowski wrote: W dniu 19 marca 2012 15:27 użytkownik Daniel J Walsh dwa...@redhat.com napisał: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2012 10:16 AM, Michał Piotrowski wrote: setroubleshoot-server is the server componant. (dbus service) setroubleshoot is the client componant. We could put the info into systemd-journal. It would be great if there was a possibility to send logs to other machines. Lennart, what do you think about it? Centralized log system is nice feature. Why not use rsyslog? It certainly supports forwarding messages over network with something as simple as: /etc/rsyslog.d/remote.conf: :msg,contains,avc: @@central-box You can consume the audit logs with the imfile input module and send out messages as emails with ommail output module. This is an existing infrastructure that you can probably leverage to solve your use case. Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: rpm 4.10.0 alpha to hit rawhide shortly
On 03/20/2012 01:49 PM, Jonathan Dieter wrote: On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote: So... first hickup that broke koji: the buildroot now requires deltarpm which needs rebuilding due to to the soname bump before we can proceed. I dont recall this being an issue before but I guess that's called progress :) Why does the buildroot require deltarpm? Are deltarpms now being generated during builds instead of at compose time? No clue. It appears to get dragged in via 'yum groupinstall srpm-build' and it means chain-build doesn't work either. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Slow shutdown with big file in /dev/shm
On 3/20/12 9:19 AM, Bojan Smojver wrote: Adam Jacksona...@redhat.com wrote: Now as to why we disable swap on shutdown, I'm not really sure. It certainly seems like useless work to me. Would it help if all memory based file systems got unmounted before swap gets disabled? That would kill these files, right? Maybe. Try it and see I guess? But it still seems to me like disabling swap on shutdown is useless work. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gsoc - Need a mentor - Integrate Proxy Settings and Network Connections(Locations)
I added myself as a mentor -- Dan On 03/20/2012 08:58 AM, Buddhike Kurera wrote: Hello Folks, Students are starting inquiring about the GSOC project ideas we listed on the wiki[0]. But unfortunately some idea dont have a primary mentor. If any one is interested in following idea[1] which is dealing with networking, please take it. Please treat this request as urgent. The list should be cleared (ideas with no mentors) once the students application period has started. More details about mentoring can be found here[2]. Thanks for the support. [0] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012 [1] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Integrate_Proxy_Settings_and_Network_Connections.28Locations.29 [2] http://www.flossmanuals.net/gsocmentoring/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pyside is now an official part of qt
hi, after reading this http://www.pyside.org/2012/03/pyside-becomes-a-qt-add-on/ how is this going to affect fedora ? do we have PyQt4 apps in our repos ? are we going to patch them to be import PySide as PyQt4 or something like that -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
On Tue, Mar 20, 2012 at 03:00:39AM +0100, Kevin Kofler wrote: Josh Boyer wrote: It's fairly disappointing this was discussed during this meeting without being on the agenda that was sent out. This is a rather large item that needs a lot of discussion among the various groups in Fedora, and I'm sure that I'm not the only person that wasn't aware it was even going to be in the meeting today. (Even ignoring the fact that the agenda was sent without a proper Subject and easily skipped.) I think this should also be brought to larger discussion among packagers as a whole. ARM as a primary arch is probably going to slow down our builds by a lot, at least at the beginning. It also means it'd become the maintainer's job to fix ARM-only build failures. I think ARM should NOT become a primary arch, period. Having an actively maintained secondary arch is also the best way to keep improving secondary arch infrastructure with the aim of reducing the delays between primary arch and secondary arch releases, thereby helping all secondary arches, not just ARM (and making them all primary sure wouldn't scale). Changing ARM to a primary arch is the wrong way to get there, and puts an undue burden on Fedora maintainers as a whole, for the benefit of a small niche. I think ARM is going to be very important, especially if Raspberry Pi or similar projects take off. However you are right that (a) ARM is slow and (b) making ARM a secondary arch without a way for maintainers to *easily* get access to ARM machines to try out fixes is a quick way to encourage ExcludeArch. Also there's a whole bunch of wider questions around Fedora on ARM, beginning with the complete lack of a credible installer. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pyside is now an official part of qt
Muayyad AlSadi wrote: after reading this http://www.pyside.org/2012/03/pyside-becomes-a-qt-add-on/ how is this going to affect fedora ? Not at all. (Well, it does mean that PySide is no longer dead, which is good. But otherwise it doesn't really change anything.) do we have PyQt4 apps in our repos ? Yes. are we going to patch them to be import PySide as PyQt4 or something like that No. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
Adam Williamson wrote: If you think ARM's a small niche, you may have some large surprising coming your way over the next few years... Then we can discuss making it a primary architecture in a few years. Now it just doesn't make sense. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: rpm 4.10.0 alpha to hit rawhide shortly
On Tue, 2012-03-20 at 16:15 +0200, Panu Matilainen wrote: On 03/20/2012 01:49 PM, Jonathan Dieter wrote: On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote: So... first hickup that broke koji: the buildroot now requires deltarpm which needs rebuilding due to to the soname bump before we can proceed. I dont recall this being an issue before but I guess that's called progress :) Why does the buildroot require deltarpm? Are deltarpms now being generated during builds instead of at compose time? No clue. It appears to get dragged in via 'yum groupinstall srpm-build' and it means chain-build doesn't work either. Ok, in F16 (and I'm assuming this is also true in Rawhide; unfortunately I don't have a Rawhide tree here to test), fedpkg is in the srpm-build group, and it requires pyrpkg which requires mock which requires createrepo which requires deltarpm. I don't know how easily we can clean up these dependencies. Do we need mock in the buildroot? If not, is it possible to split pyrpkg's mock functionality into a subpackage? Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
On Tue, Mar 20, 2012 at 03:05:07PM +, Richard W.M. Jones wrote: However you are right that (a) ARM is slow and (b) making ARM a secondary arch Erm, s/secondary/PRIMARY/. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
Well, speaking for myself only, I read this as pretty much a Lets begin discussions on it. There's no way a short bit at the end of a meeting is going to allow enough discussion. So, this is just to start the ball rolling and collect feedback from everyone. No need to feel bad about not being there to give feedback at this first meeting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
On Tue, 20 Mar 2012 08:24:09 +0100 Thorsten Leemhuis fed...@leemhuis.info wrote: Josh Boyer wrote on 20.03.2012 02:26: On Mon, Mar 19, 2012 at 3:46 PM, Jon Ciesla limburg...@gmail.com wrote: * #830 F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM (limburgher, 18:44:13) * LINK: http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers (nirik, 18:45:42) * AGREED: ask qa, rel-eng, kernel and infra teams to provide feedback on the proposal. Ask fesco members to come up with critera that they would want to add and revisit next week. (+8,-:0,0:0) (limburgher, 19:09:50) It's fairly disappointing this was discussed during this meeting without being on the agenda that was sent out. This is a rather large item that needs a lot of discussion among the various groups in Fedora, and I'm sure that I'm not the only person that wasn't aware it was even going to be in the meeting today. (Even ignoring the fact that the agenda was sent without a proper Subject and easily skipped.) I really don't think it's that big a deal. It's only a get the ball rolling and have some high level discussion. I'm sure there's going to be a lot more before any decision is made and lots of feedback from lots of parts of Fedora. This affects lots of us. +1 From my point of view the root of the problem is: Crucial information is spread over way to many places which makes it hard to stay on top. If you want to be aware of what happens in Fedora land, that you afaics have to keep an eye on - this list and at least fab-list - parts of the wiki, which is really hard (for example there is afaics no easy way to just follow the pages that are used to track new Features ) - the talk pages to those wiki pages (see yesterdays discussion about the proposed kernel-module, where I missed to look there) - the tickets in trac (like the one for Fesco meetings) - and ideally IRC and some more lists I have no real idea how to fix this, but I tend to say we need to way better make sure that important information and discussion get on this list in a easy consumable way(¹), as that's the only place where everybody looks. Sure, that can lead to a heated discussion, but then let's deal with it. Yeah, I don't know of a great way to fix that either. Information is spread out because it makes sense usually to be in the place it is. I think for the mailing list at least we could try and have someone 'summarize' discussions that go for 50 posts or something. Might help those who can't read all the discussion. https://fedoraproject.org/wiki/Fedora_Engineering/FY13_Plan#Mailing_List_Improvement_Application may well help out someday. ;) CU knurd (¹) it for example always annoys me a little bit that there are no direct links to the trac tickets in which FESCo tracks the issues it wants to discuss in a meeting -- I know how to find them and it's just one or two additional clicks, but those are a little bit annoying Is: https://fedorahosted.org/fesco/report/9 not what you are looking for? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
On Tue, 2012-03-20 at 09:12 -0600, Kevin Fenzi wrote: Well, speaking for myself only, I read this as pretty much a Lets begin discussions on it. There's no way a short bit at the end of a meeting is going to allow enough discussion. So, this is just to start the ball rolling and collect feedback from everyone. No need to feel bad about not being there to give feedback at this first meeting. +1, I do not see any harm in starting the discussion on the yesterday meeting as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On Tue, 2012-03-20 at 08:04 +0100, Milan Crha wrote: On Mon, 2012-03-19 at 23:06 -0500, Mike Chambers wrote: Does setting emails in your inbox folder to junk working automatically? It seem it doesn't do it automatically and I have to keep selecting them and manually marking them junk. On a fresh install (such as this one), I do a restore from a backup file as I always do, to include doiong the same thing in F16 (that worked just fine) and the settings are there, and set as suppose to be. Also evolution-bogofilter is installed as well. Just for some reason it's not setting them to junk automatically. Any ideas? evolution-bogofilter-3.3.91-1.fc17.x86_64 evolution-3.3.91-1.fc17.x86_64 bogofilter-1.2.2-3.fc17.x86_64 Hi, evolution's backup doesn't contain your bogofilter database, it's stored in a bogofilter private directory, thus I guess you need to train it again? Yes I understand it has to relearn. But it doesn't is the problem. I had to keep marking them as junk. Example, just reinstalled F16+updates on this very box. Started evo + the backup file as a restore, just as with F17. Soon as I marked the initial spam stuff in my inbox as junk, it started marking automatically. No, it doesn't get them all the time and have to relearn as I go, but it starts to immediately. F17 does NOT do it, almost none at all, even after a couple of days of marking them. -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RFC: Primary architecture promotion requirements
This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. - Secondary architectures in Fedora are subject to looser constraints than primary architectures for two primary reasons: 1) To make it easier to bootstrap an architecture without the overhead of the primary architecture release engineering process 2) To avoid primary architecture development being held up by poorly developed or niche architectures Promoting an architecture to primary architecture status is a significant responsibility. It implies that the port is sufficiently mature that little in the way of further architecture-specific changes or rebuilds will be required, and also that it has enough development effort to avoid it delaying the development of other primary architectures. Further, it means that the architecture becomes part of the overall Fedora brand. Fedora is an integrated Linux distribution rather than a technology collection, and as such there are various expectations that the overall Fedora experience will be consistent over all primary architectures. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: 1) There must be adequate representation for the architecture on the Fedora infrastructure and release engineering teams. 2) All builds must occur on Fedora-maintained build servers. 3) Where technically possible, all supported hardware targets must be supported via Anaconda. Exceptions are limited to highly resource constrained devices or hardware which provides no means for simultaneous support of install and target media. 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. 5) Sufficient developer resources must be available to fix any architecture-specific issues in such a way that they do not delay overall Fedora development. 6) It must be possible for maintainers of critical-path hardware dependent packages to have direct access to supported hardware in order to rectify any release-blocking issues. For example, X maintainers must have direct access to any hardware with graphics capabilities. 7) The port must not rely on sourceless binaries unless they fall under the generic firmware exemption. Where source and toolchain are available, the binaries must be built in the Fedora build infrastructure. As such, promotion to primary architecture status will require agreement from the Fedora infrastructure, release engineering, kernel and installer teams and is subject to overall approval by the Fedora Steering Committee. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
Once upon a time, Kevin Fenzi ke...@scrye.com said: Well, speaking for myself only, I read this as pretty much a Lets begin discussions on it. There's no way a short bit at the end of a meeting is going to allow enough discussion. So, this is just to start the ball rolling and collect feedback from everyone. No need to feel bad about not being there to give feedback at this first meeting. Well, it was proposed as an F18 feature, which _could_ have been approved at a single meeting. Speaking as a mirror admin (granted of a smaller mirror), I don't have sufficient disk space for two new architectures (the Fedora ARM team is actually proposing two different ARM arches). I would like to see the mirrors involved in the discussion, as there may be other (and larger) mirrors that won't carry this. I'm also not really sure what the gain is for moving from secondary to primary arch. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 03:19:35PM +, Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: ... 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Of course the general requirement that builds on the architecture to be promoted must not take much longer time than builds on the current primary architectures still stays. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: rpm 4.10.0 alpha to hit rawhide shortly
On 03/20/2012 05:10 PM, Jonathan Dieter wrote: On Tue, 2012-03-20 at 16:15 +0200, Panu Matilainen wrote: On 03/20/2012 01:49 PM, Jonathan Dieter wrote: On Tue, 2012-03-20 at 13:08 +0200, Panu Matilainen wrote: So... first hickup that broke koji: the buildroot now requires deltarpm which needs rebuilding due to to the soname bump before we can proceed. I dont recall this being an issue before but I guess that's called progress :) Why does the buildroot require deltarpm? Are deltarpms now being generated during builds instead of at compose time? No clue. It appears to get dragged in via 'yum groupinstall srpm-build' and it means chain-build doesn't work either. Ok, in F16 (and I'm assuming this is also true in Rawhide; unfortunately I don't have a Rawhide tree here to test), fedpkg is in the srpm-build group, and it requires pyrpkg which requires mock which requires createrepo which requires deltarpm. Urks, that's quite a tangle. Thanks for hunting it down. I don't know how easily we can clean up these dependencies. Do we need mock in the buildroot? If not, is it possible to split pyrpkg's mock functionality into a subpackage? We'll need somebody more familiar with the buildsys than me to answer that... For now it would suffice to be able to axe the deltarpm dependency out temporarily to allow it to be rebuilt, one way or the other. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 11:37 AM, Tomas Mraz tm...@redhat.com wrote: On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: ... 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. There's nothing blocking ARM from building multiple kernels in that requirement. They just need to all be enabled in the SRPM that gets sent to koji for the build. We do this for 32-bit x86 already by building both the normal and PAE i686 variants. The intention is to basically have a consistent and reproducible build for all kernels built from a single SRPM. I really don't think we want to enable additional kernels for final builds that have not been tested at all during development of the release. That doesn't make sense at all and sounds like poor engineering practice. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. That would be acceptable of course, and it would still fit with the requirement above just fine. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 04:37:17PM +0100, Tomas Mraz wrote: On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. The problem with not doing a full set of builds in rawhide is that it significantly reduces the testing - both in terms of making sure that code still bilds, and in terms of making sure that we don't have unexpected functional regressions. Shortly before release is a really bad time to discover this. My impression is that the kernel team don't want that to be a possibility. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Yes, there's no fundamental reason that these builds need to occur in series. If koji had support for exploding builds out to multiple machines then things would work much better. Another alternative might be to investigate whether distcc is practical in this environment. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ARM as a primary architecture
Jon, Brendan, In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. So without further ado: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. 3) arm must be integrated to the formal release criteria 4) when milestones occur, arm needs to be just as testible as other primary architectures 5) installation methods must be in place. I'm not saying it has to be using the same model as x86, but when we get to beta, if it can't be installed, it can't meet similar release criteria to existing or prior primary arches. Where possible, we should be using anaconda for installation, though I'd be open to looking at using it to build installed images for machines with severe resource constraints. 6) supported platforms must be fully integrated into building and installation. If you need a special build procedure to make this happen for kernel, we need to have rel-eng signing off saying they've approved of whatever method that is, and QE signing off that they think it'll result in a something they can claim is tested enough to release as a primary arch. 7) it can't be a serious maintenance burdon due to build related issues. We need a couple of groups to sign off that builds are fast enough, not just on a full distro rebuild (throughput) level, but also on a doesn't destroy my workflow due to waiting on it (latency) level. Obviously any feedback you guys have on this is welcome. -- Peter Old MacDonald had an agricultural real-estate tax abatement. 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Tue, Mar 20, 2012 at 10:52 AM, Peter Jones pjo...@redhat.com wrote: Jon, Brendan, In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. So without further ado: Excellent, can you add this to the ticket? 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. 3) arm must be integrated to the formal release criteria 4) when milestones occur, arm needs to be just as testible as other primary architectures 5) installation methods must be in place. I'm not saying it has to be using the same model as x86, but when we get to beta, if it can't be installed, it can't meet similar release criteria to existing or prior primary arches. Where possible, we should be using anaconda for installation, though I'd be open to looking at using it to build installed images for machines with severe resource constraints. 6) supported platforms must be fully integrated into building and installation. If you need a special build procedure to make this happen for kernel, we need to have rel-eng signing off saying they've approved of whatever method that is, and QE signing off that they think it'll result in a something they can claim is tested enough to release as a primary arch. 7) it can't be a serious maintenance burdon due to build related issues. We need a couple of groups to sign off that builds are fast enough, not just on a full distro rebuild (throughput) level, but also on a doesn't destroy my workflow due to waiting on it (latency) level. Obviously any feedback you guys have on this is welcome. -- Peter Old MacDonald had an agricultural real-estate tax abatement. 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:51 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Mar 20, 2012 at 04:37:17PM +0100, Tomas Mraz wrote: On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. The problem with not doing a full set of builds in rawhide is that it significantly reduces the testing - both in terms of making sure that code still bilds, and in terms of making sure that we don't have unexpected functional regressions. Shortly before release is a really bad time to discover this. My impression is that the kernel team don't want that to be a possibility. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Yes, there's no fundamental reason that these builds need to occur in series. If koji had support for exploding builds out to multiple machines then things would work much better. Another alternative might be to investigate whether distcc is practical in this environment. Matthew, can you add your initial list to the ticket as well, so we have these starting places to refer to? -J -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rework package groups (was: Summary minutes for today's FESCo meeting...)
Am Montag, den 19.03.2012, 14:46 -0500 schrieb Jon Ciesla: * #824 F18 Feature: Rework Package Groups -- https://fedoraproject.org/wiki/Features/ReworkPackageGroups (limburgher, 18:10:57) * AGREED: F18 Rework Package Groups is passed (+6,-:0,0:2) (limburgher, 18:12:42) Did FESCO really know what they were voting about? Can any of the FESCo members actually explain the feature? I'm afraid the feature page is so vague that nobody has a clue what we are talking about here. Does anybody - except Notting and David Lehman actually know what this feature is and how it impacts package maintainers or the spins SIG? Will groups still be consistent between yum and anaconda? Will a user who runs 'yum install @foo' get the same packages hat he had gotten wheh he selected the 'foo' group in anaconda? Please don't get me wrong: I am very much looking forward to this feature, but I am afraid nobody has an idea what is going on here. Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:55:41AM -0500, Jon Ciesla wrote: Matthew, can you add your initial list to the ticket as well, so we have these starting places to refer to? I was planning to after we'd had some discussion here, just to make sure I wasn't proposing anything too unreasonable. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:57 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Mar 20, 2012 at 10:55:41AM -0500, Jon Ciesla wrote: Matthew, can you add your initial list to the ticket as well, so we have these starting places to refer to? I was planning to after we'd had some discussion here, just to make sure I wasn't proposing anything too unreasonable. Excellent. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:58 AM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? Actually, I hadn't thought about it that way before, but having a build fail on x86 or x86_64 would allow me to kill the ARM build and save load on the ARM buildsys. A win, if it's going to fail anyway. -J -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 11:58 AM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? I thought about this a bit yesterday. My conclusions are that it will impact people in 2 cases. 1) The build works fine on i686 and x86_64 and completes in the current normal time, but then the ARM build fails some number of minutes/hours later. For most packages, that likely isn't a big deal but for large packages like gcc and the kernel, I could have done exactly what you propose and downloaded the x86 results while waiting hours for ARM to complete and tested. If the ARM build fails while I'm doing that, I need to go and redo that testing after ARM is fixed because it failing will fail the entire koji build. 2) Updates. Submitting updates requires the entire build to be complete which means you have to wait for the slowest thing to finish. Having to wait for 12 hours effectively means you can't even test your update until the next day, and then after you test it you can submit it. Again, this is mostly compounded for large packages, but it does impact workflow. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 03/20/2012 11:52 AM, Peter Jones wrote: In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. So without further ado: Thanks for sending this. We were planning to start (and still are) a separate and broader thread once we've had time to circle back with a few folks in other groups for one-on-one feedback. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rework package groups (was: Summary minutes for today's FESCo meeting...)
Christoph Wickert (christoph.wick...@googlemail.com) said: Does anybody - except Notting and David Lehman actually know what this feature is and how it impacts package maintainers or the spins SIG? package maintainers: it won't, barring the creation of some new metadata for optional package selection post-install, in which case they'll have to edit that instead of the comps file. spins SIG: the groups in the kickstart file might be different. Aside from that, some of it is still TBD. Will groups still be consistent between yum and anaconda? Will a user who runs 'yum install @foo' get the same packages hat he had gotten wheh he selected the 'foo' group in anaconda? The groups won't be selected the same in anaconda, but they'll still be consistent. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 08:58:45AM -0700, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. Looking at last gcc build times (not unusual, though I really remember arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours on both arm architectures), from http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log : i6864h18m x86_64 1h25m ppc 4h12m ppc64 4h16m s3906h27m s390x 6h04m armv5tel26h20m armv7hl 24h17m So even speeding this up twice means it is still 2x slower than the slowest other secondary architecture. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? For the builds completed on some architectures, but waiting on others nothing is moved over to the packages/ dirs. Yes, you can grab them from the task directories, but only manually, scripts fetching testsuite results won't see them, it can't be filed into bodhi, in rawhide isn't tagged into the buildroots, etc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
- Original Message - From: Josh Boyer jwbo...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Jakub Jelinek ja...@redhat.com, second...@lists.fedoraproject.org Sent: Tuesday, 20 March, 2012 4:08:16 PM Subject: Re: RFC: Primary architecture promotion requirements On Tue, Mar 20, 2012 at 11:58 AM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? I thought about this a bit yesterday. My conclusions are that it will impact people in 2 cases. 1) The build works fine on i686 and x86_64 and completes in the current normal time, but then the ARM build fails some number of minutes/hours later. For most packages, that likely isn't a big deal but for large packages like gcc and the kernel, I could have done exactly what you propose and downloaded the x86 results while waiting hours for ARM to complete and tested. If the ARM build fails while I'm doing that, I need to go and redo that testing after ARM is fixed because it failing will fail the entire koji build. 2) Updates. Submitting updates requires the entire build to be complete which means you have to wait for the slowest thing to finish. Having to wait for 12 hours effectively means you can't even test your update until the next day, and then after you test it you can submit it. Again, this is mostly compounded for large packages, but it does impact workflow. 3) chain builds in rawhide become slower. For X we do a lot of chain + dependency building, and I think the gnome guys do as well So now I have 12 packages to update, I need the first two to complete before I can get the next 10 etc, Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary minutes for today's FESCo meeting (2012-03-19)
On Tue, 20 Mar 2012 10:21:01 -0500 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Kevin Fenzi ke...@scrye.com said: Well, speaking for myself only, I read this as pretty much a Lets begin discussions on it. There's no way a short bit at the end of a meeting is going to allow enough discussion. So, this is just to start the ball rolling and collect feedback from everyone. No need to feel bad about not being there to give feedback at this first meeting. Well, it was proposed as an F18 feature, which _could_ have been approved at a single meeting. I suppose. I don't see that as likely... Speaking as a mirror admin (granted of a smaller mirror), I don't have sufficient disk space for two new architectures (the Fedora ARM team is actually proposing two different ARM arches). I would like to see the mirrors involved in the discussion, as there may be other (and larger) mirrors that won't carry this. Absolutely. Feedback from mirrors and also determining size would be great things to do. I'm also not really sure what the gain is for moving from secondary to primary arch. See other posts. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 04:58 PM, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? My #1 problem would be making packages compilable and bug-hunting arch-specific compilation problems. If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? Yes, because building primary archs first doesn't help when build-problems are secondary arch specific. That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Tue, Mar 20, 2012 at 12:09:22PM -0400, Jon Masters wrote: On 03/20/2012 11:52 AM, Peter Jones wrote: In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. So without further ado: Thanks for sending this. We were planning to start (and still are) a separate and broader thread once we've had time to circle back with a few folks in other groups for one-on-one feedback. Is the plan for that to happen before next week's fesco meeting? If not we'll probably want to just defer it until we've made sure everyone's given feedback. I'd also like to see as much of the conversation take place in public as possible in order to make sure we can pick up the reasoning behind any decisions. Thanks, -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 4:58 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. Well the solution seems rather obvious to me . There is no real (technical) reason why you cannot build on x86_64 hardware. I never ever built anything on ARM directly using cross compilers on an x86_64 host is orders of magnitude faster so I saw no reason to attempt to build on ARM. The ARM hardware I worked with had only 128MB of RAM and a 400Mhz CPU but the same should apply to modern ARM platforms too (i.e building on x86_64 is just the saner way). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. Let's figure out how to make native compilation work *better*, how to make koji work *better* when more architectures are involved than just x86. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Tue, Mar 20, 2012 at 11:30 AM, Jon Masters j...@redhat.com wrote: Hi again, I want to thank you, and everyone else in FESCo for talking with us yesterday, and for looking over the proposal. Bear in mind, it's a work in progress. We intend to have broader conversations over the coming months and F18 is an optimistic goal. Nonetheless, I feel it is achievable (we've done many more disruptive things!) but we have also many points along the way at which we can back out, and remain SA. To address a few of these points...at least, I'll try :) First, just to repeat, we took the proposal to FESCo yesterday in the spirit of early and often, not in the spirit of final deliverable. Therefore, while it is true we've not yet reached out to everyone for input, that is because it is still a work in progress for us. We'll iterate based on feedback, and based upon yesterday and reaching out to other groups. On 03/20/2012 11:52 AM, Peter Jones wrote: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages So we have a tracker bug at the moment. Is that sufficient? If so, we obviously should make sure that it is included in the proposal docs that we have this in place and are using it. What is the tracker bug? I'd like to take a peek. 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. Let's think about this some. ARM (32-bit) doesn't do Intel-style microcode, MCE, or many other things that x86 does. I don't think that means we should build packages that are x86-specific for ARM systems. We generally believe that we're starting from a point of good momentum, but there are some packages that won't ever be appropriate for ARM, and there are others where the FTBFS has been longstanding, or there are other (IMO valid) reasons why it might initially be Exclude. That doesn't mean that there would be many such cases. Nonetheless, I think it would be unreasonable to set the entry bar so high that there can be no things left to fix. That basically retains the x86 monopoly. 3) arm must be integrated to the formal release criteria Agreed. We'll need to figure that out. 4) when milestones occur, arm needs to be just as testible as other primary architectures So we have a new hire (hi Paul) who is looking at autoqa, and we're going to pull together as much as we can here. It would help me to know (and we're reaching out to QE separately - per my other mail) what you would consider testable to mean, in terms of what you'd want to see. 5) installation methods must be in place. I'm not saying it has to be using the same model as x86, but when we get to beta, if it can't be installed, it can't meet similar release criteria to existing or prior primary arches. Where possible, we should be using anaconda for installation, though I'd be open to looking at using it to build installed images for machines with severe resource constraints. So we feel it more appropriate to use image creation tools at this point, for the 32-bit systems that we have in mind. There will be servers this year, but not yet, and they represent a small part of the overall value of ARM to Fedora. When you have systems that cost more than an order of magnitude less than their x86 brethren, that does mean there are some implementation differences. For one thing, the reason most of these boards are inexpensive is that they've done away with dedicated flash on-board for U-Boot, etc. Instead, the SoC (chip) contains enough minimal logic to load everything it needs for further initialization from an SD (typically) card. The normal model that has been established is that cards are provisioned separately and inserted into a board. Think of these as appliances, kinda. There are ARM netbooks, but they are rare. We'll get to Anaconda for some of the bigger stuff later, but for now, that seems less important than ensuring that we use standard Fedora tools to make the images. 6) supported platforms must be fully integrated into building and installation. If you need a special build procedure to make this happen for kernel, we need to have rel-eng signing off saying they've approved of whatever method that is, and QE signing off that they think it'll result in a something they can claim is tested enough to release as a primary arch. Fine. I think we got onto a tangent yesterday with the kernel. It's one part of the overall system. It's an important part, but it's just a part. What we are proposing is that we target a limited number of ARM kernel variants (subpackages) during a typical build - perhaps even only versatile - because this allows us to return a built kernel more quickly than building many variants. I had planned to take this to the kernel team, but let me just
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Let's figure out how to make native compilation work *better*, how to make koji work *better* when more architectures are involved than just x86. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 08:47 AM, Josh Boyer wrote: There's nothing blocking ARM from building multiple kernels in that requirement. They just need to all be enabled in the SRPM that gets sent to koji for the build. We do this for 32-bit x86 already by building both the normal and PAE i686 variants. The intention is to basically have a consistent and reproducible build for all kernels built from a single SRPM. This is infact what we're doing now- a single kernel build produces rpms for a number of different ARM platforms (omap, tegra, imx, versatile, etc). I really don't think we want to enable additional kernels for final builds that have not been tested at all during development of the release. That doesn't make sense at all and sounds like poor engineering practice. Agree. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. That would be acceptable of course, and it would still fit with the requirement above just fine. I'm not sure how it would work, but if koji can be extended to distribute a single arch build across multiple systems where an identical srpm can be built with a koji-controlled set of flags, this would take care of the wide-breadth of kernels needing to be built. We've also had some success with distcc, but have not proposed using it as reproducability of builds becomes an issue. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 08:58:45AM -0700, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? Is cross-compilation a realistic option? In theory this would improve the speed of builds to something like the x86-64 speed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote: On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? We use cross-compilation right now for mingw-* packages (for Windows). However you cannot use cross-compilation to create a foo-*.armv7hl.rpm package. That's because our entire toolchain, from RPM through Koji, simply does not understand cross-compilation properly. Solvable, but undoubtedly a ton of work for everyone. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 09:37 AM, drago01 wrote: I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Okay, why not? The ones off the top of my head, and this is by no means exhaustive: 1. Fedora Policy (Which I imagine is based on the technical foundation of the following 5+ points and others I'm unaware of). 2. Many packages assume a native execution environment which will not exist. Incredible undertaking to move 11000 packages to cross compilation framework. 3. Absence of arm-linux cross compilers in the distribution. 4. If there were arm-linux cross compilers, how do you keep them in sync with native gcc? 5. Where does the sys-root for an arm-linux cross compiler come from? 6. Would koji then be native/cross ambidextrous? Who is going to do that? For all these reasons and more we're not proposing cross compilation for ARM. Just doing so defies what it means to be PA. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). In couple years the hardware is going to be surprisingly comparable or exceed to what you're see on x86, especially as the number of cores skyrockets while the GHz continue to climb. It's not a gimmick, we're just preparing for the future before it gets here. The only problem we face is that those cores are in multiple CPUs so we can't 'make -j' our way out of the build system problem. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:46 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote: On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? We use cross-compilation right now for mingw-* packages (for Windows). However you cannot use cross-compilation to create a foo-*.armv7hl.rpm package. That's because our entire toolchain, from RPM through Koji, simply does not understand cross-compilation properly. Solvable, but undoubtedly a ton of work for everyone. I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Hello, On 03/20/2012 12:37 PM, drago01 wrote: On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Fedora generally doesn't cross-compile because you have to minimally run certain target configuration stuff on the host, and there are many other hardcoded expectations. [ Aside - skip this bit - because someone is going to mention it and take this thread onto a wild tangent, yes you can use distcc hacks, yes, there is/was Scratchbox, and yes there are many other cute hacks. We haven't proposed any of this because we want to be boring, we want to win acceptance by doing what x86 does in as many cases as reasonable. It isn't reasonable to expect ARM to install using Anaconda on a $25 target, but it is reasonable to expect on-target build ]. Let's figure out how to make native compilation work *better*, how to make koji work *better* when more architectures are involved than just x86. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). Well, we've done a number of mass rebuilds, a complete bootstrap from scratch, and several releases now. So, it might be a gimmick, but it works. We need to stop thinking of ARM as it was 10 years ago. This year, we're going to see systems with 288+ cores in 2U of rack space. Next year, we're going to see Cortex A-15 systems that will be much faster still, and the year after, we're going to see 64-bit systems with at least 8 highly performing cores. It's not all about performance though. ARM isn't going to beat x86 in a speed race...that is not the goal. It's about aggregate performance, not individual node performance at the high end, and about mass availability at the low end. We can remain an x86-only primary distro. But that won't help address the longer term problems we will face. I'll spare the hyperbole for the moment, but I will add that this is a multi-year journey that we want to begin now. Yes, there are rough edges, yes this is cutting edge stuff, yes that is precisely what Fedora is all about. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. So, first of all, I disagree that there should be a process for promoting an architecture to primary in the first place. The set of primary architectures (x86_64, i686) should be set in stone unless a MAJOR change in hardware landscape happens, e.g. x86 gets discontinued by the hardware manufacturers and everyone uses ARM instead. I don't see that happening any time soon. Adding primary architectures puts a major burden on all Fedora maintainers. In the current state of things, I don't see a sufficient demand for making ARM (or even less any other secondary architecture) a primary architecture. If ARM is really the future as its proponents claim, we can revisit that in a few years. Not now. The focus should be on finding ways to make secondary architecture releases more timely (i.e. it's not acceptable that e.g. the stable ARM release is still Fedora 14 which doesn't even get security updates anymore), not to cheat around the problem by making ARM a primary architecture (which does not help all the other secondary architectures). Secondary architectures in Fedora are subject to looser constraints than primary architectures for two primary reasons: 1) To make it easier to bootstrap an architecture without the overhead of the primary architecture release engineering process 2) To avoid primary architecture development being held up by poorly developed or niche architectures 3) To avoid slowing down all builds by having to wait for the slow builders to complete them. 4) To avoid build failures caused by platform-specific toolchain bugs or limitations failing the entire build and forcing the maintainer to fix them. In order to ensure that these expectations are met, secondary architectures must meet various criteria before they can be promoted: 1) There must be adequate representation for the architecture on the Fedora infrastructure and release engineering teams. 2) All builds must occur on Fedora-maintained build servers. 3) Where technically possible, all supported hardware targets must be supported via Anaconda. Exceptions are limited to highly resource constrained devices or hardware which provides no means for simultaneous support of install and target media. Why would we want to make such an architecture (the exceptions) primary?! 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. 5) Sufficient developer resources must be available to fix any architecture-specific issues in such a way that they do not delay overall Fedora development. 6) It must be possible for maintainers of critical-path hardware dependent packages to have direct access to supported hardware in order to rectify any release-blocking issues. For example, X maintainers must have direct access to any hardware with graphics capabilities. 7) The port must not rely on sourceless binaries unless they fall under the generic firmware exemption. Where source and toolchain are available, the binaries must be built in the Fedora build infrastructure. This lacks several important requirements: * The platform should actually have a significant market share. Why would we want to make an obscure niche device a primary architecture (even if it fulfills all the 7 requirements you listed)? Your criteria would even allow architectures to become primary which don't have anywhere near the market share even ARM has (let alone x86). * The builders should not take significantly longer to complete builds than the x86 builders. Otherwise builds (especially chain builds) will be slowed down by a lot. * The architecture needs to have sufficient support from the pool of Fedora maintainers as a whole, who will be on the hook for making their packages build for it. * The toolchain (port) needs to have sufficient quality to not cause tons of platform-specific bugs which are of no fault of the package. (We've had our fair share of those with ppc/ppc64, due to both bugs and bizarre TOC size limitations.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 12:56 PM, Brendan Conoboy wrote: On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Yup. I vote we shelve this part of the discussion in the interest of ever turning our proposal into something that will be accepted. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:50 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:37 AM, drago01 wrote: I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Okay, why not? The ones off the top of my head, and this is by no means exhaustive: 1. Fedora Policy (Which I imagine is based on the technical foundation of the following 5+ points and others I'm unaware of). I said technical so lets take policy aside ... 2. Many packages assume a native execution environment which will not exist. Incredible undertaking to move 11000 packages to cross compilation framework. qemu? Should be still faster then doing the whole build on arm. 3. Absence of arm-linux cross compilers in the distribution. Err yeah but nothing that can't be fixed. 4. If there were arm-linux cross compilers, how do you keep them in sync with native gcc? Build from the same srpm. 5. Where does the sys-root for an arm-linux cross compiler come from? 6. Would koji then be native/cross ambidextrous? Who is going to do that? No real answers to them yet but fixing them seems to be easier then make arm as fast as x86_64. For all these reasons and more we're not proposing cross compilation for ARM. Just doing so defies what it means to be PA. We should somehow define what a PA is then. I wouldn't have added built on native hardware because that does not really seem to matter. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). In couple years the hardware is going to be surprisingly comparable or exceed to what you're see on x86, especially as the number of cores skyrockets while the GHz continue to climb. Might be true might be not ... we are talking about the next couple of months not years. It's not a gimmick, we're just preparing for the future before it gets here. The only problem we face is that those cores are in multiple CPUs so we can't 'make -j' our way out of the build system problem. Huh? Not sure I follow here. Also I am not opposed to having ARM as PA, I just don't really think we should do it the way it is proposed here (build on hardware that is way slower then the rest of the builders). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:57 PM, Jon Masters j...@redhat.com wrote: On 03/20/2012 12:56 PM, Brendan Conoboy wrote: On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Yup. I vote we shelve this part of the discussion in the interest of ever turning our proposal into something that will be accepted. OK fair enough (even though I still think that it is the only sane way to solve the build speed issue). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jakub Jelinek wrote: Looking at last gcc build times (not unusual, though I really remember arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours on both arm architectures), from http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log : i6864h18m x86_64 1h25m ppc 4h12m ppc64 4h16m s3906h27m s390x 6h04m armv5tel26h20m armv7hl 24h17m So even speeding this up twice means it is still 2x slower than the slowest other secondary architecture. Ouch!!! That shows that ARM should be the LAST architecture we consider for primary status rather than the first. (That said, I don't think it makes sense to make PPC primary again or to make S/390 primary. They don't have anywhere near the market share. But IMHO ARM doesn't have the market share either.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Brendan Conoboy wrote: Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? IMHO, at MOST 50% longer (factor 1.5) build time, and that's already being nice. You're off by a factor of 4! No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. That's exactly why we should stick with only x86 as primary architecture(s) in the foreseeable future. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? See the other replies: chain builds, updates, platform-specific errors, build results. A lot of things depend on the builds to actually complete. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Kevin Kofler wrote: But IMHO ARM doesn't have the market share either. Kevin, you don't know what you are talking about. Every cell phone has an ARM cpu in it. Smart phone or otherwise. Almost every HDTV has an ARM cpu in it. Almost every tablet has an ARM cpu in it. What do people buy these days? Phones, tablets, and TVs. Not desktop computers. Hell, ARM is even building server boxes now (this is probably where Red Hat's interest is in). I'll enjoy calling up these emails 2 years from now when you're complaining that Fedora isn't ready for ARM (if we don't start now). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 18:08 +0100, Kevin Kofler wrote: Jakub Jelinek wrote: Looking at last gcc build times (not unusual, though I really remember arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours on both arm architectures), from http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log : i6864h18m x86_64 1h25m ppc 4h12m ppc64 4h16m s3906h27m s390x 6h04m armv5tel26h20m armv7hl 24h17m So even speeding this up twice means it is still 2x slower than the slowest other secondary architecture. Ouch!!! That shows that ARM should be the LAST architecture we consider for primary status rather than the first. (That said, I don't think it makes sense to make PPC primary again or to make S/390 primary. They don't have anywhere near the market share. But IMHO ARM doesn't have the market share either.) Can you define what market you refer to ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Tomas Mraz wrote: On Tue, 2012-03-20 at 15:19 +, Matthew Garrett wrote: 4) All supported platforms must have kernels built from the Fedora kernel SRPM and enabled by default in the spec file. Each kernel must be built in a timely manner for every SRPM upload. I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. Yet that requirement makes a lot of sense, and is yet another reason why ARM shouldn't even be CONSIDERED for primary status at this point. Building a separate kernel for every single machine just doesn't scale. Imagine if we had to build a Thinkpad kernel, a MacBook kernel, a Dell Inspiron kernel etc. (and I didn't even bring model numbers in here!). There's no way such a setup is supportable. Another solution might be in koji where the kernels for the additional platforms would be built in parallel on multiple build hosts. Of course that would require changes in koji. Indeed it would, and it still wouldn't fix the underlying issue. Of course the general requirement that builds on the architecture to be promoted must not take much longer time than builds on the current primary architectures still stays. Right, and I don't see ARM satisfying this any time soon either. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
drago01 píše v Út 20. 03. 2012 v 17:57 +0100: On Tue, Mar 20, 2012 at 5:50 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:37 AM, drago01 wrote: I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Okay, why not? The ones off the top of my head, and this is by no means exhaustive: 1. Fedora Policy (Which I imagine is based on the technical foundation of the following 5+ points and others I'm unaware of). I said technical so lets take policy aside ... 2. Many packages assume a native execution environment which will not exist. Incredible undertaking to move 11000 packages to cross compilation framework. qemu? Should be still faster then doing the whole build on arm. just a side note - I was told by an OpenSUSE on ARM person that they use x86 boxes with the user-space qemu virtual machine. It works quite fast, but still needs some hacking eg. in test-suites Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 12:05 PM, Kevin Kofler kevin.kof...@chello.at wrote: Brendan Conoboy wrote: Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? IMHO, at MOST 50% longer (factor 1.5) build time, and that's already being nice. You're off by a factor of 4! No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. That's exactly why we should stick with only x86 as primary architecture(s) in the foreseeable future. Only if you assume that high clock speed workloads are the only important workloads. For highly parallellizable tasks, an ARM system with tons of slower cores is a powerhouse. Think a db server serving huge numbers of queries. -J I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? See the other replies: chain builds, updates, platform-specific errors, build results. A lot of things depend on the builds to actually complete. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. In theory yes, in practice I don't think this will be fixed any time soon, yet… I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. … I have to wholeheartedly agree with you on this part. It's just not possible to wait for those glacially slow ARM builders to complete their builds. Even the enterprise class hardware being discussed is going to be ridiculously slow. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Brendan Conoboy wrote: In couple years the hardware is going to be surprisingly comparable or exceed to what you're see on x86, especially as the number of cores skyrockets while the GHz continue to climb. Then let's rediscuss making ARM a primary architecture when that happens. Right now the speed is just not acceptable. It's not a gimmick, we're just preparing for the future before it gets here. The only problem we face is that those cores are in multiple CPUs so we can't 'make -j' our way out of the build system problem. That alone means it's not a solution. Also note that not everything in builds is parallelizable: * not all upstream build systems use make -j, * configure (or cmake etc.) and make install are usually not parallelized, * often there are makefile dependencies requiring at least some amount of serialization etc. So even if you have -j working, you STILL need a comparable speed in ONE core compared to the x86 builders. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
drago01 wrote: qemu? Should be still faster then doing the whole build on arm. LOL, no! qemu software emulation slows down by a factor of ~50! Right now ARM is slower only by a factor of ~12. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: rpm 4.10.0 alpha to hit rawhide shortly
On 3/20/12 8:10 AM, Jonathan Dieter wrote: Ok, in F16 (and I'm assuming this is also true in Rawhide; unfortunately I don't have a Rawhide tree here to test), fedpkg is in the srpm-build group, and it requires pyrpkg which requires mock which requires createrepo which requires deltarpm. I don't know how easily we can clean up these dependencies. Do we need mock in the buildroot? If not, is it possible to split pyrpkg's mock functionality into a subpackage? We're working on a 'fedpkg-simple' which just provides the functionality needed to construct the srpm and nothing else, which will greatly reduce the deps pulled in. I'm not sure what the ETA is on this. Dennis? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 03/20/2012 12:30 PM, Jon Masters wrote: Hi again, I want to thank you, and everyone else in FESCo for talking with us yesterday, and for looking over the proposal. Bear in mind, it's a work in progress. We intend to have broader conversations over the coming months and F18 is an optimistic goal. Nonetheless, I feel it is achievable (we've done many more disruptive things!) but we have also many points along the way at which we can back out, and remain SA. To address a few of these points...at least, I'll try :) First, just to repeat, we took the proposal to FESCo yesterday in the spirit of early and often, not in the spirit of final deliverable. Therefore, while it is true we've not yet reached out to everyone for input, that is because it is still a work in progress for us. We'll iterate based on feedback, and based upon yesterday and reaching out to other groups. On 03/20/2012 11:52 AM, Peter Jones wrote: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages So we have a tracker bug at the moment. Is that sufficient? If so, we obviously should make sure that it is included in the proposal docs that we have this in place and are using it. No, that's not sufficient. The plan can't be if you have a bug that only shows up on arm, you file a bug and help you out. Part of what being a primary architecture means is enabling package maintainers to do the maintenance on their package. That's why, for example, secondary arch maintainers have wide commit approval, but there's no such concept for primary architectures. 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. Let's think about this some. ARM (32-bit) doesn't do Intel-style microcode, MCE, or many other things that x86 does. I don't think that means we should build packages that are x86-specific for ARM systems. The proposal didn't suggest this, and that wasn't what I was referring to either. The specific phrasing you guys used was Any packages that fail to build on ARM are marked with excludearch by a proven packager. This is not okay. Packages that are truly x86 specific - and I'm not talking about incidental build failures due to bugs - should already have ExclusiveArch tags in them limiting them to that architecture. We generally believe that we're starting from a point of good momentum, but there are some packages that won't ever be appropriate for ARM, and there are others where the FTBFS has been longstanding, or there are other (IMO valid) reasons why it might initially be Exclude. And again, we're not talking about packages that are wholly inappropriate. That doesn't mean that there would be many such cases. Nonetheless, I think it would be unreasonable to set the entry bar so high that there can be no things left to fix. That basically retains the x86 monopoly. I don't mean to be saying there can't be outstanding bugs, but that's not what you're saying either. Adding ExclusiveArch to packages which are meant to eventually work is a form of papering over the problems. It's one thing to have outstanding issues; it's another thing to introduce non-fixes into packages for those issues. 3) arm must be integrated to the formal release criteria Agreed. We'll need to figure that out. 4) when milestones occur, arm needs to be just as testible as other primary architectures So we have a new hire (hi Paul) who is looking at autoqa, and we're going to pull together as much as we can here. It would help me to know (and we're reaching out to QE separately - per my other mail) what you would consider testable to mean, in terms of what you'd want to see. I'd largely defer to adamw for specific criteria regarding testing, both in terms of criteria we're testing for (i.e. #3) and in terms of establishing appropriate testing procedures for the platform. I've largely listed those because there's not really any indication in the proposal as it stands that this is well-considered at this point in time. There's a brief section on how to test, but it appears to be largely pro-forma. 5) installation methods must be in place. I'm not saying it has to be using the same model as x86, but when we get to beta, if it can't be installed, it can't meet similar release criteria to existing or prior primary arches. Where possible, we should be using anaconda for installation, though I'd be open to looking at using it to build installed images for machines with severe resource constraints. So we feel it more appropriate to use image creation tools at this point, for the 32-bit systems that we have in mind. I don't disagree, and I think I made that pretty clear in all those caveats you've generously quoted. I've heard that you've been talking to bcl about this. I encourage you to continue on
Re: RFC: Primary architecture promotion requirements
Brendan Conoboy wrote: Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Possible. That just means ARM cannot become a primary architecture any time soon. We should not ignore the problem just because you cannot solve it. It is a blocking issue. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 12:54:36PM -0400, Jon Masters wrote: The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). Well, we've done a number of mass rebuilds, a complete bootstrap from scratch, and several releases now. So, it might be a gimmick, but it works. We need to stop thinking of ARM as it was 10 years ago. This year, we're going to see systems with 288+ cores in 2U of rack space. Why are you even bringing up this as yet unreleased hardware in the context of arm32 builds are slow ? Even if it was released today, it doesn't solve this problem at all. Arm32 as primary and Arm64 as primary are two entirely separate discussions, and conflating the two isn't solving anything. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Sorry I am not buying that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Jon Masters wrote: On 03/20/2012 11:52 AM, Peter Jones wrote: 7) it can't be a serious maintenance burdon due to build related issues. We need a couple of groups to sign off that builds are fast enough, not just on a full distro rebuild (throughput) level, but also on a doesn't destroy my workflow due to waiting on it (latency) level. Sure. Absolutely is a concern for us, as you can see from my other comments above about the kernel, for example, but not just that. Sorry, but I don't think this is fixable any time soon. Come back when (if ever) you have hardware which has comparable speed to x86. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Tue, Mar 20, 2012 at 06:44:43PM +0100, Kevin Kofler wrote: Jon Masters wrote: Sure. Absolutely is a concern for us, as you can see from my other comments above about the kernel, for example, but not just that. Sorry, but I don't think this is fixable any time soon. Come back when (if ever) you have hardware which has comparable speed to x86. I think your point's been pretty clearly made now. It doesn't further the conversation to repeat it in reply to every message in the thread. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 09:50 -0700, Brendan Conoboy wrote: 1. Fedora Policy (Which I imagine is based on the technical foundation of the following 5+ points and others I'm unaware of). 2. Many packages assume a native execution environment which will not exist. Incredible undertaking to move 11000 packages to cross compilation framework. And even if everything builds with cross tools, ee'd still need a native platform (hw or simulated) to run the %check stage. 3. Absence of arm-linux cross compilers in the distribution. 4. If there were arm-linux cross compilers, how do you keep them in sync with native gcc? Already some work being done on that front: https://bugzilla.redhat.com/show_bug.cgi?id=761619 https://bugzilla.redhat.com/show_bug.cgi?id=766166 5. Where does the sys-root for an arm-linux cross compiler come from? The sys-root would be populated from already built RPMs much like the mock chroot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Michael Cronenworth wrote: Kevin, you don't know what you are talking about. Every cell phone has an ARM cpu in it. Smart phone or otherwise. Almost every HDTV has an ARM cpu in it. Almost every tablet has an ARM cpu in it. Several of those are not suitable devices to run a general purpose GNU/Linux distribution on, and even for those which are, why would they be our primary target? What do people buy these days? Phones, tablets, and TVs. Not desktop computers. Citation needed. Desktop/notebook computers aren't going to go away any time soon. Hell, ARM is even building server boxes now But even those servers are not fast enough to complete package builds in a reasonable time. (this is probably where Red Hat's interest is in). As far as I know, this proposal is driven by community people, not Red Hat people. I'll enjoy calling up these emails 2 years from now when you're complaining that Fedora isn't ready for ARM (if we don't start now). We're starting now, that's what the secondary architecture is for. There's no need for ARM to be a primary architecture for Fedora to be ready for it. (And I don't see myself using an ARM as my primary machine in 2 years. It's more likely that I'll still be using the same machines I use now, I don't replace my hardware that often, and even this old Pentium 4 is faster than a fast ARM machine.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 10:27 AM, Kevin Kofler wrote: Then let's rediscuss making ARM a primary architecture when that happens. Right now the speed is just not acceptable. Really? You're going to base your entire opinion on build time data on inappropriate hardware for one package without knowing even what the factors are in the build time? What if 50% of that time was due to test timeouts that require a simple fix? Please turn down the hyperbole dial and think before jumping to conclusions. If all Fedora is to you is a means of turning source code into binaries at lightning speed, x86 is great for you. I'm pretty sure Fedora is more than that. And if Fedora is going to be relevant in a few years time, it better support the CPU that is inside the computers everybody is buying today. That alone means it's not a solution. Also note that not everything in builds is parallelizable: * not all upstream build systems use make -j, But most of the big packages do. * configure (or cmake etc.) and make install are usually not parallelized, Make install speed is going to be the same. There will be no appreciable difference IO difference. It's entirely storage-speed bound. * often there are makefile dependencies requiring at least some amount of serialization Uh huh... etc. So even if you have -j working, you STILL need a comparable speed in ONE core compared to the x86 builders. Er, no, that's what you believe you need. I need packages to build in a period of time that works for the affected developers. You're responsible for some packages I believe so why don't you start by looking at how you would personally would be affected and talk about that? With as few exclamation points as possible, please. What's your slowest building package? We can probably extrapolate how long it will take to build with first generation ARM server hardware. From there we can talk about how that affects you work flow as well as how to handle it being delayed. Thanks, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 06:29:13PM +0100, Kevin Kofler wrote: drago01 wrote: qemu? Should be still faster then doing the whole build on arm. LOL, no! qemu software emulation slows down by a factor of ~50! Right now ARM is slower only by a factor of ~12. Meh, at least you got something to _boot_ in qemu-system-arm. Merely getting it to work at all has eluded me for years :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Simo Sorce wrote: Can you define what market you refer to ? Anything which can be reasonably called a computer. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Jon Ciesla wrote: Only if you assume that high clock speed workloads are the only important workloads. For highly parallellizable tasks, an ARM system with tons of slower cores is a powerhouse. Think a db server serving huge numbers of queries. Unfortunately, our builds are not that parallelizable, which is a major practical problem with ARM as a primary architecture. As for supporting the use case for our users, I don't see why we cannot support those specialized tasks with a secondary architecture. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 10:44 AM, drago01 wrote: On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboyb...@redhat.com wrote: Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Sorry I am not buying that. Because you have vast experience to the contrary? Look, even x86_64 is topping out on speed and moving to a more-core and more-systems-per-rack model. Cross compilation solves yesterday's problem, not tomorrow's. If build speed truly is a fundamental issue to becoming PA the answer is to harness multiple systems for a single build, not to use a somewhat faster system to make up for the speed of a somewhat slower system. Scaling across more cores than fit in a single SMP Linux environment is the only sensible approach to future build speedups. Though is an interesting challenge, it is completely beyond the scope of primary architecture requirements. Please, let's drop talk of cross compilation. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 11:58 AM, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? You're on the right track here, but you need to consider not just builds, but also updates. It's important for several reasons - an excessively long compile time means it's less likely that an update will be filed immediately after the build, for example. It's also important to consider things like incident response. For example, it's not as if we've never had a CVE filed against GCC that required rebuilding of packages. If it takes 24 hours to build gcc (a number I just made up for illustrative purposes), then you've got a scenario like where we're waiting on a build of gcc to get a libpng fix out so that firefox isn't being exploited. And sure, you're thinking but who wants to run firefox on 32-bit arm?, but it doesn't matter, because it's being exploited for an extra day on x86 as well while we're waiting for libpng to be built with a newer compiler that isn't even in updates-testing yet. That's the nightmare scenario, admittedly, but it still bears consideration. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
drago01 wrote: On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Sorry I am not buying that. I think you're underestimating the problems. RPM is not designed for cross- compilation, at all. Not all upstream build systems support it, either. And even where the build system supports it in principle, the individual upstream package might be doing something which actually makes it fail. While I'm not sure it would require decades, I also doubt it will be a workable solution in the short term. I think the current secondary architecture setup is the much better solution, it lets ARM builders complete their builds at their own pace without slowing down everyone. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 3/20/12 9:30 AM, Jon Masters wrote: Hi again, I want to thank you, and everyone else in FESCo for talking with us yesterday, and for looking over the proposal. Bear in mind, it's a work in progress. We intend to have broader conversations over the coming months and F18 is an optimistic goal. Nonetheless, I feel it is achievable (we've done many more disruptive things!) but we have also many points along the way at which we can back out, and remain SA. To address a few of these points...at least, I'll try :) First, just to repeat, we took the proposal to FESCo yesterday in the spirit of early and often, not in the spirit of final deliverable. Therefore, while it is true we've not yet reached out to everyone for input, that is because it is still a work in progress for us. We'll iterate based on feedback, and based upon yesterday and reaching out to other groups. On 03/20/2012 11:52 AM, Peter Jones wrote: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages So we have a tracker bug at the moment. Is that sufficient? If so, we obviously should make sure that it is included in the proposal docs that we have this in place and are using it. A tracker bug is certainly not sufficient. It would be for a SA, but not PA. Typically our users have a PA at their disposal, or failing that have ready access to a shared PA provided by the Fedora Project that they can log into and do their testing. Without ARM systems available for all the releases our maintainers have to support this is a non-starter. I will also note that having to resort to using a remote system because the arch isn't generally locally at a maintainer's disposal /is/ going to introduce a delay in getting bugs resolved and builds out the door. If the arch was ubiquitous in a way that lent itself to easy debugging and use that'd be a different matter, but I just don't see it as being there right now. 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. Let's think about this some. ARM (32-bit) doesn't do Intel-style microcode, MCE, or many other things that x86 does. I don't think that means we should build packages that are x86-specific for ARM systems. We generally believe that we're starting from a point of good momentum, but there are some packages that won't ever be appropriate for ARM, and there are others where the FTBFS has been longstanding, or there are other (IMO valid) reasons why it might initially be Exclude. That doesn't mean that there would be many such cases. Nonetheless, I think it would be unreasonable to set the entry bar so high that there can be no things left to fix. That basically retains the x86 monopoly. Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as a default action when a build fails on ARM is certainly not an option. What would help your situation is generating a few lists of packages. One list would be packages that you feel just don't make sense on ARM. Another list would be the FTBFS you mention. These lists can be debated and decided upon /before/ the migration to PA and the ExcludeArches can be in place before the switch is pulled. Once the switch is pulled, that's when excludearch is unacceptable without FESCo or such involvement, just like it is with the other primary arches. That's really a price of entry. 3) arm must be integrated to the formal release criteria Agreed. We'll need to figure that out. 4) when milestones occur, arm needs to be just as testible as other primary architectures So we have a new hire (hi Paul) who is looking at autoqa, and we're going to pull together as much as we can here. It would help me to know (and we're reaching out to QE separately - per my other mail) what you would consider testable to mean, in terms of what you'd want to see. I think what is meant here is that we have to be able to get the arm version of the rpms installed onto an appropriate host and be able to easily run the programs to ensure that things are working as expected, more than just It built, SHIP IT. Take a look at the release criteria we have currently have in place for alpha/beta/final. ARM will need to follow it or have something extremely similar. Granted the release criteria mostly involves the installation process, but it does include installs from live media. Installs /to/ a SD device and then booting said install to validate it could fit in there. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 7:05 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 10:44 AM, drago01 wrote: On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboyb...@redhat.com wrote: Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Sorry I am not buying that. Because you have vast experience to the contrary? No I do believe that there is some work required to do it. But *man-decades* is just an overstatement. Look, even x86_64 is topping out on speed and moving to a more-core and more-systems-per-rack model. I didn't claim otherwise ... Cross compilation solves yesterday's problem, not tomorrow's. Not really no. Even if we get ARM up to reasonable speeds it could help other arches in the future. If build speed truly is a fundamental issue to becoming PA the answer is to harness multiple systems for a single build, not to use a somewhat faster system to make up for the speed of a somewhat slower system. Sure if you can solve the problem in a different way it is fine. I just said then when I did software development on ARM building the software on an x86_64 host was the only obvious choice. So it sounds logical to apply it here where the goal is to build a *whole operating system* and not just a specific program. (OK hardware advanced since then but still). Scaling across more cores than fit in a single SMP Linux environment is the only sensible approach to future build speedups. Fine I am not going to stop you from doing that. Though is an interesting challenge, it is completely beyond the scope of primary architecture requirements. Please, let's drop talk of cross compilation. As I said in the other mail I am fine with that. I just had to respond to the man-decades hyperbole. (Maybe I should have just ignored it). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
