Re: Announcing: Fedora ARM Technical Talks
On 02/15/2013 02:32 PM, Jon Masters wrote: Please see the following link for further details: https://fedoraproject.org/wiki/Architectures/ARM/Talks/ARMTechTalks Today's talk is on debugging vexpress (Versatile Express) kernels running under qemu models with gdb. It will simply cover setting up a system for tracing a kernel with gdb and is introductory in nature. I will host another Fedora ARM technical talk this afternoon. This will be my second, and so I am taking the opportunity to formalize this into a series of technical talks. Each 1-2 weeks I will host a deep dive technical session, on kernel debugging, atomic operations, and covering gnarly issues that I have helped track down (e.g. systemd-logind issue). This is not limited to me - drop me a line if you would like to give a talk, or would like to help organize this series :) Minutes from today's ARM Tech Talk hosted by me: HTML: http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.html Text: http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.txt Raw: http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.log.html Tune in next Friday at 20:00 UTC, when John Dulaney will tell us all about installing Fedora onto the Samsung ARM-powered Chromebook! Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] FUDCon ARM related followup
Always was done with yaboot. Do we know if OLPC will move to UEFI? -- Sent from my phone. Please excuse formatting and brevity. Peter Robinson pbrobin...@gmail.com wrote: - Original Message - From: Peter Robinson pbrobin...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: a...@lists.fedoraproject.org Sent: Monday, January 21, 2013 6:28 PM Subject: Re: [fedora-arm] FUDCon ARM related followup On Mon, Jan 21, 2013 at 1:57 PM, Bruno Wolff III br...@wolff.to wrote: On Sun, Jan 20, 2013 at 23:56:49 -0500, Jonathan Masters j...@redhat.com wrote: 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. Since a number of Fedora developers where given XO 1.75s last summer, getting Fedora builds for those people might be a way to get more testing. (Yeah, they mostly use Fedora stuff now, but they don't use a Fedora kernel.) I have been testing OLPC builds, but that wipes my customizations, and I'd rather do more normal Fedora testing with it. Fedora kernels don't support them because they're not all up stream and we don't have support for OFW even where their kernels are upstream. That being said you can use Fedora relatively easily while still doing an initial install with the XO image and getting XO kernel updates but still receiving standard Fedora updates and installing all the other standard Fedora stuff using yum. I documented it here: http://nullr0ute.com/2012/09/using-fedora-on-your-shiny-new-olpc-xo/ It doesn't seem like OF would be that hard to support, given PPC and sparc both use it, and it isn't -that- different then uBoot. Probably not too hard to support but I believe PPC support is via yaboot (or maybe now grub2) layered on top of OFW rather than directly supporting OFW. Peter ___ 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
Fedora ARM status meeting minutes for 2012-12-19
Hi everyone, I would like to share the minutes from yesterday's Fedora ARM meeting. In particular, those on devel@ might be interested in our desire to discuss PA at FUDCon. At FUDCon, we will have a 24 node Calxeda EnergyCore (highbank) server that will demonstrate various capabilities of the (multiple) build server systems that will be available in PHX. At FUDCon we will discuss both our 32-bit build plans and PA push. Separately, there will be 64-bit discussions. We would welcome suggestions (on the arm@ list please) from those who have input on the best format for the PA discussions during the FUDCon event in January. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.log.html Additionally, I can update the status of the following: 1a). TC3 images were tested on various boards: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-12-20-VFAD-Fedora_18_Beta 1b). I did test on GuruPlug. It's the same as before (works, but requires modifications to U-Boot configuration and boot setup). This will not be a beta blocker but it will require that I write up better. 1c). Both the Panda and Panda ES have been tested. 1d). David did run the VFAD as planned. 1f). We hope to all live long enough to have the End of the World beta release posted later on today. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM status meeting 2012-12-19
Hello, This week's Fedora ARM status will take place today (Wednesday, Dec 12th) in #fedora-meeting-1 on Freenode. I will run the meeting with Brendan as Paul is on PTO today. Please ping us on #fedora-arm with additional topics on IRC also. I will be at the dentist soon, so Brendan may start the meeting in my absence. Times in various time zones (please let us know if these do not work on an ongoing basis): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 0) Fedora 18 beta preparation for TC3 - David Marlin and Brendan to update us on images, VFAD 1) Current Problem packages - What's up with F19? 2) FUDCon and PA planning 3) Your topic here If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM status meeting 2012-12-12
Hello, This week's Fedora ARM status will take place today (Wednesday, Dec 12th) in #fedora-meeting-1 on Freenode. I will run the meeting as Paul is out sick today. Please ping with additional topics on IRC also. Times in various time zones (please let us know if these do not work on an ongoing basis): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Current Problem packages - Koji status, texlive, etc. 2) F18 Beta status - Getting there. Thought is to ship and do a VFAD review? 3) Ownership of non-release blocking images (Beagleboard XM, etc) 4) F18 and kernel VFADs planning 5) Your topic here If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/09/2012 03:32 PM, Michael Scherer wrote: snip Having one repo and refusing commercial software are 2 different issues. Really, they're not though. The problem is that stuff is shipped in-distro and builds deps on core packages, and those packages are revved in a symbiotic relationship with the things that need them. The two are joined at the hip in a way that third party stuff is not. If there were a forced separation between the core OS and the stuff that is installed upon it, it would benefit everything that uses the core in equal measure, not just those things shipped in the core distro today. snip And the same goes for having a stable platform, you have to make sure that the platform is well defined, so people do not start to use something outside of the platform ( or it will not work ). In fact, that's what the LSB attempted to do, yet no one ask for it in this thread. So maybe people who want a stable platform should investigate what is the status of the LSB support in Fedora, what are the needs of the ISVs, and find a plan to make them supported. I'd love LSB to matter more. But I didn't raise that can of worms intentionally :) To drill down to a single point though, as I said above, I don't want the distro to ship every piece of software I might use. Today, there is too much of a focus on doing it that way where I think there would be more value (to those who use third party software or who are pondering downstream consumers of Fedora also) in having a smaller core and treating everything that comes on top equally. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/06/2012 10:38 AM, Michael Scherer wrote: People are annoyed to go to different bugzilla to report bugs, people are annoyed to go to different shops to shop for stuff ( as seen by the success of amazon, or even itunes, etc ), so why would it make sense to have a different way depending on what you want to install ? If I may, that comparison is flawed. When I shop at Amazon, I can buy the same product that I can buy at a big box store, or a smaller retailer. I'm enjoying the convenience of going to the App Store (Amazon) but I can also install the software myself (go to the local retailer), and it's all the same bits either way. It's not welded shut. Although the retailers want to screw each other out of business, competition laws require them to generally conform to the notion that I can get my bits wherever I want and install them into my home, etc. My biggest problem with the one true repo approach is that it creates this (flawed) notion that software is either right or wrong: it's either completely Open Source and shipped in the distro, or it's out there on an island. I like Open Source, I like some proprietary software too. I like some software from folks who don't care about packaging it for distros. I like some commercial software. I want my Operating System to provide a (small) stable platform that people can target. Then, by all means do an Amazon. But much as I like Apple, don't do an Apple (iOS) App Store where that's the only way to get bits, do it like they do on the desktop where there's still choice. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/06/2012 01:00 AM, Adam Williamson wrote: On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote: On 12/05/2012 03:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical FWIW (probably not much), I also think this is a great idea. It feels strange to me that the same thing contains manages everything from base system (e.g. kernel through core GNOME stack) and add-on apps (say Battle for Wesnoth, to pick a relatively obvious example). Now, there's a bike shed to be painted over where the lines should be drawn. We could draw them between Core and Extras! :) Note that just because we got rid of Core doesn't mean that it was a bad idea. Ubuntu even adopted a Core of their own a while back. Maybe they'll have the same experience we had and get away from that, or maybe Linux distributions should ultimately not be in the business of providing all+kitchen sink. Speaking only personally, what I want is a stable core platform of very limited size against which I can install other packages and stacks. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/07/2012 12:30 PM, Matthew Miller wrote: On Fri, Dec 07, 2012 at 10:40:13AM -0500, Jon Masters wrote: We could draw them between Core and Extras! :) Note that just because we got rid of Core doesn't mean that it was a bad idea. Ubuntu even adopted a Core of their own a while back. Maybe The bad idea was the insider-vs-outsider mentality inherent in the way the split was made. I don't think anyone wants to go back to that, and, the above joke aside, I think it's clear that we wouldn't draw the line in the same way, and we would *definitely* have different rules than in those days. Sure. Slight caveat that I do prefer Enterprise-leaning inspiration everything ;) but I don't want a return to inside-vs-outside either. To a lot of people who weren't so close to all that, the name Fedora Core still has good connotations -- I still often meet people who refer to Fedora as that. I don't know what the balance in the community now is of people who have that kind of rosy-eyed fondness, people who are new and don't have a history either way, and people who remember the Dark Times and would be put off by the name. Hey, it's still fc18 (for various RPM versioning reasons) :) they'll have the same experience we had and get away from that, or maybe Linux distributions should ultimately not be in the business of providing all+kitchen sink. Speaking only personally, what I want is a stable core platform of very limited size against which I can install other packages and stacks. I think we *could* have both. There's no reason that Fedora couldn't make that stable core platform *and* provide layers above it. In fact, referring to https://fedoraproject.org/wiki/Overview?rd=FedoraProject:About#Our_Mission it seems pretty clear that both levels are in scope. Sure we could. There's nothing to prevent a company or an organization from shipping an OS as well as software that installs upon it. Plenty do. But it's when one gets in the business of shoving in the kitchen sink and believing that everything must be provided in the one true repo that the problem comes. I want to be able to get packaged third party software for distros like Fedora more easily. If there's an expectation that some kind of platform compatibility has to exist, we might even see that happen. I was encouraged last night that the latest Altera design tools work on Fedora 17 with only one compat library being installed, but I've been far less lucky with other stuff. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM status meeting 2012-12-05
On 12/05/2012 02:39 PM, Peter Robinson wrote: I can't make the meeting. It conflicts with the Board meeting. Current items on the agenda: 1) Current Problem packages 2) F18 ARM VFAD - additional feedback, blockers? 3) Ownership of non-release blocking images (Beagleboard XM, etc) Who decided this was a non blocker? It was my understanding it was a blocker. It was supported in F17 and it was discussed that it wasn't a blocker for alpha. Paul is going to start a thread specifically on some of these additional targets, seeking volunteers to support them. I could go either way on the BB-XM. It's not too much hassle to test but it's also yet another target and so far there don't seem to be people yelling yet. 4) aarch64 update 5) Your topic here koji updates. I've still not heard any progress on the repos issues. A ticket was filed in the tracker. Hopefully we will get an update. It seems rebuilding some of the repos, in tandem with the hdf5 soname bump rebuild somewhere along the lines has resulted in a buildroot with a working compiler for netcdf. I can't reproduce the problems we had with that in either a local v5 or v7, or a mock v5 or v7, and a scratch build succeeded earlier as well of the -3 release, which is what we need to end up with anyway. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On 12/05/2012 04:06 PM, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical That would be *epicly* *awesome* in so many ways, and it'll never happen. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MPI updates
On 11/01/2012 11:08 AM, Orion Poplawski wrote: - I built openmpi 1.6.3 in rawhide yesterday. This had an unexpected bump in the libmpi_f90.so soname. I know this affects hdf5 and netcdf-fortran, both my packages and I'll be rebuilding them later today (hopefully). On that, I've made a patch that fixes ARMv5/v6/v7 atomics properly (it's a kludge, sending it upstream for them to look at). I can now build on ARM, and have sent the patch over to Peter/Fedora ARM list. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maintainers with bugzilla issues. (Please read and help contact) (last call)
On 07/06/2012 02:32 PM, Kevin Fenzi wrote: pnasrat 'Paul Nasrat' pnas...@gmail.com pinged -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/13/2012 02:02 AM, Matthew Garrett wrote: snip From a purely practical perspective, the popularity of OS X as a development platform means that we're likely to see a gradual increase in the amount of code written to assume LLVM-specific functionality. People are just going to have to cope. I do not like this as a strategy. I feel it is necessary in the case of a core toolchain component to set some expectations early on. Those might be Fedora welcomes everyone using LLVM for everything once Red Hat hires some folks to maintain LLVM on the same level as gcc or whatever the wording needs to be. But we're not going to just cope. What's going to happen is we're going to get bitten nastily. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/13/2012 01:21 AM, Michel Alexandre Salim wrote: snip Maybe we should draw more of a distinction between LLVM and clang, and use ExclusiveArch: on the latter to whitelist only architectures we feel comfortable supporting? We could. Right now, for ARM (as an example), there is really about as much representation as x86 from what I can see in terms of core arch support. I'm sure upstream bits will be pulled in, and David and ajax will do a great job - but unless I'm mistaken they're not offering to take on the task of being a architectural maintainer for core x86 code. On x86, we have Jeff's tools group within Red Hat that does an excellent job of providing all of the kinds of behind-the-scenes support that an architecture really needs. It's not just fixing build issues, or whether stuff builds on ARM - it's known how and why specific instructions are emitted and how that relates to the design. IOW it's a full time job to support something like clang at the same level that we support gcc today and I don't see that level available. Therefore, if ExclusiveArch is a solution, it ought to be ExclusiveArch: none. Instead, while I think some arches do need to be considered for exclusion - for example, if you compare the build flags for gcc and llvm+clang today for non-ARM and non-x86 you'll see various stuff on ppc/s390x that (to me) raises some concerns just in terms of the build itself - I think more this should be ExclusivePackage. I believe one should have to make a case for growing a dependence like this within the distribution. So we need it for soft rendering? Great. That's a wonderful exception to a general rule of not requiring it. I don't mean to sound anal, but we need to stop any growing in dependence on this until we're in a position to broadly support on any arches. (it's rather like how we have core packages depending on nonsense like ruby or python in the SPEC file just to do something that a shell escape could trivially have done ten years ago - if we don't make rules to stop this growth there, we're making it much harder to bootstrap - therefore rules do matter and we need them in this case before we start growing a dependence on something as core as a new toolchain) I'm at the moment not really comfortable switching LLVM to be built with Clang as the default -- given that on Linux it has a brittle dependency on specific versions of libstdc++. But we could certainly make it a switchable build-time option. Apart from the worrying test suite results on secondary archs, actually it's the libstdc++ issue that's causing the most headache. How much effort does it take to maintain a compatibility version of libstdc++? It'd make clang much more useful if we're not caught between upstream (that abandons released versions) and the Fedora GCC team's fast update cycles. I think upstream also not providing support is another red flag to be honest. On the secondary arch front btw, I believe we have two problems on ARM: one is some tests are failing (not unique to ARM), and two I believe I am onto a heretofore not-well-isolated general futex bug that isn't related to LLVM/clang as a package. Anyway, I don't feel in a good position to comment on the libstdc++ resolution other than to again repeat my concerns about having any growth in dependency. Obviously don't take this personally! You do a great job Michel :) But it's become clear to me that supporting a toolchain in Fedora requires a team of folks to back it up that we don't seem to have here. Jon. -- 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 07:39 PM, Brendan Conoboy wrote: o jonmasters to track down the OMAP (Panda/Beagle) issue. Right, but I'm also going to try to hunt down the futex issue and a few other things...so we might end up going with an older kernel in the OMAP images just for beta to get that out earlier in the next week. The OMAP issue is likely a percpu issue, hence it's ok on Beagle, etc. Update to follow. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/10/2012 04:56 AM, David Airlie wrote: - Original Message - From: Jon Masters j...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Michel Alexandre Salim sali...@fedoraproject.org Sent: Wednesday, 9 May, 2012 10:57:30 PM Subject: Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. Thanks for the private email about ARM stuff. I've just kicked off another scratch build for ARM LLVM that might fix our outstanding problems. I'm ok - vaguely - in being a co-maintainer on ARM if there is nobody else on our end who can represent ARM (as it seems). I started going through some of its design over the weekend, in my copious non-existent spare time to try to understand the ARM bits. More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Don't confuse llvm and clang, llvm has no equivalent in gcc world, clang is a C compiler like gcc that uses llvm tech. Right so I wasn't confusing these :) However, we package both together and for ease of discussion many folks are going to think of it as a gcc alternative (aside from the specific gfx situations you and ajax have). My main concern was potential for growing use beyond that. I made an analogy about glibc to which I accept ajax's response that they're trying to reconcile with eglibc, but it's more the general concept I was getting at. Let me avoid a specific example because someone will find a way to find a hole in it :) Instead, my stance is we want to be very careful about unsupportable use of LLVM. I've filed a ticket with FESCo so hopefully there can be some debate as to acceptable use :) It probably makes sense that one of myself, ajax or glisse help out packaging llvm, but we aren't the most reliable people in terms of spare time to commit. Right. You guys have various incentives to care about specific use of LLVM itself so I'm sure it will always be supported to some level, but for the other piece - clang+LLVM, etc. - to grow further use in the distro (in displacement of gcc) I feel we'd need to have actual RH staff to support it that I don't think we have any plans to have. So I want to cut this off at the pass before we blink and we have a problem. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Weekly ARM status meeting - Wed 2012/05/09
Hi Folks, Thanks for joining us today in our weekly meeting. Here are the minutes: http://meetbot.fedoraproject.org/fedora-meeting/2012-05-09/fedora-meeting.2012-05-09-20.00.html Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ARM MEETING - moving to #fedora-meeting-1 next week
Folks, The EMEA Fedora Ambassadors have a periodic meeting at the same time that we do. So that we don't ever have confusion, we will henceforth move all of our meetings to #fedora-meeting-1 at the same time. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. Thanks for the private email about ARM stuff. I've just kicked off another scratch build for ARM LLVM that might fix our outstanding problems. I'm ok - vaguely - in being a co-maintainer on ARM if there is nobody else on our end who can represent ARM (as it seems). I started going through some of its design over the weekend, in my copious non-existent spare time to try to understand the ARM bits. More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/09/2012 05:57 PM, Jon Masters wrote: More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Putting that another way, if we carried eglibc in Fedora, there would be cries and shouts if a large number of packages started requiring it because we have folks that maintain GLIBC. I feel LLVM is a similar piece of critical technology that we should not need for critpath. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Weekly ARM status meeting - Wed 2012/05/09
Hi everyone, A reminder that this week's ARM status meeting will take place tomorrow (Wednesday), on #fedora-meeting. There will be no phone call. Please reply to this email with any additional agenda items you want to add. Times in various timezones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Also join #fedora-arm on Freenode for general ARM discussion before/after the weekly syncup. Agenda: 0). Current build status - Gnarly bugs and build failures - Sending out regular problem package mails? - Atomics on older processors (v5)/LLVM/etc. 1). Fedora 17 Beta - What are the remaining constraints on getting this out? 2). Secondary Architecture Promotion - Update on our current status wiki page and response to reqs. 3). Your topic here Jon. P.S. I will return to poking at LLVM this afternoon. I hope to have an update in time for the meeting tomorrow - might be a very late night. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Weekly ARM status meeting - Wed 2012/05/02
Hi Folks, Thanks for joining us today in our weekly meeting. Here are the minutes: http://meetbot.fedoraproject.org/fedora-meeting/2012-05-02/fedora-meeting.2012-05-02-19.59.html Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Weekly ARM status meeting - Wed 2012/05/02
Hi everyone, A reminder that this week's ARM status meeting will take place tomorrow (Wednesday), on #fedora-meeting. There will be no phone call. Times in various timezones: PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Also join #fedora-arm on Freenode for general ARM discussion before/after the weekly syncup. Agenda: 0). Current build status - Gnarly bugs and build failures - Sending out regular problem package mails? - Atomics on older processors (v5)/LLVM/etc. 1). Fedora 17 Beta - What are the constraints on getting this out next week? - David will update us on media creation, etc. too 2). Secondary Architecture Promotion - Status of ARM toward promotion criteria (Brendan and Dennis have the ball, quick sync) 3). Your topic here Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes from weekly Fedora ARM status meeting (2012/04/25)
On 04/24/2012 12:27 PM, Jon Masters wrote: Let's have one of our weekly status calls tomorrow pm. I aim to send these reminders out more regularly so that we can get in the habit. If the times no longer work for those involved in the Fedora ARM project, please do let us know asap. Sadly, not every time will always work :) Meeting is on #fedora-meeting for a (trial) change. Link to the meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2012-04-25/fedora-meeting.2012-04-25-19.59.html Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Weekly ARM status call - TOMORROW (Wed 2012/04/25)
On 04/24/2012 01:33 PM, Jerry James wrote: On Tue, Apr 24, 2012 at 10:29 AM, Jon Masters j...@redhat.com wrote: Times in various timezones: PDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Shouldn't that be PDT: 1pm MDT: 2pm Yes, as I said on IRC I was going to make a joke about MDT depending how far South you are, but nobody would get it :) Anyway, I was wrong about the offsets and I'll fix it next time. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: [fedora-arm] Weekly ARM status call - TOMORROW (Wed 2012/04/25)
Original Message Subject: [fedora-arm] Weekly ARM status call - TOMORROW (Wed 2012/04/25) Date: Tue, 24 Apr 2012 12:27:23 -0400 From: Jon Masters j...@redhat.com Organization: Red Hat, Inc. To: a...@lists.fedoraproject.org Hi everyone, Let's have one of our weekly status calls tomorrow pm. I aim to send these reminders out more regularly so that we can get in the habit. If the times no longer work for those involved in the Fedora ARM project, please do let us know asap. Sadly, not every time will always work :) Meeting is on #fedora-meeting for a (trial) change. I am also going to suggest we do not have the phone component this week, and see how it goes. If folks are more comfortable, the phone bridge is easy to setup. As to the venue, I think it's appropriate to give it a trial and see what happens - if #fedora-meeting turns into an opportunity for the peanut gallery to take potshots, we'll reconsider that approach. Times in various timezones: PDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Also join #fedora-arm on Freenode for general ARM discussion before/after the weekly syncup. Agenda: 0). Current build status - Gnarly bugs and build failures - Atomics on older processors (v5) 1). Secondary Architecture Promotion - discuss outcome of FESCo meeting 2). Happy Birthday ARM - ARM turns 27 on Thursday, how are we celebrating? - Where do we stand with the F17 release. 3). Your topic here Jon. ___ 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: Feedback on secondary architecute promotion requirements draft
On 04/19/2012 05:36 PM, Matthew Garrett wrote: Ok, I'll modify that section. Thanks for the feedback! Matthew, Could you add comments addressing the need for documentation and website content around a promoted arch? And any of the other comments I made in my previous reply that you would like to add in? E.g. clarifying what sufficient developer resources means, etc. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/20/2012 04:30 PM, Matthew Garrett wrote: On Fri, Apr 20, 2012 at 04:22:38PM -0400, Jon Masters wrote: On 04/19/2012 05:36 PM, Matthew Garrett wrote: Ok, I'll modify that section. Thanks for the feedback! Matthew, Could you add comments addressing the need for documentation and website content around a promoted arch? And any of the other comments I made in my previous reply that you would like to add in? E.g. clarifying what sufficient developer resources means, etc. I think we'll want to discuss the documentation and website scenario first - I have no idea how well PPC was documented when it was a primary architecture, and we don't necessarily want to hold new ones to a higher standard when it comes to that. But yes, I'll tidy up the rest before the fesco meeting. Excellent. Thanks. See you in #fedora-meeting ;) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
Hi Matthew, On 04/18/2012 09:54 PM, Matthew Garrett wrote: Right now I don't think ARM's doing a great job of that [being part of the Fedora community]. Your meetings happen on the phone and aren't minuted. I am sorry that you feel that way. I think it is important to add some context to the point about meetings (I'm not sure how one generalizes that into a broader statement). We have meetings that are on the phone, and on IRC, on #fedora-arm, which you are welcome to join (though I understand that this is unusual to have a phone call and the timing might not be convenient to everyone's schedule - the current time was collaboratively chosen by everyone involved in Fedora ARM). We use the standard meeting bot, and we have an intention to move to #fedora-meeting in due course. For now we're still using #fedora-arm, but if it's important that we move meetings from now on, we can do that. We are aware of the need to do a better job in getting things written down (on IRC) as they are discussed. In the meeting we had today (prior to your email), we specifically discussed whether we want to continue to use the phone, and it was decided that this was generally preferred for the time being. Not everyone prefers the phone, of course, but the consensus appeared to be that we will continue the dual phone/IRC approach for now, and revisit this topic semi-regularly for review. I've got no insight at all into how your development process is progressing. I'm glad to see that you care deeply about the topic. You're welcome to join #fedora-arm, participate in the discussions, join the mailing list, and reply to any of the discussions there. You're also welcome to start new conversations, or raise issues on IRC any time you like. It might also be relatively easy for us to arrange to get you some hardware that you can run the ARM port on if you would like to help? At minimum you should be meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd be Cc:ing them to devel@. Feel free to add that to the list of requirements for SA promotion. If you're doing everything transparently We are doing everything transparently. Some times it might happen on the wrong channel, and we might screw up with regard to certain expectations, but there is no attempt to be non-transparent. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/19/2012 01:22 AM, Matthew Garrett wrote: On Thu, Apr 19, 2012 at 12:42:58AM -0400, Jon Masters wrote: Hi Matthew, On 04/18/2012 09:54 PM, Matthew Garrett wrote: Right now I don't think ARM's doing a great job of that [being part of the Fedora community]. Your meetings happen on the phone and aren't minuted. I am sorry that you feel that way. I think it is important to add some context to the point about meetings (I'm not sure how one generalizes that into a broader statement). We have meetings that are on the phone, and on IRC, on #fedora-arm, which you are welcome to join (though I understand that this is unusual to have a phone call and the timing might not be convenient to everyone's schedule - the current time was collaboratively chosen by everyone involved in Fedora ARM). We use the standard meeting bot, and we have an intention to move to #fedora-meeting in due course. For now we're still using #fedora-arm, but if it's important that we move meetings from now on, we can do that. #fedora-meeting is a given, but really, other parts of the project are able to function by having meetings on IRC - It's important to have a written record of not only what decisions were made, but also why they were made. Thanks for making this point very clear. I'm sure we'll take it on board. I'm all for doing what makes sense - moving IRC channel is hardly difficult, and dropping the phone can be done (note that we are not the only part of the Fedora project that uses the phone though). I've got no insight at all into how your development process is progressing. I'm glad to see that you care deeply about the topic. You're welcome to join #fedora-arm, participate in the discussions, join the mailing list, and reply to any of the discussions there. You're also welcome to start new conversations, or raise issues on IRC any time you like. It might also be relatively easy for us to arrange to get you some hardware that you can run the ARM port on if you would like to help? I don't have the time or the inclination to be involved in the ARM port at the moment. That's fine. Not a problem. Do note though that we're very willing to work with anyone who does want to get involved. You're most welcome. What I *do* want is to have some visibility into what you're doing in order to reduce the probability of decisions being made that are incompatible with some other aspect of the distribution. It's certainly a good idea to make sure everyone is aware of important decisions. We certainly don't need the personal approval of any one person, but we hope that in general we make sane choices, and we can benefit by making sure that everyone is aware of our sane choices :) I think the team will need to do what makes sense. We're busily trying to make progress, and we need to make some decisions. For example, you're not running the build system, but Chris and the Seneca team are. They're doing a great job. It would probably be inappropriate to expect your approval for decisions we would need to make around the build system, but it would certainly be beneficial to share what we are deciding so that there is due opportunity for any course correction. So, we'll take your input on board and we'll try to increase the level of informational flow and general comfort of those observing our effort. The onus is on you to make sure that people are aware of relevant decisions you've made. Of course, that's good input. I think we can always do a better job :) At minimum you should be meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd be Cc:ing them to devel@. Feel free to add that to the list of requirements for SA promotion. No, because it's not a requirement. In theory an SA could be perfectly suited for PA promotion without any real involvement with the Fedora community. It'd just be massively more difficult. I think there's a missunderstanding here. I don't recall suggesting that you need to add anything about real involvement to the list, just that if you feel certain specifics are required around meeting format, etiquette, and so forth, that would be useful to note down. If you're doing everything transparently We are doing everything transparently. Some times it might happen on the wrong channel, and we might screw up with regard to certain expectations, but there is no attempt to be non-transparent. I appreciate that there's no deliberate attempt to avoid scrutiny, but that's not enough. You need to take the initiative in being more active in communicating with the rest of the project. Absolutely. We are a small team, and we are trying. Like you, the reason Brendan and myself are replying this late into the evening is that we are working around to clock to advance this project. We agree that the Fedora ARM team can do a better job at engagement and we will try to dedicate a good chunk of time to improving overall cohesion. Thanks
Re: Feedback on secondary architecute promotion requirements draft
Hey guys, Cutting this sub-thread off at the pass :) I think it's obvious that we in the ARM project can do a better job at engagement, cohesion, and we can learn and improve in many ways. I would like to suggest that we steer this thread back toward the more abstract question at hand: that of secondary promotion criteria. With that in mind, I've a few thoughts specific to the existing draft, some of which have been touched on already, but let me just offer my $0.02: * Not really sure how to word this, but something about the website, wiki, and documentation? After all, it's all very x86-ish right now. * I'm trying to figure out what adequate representation means in the context of infrastructure and release engineering. For example, Dennis Gilmore is very involved in a number of secondary efforts and I would /think/ that would be sufficient? But are you putting specific head count requirements in terms of dedicated resources in here? * We agree on the need for Fedora maintained servers. Absolutely. We'll drop the notion of interim solutions (for any architecture). * I would like clarification of developer resources. For example, does this mean head count, hardware, both? And to what level? In terms of access to hardware, we're working on solutions for this. For those who work for Red Hat, I can get certain hardware made available internally (for e.g. ARM), and in the broader community, a certain amount of hardware is already being given out. But clearly, we can't give everyone one of every system. So having some numbers here - however vague they need to be - will help to clarify things. In the case of ARM, we'll endeavor to have certain hardware available in a central fashion that can be provisioned by individual developers (there are some technical challenges there, but that is being thought through). * Is the release criteria malleable when it comes to the influence of new architectures in general, in terms of what that might allow the distribution to do that it can't do on the existing architectures? Thanks for reading. Meanwhile, we genuinely will take the earlier comments on board about a need to improve our level of engagement. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 03/26/2012 08:00 AM, Richard W.M. Jones wrote: Which leads me to a rant about ARM. G RANT!! I didn't think I'd ever love the BIOS, but compared to the alternatives (UEFI and a million different ARM bootloaders) it's simple and effective. There is some truth to that. Nobody is going to stand up and say that the 32-bit ARM zoo (as I have called it on a number of occasions) is a situation today. This is a case where strong leadership and aggressive standardization is required in order to have *one* platform. That work is ongoing at the moment, and in the interim, we live with slightly more pain than would be ideal. But therein lies the fun ;) In the future, ARM systems will transition increasingly to UEFI. Many ARM server systems will likely eventually boot with ACPI as well. They will smell like low-energy alternatives to PC servers over time, and in another decade or two something more exciting than UEFI will replace UEFI and folks will mail about how things were better with UEFI! Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 06:51 PM, Brendan Conoboy wrote: On 03/20/2012 03:33 PM, Jesse Keating wrote: 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. I think this is the best takeway from the thread I've seen so far. We're trying to figure out where to go to get to PA. If it turns out F18 is wildly optimistic, ok, no problem. We'll come back later after we get all the kinks ironed out. But the past few days have provided invaluable initial input as we figure out how to drive at 60mph, while also giving you greater than 60mpg in power/performance :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updated Fedora ARM qemu images?
On 03/22/2012 03:38 PM, Chris Tyler wrote: On Thu, 2012-03-22 at 12:10 -0600, 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? New yum-installable RPM images coming Real Soon Now(tm) :-) Chris, David has some time to possibly help with this. I already mentioned it to him...hopefully he pinged you :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Hi Kevin, Thanks for your message. On 03/22/2012 11:21 PM, Kevin Kofler wrote: Peter Robinson wrote: On Thu, Mar 22, 2012 at 2:28 PM, drago01 drag...@gmail.com wrote: The only ones where this is possible right now are actually x86 based tablets. Even Windows 8 wont help here as MS mandates that the devices are locked with secure boot without having an option to disable it. No that is definitely not the case that it is x86 only, Quite the opposite: M$ rules for secure boot are: * on x86 (or non-ARM in their wording) devices, it MUST be possible for users to disable secure boot, * on ARM devices, it MUST NOT be possible for users to disable secure boot, i.e. all ARM devices shipping Window$ will have restricted boot forced on with no option to disable it. To an extent, Kevin is perhaps right here. There is a version of the Microsoft Logo requirements that implies that logo-conforming devices cannot be shipped with Custom Mode enabled. I know Matthew, and many others, are suitably involved in advocating for different positions. That's all I'm going to say here without legal counsel. But let's put this in context. There will always be locked-down devices that are designed to make it difficult to run alternative Operating Systems, there have been before Fedora ARM, and there will be afterward :) We haven't been seriously discussing the idea of running Fedora on cellphones - and I'm certainly not proposing that now! - but I would note that nobody has said how terrible it is that Fedora ARM will not run on iPhone without hacking, cracking, jailbreaking, rooting, or whatever terms you like. A vertically integrated tablet shipped with Windows 8 is the same thing - it's designed end-to-end as a single embedded product. There are many other tablets out there not shipping with Windows 8 today, and there will be many more in the future. Some of those Windows 8 tablets will eventually run non-Windows OSes because it is inevitable that someone, somewhere will find a way to do that. So while I'll defend Kevin's comment here as valid input, let me say that I would like to issue a call for civility, Kevin. Please, engage us in a reasonable, serious conversation, or don't. I haven't replied to your other messages because they are filled with vitriol. I suspect many other people similarly ignore you (and perversely, I suspect you assist in our cause of becoming a Primary Architecture by being so extremely vocal in your unreasonable opposition of the concept). Anyway, I am very willing to discuss with you, but only if you will agree to please consider having that discussion in a civil manner. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 03/20/2012 11:52 AM, Peter Jones wrote: In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. So without further ado: Thanks for sending this. We were planning to start (and still are) a separate and broader thread once we've had time to circle back with a few folks in other groups for one-on-one feedback. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
Hello, On 03/20/2012 12:37 PM, drago01 wrote: On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy b...@redhat.com wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: That said, I considera cross-building environment for secondary arch to be inevitable, which would at least help for the class of issues, I am referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. The reasons are? Fedora generally doesn't cross-compile because you have to minimally run certain target configuration stuff on the host, and there are many other hardcoded expectations. [ Aside - skip this bit - because someone is going to mention it and take this thread onto a wild tangent, yes you can use distcc hacks, yes, there is/was Scratchbox, and yes there are many other cute hacks. We haven't proposed any of this because we want to be boring, we want to win acceptance by doing what x86 does in as many cases as reasonable. It isn't reasonable to expect ARM to install using Anaconda on a $25 target, but it is reasonable to expect on-target build ]. Let's figure out how to make native compilation work *better*, how to make koji work *better* when more architectures are involved than just x86. The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). Well, we've done a number of mass rebuilds, a complete bootstrap from scratch, and several releases now. So, it might be a gimmick, but it works. We need to stop thinking of ARM as it was 10 years ago. This year, we're going to see systems with 288+ cores in 2U of rack space. Next year, we're going to see Cortex A-15 systems that will be much faster still, and the year after, we're going to see 64-bit systems with at least 8 highly performing cores. It's not all about performance though. ARM isn't going to beat x86 in a speed race...that is not the goal. It's about aggregate performance, not individual node performance at the high end, and about mass availability at the low end. We can remain an x86-only primary distro. But that won't help address the longer term problems we will face. I'll spare the hyperbole for the moment, but I will add that this is a multi-year journey that we want to begin now. Yes, there are rough edges, yes this is cutting edge stuff, yes that is precisely what Fedora is all about. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 12:56 PM, Brendan Conoboy wrote: On 03/20/2012 09:50 AM, drago01 wrote: I don't know about the details there but that does not sound like unfixable to be. I'd even say that fixing that is a prerequisite to allow secondary archs that run on slow hardware to become primary. Please, please, no. Cross compilation for Fedora cannot and will not ever get a secondary arch to primary. We're talking man-decades of engineering time to solve all the problems. Decades. Yup. I vote we shelve this part of the discussion in the interest of ever turning our proposal into something that will be accepted. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/20/2012 01:42 PM, Dave Jones wrote: On Tue, Mar 20, 2012 at 12:54:36PM -0400, Jon Masters wrote: The hardware is way slower ... so we can just build on faster hardware (x86_64). Which is the only sane way to do it. Trying to build on ARM directly is kind of a gimmick but nothing one can seriously use to build a whole operating system. (Yes it works but it is way to slow). Well, we've done a number of mass rebuilds, a complete bootstrap from scratch, and several releases now. So, it might be a gimmick, but it works. We need to stop thinking of ARM as it was 10 years ago. This year, we're going to see systems with 288+ cores in 2U of rack space. Why are you even bringing up this as yet unreleased hardware in the context of arm32 builds are slow ? Even if it was released today, it doesn't solve this problem at all. The hardware I'm citing there is 32-bit, and it's coming later *this year*. So I'm not conflating the two at all here, honestly :) Arm32 as primary and Arm64 as primary are two entirely separate discussions, and conflating the two isn't solving anything. I agree. Don't worry, we'll be getting to AArch64 later :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Thu, 2012-01-05 at 11:18 -0600, Dennis Gilmore wrote: El Thu, 05 Jan 2012 10:37:41 -0500 Tom Callaway tcall...@redhat.com escribió: On 01/05/2012 09:40 AM, Richard Shaw wrote: I just didn't know if there was any filtering going on for the mass rebuild or if all packages, regardless of dependence on gcc were going to be rebuilt. My understanding is that we traditionally rebuild everything at the time of a mass rebuild, because it is a good excuse to do it. Im planning to just rebuild everything. ideally drop all the disttags prior to fc17 since people get antsy about that at times. those packages that still have anything before .fc15 really need rebuilt. since we had reasons then to rebuild everything +1 This is a great time to rebuild everything. Not only does it assist with the gcc 4.7 switchover but it also proves that everything builds. And that turns out to be very useful when bootstrapping new architectures. I was planning (and still am) to make a formal proposal that Fedora require a mass rebuild every 2 releases if none is done for incidental reasons, just to help with ensuring the whole thing does still build. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Thu, 2012-01-05 at 21:47 +0100, Ralf Corsepius wrote: I guess you are referring an ordered rebuild, not a simple sequential rebuild. The latter would be mostly useless. For bootstrapping, ideally there would be ordered rebuilds, but even any mass rebuild assists more than having none at all :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kmod for fedora?
On Thu, 2011-12-22 at 13:31 +0100, Lennart Poettering wrote: On Thu, 22.12.11 07:17, Neal Becker (ndbeck...@gmail.com) wrote: I was reading about kmod on LWN. Sounds like it might be good for a future fedora, to optimize boot time http://www.politreco.com/2011/12/announce-kmod-1/ https://lkml.org/lkml/2011/12/22/142 Thanks. Yea, it's a first cut. I'll be working with Martin Sivak to get this into good shape. There's a review bug pre-emptively filed on this and a reviewer lined up to start looking at it once we're ready. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Any interest in an or1ksim package?
Folks, Anyone interested in an or1ksim package for Fedora? If so, I could throw something together based on upstream trunk. None of the current releases (even the RC) are able to run the orpsoc model correctly with the latest upstream kernel, due to the assumption of support for tap network devices that is very new, but the latest trunk is able to do so. Probably I'm the only person who cares about OpenRISC ;) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request update of shared-mime-info
Hi Bastien, Thanks for your help with this. I'm glad a fix is in upstream now. On Tue, 2011-11-22 at 11:12 +, Bastien Nocera wrote: On Mon, 2011-11-21 at 14:36 -0500, Jon Masters wrote: Folks, Can someone please push the update that I made (with permission) to shared-mime-info? I'm getting jcm does not have commit access when I try to make the F16 update. This fix is required to actually be able to play many MP3 files (including all purchased from Amazon.com) on F16. No, it's needed _only_ to play Amazon.com purchased files. Even if it's possible to create a broken file, I hardly think that trying to artificially raise the severity of the problem is useful. I believe any MP3 file containing a uits tag will be affected. This is the Unique Identifier Technology Solution, which appears to be required by a number of media distributors. Therefore, I believe (but have not confirmed yet) that this will affect much more paid content than just that on Amazon.com. Even if it's just all Amazon.com music I believe that is a pretty significant issue. Many users will expect to be able to download an MP3 file they purchased legally and play it on their computer. On Fedora, this is already overly complicated (for various well known and previously discussed reasons) but it usually boils down to the user Googleing for play mp3 Fedora or even play music Fedora or similar. They might be willing to take the steps required and documented there, but they will be disappointed when they can then not play downloaded content, especially legal content. You are correct that it is possible to play MP3 files on Fedora 16 without this update, however I would like to politely request again that this be pushed as an update. Separately, I did pay for you to have a legal copy of a music file that would not play for the purposes of ensuring that this functionality works in the future, and if someone else would like me to gift them an Amazon MP3 music file for test purposes, I would be willing to consider that also (off-list). Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request update of shared-mime-info
On Tue, 2011-11-22 at 15:37 -0500, Jon Masters wrote: I believe any MP3 file containing a uits tag will be affected. This is the Unique Identifier Technology Solution, which appears to be required by a number of media distributors. Therefore, I believe (but have not confirmed yet) that this will affect much more paid content than just that on Amazon.com. Even if it's just all Amazon.com music I believe that is a pretty significant issue. The following seems to clarify that UITS embedded metadata is going to be found on more than just Amazon.com. Google shows various media companies looking for hires to write code to embedded this too. http://uits.umusic.com/faq.htm Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Request update of shared-mime-info
Folks, Can someone please push the update that I made (with permission) to shared-mime-info? I'm getting jcm does not have commit access when I try to make the F16 update. This fix is required to actually be able to play many MP3 files (including all purchased from Amazon.com) on F16. Tested Koji builds: F16: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530557 F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530543 Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] ARM Architecture - Package Updates in git
On Mon, 2011-11-14 at 13:19 -0500, Chris Tyler wrote: The ARM Secondary Arch project[0] is working on an F15 release for the existing armv5tel architecture as well as the new armv7hl architecture (with hardfp ABI). This effort has been previously announced and is ongoing. A number of minor package changes are required as a result of this effort: To add to this, we will shortly be commencing an effort to track rawhide builds of primary on ARM, so these same fixes will of course land in the devel branches of packages aswell. In the coming months, we hope to be able to respond to packaging issues as they arise by shadow building everything that lands in primary within a few days. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote: Grovelling around in the F15 xorg-server sources and reviewing the Xorg log file on my F15 box, I see, with _modern hardware_ at least, that we do have the monitor geometry available from DDC or EDIC, and obviously it is trivial to compute the actual, correct DPI for each screen. I am clearly going to have to explain this one more time, forever. Let's see if I can't write it authoritatively once and simply answer with a URL from here out. (As always, use of the second person you herein is plural, not singular.) EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 16:20 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 11:14:56AM -0400, Jon Masters wrote: How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? The specification provides everything needed to express this data accurately, and proves the worth of specifications by virtue of approximately nobody actually implementing it correctly. How about an actual DPI value? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 12:12 -0400, Adam Jackson wrote: On Thu, 2011-10-06 at 11:14 -0400, Jon Masters wrote: On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Given that successive revisions of the spec have gone out of their way to make it acceptable for displays to provide _less_ useful information, on the grounds of manufacturing cost reduction, I think the momentum is quite in the other direction. More pragmatically, VESA are not the people with any influence here. The only thing that matters to a monitor vendor is what Windows does when you plug it in. Linux can stamp its little foot all it wants. No one will care. If you want to be a big enough player in that market to have some influence, you have to start by playing in the sandbox that's already built, and in that sandbox physical dimensions are just not reliable and never will be. Cope. Ok. I can cope, and not to flog a dead horse here...but has any effort been made anywhere on the Open Source side of things to influence future EDID specs? I'm sure Linux can stamp all it wants and nobody will care, but it probably doesn't hurt to raise this for discussion next time there's an update to the standard - or, shock, reach out to MSFT and see if they have any interest in working together on fixing this experience which perhaps also causes problems they care about on Windows. Just a suggestion. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On Mon, 2011-10-03 at 12:56 -0400, Adam Jackson wrote: More to the point, your DPI numbers would be per-output anyway, so there's no picking a single point size preference, the same size in pixels would be different sizes in millimeters on each output. In fairness, for my dual head setup I did what I always do: I bought a matched pair of monitors from the same batch. EDID seems sane, too. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Mon, 2011-08-29 at 19:13 +0100, Peter Robinson wrote: On Mon, Aug 29, 2011 at 4:06 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Just a quick update that we've had mock builders running around the clock and that, at last count we had built almost 9,000 native ARMv7 RPMs for the Fedora 15 bootstrap effort. I'll keep everyone updated. If you would like to contribute build cycles, please see my earlier mail, and ping us on #fedora-arm (irc.freenode.org) if you need assistance. Why don't we just get it running in koji? Once we can get a armv5tel/armv7hl running in koji we don't need to have people off doing their own thing and we can start moving forward as a group. We need a provisional set of repos to populate Koji. Arguably we might have enough now to get away with it, but we'd still wind up with lots of buildroot and false FTBFS type failures as Koji couldn't find deps. For better or worse, Dennis and I felt it was better to do a mock run first. The Koji build will happen soon. We need to do one more build to make sure we have every build dep in place during builds. Although we suspect we're good even with stage4, we'd like to make sure we don't have packages failing to enable features during build by doing it again in what we call stage5. Then, we're done. Lots of nice things could be done to improve this in the future, like bootstrap deps, etc. We'll keep an eye on builds this week. Some packages need huge resources to build, so they might be removed from the general list and built on a box we have that has a lot more RAM than many of the other builders. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Just a quick update that we've had mock builders running around the clock and that, at last count we had built almost 9,000 native ARMv7 RPMs for the Fedora 15 bootstrap effort. I'll keep everyone updated. If you would like to contribute build cycles, please see my earlier mail, and ping us on #fedora-arm (irc.freenode.org) if you need assistance. Hopefully, within a week or so we can consider switching to a full Koji environment, at which point we'll just have to do one more mass rebuild (stage5) before we /should/ have everything built correctly in Koji. We can do a preliminary alpha release of F15 soon thereafter. Folks are working on Anaconda, but I've no status update on that front yet. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday August 26th 2011, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the continued bootstrap of F15 hardfp (hardware floating point). Previously, we performed initial bootstrap (stage1), then proceeded to get RPM working natively within an ARMv7 hardfp environment (stage2), then got yum and mock working (stage3). We are now in what we are calling stage4 in which we are rebuilding the world of packages using mock, but are not yet using Koji to do so - that will be stage5, the final stage before we are able to say that we have completed bringup. We need helping building packages within a mock environment for F15. To do this, we have made your life as a (potential) volunteer somewhat more straightforward through the creation of a standard image that you can install onto an ARMv7 compatible board (tested on Panda, we believe this should also work on Beagle, and can be made to run on Tegra-2 boards like Trimslice with a replacement kernel - ask us for assistance). Once you have done this, the resulting system will contain a simple script that you can use to randomly retrieve a package that needs building and have it build without you having to even issue a single mock command :) To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Follow the instructions contained within the readme file to extract the uboot, boot, and root archives onto an SD Card for your device. These instructions will destroy whatever is already installed. If you are familiar with using chroots, you can also retrieve the root image and chroot into it if you would prefer (after bind mounting /proc, /dev, etc.). We generally prefer not using chroots at this stage however. Once you have followed the setup instructions: 0). Configure /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth* according to your setup. The ones in that image statically assign tenaya.bos.jonmasters.org. 1). Login to your board as root (password is fedora). Change the password if you would like to do so. 2). Become the builder user. You can either su - builder or you can passwd builder, and then login remotely/on the console. 3). Optional, but recommended, use screen -S builder or similar to start a screen session that you can leave running. 4). Run the simple building script: ./arm-rebuild.sh 5). Monitor the arm mailing list. It is likely that a newer version of the builder script will be posted later today or before Monday. When that happens, we may change the SSH keys used in the build image, which would have the effect of forcing everyone to update. The purpose of that being to prevent any existing builders running the older script version. Instructions will be posted for updating a couple files will be posted. Please join us on IRC: #fedora-arm on irc.freenode.org. Further documentation will be provided on the Fedora ARM wiki today, however this email should provide sufficient setup information now. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Follow the instructions contained within the readme file to extract the uboot, boot, and root archives onto an SD Card for your device. These instructions will destroy whatever is already installed. If you are familiar with using chroots, you can also retrieve the root image and chroot into it if you would prefer (after bind mounting /proc, /dev, etc.). We generally prefer not using chroots at this stage however. NOTE: The readme has been updated as of 1pm EDT today to correct a few issues. Please reload it. The current version should work on all OMAPs using x-loader, no matter how finnicky they are about partitioning. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to package GNOME Shell frippery
On Fri, 2011-07-29 at 10:57 +0200, drago01 wrote: Well in gnome 3.2 (which should be out for F16) extensions will be like firefox extensions i.e you go to extensions.gnome.org and click install to install an extension. Distro packaged extensions are frowned upon upstream. So, just so I understand, the requirement/assumption is that all machines will be online and pulling bits down directly from GNOME? That won't map at all to enterprise or non-fully connected environments. It needs to be possible to install/provision a system with this kind of functionality because users are going to want to get these extensions. David: on the subject of your followup...my advice, by the way, is that life is too short to continue to try to explain why GNOME Shell is unusable for folks like you and I. I'd just switch to XFCE and be done with it. My machines are a lot happier for having made the switch :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
No specific armv7hl VFAD today
Hello, I'm traveling this week, so didn't make any specific plans to host the VFAD earlier today. Sorry for not announcing that. Of course, there's no reason to not build and contribute bits by joining us on #fedora-arm at any time, and by following the instructions: http://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Good progress has been made recently. Dennis has succeeded in making a minimal rootfs using the packages built so far, and it even boots :) I don't think it will be too long before we can get a useful buildroot. Unless it proves redundant due to insanely cool rate of progress, there will be another VFAD next week. We may (hopefully) soon be able to transition over to just a standard package building exercise, once we've got the standard Koji infrastructure up and running. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 15th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Last week, we succeeded in reaching a point where we had yum running natively, and after that rapidly went from just under 100 native binary RPMs built to 793 right now! We still do not have all of the dependencies for mock, but we hope to be there soon. We need your help, if you have the time, hardware, and interest in doing so. Together, we can reach a point of running mock, then rebuild all of the packages we have so far natively within a mock, and ultimately have a Koji buildroot sufficient to officially rebuild everything within the standard Fedora ARM Koji infrastructure. You can find a lot more detail here about the stages involved in bringup (we are at stage 3), along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110715 For general bootstrapping series information: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch on the Fedora ARM git repo so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Fri, 2011-07-15 at 03:20 -0400, Jon Masters wrote: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Please note that this has been updated since last week. It now includes all of the information you need for stage3 (current). Further, there is an additional wiki page linked from there with a list of packages that need building. The Etherpad we were using is currently down - don't use that, use the wiki pages instead please. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, 2011-07-10 at 00:48 -0300, Itamar Reis Peixoto wrote: On Sun, Jul 10, 2011 at 12:45 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote: We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. As a followup, we now have a working yum installation. Next week, we will be working on support for mock. Once we have these, we can build up missing dependencies, then rebuild everything we have with rpmbuild. At that point, we can rebuild everything within mock and Koji-fyificate. It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. Meanwhile, enjoy working yum. Next week, working mock, hopefully. I agree, we must have a bootstrapping guide. We're going to deliver one after this armv7hl bootstrap. What we're going to do is get koji running with a minimal mock (or even once we get to just mock) and then re-run the bootstrap scripts automatically/rebuild the RPMs and hope that we caught every customization we needed. Those that were missed will be documented, then everything will be written up. Maybe not Shakespeare, but sufficiently. The wider problem that feeds from this is setting guidance. I'll throw some recommendations out there as a result of the bootstrap, not limited to just the two observations so far. Debian and others have much more comprehensive documentation on this stuff and that needs fixing. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Sat, 2011-07-09 at 23:32 -0400, Steve Dickson wrote: On 07/08/2011 10:57 AM, Lennart Poettering wrote: Or in other words: configuration via command line arguments or environment variables sucks. I disagree. It doesn't suck. It's the way UNIX and Linux have done this for dozens of years, and it's the way countless sysadmins know and love. Sucks might be true from the point of view of hey look at this great thing I just designed, but it's very much not true from the point of view of the sysadmin working on the weekend who's just thinking gee, what the heck is going on, why won't this just work how it has done for the past twenty years?. In other words suck depends on viewpoint. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Sun, 2011-07-10 at 16:32 +0100, Matthew Garrett wrote: On Sun, Jul 10, 2011 at 05:46:18AM -0400, Jon Masters wrote: I disagree. It doesn't suck. It's the way UNIX and Linux have done this for dozens of years, and it's the way countless sysadmins know and love. Sucks might be true from the point of view of hey look at this great thing I just designed, but it's very much not true from the point of view of the sysadmin working on the weekend who's just thinking gee, what the heck is going on, why won't this just work how it has done for the past twenty years?. In other words suck depends on viewpoint. The big kernel lock doesn't suck. It's the way SMP UNIX did things for dozens of years, and it's the way countless kernel hackers know and love. Sucks might be true from the point of view of hey look at this great fine-grained locking I just designed, but it's very much not true from the poit of the driver author working on the weekend who's just thinking gee, what the heck is going on, why won't this just work how it has done for the past twenty years?. In other words suck depends on viewpoint. I get your analogy, and your point. But there's a key difference. In the kernel community (which is relatively much smaller), there are established well documented means by which people find out about things like BKL removal and act upon it. There is LWN, there is LKML, there is an expectation that those working on the kernel read these things. There should not be, and there is not, an expectation that Linux users and admins in the wider world follow distribution mailing lists, wiki pages, and IRC obsessively. Or read blogs. That isn't how it's done. It's done through slow, gradual change picked up over time, unless you want the kind of pain that I believe is coming further down the line. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Sun, 2011-07-10 at 21:59 +0200, drago01 wrote: On Sun, Jul 10, 2011 at 11:46 AM, Jon Masters jonat...@jonmasters.org wrote: On Sat, 2011-07-09 at 23:32 -0400, Steve Dickson wrote: On 07/08/2011 10:57 AM, Lennart Poettering wrote: Or in other words: configuration via command line arguments or environment variables sucks. I disagree. It doesn't suck. It's the way UNIX and Linux have done this for dozens of years, and it's the way countless sysadmins know and love. Sucks might be true from the point of view of hey look at this great thing I just designed, but it's very much not true from the point of view of the sysadmin working on the weekend who's just thinking gee, what the heck is going on, why won't this just work how it has done for the past twenty years?. In other words suck depends on viewpoint. Well really it is perfect because it has been like that for $num years, how dare you change it is a very weak argument. Did I say it was perfect? No. Therein lies a confusion. There are many things that, were they designed now, would be done differently (and I'm sure if you tracked down the original inventors of many things they would have horror stories about how assumptions outlived designs). But once you have several decades of something deployed in the field, you can't just come overnight (where that is relative - compared to several decades, 6 months or even 2 years is overnight) and say what we have is better, deal because that's damned expensive from a successful product point of view. If we want people to use Fedora, and other Linux distributions in general, they can't have to throw out their books every couple of years and re-learn the very basics. Conversely, you can change this stuff, but you have to expect it to take *many years* to get there. It has no meaning at all from a technical pov. It is just I am to lazy to learn something new ... but one should really expect sysadmins to be able to keep up with changes like this. This point goes to the heart of why Windows is still so popular and successful in the marketplace. It's unfortunate, but the real world doesn't move as quickly as we would like it to do so. If it were just about technical arguments, everyone, everywhere would have been running Linux for the past decade or more, and everyone would jump at the awesomeness (technically) of some of these things. But the reality is that people are slow to change, organizations are slow to adapt, and people told hey, what you've been doing for several decades is wrong don't react well. That's what leads to rocking chairs on front porches. It's not that they're against you, it's that they're faced with having to use something that's fundamentally changed on them overnight. You don't have to take my advice or opinion, it's just that. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, 2011-07-10 at 16:23 -0500, Matt Domsch wrote: On Sun, Jul 10, 2011 at 04:43:30PM +0100, Matthew Garrett wrote: On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. This has been raised with FESCO in the past, and I don't think there's any fudnamental disagreement on it. But scheduling one mass rebuild per cycle doesn't prevent us ending up in a broken state unless we do it right at the end of the cycle, and right now that's problematic in terms of release process - rebuilding everything we've just QAed is an excellent way to introduce subtle breakage. So it really needs to be an out-of-archive verification rather than one that's targetted at the release, and we need the resources and manpower to handle it. Alternately, we could take a lesson from our compatriots at openSUSE. Their openSUSE Build Service throws a combination of automated intelligence and hardware at the problem. Given the package dependency tree, if package B BuildRequires package A, then every time A gets rebuilt, B is also bumped and rebuilt. This is, in my opinion, the correct way to solve the problem. You can't really know if something FTBFS unless you do this kind of thing. I'd go further and advocate for sufficient hardware to continually rebuild everything daily and automate bootstrap like Debian are looking into, but that's all stuff for the future. This causes build breakage to get caught fairly early in the process (rather than via an asynchronous out-of-tree process), and the resulting packages are available in their equivalent of the rawhide tree for test and use. It doesn't just benefit bootstrap either. Take (random example) the recent CFLAGS change in redhat-rpm-config. What should happen at that point is that every package is automatically rebuilt. Should it cause a problem? No. But having packages randomly fail to build later because of some change made months or even years earlier is something to fix. I know I'm preaching to the choir here. There are many reasonable reasons why some of these problems exist, and it's no failure on the part of rel-eng folks, who do their best. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, 2011-07-10 at 22:44 +0100, Matthew Garrett wrote: It's certainly true that we could do more to identify ftbfs situations earlier, but we've had mass rebuilds in most recent releases. Random failures years down the line really aren't a realistic concern. I can think of specific cases where dependent packages failed to rebuild 6 months later because of an earlier change, and I'm sure we can find some involving years at a time. Further, there are some noarch packages that haven't been rebuilt in many releases, but that's another issue. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote: We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. As a followup, we now have a working yum installation. Next week, we will be working on support for mock. Once we have these, we can build up missing dependencies, then rebuild everything we have with rpmbuild. At that point, we can rebuild everything within mock and Koji-fyificate. It's becoming clear that several points do need raising with FESCo: * Fedora should (IMO) institute mandatory mass rebuilds. Either every cycle, or every other cycle. I've briefly discussed with Dennis. Bootstrapping (and similar activities) are far easier with a clean set of deps, which is the case for F15. It should always be the case that we know everything builds and self-hosts through a mass rebuild per cycle. * Fedora would benefit from an explicit position on the dependency explosion we're seeing in basic packages. Without going off too far into my personal opinions on a need to respect UNIX heritage, etc. I will say that the explosion of requirements is going to be a problem for any future efforts and will get worse without guidance. Meanwhile, enjoy working yum. Next week, working mock, hopefully. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
[ removing extraneous copy of old Fedora devel list ] On Fri, 2011-07-08 at 09:57 -0400, Steve Dickson wrote: On 07/08/2011 08:23 AM, Lennart Poettering wrote: I am pretty sure systemd-devel is the better place to discuss this. But here are a few comments after reading throught the bug report: I didn't know it existed... My $0.02 on this is that this conversation *explcitly* *does not* belong on systemd-devel. I subscribed to that list to monitor for such conversations, but most people aren't going to do that. Problems with Fedora packaging, in the Fedora distribution should be discussed here. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these remain on Fridays, and at the same time. Last week, we succeeded in reaching a point where we have a native RPM (and therefore rpmbuild) running, and we are therefore now entering what we call stage3 (stage1 was cross-compilation, stage2 was limited native building from the sources) in which we can build packages natively. Dennis has made some progress building python and a priority will be to get native packages built sufficient to have a python RPM. Once we have python, we then get to yum, mock, and finally Koji. At that point, we just have to rebuild everything twice more (once in rpmbuild, then use those bits in a full koji) before we can build the many more packages we will require for a self-hosted system! Lots of fun! :) You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110708 That page contains links to the general instructions on (note that documentation on stage3 is being updated, by me, at the moment - the above link has some notes sufficient for Friday, but these will be incorporated into the generic instructions I link to below): https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
Hi Folks, Join us on Friday to celebrate July with another in our series of VFADs! This is an awesome opportunity to participate in improving support for ARM processors, and to learn about architecture bootstrap. Last week, we successfully added a number of new packages to our bootstrap filesystem image and got closer to having a working F15 environment we can use to build official RPMs with hard floating point, on ARMv7 systems. It's never too soon or too late to help, and you can participate at any time, by following the instructions linked below - no need to wait for us, just let us know when you've got bits we can pull into the official rootfs (which is managed in git) we are building to bootstrap the rest. Don't forget that you can find out a lot more about the Fedora ARM project, and about getting involved by visiting the wiki: http://fedoraproject.org/wiki/Architectures/ARM Which also contains links to canned images you can use to drop onto your own ARM system and hit the ground running without any installation time. Awesomeness! Jon. --- Fedora ARM hardfp activity days --- We are hosting another Fedora 15 hardfp Virtual Fedora Activity Day on Friday, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these be on Fridays. You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110701 That page contains links to the general instructions on: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Wed, 2011-06-29 at 09:14 +0200, Nikola Pajkovsky wrote: Refreshing news! What is pain in the ass is rhel6, because it doesn't have qemu-system-arm. I will play around with rhel6 and qemu-system-arm. Then I will try to build my packages for arm (if already aren't in). Is there a list of built packages? If you are internal, ping me and I can make available access to a couple of PandaBoards to save building up emulation bits (should be available ahead of Friday but not available yet). We're trying to do this natively, though I've nothing against using qemu if you'd like :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Wed, 2011-06-22 at 00:36 -0400, Jon Masters wrote: We are hosting another Fedora 15 hardfp Virtual Fedora Activity Day today, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these be on Fridays. You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110622 That page contains links to the general instructions on: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Please pull and rebase to ensure you are using the stage2/recipe.d split out build recipes for your branches/pull requests. This was just changed over in the last few minutes, but it is a much easier approach. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
Hi Folks, We are hosting another Fedora 15 hardfp Virtual Fedora Activity Day today, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Going forward, the proposal is that these be on Fridays. You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110622 That page contains links to the general instructions on: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
SUMMARY - [Fwd: Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY]
---BeginMessage--- On Fri, 2011-06-10 at 04:51 -0400, Jon Masters wrote: We are hosting a Fedora 15 hardfp Virtual Fedora Activity Day today, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110610 This activity day was completed to our overall satisfaction. At the end of the day, we had an additional dozen or more packages built and had derived a workflow for addressing the remainder of the bootstrap. We plan another followup Virtual Fedora Activity Day as follows: * Wednesday June 22nd 2011 - 14:00UTC (10:00EDT) For further information about how the day went, see: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110610 To participate further in this activity, refer to this: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Jon. ___ arm mailing list a...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ---End Message--- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY]
---BeginMessage--- Hi Folks, We are hosting a Fedora 15 hardfp Virtual Fedora Activity Day today, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). You can find a lot more detail here, along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_Virtual_FAD_20110610 Jon. ___ arm mailing list a...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ---End Message--- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]
On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote: On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler ch...@tylers.info wrote: On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote: [0] We're making a one time incompatible ABI switch in F-15 bringup to the hard float ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really. And to further clarify: - This is an addition, not a switch -- the intention is to continue to support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel. Err Tegra should be supported due to the use of vfpv3-d16? Correct? Right. v7 based Tegra parts will be supported by virtue of the vfpv3-d16 ABI (some newer VFPv3 parts have 16 additional optional registers not required by the minimal implementation we are basing upon in Fedora, intentionally, for ABI linkage, so that there's no break again). Don't worry about NEON, that's not something we're actively looking at yet, and when/if it does happen, it'll be implemented using caps to provide optimizations in certain places - it's not required or part of the ABI. Basically, if it's a properly implemented ARMv7 part it should be supportable by the hardfp port. One of the the things that has happened in recent times is the move toward much more standardized minimal hardware features that can be generically targeted. I believe this is a trend that we will see continued. Standardization is a good thing :) In case it helps Gordan and anyone else: 1). We're talking about a minimal configuration for hardfp. Assuming: - Cortex A(8) profile ARMv7 compatible parts and later - Presence of a VFPv3 unit (inferred from above) with the 16 double registers (-d16, not -d32) as required by ARM AAPCS section 6 variant (hardfp) - Intentionally standardizing on the 16 register minimum. The only item up for (some) discussion seems to be use of Thumb2. Builds so far have been having problems when turning on T2. For various reasons, I'm not particularly desperate to see us build with T2. A todo of mine is to confirm that the GCC interworking trampolines mean it doesn't matter and we can make changes to have some T2 bits later (which is how I understand that this should be working, but I want to verify by spending some quality time with objdump and a few compiled libraries). 2). NEON is ARM's SIMD (answer to SSE/AltiVec/etc.). It shares registers with VFPv3 (not totally unlike other arch's implementations). It's not a part of the core ABI we are discussing. We have not discussed any specific NEON plans up to now, other than it might be nice sometime to have NEON optimized libraries and so forth. Hope that helps! Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Does anyone care about LSB on arm?
On Sat, 2011-06-04 at 01:32 -0400, Jon Masters wrote: On Wed, 2011-06-01 at 12:25 +0100, Luke Kenneth Casson Leighton wrote: sooo... although the situation *right now* is that nobody in the commercial world is the slightest bit interested in LSB because they all do custom builds of complete software stacks, it could be said that *if* the free software community just dropped ready-to-go LSB standards in front of their noses, they'd quite likely use it. The reason we're discussing this is because a new architecture isn't going to be supported in standards like LSB overnight. It might take some time, and by that time, things may have changed with respect to the adoption of ARM systems. But if we don't think ahead, we're forced to be reactionary and try to do this (probably less effectively) later on. Nobody will be forced to adopt LSB, but general purpose distributions can benefit from having compatibility at the software level. Is this an issue for deeply embedded platforms? Not so much. Is it bad that Android rebuilds the Universe? It's their decision to make. I think we need to distinguish between traditional embedded uses of ARM parts, which will continue, and those of larger parts running general a purpose OS. I don't expect to see Fedora running on my cellphone, but I do have it running on a netbook quite nicely - the latter needs LSB more. I'll leave the rest of the rhetoric alone :) Further discussion will be copied to arm@ and not necessarily here (unless someone includes the devel@ on CC) so please do sign up there if you are interested: https://admin.fedoraproject.org/mailman/listinfo/arm I just forwarded some more notes on LSB additions for ARM. A great deal of other standardization work is ongoing at the moment, and I'll forward some more stuff to ARM list in due course. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: [fedora-arm] Activity Day June 10th - ARMv7 F15 hardfp bringup]
Folks, If you're interested in getting involved in the armv7hl[0] bringup, please do subscribe to the ARM list and follow along/join us Fri for the first of what will hopefully be several sessions dedicated to bootstrap of F15 hardfp bits, followed by building the universe around those. Jon. [0] We're making a one time incompatible ABI switch in F-15 bringup to the hard float ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really. ---BeginMessage--- Hi Folks, We're planning to have an activity day of sorts on this coming Friday, the purpose of which is to sync up and co-ordinate the various efforts to achieve working ARMv7 hardfloat support for Fedora 15 bringup. The venue is #fedora-arm, and also using a dialin number (to be provided) for those who want to discuss topics over the phone. I believe most of us are geographically located in the US, so I am suggesting we could begin about 10:00EDT, which is 14:00UTC. Here's an initial agenda that I think covers some of the important stuff: 1. discuss requirements/sync up on build flags 2. current status of works in progress (DJ/Dennis/Seneca(?)?) 3. minimal dependency discussion for F15 (xdeb-graph equiv. needed) 4. plan for building/co-ordinating builds (host bits at Seneca?) 5. get stuff building (spend most time building/fixing packages) 6. status before end of day 7. plan for followup My assumption is that we'll consolidate the various activities begun so far, establish a plan for ongoing dialog, and hopefully decide on a way to host builds (pre-Koji) and so forth in a public Seneca environment. Chris seems quite amenable to allowing machines to be used to build bits, and I think I would like that in general if we can do so (perhaps setup a staging mount where people can build packages and poke at bits?) The main outcome I'm looking for is that we don't have stuff happening in different silos, know what everyone else is working on, etc. Jon. ___ arm mailing list a...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ---End Message--- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: [fedora-arm] Activity Day June 10th - ARMv7 F15 hardfp bringup]
On Sat, 2011-06-04 at 21:10 -0400, Chris Tyler wrote: On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote: [0] We're making a one time incompatible ABI switch in F-15 bringup to the hard float ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really. And to further clarify: - This is an addition, not a switch -- the intention is to continue to support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel. - The significant incompatibility is hardfp vs. softfp ABI (moreso than v7 vs. v5). Thanks. Indeed, my separate arch comment is really that v7 (with assumed hardfp that will be the case in the form of ABI used) and v5 without hardfp do not use the same ABI calling convention. But for simplification, I called them different arches. We'll keep v5 around. I think longer term, it probably makes sense to kill it off once people have moved to newer boards/systems (like older versions of IA32 have been killed off over time). But again, that will depend on who is using v5, etc. over time. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Mon, 2011-03-28 at 14:47 -0400, Jeff Garzik wrote: end, I gave up and used a system without NM or any of the other stuff, That's the right answer: simply turn off NetworkManager and turn on the network service, to prevent these new breakages from occurring. I do that for all the machines in my test lab. For clarification, I usually do have NM_CONTROLLED set for every interface, except on laptops. In this case, I just wanted to instead turn off NetworkManager and configure the interface manually. I see no reason why it shouldn't be possible to tell a system service to stop and expect it to stay stopped until I turn it back on again. That way, I can tell NM to shutdown, do something I need to do, then get the prettified laptop experience back again when I'm done (on the netbook). This was all to tftp various firmwares over to routers I was playing with over the weekend. Soldering surface mount bits, placing wires, and poking at serial consoles and firmware setup was trivial. The hardest bit was telling a system service to stay stopped :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
manually fixing IPs
Hello, So, back in the good old days, one could just type this: ifconfig eth0 some_temp_ip up Then it became necessary to: /etc/init.d/NetworkManager stop Then it became necessary to: systemctl disable NetworkManager.service Just to try to get the interface left alone. But when the link it's attached to drops, the settings are immediately being dropped and the interface unconfigured. So, what have I missed? What's the other thing that's trying to be all helpful but actually preventing me from running TFTP usefully? Sure, I could plug it into a switch and go all Windows 95 on this, but...I'd rather not. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 12:10 +0100, Michel Alexandre Salim wrote: On 03/26/2011 12:05 PM, Jon Masters wrote: Then it became necessary to: /etc/init.d/NetworkManager stop Then it became necessary to: systemctl disable NetworkManager.service The last two are equivalent to service NetworkManager stop, which still works even with systemd. Nope. It doesn't :) I tried that, and as I said, NM restarted immediately. The only way to stop it was to disable the service, and even then something was unconfiguring the port on link loss. Argh. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 12:23 +0100, Reindl Harald wrote: Nobody stops you to disable Network-Manager, DHCP, AVAHI and the other noob-crap and write your /etc/sysconfig/network-scripts/ifcfg-eth0 manually as i do everytime directly after the first boot and i guess the next 20 years this will be the same on a unix-like system Right. This is exactly what I do on non-laptops. But I find NM useful for WiFi sometimes so I keep it installed...but now it seems it's becoming very difficult to just temporarily configure an interface that won't be touched when I plug/unplug a cable or whatnot. Really, there should be a better way that turning off every network service and script for the 5 minutes I want this. I have other machines, etc. and this is rawhide, but it's also the future. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 11:03 -0400, Neil Horman wrote: IIRC you can set: NM_CONTROLLED=no in /etc/sysconfig/network-scripts/ifcfg-ethX Supposedly that will take ethX off the reservation and allow you to use the ifup script and ifconfig utility as you traditionally would. I remain unconvinced that in rawhide it's possibly to truly instruct all these wonderful bells and whistles to leave an interface alone. In the end, I gave up and used a system without NM or any of the other stuff, since turning it off for a few minutes was getting too involved. On that other system, adding a manual ARP entry and an interface alias with another IP stuck, didn't change randomly, and did what I wanted. Not very web 2.0 I know, but I like it that way. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On Sat, 2011-02-26 at 17:33 -0500, Lyos Gemini Norezel wrote: On 02/23/2011 04:37 PM, Kevin Kofler wrote: And I'd like to counter-counter-propose that we just stop using ANY kind of subvolumes or volume management by default and just default to plain old partitions. IMHO, LVM causes more problems than it fixes. Sure, you can easily add storage from another disk, but in exchange there's no straightforward way to resize your partitions, at least none of the common partition editors can do it. There's also a performance penalty. +1 This subvolume nonsense has no real place on any home computer/consumer device. With all due respect, that's the path chosen by certain other Linux distributions (ones where if I install them I have to jump through all kinds of hoops to turn on LVM). That is not the way we should be going. I've made my objections known, added a comment on the wiki discussion for the feature, and will raise an objection at the appropriate time that it is proposed to drop LVM use by default. Until then, I'm done :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On Wed, 2011-02-23 at 07:15 -0500, Josh Boyer wrote: On Tue, Feb 22, 2011 at 10:25 PM, Jon Masters jonat...@jonmasters.org wrote: On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote: 2) Fedora 16 ships without LVM as the volume manager and instead use BTRFS's built in volume management, again just for the default. In my personal opinion, this is a poor design decision. Yes, BTRFS can do a lot of volume-y things, and these are growing by the day, but I don't want my filesystem replacing a full volume manager and I am concerned that this will lead to less testing and exposure to full LVM use within the Fedora community. Instead, I'd like to counter-propose that everything stay exactly as it is, with users being able to elect to switch to BTRFS (sub)volumes if they are interested in doing so. Should the switch to BTRFS by default happen, this will be one more thing I will have to fix immediately during installation. The list grows longer and longer over time - please don't make this change. You seem to spend a lot of time during your installs undoing all the new things that were done for the release. Perhaps a rapid changing, bleeding-edge distribution isn't quite suited to your needs. Maybe you would be more comfortable with Debian or CentOS? I'll bite. I am, indeed, a fan of various Enterprise Linux distributions and I make no pretense that I am not. I do run an Enterprise Linux on one desktop, and it's also true that I intentionally run my primary desktop several Fedora releases behind so as to avoid many of the problems I see from some of these changes. However, I also run more recent Fedora releases, and on those releases, I typically have to undo changes such as the one originally being proposed (replacing LVM). Again, I feel the solution is to have a Fedora architect whose role is to realize the problems caused by seemingly isolated changes, and stop them from propagating. You don't just replace years of UNIX (or Linux) history/heritage overnight without bothering a chunk of the users. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote: 2) Fedora 16 ships without LVM as the volume manager and instead use BTRFS's built in volume management, again just for the default. In my personal opinion, this is a poor design decision. Yes, BTRFS can do a lot of volume-y things, and these are growing by the day, but I don't want my filesystem replacing a full volume manager and I am concerned that this will lead to less testing and exposure to full LVM use within the Fedora community. Instead, I'd like to counter-propose that everything stay exactly as it is, with users being able to elect to switch to BTRFS (sub)volumes if they are interested in doing so. Should the switch to BTRFS by default happen, this will be one more thing I will have to fix immediately during installation. The list grows longer and longer over time - please don't make this change. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote: On Tue, 08.02.11 04:44, Braden McDaniel (bra...@endoframe.com) wrote: I'm not sure whether 1 means it is or it isn't; but system-config-services claims it's enabled. s-c-s only covers sysv services. We probably should deprecate it or at least add a bit of code to point out that whether a service is on or off in sysv is ignored for native systemd services. What utility are you recommending to replace it? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager doesn't start on boot
On Tue, 2011-02-08 at 11:27 +0100, Lennart Poettering wrote: On Tue, 08.02.11 05:18, Jon Masters (jonat...@jonmasters.org) wrote: On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote: On Tue, 08.02.11 04:44, Braden McDaniel (bra...@endoframe.com) wrote: I'm not sure whether 1 means it is or it isn't; but system-config-services claims it's enabled. s-c-s only covers sysv services. We probably should deprecate it or at least add a bit of code to point out that whether a service is on or off in sysv is ignored for native systemd services. What utility are you recommending to replace it? Well, systemadm does some of this stuff, but doesn't really do enabling/disabling of services, and also needs some love. I guess my answer is to use systemctl enable foo.service and systemctl disable foo.service until somebody comes up with an UI for this (if one is actually needed). My point is that if there's a GUI config tool today, there should be one tomorrow. Even when in curses, it's nice for some users after install to be able to configure this stuff with a menu. And none of those users who want a config tool are going to care that upstart was replaced, etc. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide woes
On Fri, 2011-02-04 at 03:09 -0500, Felix Miata wrote: On 2011/02/04 01:26 (GMT-0500) Jon Masters composed: On Thu, 2011-02-03 at 18:04 -0500, Felix Miata wrote: I tried to net (minimal) install 40 hours ago and got no initrd and thus no boot. Culprit was less not installed. I made a working initrd via chroot and yum install less. Still when done, ethX cannot be found, so I have no network except via chroot, and even then after installing X and KDE, yum gives errors about installed packages not actually being installed. Can you run: $ /sbin/ifconfig -a And let us know if you are seeing differently named devices, or if they are simply outright missing? Thanks. If you had asked 30 or more minutes sooner I could have, but I installed again and got a much bigger nearly unbootable mess trying to install more than minimal. Anaconda installed 660+ packages, then aborted before setup finished, without installing any of Grub. I can boot off other installed Grubs, but only to single, and if I do ifconfig -a from runlevel 1 the only result is multiple screens of segfault info. Possibly http://fm.no-ip.com/Tmp/Linux/F/anaconda.ifcfg.log from the earlier install has what you want. Logs from the 1AM install are also in http://fm.no-ip.com/Tmp/Linux/F/ . (replaced anaconda.ifcfg.log with anaoconda.ifcfg.txt when looking) Looks like your system is attempting to name devices according to PCI slot. What is the hardware that you are running? I doubt it'll be possible to debug the network issue further without some kind of minimally working install. FWIW, I bought a dedicated cheap netbook to test rawhide since I don't want this hassle anywhere else - means stuff breaks, but my desktop is happily running Fedora 13 :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide woes
On Thu, 2011-02-03 at 18:04 -0500, Felix Miata wrote: I tried to net (minimal) install 40 hours ago and got no initrd and thus no boot. Culprit was less not installed. I made a working initrd via chroot and yum install less. Still when done, ethX cannot be found, so I have no network except via chroot, and even then after installing X and KDE, yum gives errors about installed packages not actually being installed. Can you run: $ /sbin/ifconfig -a And let us know if you are seeing differently named devices, or if they are simply outright missing? Thanks. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Rawhide Test Day for Network Device Naming on January 27th 2011
On Wed, 2011-01-19 at 22:30 +0530, narendr...@dell.com wrote: The objective is to test the new naming scheme for onboard and PCI add-in network interfaces as suggested by 'biosdevname' utility. It would be great if you could participate and provide your feedback which would help us flush bugs. Cool. I will be there. I have an R610 I've borrowed to do some testing of these features in general, and will attempt to borrow an R710 too. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
On Fri, 2011-01-14 at 16:51 -0600, Matt Domsch wrote: It took my build system 96 hours to build all of rawhide (10k packages) for both x86_64 and i386. Builders are 10 Dell PowerEdge 1955 servers, each with 2 sockets 3GHz Xeon 5160 CPUs (4 cores each), 8GB RAM. Builders running Fedora 14. OOI, do you sequentially build one package at a time on a builder, or do you do parallel builds? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
On Sat, 2011-01-15 at 19:54 -0500, Matthew Miller wrote: On Sat, Jan 15, 2011 at 04:49:37PM +0100, Tomasz Torcz wrote: A slowdown by a factor of 4 is a high price to pay for the impact of RemoveSUID. I'd rather pay at most 30%, and not a factor of 4. That's the extreme corner case, caused by bug in tmpfs (lack of filecaps?). Upstream kernel bug, I would say. Lack of a feature isn't a bug. Not to be an antagonist, but I still see no rational reason to remove setuid and replace it with this alternative implementation wholesale at this time. UNIX got away with setuid for a *long* time, and I'm sure we could have managed for another year (or 30) without a big switchover. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide: Gnome totally busted after today's (?) round of updates
On Wed, 2011-01-12 at 20:12 -0500, Matthias Clasen wrote: On Wed, 2011-01-12 at 17:34 -0500, Andy Lawrence wrote: Is there a package we can down-grade to get back up and running? Or an update via Koji? With the gnome-shell, gjs and gobject-introspection builds that are in koji now, things should be much better. At least on my system, things work fine again. So that presumes a switch to the Shell? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Wed, 2010-12-15 at 22:25 +0200, Ville Skyttä wrote: Files marked as documentation must not cause additional dependencies that aren't satisfied by the package itself or its dependency chain as it would be if none of its files marked as documentation were included in the package. Doesn't this exclude things like man pages, since they need a man page formatter to display them that would not be required were those docs not included in a package? If so, it seems like an excessive limitation. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Wed, 2010-12-15 at 23:57 +0200, Ville Skyttä wrote: On Wednesday 15 December 2010, Jon Masters wrote: On Wed, 2010-12-15 at 22:25 +0200, Ville Skyttä wrote: Files marked as documentation must not cause additional dependencies that aren't satisfied by the package itself or its dependency chain as it would be if none of its files marked as documentation were included in the package. Doesn't this exclude things like man pages, since they need a man page formatter to display them that would not be required were those docs not included in a package? If so, it seems like an excessive limitation. I thought about adding something that if there's a concern that people will try to abuse the above guideline for something, some refinements could be added, but I believe people are capable of applying common sense. But if someone can plug this potential loophole in the text and still keep it understandable, please feel free to rephrase it. But how many packages nowadays require a man page reader simply because they install man pages? Well, since it's a guideline, it's worth discussion. Sure there's only 18 in your list, but that sounds more like a bug than a feature. Similarly, for docs in HTML format we could probably do with some kind of dependency suggestion (I'm not sure what the Fedora version of RPM recommended way of doing dependency level suggestions is now). I would think that would be the ideal, to recommend these things but not require them to be installed if it's just documentation files. I think the policy should be to somehow recommend the additional bits, then you can add but not require in place of the existing wording. Anyway, what is the current Fedora RPM way of doing suggestions? I've seen this stuff in SuSE, and other package managers (including RPM). Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Tue, 2010-12-07 at 20:29 -0600, Matt Domsch wrote: My goal isn't to make life difficult for everyone. My goal is to keep the distribution in a form where it can actually build from the open source we provide. Thanks Matt. What you're doing is vitally important for the distribution, since it should build from source always. You do a lot of great work in this area and I hope you continue for a long time! :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Mon, 2010-12-06 at 23:01 -0600, Matt Domsch wrote: I trust module-init-tools will get resolved with an impending upstream release. Not like that can go unfixed forever. :-) Should be fixed before Wednesday (tomorrow). I have some fixes for compressed modules too. Will let you know when this is resolved. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, 2010-11-30 at 16:29 -0600, Michael Cronenworth wrote: Matt Domsch wrote: Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names. specifically, em0 for the above device, and emType Instance for the second NIC specified in SMBIOS... OK. Perhaps the wiki should be updated to state the feature works more generically (SMBIOS 2.6+) and not for just Dell/HP systems? +1 And also, I'd love to see fewer attacks on Dell here. Matt is doing good work that is generic and uses open standards that can be implemented by many vendors. The fact that some have yet to move on SMBIOS struct type additions reflects on them alone. Interesting work, Matt. I'm surprised the Unix purists who would fight you to death to keep sendmail on desktops would allow you to change the almighty eth* naming scheme. Because it makes *sense* and is in keeping with UNIX tradition on many systems. I'm all for making all manner of changes when there is a justification that is rationalized and the benefits can be explained. When it's hand wavy this is good type stuff, I feel different :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
