Re: F20 System Wide Change: No Default Syslog
On Jul 15, 2013, at 5:11, Miroslav Suchý msu...@redhat.com wrote: On 07/15/2013 10:44 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: No Default Syslog = https://fedoraproject.org/wiki/Changes/NoDefaultSyslog Change owner(s): Lennart Poettering lennart at poettering net, Matthew Miller mattdm at fedoraproject org No longer install a traditional syslog service by default. (Specifically, remove rsyslog from the @core or @standard groups in comps.) The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, and even traditional sysklogd will continue to cover use cases outside of the default. My voice may be one of thousands, but I'm saying: I want to have traditional syslog service as default and have journal from systemd as option. I concur. I have systems that live in a heterogeneous environment and need traditional syslog. By making it optional, it will ultimately die, forcing journal as the only viable option in a Fedora environment. This is IMO not net beneficial for downstream use cases later on either. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
The stack-protector issue has been raised to priority number one for the library folks within the Linaro toolchain group. I have followed up with members of the toolchain and steering committees as appropriate to ensure this is going to be taken care of extremely swiftly. Next! -- Sent from my iPad On Jul 12, 2013, at 5:36, Jonathan Masters j...@redhat.com wrote: Note that there are teams within Linaro doing benchmarking and driving such. And once the specific stack protector issue was raised, I poked Marcus in person and he escalated it such that it will be looked at this next engineering cycle. In general we can plan ahead if we know there are issues. We can't offer a 4 hour SLA. This isn't meant to be aimed at Jakub :) just replying here. Btw, on a tangent, those throwing stones in the other subthreads need to bear in mind no architecture can guarantee every feature at all times. If you would like, we can scrub through and find something broken on x86 that a test suite claims to work, and we can infer all kinds of insulting things from that. But it will achieve nothing. Sometimes stuff just is unintentionally broken. Audit was one such issue a year back - silent register corruption due to a busted patch and lack of people historically using it to notice. But we fixed that. And we will find more issues over time and fix those, especially now that we have many folks running Fedora kernels and others in Linaro ramping up on testing upstream with non-embedded configs. Jon. -- Sent from my iPad On Jul 11, 2013, at 20:03, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote: 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? Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise, but most probably it is just less efficient. Definitely something to be benchmarked, analyzed for code size etc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Thanks Brendan. My Fedora doesn't even use a GNOME desktop. I've happily used XFCE for years. And I make no secret that I care about servers more than desktops (you know, that part of the market where general purpose Linux has a huge footprint and stands a chance). I would hate to look back in five years and say yea, Hyperscale ARM servers took over and Red Hat was totally there, but Fedora missed the boat entirely. Move with the times. Fedora wants to embrace the new and revolutionary? ARM is powering some very exciting disruption and Fedora should not be sitting on the sidelines naval gazing and pining for the declining desktop of yesteryear. -- Sent from my iPad On Jul 11, 2013, at 7:05, Brendan Conoboy b...@redhat.com wrote: On 07/10/2013 09:13 PM, Matthew Garrett wrote: Fedora is an operating system that supports a range of desktop environments, defaulting to the GNOME desktop environment. An OS that supports headless servers but not desktop environments might be based on Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to being a Fedora PA. It is becoming increasingly difficult to distinguish whether to read these messages as high standards or hyperbole. Maybe your Fedora means desktop OS, but my Fedora has more facets than that. Fedora Primary is not some Platonic Form embodied by x86; that would be better described as Fedora Fantasy. The all or nothing element in the above simply serves to discourage further contribution and is harming Fedora's growth. The relentless I don't want ARM to sully the good name of Fedora is absurd: User for user, ARM is considerably more popular than Fedora. Is your definition of Primary a sacred idea that is responsible for Fedora's success? If held dear for too long it will be the well known idea responsible for its failure. Please consider the idea that there is a useful middle ground Primary and Secondary. Primary Release/Primary Build system | Primary Build system/Secondary Release | Secondary Build system/Secondary Release It might be multidimensional: Primary Desktop---Secondary Desktop | | Primary ServerSecondary Server 15 months ago: There were concerns about reliability- we moved to enterprise hardware in PHX. There were concerns about build times, particularly that of the kernel: We bought the fastest hardware available, moved to a unified kernel architecture and sped up builds many-fold. There were concerns about kernel and toolchain maintainship: We hired and/or tasked kernel, glibc, gcc, and other engineers. There were concerns about releases being held up: We released F19 Beta and GA on the same day as x86. There were concerns about releng: Releng wrote the new promotion proposal. There were concerns about QARelease criteria: We copied most of Primary's procedures. There were concerns about the installer: We're using anaconda and standard image creation tooling. There were concerns about desktop users: All supported platforms that have graphical hardware have a desktop. The list goes on and on. For any of the above a person can be small and pick out tiny details where they aren't satisfied, but if you're one of the people who is going to do that, please say the following: I object to armv7hl moving to primary because of $DEFECT, but if $DEFECT is remedied by $MILESTONE, I will then support the move of armv7hl to primary. You define $DEFECT and $MILESTONE and we can have a productive discussion. At this time I think it is quite reasonable to ask for the build systems to be merged. Whether you call it Primary, Secondary, or some new middle-of-the-ground word, it's progress. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
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 ;) -- Sent from my iPad On Jul 11, 2013, at 12:14, Peter Robinson pbrobin...@gmail.com wrote: On Thu, Jul 11, 2013 at 6:15 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Jul 11, 2013 at 12:43:36AM -0400, DJ Delorie wrote: Stack protector is not a new requirement in Fedora. It's been part of the distribution for years. xterm has been part of the distribution for years also, but it's not a release requirement. The assumption has always been that all primary architectures embody the same level of functionality, with the exception of fundamental differences between the architectures. If things that are currently supported by the primary architectures cease to be supported by the primary architectures, that's a strong argument that they're not fundamental to Fedora. For example, in the absence of hardware nx support, I wouldn't argue that ARM should be forced to implement execshield - both because it's fundamentally tied to 32-bit x86, and because we've given up on supporting it. But yes, if ARM wanted to ship without xterm while the other primary architectures supported it, I'd say that that would be a blocker for shipping ARM as a primary architecture. I think assumption is part of the problem here, you're assuming something that is different to the assumption of others but as it's not documented anywhere it means that neither opinion is neither right nor wrong. I think what's been missed here is that the secondary architecture promotion guidelines were intended to be an addition to common sense rather than a replacement for it. They didn't seek to be an exhaustive list of things that had to be present for something to be a PA - they were an attempt to shape out the grey areas. A primary architecture should include everything that one could reasonable expect to be present in Fedora, which includes security features. And I agree that common sense is required here, we're not arguing that security features should be ignored and we weren't ignoring them, we made an assumption that because the kernel, the compiler options were there that so was the glibc rather than a boiler plate code that made all of the rest of the components essentially useless. As for the common sense about the desktop I don't necessarily agree that while the gnome desktop is the default that it's an explicit requirement. There's 4 million XOs shipping Fedora (both x86 and ARM) that don't ship with gnome3 as well as no doubt millions of instances of cloud images that don't have a requirement of a desktop yet we still call them Fedora... Fedora with a requirement for a desktop or a single desktop option I think is a thing of the past and while I would like to support it I don't believe it's common sense to have it as a blocker. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Note that there are teams within Linaro doing benchmarking and driving such. And once the specific stack protector issue was raised, I poked Marcus in person and he escalated it such that it will be looked at this next engineering cycle. In general we can plan ahead if we know there are issues. We can't offer a 4 hour SLA. This isn't meant to be aimed at Jakub :) just replying here. Btw, on a tangent, those throwing stones in the other subthreads need to bear in mind no architecture can guarantee every feature at all times. If you would like, we can scrub through and find something broken on x86 that a test suite claims to work, and we can infer all kinds of insulting things from that. But it will achieve nothing. Sometimes stuff just is unintentionally broken. Audit was one such issue a year back - silent register corruption due to a busted patch and lack of people historically using it to notice. But we fixed that. And we will find more issues over time and fix those, especially now that we have many folks running Fedora kernels and others in Linaro ramping up on testing upstream with non-embedded configs. Jon. -- Sent from my iPad On Jul 11, 2013, at 20:03, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote: 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? Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise, but most probably it is just less efficient. Definitely something to be benchmarked, analyzed for code size etc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Jul 12, 2013, at 5:32, Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Jul 11, 2013 at 11:58:08PM -0400, Matthew Miller wrote: On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote: 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. ;-) False marketing. Majority of ARM devices out there don't run Fedora and never will. Sooner or later, though, we probably _should_ deemphasize 32-bit x86. The website already links to 64-bit in preference to 32-bit. There's arguably reasons to prefer 32-bit in certain memory-constrained environments, but there's certainly arguments in favour of (say) dropping most of the 32-bit x86 package set and turning it into a specialised subset of the overall distribution. Heck, if you're doing that, go x32 for those small set of libraries and force folks to build against those :) We'll have a similar API on AArch64 in due course and I wouldn't want to see a Primary Architecture missing feature parity with secondaries... :P -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
That option simply preserves the global stack canary value between tasks during context switch. It's not really core to this. The core piece is userspace compiler tooling. I know the option exists and I thought/was lead to believe it works. But if Jakub has concerns I will add that to the feedback I have already raised with ARM/Linaro here in Dublin this evening. But also guys, come on. We can't be having random new requirements being added in a bike shedding exercise with the first this being raised happening now. If there are issues then they can be prioritized and worked on, but we'll never get anywhere if things are raised in this manner. As I see it, ARM is the most popular architecture on Earth, is damn well supported in Fedora, and we do the Fedora community a disservice by not bringing the 4 F's into this and thinking about the broader context. So, I'll/we'll come back with more data on the stack protector implementation and what we can do about llvmpipe, but meanwhile please give us useful guidance on what you actually want for ARM to be a PA. Not hand wavy it must be feature parity with x86. I can think of plenty of terrible things x86 does that I would never want to see ARM attempt to match. Jon. -- Sent from my iPad On Jul 10, 2013, at 19:40, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote: armv7 has stack protector, aarch64 which is outside of this proposal doesnt yet have it. Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro really have full stack protector support, while perhaps -fstack-protector doesn't error out on armv7, it certainly isn't supported in glibc (neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about arm having security standards high enough for being a primary architecture. So what does the kernel level CC_STACKPROTECTOR config option bring to this as it appears to be associated with the -fstack-protector option as well (according to it's Kconfig description) but is only supported on x86/arm from that list above (plus sh). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Excellent proposal. I of course think this would be just awesome! -- Sent from my iPad On Jul 9, 2013, at 15:37, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: ARM as primary Architecture = https://fedoraproject.org/wiki/Changes/ARM_as_Primary Change owner(s): Dennis Gilmore den...@ausil.us, Peter Robinson pbrobin...@gmail.com Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit). == Detailed description == The Changing IT landscape has started to focus on greener technologies as well as cheaper mass produced devices that allow for fully functional cheap devices for lower socio-economic areas and other markets like education and makers. ARM SoCs have traditionally been the domain of embedded and mobile applications but are now finding their way into more traditional computing devices like desktop, notebook and server markets. Fedora ARM currently works on many different devices with wider support coming with each new mainline kernel release. For this change we will enable armv7hl builds on primary koji, and compose arm trees as with the other primary architectures. Fedora has in the Phoenix data centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will remain allocated to the arm secondary architecture koji instance for building updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of life the ARMv5 softfp nodes will able to be be reallocated to other tasks. Infrastructure has expressed an interest in testing and experimenting with some of its workloads on ARM, some are allocated to QA and some for releng. There is currently 24 nodes configured in primary koji ready to go as builders, there is the capacity to add up to 24 more when ARM becomes primary if desired. The kernel is now a multi platform unified ARMv7 kernel supporting a number of SoCs with support expanding with each new upstream release. We build a base and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64) kernel maintainer working in collaboration with the Fedora kernel team. The releases are composed using the exact same tooling as used for the primary architectures. Disk images for development boards are generated by appliance- creator and the kickstarts live in spin-kickstarts, they take a similar format as the livecds on primary but are shipped as an OEM disk image, and like primary initial-setup is used to do final user configuration. Like primary pungi is used to generate an install tree, PXE install trees are created but current bootloaders don't support isofs so ISO images aren't currently created. == Scope == Add armv7hl to list of arches for f20-build and future build tags in koji compose armhfp trees with i386 and x86_64. Requisite build hardware already exists in phx2 and is configured to work with mainline koji. Proposal owners: change the arches in koji, import the matching ARMv7 rawhide builds into koji. Update Release Engineering scripts to automatically build armhfp trees along with i686 and x86_64. Other developers: submit builds as normal, in the event of unexpected build failures liaise with the ARM Team to help debug and fix issues. Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are part of the team of people proposing the Change. Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Matthew, We'll be looking into LLVM in due course. There are a few of us capable of fixing the issue (that you were noted as being extremely concerned about on IRC at the time - we will be happy to send you updates on this) but we balance this with other priorities (as well as a desire not to grow a dependency on LLVM more broadly - Fedora relies heavily upon the expertise of RH's tools team, which focuses on GCC almost exclusively precisely to avoid fragmenting the resources that do exist to develop awesome new tooling). Right now, many desktops work just fine, and there is no reason ARM cannot be a a Primary Architecture because of a temporary bug in llvmpipe (or otherwise we can revive this thread for you next time it breaks on the other architecture and see if it should be demoted accordingly?). If there is a rule saying PA needs GNOME then this can easily be adjusted to reflect the fact that many are running Fedora on ARM today happily with a variety of other desktop environments. Jon. -- Sent from my iPad On Jul 9, 2013, at 18:57, Matthew Garrett mj...@srcf.ucam.org wrote: llvmpipe has been known to be broken for months, and nobody on the ARM team appears capable of fixing it. As a result, ARM shipped in F19 without any out of the box support for running our default desktop. This doesn't make it seem like the ARM port currently has sufficient developer expertise involved, and I'd really like to hear what the plans are for (a) fixing the existing problems, and (b) ensuring that we don't end up in a situation where other architectures are held up because there's nobody who can fix ARM-specific bugs. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
Indeed. This was a concern I raised when we first began the bootstrap. Blindly
rerunning autoreconf in every case is a really bad idea. But doing it in a
discretionary way, allowing the package maintainer to influence what happens
(they in theory know whether this will work for their package and their
upstream) is good.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: Ben Boeckel [maths...@gmail.com]
Received: Thursday, 20 Jun 2013, 7:53
To: devel@lists.fedoraproject.org
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not
support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
One problem with that is, one cannot blindly run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make minor changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving back to editing the .in and .ac files
directly.
--Ben
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
Hi Jaroslav, I would like to raise a caution about implementing this change. Several other non-Linux systems are able to handle a variety of hardware changes after installation, and still boot afterwards. I think it would be unfortunate if, after changing hardware, it were not possible to boot other than with a rescue image. Hardware is becoming faster, and even on our small ARM boards, initramfs size is not such a huge problem, especially in the medium term. Jon. -- Sent from my iPad On Jan 29, 2013, at 10:00, Jaroslav Reznik jrez...@redhat.com wrote: = Features/DracutHostOnly = https://fedoraproject.org/wiki/Features/DracutHostOnly Feature owner(s): Harald Hoyer har...@redhat.com Only create host-only initramfs images. A generic fallback image should be installed by anaconda on installation/update and never ever be removed. == Detailed description == Current initramfs images contain most of the kernel drivers to boot from any hardware. This results in a very big initramfs, which takes a long time to load on system start and a long time to create on kernel updates. Switching to host-only will improve the situation. To cope with hardware change, a boot entry Rescue System should be installed with a full fledged initramfs also containing debug tools. This boot entry can then be used to recover from hardware changes and also from unforseen software failure after updates. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FUDCon ARM related followup
Hi everyone, Thank you very much to those who attended FUDCon in Lawrence, KS this past weekend, in person, online via the streams, on IRC, or otherwise. It was great to see everyone. We in the ARM team had a great time (at least, I know I did) and I was pleased to see more mainstream Fedora discussion around ARM. We had reps from QE, virt, infra, and other awesome folks who wanted to get more involved, and this was great to see. I hope by the time we have the next FUDCon we will be even further along the path toward being fully integrated into primary. We had a number of conversations about how to involve more people in Fedora on ARM. We also had many other conversations that are being minuted on the wiki, with more notes and links to follow. Now is a great time to join arm@ and add your input. Thanks very much, Jon. -- Sent from my iPad -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: [fedora-arm] Fedora ARM Roadmap from this morning's hackfest discussion
Forwarding for the broader audience. Note that this is subject to further discussion. Please feel welcomed to join and participate in arm@ with regard to this, and the many other pieces related to FUDCon. Additionally, thank you very much to everyone who attended (physically, virtually, or in spirit) and made this a wonderful weekend that I enjoyed very much. -- Sent from 30,000ft Begin forwarded message: From: Brendan Conoboy b...@redhat.com Date: January 19, 2013, 16:30:51 CST To: arm a...@lists.fedoraproject.org Subject: [fedora-arm] Fedora ARM Roadmap from this morning's hackfest discussion During this morning's hackfest we discussed and agreed to a tentative road-map for armv5, v6, v7, and v8. Part of this is in the context of moving build infrastucture to the PHX colocation facility. Part of this is in the context of pushing ARM to Primary architecture status. The following is a summary of what we agreed to: Any release we do as part of Fedora ARM will be supported according to PA life cycle (IE, end of life between PA and SA ARM release will be the same day). Any release we do as a secondary architecture will continue to be supported by the secondary architecture koji instance, even if later releases are done as a primary architecture. For example, F18-ARM will always be secondary because it was built on the secondary koji hub. In a couple weeks' time we will have 96 Calxeda Highbank servers in PHX. There is already a new koji hub and database in PHX ready to take over. Once the ARM systems are running smoothly we will migrate armv5tel and armv7hl builds to these machines. Dennis Gilmore will take the lead in migrating koji to the new systems. Here is the plan on an architecture-by-architecture basis: armv5: F19 will be the last release we build on armv5tel. We will continue to support F19 armv5tel throughout the supported lifecycle of F19. This means packages in f19-testing, f19-updates, etc will continue until they're shut down in prmiary. armv6: Seneca will continue their development of armv6hl on the hardware at Seneca college. The systems currently working on armv5tel and armvhl will be redirected to this effort once those architectures are migrated to PHX- allowing them to make faster progress. armv7: The goal is to push armv7hl as a primary architecture in the Fedora 20 or 21 timeframe. Once accepted some of the builders in PHX will be moved to the primary network infrastructure, but a sufficient number will be left as secondary builders to continue support for F19 and earlier throughout their lifecycles. armv8: The aarch64 bootstrap effort continues to progress and is now at the early portion of stage 3: Rebuilding packages natively with rpmbuild. To follow will be a prolonged stage 4 in which most packages are built with mock. When we bootstrapped armv7hl stage 4 was a significant group effort and will hopefully be so again. It is likely we will reach stage stage 4 before v8 hardware is generally available, so every person's assistance will be especially welcome. The hope is to have v8 support in koji as a secondary architecture shortly after hardware becomes available. Our educated guess is that we will be somewhere between F20 and F21 development when v8 is ready to be guided by koji as an official secondary architecture. That's it! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list a...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Hi Lennart, I would like to remove finger from the list. It is still very much in use. I use it many times daily. I realize my use case is multiuser and server systems - not of interest to Fedora - but the overhead is little, so I would be grateful if it remained. Jon. -- Sent from my iPad On Jan 10, 2013, at 10:07, Lennart Poettering mzerq...@0pointer.de wrote: Heya, I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. I'd like to propose that maybe it is time to remove these from standard for F19. Note sure how to proceed on that. Propose a feature? File a bug? Is there even a comps maintainer? (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM F18 Beta VFAD - Test Images posted
Hey Lukas, I think the other (well meaning) responses haven't yet addressed your original question. For the record, for ARM development boards, we (Fedora ARM) ship prebuilt disk images suitable and intended for dd'ing onto a storage card for convenient installation. Other targets support conventional installation[0], such as on Calxeda HighBank (known as EnergyCore), and the emulation target comes as a rootfs and kernel. If you need a specific kernel binary for one of these images, you can extract it as Brendan mentioned, or you can use arm.koji.fedoraproject.org to download any package, or the the regular mirrors. If you have questions, please join a...@list.fedoraproject.org or #fedora-arm on Freenode IRC. Regards, Jon. [0] Someone will feel the need to point out that you could run Anaconda on a Trimslice, or on a PandaBoard unless I add this footnote to say I am deliberately ignoring that uncommon use case in the general Fedora user base of ARM today. -- Sent from my iPad On Jan 4, 2013, at 10:01, Lukas Zapletal lzap+...@redhat.com wrote: Pardon my ignorance, but where can I find the kernel images? These are just root systems, right? I'd love to try Kirkwood on NSA-310. Thanks! LZ On Mon, Dec 03, 2012 at 12:57:19PM -0500, Paul Whalen wrote: Please join us today (December 3rd, 2012) in #fedora-arm on Freenode for another Fedora ARM VFAD. There are a number of pre-created F18 ARM Beta TC1 images available for testing, including: Pandaboard, Trimslice, vexpress (QEMU) and Kirkwood. Images can be downloaded from: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc1/ Please help us track the results by adding your findings to: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-12-03-VFAD-Fedora_18_Beta All help is appreciated and we look forward to your participation. Thanks, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Later, Lukas lzap Zapletal #katello #systemengine -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: FYI: Debian multiarch project
I brought this up previously in the context of the Fedora ARM bootstrap. It will be one of topics in the writeup. -- Sent from my phone - message formatted and/or shortened accordingly. -Original Message- From: Richard W.M. Jones [rjo...@redhat.com] Received: Wednesday, 20 Jul 2011, 8:35 To: devel@lists.fedoraproject.org Subject: FYI: Debian multiarch project Latest from the shores of Debian: http://wiki.debian.org/Multiarch/ The reason I noticed this is when I updated my Debian builder to the latest unstable, and noticed that most libraries have moved from /lib to /lib/x86_64-linux-gnu/ (including libc and ld-linux!) and similarly for /usr/lib - /usr/lib/arch-triple/ I'm actually considering reinstalling that machine ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
