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: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2
On 08/31/2015 08:17 AM, Harald Hoyer wrote: [snip] Minutes: <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.html> Minutes (text): <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.txt> Log: <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.log.html> For today's meeting we didn't really use zodbot minute keeping features, so in the interest of sparking some discussion I'd like to recap. At Flock 2015 there was a 2 hour session on the subject of rings which are basically policy zones inhabited by packages. Right now fedora packaging has 1 policy, so the entire OS is in a single ring. Creating more rings means creating more policies. By doing this Fedora can become adopt the flexible to appeal to diverse development communities and thus grow. The general consensus at Flock was that Environments and Stacks should take the lead in helping to define new rings, and especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). A week or so ago, a small Environments and Stacks meeting took place where it was generally agreed that the Base working group was the right place to define Ring 0. That brings us to this morning's BaseWG meeting. I talked a lot so here is a rough recap integrating a few of the questions and comments people had (Do read the log if you have time!) Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: 1. Ring 0 is a repository of rpm packages built in koji. 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. 6. Ring 0 contains the minimal libraries that define the OS API/ABI, such as glibc. This probably happens implicitly by #3, repoclosure. 7. Ring 0 contains the tools needed to update existing packages and install new packages. That's the starting point, but it is by no means comprehensive. The OS probably provides specific services beyond the ability to login, for instance. Which styles of boot are supported? Where does installation infrastructure like anaconda land? This is equal parts philosophy and practicality. Also, policies for ring 0 may differ from what Base has previously adopted: Do we create a ring 0 minimal compose since we already need to check repoclosure? This might be a great way to refactor primary/secondary such that we can gracefully transition i686 down and secondary arches up. Lots of opportunities, much to consider. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2
On 08/31/2015 11:41 AM, Simo Sorce wrote: On Mon, 2015-08-31 at 10:18 -0700, Brendan Conoboy wrote: On 08/31/2015 08:17 AM, Harald Hoyer wrote: [snip] Minutes: <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.html> Minutes (text): <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.txt> Log: <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.log.html> For today's meeting we didn't really use zodbot minute keeping features, so in the interest of sparking some discussion I'd like to recap. At Flock 2015 there was a 2 hour session on the subject of rings which are basically policy zones inhabited by packages. Right now fedora packaging has 1 policy, so the entire OS is in a single ring. Creating more rings means creating more policies. By doing this Fedora can become adopt the flexible to appeal to diverse development communities and thus grow. The general consensus at Flock was that Environments and Stacks should take the lead in helping to define new rings, and especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). A week or so ago, a small Environments and Stacks meeting took place where it was generally agreed that the Base working group was the right place to define Ring 0. That brings us to this morning's BaseWG meeting. I talked a lot so here is a rough recap integrating a few of the questions and comments people had (Do read the log if you have time!) Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: 1. Ring 0 is a repository of rpm packages built in koji. 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. Can you elaborate more on this point (5) ? I can totally see how a package may be critical and therefore deserve to be in ring 0 and yet have optional features in terms of subpackages that are not necessarily ring 0. For example some library that offers optionally bindings for somewhat rarely used languages (say ocaml). The subpackages for those bindings shouldn't necessarily be ring 0. Or did I misunderstand the point ? Let's take gcc for example. The gcc package produces numerous subpackages including various compilers and libraries. One of those libraries, libgcc, is linked into nearly every dynamically linked ELF executable on your system (Run ldd to confirm), including /sbin/init. Since we really want /sbin/init to function we need to include libgcc in ring 0. Since ring membership is at a source level rather than a sub-package level, gcc is ring 0. There are other good arguments for the executable-generating tools living in ring 0, but this one illustrates the point. Ring policies might include things like how long the package is supported, what build system can generate it, what release cycle it is on, what the packaging guidelines are, what the updates rebase policy is, and so forth. These types of policies apply to source rpms as a whole. You can't apply one to gcc-c++ and another to libgcc. I think the question you are posing might be, in the context of gcc, might be: Does gcc-g++ need to appear in the same repository as libgcc? IE, can we decouple what we build from what is presented to users? If the threshold for must-include is repoclosure then no, we don't need to include
Fedora Ring 0 definition
Re-sending this with a better title so people might read it ;-) On 08/31/2015 10:18 AM, Brendan Conoboy wrote: On 08/31/2015 08:17 AM, Harald Hoyer wrote: [snip] Minutes: <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.html> Minutes (text): <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.txt> Log: <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.log.html> For today's meeting we didn't really use zodbot minute keeping features, so in the interest of sparking some discussion I'd like to recap. At Flock 2015 there was a 2 hour session on the subject of rings which are basically policy zones inhabited by packages. Right now fedora packaging has 1 policy, so the entire OS is in a single ring. Creating more rings means creating more policies. By doing this Fedora can become adopt the flexible to appeal to diverse development communities and thus grow. The general consensus at Flock was that Environments and Stacks should take the lead in helping to define new rings, and especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). A week or so ago, a small Environments and Stacks meeting took place where it was generally agreed that the Base working group was the right place to define Ring 0. That brings us to this morning's BaseWG meeting. I talked a lot so here is a rough recap integrating a few of the questions and comments people had (Do read the log if you have time!) Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: 1. Ring 0 is a repository of rpm packages built in koji. 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. 6. Ring 0 contains the minimal libraries that define the OS API/ABI, such as glibc. This probably happens implicitly by #3, repoclosure. 7. Ring 0 contains the tools needed to update existing packages and install new packages. That's the starting point, but it is by no means comprehensive. The OS probably provides specific services beyond the ability to login, for instance. Which styles of boot are supported? Where does installation infrastructure like anaconda land? This is equal parts philosophy and practicality. Also, policies for ring 0 may differ from what Base has previously adopted: Do we create a ring 0 minimal compose since we already need to check repoclosure? This might be a great way to refactor primary/secondary such that we can gracefully transition i686 down and secondary arches up. Lots of opportunities, much to consider. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/02/2015 12:37 PM, Jakub Jelinek wrote: On Wed, Sep 02, 2015 at 03:31:04PM -0400, Matthew Miller wrote: 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. H. Are we sure about that? That means that one can't, for example, subpackage an optional feature with huge dependencies (or cascading explosion of dependencies) to keep them from being pulled into Ring 0. If this is the case, are we open to having *separate* Ring 1 packages built from the same source but with different options? Yeah. E.g. it would really surprise me if you could keep libgcc or libstdc++ packages out of Ring 0. But do you want because of that all the other subpackages of gcc (almost 50) with all their dependencies. Right, so there are two avenues that spring to mind: 1. Do we split packages up into separate builds to isolate subpackages? This sounds pretty ugly. A maintainer would have to keep them manually in sync. A gcc-ring0 and a gcc-ring1 source rpm? 2. Ring 0 can include 2 separate composes: The required subpackage pieces go into one repository that does pass repoclosure, the remaining subpackages go into a second repository with less strict requirements. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/02/2015 12:24 PM, Adam Miller wrote: On 08/31/2015 10:18 AM, Brendan Conoboy wrote: For today's meeting we didn't really use zodbot minute keeping features, so in the interest of sparking some discussion I'd like to recap. At Flock 2015 there was a 2 hour session on the subject of rings which are basically policy zones inhabited by packages. Right now fedora packaging has 1 policy, so the entire OS is in a single ring. Creating more rings means creating more policies. By doing this Fedora can become adopt the flexible to appeal to diverse development communities and thus grow. The general consensus at Flock was that Environments and Stacks should take the lead in helping to define new rings, and especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). A week or so ago, a small Environments and Stacks meeting took place where it was generally agreed that the Base working group was the right place to define Ring 0. That brings us to this morning's BaseWG meeting. I talked a lot so here is a rough recap integrating a few of the questions and comments people had (Do read the log if you have time!) Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: 1. Ring 0 is a repository of rpm packages built in koji. +1 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. What's the definition of login prompt here? Is the discussion around targeting GDM or just a getty from systemd-logind.service? I was thinking systemd-logind.service. Keeping the GUI stack out of ring 0 seems highly desirable. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). +1 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. Do you mean that BuildRequires don't need to be members of Ring 0 in the above? Yes. Restated: Packages listed in 'BuildRequireis' do not need to be members of Ring 0. Minimizing the number of such requirements is highly desirable, however. [snipped +1s] That's the starting point, but it is by no means comprehensive. The OS probably provides specific services beyond the ability to login, for instance. Which styles of boot are supported? Where does installation infrastructure like anaconda land? This is equal parts philosophy and practicality. Also, policies for ring 0 may differ from what Base has previously adopted: Do we create a ring 0 minimal compose since we already need to check repoclosure? This might be a great way to refactor primary/secondary such that we can gracefully transition i686 down and secondary arches up. Lots of opportunities, much to consider. +1 - I like the idea of formulating a definition of what these things mean. I think having Ring0 as a deliverable entity and the core building block that all "editions" are built from is a great idea. The way this works out in my head is effectively that Workstation, Server, and Cloud would be built on top of Ring0 and it could also carry over to the spins. Possibly, later in life, allowing the "higher level" bits that everyone in the different SIGs care about to move more quickly/independently of Ring0. Is that more or less where this is going or am I off in crazy town? That's definitely one of the directions I think this goes: Once you break up ring 0 and ring 1 policies you can start thinking about ways in which release cycles decouple, or even having longer support terms for lower rings. Thanks for the recap and +1 for the re-introduction with a new title :) Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/02/2015 12:24 PM, Josh Boyer wrote: On Wed, Sep 2, 2015 at 2:59 PM, Brendan Conoboy wrote: Re-sending this with a better title so people might read it ;-) I read it last week. Perhaps the lack of commentary isn't because of the title. It's because there is nothing new here. The proposal boils down to "collection/classification of packages that are important." There is nothing about how to actually start here. See below. Perhaps it's a combination of both, but the repost has definitely gotten more replies. Comments inline below. At Flock 2015 there was a 2 hour session on the subject of rings which are basically policy zones inhabited by packages. Right now fedora packaging has 1 policy, so the entire OS is in a single ring. Creating more rings means creating more policies. By doing this Fedora can become adopt the flexible to appeal to diverse development communities and thus grow. The general consensus at Flock was that Environments and Stacks should take the lead in helping to define new rings, and especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). A week or so ago, a small Environments and Stacks meeting took place where it was generally agreed that the Base working group was the right place to define Ring 0. That brings us to this morning's BaseWG meeting. I talked a lot so here is a rough recap integrating a few of the questions and comments people had (Do read the log if you have time!) Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: The original incarnation of the Base WG defined this already. How does your definition differ? For that matter, how does your definition differ from the existing critpath concept that is already implemented in bodhi? These are good questions, but perhaps premature. Here's another: What is the ongoing purpose of the current Base WG? This discussion may serve as a focal point for some of its next steps. The discussion at flock was, everybody wants to move forward with rings, but they need to know the specifics, so that's what we want to accomplish. I would like to see Fedora serve a broader base of users and new/existing developer communities- rings in general can do this, but I've only written about the ring0/ring1 split. 1. Ring 0 is a repository of rpm packages built in koji. 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. Define login prompt. Am thinking text login prompt, IE, served by systemd. Keeping GUI out of ring0 seems desirable. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. These match the previous definition that the Base WG came up with. Nothing came of that except the dependency reduction work that a few people jumped into and Harald bravely carried on with. Hopefully people aren't expecting everything to be brand new and also somehow a good idea. 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. Also the same as before. Ah, but the compose question might be answered differently. 6. Ring 0 contains the minimal libraries that define the OS API/ABI, such as glibc. This probably happens implicitly by #3, repoclosure. 7. Ring 0 contains the tools needed to update existing packages and install new packages. Which is where a lot of the bulk came from in the original definition. This brings in python at a minimum. If by tools you mean "graphical updaters" then you're almost back to Ring 0 being Fedora distribution. So precise language is needed. How about "1 CLI update tool
Re: Fedora Ring 0 definition
On 09/02/2015 12:31 PM, Matthew Miller wrote: On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote: Re-sending this with a better title so people might read it ;-) Yes, thanks -- I admit to having skimmed over it in my mail-catchup attempt. especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). If people aren't gonna want to rename Rawhide to Bikeshed, then maybe *this* could be called that. :) Hah! Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. Speaking of bikesheds... we've traditionally defined the Fedora operating system as *the whole thing*, so now calling a subset of that the OS gives plenty of room for quibbling. I'm hoping to forestall that by saying that regardless of that, we all know what you mean here. That may be optimistic. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: 1. Ring 0 is a repository of rpm packages built in koji. 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. In my conception, the "is limited to" set was Ring 0, and the thing you are calling Ring 0 was Ring 1, and then Envs and Stacks was Ring 2. I can live with ajusting things; just noting. For the rest of this message I will use your levels. Where do optional subpackages go in your original definition: IE, where does gcc-c++ land: Ring 0 or ring 1? You could even go wild and say that ring 0 is the compose of the Requires satisfiable pieces, Ring 1 is the compose of the Requires non-satisfiable pieces from the same source rpms, then Ring 2 is what I called 1. I like Langdon's ring0 ring0' (prime) notation better though, it clears up that a single source package is responsible for both pieces of each number. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). *nod* 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. When you say Ring 1 here, you mean Ring 0, right? Yep. 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. H. Are we sure about that? That means that one can't, for example, subpackage an optional feature with huge dependencies (or cascading explosion of dependencies) to keep them from being pulled into Ring 0. If this is the case, are we open to having *separate* Ring 1 packages built from the same source but with different options? That sounds bad to me- we would need machinery to keep them in sync, and it would be more work for developers. 6. Ring 0 contains the minimal libraries that define the OS API/ABI, such as glibc. This probably happens implicitly by #3, repoclosure. 7. Ring 0 contains the tools needed to update existing packages and install new packages. At the DNF level or at the Yum level? Not sure I understand your question: I had dnf in mind, but the gist of it is that ring 0 includes a tool which handles automated dependency resolution. It's arguable though, rpm+curl could be considered sufficient. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/02/2015 12:47 PM, Simo Sorce wrote: On Wed, 2015-09-02 at 15:31 -0400, Matthew Miller wrote: On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote: Re-sending this with a better title so people might read it ;-) Yes, thanks -- I admit to having skimmed over it in my mail-catchup attempt. especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). If people aren't gonna want to rename Rawhide to Bikeshed, then maybe *this* could be called that. :) Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. Speaking of bikesheds... we've traditionally defined the Fedora operating system as *the whole thing*, so now calling a subset of that the OS gives plenty of room for quibbling. I'm hoping to forestall that by saying that regardless of that, we all know what you mean here. That may be optimistic. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: 1. Ring 0 is a repository of rpm packages built in koji. 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. In my conception, the "is limited to" set was Ring 0, and the thing you are calling Ring 0 was Ring 1, and then Envs and Stacks was Ring 2. I can live with ajusting things; just noting. For the rest of this message I will use your levels. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). *nod* 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. When you say Ring 1 here, you mean Ring 0, right? 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. H. Are we sure about that? That means that one can't, for example, subpackage an optional feature with huge dependencies (or cascading explosion of dependencies) to keep them from being pulled into Ring 0. If this is the case, are we open to having *separate* Ring 1 packages built from the same source but with different options? This is what I replied to the original mail too, nobody answered ... I answered- did you miss it? Simo. 6. Ring 0 contains the minimal libraries that define the OS API/ABI, such as glibc. This probably happens implicitly by #3, repoclosure. 7. Ring 0 contains the tools needed to update existing packages and install new packages. At the DNF level or at the Yum level? -- Matthew Miller Fedora Project Leader -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/02/2015 02:14 PM, Simo Sorce wrote: On Wed, 2015-09-02 at 13:57 -0700, Brendan Conoboy wrote: On 09/02/2015 12:47 PM, Simo Sorce wrote: On Wed, 2015-09-02 at 15:31 -0400, Matthew Miller wrote: On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote: Re-sending this with a better title so people might read it ;-) Yes, thanks -- I admit to having skimmed over it in my mail-catchup attempt. especially how the rings interact. As a side note, everyone agreed the word "rings" breaks down the further you get away from the center, but nobody has come up with something better yet (Venns? Blobs? Zones?). If people aren't gonna want to rename Rawhide to Bikeshed, then maybe *this* could be called that. :) Right now the Fedora distribution is 1 ring, let's call it ring 1. The distribution contains an operating system and numerous applications that run on that operating system. When we talk about defining ring 0 we're really talking about distinguishing between the operating system and the applications that run on top of it. Speaking of bikesheds... we've traditionally defined the Fedora operating system as *the whole thing*, so now calling a subset of that the OS gives plenty of room for quibbling. I'm hoping to forestall that by saying that regardless of that, we all know what you mean here. That may be optimistic. We want to go from this: Ring 1: The Fedora Distribution To this: The Fedora Distribution: Ring 0: The Linux Operating System Ring 1: The Applications and Stacks It seems quite modest, but working through the details on what this means is hard. What is an operating system in the Linux context? Ring 0 will likely have the strictest set of policies of all the rings, so we want to keep it as small as possible, but it is more than a minimal install. These are the traits of rings in general and ring 0 in particular as I see it: 1. Ring 0 is a repository of rpm packages built in koji. 2. Ring 0 contains, but is not limited to, the minimal install of packages to go from Power On to a login prompt. In my conception, the "is limited to" set was Ring 0, and the thing you are calling Ring 0 was Ring 1, and then Envs and Stacks was Ring 2. I can live with ajusting things; just noting. For the rest of this message I will use your levels. 3. Ring 0 passes repoclosure on its own (Packages listed as hard "Requires" in a ring 0 spec file are themselves are implicitly ring 0). *nod* 4. Ring 0 is not self hosting. Packages listed in "BuildRequires" do not need to be members of Ring 1. This isn't ideal, but it's a practical consideration. When you say Ring 1 here, you mean Ring 0, right? 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. H. Are we sure about that? That means that one can't, for example, subpackage an optional feature with huge dependencies (or cascading explosion of dependencies) to keep them from being pulled into Ring 0. If this is the case, are we open to having *separate* Ring 1 packages built from the same source but with different options? This is what I replied to the original mail too, nobody answered ... I answered- did you miss it? Apparently never got it, I've had some annoying SPAM false positives recently that involved fedora lists posts (I also missed a chunk of flock mailing :-/) Yeah, I found a big chunk of flock email in my spam folder as well *after* the event. Sigh. Here's a pointer to the message: http://www.spinics.net/lists/fedora-devel/msg213539.html A quick cut&pate from that reply: [blc] >> 5. Ring membership is at the source package level, not the binary >> package. If one source package's binary/noarch sub-package is in ring >> 0, all sub-packages are in ring 0. > [simo] > Can you elaborate more on this point (5) ? > > I can totally see how a package may be critical and therefore deserve to > be in ring 0 and yet have optional features in terms of subpackages that > are not necessarily ring 0. > For example some library that offers optionally bindings for somewhat > rarely used languages (say ocaml). The subpackages for those bindings > shouldn't necessarily be ring 0. > > Or did I misunderstand the point ? [blc] Let's take gcc for example. The gcc package produces numerous subpackages including various compilers and libraries. One of those libraries, libgcc, is linked into nearly every dynamically linked ELF executable on your system (Run ldd to confirm), including /sbin/init. Since we really want /sbin/init to function we need to include libgcc in ring 0. Since ring membership is at a source level rather than a sub-package level, gcc is ring 0. There are other good arguments for the executable-genera
Re: Fedora Ring 0 definition
On 09/07/2015 05:21 AM, Miloslav Trmac wrote: 2015-09-02 23:24 GMT+02:00 Brendan Conoboy mailto:b...@redhat.com>>: [blc] >> 5. Ring membership is at the source package level, not the binary >> package. If one source package's binary/noarch sub-package is in ring >> 0, all sub-packages are in ring 0. > [simo] > Can you elaborate more on this point (5) ? > > I can totally see how a package may be critical and therefore deserve to > be in ring 0 and yet have optional features in terms of subpackages that > are not necessarily ring 0. > For example some library that offers optionally bindings for somewhat > rarely used languages (say ocaml). The subpackages for those bindings > shouldn't necessarily be ring 0. > > Or did I misunderstand the point ? [blc] Let's take gcc for example. The gcc package produces numerous subpackages including various compilers and libraries. One of those libraries, libgcc, is linked into nearly every dynamically linked ELF executable on your system (Run ldd to confirm), including /sbin/init. Since we really want /sbin/init to function we need to include libgcc in ring 0. Since ring membership is at a source level rather than a sub-package level, gcc is ring 0. There are other good arguments for the executable-generating tools living in ring 0, but this one illustrates the point. (Sorry, I have not been following the conversation over the months in detail, have not seen the Flock presentations, and I may well be missing something. But still, it seems worth asking for a sanity check.) The whole conversation seems to me rather confusing, and more likely, just confused. How did we end up (or at least it seems that way) with a consensus that we will have policy rings, i.e. organization into ideal subsets, and a consensus that they will be based on SRPMs, and perhaps even a tentative consensus that the rings should be transitively closed over BuildRequires, /without any consensus on what the rings are?!/ We don't have a consensus yet, that's part of what the discussion is about. What we have so far is a general idea that E&S roughly oversee how the rings interact and distinct groups should have input into the definition of each of the rings. Ring 0 looks roughly like the Base WG's domain. AFAICS somehow the goals and means have gotten confused, and we are trying to find goals that would make sense in a specific implementation method; that’s completely backwards. Thinking about a few possible goals¹: * They have /nothing/ to do with SRPMs—actually even the concept of “source code” does not appear—and most of the policies are not inherently tied to SRPMs; they could just as well be specified, documented, tested or enforced in terms of a whole installed system, or in terms of individual elements. We /might/ want to ultimately /implement/ the policies in terms of SRPMs, but the /goals/ are not in terms of SRPMs, so thinking about the policies in terms of SRPMs is unnecessarily restrictive. * There is no subset/superset relationship between SRPMs, or individual files, implementing these goals; the goals are not even in terms of files! Let’s think about the/produced artifacts/, whatever that is, first: decide what we want to achieve by the policies, and what the desired and practical policies would be. /Then/ would be an appropriate time to check for subset/superset relationships and other ways to inherit/share effort; /not/ at the very start of the definition process! You are right that we do need to think about overall goals to be achieved, then the policies that achieve those goals. For my part I am interested in distinguishing the OS from the applications that run on top of it. This might be the difference between ring 0 and ring 1. It's too early to tell, though. During today's base wg we talked a little bit further about possible goals that a ring 0 might fulfill (http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-14/fedora_base_design_working_group.2015-09-14-14.15.log.html). A few hypothetical possibilities as examples: 1. Make a "Base" (or ring0) compose who has its own alpha/beta/ga cycle that precedes the RC deadlines for the current editions and spins, providing a stable set of NVRs to base upon. 2. New boundaries for primary/secondary arch blocker status, rules for excludearch, threshold for inclusion in primary koji, etc. 3. Decouple the ring 0 release cycle and support terms from the editions. Maybe base comes out every 4 months. Or 9 months. Maybe it's supported for 24 months. Things like that- it's small. Editions and spins can pick the base release to build on. Also, it seems to me that it would be useful to, at least conce
Re: Fedora Ring 0 definition
On 09/07/2015 06:42 AM, Ian Malone wrote: On 7 September 2015 at 13:21, Miloslav Trmac wrote: Also, it seems to me that it would be useful to, at least conceptually, to not think about Fedora as a self-hosting perpetual motion^Wrecompilation machine, but as “just another huge application” being built using compilers and other tools which come from $some_other_magic_place. That’s not to say that self-hosting is not valuable—it is a critical property of the subset of the Open Source ecosystem which Fedora distributes—but it is more of a property of the ecosystem than the produced artifacts. I'm perfectly happy to leave this discussion to Redhat people, and I think you have some good points about not letting implementation drive goals. However people seem to be talking down self-hosting here. For fedora as a distribution self-hosting is a part of the "Freedom" foundation. It's no good insisting that source is available for packages if they cannot be built. Similarly it's not just a part of the ecosystem as that might imply, since the ability to improve and extend it also requires self-hosting. I've no opinion beyond that on whether it's considered part of ring 0 or cube beta. I'm just one person with an opinion, it would be best if everybody with a stake took part in the ring definitions. Creating additional rings that address communities where self-hosting is a foreign concept may be useful and desirable. Making Fedora a first class OS for languages where rpm packaging doesn't make sense is great! -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/07/2015 06:52 AM, Miloslav Trmac wrote: [snip] Oh I’m not at all suggesting that the Fedora universe should not be self-hosting, or that this self-hosting property should not be regularly verified by mass rebuilds or the like. I just wanted to say that that having various /subsets/ of the Fedora universe, and especially the by-definition-smallest ring 0 or its immediate superset, self hosting, is vastly complicating matters and I don’t see a benefit to it. Mirek Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is. Can we offer a longer term of support for ring 0 than ring 1? What happens when a bug in ring 0 requires a fix in ring 1, but the support window for ring 1 has closed? That's the main thing that's worrying about a free-for-all with self hosting. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/07/2015 05:34 AM, Miroslav Suchý wrote: Dne 2.9.2015 v 20:59 Brendan Conoboy napsal(a): 5. Ring membership is at the source package level, not the binary package. If one source package's binary/noarch sub-package is in ring 0, all sub-packages are in ring 0. So we are going to include all those *-doc subpackages? And all languages bindings? E.g look at rpm subpackages. Yes, this is a good question. Per elsewhere in the thread, it may make sense to have 2 composes: One for the bits that Requires can be satisfied, a second that requires outer rings to satisfy. It is a little messy though, and will require a more nuanced expression of rules for inputs and outputs. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/14/2015 11:40 PM, Miroslav Suchy wrote: Dne 14.9.2015 v 23:10 Brendan Conoboy napsal(a): /Then/ we could start thinking about /truly minimal/ concepts, perhaps “container minimal” = “the minimal set needed to start and run an executable dependent on Fedora ABI” (e.g. kernel version requirement +glibc+locale data+Python 3 interpreter+…, useful for building containers), “VM minimal” could be “the minimal contents of a VM needed to start and run…” (e.g. kernel implementation+init+container minimal, useful for single-app VM), “CLI minimal”, … Mirek Right, so I don't think minimal is the end goal, I think the OS (not the distribution) is the end goal- minimal is presumably a subset of the OS. And how we call this "truly minimal concept"? Ring -1? I would like to have those Rings zero based, where zero is absolute minimum to run. Somewhere. Not necessary on bare metal. The whole "OS" can be Ring 1. There is still plenty of numbers remaining. How is this useful? -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/15/2015 07:27 AM, Matthew Miller wrote: On Mon, Sep 14, 2015 at 02:19:38PM -0700, Brendan Conoboy wrote: Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is. Can we offer a longer term of support for ring 0 than ring 1? What happens when a bug in ring 0 requires a fix in ring 1, but the support window for ring 1 has closed? That's the main thing that's worrying about a free-for-all with self hosting. I think the main risk here, at least from a fast-moving-Fedora perspective, is that the build-dep in Ring 1 gets updated to be too new to build the Ring 0 package. (Or, less likely but possible, dropped entirely before Ring 0 support term ends.) This can be addressed by having a Ring 1 policy that packages may change, but all currently-supported Ring 0s need to be buildable from the latest Ring 1. If a Ring 1 update would be break that, a compat package would be required. Or, a more complicated but more flexible rule: assuming that we have multiple Ring 1s going at a time (as we currently have F21, F22, F23-branch, and F24-rawhide), there must be _some_ currently-active Ring 1 which would build every active Ring 0, but not necessarily the same one. So maybe Ring 0 version A would be slated to last through EOL of Ring 1 F25, and then Ring 1 F23, F24, F25 would all need to be able to build it, but F26 and F27 wouldn't (so compat packages could be retired if they're not needed for Ring 0 version B). Either of these seem possible. It's also reminded me of another "why rings" and "why split the OS out?" answer: Because it might be possible to move to a branch-per-major-version model instead of a branch-per-release-model for the non-OS components. Serious retooling for that one, of course, but it'd be neat. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/15/2015 07:51 AM, Josh Boyer wrote: On Tue, Sep 15, 2015 at 10:27 AM, Matthew Miller wrote: On Mon, Sep 14, 2015 at 02:19:38PM -0700, Brendan Conoboy wrote: Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is. Can we offer a longer term of support for ring 0 than ring 1? What happens when a bug in ring 0 requires a fix in ring 1, but the support window for ring 1 has closed? That's the main thing that's worrying about a free-for-all with self hosting. I think the main risk here, at least from a fast-moving-Fedora perspective, is that the build-dep in Ring 1 gets updated to be too new to build the Ring 0 package. (Or, less likely but possible, dropped entirely before Ring 0 support term ends.) This can be addressed by having a Ring 1 policy that packages may change, but all currently-supported Ring 0s need to be buildable from the latest Ring 1. If a Ring 1 update would be break that, a compat package would be required. The "if" is key there. Right now, rawhide breaks all the time because people are not aware ahead of time if something is going to break when they update package foo. Without automated testing around "what happens to Ring 0/1 if I bump foo", I'm afraid we'd be left in the exact same state. As you say, this is a long standing issue. It would be really helpful if we had some automated mechanism that upon rebase, all packages that used the rebase package as a BuildRequires was auto-scratch-built. Failure notice could go to both package owners. Would this be a spamathon or genuinely helpful? Or, a more complicated but more flexible rule: assuming that we have multiple Ring 1s going at a time (as we currently have F21, F22, F23-branch, and F24-rawhide), there must be _some_ currently-active Ring 1 which would build every active Ring 0, but not necessarily the same one. So maybe Ring 0 version A would be slated to last through EOL of Ring 1 F25, and then Ring 1 F23, F24, F25 would all need to be able to build it, but F26 and F27 wouldn't (so compat packages could be retired if they're not needed for Ring 0 version B). That makes my head hurt even more. If Ring 0 can be built by Ring 1 A, Ring 1 B, and Ring 1 C, which is actually used to build Ring 0 that is shipped? How does one do recreatable builds across all permutations of Ring0/1? And if all permutations must be tested, how is that _any_ different than just having it all in the same ring and simply not bumping certain packages? You probably use the latest Ring 1 to build Ring 0. That would be crazy, but we keep the ABI/API generating pieces in Ring 0 so it's not too bad. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On 09/15/2015 07:26 AM, Colin Walters wrote: 'On Mon, Sep 14, 2015, at 05:12 PM, Brendan Conoboy wrote: I'm just one person with an opinion, it would be best if everybody with a stake took part in the ring definitions. Creating additional rings that address communities where self-hosting is a foreign concept may be useful and desirable. Making Fedora a first class OS for languages where rpm packaging doesn't make sense is great! One thing I find strange is that while by some measurements the rings effort would be a major change, by others it seems to be a minor tweak of what exists today. I haven't seen for example any evaluation or discussion of the apparent assumption that Ring 0 will be binary RPM packages, maintained how they always have been. I haven't seen much discussion of "should ring 0 be RPMs". We talked about a related question at flock: Should packages built as COPRs be allowed into low level rings? The answer from RCM was no, due to trust and stability issues. I think we're assuming ring 0 is RPMs because we don't have a second package format that we deeply understand and think is suitable. To give a random contrast, look at OpenEmbedded: http://www.openembedded.org/wiki/Main_Page As far as being a flexible base layer that is *explicitly* not itself a Product, they do this *really* well. One thing I like beyond the technology is how they have one git repository for the core, then explicit "layers" which are also git repositories. These aggregate maintenance of *multiple* components and create a very *collaborative* model. This is not generally true in the "big bag of packages" model since the core/extras merge. One small thing we could do to try to emulate this for ring0 would be to put all of the spec files for Ring 0 into one git repository for example. And have actual peer review for patches, just like one sees on: http://lists.openembedded.org/pipermail/openembedded-core/2015-September/thread.html It's certainly an argument for ring 0 being the minimal install ;-) How do you deliver updates? -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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: 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 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 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
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 03/20/2012 10:44 AM, drago01 wrote: On Tue, Mar 20, 2012 at 5:56 PM, 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. 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 10:54 AM, Kevin Kofler wrote: As far as I know, this proposal is driven by community people, not Red Hat people. Many people in the Fedora ARM community are Red Hat people, but that's hardly relevant to the proposal. 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. No, Fedora ARM started years ago. There comes a point where a secondary cannot continue to grow. To become more than it is, it needs the support and interest of the main Fedora community. We are reaching that point. That is why we are having this discussion. (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.) I sincerely doubt it. Compare specs to a Tegra 3 chip. And that's just a mobile system. -- 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:15 AM, drago01 wrote: 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). Okay, feel free to send me private mail or ask in IRC and we can discuss, if only for academic purposes :-) -- 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:39 AM, Chris Adams wrote: And how many cell phones, tablets, and TVs is Fedora ARM planning to target? It doesn't sound like that's the target market (at least at this time). Indeed, targeting mobile devices on day 1 is beyond the scope of the proposal. The first step is the eat-our-own-dogfood target, which is self-hosting ARM servers. Mobile devices are a natural direction for Fedora ARM, of course, but as with every new direction there are a different set of challenges to be worked through. For now we're just talking about the core OS. -- 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:20 AM, Jesse Keating wrote: Honestly I've yet to see a succinct list of reasons why secondary arch is no longer good enough for the ARM effort, for at least the next few releases. I may have missed it in the flurry of emails and debate, anybody care to recap it for clarity? This was one of the points raised by FESCo yesterday, and it's a fine question that we'll be answering better, elsewhere, in due course. That said, where does this question lead? If we explain what we're trying to get to, will it somehow overcome the objections raised such as build system performance? For the sake of coherent discussion, let's assume that we have good reasons why we want to move to primary, and we can keep the subject on what the requirements are for doing so. The topic at hand isn't even ARM specific, it's just been prompted by us ARM aficionados. Again, I understand that there do need to be good reasons, that's just not the subject of this particular thread. So, other than build system performance, what are the requirements you'd like to see met? -- 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:50 AM, Chris Adams wrote: Okay, but how many ARM servers are in widespread use? For the resources required as a primary arch, there should be a large expected user base. The first sentence of the detailed description on the feature page is "ARM processors are the most popular CPUs in the world." but that is entirely irrelevant if you aren't targeting a significant number of those CPUs. Believe me, I want to target those CPUs, but no single proposal can include all the steps necessary to get there. Think of ARM-on-primary as the first of many steps designed to get us there. If you've ever climbed a mountain you'll know that the trick getting to the top is to put one foot in front of the other. This is just a step along the way. -- 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:16 AM, Jesse Keating wrote: You are materially impacted. AutoQA won't run until the entire build is complete. Updates cannot be prepared until the entire build is complete. Buildroots won't be updated with the build results until the entire build is complete. You won't know if your build /fails/ on the arch until it's done, etc... Having one arch significantly slower than the others absolutely creates material impact upon developers. I haven't run this by anybody yet, so if it's nonsense just say so, but... Would it be reasonable to, even amongst primary architectures, allow these steps to go forward even if one arch fails while another succeeds? Let's say we have arch-groups in primary- i686 and x86_64 are in a group, armv7hl and armv5tel are in a group. The results of one group do not inhibit the progress of another. Feasible with a bit of retooling, or a nightmare waiting to happen? The discussion so far has focused almost exclusively on build time. We hear you. Let's talk about what to do about it. And what concerns there are besides build time. -- 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:37 AM, Jesse Keating wrote: We had something like this where i586 and i686 were considered different arches, at least for the kernel, and those two builds would happen in parallel often on different machines. Perhaps the same could be done for the arm variants as well. Right now we consider armv5tel and armv7hl to be different aches so they are built on separate machines. That bit of optimization is done. IIf there is some sane way to distribute a single armv7hl or armv5tel build across multiple builders that may be an interesting avenue to pursue (Sanity tbd by releng:-). The builders we expect to see this year have 4 cores, but if we could realistically do a 'make -j 32' and have 8 systems involved in any one package, that'd certainly take care of performance concerns for parallelizable builds. It's a neat idea, but making it work reliably is a proposal unto itself. -- 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 12:05 PM, Jesse Keating wrote: So if you're willing to live like that, I must ask again, what do you think you'll be getting out of being a primary arch? I'm willing to temporarily do better than secondary and worse than primary on the road to becoming primary. This is a huge transition- identifying the right path to make that transition is part of what this is about. The whole point of this thread is to establish requirements for promotion. Part of that discussion logically includes the steps to get there. Currently what I hear is "be as good as x86 and you're there." That's not productive. There are legitimate issues with moving to PA so we're having this discussion to identify them and ultimately work through them. -- 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 12:03 PM, Chris Adams wrote: Okay, but why is ARM-as-primary-arch an early step, and not near the end? Increasing the developer and engineering burden across the whole project should not be done for a small target audience. Really there is no beginning and no end, so we're somewhere in the middle ;-) ARM-as-secondary was earlier. ARM-as-primary is next. Fedora-on-tablets is later. Fedora-on-cellphones is later. The bottom line is that Fedora is an rpm-based native-built operating system, so ARM servers come first. Fedora isn't currently built to run efficiently and smoothly on embedded devices. That's okay, it's nice to have followup projects. Meanwhile ARM servers are going to be important too. -- 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 12:19 PM, Jesse Keating wrote: What does "better than secondary arch" mean to you? I'm really struggling here. As an example, the same koji server handling x86 builds handling ARM builds. The same facilities providing power, cooling, storage. Subject to applicability, the same QE mechanisms being employed. The same release schedule. Comparable positioning on the Fedora downloads pages. Primary and secondary are night-and-day different, it isn't just the integrated build system being disconnected, it's end-to-end. We as a group have identified many of the roadblocks or pain points of bringing arm into primary arch. What pain points have been described other than "I am concerned about the impact of builds on the whole running slower than they do now"? This is not a facetious question, this is really what we're trying to get from the thread. -- 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 12:44 PM, Chris Murphy wrote: But this *requirements* thread is about acclimation, planning and anticipating the challenges of the climb. Serious climbs may involve days or months of this. So if the analogy holds, a lot of advance work has to be done before ARM actually is promoted to primary. This isn't the go, no-go meeting, or gear-up time. This is the shopping list. Thank you :-) Now the ultra ridiculous: How about secondary architecture requirements demoted as-is to tertiary. And create substantially more aggressive requirements for secondary architecture (in which ARM would be placed), yet are not identical requirements to primary architecture requirements? Yes, the all-or-nothing mindset between secondary and primary is almost certainly the root of the problem. We want more representation in Fedora than being a secondary connotes, but at the same time, ARM today does not fulfill every aspect of what PA means. The discussion is about what is required, how to get there. There has to be a way to represent Fedora's architectural support as a spectrum of features, not simply a binary assessment. I absolutely do want to get ARM onto the same koji build system, but don't want to make ARM the mortal enemy of every packager whose workflow is materially hampered. This discussion has been quite useful in shaping my opinion that we need to improve the koji portion of the proposal (Principally because of chain builds), but how to make those improvements needs to be worked out. -- 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 01:14 PM, Andy Grover wrote: Can Koji use distcc for ARM arches? Would that speedup be enough to make ARM build competitive with others? I believe this is a non-starter for rel-eng. The ARM team are not recommending this path. -- 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 01:32 PM, Przemek Klosowski wrote: Is cross-compile an option? if it is, how long does it take to cross-compile in an x86_64 environment? Discussed elsewhere in this thread. Not an option. -- 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 01:48 PM, Richard W.M. Jones wrote: I would suggest -- in order to move the present discussion on -- that you try using various methods to speed up an ARM build of (eg) glibc. distcc, some sort of demo cross-compilation, etc. What works, what doesn't work, what needs more work? Distcc suffers from a fatal flaw: You can't reproduce the build. Transient failures and corruption cannot be tracked down. We've done lots of experimentation with distcc, even using distcc + a cross compiler. It does great stuff to build time performance, but it sacrifices build integrity for performance and that's not an acceptable condition for PA. -- 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 01:03 PM, Jesse Keating wrote: As an example, the same koji server handling x86 builds handling ARM builds. Only the koji hub would be the same, the arm builders would be different machines. This isn't all that different from having the primary hub trigger the arm hub to start a build on the arm builders. So in principle, do you object to the same koji hub being used for ARM if ARM is still SA? The PPC builders are there, or at least were at some point, why not propose moving some arm stuff there for the arm secondary arch effort? ... I don't see SA/PA mattering as much here. It's up to QE what they want to take on and what they point automated tooling at. The sense I'm getting from your reply is that the PA/SA designation is almost decorative, that a secondary can do anything a primary can, except inhibit the progress of builds. So, if the Fedora ARM team fixes all broken builds, brings in all the QE mechanisms, engages the Fedora system at every level of the organization, solves the the build time performance issue, and otherwise keep at it until we're functionally indistinguishable from PA, *then* it's time to have the PA/SA discussion. Is that right? Speaking for myself, I see most of these things as a benefit of membership in PA rather than prerequisites. Or more to the point, transitioning from SA to PA means doing all of these things, so it's really just an order of operations that needs to be agreed upon. That's set by you, as a secondary arch. Why not pin it to the Fedora release schedule and see how well you do? We're quite close, though clearly the QE is different. That said, within the websites group perhaps there is room for a featured secondary arch, with high visibility. Having something to point to first would help. Fair enough. Did you just ignore the emails starting these two threads by mjg and pjones? I believe they outlined some very good requirements for getting a secondary arch into primary. These longer threads have been debating some of the finer points of those proposals. On the contrary, mjg and pjones' emails are just the sort of constructive and thoughtful feedback I'm looking for. If the points they've raised (which they also raised yesterday) speak to everybody's concerns, then I'm happy to view them as the authoritative feedback of Fedora-devel for our planning purposes. On the other hand, if they've left anything out that should be considered in this plan, I'd like to see it. -- 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 03:33 PM, Jesse Keating wrote: So in principle, do you object to the same koji hub being used for ARM if ARM is still SA? I'm not really sure how to process that question. As a current secondary arch, the primary hub is still the trigger point for the vast majority of the builds that will happen for arm. A successful build on the primary hub will trigger (through koji-shadow) a build on the secondary arches. I'm sure you're (painfully) aware of this. I don't understand how the same koji hub could be used for arm while arm is still SA differently than above. Context for the question: One of the benefits to PA that I see is that PA's infrastructure is really good. I mean, the reliability is outstanding. Kudos to all involved. To what extent can a secondary sharing in that bliss? Machines in the same racks? Services on the same machines? The same koji hub, but treating failed SA builds differently than failed PA builds? How close can we get to treating a secondary architecture like a primary, as far as that infrastructure goes? Is the limit, again, as close as we want up to the point of it affecting primary programmatically? Or should there be a separation, even if it's technically feasible to combine the services for both SA and PA? Mostly. It'll take effort on the part of the secondary arch to engage these other parts of the Fedora project to convince them to pay attention to your arch. If you were a primary, they're essentially forced to care. Enticing them to care as a secondary arch goes a long long way to show that you're ready to be a primary arch and that the promotion would not cause much ripple effect. Agreed. We definitely want promotion, in the end, to be a small ripple, if little notice because the hard parts are already done. That does seem right. Just like the old adage, dress for the job you want, not the one you have, or do the work for the promotion you want, and you'll earn the promotion, the same applies here. Show that the secondary arch can function well as a primary arch without significant burden to the rest of the project and then it's a much easier decision to make the promotion. Yes... "doing all of these things" doesn't happen magically just because the board/fesco grants that ARM is suddenly a primary arch. If we made arm a primary arch tomorrow, you'd still have to solve all the above issues, only now you've got hundreds of very angry developers who's workflow is now severely interrupted, and they're all calling for your head. Doesn't it make more sense to solve these issues /before/ doing the promotion? Figure out how to make the car go 60mph before taking it onto the freeway, else you'll piss off all the other cars on the freeway. Absolutely. We're having this discussion as a way to solve the issues before promotion. None of us expect ARM to be promoted today, or tomorrow, but perhaps 3-5 months from now is realistic. Or maybe that's too soon. The bottom line is that there are issues to be worked out and that's what has prompted the discussion. Fair enough, I honestly didn't think you had ignored it, and it was rude of me to suggest otherwise. I apologize for that. Thanks- I didn't think your replies mean spirited and very much appreciate your taking the time to think about the issues with the proposal. It's a work in progress and it will certainly be a while before it's complete enough that to be approved. We're charting a course toward primary and these threads are simply a way of drawing up the map we'll be taking. "fedora-devel" doesn't really have anything of the "authoritative" sort, we just have a lot of subscribers and opinions. Those opinions are usually considered by FESCo when FESCo makes a decision, and generally considered by those proposing something and asking for feedback on their way to a FESCo decision. Yep. Regards, -- 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 03:33 PM, Kevin Kofler wrote: You haven't answered his question: why would ARM-as-primary come before Fedora-on-tablets and Fedora-on-cellphones? Those can be perfectly supported using the secondary architecture infrastructure (or if not, we need to improve that infrastructure). That's two questions. I'll answer the first one: ARM Server semiconductors are more amenable to open source licensing than embedded & telecommunication companies, so getting a complete open source ARM Server running is simple compared to getting an ARM Linux tablet or cell phone running. -- 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 04:43 PM, Xose Vazquez Perez wrote: ARMv8 will be 64-bit and faster: http://en.wikipedia.org/wiki/ARM_architecture#ARMv8_and_64-bit http://www.arm.com/files/downloads/ARMv8_Architecture.pdf It should be ready for servers and desktops, maybe, in three-four years. But not today. ARMv8 is not contemplated in this proposal as it is so far out. -- 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/21/2012 05:25 AM, Chris Tyler wrote: Fully-emulated actually fits into the "Native Builds" guideline, but it hasn't been economical to use this approach because there's no hardware support for ARM emulation on x86 (the way that there is hardware acceleration for x86 virtualization on x86) and it therefore requires a very fast/expensive x86 box to emulate a slow/cheap ARM box. The main place I see ARM emulation being useful is in allowing any packager with an x86 host to boot a simulated ARM host to resolve build failures in their package. That's not ideal- ideal is every package owner has an ARM system they can use, but it's perhaps a starting point. If other people have feedback on this point I'd be interested to hear their take on it. I think a combination of ARM emulation and providing a network-accessible set of test machines will go along way toward giving packagers what they need and plan to update the proposal to say so, subject to the feedback we get on this point. -- 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/21/2012 06:26 AM, Peter Robinson wrote: Thanks Adam, this is the first real use case where speed of builds is important for something other than keeping the developer happy. Other points raised on the list are: 1. The nature of chainbuilds would feel slowed build times particularly. This is more of a multi-developer happy item. 2. Total turnaround time on security updates. -- 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/21/2012 11:18 AM, drago01 wrote: But there seems to be a huge oppositions against that in Fedora. How does Ubuntu build there ARM builds? Native or using cross compilers? Native. -- 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/21/2012 02:13 PM, Peter Robinson wrote: As do Debian I believe. I think, but aren't 100% sure, that all major distributions except suse build as native. At the last Linaro Connect the Debian guys said they're building natively on i.MX53 boards (Which are cool because they have real SATA). -- 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 03/21/2012 07:00 PM, Kevin Kofler wrote: ARM should most definitely NOT be approved as a primary architecture before all the requirements are actually met! The dynamics of "when" are very much open to discussion, not to mention "what" that will mean. We need a path to get from secondary to primary. Whether it's designated "primary" at the end of that path or somewhere in the middle is irrelevant- it's about getting ARM handled the Primary Way (TM) during the journey. We have seen what happened when the EU took Greece's word on the promise that they'd eventually meet the Maastricht criteria. Let's not do the same mistake in Fedora! What? -- 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 03/21/2012 07:50 PM, Kevin Kofler wrote: But there are x86 CPUs with more than 4 cores, and multi-CPU SMP systems which still present themselves as one (multi-CPU/core) computer. IIRC, our x86 Koji builders have 16 cores per machine (might be even more by now, not sure). Hypothetically speaking, if presented with an ARM system that builds packages, on average, 3x faster than x86, will you advocate that x86 be dropped to secondary and ARM be PA exclusively? Sure it's hypothetical, but if that one variable changes, how does your position change? -- 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 03/21/2012 08:13 PM, Kevin Kofler wrote: The Maastricht criteria are the requirements countries had to fulfill to get accepted into the Eurozone (i.e. to use the Euro as their currency). Greece was accepted into the Eurozone without fulfilling those criteria because they promised they'd fix the problems later. (FWIW, they also "adjusted" the stats to fit the criteria in more than one place and the EU failed to detect the cheating.) This is the main reason why we have the Euro crisis now. (Sorry for the European politics intermission, but I just had to explain the analogy. :-) ) I know what's happening in Greece. I don't know why you're bringing it up here. -- 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 03/21/2012 08:28 PM, Kevin Kofler wrote: I'm bringing it up here as an example (by analogy) of what happens when you let a country (an architecture) such as Greece (ARM) enter the Eurozone (the primary Fedora architectures) without fulfilling the required criteria (at the time of the approval, not at some promised later point). Your analogy was easy to understand, but why you wrote it was not. It's inappropriate and I can't imagine what good you think will come of having made it. Whatever your politics are they might not be shared by others taking part in this discussion and it's easy to see room for somebody taking offense at your analogy, Let's act like we're all on the same side. We are, after all, all working on Fedora. -- 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 03/22/2012 12:23 AM, drago01 wrote: While I agree that we will see more smartphones and tablets in the future the people that actually replace there traditional computers with tablets or even smartphones are near zero. Sells do not really tell the whole story as many people simply don't have a need to buy new laptops/desktops because what they have is "good enough" so they spend there money on other gadgets. I don't believe phones and tablets are going to completely usurp desktop computers, but if Fedora doesn't offer a path for people whose primary "computer" is a cell phone or tablet, we lose out on the next generation of developers and end users. That's a sure way to irrelevance. Then again, all this is beside the point: We're targeting ARM servers in the proposal. The groundwork we lay with ARM servers will also lead to Fedora's ability to support mobile devices including ARM laptops, tablets, and phones. But it's a much longer journey to run Fedora on a phone than it's going to be to run it on a server. -- 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 03/22/2012 04:26 AM, Peter Robinson wrote: Actually that is not the case, it might be the case in the western developed world, but in the developing world in places like China, India and Africa in most cases the first an only device that a user has is a smart phone or tablet due to the fact it's low power, runs off batteries and has wireless connectivity, I think you'll find the sale of these style of devices in those places out flanks everything else, they are selling 100s of millions of them. Indeed- it's even true in the US. I don't actually have a desktop- I have a laptop with a docking station- 2 monitors, quad core i7, 12GB of RAM. The next generation of this device will either be faster, smaller, a tablet, or cost less- possibly all 4. This won't stop until mobile phones and/or tables are dockable desktop computers. The high end will be servers that double as power-user desktops. There is literally no reason for anything in-between. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updated Fedora ARM qemu images?
On 03/22/2012 11:10 AM, Orion Poplawski wrote: I started looking at: http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu VM starts okay in F16 with setsebool -P virt_use_execmem=on But the image is a Fedora 12 system. Any updated images out there? You should be able to use the F17 alpha 1 image. The pointer is it: http://fedoraproject.org/wiki/Architectures/ARM We'll have the document updated for this soon. I've set reply-to to the arm list since the responsible parties are all there. -- 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 03/22/2012 01:23 PM, Adam Williamson wrote: I would still like you to consider the question of whether this holds for the Fedora case, though. Is Fedora as a project in fact suitable - either in current implementation, or in terms of our self-definition and long term goals - for this whole 'market' you are identifying as a single entity? Are we in fact truly interested in producing code for these content consumption devices? Is that what we're doing? #include Fedora is not currently suitable for mobile devices. The majority of end users want content consumption, not content creation, devices. The fact that computers up to this point have been general purpose enough to be both is why we're all here having this conversation. I'm not saying Fedora is going to save the world, but it can certainly save itself by making sure that future content-consumption devices can also be used for content creation. It's the hardware that the majority of all future developers-in-potential are going to own. -- 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 03/28/2012 07:27 PM, Andy Grover wrote: Wait, I thought there was some kind of "flattened device tree" or something that the ARM folks thought would let them avoid ACPI. Did that not pan out? Maybe MS put the kibosh on it? In the long run you're likely to see FDT for mobile devices and UEFI for servers. Jon's prognostications are regarding the long view (years). -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Feedback on secondary architecute promotion requirements draft
here source would be incompatible but binaries wouldn't be, but thought I'd mentioned it. > Excludearch may be used only to disable packages that are > fundamentally architecture specific. Assuming we mean the package has architecture specific components that either can not, or have not, been ported, agree. > Installable, testable images must be generated at the normal project > milestones in a way that conforms to release engineering and QE > requirements. Where possible, image generation should be integrated > into the existing image generation infrastructure. As long as the RE and QE requirements are similarly defined that's fine. > The architecture must meet appropriate formal release criteria As long as the release criteria are applicable to the architecture. > This list is not intended to be exhaustive - 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 Engineering Steering > Committee, and additional criteria may be imposed if felt to be > necessary. Let's make the list exhaustive; there needs to be a path to sure success. This means establishing a complete procedure where when an SA formally applies to become PA, acceptance means there is a definitive set of steps needed to get there. This is one of the major reasons for developing these criteria. Put another way: FESCo and affected groups should have the ability to review whether or not the SA has in-fact fulfilled the requirements for PA, as agreed to by all parties at the time of application. If those requirements are deemed to have been met, promotion is automatic. There could be a deadline on application acceptance: EG, 12 months from acceptance of application to fulfillment of criteria. This protects against criteria becoming stale. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 04:58 AM, Josh Boyer wrote: On Apr 2, 2012 11:10 PM, "Brendan Conoboy" mailto:b...@redhat.com>> wrote: > All builds must occur on Fedora-maintained build servers. > > FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. Exactly. And if there were two unrelated arches in transition it would mean 2 hubs would be needed. The point here is that a piece of hardware is needed so SA's making the transition will need to ensure this hardware is available. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 09:07 AM, Josh Boyer wrote: From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. Where do you envision the builders being in this scenario? I see the steps being something like this: 1. SA builders and/or hub are located outside PHX. 2 option a. Builders come up in PHX, hub stays in original location. 2 option b. Staging hub comes up in PHX, builders stay in original location. 3. Both staging hub and builders come up in PHX 4. When appropriate move from staging hub to primary hub. Having everything take place in PHX prior to the switchover has numerous benefits. These 3 come to mind immediately: 1. Fast local network will represent true build times (vs transfering rpms across the external network). 2. Realistic load assessment. If, hypothetically primary koji and staging koji are both virtual machines on the same underlying hardware you'll know if the hardware can handle the load. Also network, disk, etc. 3. Comparable infrastructure reliability. Switching koji hubs twice does incur a bit more work, but it may also provide better results. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 12:02 PM, Josh Boyer wrote: Erm... you already have this. So will any SA making a transition. I don't see a problem. Outside PHX, yes. Inside, no. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 12:10 PM, Kevin Fenzi wrote: I'll note again that the ppc and s390 secondary arch hubs are in fact in phx2. ;) You're already one step ahead of ARM ;-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 08:21 AM, Peter Jones wrote: [snip] > We need to make the whole process one with continuous feedback, or it's never going to work. So I'd expect that we don't want to specify anything all that precisely - I'd rather you come up with an implementation plan to satisfy each point, and then we (SA Maintainer and FESCo) decide together if it's satisfactory, and later decide that it has or hasn't yet been met, and if not what remedial steps should be taken. Communication is really the piece which needs development in the proposed guidelines. SA's tend to work quite independently so the proposal needs to spell out a few things that get everybody communicating at the right times and the right ways. It's probably perfectly clear in many people's minds folks how these things should be handled, but if we could formalize them a tiny bit it would do wonders for filling in what's missing in the secondary promotion draft. 1. What does the SA2PA proposal need to cover? MJG's 10 criteria give a general scope of what needs to be covered, so this is more or less done. If I'm reading Peter's comments above correctly the guidelines should indicate that the SA2PA proposal must be generated by the SA team (as opposed to FESCo) and should address all 10 points. 2. How should an SA team propose to FESCo and the community that their SA is ready to be evaluated for PA track? Is submitting a feature page the right way to start, or a discussion on f-d-l? Whatever the right way is I'd like to see that information added to the proposed guidelines. 3. When should the SA team make their first proposal? There is great potential for wasted effort bringing the topic up too early or too late in the SA's development, not to mention when in the primary release cycle such topics should be brought up. 4. How to keep FESCo and the community informed during the process. Presumably after #2 there will be feedback along the lines of "you need to do more on points x, y, and z". If the answer is "FESCo will say how to keep everybody informed" then let's have the proposal state that. Basically, I think the guidelines MJG has put together are good principles; they just need some procedural blanks filled in so SA teams know how to apply them and communicate with the greater Fedora community. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/16/2012 02:20 PM, Matthew Garrett wrote: I think a better way to think about this might be lie the packaging guidelines - they provide a set of technical constraints, but they don't tell you how to be part of the packaging community. I see SAs in the same kind of way. Secondary architecture maintainers should be active members of the greater Fedora community. You should be talking about what you're doing, providing regular status updates on devel@, actively involving yourself in other technical discussions to make sure that decisions aren't made without consideration of your constraints. Basically, behave as if you're a primary architecture. If you manage that then I think most of the problems you're worried about go away. It'll be obvious to everyone whether or not you're ready to be a primary architecture at any given point. Don't worry about the details. Just be part of Fedora. That almost sounds like an argument for scrapping the promotion requirements document entirely. Is that what you meant? I understand where you're coming from philosophically, but we're talking about something more concrete. Many people who are interested in SA2PA promotion requirements are working on Fedora 24/7 and they want guidance too. As documents go I'm all for having a philosophical section on what the mindset is, but it should be matched with applied examples. I think what you're trying to say above is "For a secondary architecture to become primary architecture, its team should have a demonstrable history of communicating with the greater Fedora community about what it's doing and how the greater Fedora community's activities are affecting it." If that is indeed what you mean, please put it in the document and include some examples. The word "communicate" doesn't exist in the current document. I'm open to providing what I think are reasonable examples if they may ultimately make it into the end document. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 08:31 AM, Peter Jones wrote: Look at it this way - if an arch is following the process to become primary, but during that process actually becomes *less* viable, or for whatever reason farther from being reasonable as a PA, the process needs to be such that that's something people see and discuss. If it doesn't come up, it's because it's completely fallen off the deep end. So I'd much rather just say that an arch that's attempting to transition from secondary to primary needs to regularly keep FESCo and f-d-l informed as to the status than have something like formal sunsetting. If they don't keep us up to date, they have de facto stopped trying. Okay, I'm relenting on automatic promotion. Basically, Peter is right that communication is essential, so some guidelines on what needs to be there would be most helpful. I would appreciate wider feedback on message ID 4f8c8416.4000...@redhat.com from yesterday. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
simulator (with X support) would meet this requirement. If not then the requirement is essentially: Most packagers on the critical path must own one of these SA-supported systems before it can be primary. Excludearch may be used only to disable packages that are fundamentally architecture specific. Assuming we mean the package has architecture specific components that either can not, or have not, been ported, agree. I'm not enthusiastic about excludearch being used simply because a component hasn't been ported, but I think that's probably a stronger position than we've traditionally had so I'm probably ok with it being used for that. Okay, please clarify in the document. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/18/2012 06:42 PM, Matthew Garrett wrote: [snip] What if some forms of the hardware are desktop capable, others are not, but the community only has an interest in supporting headless installations? Then it's not fit to be a primary architecture. Okay, please add examples like this wherever possible. I believe a subsequent discussion on the matter has yielded the value of 4 hours. Can the guidelines include this, perhaps with the caveat of "At the time this draft was approved, the agreed maximum build time for a kernel was 4 hours." No, because it's the kind of thing that's going to be influenced by multiple factors. Each architecture seeking PA status should have this discussion with the kernel team. Huh? The whole point of this item is that it's architecture neutral- the kernel team for security reasons believes it important that all kernel builds take less than 4 hours from start to finish. Why would a new architecture change that number? There's a caveat in the suggested wording above. Don't understand the resistance. Okay, you're clearly writing that with a do everything to be PA while SA, then you'll have proved yourself mindset. That's fine, but it would help to spell this out. You might just as well say all architecture-specific issues are fixed before promotion may be granted. I'm not sure that's an achievable goal, frankly, but that does seem to be what you're saying. Becoming a PA won't magically produce extra maintainers. It's still going to be up to the architecture maintainers to deal with ARM-specific bugs in packages, if the package maintainer isn't able to deal with them. So, yes, I think in this respect it's important for the SA to demonstrate that it's not going to hold up development once it becomes primary. I'm nonplussed by the answer, but can't disagree with it either. This seems to make #5 and #8 the same thing. You just need to merge them by adding the changes you'd already agreed with below, and including something like "All packages that are architecture neutral or have been ported to ARM must build from the same srpm prior to PA promotion." [snip] I'm not enthusiastic about excludearch being used simply because a component hasn't been ported, but I think that's probably a stronger position than we've traditionally had so I'm probably ok with it being used for that. Okay, please clarify in the document. Ok. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/18/2012 06:54 PM, Matthew Garrett wrote: Not really. The proposed criteria provide strong guidance. If you meet them all then you're probably fine. But the point isn't to be slaves to these criteria. It's to be active particpants in the Fedora development community. It's a big if for any secondary to meet such criteria. Right now I don't think ARM's doing a great job of that. Your meetings happen on the phone and aren't minuted. I've got no insight at all into how your development process is progressing. At minimum you should be meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd be Cc:ing them to devel@. If you're doing everything transparently then people are more likely to object to things at the time, whereas if you turn up at the beginning of F19 and say "Look, we've ticked all your boxes" you're liable to find people who haven't been actively following you and have only just realised that you're done something wrong. While I'm glad you've taken the time to watch the ARM team and form these opinions I'm also sad you've waited until now to share them. Why haven't you troubled yourself to mail fedora-arm about this matter instead of bringing it up at an inappropriate time? We're talking about secondary architectures in general here, not ARM. This document isn't supposed to be a discussion of how to be good members of the Fedora community. A secondary architecture should be led by people who already know how to do that. Volunteers welcome. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/18/2012 07:13 PM, Matthew Garrett wrote: Huh? The whole point of this item is that it's architecture neutral- the kernel team for security reasons believes it important that all kernel builds take less than 4 hours from start to finish. Why would a new architecture change that number? There's a caveat in the suggested wording above. Don't understand the resistance. The kernel team may have their view skewed by how likely they think it is that a given architecture will be likely to force additional rebuilds. So yes, the point of this document is that it's architecture neutral, and so it's inappropriate for it to list figures that have been quoted for a specific architecture. This is very puzzling. As part of your proposal we had the discussion with the kernel team and they came back with the answer for this proposal. Now you don't want it. If you don't want to kernel team's answer, why mention them at all? If it's a general principle for a braod spectrum of packages that's entirely sensible and the document shoudl say so. If we're specifically calling out the kernel and nothing else it's nonsense to ignore the answer to the question. Not really. You could potentially satisfy number 8 without satisfying number 5, and you could satisfy number 5 without satisfying number 8. As you like. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/18/2012 10:12 PM, Matthew Garrett wrote: On Wed, Apr 18, 2012 at 09:57:19PM -0700, Brendan Conoboy wrote: On 04/18/2012 07:13 PM, Matthew Garrett wrote: The kernel team may have their view skewed by how likely they think it is that a given architecture will be likely to force additional rebuilds. So yes, the point of this document is that it's architecture neutral, and so it's inappropriate for it to list figures that have been quoted for a specific architecture. This is very puzzling. As part of your proposal we had the discussion with the kernel team and they came back with the answer for this proposal. Now you don't want it. If you don't want to kernel team's answer, why mention them at all? If it's a general principle for a braod spectrum of packages that's entirely sensible and the document shoudl say so. If we're specifically calling out the kernel and nothing else it's nonsense to ignore the answer to the question. They're happy with it being 4 hours for ARM. The number might be different for some other architecture. Since this is supposed to be a generic document, it's not appropriate to put the 4 hour figure in it. Still not following you. Everything in PA builds at once- 4 hours is the lowest common denominator that the kernel team will accept. The builds all start at the same time and have to end within 4 hours, regardless of arch. This is a silly thing to be quibbling over so I'll leave it there. -- 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 04/23/2012 12:54 PM, "Jóhann B. Guðmundsson" wrote: So FESCo is in otherwords saying that other installers and even installing methods ( think like the distribution would be flashed to a device in the maybe not to distant future instead of being installed in the traditional sense as we know it to be ) are not allowed or otherwise considered to be part of the distribution should some community members want to writer and or package an alternative installer to ship and use on their spin? It's not about anaconda specifically, it's about having a standard installer experience across all PAs to the extent technically sensible. Maybe something else will supplant anaconda in time. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
On 05/09/2012 03:32 PM, Paul Whalen wrote: As per our meeting today, we would like to have a VFAD on Friday May 11th at 12pm (EDT) to run through the modified Fedora ARM release criteria (http://etherpad.proximity.on.ca:9001/p/k8c7SAPEhA ) in preparation for the Fedora 17 ARM Beta release. Please take a moment before the VFAD to review the release criteria and provide feedback in #fedora-arm rather then editing the document directly. Hi Everybody, Thanks to everybody who took part testing images during today's VFAD! Here is a summary of what was covered: The following images (At http://scotland.proximity.on.ca/arm-nightlies/) are booting and operating correctly: Trimslice for serial console with SD Card Trimslice for serial console with USB Sata Raspberry Pi for serial console with SD Card (Non-F17 kernel) Raspberry Pi for X console with SD Card (Non-F17 kernel) Versatile Express for serial console with qemu-system-arm (Non-F17 kernel Versatile Express for X with qemu-system-arm (Non-F17 kernel) The following images did boot successfully, but some people observed network issues: Beagleboard XM for serial console with SD Card (Hard Float) Beagleboard XM for serial console with SD Card (Soft Float) I'm rebuilding the Beagle XM images now with a new uboot and an old (known good) kernel. We'll be looking for testers on these- let me know if you plan on trying out either configuration and I will let you know when the new image is in place. The following images did not boot successfully: Pandaboard for serial console with SD Card Pandaboard for serial console with USB SATA The Pandas had problems with the uboot environment (It had never been tested), as well as a kernel panic during boot. Like the Beagle XMs, these are being regenerated. Let me know if you plan on retesting. Additionally, the USB SATA image will require a companion SD image to provide MLO/UBoot. This is not currently provided. The following image was not tested: iMX51 for serial console with SD Card. This image might work with an Efika smarttop (?), but nobody had a chance to test it out. Please note if you're planning on testing this, this is not going to give you a groovy Efika F17 GUI experience- they're still working on the kernel drivers, as I understand it. It's a serial console only image. With regard to release criteria: Alpha Release Criteria: o Each image is accompanied by an MD5 sum. o No known file conflicts exist. o Firstboot: Is not currently operable, but the images do automatically resize and a guest account is available for the X images. Todo. o Virtual consoles: Unknown. Todo. o Default web browser: A web browser is not installed in any image. Suggestions for a suitable browser welcome. Todo. o Update status: Images are up-to-date at generation time. Yum update works. o Graphics: Base X, XFCE Desktop are installed and provide artwork. Graphical bootloader was not tested (rhgb?). Graphical login and xfce work. o Syslog: Is installed, functional. o Shutdown: Reboot reboots or halts, halt halts. Beta Release Criteria: o Alpha release criteria met? Not quite, see above. o Bugs in beta tracker were not checked today. o All images are under 4G in size when uncompressed. X images are 3800MB. Serial images are 1900MB. o Unaware of virtual console testing. Todo. o Unaware of any audio testing performed. Todo. o Desktop testing was minimal but breadth is incomplete (no web browser). Todo. o Removable media was not automatically mounted (or detected) on at least 1 Trimslice. Todo. o Default update manager testing indicates gnome-packagekit is needed. New X images will include this package. o Desktop reboot/shutdown/suspend untested. Plans for what's next: o jonmasters to track down the OMAP (Panda/Beagle) issue. o bconoboy to regenerate images with OMAP workarounds and other VFAD feedback fixes. o pbrobinson to integrate Versatile Express kernel configuration into official kernel-3.3.x.fc17 tree. o Much more testing (It's happening even now). Thanks to jcapik, pbrobinson, dmarlin, dgilmore, pwhalen, pbrobinson, jskarvad, djdelorie, jonmasters, jsmith, jmontleon, ctyler, maxam, and the rest of the Seneca crew for testing images, providing feedback, and making today a great success. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
On 05/11/2012 04:54 PM, DJ Delorie wrote: I did install and test firefox, it worked fine, including installing add-ons, downloading files, and logging in to FAS. Right- followup question: Is Firefox what we want in the X images? o Desktop reboot/shutdown/suspend untested. I tested this in qemu, it worked. Great! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 17 ARM Beta Release
On 05/23/2012 10:53 PM, rihowa...@gmail.com wrote: http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_Beta I do not see any files listed with kirkwood kernels. What happened to the files that came with kirkwood kernels? We didn't do image testing on kirkwood devices (dreamplug, guruplug) for the final beta spin, so it was not included. We are generating them every night though, so if you'd like to try a *completely untested* Kirkwood image, you'll find one at the following location: http://scotland.proximity.on.ca/arm-nightlies/ -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strategy for packaging an ARM Cortex-M toolchain
On 05/25/2012 12:10 PM, Przemek Klosowski wrote: I recomment to implement 2 separate toolchains with separate packages. Well, maybe that's true in the interest of expediency, but it's hardly an optimal solution. Would it at least be possible to list reasons why binutils have to be different, with the hope that they would be reduced over time, allowing eventual merging of the toolchains? Why have more than one gcc or binutils for arm-eabi at all? Just add multilibs for the extra variants of interest. You can even split the multilibs out into subpackages if it matters. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strategy for packaging an ARM Cortex-M toolchain
On 05/25/2012 08:27 PM, Ralf Corsepius wrote: Why have more than one gcc or binutils for arm-eabi at all? Just add multilibs for the extra variants of interest. You can even split the multilibs out into subpackages if it matters. This is simply not true. A gcc targeting glibc/linux is entirely different from a GCC targetting newlib and entirely different from a GCC targetting another OS. Exactly. There only needs to be one for newlib arm-eabi- it doesn't need to be Cortex-M specific. There only needs to be one for arm-linux-gneabi. Having arm-gp2x-linux is more specific than necessary. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 ARM Release Candidate VFAD results - Follow up VFAD on Monday June 18th
On 06/15/2012 05:25 PM, Paul Whalen wrote: New images for RC2 are being created now! Due to the overwhelming success of today, we are holding another VFAD next week: Fedora 17 - RC2 image validation VFAD Monday June 18th - 12pm EDT #fedora-arm on Freenode If anybody wants to get a jump on Monday's testing the latest nightlies have fixes for all blockers from yesterday's RC1. The images can be retrieved from: http://scotland.proximity.on.ca/arm-nightlies/ Cheers, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 10:18 AM, Adam Williamson wrote: Sorry for the self-reply, but just in case it's not brutally clear yet, I wanted to explicitly state this: [snip] Bravo! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)
On 10/08/2015 08:48 AM, Haïkel wrote: [snip] Please keep in mind, that Fesco is aware this is not a perfect solution, and we''ll gladly review any proposals to improve this policy. But we can keep discussing this for years, or try to solve this issue incrementally. We chose the latter. [snip] Replying to highlight this piece. The passed proposal is an improvement: it opens Fedora to more participants, it better reflects some upstream realities, and best of all it can be further amended. As people have the time and inclination they can and should propose further improvements- Fesco is clearly open to and expecting this, so if you have an idea on how to further improve the bundling policies, please propose it. In this way Fedora gets better and better over time. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)
On 10/08/2015 03:32 PM, Dominik 'Rathann' Mierzejewski wrote: On Friday, 09 October 2015 at 00:14, Brendan Conoboy wrote: On 10/08/2015 08:48 AM, Haïkel wrote: [snip] Please keep in mind, that Fesco is aware this is not a perfect solution, and we''ll gladly review any proposals to improve this policy. But we can keep discussing this for years, or try to solve this issue incrementally. We chose the latter. [snip] Replying to highlight this piece. The passed proposal is an improvement: it opens Fedora to more participants, it better reflects some upstream realities, and best of all it can be further amended. As people have the time and inclination they can and should propose further improvements- Fesco is clearly open to and expecting this, so if you have an idea on how to further improve the bundling policies, please propose it. In this way Fedora gets better and better over time. Forgive me the analogy, but to me it looked like this: Some vocal people don't like this old scary building we have. Let's destroy the building completely, put up a nicely painted shed in its place and hope someone will "improve it". I believe it would've been easier to renovate the old building than to rebuild everything from the ground up. Hey, you sound pretty upset. The analogy on offer is quite extreme, presumably in proportion to how bothered you are, and unfortunately suggests a negative view of the those who proposed/supported the change. Let's try a different analogy: Fedora is the house, the old bundling policy is is a compromised floor board, the new policy is a replacement floor board, but it needs to be sanded and stained. You would prefer this finish work be done before pulling the old board. The carpenter (Fesco) decided to replace the board before finishing. This lets everybody evaluate how much sanding and finishing is necessary to get the new board to match the rest of the floor. It's clear you have specific and reasonable concerns about the new language and it should be very straight forward to propose alterations that Fesco can support. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: no systemd in containers: Requires -> Recommends
On 12/17/2015 01:43 AM, Harald Hoyer wrote: For docker containers, or containers, which don't want systemd, the current "Requires: systemd" in a lot of packages is preventing building a minimal image. To improve the situation, we could make use of the new rpm weak dependencies. So the Requires(post): systemd Requires(preun): systemd Requires(postun): systemd would become Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd With this in place, kickstart files could omit systemd. The downside is: - if systemd is installed afterwards, the %post scripts do not trigger - packages, which need systemd-tmpfiles or systemd-sysusers could not be converted If systemd is removed before the other packages, I don't see a problem. There are only leftovers in /etc/systemd. To prevent having a non-bootable system (not container), we could let the kernel.spec have a Requires on systemd. Comments? Please discuss. I haven't seen a lot of downside brought up in this thread. If the only objections people have is that it doesn't facilitate their personal use cases those don't seem like real objections. Is anybody going to be really negatively impacted by such a change? For my part I'd like to see this happen, not just for packages requiring systemd, but for all packages where "Requires" is really stronger than necessary. Now that we have soft dependencies it would be nice to go through and move to Recommends where software continues to function in some reduced capacity. Everything would still go into the composes as before and for people who like things the way they are, there isn't much downside. Meanwhile, for people who want to trim their package set to the utmost, they would be able to do so without creating fake stub packages or using hacks to get around requires. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: no systemd in containers: Requires -> Recommends
On 12/17/2015 05:27 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Dec 17, 2015 at 04:13:06PM -0800, Brendan Conoboy wrote: On 12/17/2015 01:43 AM, Harald Hoyer wrote: For docker containers, or containers, which don't want systemd, the current "Requires: systemd" in a lot of packages is preventing building a minimal image. To improve the situation, we could make use of the new rpm weak dependencies. So the Requires(post): systemd Requires(preun): systemd Requires(postun): systemd would become Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd With this in place, kickstart files could omit systemd. The downside is: - if systemd is installed afterwards, the %post scripts do not trigger - packages, which need systemd-tmpfiles or systemd-sysusers could not be converted If systemd is removed before the other packages, I don't see a problem. There are only leftovers in /etc/systemd. To prevent having a non-bootable system (not container), we could let the kernel.spec have a Requires on systemd. Comments? Please discuss. I haven't seen a lot of downside brought up in this thread. If the only objections people have is that it doesn't facilitate their personal use cases those don't seem like real objections. Is anybody going to be really negatively impacted by such a change? For my part I'd like to see this happen, not just for packages requiring systemd, but for all packages where "Requires" is really stronger than necessary. Now that we have soft dependencies it would be nice to go through and move to Recommends where software continues to function in some reduced capacity. For some packages "reduced capacity" because of lack of systemd.rpm means "doesn't even get started as expected" or "crashes on start with permission errors" or "cannot write logs" or similar. Like Lennart and Neil said, utilities provided by systemd.rpm are the basis which allows many things to "just work". This is so obvious that it is assumed implicitly in this disussion, and it's hardly "personal use cases". If the software crashes on start with permission error that's not really working in a reduced capacity. There is a degree of subjectivity and arguing every corner case is not useful. The default behavior of dnf is that if a package is recommended and available, it will be installed just like if it were required. The only difference is that if it isn't available an install can still succeed. For those who are curious, Fedora's documentation on weak dependencies is here: https://fedoraproject.org/wiki/Packaging:WeakDependencies -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: no systemd in containers: Requires -> Recommends
On 12/17/2015 04:22 PM, Adam Williamson wrote: On Thu, 2015-12-17 at 16:13 -0800, Brendan Conoboy wrote: On 12/17/2015 01:43 AM, Harald Hoyer wrote: For docker containers, or containers, which don't want systemd, the current "Requires: systemd" in a lot of packages is preventing building a minimal image. To improve the situation, we could make use of the new rpm weak dependencies. So the Requires(post): systemd Requires(preun): systemd Requires(postun): systemd would become Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd With this in place, kickstart files could omit systemd. The downside is: - if systemd is installed afterwards, the %post scripts do not trigger - packages, which need systemd-tmpfiles or systemd-sysusers could not be converted If systemd is removed before the other packages, I don't see a problem. There are only leftovers in /etc/systemd. To prevent having a non-bootable system (not container), we could let the kernel.spec have a Requires on systemd. Comments? Please discuss. I haven't seen a lot of downside brought up in this thread. If the only objections people have is that it doesn't facilitate their personal use cases those don't seem like real objections. Is anybody going to be really negatively impacted by such a change? For my part I'd like to see this happen, not just for packages requiring systemd, but for all packages where "Requires" is really stronger than necessary. Now that we have soft dependencies it would be nice to go through and move to Recommends where software continues to function in some reduced capacity. Everything would still go into the composes as before and for people who like things the way they are, there isn't much downside. Meanwhile, for people who want to trim their package set to the utmost, they would be able to do so without creating fake stub packages or using hacks to get around requires. I'm OK with this *so long as* people don't start using Recommends: for optional and heavy things. As long as we have a strong convention that Recommends: is for things you're almost certainly going to want but aren't technically *required*, and Suggests: is for things that are pretty optional, it should work OK. What would concern me is if we had a mix of packages using Recommends: for nearly-required things and packages using Recommends: for very-optional things, because you'd then be more or less stuck with the very-optional stuff (since if you skipped 'Recommends' universally, you'd miss lots of important stuff from other packages). Totally with you there. We don't want to cut dependencies out at any cost. Rather we want to make packages suitable to a wider audience, useful in more scenarios, without forcing the pulling in superfluous pieces unnecessarily. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: no systemd in containers: Requires -> Recommends
On 12/17/2015 05:46 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Dec 17, 2015 at 05:34:31PM -0800, Brendan Conoboy wrote: On 12/17/2015 05:27 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Dec 17, 2015 at 04:13:06PM -0800, Brendan Conoboy wrote: On 12/17/2015 01:43 AM, Harald Hoyer wrote: For docker containers, or containers, which don't want systemd, the current "Requires: systemd" in a lot of packages is preventing building a minimal image. To improve the situation, we could make use of the new rpm weak dependencies. So the Requires(post): systemd Requires(preun): systemd Requires(postun): systemd would become Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd With this in place, kickstart files could omit systemd. The downside is: - if systemd is installed afterwards, the %post scripts do not trigger - packages, which need systemd-tmpfiles or systemd-sysusers could not be converted If systemd is removed before the other packages, I don't see a problem. There are only leftovers in /etc/systemd. To prevent having a non-bootable system (not container), we could let the kernel.spec have a Requires on systemd. Comments? Please discuss. I haven't seen a lot of downside brought up in this thread. If the only objections people have is that it doesn't facilitate their personal use cases those don't seem like real objections. Is anybody going to be really negatively impacted by such a change? For my part I'd like to see this happen, not just for packages requiring systemd, but for all packages where "Requires" is really stronger than necessary. Now that we have soft dependencies it would be nice to go through and move to Recommends where software continues to function in some reduced capacity. For some packages "reduced capacity" because of lack of systemd.rpm means "doesn't even get started as expected" or "crashes on start with permission errors" or "cannot write logs" or similar. Like Lennart and Neil said, utilities provided by systemd.rpm are the basis which allows many things to "just work". This is so obvious that it is assumed implicitly in this disussion, and it's hardly "personal use cases". If the software crashes on start with permission error that's not really working in a reduced capacity. Exactly. So Required(post/pre/preun):systemd cannot currently be changed to Recommmends, at least in the general case. It's not clear the cases you have in mind are the general case. There is doubtless a happy medium here, though. Perhaps it is opening up the policy to promote Recommends, but leave it to packager discretion. Recommends largely behaves like requires, so it's fairly low risk to err on the side of recommends. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Licensing change: Audacious - GPLv3 --> BSD
On 07/10/2012 11:05 AM, Michael Schwendt wrote: On Tue, 10 Jul 2012 13:19:09 -0400, Seth Johnson wrote: Copyright is automatic under Berne. Which only means that you don't need to apply for copyright at any government office. But copyright on _what_? What comprises a "copyright work"? Single words? Single lines of code? Trivial/obvious code fragments some other person who have added at some other point of time? Or more original work only? That's a great question. people who contribute code to a GPL'd project (or any project) automatically have a copyright claim, And we still don't know what has been contributed, if at all. And what licensing terms were applied to the file the person contributed to. The project this thread refers to has used different licenses for a long time already. Hey Audacious developers, here's a patch for a missing "return 1;" in libaudcore, and now that you've seen my patch, if you merge that line of code, I claim my rights. Yep, good example. What is the threshold? There is only 1 person who can answer that authoritatively: The judge who ends up presiding over the court case where it's formally asked. Everything else is opinion. Some of it informed: attorneys, some of it educated guessing (devoted groklaw readers), some of it blindingly ignorant. Wherever each member of de...@l.fpo falls on that spectrum, the odds are they shouldn't be giving legal advice because there's only 1 judge and none of us are they. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 10/30/2012 02:58 PM, David Airlie wrote: Should we just skip F18? (like seriously). Seems a little over the top. Why not use the extra time to squash other bugs, making F18 a better release overall? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 08:47 AM, Till Maas wrote: IMHO it is also not that easy to get something going with ARM on Fedora. For example I bought a Sheeva-ARM devices to get upstream release monitoring running on it . But even when I got it installed, the device crashed with a kernel soft lockup. BZ#? > Now the devices are no longer supported. I got a RPi (from the hardware summer of fun) with the same intent, but until today it is not properly supported and won't. Never been supported by Fedora ARM for lack of upstream kernel and firmware license issues. It's a Seneca College remix, but AFAIK it works great: http://pidora.ca/ > In the meantime I bought a Cubieboard, no luck here as well. Since the Cubieboard remix even requires HDMI output and does not work headless, I did not try it because if missing HDMI hardware. Never been supported by Fedora ARM for lack of upstream kernel. That might change in the next release as the upstream is coming along. > Also all the Fedora ARM efforts usually require to dd some images instead of just allowing to run a textmode anaconda via serial or some other installer, which just feels quirky. F19 on ARM supports interactive anaconda installs over serial. Or vnc installs if you want graphics. Or kickstart installs if you want automation. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 07:33 AM, Matthew Garrett wrote: Promotion is supposed to benefit Fedora, not the architecture being promoted. And you think it would not benefit Fedora. So promoting ARM comes at a cost to every individual package maintainer, who now has to do additional work. Do you really think individual package maintainers haven't been involved to date? It's flattering to think that our relatively small crew has somehow been able to manage every issue that's come up with all 13500+ packages, but the truth is that package maintainers are good people who already handle many of the ARM issues that come up as source churns. The main difference is workflow change. Today: ARM builds are queued by koji-shadow some period of time after they complete successfully on primary. If a build fails then the koji-shadow admin gets notified. If it's a real bug it gets BZed, we work with the package maintainer, the bug is fixed, and we move on. As primary: ARM builds would be queued at the same time as x86. If a build fails the package maintainer gets notified. If it's an ARM-specific bug the maintainer would get in touch with the ARM team. The full details of this change are TBD and should be discussed. I agree that that's the ideal case. If package maintainers are willing to volunteer their time to ensure their packages work on ARM then everything is easier and we all benefit. That doesn't seem to be the case yet. Oh? What I'm saying is that making ARM a primary architecture isn't going to automatically make volunteers start caring about ARM, and so there should be evidence that the existing ARM porters can deal with the worst case scenario of supporting an arbitrary set of packages themselves. Perhaps it's inevitable, but I would like to avoid a reprisal of the Richard Dawkins & Wendy Wright debate. What evidence are you asking for? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 08:34 AM, Matthew Garrett wrote: That's why I'd like to see all of these things fixed *before* promotion. Yes, you've been very consistent, it can be summarized in 3 points: 1. Provide a list of every ARM deficiency. 2. Provide a fix for everything listed in 1. 3. After #1 and #2 are complete, we can talk about what else is needed. I would say you're setting the bar too high, but it has passed the event horizon so evidence of its supposed existence is hard to come by. If this is not what you mean to be conveying please demonstrate otherwise. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 03:55 AM, Josh Boyer wrote: I will note that it is not x86 alone. If one is simply going by "as close to the current Fedora experience the current Primary offers", then the PowerPC secondary arch team is actually ahead of ARM. I'm not saying they are a better candidate, but I am pointing out that the criteria Matthew is alluding to is being met by non-x86 architectures. I'm not up-to-date on the current condition of Power: Are you specifically referring to GNOME & KDE? If so I'd posit that this is because GNOME & KDE make a lot more sense on Power than they do on ARM. Developer energy goes where it's needed & wanted. Prior to this discussion nobody was lamenting the state of gnome on their low power ARM system. We're still building them of course- all the GNOME and KDE packages are built, they're just not getting used AFAIK. I don't believe that is true. ARM is useful, I want it to be a Primary arch, but I fail to see how your middle ground below of having it be primary in the build system is going to somehow grow Fedora. I believe there are concerns that it will place additional burden on package maintainers (like ppc did before there was a real arch team for it), and that those concerns are valid. Are those concerns valid? By what measure? Can they be controverted by evidence? Thus far we have pro and con anecdotes. And yet did not include any of that information in your proposal. I believe build times have improved. I also believe that you should show it in the proposal so that it is clear you are addressing prior concerns. I'm appreciate the effort spent to speed up the kernel build times, but the concern is global. Show the work done in the proposal with some simple numbers. These are good suggestions- thanks for that. Again, I would like to see ARM as Primary and I believe the ARM team has done a rather good job. Promoting anything to Primary has never been done before, so bear with us as we work through it. Absolutely. Change is hard, but if all goes well this one will be popular in hindsight :-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 04:11 AM, Josh Boyer wrote: To expand on this a bit, how do you believe that merging ARM into the build system is going to encourage growth in Fedora? What will it buy you that you don't already have? At first glance, it gets you slightly more timely builds. However, you've already proven that timely builds isn't an issue at all by having ARM releases ready the same day as primary. So please, elaborate on that in the proposal. You have a lot of what you want listed, but not why. Speaking just for the build system change, I see these benefits (There may be others, I don't run the build system): 1. Running koji-shadow is often a full-time job. The person doing the job could be working on ARM issues directly instead of being a build nanny. 2. Koji-shadow can introduce SA rpms who have a different NVR dependencies than PA. There are numerous koji-shadow issues, really. 3. Build failures on ARM aren't always ARM specific- it can serve as a notice of problems present but not yet observed on other architectures, perhaps hidden by accidental alignment, etc. 4. Failures like those in #4 benefit all secondaries, not just ARM. Solve it in PA, or we end up solving it once in ARM, once in Power, once in s390... it's a lot of wasted, redundant effort. 5. Primary packagers are already fixing ARM build failures, they're just doing it a day or a week later. They don't know there is an issue until we tell them. We're talking about cutting out the middle man. 6. It simplifies releng and infrastructure in that there is one less secondary to handle, one less koji server to maintain, one less set of firewall exceptions to honor, and whatever else goes into maintaining the distinction. etc. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 05:08 AM, Josh Boyer wrote: In terms of Fedora experience. You install it graphically via Anaconda. You wind up with Gnome (or LXDE or XFCE) and can run it. Yum works. Security features are implemented and working. Etc. These are the things Matthew is alluding to. In theory you can install graphically today. We tested graphical installs via vnc (Not having a framebuffer puts a crimp in the matter). You wind up with LXDE or XFCE, etc, and you can run it. Yum works. Security features are implemented and working- except evidently pointer guards, which we found out about *yesterday*. What I'm looking for is supporting data on prior concerns and what both the ARM team and the Fedora project gain from making ARM primary. Again, the proposal is lacking in the why area. "You get ARM!" isn't cutting it because you've all done such a good job that Fedora already has ARM on the same day as x86 and PowerPC. Fair enough! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 08:46 AM, Till Maas wrote: On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote: And following the legitimate concerns about stack-protector this was raised by ARM into core Linaro as an urgent action for which engineering resource is being assigned to correct this deficiency ASAP. Thus within a day an issue has been noted that we were unaware of and is being worked through a process to correct it, as would be the case with any deficiency on x86. The stack protection stuff will be fixed. Let's bike shed over the next nitpick nuance that the anti-ARM crowd want to throw in the way ;) Was the flag ignored previously or why was this missing feature not announced? Please see: https://lists.fedoraproject.org/pipermail/devel/2013-July/185106.html Per Carlos's email, the flag is not ignored, the feature is there, but it isn't as fully featured. Specifically stack guards are present but pointer guards are not. This was news to all of us. It's disappointing that the issue was not brought to the ARM team's attention prior to the F20 promotion discussion being introduced. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 11:22 AM, Peter Jones wrote: The point of this isn't just that it was broken, though - the concern here is that the test suite said it was not working. What else isn't working because nobody has even looked? What's worrisome here is not merely that a major security feature wasn't working. While that is troubling, the fact of the matter is that people *not* on your team thought it wasn't working, and assumed that you knew. The test suite is giving failing results. That's not usually an indicator of high quality or success. Yes, this is a serious issue for any architecture. It's more of a people problem than technical though. We can solve it for gcc on ARM specifically, but as a general case I don't have an easy answer. The worry isn't that there's one thing here or there that doesn't work - the worry is that there are relatively major Fedora features that we've advertised in big letters in the relatively recent past that simply don't work because nobody has paid any attention to whether or not they work. Hmm. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 10:41 AM, Bill Nottingham wrote: Kernel, glibc, all the core library stacks. And I would argue that yes, this *includes* libGL. So llvmpipe needs fixed, outside of any desktops. Should we define the core functionality better? Probably. I would argue that it does not include libGL because it's not a requirement for headless deployment scenarios. Why would you argue for it? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 11:49 AM, Jakub Jelinek wrote: Stack guards are present, but using libssp, which is the fallback way, second class citizen and most likely slower than the standard way. E.g. the libssp stack guard setup always uses /dev/urandom, while I guess even on ARM kernel provides AT_RANDOM that can be just used. And I'd bet that even on ARM reading the stack guard via TLS (well, static only always, i.e. hardcoded offset from TLS register), especially for PIC, is faster than doing GOT read and two memory references. Thanks. Security-wise, is the implementation roughly equivalent in what is protected against, albeit less efficient? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 11:38 AM, Till Maas wrote: https://bugzilla.redhat.com/show_bug.cgi?id=865022 It is currently closed, because I did not re-test anymore after it was announced that the device won't be supported anymore soon. Thanks. Since the last update we have added a dedicated ARM kernel maintainer. Fedora 18 on armv5tel is still supported. If you would like to pursue the issue further we will assist. Never been supported by Fedora ARM for lack of upstream kernel and firmware license issues. It's a Seneca College remix, but AFAIK it works great: http://pidora.ca/ Yes, but this is probably also a reason why there was little Fedora related outcome from the Hardware summer of fun. Not sure I follow. Before Pidora Seneca still supported the Pi on armv5tel, as early as F13. This sounds promising. Are there remix-anaconda images that can be used to test this on a Cubieboard? I'm not aware of the current remix situation on F19- Perhaps Hans will comment? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 12:37 PM, Bill Nottingham wrote: Well, as I said (and you cut out) ... I do know what some people want ARM to be in terms of dense hypserscale servers (32/64-bit)... but the community that would be using Fedora ARM does seem to be targeting a wider array than that. ... The F19 ARM release released 5 desktop images. You seem to be arguing that the required featureset of ARM as a primary arch should only be for headless deployment, but the ARM community itself is saying otherwise. Interests differ between participants. If this was the only objection to moving ARM to the primary build system I would say let's drop graphics from official Fedora ARM support for the purposes of the move and make all graphical images respins or remixes. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/11/2013 07:07 PM, Frank Ch. Eigler wrote: Adam Williamson writes: [...] "Primary Architectures : These are architectures with the majority of the users, the most common architectures. [...] By that standard, PA treatment of ARM seems way premature. Or does it mean x86 as PA is out of line? There are a lot more people with ARM devices than x86. Sorry everybody, we're going to have to demote x86. ;-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 04:13 AM, Christopher Meng wrote: Agree, I have 2 Arndale now, its performance can beats any other v7 devices. But. I'm not sure if A15 can be fully supported. Currently I only see many A9 hardwares. Some requisite patches weren't upstream in time for Fedora 19's 3.9 GA kernel, but are in the 3.10 update. This means Arndale should be fully supportable in Fedora 20. Meanwhile, there is an F19 remix for Arndale using a later kernel: http://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes Kudos to Jon Disnard for putting this together. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 10:15 AM, Chris Tyler wrote: I think that's s/Arndale/Chromebook/ Same SoC, different peripherals sticking out. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 11:09 AM, Bill Nottingham wrote: If I'm understanding you, you would prefer that ARM be blessed with the stamp of being a 'primary' arch at the cost of dropping release targets, images, and featuresets that are made by and for the community now. I wouldn't put it like that. The ARM team isn't asking for a blessing, we're asking to have builds that block ARM also block x86. At a technical level, that is a fundamental part of what being primary is. Yes, there are other aspects, both practical (what is released) and philosophical (What is Fedora). It's the next logical step. If not now, when? When libGL is ready to go? I don't think I can support that - it seems awfully unfriendly to the community that exists now. You are proceeding from a misconception: This is a thought exercise- If ARM devices didn't have graphics would it still be essential for PA promotion that libGL for ARM work and be accelerated? There is no proposal to throw out the baby or the bathwater. This is about defining the threshold at which point armv7hl gets built along side i686 and x86_64. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
