irclog2html for #uclibc on 20021202

01:11.56*** join/#uclibc phpCure (foobar@h-69-3-1-45.MCLNVA23.covad.net)
01:18.32dsthe sparc port is in lousy shape
02:17.08mjn3ds: how bad is it?
02:22.42dsmjn3: I'm having a difficult time getting it to compile
02:23.26mjn3what is it dying on?
02:24.45dslots of stuff.  once I fix the syscalls.h problem, it complains about weak_alias(stat,stat64)
02:24.54dsbut mostly I was just venting
02:27.16mjn3ah... 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.29mjn3ds: 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.55dsok
02:56.01r0dzillagreetings
02:56.43r0dzillagot a busybox question...
02:57.17r0dzillagetting an error on busybox's init, at first it says can't run /etc/init.d/rcS: permission denied
02:57.28r0dzillaI correct the perms and reboot
02:57.34r0dzillanow it says the file is not there
03:02.53dsrcS probably invokes an interpreter.  Does that exist?
03:08.38r0dzillalet me check, was afk for a bit
03:09.19dserg.  I'm building on a sparc64 machine.
03:09.28dsI think I'll go cry now
03:09.29r0dzilla/bin/mount -av
03:09.29r0dzilla/bin/hostname RescueFloppy
03:09.53r0dzillahmmm...
03:09.58r0dzillaI may have found my problem...
03:10.00r0dzillalol
03:11.31r0dzillamount 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.03psypetehe-lo
07:44.21psypetei have a question
07:44.45psypetecould 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.31psypetehello?
13:38.09anderseemorning
13:40.42psypeteahhh
13:40.47psypetemy favorite person in the world
13:40.49psypetemorning
13:41.30psypeteandersee: i have a question about init :)
13:45.28psypeteandersee: 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.23anderseepsypete: you do not want to handle SIGCHLD directly.  Check out the latest version of busybox init.
13:54.50anderseepsypete: you simply want to add an extra while loop, comparable to the one at the end of bb init.
13:55.01andersee<PROTECTED>
13:55.01andersee<PROTECTED>
13:55.01andersee<PROTECTED>
13:55.01andersee<PROTECTED>
13:55.02andersee<PROTECTED>
13:55.02andersee<PROTECTED>
13:55.12andersee...
13:55.14andersee<PROTECTED>
13:55.14andersee<PROTECTED>
13:55.14andersee<PROTECTED>
13:56.16psypetehrmmm
13:56.31psypetewhere exactly does that go?
13:56.39psypeteis that the handler for SIGCHLD?
13:58.32anderseenonono.  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.52psypeteoh ok
13:59.07psypetewhere in particular would that loop go?
13:59.30psypete(since i have several programs executed from init including a shell as the last one executed)
14:03.52anderseepsypete: do take a look at the source
14:03.56anderseepsypete: http://busybox.net/cgi-bin/cvsweb/busybox/init/init.c?rev=1.178&content-type=text/vnd.viewcvs-markup
14:04.21anderseepsypete: Go to the very end of the file...  You will see a double while() loop
14:04.54anderseepsypete: Starting at "/* Now run the looping stuff for the rest of forever */"
14:05.21psypeteandersee: 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.52mjn3andersee: hey
14:10.18anderseemjn3: morning
14:11.07anderseeI had a nice weekend.  I'm feeling much more relaxed then I've been for a while.
14:12.11mjn3andersee: 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.06anderseeExcellent.
14:14.15anderseeHows the size looking?
14:14.44psypeteandersee: 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.57anderseepsypete: That is a big pile of junk to force a controlling terminal...
14:16.10psypete...which i think i need to run bash :)
14:16.27psypeteor more to the point, lash :)
14:17.45anderseepsypete: Actually, probably not.  I think I changed the run() function a bit since you made your mini-init
14:18.05psypeteHrm
14:20.09mjn3andersee: 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.20anderseeSeems fair...
14:22.31anderseeWhen one trims off the oddball ones like korean and ja_JP, do things get much smaller?
14:27.09mjn3i'm looking at 5 cases
14:27.35mjn31 - 102 locales based on iso16541_t1
14:27.59mjn32 - 14 locales "close to" en_CA
14:28.29mjn33 - the cs_CZ locale... not close enough to en_CA :-(
14:28.48mjn34 - ja_JP
14:28.49mjn35
14:28.53mjn35 - ko_KR
14:29.24mjn36 - (ok, i miscounted) ar_SA
14:31.17mjn3rough 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.26mjn3so, i might even wind up around 150k of collation data.  my target was < 200k because it was a "sufficiently round number"
14:39.04anderseehehe
14:39.10anderseeSounds good.
15:37.05mjn3andersee: 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.20anderseeThat works
15:41.34anderseeWould be more consistant to have them grouped there
15:42.20mjn3good enough
15:54.23anderseemjn3: BTW, are you planning on adding monetary.h?
15:57.27mjn3andersee: 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.35anderseek.  just noticed it was the only locale specific header file we seem to lack
15:58.44sandman_hi Erik
16:00.11sandman_andersee: Is there a time frame for the 0.61 release yet ?
16:00.56anderseesandman_: nope.  Though bug1 has been pushing to get things ready to release.
16:01.41anderseesandman_: 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.37mjn3andersee: yes, but all it is for is strfmon... so it will probably be a while before i get to it
16:04.16sandman_k .. how is the current state of unstable ?
16:04.45sandman_any applets that are _really_ unstable ?
16:05.54anderseesandman_: not really
16:06.05anderseesandman_: Though it could all use more testing I suppose
16:06.42sandman_I'll make a new package and let the familiar users test it then ;)
16:32.00mjn3andersee: ok.  i think search.h cleanup is finished
16:33.11anderseemjn3: cool
16:33.23anderseemjn3: I saw the commits.  That'll be good
16:34.58mjn3andersee: 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.43anderseek
16:35.49mjn3"very unbalanced trees" translates to "linked list" in the worst case
16:35.59anderseeI'm sure we'll get there
16:37.05mjn3as i recall, the auto-balancing approach adds about 1k or so.  but i could be wrong.  that was a while back
16:53.18waldiandersee: is it possible that you don't want to answer my questions?
16:59.55anderseewaldi: what questions?
17:00.10waldi"andersee: do you accept that i upload busybox-cvs with Maintainer: debian-boot and some Uploaders including yourself?"
17:00.14anderseewaldi: Did you email me?
17:00.21waldino
17:01.00anderseewaldi: I don't mind having such a busybox-cvs package
17:01.21waldiit exists in the cvs
17:02.55anderseewaldi: bug1 put together the busybox-cvs version
17:03.11waldiit is based on my patches
17:04.36anderseeAs I said, I don't mind such a package
17:07.13waldithan i will include the patches in the stable busybox and upload them
17:07.42anderseeWhat?
17:07.46anderseeNo no no
17:07.59anderseeYou said busybox-cvs, so I assumed devel
17:08.00waldithe problem is, we _need_ them
17:08.09anderseeWhat patches?
17:08.44anderseeYou are not being clear to me at all.  I thought you were talking about busybox devel....
17:08.44waldiip, some klog patches
17:11.26waldibusybox debian packages
17:11.36anderseewaldi: And ip is in the devel version of busybox.
17:11.44waldiyes
17:12.50anderseewaldi: 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.11anderseewaldi: Stable 0.60. is bugfixes only at this point
17:16.14waldiokay
17:17.08waldiandersee: i'll add you to uploaders
18:29.03anderseemjn3: toolchains will now build cross-compilers once again
18:38.57mjn3andersee: ok... (i haven't had any time lately to try them)
19:28.19*** join/#uclibc BZFlag (timr@rikers.org)
19:30.38anderseeBZFlag: how goes it?
19:50.53BZFlagas well as can be expected. ;-) vacation was nice.
20:00.57lucais it me or is lxdialog not in the .60.5 tarball?
20:04.03mjn3luca: yes
20:04.51mjn3luca: ;-)  seriously, stable busybox config is done by hand-editing
20:05.54lucathat's fine... i do hand edit Config.h
20:06.07lucabut this tarball has no lxdialog subdir in scripts
20:06.23lucai only happened to come across lxdialog by going through the CVS tree
20:06.43lucai'm just wondering why it is left out...
20:07.42mjn3luca: the cvs tree for .60.5 is busybox.stable whereas the busybox cvs tree is the unstable devel version
20:07.56lucaactually, there's a tonne of stuff in the devel tree
20:08.48lucamy 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.49bug1waldi: i commited a modified varient of your usage patch, havent tried it yet
20:59.38bug1its better to catch usage errors in the calling applet
21:01.38waldiokay
21:02.28waldihmm, why i aren't see your commits?
21:03.23waldiR debian/busybox-doc.docs
21:03.31waldiyou should remove that file
21:06.38bug1i think that some filesi n ./debian/ may not be tagged properly or something (but i dont know cvs very well)
21:08.17waldihmm? you shoudl commit into head
21:13.52bug1waldi: or maybe i just overlooked it, its gone now
21:15.13waldihmm
21:15.39waldii don't see your changes
21:16.54bug1do you see the patch to editors/vi and libbb/procps.c
21:17.32waldi<PROTECTED>
21:17.32waldi<PROTECTED>
21:17.33bug1i applied that after removing debian/busybox-doc.docs, if i do a cvs up busybox-doc.docs doesnt come back
21:17.59waldiplease try cvs status libbb/procps.c
21:18.33waldithe last change of this file is commited 2002/11/25
21:18.40anderseewaldi: Are you checking cvs.busybox.net or the public anoncvs mirror at busybox.net?
21:18.52bug1<PROTECTED>
21:18.53bug1<PROTECTED>
21:18.55waldi:pserver:anonymous@busybox.net:/var/cvs
21:19.03anderseewaldi: So there you go
21:19.11waldiokay
21:19.12anderseewaldi: It is synced every 4 hours
21:19.28anderseewaldi: I can run a sync manually for you, if you care
21:19.46waldiandersee: cvs.b.n doesn't permit pserver?
21:21.54waldi/var/cvs/busybox: no such repository
21:21.58waldiseems so
21:22.13anderseewaldi: 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.30waldi<g>
21:23.31waldiandersee: please include a sentence which mention this delay on busybox.net
21:23.55anderseeIt runs cvs and the mailing lists for busybox and uclibc...
21:25.55anderseewaldi: 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.28waldiandersee: why does the webinterface don't use the mirror?
21:26.39waldithan it shouldn't be a problem
21:28.23anderseewaldi: 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.56waldibug1: the ip command should be in /bin, not /sbin
21:34.14waldithe position has some historical reasons
21:34.20bug1ok
21:35.08bug1i assume thats the same for iplink etc
21:36.17waldiits a little bit unclear
21:36.32waldithe debian package installes only the ip binary in bin
21:37.05bug1best to keep them all in the same directory anyway i think
21:38.13bug1i like the seperate ip commands
21:38.26waldiwhy?
21:38.58bug1i think its nicer not having to use extra options in ip
21:39.03bug1more direct
21:39.20waldii use always ip with the extra options
21:40.24bug1and the default value does something usefull without any options at all
21:40.57bug1b.t.w. i managed to save a few hundred bytes on ip yesterday
21:41.13waldii saw it
21:41.27bug1do you like the  way i did it :)
21:41.51waldii don't try to read the diff completely
21:43.06bug1ahh... 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.36waldiandersee: why aren't the usage messages include in the applets struct?
21:45.27bug1andersee: and while your about, how is busybox.sgml created ?
22:02.15anderseewaldi: It is.  Or at least a pointer to it is.
22:05.08anderseebug1: docs/autodocifier.pl
22:07.03anderseebug1: It should go something like
22:07.06andersee<PROTECTED>
22:07.06andersee<PROTECTED>
22:07.06andersee<PROTECTED>
22:07.52bug1yea, i saw that, i tried using autodocifier -sgml usage.h and it just produced a heap of <fixme>tag</fixme> stuff
22:09.01bug1or is busybox.sgml created from busybox.pod
22:09.13anderseebug1: Hmm.  I guess we should fix it sometime.  Or switch to using something else.
22:24.02bug1looking at autodocifier in cvs, i dont see how it has ever produced busybox.sgml
22:25.40anderseebug1: 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.06anderseebug1: I guess I lied about autodocifier.pl earlier.
22:26.18anderseebug1: Guess I'm getting old
22:26.42bug1hehe
22:27.40bug1you sound like vodz, hes always refering to himself as old
22:29.47bug1it must have taken a while to do busybox.sgml by hand
22:35.07anderseeI copied/pasted most of the content from the .pod
22:35.55anderseeThat was before the generation of the .pod was automated
22:39.15bug1maybe 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.14bug1i guess its messy whichever way its done
22:41.08bug1if we did have a usage.sgml, then wouldnt we just need to create a template and it would automatically convert it
23:00.30psypeteandersee: thanx for your help eariler, looks like it's actually working :)
23:30.27anderseepsypete: :-)
23:32.25psypeteandersee: 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 :-)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.