Re: conclusion: F15 / systemd / user-experience
On 06/14/2011 05:57 AM, Somebody in the thread at some point said: Fedora could well benefit from switching to a rolling release model as well (no not rawhide - a controlled rolling release much as the kernel development follows). I've been living from rawhide on my main laptop for a few years, from my POV the existing setup where rawhide never stops and it branches off before the release is ideal already. I sometimes get the equivalent of a crossword puzzle to do on the next boot after an update to get it up again, but at least it keeps me aware of major developments. Since the upstream projects never stop either, capturing that reality in rawhide in packagable form as a first step all the time seems like it must be part of a good solution. BTW I am very happy someone is grasping the nettle of sysvinit, keep up the good work everybody! -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 11:17 AM, Somebody in the thread at some point said: Hi - Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. And you pitch systemd to be used by embedded devices. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! IPv6 is optional though, Lennart says you can blacklist the module. If it acts gracefully if IPv6 is not builtin or installable by module then all is well. Embedded as an argument needs a lot of care. It means several very different things, but many of those things are out of scope for Fedora, eg, ARM7. (Use busybox there ^^) For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. So while it's super healthy to press system tools on bloat, it is quite possible to deploy the Embedded argument to go too far and conflict with what Fedora is and trying to do overall -- and what other Embedded guys will want from it in future. Embedded is generally converging towards the kind of full strength systems we use on x86 today. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 11:43 AM, Somebody in the thread at some point said: For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. I talk to a lot of embedded people. Tiny machines are not going to disappear anytime soon - they just go into smaller and smaller gadgets. Me too... I think maybe considerations valid at the low-end devices you know very well are blinding you a bit to how applicable those considerations are, eg -- For example, there are still a noticeable segment of NOMMU CPUs, meaning if you really target embedded, you need to learn how to live with vfork only. ... NOMMU and ARM7 that can't run Fedora are to discussions about architecture of Fedora. You can't just handwave embedded away by assuming that embedded will get big enough for me to not really care about optimizing for size. My point was that pressure against bloat is good. But when I look at compromises made in stuff commonly used in ARM7 / cross world, I wouldn't want to see that happening in Fedora in the name of a debloating jihad that simply doesn't matter on most of the platforms it targets. Still, I hope this thread at least reminded people that it doesn't hurt to have a modest memory footprint ^^ -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
headsup: rawhide 3.0 kernel needs symlink
Hi - Maybe it's common knowledge already but the 3.0 / 3.0.0 thing has led to the uname -r of the kernel not matching the packaged module path. Your boot will be a bit minimal until you stick a symlink in along the lines of -- ln -sf /lib/modules/3.0-0.rc1.git0.1.fc16.x86_64 /lib/modules/3.0.0-0.rc1.git0.1.fc16.x86_64 -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC15 beta testing result by my 76-year old uncle
On 04/23/2011 08:46 PM, Somebody in the thread at some point said: Hi - I've setup FC15 beta for my 76-year old uncle. The major issues encountered: * wake up from suspend didn't work on his laptop; on another one does I thought my suspend was broken on this laptop. But it turned out it is hit by a bug where the driver (nouveau) tries to reload firmwire in its resume code while userspace is still frozen. That fails, but only after sitting there looking dead for 60s. After the timeout, it resumes great. So it might be worth trying. * logitech quickcam express doesn't work -- light goes on in Cheese/skype, but not image I don't know about it specifically, but when I use my USB microscope I use Camorama. Notice though it has no UI to select device, you have to give a switch --device=/dev/video1 on commandline if it's not the first video device. It also might be worth a try. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Adding ARM Cross generation patch to gcc and binutils specfiles
Hi - Building on the work of Lennert Buytenhek and David Woodhouse I recently uplevelled the spec files for gcc and binutils they did for gcc-4.1.2 and binutils-2.17.50.0.18 to work with recent rawhide gcc and binutils. The goal of the spec changes is to allow rpmbuild to also build cross gcc and binutils packages which can co-exist with the normal host ones, it makes it easy then to build cross kernels or bootloaders which may otherwise be difficult when your native system doesn't work yet ^^ The patched spec files need to be built like this: $ rpmbuild -ba --define binutils_target armv5tel-redhat-linux-gnueabi rpmbuild/SPECS/gcc.spec # rpm -i rpmbuild/RPMS/x86_64/armv5tel-redhat-linux-gnueabi-binutils-2.20.51.0.12-2.fc15.x86_64.rpm $ rpmbuild -ba --define=cross_target armv5tel-redhat-linux-gnueabi rpmbuild/SPECS/gcc.spec The binutils patch is simple and small (against binutils-2.20.51.0.12-2.fc15): http://warmcat.com/binutils-cross12.diff The gcc patch (against gcc-4.5.1-5.fc15): http://warmcat.com/gcc-cross12.diff is not small or selfcontained and may have some rough edges, but it works to build functional cross packages that don't conflict with the host install so its heart is at least in the right place or, best from my point of view, the patch can be cleaned and merged with the normal gcc spec. I see Hans looks after arm-gp2x-linux-gcc which is also stuck in a gcc-4.1.2 timewarp that maybe my uplevelled patch can also help. Maybe Jakub and Hans could eyeball the patches and see if there is a path to allowing cross packages going on just by rebuilding with the right rpmbuild parameters. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Putting cross compilers into Fedora
On 09/01/10 16:29, Somebody in the thread at some point said: Hi - What are the use cases for the cross-compilers? If these are to compliment the Fedora secondary archs, then compiling kernels is probably the main use of cross-compilers -- for example, on ARM, devices often need a custom kernel to go with a standard rootfs. Once you're up on the device, you can build there, or you can use koji. It's a principle of secondary archs that packages are built natively, either on hardware or in emulation. On the other hand, if you're trying to cross-compile userspace, that's a whole different thing -- a lot more work, and perhaps much less needed. From using the ARM Fedora Cross Compiler stuff David and Lennert did, I think this comment is very much to the point. The cross stuff was really valuable for providing a standardized way to build and develop bootloader and kernel. But for everything else, it was simpler and more reliable to do it on the device itself in its real environment in terms of dependencies, not least you only have one world to manage there. So the big win is just having cross-gcc and binutils; any more than that it grows into trying to handle build and management of cross-everything which is better done native anyway. (Would particularly love to see a cross MIPS packageset...) -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/13/10 11:46, Somebody in the thread at some point said: On 03/13/2010 11:52 AM, Ville-Pekka Vainio wrote: pe, 2010-03-12 kello 15:20 -0800, Jesse Keating kirjoitti: As Fedora is the distribution I'm most familiar with, I've also installed it on some of my family members' systems but lately I've been considering switching those to Ubuntu once the new LTS release comes out. You actually want a different distribution, likely a Fedora LTS, not current Fedora. Unfortunately, Fedora's leadership repeatedly had brushed off a Fedora LTS as unmaintainable and redirected people to CentOS. But they're right to say it's unmaintainable in the long term aren't they? You said yourself in your impressive summary I agree with: * Backporting might be simple in some cases, but it might not be possible or uneffective in others. What are people meant to do when they commit to stability in the sense of not uplevelling things and introducing new code, and then find that backporting is not possible or uneffective? It's fair to imagine that the upstream and its lib dependencies' HEADs won't stay similar to whatever it is that was released in most cases just to make life easy. Then the workload is increasingly nontrivial or impossible as the codebases diverge. Is the effort and personpower poured into trying to hold the line at some arbitrary release not in the end better poured into moving things forward and improving them? I don't ask it idly or without understanding the value of stability at the end user, we will be shipping very large numbers of embedded devices where updates must not trash or damage the user experience. I am just wondering if the focus on backport-based stability is in the end illusory and doomed. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot rely on /dev being present in %post scripts?
On 08/14/2009 10:20 AM, Somebody in the thread at some point said: It's been pretty common since forever for various scriptlets to redirect output of stderr/stdout to /dev/null, so I think it'd be a bit of an ugly mess if there was a mandatory packaging rule you couldn't use at least /dev/null I hope post scripts wont have to test for /dev/null and create a device node for it if it isn't present, before redirecting to it. ;o) You could use mknod to create a workable /tmp/dev/null if it was the idea, satisfying any dependency locally. Some magic /sys dir that always satisfies anything eg, /sys/device_node/1_3 could solve it as well. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/12/10 00:45, Somebody in the thread at some point said: If you are the user, then you should not be compiling software. :-) You should be using some repository and that repository is responsible for rebuilding the package. I tend to agree with what you have been writing but this seems wrong. I don't think I'm the only person who is using Fedora as a basis for homegrown apps, if what I want isn't in Fedora (because I am creating it locally) then I certainly will compile software as a Fedora user and the case must be considered. However I agree this isn't a real issue, the packages with the homegrown apps should choke the yum update because they see the lib versions they depend on would go away, so nothing breaks. Then the pressure is on the homegrown software guy to uplevel which will normally be a turnkey rebuild into a repo yum knows about and this seems acceptable to me. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/12/10 14:01, Somebody in the thread at some point said: On Fri, Mar 12, 2010 at 12:23:58PM +, Andy Green wrote: However I agree this isn't a real issue, the packages with the homegrown apps should choke the yum update because they see the lib versions they depend on would go away, so nothing breaks. Only if they're using the packaging system. While in an ideal world everything would be packaged in Fedora, the reality is that there's plenty of code that isn't, and users do do things like download stuff Then that's the person's problem who is using a packaged OS outside the packaging system: he can expect nothing but headaches being in stealth mode. It seems we all agree though that it's true the update action will choke if there are packages around that need the old libs and that's OK for that scenario. and run ./configure; make; make install. The ones who are least likely to know how to generate packages are the ones who are most likely to be confused by applications suddenly breaking because of a soname bump, and they're the ones who are going to be wary of running *any* updates because they tend to break stuff for them. That is what will happen when they upgrade to fc(n+1) anyway. And these guys have to know enough usually to yum in a load of -devel pieces. All that guy has to do is re-run make ; make install after the update and he's away again. That does not sound very onerous. If there's a big gain to be had in terms of solving impossible backport situations then it sounds like a tradeoff that's at the least reasonable to argue. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/12/10 18:06, Somebody in the thread at some point said: In this context, if you're writing homegrown apps, you're a developer, not a user, so the above sentence obviously does not apply. Instead, my original point does (you'll be compiling your own software very often anyway). It's a bit of a false dichotomy because I may be developing my stuff and using someone else's, but I take your point. You can call it a straw man, no problem calling things as they are. I love people quoting other people slightly out of context and putting their spin on it to make a point ... My dear Simo your IFF is malfunctioning. I take your point is me agreeing that I took his words out of context when I went back and read what he clearly quoted. Having understood his larger point, I don't think splitting people into developers and users is a worthwhile distinction because all developers are users of something else. At the company I am working for this whole subject has been a matter of great debate these last days about the best way to update our own stable packages for our own repo on top of a Fedora basis, by focus on backport or elevating our equivalent of rawhide into stable after thorough testing. AFAICS the best way through it is a mixture depending on the exact situation of each package and the divergence in the sources and libs. If a fix we would like to have in stable is dependent on new APIs in uplevelled libs, backporting becomes Hell given the need to retain the old APIs for packages that don't get updated while integrating new ones for the fix. It pushes me towards thinking a solution by bringing in the new libs and accepting the damage in terms of uplevelling and retesting the users of the library can often be the right way. And that seems to be Kevin's POV which is why I was surprised to misread what I misread. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
