Re: Now I'm curious...
On Mon, Sep 03, 2007 at 04:44:55PM -0500, Kevin Day wrote: Except for: 1) There is no stable uClibc, 0.9.28 is bugridden, 0.9.29 requires a number of patches only available in svn (let alone countless other bugs yet to be publicized) , and releases prior to 0.9.28 seem to have Yikes, is there a list of the known essential patches to 29? I'm using 0.9.28 and having problems with threads, so I'm attempting to upgrade to 29 as I see it includes a large libpthread update. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Monday 03 September 2007 4:08:06 am Christian MICHON wrote: On 9/2/07, Rob Landley [EMAIL PROTECTED] wrote: (...) I'm poking Peter to put out a release. I'll let you know if he does. (I'd happily send _him_ a cake, but he appears to be in Europe...) Hi Rob, and why not allowing us to peek at his 1194 commits instead ? Because he got roundly chewed out here and was essentially told to go away by at least two high-profile commiters, and Erik never stepped up to defend him, so he took his ball and went home? Now we're noticing that it was, in fact, a nice ball. does he have a public/private repository ? git ? mercurial ? svn ? He has a private repository of some kind. I spoke to him about it a year or so back but can't find it in my back email (might have been on irc). Recently he mentioned the number of commits in it, which is what brought it back to mind. Mostly what I see is when I bring up a question he sends me a patch fixing whatever it was from his repository... This would look less like a fork this way, no ? I think it's undeniably a fork, because he was checking everything in and was told to stop. He didn't create the fork, he was merging everything he did into mainline. That' show he got in trouble: Manuel and shjhill created the fork by telling him to stop merging last year. They thought he was merging too much. Of course, one could argue that a project on hiatus is about to fork anyway sooner or later... /me pleads the fifth: http://en.wikipedia.org/wiki/Tiny_C_Compiler My preference would be to see the people in charge back in the decision process. Maybe they're either too busy (understandable, they need to earn money also) or on holidays ? Patience then might be the key here... No flaming please :) I'm not flaming anybody, I'm just pointing out some interesting statistics. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
- Original Message - From: Rob Landley [EMAIL PROTECTED] To: Christian MICHON [EMAIL PROTECTED] Cc: uclibc@uclibc.org Sent: Tuesday, September 04, 2007 12:45 AM Subject: Re: Now I'm curious... On Monday 03 September 2007 4:08:06 am Christian MICHON wrote: On 9/2/07, Rob Landley [EMAIL PROTECTED] wrote: (...) I'm poking Peter to put out a release. I'll let you know if he does. (I'd happily send _him_ a cake, but he appears to be in Europe...) Hi Rob, and why not allowing us to peek at his 1194 commits instead ? Because he got roundly chewed out here and was essentially told to go away by at least two high-profile commiters, and Erik never stepped up to defend him, so he took his ball and went home? Now we're noticing that it was, in fact, a nice ball. I agree that Peter was a valuable and aggressive contributor. It's sad that instead of communicating each other's concerns, high-profile committer(s) snatched psm's commit rights. IIRC, Peter got into trouble as his changes were huge, hard to review and some time broke the build and/or compatability. I am sure now PSM can very well contribute to uClibc and give it its glory back. I vote for offering him a maintainer position again. Regards, NK ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Tue, Sep 04, 2007 at 01:08:53AM -0700, Nitin Gupta wrote: I agree that Peter was a valuable and aggressive contributor. It's sad that instead of communicating each other's concerns, high-profile committer(s) snatched psm's commit rights. Your facts are incorrect. Peter voluntarily removed himself and asked for his account to be deactivated. However, it is still active and he is welcome to check in changes. IIRC, Peter got into trouble as his changes were huge, hard to review and some time broke the build and/or compatability. This is correct. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Tuesday 04 September 2007 08:44, Rob Landley wrote: Er, deciding to allow means nothing if nobody does the work. My objection is that people who were chased away from the current uClibc tree have since been doing more work than the people who did the chasing. That doesn't seem efficient, somehow. I don't care which tree is official. That means very little to me. I don't poke at svn much anymore now that I've moved on to distributed source control, and although it's _polite_ to post my fixes back here, if they don't get integrated oh well. My uClibc tree supports miniconfig. uClibc 0.9.29 does not. *shrug* I saw Linus' video. Distributed SCM is nice for development, but at the end of a day, people want to go to some official place and download a latest stable version. It's doesn't matter that developers use git or mercurial, the code has to eventually end up at http://www.uclibc.org/downloads/. In the long run, successful long-term project must be usable by _users_, and users want to be able to figure out where latest code is, they don't want to search through forest of git/mercurial trees. Of course, if there is no agreement between maintainers and development slows down, sometimes it is naturally resolved by forking. It will be decided to do a release by whom? By whoever is doing most of maintainer's work. There are two editorial jobs involved in maintaining a project: 1) Deciding what to merge (and how), which often means saying no to the majority of submissions for the purposes of fighting off Sturgeon's Law. Book and magazine publishers do exactly the same thing with the slush pile, and movie producers do this with screenplays: this is nothing new. 2) Putting out stable releases. I've already mentioned I like time-based ones, and the video does a good job of explaining the benefits in detail. An interesting point is that the person putting out stable releases and the person controlling the development tree don't HAVE to be the same person. Especially once a stable release _has_ been issued, maintaining bugfix-only stable releases is often best done by somebody OTHER than the maintainer of the development branch. Do you propose someone to take these positions? If you use a modern distributed source control system, there's no concept of commit access. You can watch Linus Torvalds explain this on video, and hear him call CVS and SVN all sorts of nasty names. :) http://video.google.com/videoplay?docid=-2199332044603874737 http://kernel.org/ still exists, because people want to have official tree. Personally, I'm quite fond of Mercurial, as you can see at http://landley.net/hg;. Also, I just heard back from Peter whose tree is indeed in Mercurial. (Although not online at a permanent location, just when he leaves his machine on running hg serve, and the URL he emailed me last night is down at the moment. Possibly on a dynamic IP. I've asked him if I can mirror it on my website...) I have nothing against people using mercurial/git, it's just not very relevant to the question how to energize uclibc development? Let's all switch to mercurial/git doesn't solve it. -- vda ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
arm support for new linuxthreads in 0.9.29
Hi, I'm trying to upgrade to 0.9.29 and use the new linuxthreads, but my target is arm and it won't compile due to missing sysdep-cancel.h. Attempts to drop in versions thereof from glibc's code result in successful compilation, but any threaded application segfaults during startup. Switching back to the old linuxthreads works, but I'm having problems with a multithreaded application hanging so I want to try the new library... What do I need to do to get the new version to compile? thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
The Holy Grail (of computing?)
I enjoyed reading the discussion regarding (in)activity with the project. I have been watching the whole uClibc/buildroot project for several years now. I have joined and exited the list a few times. I recently got interested again in uClibc and figured I'd check out the progress... I am dismayed that it is still in a pre 1.0 release stage! So I thought I'd just throw out a few questions to anyone on the list and see what kind of responses we get. Keep in mind, I am not a developer, nor am I advocating drastic changes in uClibc. I just wanted to throw out a few thought provoking questions. I know that the *typical* answer is to go to www.uclibc.org and look at the answers for myself, but I don't think I'ld get as complete an answer as I will in discussing it here. I'll first make a few assumptions. For purposes of discussion I am going to consider a uClibc system as Busybox / uClibc / buildroot in companionship or combined with one another. If you chose to single out one aspect over another, please point out if you are addressing the project as a whole, or one of the three aforementioned components. 1.) Who is the target audience for a uClibc system? Seems to me that I read that the primary target is for the embedded market. Does that still hold true? Or has the embedded market passed on uClibc. Either way, I'm looking for some real in depth answers. not just Oh, anybody could use it, stuff. 2.) What other needs (niches) might the uClibc system meet? When thinking of other applications for uClibc, why not rank them in order of coolness? (Very subjective, I know!) 3.) How heavily is uClibc tied to GNU software? 4.) How does this project feel about the proposition of Mark Shuttlesworth to engage in a predictable 6 month release cycle? 5.) What do mailing list participants for uClibc system feel is the most crucial step(s) needing to be taken to maximize the usage or stability of the uClibc System? 6.) What are the greatest 5 inherent strengths of the system? What are it's 5 most glaring weaknesses? 7.) Is the system developer friendly? Why, or why not? If yes, what can be done to encourage more participation? If no, what fundemental things need to be changed? 8.) As far as philosophies go, would this project more closely align itself with the Free Software Foundation group or the Linux Foundation group? If you had to pick one or the other, that is... 9.) How do you use your uClibc system? 10.) How well does uClibc support your computing activities (scale of 1 to 10) ? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Tuesday 04 September 2007 8:21:13 am Denys Vlasenko wrote: On Tuesday 04 September 2007 08:44, Rob Landley wrote: Er, deciding to allow means nothing if nobody does the work. My objection is that people who were chased away from the current uClibc tree have since been doing more work than the people who did the chasing. That doesn't seem efficient, somehow. I don't care which tree is official. That means very little to me. I don't poke at svn much anymore now that I've moved on to distributed source control, and although it's _polite_ to post my fixes back here, if they don't get integrated oh well. My uClibc tree supports miniconfig. uClibc 0.9.29 does not. *shrug* I saw Linus' video. Distributed SCM is nice for development, but at the end of a day, people want to go to some official place and download a latest stable version. Yes. It's doesn't matter that developers use git or mercurial, the code has to eventually end up at http://www.uclibc.org/downloads/. Yes and no. When the maintainer of XFree86 threw out Keith Packard, he went off and started his own fork and the entire world followed. Glibc 2.0 and egcs were (more or less) such forks, prompted by stagnation. Back before Linus took up source control and was dropping the majority of patches on the floor (even the ones from maintainers), Alan Cox retired from Linux development for a year (went off and got an MBA) because people were starting to consider his tree the official one, and push him to become the new point man, and he didn't want the job. (More distros shipped stuff based on the -ac tree back in 2002 than on Linus's tree.) In the long run, successful long-term project must be usable by _users_, and users want to be able to figure out where latest code is, they don't want to search through forest of git/mercurial trees. I think the ethereal userbase managed to find wireshark. http://www.linux.com/articles/54968 Of course, if there is no agreement between maintainers and development slows down, sometimes it is naturally resolved by forking. *shrug* I'm not promoting any specific course of action, but a uClibc tree has come to my attention with about 30 times as many patches since 0.9.29 as mainline, and it's maintained by a guy who's answered over half the obscure technical questions I get stumped on about arm soft float and such (often answered by providing me patches). This developer will not return to this list, and has no interest in inheriting the existing tree (which is in an obsolete source control format anyway, and the new tree is mercurial which is my first choice these days anyway). It will be decided to do a release by whom? By whoever is doing most of maintainer's work. Anyone can put out a release. I put out a release of my tcc fork: http://landley.net/code/tinycc/downloads/ And I plan another one soon. That is rampantly unofficial, I have no access to tinycc.org and wouldn't commit to a CVS tree unless well-paid to do so. But there are people using my fork. There are two editorial jobs involved in maintaining a project: 1) Deciding what to merge (and how), which often means saying no to the majority of submissions for the purposes of fighting off Sturgeon's Law. Book and magazine publishers do exactly the same thing with the slush pile, and movie producers do this with screenplays: this is nothing new. 2) Putting out stable releases. I've already mentioned I like time-based ones, and the video does a good job of explaining the benefits in detail. An interesting point is that the person putting out stable releases and the person controlling the development tree don't HAVE to be the same person. Especially once a stable release _has_ been issued, maintaining bugfix-only stable releases is often best done by somebody OTHER than the maintainer of the development branch. Do you propose someone to take these positions? I'm pointing out the nature of the problem. PSM is currently _doing_ the first, he's just not doing it publicly, nor in the context of this mailing list or the svn tree on uClibc.org. The second job doesn't have to be done by the same guy. Stable releases involve snapshotting the tree and applying bugfix patches only. There's less of a judgement call involved in that, especially if new stable releases come out often enough that the decision to leave a feature out until the next release isn't particularly painful. I could theoretically take the second job, but it's useless without the first. If you use a modern distributed source control system, there's no concept of commit access. You can watch Linus Torvalds explain this on video, and hear him call CVS and SVN all sorts of nasty names. :) http://video.google.com/videoplay?docid=-2199332044603874737 http://kernel.org/ still exists, because people want to have official tree. Sure. But if the official tree stops being the
Re: The Holy Grail (of computing?)
On Tuesday 04 September 2007 11:12:55 am Mark Shelby wrote: I enjoyed reading the discussion regarding (in)activity with the project. I have been watching the whole uClibc/buildroot project for several years now. I have joined and exited the list a few times. I recently got interested again in uClibc and figured I'd check out the progress... I am dismayed that it is still in a pre 1.0 release stage! So I thought I'd just throw out a few questions to anyone on the list and see what kind of responses we get. Keep in mind, I am not a developer, nor am I advocating drastic changes in uClibc. I just wanted to throw out a few thought provoking questions. I know that the *typical* answer is to go to www.uclibc.org and look at the answers for myself, but I don't think I'ld get as complete an answer as I will in discussing it here. I'll first make a few assumptions. For purposes of discussion I am going to consider a uClibc system as Busybox / uClibc / buildroot in companionship or combined with one another. I don't use buildroot at all. Lots of other projects (like Gentoo Embedded or my own Firmware LInux) use uClibc but not buildroot. If you chose to single out one aspect over another, please point out if you are addressing the project as a whole, or one of the three aforementioned components. 1.) Who is the target audience for a uClibc system? Seems to me that I read that the primary target is for the embedded market. Does that still hold true? Or has the embedded market passed on uClibc. Either way, I'm looking for some real in depth answers. not just Oh, anybody could use it, stuff. The embedded market uses uClibc heavily. I don't consider it restricted to that though, it's a nice fit for bootable CD distros (where an extra megabyte or two of free space is still noticed), and in general it's nice to have a simple, readable C library. (Being tied to a single implementation is bad.) 2.) What other needs (niches) might the uClibc system meet? When thinking of other applications for uClibc, why not rank them in order of coolness? (Very subjective, I know!) Because it sounds too much like work? (Well you asked.) 3.) How heavily is uClibc tied to GNU software? Not at all. One of the long term goals of my Firmware Linux project is to come up with a Linux system that has no GNU software in it, not even in the build toolchain used to compile it. 4.) How does this project feel about the proposition of Mark Shuttlesworth to engage in a predictable 6 month release cycle? This project doesn't feel anything, but some of the developers consider that a very good thing, and I used to send Erik (the previous maintainer) cakes to try to stimulate new releases (the first one was to commemorate the one year anniversary of the 0.9.26 release). The Linux kernel is also aiming at regular periodic releases, and BusyBox is doing this too. 5.) What do mailing list participants for uClibc system feel is the most crucial step(s) needing to be taken to maximize the usage or stability of the uClibc System? *shrug* I try to use it to build lots of packages, actually use the results, and send in bug reports. 6.) What are the greatest 5 inherent strengths of the system? What are it's 5 most glaring weaknesses? You have a homework assignment? 7.) Is the system developer friendly? Why, or why not? If yes, what can be done to encourage more participation? If no, what fundemental things need to be changed? Explain the nature of the universe. Provide three examples. Go. I consider Firmware Linux relative developer friendly (and if it isn't I'd like to hear about it). I consider uClibc a low-level component that by itself does nothing. 8.) As far as philosophies go, would this project more closely align itself with the Free Software Foundation group or the Linux Foundation group? If you had to pick one or the other, that is... I'm Open Source, not Free Software. I actively oppose the FSF on several points (such as deprecating GPLv2 in any way, and Stallman's GNU/Linux/dammit campaign). I think the Hurd failed, Linux would have happened without him (obvious if you study the history, it forked off of _minix_, not GNU), and Stallman needs to get over it. 9.) How do you use your uClibc system? I press keys on a keyboard and view patterns on a screen. Sometimes a network card is involved. 10.) How well does uClibc support your computing activities (scale of 1 to 10) ? Blue. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Tuesday 04 September 2007 3:08:53 am Nitin Gupta wrote: I vote for offering him a maintainer position again. Er, I don't think it works that way. (We vote?) And I don't think he wants the job. The great thing about open source is you can go off and do your own thing. He's done so. I'm interested in at least evaluating the thing he's done, possibly in using it in my projects. This might mean using his version instead of the version here, sending him patches for bugs I find instead of posting them here, etc. *shrug* If it works better for me... Dunno yet, just downloaded it last night, haven't had much of a chance to bang on it yet. (Still playing with linux-2.6.23-rc5. One new set of bugs at a time... :) Regards, NK Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
