**** BEGIN LOGGING AT Wed Jul 13 23:59:57 2005 Jul 14 01:13:23 hm.. optware Jul 14 01:13:35 mhm.. Jul 14 01:14:05 old stuff? Jul 14 01:14:29 hm, isn't that the old unslung packages? Jul 14 01:14:41 looks like it could be that Jul 14 01:15:27 optware is new name for packages for unslung and wl500g Jul 14 01:15:28 I never used the nslu2 for what its meant for, and I never used unslung Jul 14 01:16:03 ah yes, or course Jul 14 01:16:07 :) Jul 14 01:18:47 anyone have experience with the quality of this webcam? http://cgi.ebay.com.au/ws/eBayISAPI.dll?ViewItem&item=5218362688&ssPageName=ADME:B:BN:AU:1 Jul 14 01:29:27 hm.. no subversion package in openslug? Jul 14 01:33:08 not yet ... Jul 14 01:33:37 should be easy for you to port from optware ... Jul 14 01:33:40 :-) Jul 14 01:33:44 :) ok Jul 14 02:25:11 * kolla_ struggles to get portage working on the slug :/ Jul 14 03:27:36 Hi, anyone doing native compiling on you slug here? Jul 14 03:27:45 yes Jul 14 03:27:50 on openslug Jul 14 03:28:21 openslug yepp;) Jul 14 03:28:38 2.0 beta Jul 14 03:29:03 Im on, well, whatever the latest in monotone is caled Jul 14 03:29:17 2.2-beta at the moment Jul 14 03:29:23 ah Jul 14 03:29:33 (plus deltas) Jul 14 03:30:05 k, I have planned to moved to csv, but I wanted to give the binaries a try first. Jul 14 03:30:22 Good Plan Jul 14 03:30:37 yup, I started playing with 2.0 beta too Jul 14 03:32:17 I can't get gcc to work;( Jul 14 03:32:46 have you looked at: http://www.nslu2-linux.org/wiki/HowTo/OpenSlugNativeCompileEnvironment ? Jul 14 03:32:50 Seems like the ld or as is broken/missing. Jul 14 03:33:05 Yes, Jul 14 03:33:27 adn you have done everything in http://www.nslu2-linux.org/wiki/HowTo/OpenSlugDevInst ? Jul 14 03:33:36 It basically says pull it from csv. Jul 14 03:34:38 binutils is missing from the feeds (still trying bin relase);) Jul 14 03:35:03 ah, yes.. I set up a cross build for that Jul 14 03:35:19 but then moved to 2.2 beta where it is in the feed Jul 14 03:35:40 (but Im still running from my own cross built packages) Jul 14 03:36:29 ah Jul 14 03:36:46 NAiL: are there some binutils for 2.0 beta? Jul 14 03:36:47 Hmm, I see you point. Jul 14 03:36:56 DaKa2: There soon will be Jul 14 03:36:59 and gnu-config too Jul 14 03:37:04 :) Jul 14 03:37:24 then OpenSlugNativeCompileEnvironment could be trimmed down, alot Jul 14 03:38:04 All I need is a working as;) Jul 14 03:38:20 as == binutils Jul 14 03:38:26 so.. Jul 14 03:38:29 yepp Jul 14 03:38:57 Seems like I need to pull it from monotone. Jul 14 03:39:00 but NAiL seems to be adding binutils Jul 14 03:39:08 yes Jul 14 03:39:28 Ah, cool. When? Jul 14 03:39:59 Should be in the feed shortly, after I've compiled them and pushed Jul 14 03:40:13 Konge! Jul 14 03:40:24 i.e. great work man! Jul 14 03:40:33 joda, forstår ;-) Jul 14 03:40:41 03repvik * r85 10/releases/OpenSlug-2.0-beta/openembedded/packages/meta/openslug-packages.bb: Added binutils & gnu-config for native dev Jul 14 03:40:46 nice Jul 14 03:41:14 Ah, another .no Jul 14 03:41:15 * NAiL looks at that empty bottle of tuborg on his desk Jul 14 03:41:36 or .dk? Jul 14 03:41:48 netname: BROADNET-NO-INKUBATOR Jul 14 03:41:48 descr: Inkubator Sundland AS Jul 14 03:41:48 country: NO Jul 14 03:42:03 ah Jul 14 03:42:12 yepp, anywhere near you? Jul 14 03:42:30 * DaKa2 -> .se Jul 14 03:42:36 Nail? Jul 14 03:42:39 TRD Jul 14 04:00:36 Tuborg: mkdir -p /home/slug ; cd /home/slug ; wget http://www.nslu2-linux.org/Makefile ; make setup ; make build-openslug Jul 14 04:01:09 thx Jul 14 04:02:01 Got to install monotone first;) Jul 14 04:02:10 Is there any way of getting samba to just use /etc/passwd instead of needing it's own smbpasswd ? Jul 14 04:02:15 Tuborg: make sure it's 0.19 Jul 14 04:04:19 k, thx. Jul 14 04:06:07 rwhitby: nopes, because of hash differences Jul 14 04:06:21 rwhitby: you can learn PAM to do samba though ;) Jul 14 04:06:27 (or ldap or other stuff) Jul 14 04:08:06 Fuzzel: thx Jul 14 04:11:46 afaik the netgear stuff simply puts the same password into both the db's Jul 14 04:13:52 netgear? you mean linksys right? Jul 14 04:15:37 collect2: ld returned 1 exit status => 2.0 beta binaries;( Jul 14 04:16:02 which is why using 'passwd' does update the /etc/paswd but no the samba one Jul 14 04:17:45 well, I manage a 1300 user network with a script that sets the password with both passwd and smbpasswd :) Jul 14 04:18:12 should have gone for ldap, but hey.. simplicity Jul 14 04:18:22 Bye ppl. Thanks for you help. Jul 14 04:18:35 bye Jul 14 04:20:05 poor users ;) Jul 14 04:21:15 :) they are happy, changing passwords on a nice webpage, integrated with the rest of the intranet Jul 14 04:21:46 and, it works, 24/7/365 Jul 14 04:23:04 NAiL: what's the status of php and apache/thttpd on openslug? Can I use it to serve content to my Neuston now? Jul 14 04:23:45 Probably non-working. g2 has been working on compiling them natively and was going to package them up. Jul 14 04:24:01 thttpd has some minor issues re. paths, which I'm going to fix today Jul 14 04:24:36 <[g2]> rwhitby, php5 builds with file and a libtool upgrade Jul 14 04:24:49 <[g2]> I'd like to get something like that into the feed Jul 14 04:25:13 [g2]: we're still waiting for a decision on option 1 vs option 3 .... Jul 14 04:25:46 (for the openslug native feed). I guess that's NAiL's decision now :-) Jul 14 04:26:20 Which options are you talking about? Jul 14 04:27:05 daka: ah well if they are happy then it is good :) Jul 14 04:27:15 Option 1 is taking optware, and making it work for openslug native. Option 2 is taking the bitbake/oe and making it work for openslug native. Option 3 is creating yet another build environment for openslug native. Jul 14 04:27:17 daka: and basically they get a single password for everything indeed Jul 14 04:27:23 exactly Jul 14 04:28:11 rwhitby: the whole shebang? Or just a few packages? Jul 14 04:28:30 NAiL: just those packages which can't be built cross - same deal as optware. Jul 14 04:28:33 <[g2]> NAiL, just the packages that don't build in OE Jul 14 04:28:36 aha Jul 14 04:28:57 <[g2]> We should have a distro discussion Jul 14 04:29:06 I like option 2... bb openslug-native Jul 14 04:29:11 :) Jul 14 04:29:26 but I wouldn't want to make that work :) Jul 14 04:29:33 although if apache builds fine cross for optware, then it should be possible to replicate that for openslug cross Jul 14 04:29:37 <[g2]> Actually option is just about ready to go Jul 14 04:30:14 [g2]: option 2 requires bitbake to be option 2. otherwise it's option 3. Jul 14 04:30:41 <[g2]> ok... I think 1 and 3 are not too far off Jul 14 04:30:52 rwhitby: yeah, that's what I thought too. For me, it looks like option 1 is the easiest Jul 14 04:31:08 <[g2]> On option 3 there's a scripts that runs and does a full native setup Jul 14 04:31:29 [g2]: yeah, the bootstrapping is nearly all in place. that's why it's time to put the build infrastructure around those tools. Jul 14 04:31:36 <[g2]> and from that everything is ready to be built natively Jul 14 04:31:42 <[g2]> and has been tested Jul 14 04:31:54 <[g2]> 100% perl tests success Jul 14 04:32:09 <[g2]> I even ran cpan the other day Jul 14 04:32:23 [g2]: you're still taking about the tools required to do native builds, as opposed to the native build infrastructure. Please keep those two concepts separate. Jul 14 04:32:38 <[g2]> I am Jul 14 04:33:08 <[g2]> I want to focus on the build infrastructure and its objective Jul 14 04:33:23 <[g2]> hence the distro talk Jul 14 04:33:35 ok, we need to nail down terminology then. Jul 14 04:33:49 To do native builds, you need a number of things: Jul 14 04:33:59 1/ A compiler and assorted other tools Jul 14 04:34:16 2/ A set of source files and patches for the package you want to build Jul 14 04:34:43 3/ A build infrastructure which takes the tools, and builds the package, and packages the result, and uploads it to the feed. Jul 14 04:34:58 <[g2]> check, check, check Jul 14 04:35:33 how far of is bitbake from working on the slug? Jul 14 04:35:45 when I talk about options 1, 2, 3, I'm talking about the latter two items, not the compiler and other assorted tools. Jul 14 04:36:07 <[g2]> actually 3 does drive 1 Jul 14 04:36:18 <[g2]> here's are 2 examples Jul 14 04:36:34 agreed. there is a set of required tools that are needed for the build infrastructure to operate. Jul 14 04:36:49 and I think you have bootstrapped just about all the required tools. Jul 14 04:36:50 <[g2]> with out the "file" tool working libphp5.so doesn't build Jul 14 04:37:04 right. "file" is one of the required tools Jul 14 04:37:31 that's independent of which option (1, 2, or 3) is chosen for the build infrastructure. Jul 14 04:37:31 <[g2]> with gzip cpan doesn't work with perl and the busybox gzip needs replaced Jul 14 04:38:03 agreed. again, another case of specific required versions of required tools. Jul 14 04:38:50 <[g2]> well the point was much of the busybox functionality is replaced with native development Jul 14 04:39:11 <[g2]> so for that release it probably shouldn't be there to begin with Jul 14 04:39:37 working out the required tools, and how to bootstrap them is a hard problem, but it is one which does not require a lot of discussion cause the set of required tools makes itself evident quite readily. Working out the set of required tools is not the question I am asking. Jul 14 04:40:13 <[g2]> I fully understand that Jul 14 04:40:28 deciding on the build infrastructure (which drives, but is completely orthogonal to, the set of required tools) is what we need to do soon ... Jul 14 04:41:25 <[g2]> I fully agree on the deciding, I think its only 98% orthogonal Jul 14 04:41:40 <[g2]> we don't need to discuss that 2% now Jul 14 04:42:08 <[g2]> we do need to discuss the infrastructe and it's goals Jul 14 04:42:22 when you said "On option 3 there's a scripts that runs and does a full native setup" you're talking about an automated way of getting the complete set of required tools, right? Jul 14 04:42:42 which is different from the native build infrastructure, right? Jul 14 04:42:43 <[g2]> right Jul 14 04:43:08 <[g2]> well it's a simple as running a script or adding that as an ipkg install Jul 14 04:43:35 ok, that's what confused me, cause those scripts or ipkg install are required independent of which option (1, 2, or 3) is chosen. Jul 14 04:46:16 <[g2]> so are you clear I was just talking about an option that would work for 1 and 3 equally well Jul 14 04:52:48 an option of installing the correct set of required tools, or an option for the build infrastructure? Jul 14 04:53:36 I'm having slight problems parsing this discussion Jul 14 04:53:37 <[g2]> the install fully satisfies 1/ A compiler and assorted other tools Jul 14 04:53:37 * rwhitby is helping teach a baby to go to sleep by herself, so responses may be delayed at times .... Jul 14 04:54:06 [g2]: nod. OK, I think we're in sync on the terminology Jul 14 04:54:11 <[g2]> pls give baby lots of hugs, kisses, and love from us Jul 14 04:54:49 <[g2]> rwhitby, it *could* also handle 3's tools and sw but that's not necessary Jul 14 04:55:30 <[g2]> how about we call those items Jul 14 04:55:48 <[g2]> NB 1 - for Native Build 1 compiler and assorted tools Jul 14 04:56:10 <[g2]> NB 2 - Native build source and patches Jul 14 04:56:30 <[g2]> NB 3 - Native build infrastructure envrion Jul 14 04:56:58 <[g2]> as opposed to option 1, 2, 3 for the Native Build approach Jul 14 04:59:42 ok, Jul 14 05:00:18 so the OE metadata, and the optware .mk files and source dir contents, are two different ways to approach NB 2 Jul 14 05:00:46 and bitbake, and the optware top-level Makefile, are two different ways to approach NB 3 Jul 14 05:01:08 <[g2]> I think I can probably run bitbake on my slug now Jul 14 05:01:23 <[g2]> I was thinking about giving it a try today Jul 14 05:01:52 and for NB 1 we currently only have a wiki page for optware, and similarly for openslug native (independent of NB 2 and NB 3) Jul 14 05:03:06 and the solution for NB 1 is independent of the solutions for NB 2 and NB 3. i,e, a single openslug-native-dev-tool.ipk could do it. Jul 14 05:03:48 rwhitby: re. thttpd: It works, but lacks an init script yet. Jul 14 05:03:54 <[g2]> rwhitby, right I'm just being a little pedantic about the contents of that Jul 14 05:04:04 for NB 2, my position is that we do *not* want to create yet another source of metadata for package build source and patches, so we either choose the OE metadata or the optware metadata. Jul 14 05:04:36 and the solution for NB 2 may well drive the solution for NB 3. Jul 14 05:07:14 <[g2]> monotone built cross for me on openslug this morning Jul 14 05:08:17 <[g2]> IMHO I don't think we should use monotone on the slug unless we take over the unused NPE for the MD5/SHA1 computations Jul 14 05:08:29 <[g2]> the pulls will take forever Jul 14 05:08:38 I copied my monotone db from my cross build to the slug Jul 14 05:09:02 then things are fast Jul 14 05:09:21 [g2]: Can't do that for the nslu2 Jul 14 05:09:40 <[g2]> right ... but a SVN version of the db for native packages would work Jul 14 05:09:55 The NPEs in the IXP420 can't do SHA1/MD5 Jul 14 05:10:21 IXP422 or IXP425 only Jul 14 05:10:27 <[g2]> I know they don't have hw but it's another 133Mhz/266Mhz processor with DMA right ? Jul 14 05:10:47 <[g2]> I know only the 422/425 have the crypto hw Jul 14 05:10:49 Well. In theory it is but it's not documented anywhere at all so you'd have to reverse engineer everything Jul 14 05:11:14 <[g2]> actually lennert mention he's got an alpha NPE debugger on lak Jul 14 05:11:20 We've got nothing. The microcode is a big binary blob and the bit that talks to the NPE is a big binary library Jul 14 05:11:24 Oh? Jul 14 05:11:31 <[g2]> couple weeks ago Jul 14 05:12:17 <[g2]> I'm just saying for ppl with absolutely nothing to do and plenty of time on their hands Jul 14 05:12:34 Lots and lots of time on their hands :) Jul 14 05:12:35 <[g2]> and quite sharp technically Jul 14 05:13:09 <[g2]> versed in assembler and multiprocessing Jul 14 05:13:34 Wonder how Lennert did it Jul 14 05:14:29 <[g2]> well he probably learned a bunch when he fixed the NPEs booting across the backplane, but I digresss Jul 14 05:14:48 Yeah but still... It's a huge leap in knowledge Jul 14 05:14:56 <[g2]> not really Jul 14 05:15:10 Public knowledge about how the NPEs work is basically nil Jul 14 05:15:48 Might have to go have a talk with him at some point Jul 14 05:15:59 <[g2]> Well I don't know for sure about the Intel NPEs Jul 14 05:16:39 <[g2]> I was the sole network processor guy for 14 months on a product using the Vitesse IQ2000 Jul 14 05:17:08 <[g2]> we did gigabit networking Jul 14 05:17:53 <[g2]> I really liked the Vitesse chip and I'm sure the Intel one is different in the specifics, but more common in general Jul 14 05:19:12 <[g2]> I decide a year ago I wasn't going to munge around in there, so I'm munging with build infrastructure, JTAG, etc... Jul 14 05:19:47 03nail 07org.openembedded.nslu2-linux * red9017c6... 10/packages/thttpd/ (files/init thttpd_2.25b.bb): Added initscript Jul 14 05:20:26 [g2]: nod on the having to export build infrastructure to slug via cvs or svn or rsync from a desktop server Jul 14 05:20:52 we can serve it down from a desktop server using NFS or something too .... Jul 14 05:21:02 <[g2]> so we may be able to run bb Jul 14 05:22:15 one idea is to have a set of very small symlink dirs, and an external toolchain. So to compile apache, you point BBFILES to an "apache" subset of oe-symlinks in it's own subdir, so that bb only sees a few bb's to parse. Jul 14 05:22:45 then there is a top-level Makefile which just cycles through each of those mini-BBFILES dirs, and runs a bitbake in each. Jul 14 05:25:45 <[g2]> rwhitby, the mechanics of the external toolchain and its implementation is an OE issue to look into Jul 14 05:26:18 [g2]: I did an external toolchain for asusoe - there is a machine and distro file for it in place. Jul 14 05:26:31 <[g2]> DaKa2, you wanted to focus on getting stuff built in OE right ? Jul 14 05:26:48 we would ipkg install the toolchain, and then just point the native build infrastructure to it Jul 14 05:27:21 <[g2]> rwhitby, I'm not clear about the dependency handling for all the bb tools Jul 14 05:29:10 what I am suggesting is that for building apache, we would have an "apache" symlinks dir, which was a separate subset copy (in a separate directory) of oe-symlinks, and which only contained the dependency tree for apache. So maybe it would contain less than 10 symlinks (i.e. less than 10 .bb files for bitbake to parse) Jul 14 05:29:41 that should reduce the memory requirements of the bitbake build to something manageable with swap Jul 14 05:29:52 is that what you were asking about? Jul 14 05:30:22 for the external toolchain, look in conf/distro/asusoe.conf and conf/machine/wl500g.conf Jul 14 05:30:32 <[g2]> apache depends on the virtual machine and virtual glibc Jul 14 05:30:35 <[g2]> right ? Jul 14 05:30:47 I think INHIBIT_DEFAULT_DEPS is the key to breaking those deps. Jul 14 05:31:07 <[g2]> so it just runs the native stuff then ? Jul 14 05:32:19 Hmm - dunno. I guess this is different from asusoe, cause I was doing an external toolchain to cross compile packages, whereas here we want to use an external toolchain to native compile packages Jul 14 05:32:54 but I guess native compilation is just a degenerative case of cross compilation .... Jul 14 05:33:00 <[g2]> nod Jul 14 05:33:27 <[g2]> so I think your subset idea would work now for apache if it was in OE Jul 14 05:33:50 <[g2]> I think we should Jul 14 05:34:03 <[g2]> 1) build thttpd-php5 nativiely Jul 14 05:34:27 <[g2]> 2) try to setup the subset to build and package those natively Jul 14 05:34:46 <[g2]> both with a simple makefile and with bitbake if it runs Jul 14 05:35:08 sounds like a plan to me Jul 14 05:35:20 <[g2]> we could do apache-php5 too as I've already did that natively Jul 14 05:35:39 <[g2]> s/did/done/ Jul 14 05:36:16 we can put the mini-symlinks dirs in the normal svn repo, in a sibling set of subdirs of oe-symlinks/native/foo/packages/ Jul 14 05:36:39 where "foo" is the target package (i.e. apache) Jul 14 05:37:11 and the lowest-level packages directory (under native/foo) contains symlinks for apache and any other packages that it depends on for the native build. Jul 14 05:37:19 <[g2]> I think before deciding that we should see if it runs and how big the footprint is Jul 14 05:37:41 then there is a separate oe-symlinks/native/bar/packages/.... dir for the second target package Jul 14 05:37:55 agreed re prototyping first Jul 14 05:38:23 but let's do the prototyping in-place where we can ... Jul 14 05:39:40 ok, night all. thx for the discussion [g2] Jul 14 05:39:59 <[g2]> ok Jul 14 05:40:12 <[g2]> sweet dreams to you, baby and all Jul 14 06:14:00 03nail 07org.openembedded.nslu2-linux * rd32f204f... 10/packages/ (3 files in 3 dirs): Jul 14 06:14:00 Updated initscript Jul 14 06:14:00 Added thttpd to packages Jul 14 06:15:40 What's the latest change to openslug-packages.bb? I got a 3-way merge on it (although I never even opened it!) and I'm unsure which version to use. Jul 14 06:15:52 Just added thttpd Jul 14 06:16:37 before that. mgetty was added or removed i think Jul 14 06:16:49 postfix and mpd too Jul 14 06:17:30 postfix and mpd were added Jul 14 06:17:35 ok. Jul 14 06:18:32 Great Monotone crashed with an error! Jul 14 06:18:53 what error? Jul 14 06:19:43 monotone: fatal: std::logic_error: change_set.cc:487: invariant 'I(j != deltas.end())' violated Jul 14 06:19:43 monotone: Jul 14 06:19:43 monotone: this is almost certainly a bug in monotone. Jul 14 06:19:43 monotone: please send this error message, the output of 'monotone --full-version', Jul 14 06:19:43 monotone: and a description of what you were doing to monotone-devel@nongnu.org. Jul 14 06:19:44 monotone: wrote debugging log to MT/debug Jul 14 06:19:46 make: *** [update-openembedded] Error 3 Jul 14 06:20:04 brilliant Jul 14 06:20:10 I hate that thing already! Jul 14 06:20:49 I don't understand why you're having problems... Jul 14 06:21:19 I wish I did! Jul 14 06:21:53 ANd worst, I've never touched those f'n files. And I pull everyday so It's not like my repo is ancient. Jul 14 06:22:12 That's strange Jul 14 06:22:36 I pull several times a day, and I haven't experienced that problem yet Jul 14 06:23:01 well, at least I know I'm not alone as jbowler-away and others had similar issues. Jul 14 06:23:26 yeah Jul 14 06:23:29 not that I'm surprised, monotone is far from mature. Jul 14 06:25:15 03repvik * r86 10/releases/OpenSlug-2.0-beta/openembedded/packages/thttpd/ (files/init thttpd_2.25b.bb): Pushing updated thttpd to stable Jul 14 06:25:27 would be nice if we could at least upgrade to latest released version Jul 14 06:25:48 yeah, but that does require some amount of synchronization though Jul 14 06:27:50 jacques, Are you talking about monotone or? Jul 14 06:29:29 * [g2] notes bb running on Fatslug -- NOTE: Handling BitBake files: \ (0054/2545) [ 2 %] Jul 14 06:29:48 How fast is that going? Jul 14 06:29:51 ouch, that's gonna take a while Jul 14 06:30:13 what? are you guys crazy? bb on the slug? It's slow even on my dual xeon! Jul 14 06:30:28 <[g2]> Tiersten, pretty slow Jul 14 06:30:30 must be horribly slow. Jul 14 06:30:32 * jacques thinks [g2] should use symlinks Jul 14 06:30:47 Or clear his calendar for the next day or two Jul 14 06:30:49 <[g2]> jacques, I will this is just the stress test Jul 14 06:30:52 what's the advantage of doing it on the slug? Just for the challenge? Jul 14 06:31:02 <[g2]> VoodooZ_work, native packaging Jul 14 06:31:12 i see. Jul 14 06:31:22 <[g2]> I guess you didn't see the log today :) Jul 14 06:31:34 okay I guess I'm the only person that thinks running oe/bitbake stuff on the nslu2 is not practical. Jul 14 06:31:34 [g2], did you have weird 3-way merges with monotone lately? Jul 14 06:31:46 <[g2]> several Jul 14 06:31:55 especially after hearing eno story of monotone taking 2 *days* to sync. Jul 14 06:31:58 <[g2]> usually from my changes Jul 14 06:32:00 I'm trying to read it but real life (work) is cutting in. Jul 14 06:32:22 <[g2]> dyoung, we'd rsync the monotone updates Jul 14 06:32:33 <[g2]> I tarballed the openembedded dir Jul 14 06:32:57 Good Plan Jul 14 06:33:03 mt is driving me nuts right now as it crashed after yet another stupid 3-way merge. Jul 14 06:33:13 running monotone today on a nslu2 is not practical. Jul 14 06:33:16 <[g2]> NOTE: Handling BitBake files: | (0146/2545) [ 5 %] Jul 14 06:33:39 <[g2]> that's nearly 25% of the full openslug package build Jul 14 06:33:45 heh I was just about to say that Jul 14 06:34:00 * [g2] tarballs up the symlinks Jul 14 06:34:04 [g2], this on a turboslug? Jul 14 06:34:20 <[g2]> nod fatturbo Jul 14 06:34:26 is monotone 0.20 safe? Jul 14 06:34:40 * VoodooZ_work checks the changelog Jul 14 06:36:35 VoodooZ_work, No. Jul 14 06:36:51 0.19 and 0.20 repos cannot be netsynced. Jul 14 06:36:56 (with each other) Jul 14 06:37:17 they say that the db and working copies are fully compatible and only the netsync clients and servers need updating. Jul 14 06:37:55 which is why both us and the rest of oe needs to switch at the same time Jul 14 06:38:08 true. Jul 14 06:38:50 I guess I won't bother with it for a few weeks until things stabilize then. Jul 14 06:39:22 03nail 07org.openembedded.nslu2-linux * r5254e94c... 10/ (15 files in 14 dirs): Jul 14 06:39:22 propagate from branch 'org.openembedded.dev' (head fb87c6675723cb138a41ecb1b79ceae9fcd25754) Jul 14 06:39:22 to branch 'org.openembedded.nslu2-linux' (head d32f204f274e9d1d693eb680d1de4e3807521227) Jul 14 06:39:50 [g2]: I want to focus on getting stuff built in OE, yes Jul 14 06:40:57 kindoff missed that whole discussion, didn't I? :-) Jul 14 06:41:09 <[g2]> no it's logged right ? Jul 14 06:41:11 <[g2]> :) Jul 14 06:41:23 yep Jul 14 06:42:47 [g2]: The problem-packages are apache, perl and php, right? Jul 14 06:42:56 <[g2]> right Jul 14 06:43:11 <[g2]> I'd focus on php5 right now Jul 14 06:43:34 <[g2]> and then try thttpd-php5 or move on to apahce-php5 Jul 14 06:43:47 I haven't even looked at php yet. Jul 14 06:43:50 but all their deps can be cross built? right? Jul 14 06:43:52 <[g2]> I've got apache 2.0/php5 building and running natively Jul 14 06:44:12 <[g2]> it's tricky Jul 14 06:44:42 so you only need to ipkg all of the deps, and then bb a single file? Jul 14 06:44:45 <[g2]> I could be all wrong here, but I think we need to patch all the .la files build to match the native version Jul 14 06:45:02 Ow... Jul 14 06:46:07 <[g2]> Oh.. now just parsing openslug bb's Jul 14 06:46:25 <[g2]> NOTE: Handling BitBake files: \ (0014/0637) [ 2 % Jul 14 06:46:37 well, you would only have to parse one file Jul 14 06:46:49 <[g2]> for what PHP5 ? Jul 14 06:46:53 Has anyone tried setting up distcc? Jul 14 06:47:07 since all the deps should be able to be cross built Jul 14 06:47:30 I havn't tried php5 Jul 14 06:47:42 <[g2]> did you run php ? Jul 14 06:47:54 not on the slug Jul 14 06:47:58 but I plan on doing that Jul 14 06:48:04 <[g2]> cause perl builds but dies on execution Jul 14 06:48:19 hm.. thats no good.. Jul 14 06:48:34 <[g2]> well cross is still some black-magic Jul 14 06:50:06 <[g2]> NOTE: Handling BitBake files: | (0101/0637) [15 %] Jul 14 06:50:11 :) Jul 14 07:04:21 question: in GCC is there a way to force a structure/variable to be kept in cache/registers to speed things up? like the register operator? Jul 14 07:04:56 Not for a whole structure no Jul 14 07:04:57 I want to avoid the hit of going out to RAM on every iterations. Jul 14 07:05:41 not even a small one? Jul 14 07:05:58 <[g2]> VoodooZ_work, is it a very small function ? Jul 14 07:06:15 <[g2]> inline it Jul 14 07:06:18 Nope. Consider how many registers the average processor has Jul 14 07:06:43 "register" doesn't force it anyway. It's more of a suggestion Jul 14 07:07:13 ok. Jul 14 07:07:13 This running on the NSLU2? Jul 14 07:07:48 <[g2]> I think openslug OE metadata will fit in 64MB Jul 14 07:07:55 Use the mini data cache if so Jul 14 07:07:57 [g2]: Cool Jul 14 07:08:21 It's a morphological erosion operation so it compares a 3*3 matrix over all pixels of a 320x240 image so the overhead of reading the RAM really shows. Jul 14 07:08:24 <[g2]> compiling would suck but it's pretty amazing that all the parsing is in memory Jul 14 07:09:01 I can't expect to put the image in cache but I wanted to check if storing the structuring element (3x3 matrix) could be stored in cache. Jul 14 07:09:07 <[g2]> NOTE: Handling BitBake files: / (0571/0637) [89 % Jul 14 07:09:14 It's a really small function. Jul 14 07:09:24 <[g2]> then inline it Jul 14 07:09:59 4 nested for loops: for y --- for x --- for i -- for j Jul 14 07:10:19 I'll try but the function itself is not called often. Just the loop. Jul 14 07:10:25 <[g2]> well we may have different ideas about small :) Jul 14 07:10:45 hehe Jul 14 07:10:45 <[g2]> nod on the function Jul 14 07:11:48 I just want to avoid the overhead of reading the ram inside the loops. Jul 14 07:12:10 <[g2]> hey... Jul 14 07:12:21 <[g2]> NOTE: package quilt-native-0.39: started Jul 14 07:12:21 <[g2]> NOTE: package quilt-native-0.39-r0: task do_fetch: started Jul 14 07:12:21 <[g2]> NOTE: fetch http://www.oesources.org/source/current/quilt_savannah.nongnu.org_VER_0_39_.tar.gz Jul 14 07:12:21 <[g2]> wget: invalid option -- t Jul 14 07:12:21 <[g2]> BusyBox v1.00 (2005.07.02-01:41+0000) multi-call binary Jul 14 07:12:22 How would using the minicache be done? Jul 14 07:13:37 -t is for the number of retries I think Jul 14 07:15:42 [g2], do you know of a place where I could find an example of using the cache in gcc? Jul 14 07:16:38 <[g2]> the minicache ? Jul 14 07:17:49 Sorry, I gues Tiersten is the one that suggested that. Jul 14 07:18:02 Tiersten, the question is addressed to you then. :) Jul 14 07:19:45 Is it even possible to force a piece of data to be stored in the cache under GCC? Jul 14 07:20:14 If I had a lead I could google it. otherwise I might be chasing my tail as GCC is huge. Jul 14 07:20:38 mmap it Jul 14 07:20:49 then just dereference a pointer to it Jul 14 07:20:55 assuming your data fits into it anyway Jul 14 07:21:10 I see. Jul 14 07:21:32 top of your head: do you know the address? Or is this on the wiki? Jul 14 07:22:03 It's in the IXP docs Jul 14 07:22:54 ok, thanks. Jul 14 07:24:00 It should give me a pretty good speed boost as that little 3x3 matrix is in the inner loop so it gets referenced 320x240x3x3 times! Jul 14 07:24:39 brb Jul 14 07:27:09 VoodooZ_work: You have to be root BTW Jul 14 07:45:43 yep. no problem Jul 14 07:46:09 Actually, I was wondering. Who manages that mini-cache normally? the kernel? What does it use it for normally? Jul 14 07:49:13 hmm Jul 14 07:49:49 me notices a bulging capacitor on his old dev box mobo. Jul 14 07:51:24 Tiersten, I found a page that says: ffff8000 ffffffff copy_user_page / clear_user_page use. Jul 14 07:51:24 For SA11xx and Xscale, this is used to Jul 14 07:51:25 setup a minicache mapping. Jul 14 07:51:35 would copy_user_page be related? Jul 14 07:53:10 they're kernel functions Jul 14 07:53:28 I tihnk just using mmap on /dev/mem should work... Jul 14 07:53:31 (Not that I've tried) Jul 14 07:53:59 You're living life on the edge however if anything does go wrong in your app since you can cause major breakage Jul 14 07:57:17 I just read something about internal SRAM. Is this the same as the mini-cache? Jul 14 07:57:59 If it's 2KB then yes Jul 14 07:58:14 check http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-February/019620.html. There's a guy telling how to map it. Jul 14 08:01:56 The mini data cache might be used then already. If so then you can't use it obviously. Jul 14 08:02:01 you'll need to check the kernel Jul 14 08:02:20 ok. thanks Jul 14 08:03:39 Sorry. Would be more helpful but I'm busy with work at the moment Jul 14 08:04:59 No problems mate. I can do the research. Jul 14 08:05:41 I'm reading the source right now and copypage-xscale.c says the minicache is used for it. Jul 14 08:05:56 ah Jul 14 08:06:07 You're a bit stuck then Jul 14 08:06:43 I doubt they've left some out. Jul 14 08:07:19 I'll have to read more on copypage Jul 14 08:07:42 It's used to copy data to and from the kernel space from user space Jul 14 08:08:00 ok. I think I remember seeing that in my webcam driver. Jul 14 08:08:27 So that can't be used for me then. Jul 14 08:10:55 It's hard to tell if it's all used up as it's all assembly code. :( Jul 14 08:30:43 I messed up my slug last night while troubleshooting an Apache problem -- had to re-flash to get it working again. I want to find out what I did wrong before I resume troubleshooting. Can anyone offer advice? Jul 14 08:32:08 You probably filled up the flash Jul 14 08:32:57 Yes, I suspected that. The slug's top light was blinking endlessly. Jul 14 08:33:17 Did you have debugging turn on or something? The logs? Jul 14 08:34:05 I was running Apache with the "httpd -X" option. Jul 14 08:35:40 I notice with "df" that "/dev/sda1" mounted on "/initrd" is 82% used. What does that mean? Jul 14 08:36:10 you can simply umount /initrd Jul 14 08:36:42 Why is it mounted in the first place? Is the system using it for something? Jul 14 08:36:53 It's the ramdisk used for booting Jul 14 08:36:55 sure, it's what it boots from Jul 14 08:37:03 the sda1 part is imply wrong though Jul 14 08:37:47 yeah, that is probably because /etc/mtab is copied when sda1 is still mounted at /inittab Jul 14 08:38:02 before the pivot_root Jul 14 08:38:12 yes Jul 14 08:38:17 it's normal Jul 14 08:38:46 and harmless Jul 14 08:38:54 Okay, so nothing to worry about there. Jul 14 08:38:56 so don't worry that it says /dev/sda1 Jul 14 08:38:57 and thus noone has bothered to fix it ;) Jul 14 08:39:01 I umount it on startup, and have an entry in fstab to mount it from /dev/mtdblock4 if I like Jul 14 08:39:34 What else could have caused the flash to fill up? Jul 14 08:40:37 I killed some Apache processes before running "httpd -X". Could that have done something? Jul 14 08:42:42 I had forgotten that "httpd stop" would stop Apache more gracefully, so I was using "kill" to end its processes. If I made a mistake and killed some other process number, could that have filled up the flash? Jul 14 08:43:46 I'm just trying to find out what I did wrong to fill up the flash so I don't repeat my mistake and have to re-flash again. Jul 14 08:45:12 Okay, maybe it's hard to speculate what I did wrong and I should just carry on troubleshooting. Jul 14 08:46:43 Thanks for clarifying that the /initrd ramdisk is harmless. Jul 14 08:47:41 No clue about your apache problem though Jul 14 08:47:53 It's got all the signs of a filled flash Jul 14 08:48:16 Okay. Thanks, Tiersten. I think you're right. Jul 14 08:48:44 Were you doing any uploads through Apache? Jul 14 08:49:05 I occasionally get temp files left behind by PHP/Apache for interrupted uploads Jul 14 08:49:31 I have been doing uploads, yes. Jul 14 08:49:59 The problem I was troubleshooting has to do with PHP scripts that generate e-mail. Jul 14 08:50:21 Josh Parsons had confirmed that others had similar problems. Jul 14 08:50:42 Yeah. I remember reading some posts about that Jul 14 08:50:55 For example, when I add a new WordPress user, Apache becomes unresponsive. Jul 14 08:51:16 What that happens I can only recover by rebooting the slug. Jul 14 08:51:45 I'm pretty sure that the Wordpress new user script generates an e-mail message to the new user Jul 14 08:51:53 hrm Jul 14 08:52:42 Sorry? "hrm"? (I'm new to IRC) ;-) Jul 14 08:53:06 hrm = thinking Jul 14 08:53:08 it indicates he's thinking Jul 14 08:53:10 Make the noise hrm :) Jul 14 08:53:12 :) Jul 14 08:53:16 Okay, sorry Jul 14 08:53:43 Anyway, I was getting ready to run strace Jul 14 08:54:40 NAiL and others had suggested I try "httpd -X" to reproduce the problem with single-threaded Apache Jul 14 08:55:16 They also suggested using strace to try finding out what exactly is happening when Apache hangs. Jul 14 08:56:01 I had not yet gotten to using strace when I rebooted the slug and found that (apparently) the flash was full. Jul 14 08:56:15 oooh Jul 14 08:56:30 apache logfiles? Jul 14 08:57:07 Looking now... Jul 14 09:01:03 Well, I see "[error] cgid daemon process died, restarting" in the Apache log sometime around when I had to re-flash. Jul 14 09:01:25 I see nothing else that jumps out at me. What should I be looking for? Jul 14 09:02:01 Earlier I had found no meaningful Apache log entries associated with the PHP script problem. Jul 14 09:03:32 NAiL suggested that if Apache hangs on the mail script there would likely be no errors in the log file. Jul 14 09:04:07 jacques, what should I look for in the log as I search for clues to what filled the flash? Jul 14 09:04:19 I thought the logs themselves had filled the flash Jul 14 09:04:58 The log is in /share/hdd/data/... Jul 14 09:05:25 It is 685 KB Jul 14 09:05:57 Are there other log files I should check? Jul 14 09:07:09 I thought about 600kB was all the space left on the flash Jul 14 09:08:06 But I thought the log was on the HDD? Jul 14 09:08:30 I dunno, I didn't even know you had a HD Jul 14 09:08:38 it's rather hard to debug this with the info I have Jul 14 09:08:57 I realize that. I appreciate everyone's help. Jul 14 09:09:39 I just wanted to do a reality-check with others to see if I could prevent doing again whatever I did before to fill the flash. Jul 14 09:10:40 Perhaps I won't find the root cause, but at least going through some of the ideas you folks have brought up helps to eliminate some of the more obvious possibilities. Jul 14 09:11:00 flash is so small you should be able to find the files that are filling it Jul 14 09:14:59 Let me make sure I'm looking in the right place. (Stupid question alert!) Where in the file system will I find the flash files? Jul 14 09:19:26 <[g2]> FYI for those not following in #openslug Jul 14 09:19:30 Thanks for your help, everyone. Running out of time. Got to go. Thanks. Jul 14 09:19:34 <[g2]> ls tmp/deploy/ipk/ Jul 14 09:19:34 <[g2]> lsof-doc_4.75-r0_armeb.ipk lsof_4.75-r0_armeb.ipk Jul 14 09:19:52 <[g2]> uname -a Jul 14 09:19:52 <[g2]> Linux apex 2.6.11.2 #1 Thu Jul 7 21:48:02 EDT 2005 armv5teb unknown unknown GNU/Linux Jul 14 09:20:24 <[g2]> The first openslug package was natively created Jul 14 09:20:36 <[g2]> with bitbake Jul 14 09:20:39 Cool Jul 14 09:20:43 How long has it taken? :) Jul 14 09:21:16 <[g2]> Tiersten, it's almost a year in development probably lots longer :) Jul 14 09:22:08 ah the days when we just used sed on the kernel binary... Jul 14 09:22:53 <[g2]> there are 16 files to parse and from an empty tmp dir it takes..... (building now) Jul 14 09:24:52 <[g2]> it builds 3 packages Jul 14 09:27:37 <[g2]> real 5m45.271s Jul 14 09:27:37 <[g2]> user 4m23.990s Jul 14 09:27:37 <[g2]> sys 1m16.290s Jul 14 09:27:58 Not too bad Jul 14 09:28:12 <[g2]> it really isn't Jul 14 09:28:33 <[g2]> now I'll be able to package up native python/perl/etc.... Jul 14 09:29:11 Did you see my idea the other day about distcc? Jul 14 09:29:24 re all Jul 14 09:29:29 Hey Jul 14 09:29:39 <[g2]> I saw distcc mentioned Jul 14 09:30:03 <[g2]> I think a fat rev082 would be best Jul 14 09:30:20 <[g2]> 425 @ 533 Jul 14 09:30:33 With distcc we should be able to speed up native builds significantly since most of the compilation will be offloaded to the PC Jul 14 09:30:47 configure and everything else still runs on the nslu2 so it shouldn't break Jul 14 09:31:49 <[g2]> well if the cross stuff was figured out it'd just build cross in the first place no ? Jul 14 09:32:17 It's difficult for some packages because they want to run stuff as it builds Jul 14 09:32:18 <[g2]> you are talking like the matchbox folks Jul 14 09:32:41 Oh. This isn't a replacement for cross compilation. Just to speed up the stuff that has to build native Jul 14 09:32:51 matchbox folks? Jul 14 09:33:17 <[g2]> yeah a band of embedded folk working on arm target for Nokia Jul 14 09:33:36 <[g2]> a dozen or so ppl spent 3-4 years setting up an envrion Jul 14 09:33:50 Getting distcc to work isn't that hard Jul 14 09:33:57 <[g2]> compiling native actually build cross Jul 14 09:34:16 <[g2]> with distcc iirc Jul 14 09:34:46 It's inbetween building native and cross compiling Jul 14 09:34:57 guys- a question if i may? Jul 14 09:35:05 <[g2]> they had some shell shims that transparently ran stuff on the right target Jul 14 09:35:05 Most stuff is still native like configure and the small test programs it generates but everything big is offloaded to something more powerful Jul 14 09:35:09 <[g2]> kitno455, go! Jul 14 09:35:18 distcc does it for you. You just change what CC is Jul 14 09:35:21 want to build latest bleeding edge openslug Jul 14 09:35:30 that's pretty much it bar installing the server and client software Jul 14 09:35:31 directions on wiki are everywhich way Jul 14 09:35:44 <[g2]> got monotone ? Jul 14 09:35:48 not yet Jul 14 09:35:56 stock, fresh install of fc2 Jul 14 09:36:07 <[g2]> fc2... uh oh Jul 14 09:36:15 hahah Jul 14 09:36:19 <[g2]> really Jul 14 09:36:23 bit old isn't it? Jul 14 09:36:41 <[g2]> I think some ppl had fc issue, it's may be on the wiki Jul 14 09:36:43 yeah, have a big webapp that runs on fc2 on my servers Jul 14 09:36:56 need desktop to stay same as servers for testing Jul 14 09:37:08 fc4 has upgraded to apache2, etc Jul 14 09:37:13 ah Jul 14 09:37:17 i mean, mod_perl2 Jul 14 09:37:40 fc3 any better? Jul 14 09:37:45 i can do that easily Jul 14 09:37:45 <[g2]> dunno Jul 14 09:37:55 well, i'll jsut have to try it :) Jul 14 09:38:22 is there a concise set of instrutctions handy? i get lost in the damn wiki Jul 14 09:38:31 i think someone is confusing matchbox and scratchbox Jul 14 09:38:35 <[g2]> mkdir /home/slug; cd /home/slug; wget http://www.nslu2-linux.org/Makefile; make openslug-build Jul 14 09:38:49 humm, home is nfs mounted Jul 14 09:38:58 can i use someplace else? Jul 14 09:39:11 <[g2]> jacques, HEH... could be! on the matchbox/scratchbox issue Jul 14 09:39:22 or is that path hardcoded in the build env? Jul 14 09:39:33 <[g2]> kitno455, can be any dir Jul 14 09:39:48 [g2], does that command build monotone too? Jul 14 09:40:09 It assumes you've got it installed yourself Jul 14 09:40:12 <[g2]> no it expects monotone t be in the path Jul 14 09:40:19 right Jul 14 09:40:29 off to try. Jul 14 09:40:53 there is a howto for installing monotone in the monotone docs. you need a few other things as well. it's all explained in there with steps Jul 14 09:41:21 <[g2]> emerge monotone Jul 14 09:41:30 <[g2]> doh! wrong distro :) Jul 14 09:41:32 Don't think that works on FC2 :) Jul 14 09:41:34 no gentoo ehre :) Jul 14 09:41:46 <[g2]> apt-get install monotone Jul 14 09:41:47 wonder if freshrpms has it Jul 14 09:42:00 <[g2]> kitno455, make *sure* you've got version 18 Jul 14 09:42:10 what about version .20? Jul 14 09:42:18 no worky? Jul 14 09:42:46 It's not compatible Jul 14 09:42:56 greate :) Jul 14 09:43:10 We're waiting on OE to upgrade Jul 14 09:43:50 too many damn pieces for me to keep track of :) Jul 14 09:44:15 Not too bad. Just make sure monotone is 0.18 and get the Makefile and do make openslug Jul 14 09:44:20 It's pretty much automatic from then on Jul 14 09:44:24 cool Jul 14 09:44:54 how does it relate to things in current ipk repo? Jul 14 09:45:09 are they going to work, or should the be built directly? Jul 14 09:45:27 should be fine Jul 14 09:45:46 monotone takes ages BTW just to warn you Jul 14 09:45:59 to build, or to work :) Jul 14 09:46:15 to work. it's got a lot to import Jul 14 09:46:55 what exactly am i chekcing out with monotone? Jul 14 09:47:08 build scripts, or the actual tarballs? Jul 14 09:47:23 <[g2]> oe metadata Jul 14 09:47:27 OE Jul 14 09:47:51 oe is primarly 'spec' files and patches, right? Jul 14 09:48:09 along with the bitbake python tools? Jul 14 09:55:15 <[g2]> kitno455, yup that's the overview Jul 14 09:55:40 then why is that so big? just that many packages in oe? Jul 14 09:55:50 <[g2]> 2500+ Jul 14 09:56:10 <[g2]> and toolchain arch cross knowledge Jul 14 09:56:19 <[g2]> it's a veritable treasure! Jul 14 09:56:47 but the tool chain is not in oe, it gets built, right? Jul 14 09:59:32 <[g2]> with all the info from the oe metadata Jul 14 09:59:35 <[g2]> and patches Jul 14 10:03:08 ok, so monotone is used to get: bitbake tools, crosscompiler patches and build scripts, and oe package patches and build scripts Jul 14 10:08:03 <[g2]> kitno455, monotone get's the oe metadata and symlinks Jul 14 10:08:13 <[g2]> svn gets bitbake and some other stuff Jul 14 10:09:09 uhm, bitbake only avail from svn, but oe uses monotone. are they not the same folks? Jul 14 10:09:35 <[g2]> yup Jul 14 10:09:43 odd Jul 14 10:09:51 <[g2]> but bitbake has been in SVN for many months Jul 14 10:10:08 <[g2]> monotone is a couple weeks old due to the BK issue Jul 14 10:10:15 why move oe to monotone? is it that much better than svn? Jul 14 10:10:33 <[g2]> not monotone itself, but repo in monotone Jul 14 10:10:59 i know, but if svn was already being used to store bitbake.... Jul 14 10:11:41 sigh Jul 14 10:12:11 hey, if i am beating a dead horse, just say shut up :) Jul 14 10:12:20 hell, i'm still using cvs :) Jul 14 10:12:21 shut up Jul 14 10:12:26 done Jul 14 10:12:36 Talk to the OE guys :) Jul 14 10:12:41 hahah Jul 14 10:12:56 OE does seem a double edged sword Jul 14 10:14:10 <[g2]> speaking of OE we'll need to talk to them about this some Jul 14 10:14:58 be careful. jacques might tell you to shut up :) Jul 14 10:31:25 [g2], did you mean make build-openslug? there is no openslug-build target in the Makefile.... Jul 14 10:33:17 make setup && make openslug Jul 14 10:34:20 right, thanks david. Jul 14 10:34:33 :) Jul 14 10:34:57 <[g2]> I'm just too slow today Jul 14 10:39:16 monotone is still building anyway, i just jumped ahead to look at Makefile... Jul 14 10:52:18 monotone pulls allways happen on port 5253? have to punch hole in fw Jul 14 10:57:07 ok, make setup pulling lots of stuff currently. need to read up more on monotone, this looks interesting. Jul 14 10:58:24 well. make setup is fun.. takes 15-60 minutes Jul 14 10:58:47 and it says nothing how far it has gotten, on verifying new revisions Jul 14 11:18:42 yeah, we are sitting now, with somehting about verifying revs, and then some bytes transgfered Jul 14 11:19:09 monotone does not handle 80 char wide windows well Jul 14 11:20:28 on the initial one it has lots of revs to verify, and that takes time, when it just has the normal 10-20 /day it goes quite fast Jul 14 11:25:41 at this point, all i seem to have is a pair of .db files Jul 14 11:26:06 checksums, revision numbers and the like, i guess? Jul 14 11:27:05 well, everything Jul 14 11:28:45 that would be odd- the entire repo is in a single file? Jul 14 11:29:12 yes :) that is odd Jul 14 11:29:24 but true Jul 14 11:29:28 arg. Jul 14 11:29:33 it later creates the filesystem from it Jul 14 11:30:02 then in order to update it has to go thru this process backwards? Jul 14 11:30:11 no Jul 14 11:30:23 it takes care of that Jul 14 11:30:46 or well, it is the same process Jul 14 11:30:57 well, i am not going to worry about it. i am sure the guys that designed it this way either know far more about distributed scm than i, or they are crazy Jul 14 11:30:59 The DB contains everything. It has every changeset ever applied Jul 14 11:31:12 and i pull the whole thing? Jul 14 11:31:20 yup :-) Jul 14 11:31:26 36Mb or something Jul 14 11:31:48 Yes. The reason why it takes so long at the start is because it has to do an consistency check of all the revisions and the various trees Jul 14 11:32:04 what is checking revisions actually doing? looping thru the db and going back to server for each tree? Jul 14 11:32:12 No Jul 14 11:32:17 Just leave it alone and assume it works! Jul 14 11:32:21 :) Jul 14 11:32:33 you know what happens when you assume :) Jul 14 11:32:40 Yes. It saves lots of time Jul 14 11:32:52 i like to know abit about what is running on my machine. curiosity mostly Jul 14 11:32:54 Feel free to talk to the OE and Monotone people Jul 14 11:33:10 aka: shut up :) Jul 14 11:33:37 No. But you're asking the wrong people about implementation details of monotone because we didn't write it... Jul 14 11:34:14 just figured you were curious enough to have asked already. lazyness on my part just to ask you. Jul 14 11:34:27 did not mean to be a bother Jul 14 11:34:43 It is still relatively new. We've not been using it for that long Jul 14 11:35:19 yeah, 0.18 version number would not inspire much confidence in the closed-source world :) Jul 14 11:36:09 I mean us not monotone Jul 14 11:36:21 Version numbers are irrelevant anyway Jul 14 11:36:51 They could just move the decimal place over and make it more appealing to you Jul 14 11:39:15 i am kidding, of course. Jul 14 12:48:29 VoodooZ_Log: to get a structure to be processed in ARM registers simply declare a local copy on the stack, copy the value in, process, copy out (make sure you don't take the address of the local one). Jul 14 12:53:24 <[cc]smart> NAiL: ping Jul 14 12:54:02 <[cc]smart> jbowler-away: hi. Jul 14 13:00:44 [cc]smart hi Jul 14 13:00:59 re Jul 14 13:01:40 kitno455: you want monotone 0.19 ideally, not 0.18 (though that should work) Jul 14 13:02:52 jbowler-away, thanks, its running the setup now Jul 14 13:03:02 should i stop it and install .19? Jul 14 13:03:18 I wouldn't... Jul 14 13:03:56 I'm pretty sure .18 is ok. If you ever need to write back to the database though I would install 0.19 first. Jul 14 13:04:25 [cc]smart: pong Jul 14 13:05:29 The (local) databases are compatible, just a matter of running db migrate to get the local db to 0.19 and moving ~/.monotonerc to ~/.monotone/monotonerc Jul 14 13:09:50 how does one get perms to push? Jul 14 13:10:31 <[g2]> kitno455, yeah do lots of development :) Jul 14 13:10:52 duh. i mean from a technical perspective Jul 14 13:11:12 i am used to cvs, - you have an account at the time you checkout Jul 14 13:11:30 but i just did this monotone checkout with no name? Jul 14 13:11:40 <[g2]> just like anon cvs Jul 14 13:11:52 ok, but anon cvs cant commit Jul 14 13:12:01 <[g2]> and neither can you Jul 14 13:12:09 my point exactly. Jul 14 13:12:15 <[g2]> except to your local repo Jul 14 13:12:26 when one becomes an anointed devel, you check out again, like cvs? Jul 14 13:12:34 but with a userid? Jul 14 13:13:01 <[g2]> there's a key with a cert Jul 14 13:13:30 ok, i make a pub/priv key and put them somewhere? Jul 14 13:13:35 yes Jul 14 13:13:39 do i have to checkout again? Jul 14 13:13:44 no Jul 14 13:13:49 good Jul 14 13:13:59 pet peev of cvs :) Jul 14 13:14:03 you need the private key when you first modify your local db. Jul 14 13:14:35 you need that private key to be trusted by any remote database you sync (push) to, as opposed to pull. Jul 14 13:14:36 irc question: how are you bolding? Jul 14 13:14:46 '*' round the word Jul 14 13:14:55 right on both counts. Jul 14 13:14:59 gotcha Jul 14 13:15:08 Well, actually, it seems to recognized \s\*\*\s Jul 14 13:15:16 *gotcha* Jul 14 13:15:23 hmm Jul 14 13:15:34 But I think it's the client doing it :-P Jul 14 13:15:36 *gotcha* Jul 14 13:15:42 not my client :) Jul 14 13:16:14 <[cc]smart> jbowler-away: script would be ready. nice to have addition would be autoounter for subdirectories Jul 14 13:16:21 do later versions of monotone give more status on revs checking... Jul 14 13:16:39 no ;-) Jul 14 13:16:41 <[cc]smart> should be easy in principle but i had a little struggle with identifying the entry in fstab so i left it out for now Jul 14 13:16:54 <[cc]smart> in any case populate-volatile.sh should be ready. Jul 14 13:17:04 [cc]smart: Why'd you ping, master? :) Jul 14 13:17:16 <[cc]smart> and i'd like to add it somewhere. Jul 14 13:17:25 <[cc]smart> because of populate-colatile.sh Jul 14 13:17:43 <[cc]smart> i'd like to avoid messing with other OE for now Jul 14 13:18:01 <[cc]smart> so i wanted to ask you if i sould maybe put it in an openslug specific place Jul 14 13:18:05 Well, we can do it in initscripts-openslug Jul 14 13:18:28 <[cc]smart> later then it would be possible for OE people, if they think they want, to decide to move it somehwre else Jul 14 13:18:37 It's kind of bogus, but that .bb file is already hacking other package startup scripts. Jul 14 13:18:53 <[cc]smart> so it seems to be the right place Jul 14 13:19:26 <[g2]> jbowler-away, [cc]smart are you familiar with update-alternatives ? Jul 14 13:19:27 <[cc]smart> point is, i've got nearly 0 clue about .bb files and what can be fetched from where to be installed there Jul 14 13:19:43 <[cc]smart> update-alternatives ? Jul 14 13:19:45 [g2]: no, need to work it out for monotone I think... Jul 14 13:20:02 [cc]smart: it's got comments :-) Jul 14 13:20:11 <[g2]> DaKa2, had a good idea about using it Jul 14 13:20:21 Anyway, you edited one before for rmrecovery ;-) Jul 14 13:20:28 <[g2]> then we wouldn't have to do --force-overwrite Jul 14 13:21:01 [g2] - I didn't see that, where are we using force-overwrite? Jul 14 13:21:02 <[g2]> NAiL, can you do me a check in favor ? Jul 14 13:21:15 probably Jul 14 13:21:34 <[g2]> on the install for the native devel where they conflict with the busybox files Jul 14 13:22:01 <[g2]> can you add patch and util-linux to the packages and symlinks ? Jul 14 13:22:36 yeah patch! Jul 14 13:22:55 util-linux is already in symlinks Jul 14 13:23:07 <[g2]> ok.. Jul 14 13:23:13 <[g2]> then just to the packages Jul 14 13:23:14 [cc]smart: add it to initscripts-openslug just before populate-var.sh (S36) then zap the populate-var.sh link as the first thing it does (and check that this doesn't cause /etc/init.d/rcS to explode). Jul 14 13:23:21 03repvik * r87 10/trunk/openslug/nslu2-linux/packages/patch: Added patch Jul 14 13:23:32 <[cc]smart> so i would add the 2 files here: nslu2-linux/openslug/openembedded/packages/initscripts/initscripts-1.0/openslug Jul 14 13:23:53 [cc]smart: I'm not suggesting this is the right approach, but it should work and we can work out something better when we have it verified as fully operational. Jul 14 13:24:05 [cc]smart: no, in the .bb file Jul 14 13:24:17 <[cc]smart> putting the files into the file ? Jul 14 13:24:34 Oh, hum.... Jul 14 13:24:45 <[cc]smart> mighty work # wc -l * Jul 14 13:24:46 <[cc]smart> 64 populate-volatile.sh Jul 14 13:24:46 <[cc]smart> 30 volatiles Jul 14 13:25:21 Yes. Put it in the openslug sub-dir. I'm pretty sure #oe would want it in base-files. Jul 14 13:25:42 <[cc]smart> they can later decide to move if they find it useful i'd say Jul 14 13:25:44 HUm... it would be much better to discuss this with mickeyl now - otherwise it's work moving it around. Jul 14 13:26:04 <[cc]smart> monotone should make moves easy, no ? Jul 14 13:26:23 Someone has to run vi... Jul 14 13:26:30 <[cc]smart> i'll do it :) Jul 14 13:27:29 The advantage to doing it openslug-specific is that any bugs can be worked out here first, the disadvantage is that it makes the whole stuff more work in the end. Jul 14 13:28:27 Watch out for the PR in initscripts-openslug - it inherits PR from initscripts, so you increment the '.1' to '.2' Jul 14 13:29:37 Note that you cannot edit another package from within the do_install - because do_install goes to a local directory, so even though the other package has been built nothing from it is visible. Jul 14 13:33:56 03nail 07org.openembedded.nslu2-linux * r3e0e75c3... 10/packages/meta/openslug-packages.bb: Added patch and util-linux Jul 14 13:43:48 <[cc]smart> ok, baking now. will see tomorrow if it's ok and prolly push it in the evening. then i can fix bug 193 Jul 14 13:49:10 [g2]: patch and util-linux in the unstable feed now Jul 14 13:49:41 <[g2]> NAiL, thx Jul 14 13:50:14 np Jul 14 13:51:01 <[cc]smart> so, goin to sleep Jul 14 13:51:02 <[cc]smart> n8 all Jul 14 13:55:41 jbot, convert 31C to F Jul 14 13:55:43 31C cannot be correctly converted to F. Jul 14 13:56:09 Ooh, a temperature which doesn't exist in the US! Jul 14 13:56:28 lol Jul 14 13:56:31 lol Jul 14 13:56:56 Funny because the inverse can be true (since /9 isn't exact in decimal) but if I remember my math C->F should always be exact. Jul 14 13:57:49 jbot, convert 31C/s to A Jul 14 13:57:51 A is an invalid unit? Jul 14 13:58:09 Ah ha, it's losing its confidence... Jul 14 13:58:32 jbot, convert 31C to K Jul 14 13:58:34 31C cannot be correctly converted to K. Jul 14 13:58:46 jbot, convert 37C to F Jul 14 13:58:48 37C cannot be correctly converted to F. Jul 14 13:58:53 neat Jul 14 13:59:10 jbot, weather kcvo Jul 14 13:59:13 Corvallis, Corvallis Municipal Airport, OR, United States; (KCVO) 44-30N 123-17W; last updated: 2005.07.14 1935 UTC; Dew Point: 53 F (12 C); Pressure (altimeter): 30.07 in. Hg (1018 hPa); Relative Humidity: 39%; Sky conditions: clear; Temperature: 80 F (27 C); Visibility: 10 mile(s); Wind: from the NE (040 degrees) at 13 MPH (11 KT) Jul 14 13:59:21 well something works at least Jul 14 13:59:26 jbot, convert 37 miles to kilometres Jul 14 13:59:28 37 miles is approximately 59.5457 kilometres Jul 14 13:59:46 jbot, convert 88 parsecs to angstroms Jul 14 13:59:48 88 parsecs is approximately 2.7137e+28 angstroms Jul 14 13:59:50 jbot, convert 31 C to F Jul 14 13:59:52 31 C cannot be correctly converted to F. Jul 14 13:59:55 hrm Jul 14 14:00:03 whats the syntax or doesn't it know how to do temp? Jul 14 14:00:04 spell it out? Jul 14 14:00:13 jbot, convert 31 celsius to fahrenheit Jul 14 14:00:14 jbot, convert 37 celcius to farenheit Jul 14 14:00:22 oops Jul 14 14:00:26 jbot, convert 37 centigrade to farenheit Jul 14 14:00:28 farenheit is an invalid unit? Jul 14 14:00:41 jbot, convert 37 centigrade to fahrenheit Jul 14 14:00:43 fahrenheit is an invalid unit? Jul 14 14:00:44 I managed to spell both of those wrong Jul 14 14:00:46 just use metric okay? Jul 14 14:00:57 oooh, let me try Jul 14 14:01:23 or maybe I didn't misspell both Jul 14 14:01:29 jacques: are you sure, I suspect your speling is betr then min Jul 14 14:01:58 jbot, convert 37 degrees celsius to degrees fahrenheit Jul 14 14:02:01 ah I guess both of mine were right but looked wrong to me Jul 14 14:02:18 jbot, convert 31 degrees Celsius to Fahrenheit Jul 14 14:02:25 heh Jul 14 14:02:28 unknown unit Jul 14 14:02:32 jbot, units Jul 14 14:02:33 converts between different systems of units. URL: ftp://ftp.gnu.org/gnu/units/ Jul 14 14:02:51 no help there Jul 14 14:02:57 jbot, help convert Jul 14 14:03:06 no help on convert. Use 'help' without arguments. Jul 14 14:03:17 It thinks c = speed of light Jul 14 14:03:51 jbot, convert 1 c to mph Jul 14 14:03:53 1 c is approximately 6.70617e+08 mph Jul 14 14:03:56 yep Jul 14 14:03:56 see... Jul 14 14:04:05 that was helpful Jul 14 14:04:26 c * 9/5 + 32 Jul 14 14:04:38 iirc Jul 14 14:04:40 jbot, convert 1 erg to W Jul 14 14:04:42 1 erg cannot be correctly converted to W. Jul 14 14:04:49 jbot, convert 10 tempC to tempF Jul 14 14:04:58 ah Jul 14 14:05:03 jbot, 31 * 9/5 + 32 Jul 14 14:05:03 87.8 Jul 14 14:05:05 jbot, convert 10 degC to degF Jul 14 14:05:06 :-D Jul 14 14:05:10 damnit Jul 14 14:05:26 jbot, convert 10 tempC to tempF Jul 14 14:05:41 it missing half the units.dat file or something? Jul 14 14:05:50 this should look good in the logs Jul 14 14:06:09 jbot, no botsnack for you! Jul 14 14:06:09 aw, gee, ByronT Jul 14 14:06:17 bad jbot bad! Jul 14 14:06:29 no cookie for you Jul 14 14:06:56 too much fun, bbl Jul 14 14:07:09 jbot, convert tempC(31) to tempF Jul 14 14:07:14 give up :) Jul 14 14:07:16 jbot is broken Jul 14 14:07:54 we worked him too hard Jul 14 14:09:16 jbot is like an infocom game Jul 14 14:09:37 jbot, xyzzy Jul 14 14:09:38 twice as much happens Jul 14 14:12:39 nah. infocom games had a fairly good parser Jul 14 14:18:57 03nail 07org.openembedded.nslu2-linux * r69c4e49f... 10/packages/thttpd/ (files/init thttpd_2.25b.bb): Fixed so initscript starts thttpd with the right path Jul 14 14:23:01 ~emulate rwhitby Jul 14 14:23:02 Another Satisfied Customer! Jul 14 14:23:05 hrrm Jul 14 14:23:06 ~emulate rwhitby Jul 14 14:24:28 * NAiL is impressed by his new desktop. I've been using 100% cpu for a few hours now, and the CPU temp is 34C Jul 14 14:25:21 that would be 2 deg over my ambient temp.. Jul 14 14:26:35 My case temp is 32C ;) Jul 14 14:26:48 grr Jul 14 14:27:11 i hate the summer! Jul 14 14:27:18 * DaKa2 wants winter **** BEGIN LOGGING AT Thu Jul 14 14:33:08 2005 Jul 14 14:36:32 so who tripped over the network cable? Jul 14 15:40:37 jbowler-away: we should talk to #oe folks before going too far down the populate-volatile.sh path. We don't really want to have a completely different boot sequence from the rest of OE distros. Can someone put it on a wiki page so we can point them to it and discuss it? Jul 14 18:31:32 03jp30 * 10unslung/make/transcode.mk: prevent transcode from being confused by the presence of x11 Jul 14 23:34:23 openembedded/packages/mpd is empty, but is referred to by openslug-packages.bb Jul 14 23:35:27 That would explain why it failed... Jul 14 23:37:20 No, something else is happening. It was util-linux which failed for me. Jul 14 23:38:57 mpd is musicpd/mpd_0.11.2.bb - it builds fine with glibc, it fails on uclibc because the dependent libvorbis fails at a link step (misplaced -lm) Jul 14 23:39:43 ok, it's the symlinks which is wrong then ... Jul 14 23:41:02 03rwhitby * r88 10/trunk/openslug/nslu2-linux/packages/musicpd: Added musicpd directory for the mpd package Jul 14 23:41:24 Yes... Jul 14 23:42:36 I still haven't had a complete unslung/openslug/optware build since we moved to monotone .... maybe now jp30 is back that will happen. Looks like he had the same problem with transcode that I saw ... Jul 14 23:43:57 I haven't had a complete openslug-packages for days, without fixups. We have a period of instability... Jul 14 23:44:21 yep, we will get it all back under control one day :-) Jul 14 23:44:27 Still, it's because of increased activity. That is good. Jul 14 23:45:49 jbowler: with regard to populate-vars, have we given #oe a heads up on that yet? Jul 14 23:54:37 NOTE: package postfix-2.0.20-r0: task do_package: started Jul 14 23:54:38 ERROR: function do_install failed Jul 14 23:54:38 ERROR: see log in /home/slug/openslug/tmp/work/postfix-2.0.20-r0/temp/log.do_install.12912 Jul 14 23:54:38 NOTE: Task failed: /home/slug/openslug/tmp/work/postfix-2.0.20-r0/temp/log.do_install.12912 Jul 14 23:54:38 NOTE: package postfix-2.0.20-r0: task do_package: failed Jul 14 23:54:42 anyone else seeing that? **** ENDING LOGGING AT Thu Jul 14 23:59:56 2005