01:11.56 | *** join/#uclibc phpCure (foobar@h-69-3-1-45.MCLNVA23.covad.net) |
01:18.32 | ds | the sparc port is in lousy shape |
02:17.08 | mjn3 | ds: how bad is it? |
02:22.42 | ds | mjn3: I'm having a difficult time getting it to compile |
02:23.26 | mjn3 | what is it dying on? |
02:24.45 | ds | lots of stuff. once I fix the syscalls.h problem, it complains about weak_alias(stat,stat64) |
02:24.54 | ds | but mostly I was just venting |
02:27.16 | mjn3 | ah... i quite understand. i've vented a bit myself lately trying to squeeze collation data into a reasonable size. i'm seeing light at the end of the tunnel now though |
02:43.29 | mjn3 | ds: got a minute to give me some feedback wrt NOMMU systems? |
02:54.07 | *** join/#uclibc r0dzilla (~rodzilla@adsl-35-152-41.chs.bellsouth.net) |
02:55.55 | ds | ok |
02:56.01 | r0dzilla | greetings |
02:56.43 | r0dzilla | got a busybox question... |
02:57.17 | r0dzilla | getting an error on busybox's init, at first it says can't run /etc/init.d/rcS: permission denied |
02:57.28 | r0dzilla | I correct the perms and reboot |
02:57.34 | r0dzilla | now it says the file is not there |
03:02.53 | ds | rcS probably invokes an interpreter. Does that exist? |
03:08.38 | r0dzilla | let me check, was afk for a bit |
03:09.19 | ds | erg. I'm building on a sparc64 machine. |
03:09.28 | ds | I think I'll go cry now |
03:09.29 | r0dzilla | /bin/mount -av |
03:09.29 | r0dzilla | /bin/hostname RescueFloppy |
03:09.53 | r0dzilla | hmmm... |
03:09.58 | r0dzilla | I may have found my problem... |
03:10.00 | r0dzilla | lol |
03:11.31 | r0dzilla | mount is covered by busybox, but hostname is not, and I don't have it on the floppy |
07:33.57 | *** join/#uclibc psypete (~psypete@dsl-65-190-50-157.telocity.com) |
07:34.03 | psypete | he-lo |
07:44.21 | psypete | i have a question |
07:44.45 | psypete | could someone point me to the part of init where child processes get reaped if they don't clean themselves up at exit time? |
12:50.31 | psypete | hello? |
13:38.09 | andersee | morning |
13:40.42 | psypete | ahhh |
13:40.47 | psypete | my favorite person in the world |
13:40.49 | psypete | morning |
13:41.30 | psypete | andersee: i have a question about init :) |
13:45.28 | psypete | andersee: apparently my tiny init program isn't handling zombies properly, and i'm supposed to handle SIGCHLD, but i can't get how to exactly; do i do it before a fork? after? before an execv? after? before the parent's waitpid call? after? i'm just not sure what to set it to either :( |
13:54.23 | andersee | psypete: you do not want to handle SIGCHLD directly. Check out the latest version of busybox init. |
13:54.50 | andersee | psypete: you simply want to add an extra while loop, comparable to the one at the end of bb init. |
13:55.01 | andersee | <PROTECTED> |
13:55.01 | andersee | <PROTECTED> |
13:55.01 | andersee | <PROTECTED> |
13:55.01 | andersee | <PROTECTED> |
13:55.02 | andersee | <PROTECTED> |
13:55.02 | andersee | <PROTECTED> |
13:55.12 | andersee | ... |
13:55.14 | andersee | <PROTECTED> |
13:55.14 | andersee | <PROTECTED> |
13:55.14 | andersee | <PROTECTED> |
13:56.16 | psypete | hrmmm |
13:56.31 | psypete | where exactly does that go? |
13:56.39 | psypete | is that the handler for SIGCHLD? |
13:58.32 | andersee | nonono. You don't really want an explicit SIGCHLD handler. You just need a while loop the waits for stuff to die and restarts it and reaps dead child processes |
13:58.52 | psypete | oh ok |
13:59.07 | psypete | where in particular would that loop go? |
13:59.30 | psypete | (since i have several programs executed from init including a shell as the last one executed) |
14:03.52 | andersee | psypete: do take a look at the source |
14:03.56 | andersee | psypete: http://busybox.net/cgi-bin/cvsweb/busybox/init/init.c?rev=1.178&content-type=text/vnd.viewcvs-markup |
14:04.21 | andersee | psypete: Go to the very end of the file... You will see a double while() loop |
14:04.54 | andersee | psypete: Starting at "/* Now run the looping stuff for the rest of forever */" |
14:05.21 | psypete | andersee: i have looked at the source, thoroughly confused from SIGCHLD stuff :) but i shall look at this loop now |
14:08.53 | *** join/#uclibc mjn3 (~mjn3@cdm-208-59-243-laft.cox-internet.com) |
14:09.52 | mjn3 | andersee: hey |
14:10.18 | andersee | mjn3: morning |
14:11.07 | andersee | I had a nice weekend. I'm feeling much more relaxed then I've been for a while. |
14:12.11 | mjn3 | andersee: it took longer than i thought, but (it think) i finally came up with an algorithm to build the tables i need. i'm going to code it up today, although i've got a couple of errands to run today as well |
14:14.06 | andersee | Excellent. |
14:14.15 | andersee | Hows the size looking? |
14:14.44 | psypete | andersee: in the run() function, why is it you block sigchild and later set it back to SIG_DFL ? i have a somewhat smaller function for running arbitrary programs as necessary, and it looks kind of similar to this run() function |
14:15.57 | andersee | psypete: That is a big pile of junk to force a controlling terminal... |
14:16.10 | psypete | ...which i think i need to run bash :) |
14:16.27 | psypete | or more to the point, lash :) |
14:17.45 | andersee | psypete: Actually, probably not. I think I changed the run() function a bit since you made your mini-init |
14:18.05 | psypete | Hrm |
14:20.09 | mjn3 | andersee: still looking < 200k. total locale data size should be between 250k-300k when all's said and done. note that initially collation will require wchar support. while i could (and may in the future) support collation for the various 8-bit codesets natively, initally strcoll will be implemented in terms of wcscoll |
14:21.20 | andersee | Seems fair... |
14:22.31 | andersee | When one trims off the oddball ones like korean and ja_JP, do things get much smaller? |
14:27.09 | mjn3 | i'm looking at 5 cases |
14:27.35 | mjn3 | 1 - 102 locales based on iso16541_t1 |
14:27.59 | mjn3 | 2 - 14 locales "close to" en_CA |
14:28.29 | mjn3 | 3 - the cs_CZ locale... not close enough to en_CA :-( |
14:28.48 | mjn3 | 4 - ja_JP |
14:28.49 | mjn3 | 5 |
14:28.53 | mjn3 | 5 - ko_KR |
14:29.24 | mjn3 | 6 - (ok, i miscounted) ar_SA |
14:31.17 | mjn3 | rough estimated sizes -- 1) 40-50k 2) 40-50k 3) maybe 20k ; 4) and 5) could be as little as 5-10k a piece. could be more. 6) 10k-20k |
14:32.26 | mjn3 | so, i might even wind up around 150k of collation data. my target was < 200k because it was a "sufficiently round number" |
14:39.04 | andersee | hehe |
14:39.10 | andersee | Sounds good. |
15:37.05 | mjn3 | andersee: i'm considering added glibc's hsearch{_r} to uClibc as it is currently missing. it would add < 700 bytes of code for i386. any problem with me adding libc/misc/search and putting hsearch* there as well as moving current lsearch, tsearch, and insremque since they're all prototyped in search.h? |
15:41.20 | andersee | That works |
15:41.34 | andersee | Would be more consistant to have them grouped there |
15:42.20 | mjn3 | good enough |
15:54.23 | andersee | mjn3: BTW, are you planning on adding monetary.h? |
15:57.27 | mjn3 | andersee: it is on the todo list since it is SUSv3, but it is towards the bottom |
15:58.23 | *** join/#uclibc sandman_ (~sandman@pD9E89720.dip.t-dialin.net) |
15:58.35 | andersee | k. just noticed it was the only locale specific header file we seem to lack |
15:58.44 | sandman_ | hi Erik |
16:00.11 | sandman_ | andersee: Is there a time frame for the 0.61 release yet ? |
16:00.56 | andersee | sandman_: nope. Though bug1 has been pushing to get things ready to release. |
16:01.41 | andersee | sandman_: The biggest thing still lacking is that I need to rework the config system once again, per what I've done with uClibc. |
16:02.37 | mjn3 | andersee: yes, but all it is for is strfmon... so it will probably be a while before i get to it |
16:04.16 | sandman_ | k .. how is the current state of unstable ? |
16:04.45 | sandman_ | any applets that are _really_ unstable ? |
16:05.54 | andersee | sandman_: not really |
16:06.05 | andersee | sandman_: Though it could all use more testing I suppose |
16:06.42 | sandman_ | I'll make a new package and let the familiar users test it then ;) |
16:32.00 | mjn3 | andersee: ok. i think search.h cleanup is finished |
16:33.11 | andersee | mjn3: cool |
16:33.23 | andersee | mjn3: I saw the commits. That'll be good |
16:34.58 | mjn3 | andersee: we may at some point want to add the current glibc avl-tree implementation of tsearch as a config option. the current tsearch code is small but can build very unbalanced trees |
16:35.43 | andersee | k |
16:35.49 | mjn3 | "very unbalanced trees" translates to "linked list" in the worst case |
16:35.59 | andersee | I'm sure we'll get there |
16:37.05 | mjn3 | as i recall, the auto-balancing approach adds about 1k or so. but i could be wrong. that was a while back |
16:53.18 | waldi | andersee: is it possible that you don't want to answer my questions? |
16:59.55 | andersee | waldi: what questions? |
17:00.10 | waldi | "andersee: do you accept that i upload busybox-cvs with Maintainer: debian-boot and some Uploaders including yourself?" |
17:00.14 | andersee | waldi: Did you email me? |
17:00.21 | waldi | no |
17:01.00 | andersee | waldi: I don't mind having such a busybox-cvs package |
17:01.21 | waldi | it exists in the cvs |
17:02.55 | andersee | waldi: bug1 put together the busybox-cvs version |
17:03.11 | waldi | it is based on my patches |
17:04.36 | andersee | As I said, I don't mind such a package |
17:07.13 | waldi | than i will include the patches in the stable busybox and upload them |
17:07.42 | andersee | What? |
17:07.46 | andersee | No no no |
17:07.59 | andersee | You said busybox-cvs, so I assumed devel |
17:08.00 | waldi | the problem is, we _need_ them |
17:08.09 | andersee | What patches? |
17:08.44 | andersee | You are not being clear to me at all. I thought you were talking about busybox devel.... |
17:08.44 | waldi | ip, some klog patches |
17:11.26 | waldi | busybox debian packages |
17:11.36 | andersee | waldi: And ip is in the devel version of busybox. |
17:11.44 | waldi | yes |
17:12.50 | andersee | waldi: So you have my blessing to package the devel version as discussed above. Don't mess with the stable version. Adding in large applets such as ip is not something that will be going into stable. |
17:13.11 | andersee | waldi: Stable 0.60. is bugfixes only at this point |
17:16.14 | waldi | okay |
17:17.08 | waldi | andersee: i'll add you to uploaders |
18:29.03 | andersee | mjn3: toolchains will now build cross-compilers once again |
18:38.57 | mjn3 | andersee: ok... (i haven't had any time lately to try them) |
19:28.19 | *** join/#uclibc BZFlag (timr@rikers.org) |
19:30.38 | andersee | BZFlag: how goes it? |
19:50.53 | BZFlag | as well as can be expected. ;-) vacation was nice. |
20:00.57 | luca | is it me or is lxdialog not in the .60.5 tarball? |
20:04.03 | mjn3 | luca: yes |
20:04.51 | mjn3 | luca: ;-) seriously, stable busybox config is done by hand-editing |
20:05.54 | luca | that's fine... i do hand edit Config.h |
20:06.07 | luca | but this tarball has no lxdialog subdir in scripts |
20:06.23 | luca | i only happened to come across lxdialog by going through the CVS tree |
20:06.43 | luca | i'm just wondering why it is left out... |
20:07.42 | mjn3 | luca: the cvs tree for .60.5 is busybox.stable whereas the busybox cvs tree is the unstable devel version |
20:07.56 | luca | actually, there's a tonne of stuff in the devel tree |
20:08.48 | luca | my god, your next release will be huge, if all that is included :) |
20:29.46 | *** join/#uclibc BZFlag (~timr@gk2-ext.lineo.com) |
20:57.21 | *** join/#uclibc bug1 (~bug1@c16500.sunsh3.vic.optusnet.com.au) |
20:58.49 | bug1 | waldi: i commited a modified varient of your usage patch, havent tried it yet |
20:59.38 | bug1 | its better to catch usage errors in the calling applet |
21:01.38 | waldi | okay |
21:02.28 | waldi | hmm, why i aren't see your commits? |
21:03.23 | waldi | R debian/busybox-doc.docs |
21:03.31 | waldi | you should remove that file |
21:06.38 | bug1 | i think that some filesi n ./debian/ may not be tagged properly or something (but i dont know cvs very well) |
21:08.17 | waldi | hmm? you shoudl commit into head |
21:13.52 | bug1 | waldi: or maybe i just overlooked it, its gone now |
21:15.13 | waldi | hmm |
21:15.39 | waldi | i don't see your changes |
21:16.54 | bug1 | do you see the patch to editors/vi and libbb/procps.c |
21:17.32 | waldi | <PROTECTED> |
21:17.32 | waldi | <PROTECTED> |
21:17.33 | bug1 | i applied that after removing debian/busybox-doc.docs, if i do a cvs up busybox-doc.docs doesnt come back |
21:17.59 | waldi | please try cvs status libbb/procps.c |
21:18.33 | waldi | the last change of this file is commited 2002/11/25 |
21:18.40 | andersee | waldi: Are you checking cvs.busybox.net or the public anoncvs mirror at busybox.net? |
21:18.52 | bug1 | <PROTECTED> |
21:18.53 | bug1 | <PROTECTED> |
21:18.55 | waldi | :pserver:anonymous@busybox.net:/var/cvs |
21:19.03 | andersee | waldi: So there you go |
21:19.11 | waldi | okay |
21:19.12 | andersee | waldi: It is synced every 4 hours |
21:19.28 | andersee | waldi: I can run a sync manually for you, if you care |
21:19.46 | waldi | andersee: cvs.b.n doesn't permit pserver? |
21:21.54 | waldi | /var/cvs/busybox: no such repository |
21:21.58 | waldi | seems so |
21:22.13 | andersee | waldi: cvs.busybox.net lives about 4 feet from me, and is also known as codepoet.org. It lives as the end of my home DSL line. And no, I don't allow pserser. |
21:22.30 | waldi | <g> |
21:23.31 | waldi | andersee: please include a sentence which mention this delay on busybox.net |
21:23.55 | andersee | It runs cvs and the mailing lists for busybox and uclibc... |
21:25.55 | andersee | waldi: I'd actually prefer not to. Most people can live with the slight delay, and I'd rather not have my little Netwinder (a 200 Mhz strongARM box) flooded with people hitting the web interface to check if pet patch X is committed yet. That is what the busybox-cvs commit mailing lists are for. |
21:26.28 | waldi | andersee: why does the webinterface don't use the mirror? |
21:26.39 | waldi | than it shouldn't be a problem |
21:28.23 | andersee | waldi: the web interface on cvs.busybox.net reflects status of the local archive, as does the one on busybox.net. The one on cvs.b.n may be up to 4 hours in advance... |
21:33.56 | waldi | bug1: the ip command should be in /bin, not /sbin |
21:34.14 | waldi | the position has some historical reasons |
21:34.20 | bug1 | ok |
21:35.08 | bug1 | i assume thats the same for iplink etc |
21:36.17 | waldi | its a little bit unclear |
21:36.32 | waldi | the debian package installes only the ip binary in bin |
21:37.05 | bug1 | best to keep them all in the same directory anyway i think |
21:38.13 | bug1 | i like the seperate ip commands |
21:38.26 | waldi | why? |
21:38.58 | bug1 | i think its nicer not having to use extra options in ip |
21:39.03 | bug1 | more direct |
21:39.20 | waldi | i use always ip with the extra options |
21:40.24 | bug1 | and the default value does something usefull without any options at all |
21:40.57 | bug1 | b.t.w. i managed to save a few hundred bytes on ip yesterday |
21:41.13 | waldi | i saw it |
21:41.27 | bug1 | do you like the way i did it :) |
21:41.51 | waldi | i don't try to read the diff completely |
21:43.06 | bug1 | ahh... i was pretyt happy with it, create an array of options and comvert them to a number, then use a case statement, reduces the number of conditions and function calls |
21:43.36 | waldi | andersee: why aren't the usage messages include in the applets struct? |
21:45.27 | bug1 | andersee: and while your about, how is busybox.sgml created ? |
22:02.15 | andersee | waldi: It is. Or at least a pointer to it is. |
22:05.08 | andersee | bug1: docs/autodocifier.pl |
22:07.03 | andersee | bug1: It should go something like |
22:07.06 | andersee | <PROTECTED> |
22:07.06 | andersee | <PROTECTED> |
22:07.06 | andersee | <PROTECTED> |
22:07.52 | bug1 | yea, i saw that, i tried using autodocifier -sgml usage.h and it just produced a heap of <fixme>tag</fixme> stuff |
22:09.01 | bug1 | or is busybox.sgml created from busybox.pod |
22:09.13 | andersee | bug1: Hmm. I guess we should fix it sometime. Or switch to using something else. |
22:24.02 | bug1 | looking at autodocifier in cvs, i dont see how it has ever produced busybox.sgml |
22:25.40 | andersee | bug1: busybox.sgml was hand written by me. We never got autodocifier to do it properly. Which is why the sgml docs are not authoratative. |
22:26.06 | andersee | bug1: I guess I lied about autodocifier.pl earlier. |
22:26.18 | andersee | bug1: Guess I'm getting old |
22:26.42 | bug1 | hehe |
22:27.40 | bug1 | you sound like vodz, hes always refering to himself as old |
22:29.47 | bug1 | it must have taken a while to do busybox.sgml by hand |
22:35.07 | andersee | I copied/pasted most of the content from the .pod |
22:35.55 | andersee | That was before the generation of the .pod was automated |
22:39.15 | bug1 | maybe we are doing it backwards, maybe there should be a usage.sgml that generates usage.h, if sgml's strenght converting it to other formats, then maybe it should be the origin |
22:40.14 | bug1 | i guess its messy whichever way its done |
22:41.08 | bug1 | if we did have a usage.sgml, then wouldnt we just need to create a template and it would automatically convert it |
23:00.30 | psypete | andersee: thanx for your help eariler, looks like it's actually working :) |
23:30.27 | andersee | psypete: :-) |
23:32.25 | psypete | andersee: i don't see how... i'm only reaping when i execute the program (and it finishes very quickly) and then i thinki reap after the shell finishes, so i don't know how it keeps reaping, but w/e :-) |