Re: move to rawhide update (Fedora QA breakage)
II. - What for me is an inhibitor is the bugzilla section tell us how to reproduce the problem. I have no desire whatsoever to try Mikus unfortunately plays a troll on the Internet. He probably isn't one in real life, but the way he uses the XO is extremely unusual, so he views the XO in ways that appear to be 77 degrees away from the usual viewpoint. His bug reports require careful interpretation if you want to avoid immediately discarding them as worthless. What good would it do for me to enter a bugzilla report? A dozen people would ask me for more information, and for more try this and try that. I have better things to do with my time. I'm sad to report that I tried to participate in a Fedora QA test day last week for some particular hardware I have (low end Radeon graphics). I filed one clear bug report, and four days later got the usual please send us lots of irrelevant info form letter. I filed a testy reply telling them they don't need it and please stop pretending to close out bug reports by demanding that the user send some irrelevant info. See: https://bugzilla.redhat.com/show_bug.cgi?id=493748 One of these irrelevant busybodies self-identifies as one of the Fedora BugZappers with this link: https://fedoraproject.org/wiki/BugZappers We are a group of volunteers and Red Hat employees whose primary mission is to review and triage bug report submissions on bugzilla.redhat.com, acting as a bridge between users and developers to aid in fixing and closing bugs. Now I see what's going on. Clueless people are crashing around in the bug database, helping developers by hassling users. Then if you don't answer the idiots, 30 days later they close out your bug report as CLOSED:INSUFFICIENT_DATA. Instead of a bridge, they seem to be more of a barrier, though perhaps they do good work somewhere. I think these are the same people who also trashed the OLPC suspend/resume is broken bug report, by running a script that declared it an obsolete problem that only applied to F10, even though the problem persists long after F10. But as the BugZapper credo says, No programming knowledge is necessary, and triagers don't necessarily need to understand the bugs they are working on. So I'll have to agree with Mikus's analysis of why not to bother filing Red Hat bugzilla bugs. Idiots will hassle you, and claim that the bug doesn't exist after all, then close it. (*) John (*): At Cygnus, we wrote a bug tracking system, PRMS. We made very sure that nobody except the original submitter could close out a bug report. The only thing developers or QA people could do was put the bug into feedback state, asking the original submitter to confirm that the bug really is fixed. I insisted on this process flow because of the numerous companies I'd reported bugs to, who regularly closed out my bugs without fixing them -- over and over. I'd search the bug reports at Sun and find six people all reporting the same bug I'd encountered -- and all six of them closed inappropriately by somebody whose job it was to close bug reports (not to fix bugs). Cygnus's customers appreciated the attention, even though it was sometimes a hassle for us to nudge them to close out the bugs we really HAD fixed. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update (Fedora QA breakage)
Now I see what's going on. Clueless people are crashing around in the bug database, helping developers by hassling users. Then if you don't answer the idiots, 30 days later they close out your bug report as CLOSED:INSUFFICIENT_DATA. Instead of a bridge, they seem to be more of a barrier, though perhaps they do good work somewhere. I think these are the same people who also trashed the OLPC suspend/resume is broken bug report, by running a script that declared it an obsolete problem that only applied to F10, even though the problem persists long after F10. But as the BugZapper credo says, No programming knowledge is necessary, and triagers don't necessarily need to understand the bugs they are working on. I agree with you to a certain extent. I believe the reason for the relable as F10 is primarily due to the fact that Fedora is relatively fast moving. The idiots you refer to are in the case of the this has been reported in rawhide during the F10 development process so assigning it to F10 are in fact scripts so are complete idiots. There's a good reason to assign it from rawhide to the specific release that it was reported under, its because it moves very quickly. X is an example of this. There's been massive changes in the last 3-4 fedora releases and for example errors related to input devices reported in F-9 are completely irrelevant in F-10 because the entire X input subsystem was replaced. So to be able to see that it was reported in what became F-9 is important because its going to be completely different issue in F-10. Just because it gets moved from a rawhide designator to a F-10 one doesn't mean its closed, and if its still relevant for rawhide, you can update it. I do so regularly. As for the bugZappers. no comment :-) Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
2009/4/8 John Gilmore g...@toad.com: Since OLPC's upstream is both Linus's kernel releases, and Fedora's distributions, there are two upstream places to push OLPC's hardware support patches to. Have we only been trying to get them into one of those places (Linus's)? The F11 kernel currently carries about 60 patches beyond Linus's version. Some are tiny 4kb patches; others are 300KB. Why aren't any of the XO-1 hardware support patches included in the F11 kernel? I don't think any effort has been made (since layoffs) to get any kernel patches upstream anywhere, mostly due to time constraints. But anyone is welcome to step up and do so! During a quick discussion with Chris and some others we seemed to agree on the following: - regardless of Fedora/F11/F12 status, policies or whatever, the first thing to do in any case is to get the patches upstream to Linus - we haven't actually tried sending our patches specifically to Fedora (knowing that they aren't quite ready for Linus) - but IMO this would be a bad idea - we don't really know Fedora's kernel policies for accepting non-upstream patches, or for backporting upstreamed patches into current Fedora kernels - my opinion: getting patches upstream to Linus, or perhaps even as far as linux-next, would be enough for the fedora kernel maintainers to include the patches in the F11 release kernel as an update. So let's not rule out suspend-on-F11.. it's possible that F11-plus-updates may work in future. The biggest showstopper right now seems to be finding someone to do the work of upstreaming the patches. And, in my opinion and experience, the correct way to do this is to approach upstream saying hey, we have this weird hardware, how would you like to see the kernel code crafted? here's a possible patch to act as the basis of discussions and *not* hey, we have this weird hardware, please take our patches as-is without consideration because we've shipped them internally for 2 years which makes the task harder (since kernel hacking may be needed as a result of discussions), but should lead to success :) Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
I thought now that we're getting closer to the Fedora 11 freeze it would be a good time for everyone to where they're at as we move towards F-11/9.1.0/olpc-next. My biggest current question is: When on my XO I enter 'yum check-update' (using either the latest SoaS2 .iso or the latest ~cjb/rawhide-xo .img), it tells me that there are more than 220 packages at the rawhide repositories that are at a more recent version level than those provided by the system on my XO. Why don't the SoaS/~cjb distributions contain the latest rawhide packages ? The main and probably most major issues outstanding are the kernel/boot process - so kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of stuff of which I have no real idea about. Updates? The remaining issues are mostly either package deps or getting them into Fedora. If we are talking about 9.1.0, it would be nice if 'sound' and 'moving pictures' worked in F-11 on the XO. Currently they don't. I agree that 'suspend' (or even power-off on 'shutdown') would improve the usability of F-11 on the XO. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
My biggest current question is: When on my XO I enter 'yum check-update' (using either the latest SoaS2 .iso or the latest ~cjb/rawhide-xo .img), it tells me that there are more than 220 packages at the rawhide repositories that are at a more recent version level than those provided by the system on my XO. Why don't the SoaS/~cjb distributions contain the latest rawhide packages ? Because rawhide is a daily moving development target. If there's a large update (like when rawhide was blocked for the creation of F11-Beta) there could 100s of updates in a day. See the daily rawhide report on the fedora-devel list for a general overview. The main and probably most major issues outstanding are the kernel/boot process - so kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of stuff of which I have no real idea about. Updates? The remaining issues are mostly either package deps or getting them into Fedora. If we are talking about 9.1.0, it would be nice if 'sound' and 'moving pictures' worked in F-11 on the XO. Currently they don't. Are there bugzilla reports for these? What do you mean by 'moving pictures', do you mean recording video or playing video? I agree that 'suspend' (or even power-off on 'shutdown') would improve the usability of F-11 on the XO. I believe this is being worked on. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
Why don't the SoaS/~cjb distributions contain the latest rawhide packages ? Because rawhide is a daily moving development target. Aren't you both right? The builds contain the latest rawhide packages as of the image creation date, right? Thus if it's no longer the instant the image was created, rawhide packages may have been updated. Yes. that is correct. The image is built from the current rawhide at the time of build. But if the image was based on rawhide from a couple of days ago (or the F-11 beta) it wouldn't be surprising that there was 210 package updates. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
On Tue, 7 Apr 2009, p...@laptop.org wrote: as mikus said, his applications all worked before. this is a regression, plain an simple, *with respect to the previous XO releases*. now, to the extent that fedora doesn't really care about any specific piece of hardware, especially one which wasn't running fedora when these things last worked, then i suppose it's appropriate to ignore the issues. i think this, and the fact that no one is sure what's broken in the current fedora-on-XO releases, points to huge holes in the OLPC plan of record for ongoing support of this product. unless some energetic entity is willing to own the actual XO distribution(s), and be responsible for maintaining a bug list, and issuing even minimal release notes, i fear for the project. (or, rather, i fear that the project will be running 8.2 until the laptops die. which wouldn't be the worst possible outcome, i suppose... :-/ ) This is what happens when the 95% of the developers working on the project get canned. The unenviable choice becomes: * Get a community to work from an 8.2 branch that will become more and more outdated over time; or * Get a community to work from a moving target that has a greater chance of supporting new features once they're integrated, but is inherently less stable for large chunks of the development cycle. Whichever way you go, strong leadership, patience, and many hands are required to fight through the problems. If the community cares enough and develops the necessary leadership, the project moves forward. But it's never easy. It is my hope that people continue to use the tracking bug here, and align bugs to it, and use it to assess fitness of the current release: https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1 It may not be the perfect tool, but it's the best we have. --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
II. - What for me is an inhibitor is the bugzilla section tell us how to reproduce the problem. I have no desire whatsoever to try to describe how to obtain the Fluendo mp3 codec for an XO, nor how to follow its instructions for seeing if it works. I have even less desire to describe where I obtained a static-linked Mplayer, nor how I have set up my XO for playing movies. [Both the mp3 codec and the Mplayer application work fine in 8.2.1.] What good would it do for me to enter a bugzilla report? A dozen people would ask me for more information, and for more try this and try that. I have better things to do with my time. Well, firstly if they're statically compiled applications that aren't shipped in Fedora there's no point filing bugs in Fedora about them as they aren't supported. but surely the APIs that they use _are_ supported, no? Yes. But if your going to have an attitude of its a waste of your time, I won't waste my time trying to get them to work for you. if mikus is having these problems, children with laptops will too. i'm sorry to hear someone who has done a _lot_ of very patient bug reporting and testing (and documentation, i believe) being dismissed like this. I'm not dismissing him. I'm quite prepared to help him if he'll provide the information. I'm someone who has done a _lot_ of very patient bug testing and trying to get all the OLPC changes to Fedora upstream so that we have the best release possible. As for children having these problems, most children will use the built in video player (totem, not sure of the sugar application), and then from there there will be local support teams and it will then move upstream (I believe). I doubt they will be reporting the bugs direct to the olpc-devel mailing lists. no point in filing bugs? let's all pack it in and go home. send the bug reports straight to nicholas. By no point filing bugs I meant that 80% of fedora package maintainers will close the bug straight up because its not a package in Fedora and will ask a bug to be filed with the upstream. Those that don't close the bug will expect details and ask questions which mikus clearly stated he couldn't be bothered providing. There's not a lot that can be done unless he at least states what application it is. He original stated 'sound' and 'moving pictures', how am I or anyone else suppose to work out what that means without asking for details such as the application, what version/build it is and if its not in Fedora where he got it from. Even Microsoft don't support 3rd party applications. That's why Fedora refuses to ship binary drivers for graphics chips and binary applications, it causes alot of problems. go and search the ubuntu forums or google about video driver problems. that being said, as a developer, i understand that a bug report with missing background information is difficult to deal with. mikus -- even attaching the static mplayer binary to the bug report, with an explanation that it used to work on 8.2, and now it doesn't, would be better than nothing. its not difficult, its impossible. What do you mean by 'moving pictures', do you mean recording video or playing video? I don't try to record video - so I have no idea if it works or not (see what I mean about being asked questions which I don't know how to answer?). The 'Record' activity does not show me a picture of what the XO camera is supposed to be seeing. The 'watchlisten' activity gives me neither 'sound' nor 'moving pictures'. [IIRC, it can close prematurely.] Mplayer runs, but gives me neither 'sound' nor anything except a blank screen. I can check the record activity but as mentioned before issues with mplayer and mp3 codecs will need to be reported to where ever you get them from. as mikus said, his applications all worked before. this is a regression, plain an simple, *with respect to the previous XO releases*. now, to the extent that fedora doesn't really care about any specific piece of hardware, especially one which wasn't running fedora when these things last worked, then i suppose it's appropriate to ignore the issues. Yes, it may well be a regression but if he's using rpms or binary tarballs compiled against older versions of Fedora that could be the issue. It could be as simple as directing him to a repository that contains the best version of mplayer to use on F11 but he's provided nothing. I'm trying to help but I'm not god, I'm one person and if the person that wants help isn't prepared to do some legwork why should I. I do this in my free time and I due to the lack of people on the project I could spend every spare second of waking time on it and still not have every done. i think this, and the fact that no one is sure what's broken in the current fedora-on-XO releases, points to huge holes in the OLPC plan of record for ongoing support
Re: move to rawhide update
If we are talking about 9.1.0, it would be nice if 'sound' and 'moving pictures' worked in F-11 on the XO. Currently they don't. Are there bugzilla reports for these? I. - I haven't figured out how to do an exhaustive search on bugzilla. 'OLPC' picks up some; 'XO' picks up some; '461806' picks up some. But let me emphasize once again - bugzilla appears to be aimed at the problems of developers (and isn't optimal for users). II. - What for me is an inhibitor is the bugzilla section tell us how to reproduce the problem. I have no desire whatsoever to try to describe how to obtain the Fluendo mp3 codec for an XO, nor how to follow its instructions for seeing if it works. I have even less desire to describe where I obtained a static-linked Mplayer, nor how I have set up my XO for playing movies. [Both the mp3 codec and the Mplayer application work fine in 8.2.1.] What good would it do for me to enter a bugzilla report? A dozen people would ask me for more information, and for more try this and try that. I have better things to do with my time. What do you mean by 'moving pictures', do you mean recording video or playing video? I don't try to record video - so I have no idea if it works or not (see what I mean about being asked questions which I don't know how to answer?). The 'Record' activity does not show me a picture of what the XO camera is supposed to be seeing. The 'watchlisten' activity gives me neither 'sound' nor 'moving pictures'. [IIRC, it can close prematurely.] Mplayer runs, but gives me neither 'sound' nor anything except a blank screen. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
Are there bugzilla reports for these? I. - I haven't figured out how to do an exhaustive search on bugzilla. 'OLPC' picks up some; 'XO' picks up some; '461806' picks up some. But let me emphasize once again - bugzilla appears to be aimed at the problems of developers (and isn't optimal for users). You don't need to do an exhaustive search on bugzilla. You just need to search against the component that's causing issues. eg totem media player. Generally most components will have 10 bugs so its easy to see if its an issue for the component. II. - What for me is an inhibitor is the bugzilla section tell us how to reproduce the problem. I have no desire whatsoever to try to describe how to obtain the Fluendo mp3 codec for an XO, nor how to follow its instructions for seeing if it works. I have even less desire to describe where I obtained a static-linked Mplayer, nor how I have set up my XO for playing movies. [Both the mp3 codec and the Mplayer application work fine in 8.2.1.] What good would it do for me to enter a bugzilla report? A dozen people would ask me for more information, and for more try this and try that. I have better things to do with my time. Well, firstly if they're statically compiled applications that aren't shipped in Fedora there's no point filing bugs in Fedora about them as they aren't supported. But if your going to have an attitude of its a waste of your time, I won't waste my time trying to get them to work for you. What do you mean by 'moving pictures', do you mean recording video or playing video? I don't try to record video - so I have no idea if it works or not (see what I mean about being asked questions which I don't know how to answer?). The 'Record' activity does not show me a picture of what the XO camera is supposed to be seeing. The 'watchlisten' activity gives me neither 'sound' nor 'moving pictures'. [IIRC, it can close prematurely.] Mplayer runs, but gives me neither 'sound' nor anything except a blank screen. I can check the record activity but as mentioned before issues with mplayer and mp3 codecs will need to be reported to where ever you get them from. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
peter, and greg -- greg wrote: Whichever way you go, strong leadership, patience, and many hands are required to fight through the problems. If the community cares enough and develops the necessary leadership, the project moves forward. But it's never easy. It is my hope that people continue to use the tracking bug here, and align bugs to it, and use it to assess fitness of the current release: https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1 of course. but the whole thing feels a lot like telling someone that their local dealership has closed, and they should write to the car's manufacturer for information about oil changes. the scale of the solution doesn't match the needs of the problem. (the analogy is shaky, i agree.) but as an example -- if bugs filed against the XO will be summarily closed by the developers because it's not our problem, file it upstream, the larger OLPC community will be ill-served. users of the XO are not typical open-source enthusiasts, and they're not the audience that current linux distributions are used to targeting. the XO isn't a general purpose laptop, and was never intended to be. it's better considered a device, with special needs, and as such i think it will be under-served by the new generic release and support scheme. while i agree that the current plan is probably the best we can come up with, i remain frustrated. thanks. and sorry for the non-technical venting... believe me, the real target of my rant is not the folks like you two who are continuing the mission. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
On Tue, 7 Apr 2009, p...@laptop.org wrote: peter, and greg -- greg wrote: Whichever way you go, strong leadership, patience, and many hands are required to fight through the problems. If the community cares enough and develops the necessary leadership, the project moves forward. But it's never easy. It is my hope that people continue to use the tracking bug here, and align bugs to it, and use it to assess fitness of the current release: https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1 of course. but the whole thing feels a lot like telling someone that their local dealership has closed, and they should write to the car's manufacturer for information about oil changes. the scale of the solution doesn't match the needs of the problem. (the analogy is shaky, i agree.) but as an example -- if bugs filed against the XO will be summarily closed by the developers because it's not our problem, file it upstream, the larger OLPC community will be ill-served. s/larger OLPC community/larger open source community/ Because, of course, this is not a problem experienced only by OLPC. This painful problem is central to every distro provider. The answer is a comprehensive ecosystem-wide mechanism for distributed defect tracking, and we are years away from that solution, I suspect. users of the XO are not typical open-source enthusiasts, and they're not the audience that current linux distributions are used to targeting. the XO isn't a general purpose laptop, and was never intended to be. it's better considered a device, with special needs, and as such i think it will be under-served by the new generic release and support scheme. while i agree that the current plan is probably the best we can come up with, i remain frustrated. Yeah, me too. The hope continues to be that we can stabilize and maintain the base, and then focus on the deltas that set the device apart. But it's a hard problem, made harder by a lack of resources. thanks. and sorry for the non-technical venting... believe me, the real target of my rant is not the folks like you two who are continuing the mission. I know, dude. It's okay. If you have any suggestions, believe me, I'm happy to hear them. :) --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
The main and probably most major issues outstanding are the kernel/boot process - so kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of stuff of which I have no real idea about. Updates? It's pretty trivial to disable Rainbow, whereas it's not trivial to get maintainers of half a dozen packages to adopt patches that let them deal with Rainbow. So if you want F11 to work on OLPC, disabling Rainbow's UID fiddling in the version of Sugar that ships in F11 is the obvious short-term cure. Some of the initscript changes related to the bizarre idea of running the anti-theft process as pid 1 so it couldn't be killed by root. This required changing init so it didn't run as pid 1. This is trivial to fix by running the anti-theft process (which is a no-op loop on most OLPCs anyway, and should in a sane world merely exit) on some other pid, and running init where it belongs. It looks like perhaps the kernel changes have slipped right through the F11 schedule. Is it seriously likely that the F11 kernel maintainers would adopt a pile of OLPC patches that aren't in the upstream kernel, between the Beta and the Final F11 releases? Had these changes been adopted (by Fedora or by the Linux kernel) early in the release cycle, they could've been well tested to make sure they don't introduce any problems into non-OLPC hardware. But now, it appears that F11 won't be able to suspend on OLPC, which makes it almost useless for laptop use (as opposed to developer use when the laptop is sitting on a desk with permanent AC power). Such is the price of firing all of your kernel developers. Even the bug report that tracks the kernel power management changes has fallen into disarray (the Fedora Bug Zapper zapped it in November and nobody has bothered to fix it since): https://bugzilla.redhat.com/show_bug.cgi?id=465284 John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
john wrote: It looks like perhaps the kernel changes have slipped right through the F11 schedule. Is it seriously likely that the F11 kernel for the record, this was a conscious decision. everyone knew there wouldn't be time to get XO-specific changes upstream, and back to fedora, before F11. as you say, it was the cost of going broke. the challenge is now to get those changes upstream in time for F12. maintainers would adopt a pile of OLPC patches that aren't in the upstream kernel, between the Beta and the Final F11 releases? Had these changes been adopted (by Fedora or by the Linux kernel) early in the release cycle, they could've been well tested to make sure they don't introduce any problems into non-OLPC hardware. But now, it appears that F11 won't be able to suspend on OLPC, which makes it almost useless for laptop use (as opposed to developer use when the laptop is sitting on a desk with permanent AC power). Such is the i think the plan is to make an OLPC-patched kernel available for the distribution creators. paul price of firing all of your kernel developers. Even the bug report that tracks the kernel power management changes has fallen into disarray (the Fedora Bug Zapper zapped it in November and nobody has bothered to fix it since): https://bugzilla.redhat.com/show_bug.cgi?id=465284 John ___ Fedora-olpc-list mailing list fedora-olpc-l...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-olpc-list =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
Hi John, It's pretty trivial to disable Rainbow, whereas it's not trivial to get maintainers of half a dozen packages to adopt patches that let them deal with Rainbow. Yes, we aren't using rainbow in the F11 builds. Some of the initscript changes related to the bizarre idea of running the anti-theft process as pid 1 so it couldn't be killed by root. Or this. But now, it appears that F11 won't be able to suspend on OLPC, which makes it almost useless for laptop use (as opposed to developer use when the laptop is sitting on a desk with permanent AC power). Sure, but you can install a different kernel on your F11 image, such as OLPC's custom kernel (this has already been tested working), or just the minimum set of patches to the F11 kernel that add suspend/resume support, as Scott Douglass and Martin Dengler have been looking at recently. I hope we can get some power management patches (even if they're basic patches rather than everything we have) upstream and back for F12. We started the F11 project with the knowledge that we wouldn't be able to get much of what we need upstream and back in time for its release. Thanks, - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
Paul, Whichever way you go, strong leadership, patience, and many hands are required to fight through the problems. If the community cares enough and develops the necessary leadership, the project moves forward. But it's never easy. It is my hope that people continue to use the tracking bug here, and align bugs to it, and use it to assess fitness of the current release: https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1 of course. but the whole thing feels a lot like telling someone that their local dealership has closed, and they should write to the car's manufacturer for information about oil changes. the scale of the solution doesn't match the needs of the problem. (the analogy is shaky, i agree.) I agree with you here to a degree, but also by getting the Fedora community involved you also get 1000s of extra bug testers, coders, and community which I think in time will have much more of a positive effect than negative. Unfortunately in the short term while everything gets moved upstream and settles out there will be some pain. but as an example -- if bugs filed against the XO will be summarily closed by the developers because it's not our problem, file it upstream, the larger OLPC community will be ill-served. They won't be summarily closed if they are related to Fedora, but if its the other application that is broken its very standard. I had Microsoft do exactly the same at work the other day when it was proven that it was a vendors AV causing the problem. Of course this will also depend on the package maintainer and how responsive the reporter is. For things like 3rd party stuff it might be worthwhile using/recommending some of the recognised fedora repos for mp3 stuff etc. I'm not sure how that would need to be handled from a legal perspective. users of the XO are not typical open-source enthusiasts, and they're not the audience that current linux distributions are used to targeting. the XO isn't a general purpose laptop, and was never intended to be. it's better considered a device, with special needs, and as such i think it will be under-served by the new generic release and support scheme. while i agree that the current plan is probably the best we can come up with, i remain frustrated. Also most XO users will probably unlikely to go and get software that's not distributed through a supported stream such as a school server or fedora repos. While the current situation isn't ideal but it was my understanding that alot of the support was being moved to country based teams which would then liaise with upstream OLPC/sugarlabs/fedora so it might well work ok as that gets implemented. thanks. and sorry for the non-technical venting... believe me, the real target of my rant is not the folks like you two who are continuing the mission. Its not an issue. We're all hear for the same reason and probably all frustrated for various reason. I came in at the very end of the 8.2.0 dev cycle. With the changes I've some how got a lot more involved than I originally planned I started getting involved with small Fedora devices because I wanted to help with a spin for Netbooks that's sort of been replaced with this :-) Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
Hi Chris, It's pretty trivial to disable Rainbow, whereas it's not trivial to get maintainers of half a dozen packages to adopt patches that let them deal with Rainbow. Yes, we aren't using rainbow in the F11 builds. Some of the initscript changes related to the bizarre idea of running the anti-theft process as pid 1 so it couldn't be killed by root. Or this. But now, it appears that F11 won't be able to suspend on OLPC, which makes it almost useless for laptop use (as opposed to developer use when the laptop is sitting on a desk with permanent AC power). Sure, but you can install a different kernel on your F11 image, such as OLPC's custom kernel (this has already been tested working), or just the minimum set of patches to the F11 kernel that add suspend/resume support, as Scott Douglass and Martin Dengler have been looking at recently. I hope we can get some power management patches (even if they're basic patches rather than everything we have) upstream and back for F12. We started the F11 project with the knowledge that we wouldn't be able to get much of what we need upstream and back in time for its release. So is that trying to get them into 2.6.30? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
Hi, So is that trying to get them into 2.6.30? Yes, that would be ideal. - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
Given everything discussed so far, is it worth considering an F11-OLPC branch, with the intent of merging with F12? -- Kevin Sonney -- ke...@sonney.com “Around here, however, we don’t look backwards for very long. We keep moving forward, opening up new doors and doing new things… and curiosity keeps leading us down new paths.” –Walt Disney I check email a couple times daily; to reach me sooner, click here: http://awayfind.com/ksonney ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
On Tue, Apr 07, 2009 at 05:17:09PM +0100, Peter Robinson wrote: Why don't the SoaS/~cjb distributions contain the latest rawhide packages ? Because rawhide is a daily moving development target. Aren't you both right? The builds contain the latest rawhide packages as of the image creation date, right? Thus if it's no longer the instant the image was created, rawhide packages may have been updated. [mikus] Peter Martin pgplabmuIFC50.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel