**** BEGIN LOGGING AT Thu Feb 15 02:59:57 2007
Feb 15 04:31:51 <CIA-19> 03mwester * r696 10kernel/trunk/patches/apex/ (2 files): Working config files for DSM-G600 RevA
Feb 15 04:40:47 <CIA-19> 03mwester * r697 10kernel/trunk/ (4 files in 2 dirs): 
Feb 15 04:40:47 <CIA-19> Kernel shim for DSM-G600 updated so that a default command line will be
Feb 15 04:40:47 <CIA-19> provided if the command line ATAG passed in is missing, or empty.
Feb 15 05:02:05 <CIA-19> 03rwhitby * r698 10kernel/trunk/patches/ (2.6.19/defconfig 2.6.20/defconfig): Make the FIS directory partition writeable
Feb 15 05:41:57 <CIA-19> 03bzhou * r5504 10optware/trunk/make/py-roundup.mk: py-roundup: 1.3.2 -> 1.3.3
Feb 15 12:36:48 <CoreDump|afk> http://pastebin.com/881377
Feb 15 12:40:37 <NAiL> CoreDump|afk: looks nice
Feb 15 12:42:06 <NAiL> CoreDump|afk: You might want to count the partitions on each external disk before choosing which disk. I had two identical disks connected, and with your script I'd probably choose the wrong one once in a while ;-)
Feb 15 12:42:18 <NAiL> One had three partitions, the other one had just one large
Feb 15 12:42:40 <CoreDump|afk> NAiL: excellent idea
Feb 15 12:43:54 <NAiL> how does it actually set which partition to boot from?
Feb 15 12:43:58 <NAiL> does it use UUID?
Feb 15 12:44:21 <NAiL> (since booting with two or more disks is a real PITA without UUID)
Feb 15 12:44:25 <CoreDump|afk> yes it does ;) it's not yet fully implemented
Feb 15 12:44:51 <CoreDump|afk> gotta run to work :\ later!
Feb 15 12:50:22 <NAiL> later
Feb 15 12:53:58 <NAiL> actually, just listing the disks and listing the partitions as subitems would probably make more sense. Don't give the disk itself a number, just the partitions. That'd probably be faster and less cumbersome.
Feb 15 12:54:12 * NAiL just keeps talking
Feb 15 13:01:53 <hrw> NAiL: http://pastebin.com/881396 like?
Feb 15 13:02:18 <hrw> NAiL: partition labels would be nice to have too
Feb 15 13:09:27 <CIA-19> 03oleo * r5505 10optware/trunk/ (6 files in 2 dirs): transmission: add Bypass capability and proper error handling.
Feb 15 13:10:39 <NAiL> hrw: I was thinking something like this: http://pastebin.com/881407
Feb 15 13:10:40 <NAiL> but your suggestion looks good too
Feb 15 13:12:14 <NAiL> hrw: What tools are necessary to get partition labels working?
Feb 15 13:14:07 <hrw> http://pastebin.com/881408
Feb 15 13:14:33 <NAiL> looking good
Feb 15 13:15:52 <hrw> but no idea how to get labels
Feb 15 13:16:31 <NAiL> I think we tried getting labels working about a year ago
Feb 15 13:16:44 <NAiL> but IIRC it just took too much space in flash
Feb 15 14:16:14 <drif> should metalog show in netstat -l ? trying to listen to local1 facility...
Feb 15 14:54:08 <VoodooZ> rwhitby, NAiL, others: Anybody know if the apex environment location has/will change? My old apex was configured for CONFIG_ENV_REGION="nor:128k+64k"
Feb 15 14:54:41 <VoodooZ> I'm in the process of updating apex to the latest version and want to make sure all the old settings still apply.
Feb 15 16:00:18 <hillct> Any recommendations on a good example package/bitbake file on which to learn about migrating a makefile to bitbake?
Feb 15 16:15:10 <osas> hillct: which package do you want to migrate?
Feb 15 16:15:28 <hillct> logrotate
Feb 15 16:15:34 <hillct> pretty simple makefile
Feb 15 16:16:00 <hillct> just going to move it from optware
Feb 15 16:16:23 <hillct> but i need to better understand the package build process
Feb 15 16:16:42 <hillct> I gather I just need to create a bitbake file that behaves the same as the makefile
Feb 15 16:18:08 <osas> take a look at dircproxy
Feb 15 16:18:15 <osas> it is the simplest one
Feb 15 16:18:20 <hillct> ok
Feb 15 16:18:22 <hillct> thanks
Feb 15 16:18:34 <osas> try it, take a look at the logs and start debugging
Feb 15 16:18:37 <osas> and have fun
Feb 15 16:18:40 <osas> =)
Feb 15 16:18:44 <hillct> is there a primer doc on the build procedure (what files go where, what test procedures ot use, etc)?
Feb 15 16:18:55 <osas> google for it ...
Feb 15 16:18:58 <hillct> K
Feb 15 16:18:59 <osas> search the wiki
Feb 15 16:19:05 <osas> this is what I did
Feb 15 16:19:07 <hillct> but there is one
Feb 15 16:19:17 <osas> It took me some time ... but in the end I got it
Feb 15 16:19:17 <hillct> I can find it
Feb 15 16:19:34 <hillct> as long as the info is out there to find
Feb 15 16:19:45 <osas> it is =)
Feb 15 16:19:48 <hillct> thanks
Feb 15 16:20:01 <osas> maybe not in an obvious format, but it is
Feb 15 16:38:53 <CIA-19> 03bzhou * r5506 10optware/trunk/ (Makefile make/mediatomb.mk): mediatomb: for uclibc, disable id3lib and taglib, added -lm to LDFLAGS; promoted for ddwrt and oleg
Feb 15 16:58:38 <hillct> the masterMakefile wiki page describes issues when running setup-env
Feb 15 16:58:41 <hillct> "If you get kicked out of your shell when running one of the above commands, you should run make in the openslug directory, which will set up a file in the openslug directory. This file is parsed by setup-env and contains the right configuration that prevents you from being kicked out of your shell."
Feb 15 16:59:05 <hillct> make, in openslug directory doesn't seem to be sufficient
Feb 15 16:59:36 <hillct> I found that the shell was still closed when runnong seyup-env
Feb 15 17:00:13 <hillct> This was the case before making slugosbe-image
Feb 15 17:01:15 <hillct> after building that image, and running make in the openslug directory as described, works. It's not clear what dependency of setup-env is being met by building slugosbe-image though
Feb 15 17:01:16 <NAiL> do a "make openslug-image", then wait until bitbake starts counting
Feb 15 17:01:26 <NAiL> that should IIRC make the correct setup-env stuff
Feb 15 17:04:53 <hillct> testing
Feb 15 17:06:33 <hillct> nope. that doesn't dot the trick
Feb 15 17:09:00 <hillct> I'm starting from scratch as it's possible I've screwed up my enviroment somehow
Feb 15 17:10:34 <CIA-19> 03bzhou * r5507 10optware/trunk/make/mediatomb.mk: mediatomb: r1094 -> r1096, upstream fixed LDFLAGS in configure.ac for -ljs check
Feb 15 17:41:05 <CIA-19> 03osas * r5508 10optware/trunk/make/pcapsipdump.mk: pcapsipdump: 0.1.1 -> 0.1.2
Feb 15 17:45:55 <hrw> hillct: its simple 'make;make install DESTDIR=somewhere' package?
Feb 15 17:46:05 <hillct> setup-env definately has some other dependency besides those built by make in the openslug directory
Feb 15 17:46:34 <hillct> hrw: what's simple? make procedure?
Feb 15 17:46:42 <hillct> in the most veneral sense, sure
Feb 15 17:46:47 <hillct> er general sense
Feb 15 17:47:35 <hrw> hillct: try simplest possible recipe: 'SRC_URI = "url-to-sources"' - if not work then check tmp/work does it got proper directory.
Feb 15 17:47:59 <hrw> hillct: if not then add S = "${WORKDIR}/proper-dir/" and retry
Feb 15 17:48:14 <hrw> hillct: iirc do_compile() by default try to run make
Feb 15 17:51:06 <hillct> hrw: sounds good. At the moment I'm back to step 1, building the toolchain. I had built the toolchain via make slugosbe-image but then found that setup-env started working without kicking me out of ther shell. I figured I'd try the more minimal toolchain build as defined in the wiki
Feb 15 17:51:42 <hillct> made clean, then found that I couldn't get setup-env to work anymore, even after making in the openslug directory
Feb 15 17:51:48 <hillct> not sure what's going on
Feb 15 17:52:21 <hrw> I never used nslu mastermakefile
Feb 15 17:52:37 <hillct> oh?
Feb 15 17:52:49 <hillct> how'd you go about building the toolchain?
Feb 15 17:53:07 <hrw> hillct: I use OE for longer time then nslu devs - soon 3 years will pass
Feb 15 17:53:35 <hillct> oh, so you have a more comprehensive OE enviroment on which you rely
Feb 15 17:53:49 <hrw> yeo
Feb 15 17:54:07 <hillct> I'm just learning about the OE toolset at this point
Feb 15 17:54:17 <hrw> 3A
Feb 15 17:54:18 <hrw> cu
Feb 15 17:54:19 <hillct> not much of a makefile hacker either
Feb 15 17:54:28 <hillct> later...
Feb 15 18:07:43 <hillct> NAiL: it appears that the unsatisfied depencency of setup-env is the file conf/tempdir.conf
Feb 15 18:07:58 <hillct> not 1005 certain
Feb 15 18:07:58 <hillct> er not 100%
Feb 15 18:17:23 <hillct> NAiL: the minimum toolchain build is now proceeding. looks like tempdir.conf just wasn't being setup
Feb 15 18:20:29 <NAiL> good
Feb 15 18:25:13 <hillct> it might be valuable to have a make target specifically for the minimum toolchain for use when setting up to do migration of optware to OE (and probably other cases)
Feb 15 18:26:33 <hillct> I'll try and put one together once I get a better handle on this
Feb 15 20:52:26 <CIA-19> 03bzhou * r5509 10optware/trunk/ (Makefile make/libiconv.mk): libiconv: 1.9.1 -> 1.11; revived for wl500g alone
Feb 15 21:05:30 <CIA-19> 03bzhou * r5510 10optware/trunk/ (Makefile make/mediatomb.mk): mediatomb: using standalone libiconv if not part of libc; promoted for wl500g
Feb 15 21:15:36 <CIA-19> 03bzhou * r5511 10optware/trunk/Makefile: promoted dict for wl500g
Feb 15 22:04:31 <hillct> ok
Feb 15 22:04:33 <hillct> so
Feb 15 22:04:42 <hillct> finally have my toolchain built
Feb 15 22:09:39 <hillct> earlier, someone mentioned the name of the .bb file to which i need to add a reference to the bb file for the package I'm adding
Feb 15 22:10:18 <hillct> but i can't find it now
Feb 15 22:15:54 <marja`sjuk> Anyone had the problem that the debian installation refuses to do the step "Configure flash memory to boot the system"
Feb 15 22:16:25 <marja`sjuk> Its really annoying, the entire installation is done dispite this essential step
Feb 15 22:20:29 <CoreDump|home> NAiL: hrw|gone nice mockups for set-bootdev
Feb 15 22:20:34 <CoreDump|home> hi
Feb 15 22:22:41 * rwhitby guess he needs to check the overnight logs ...
Feb 15 22:23:34 <CoreDump|home> rwhitby: http://pastebin.com/881377
Feb 15 22:24:08 <rwhitby> nice
Feb 15 22:26:37 <hillct> hi rwhitby
Feb 15 22:26:43 <hillct> and CoreDump|home
Feb 15 22:27:31 <rwhitby> g'day hillct 
Feb 15 22:28:05 <hillct> I now have a working build enviroment and am trying to inderstand the files needed to complete a build and package process
Feb 15 22:28:16 <CoreDump|home> hi hillct 
Feb 15 22:28:27 <hillct> I'm reviewing dircproxy as an example
Feb 15 22:28:56 <hillct> I understand the bb source retrieval and patch steps
Feb 15 22:29:11 <hillct> what controls the ipk packaging process?
Feb 15 22:30:27 <hillct> I see in optware builds there's a directory for each package containing the ipk control files. I don't see anything similar for OE builds
Feb 15 22:31:49 <rwhitby> hillct: it's all in the OE classes
Feb 15 22:31:59 <rwhitby> and in the distro and machine conf files
Feb 15 22:32:42 <hillct> ok
Feb 15 22:32:49 <rwhitby> look in conf/machine/nslu2be.conf and conf/distro/slugos.conf (and all the files that the include or inherit).  You can find .bbclass files in classes/...
Feb 15 22:33:04 <rwhitby> then look in packages/images/slugos-image.bb for the final steps.
Feb 15 22:33:16 <hillct> ah
Feb 15 22:33:19 <rwhitby> and packages/meta/slugos-packages.bb for what gets into the feeds
Feb 15 22:33:49 <hillct> ok. I looked at the classes a bit. I have more reading to do I guess
Feb 15 22:34:10 <hillct> big learning curve
Feb 15 22:36:42 <rwhitby> yep
Feb 15 22:36:52 <rwhitby> that's why we have optware too :-)
Feb 15 22:37:01 <hillct> oh, are there any make targets for cleaning up /openembedded that won't break the toolchain or have other undesirable effects, when I (almost certainly) currupt my OE directory with broken package data files?
Feb 15 22:37:45 <rwhitby> bitbake -c clean -b openembedded/packages/foo/foo_x.y.z.bb
Feb 15 22:38:40 <hillct> maybe I stould start by reading the entire bitbake manual cover to cover rather than just using it as a reference
Feb 15 22:38:45 <hillct> ;)
Feb 15 22:38:58 <hillct> neah. that's too easy (and un-fun)
Feb 15 22:52:37 <CoreDump|home> rwhitby: hows your moko image coming?
Feb 15 22:53:34 <rwhitby> CoreDump|home: mokoslug?  it booted on the slug this morning (finally got the rootfs small enough to fit)
Feb 15 22:53:49 <rwhitby> it'll be ready by the time altboot is ready ;-)
Feb 15 22:53:53 <CoreDump|home> hehe
Feb 15 22:54:34 <CoreDump|home> rwhitby: I got a question tho: Why do you insist on installing *slug into flash? Why not require $USER to install on HDD by default?
Feb 15 22:54:50 <rwhitby> recovery
Feb 15 22:55:09 <rwhitby> since there is no console, you must have a fully operational rootfs in flash, otherwise you can't debug a hard disk problem
Feb 15 22:55:11 <CoreDump|home> a barebone recovery image would do then ;) 
Feb 15 22:55:28 <CoreDump|home> and the true image is on HDD
Feb 15 22:55:30 <rwhitby> not if the problem is in the hard disk enclosure, for instance
Feb 15 22:55:43 <rwhitby> (which happens)
Feb 15 22:56:02 <rwhitby> also, many people like to run it with just a single application (like dnsmasq) and no external storage
Feb 15 22:56:37 <CoreDump|home> rwhitby: I see
Feb 15 22:56:56 * nbd likes to have a full working environment on flash
Feb 15 22:57:27 <CoreDump|home> rwhitby: well, that situation is far from ideal IMO. The small rootfs is too much of a hassle
Feb 15 22:57:42 <CoreDump|home> (again IMO)
Feb 15 22:57:42 <rwhitby> CoreDump|home: it also is a good measure to stop bloat :-)
Feb 15 22:58:33 <nbd> how big is the flash typically on devices that you guys work with?
Feb 15 22:58:49 <CoreDump|home> this is my first device w/ < 16Mb flash
Feb 15 22:58:51 <NAiL> Most of my devices are 16mb :)
Feb 15 22:58:52 <rwhitby> 8MB on the slug
Feb 15 22:58:57 <CoreDump|home> and 16Mb sucked badly
Feb 15 22:59:00 <nbd> wow, 8MB, that's a lot
Feb 15 22:59:05 <rwhitby> :-)
Feb 15 22:59:10 <nbd> we typically deal with 4 MB
Feb 15 22:59:23 <rwhitby> yeah, 8MB is luxury for an OpenWRT developer
Feb 15 22:59:23 <nbd> and one device with hdd that i was working on had only 2
Feb 15 22:59:30 <nbd> had to fit all the tools to create the filesystem in 2 MB
Feb 15 22:59:36 <CoreDump|home> ouch
Feb 15 22:59:44 <nbd> even had some left over for a small jffs2 partition
Feb 15 22:59:45 <rwhitby> "when I was a lad ...."
Feb 15 22:59:49 <NAiL> the DS101j has only 2mb
Feb 15 22:59:58 <nbd> this was with linux 2.4, though
Feb 15 23:00:01 <NAiL> I never got around to getting one
Feb 15 23:00:01 <nbd> 2.6 eats a little more
Feb 15 23:00:10 <rwhitby> CoreDump|home: here's mokoslug currently: /dev/mtdblock4            6528      5988       540  92% /
Feb 15 23:01:28 <CoreDump|home> rwhitby: I thinking about a larger-sized image with most "typical" stuff pre-installed and working out-of-the-box
Feb 15 23:02:09 <nbd> with 8 mb you even have enough space to throw in samba :)
Feb 15 23:02:09 * NAiL would like a complete rescue-image in flash
Feb 15 23:02:54 <CoreDump|home> Maybe a complete bootable rescue OS in flash which can partition / install the larger-sized image on HDD w/o much $USER intervention
Feb 15 23:05:59 <rwhitby> CoreDump|home: why not just make that larger-sized image an "ipkg install task-larger-sized-image" ?
Feb 15 23:06:47 <rwhitby> CoreDump|home: that's the idea, install the image, altboot to disk, ipkg install the larger configuration.
Feb 15 23:06:55 <CoreDump|home> because then you'd have to get $USER to turnup disk -i blahh again or use the cursed ipkg-link
Feb 15 23:06:56 <NAiL> CoreDump|home: What device are you working on?
Feb 15 23:06:58 <nbd> the hdd partition could be mounted as an overlay on top of the flash ffs
Feb 15 23:07:01 <nbd> with mini_fo
Feb 15 23:07:02 <nbd> :)
Feb 15 23:07:25 <CoreDump|home> NAiL: Zauruses =)
Feb 15 23:07:34 <rwhitby> CoreDump|home: we never use ipkg-link.
Feb 15 23:07:34 <NAiL> ah, zaurii :-P
Feb 15 23:07:40 <rwhitby> we turnup -i to disk, then ipkg install
Feb 15 23:07:44 <CoreDump|home> rwhitby: thank god hehe =)
Feb 15 23:08:15 <rwhitby> (so the flash remains a stable recovery filesystem which is not borked by user customisations unless they really know what they are doing)
Feb 15 23:08:33 <nbd> openwrt got rid of symlink hacks as overlay method, and i'm happy about that
Feb 15 23:08:37 <CoreDump|home> rwhitby: right, sound good
Feb 15 23:08:56 <CoreDump|home> nbd: I soo hate this symlinking crap
Feb 15 23:08:57 <NAiL> I'm aiming for a complete rescue fs in  the TS101 flash that will only be booted from when the reset button is held during boot. By default, it'll hopefully boot debian directly from disk :-D
Feb 15 23:09:32 <rwhitby> CoreDump|home: and with altboot, $USER can even upgrade the kernel on disk and if it doesn't work they failsafe to the working kernel in flash.
Feb 15 23:09:41 <CoreDump|home> NAiL: pull disk = boot rescue OS ;)
Feb 15 23:09:57 <NAiL> with ~13mb flash available for a jffs2 image, I guess I've got plenty of space ;)
Feb 15 23:10:09 <nbd> NAiL: oh yeah
Feb 15 23:10:17 <NAiL> CoreDump|home: yeah, dunno if U-Boot can do that though
Feb 15 23:10:20 <nbd> NAiL: you almost don't need the hdd for apps :)
Feb 15 23:10:26 <NAiL> hehe
Feb 15 23:10:49 <nbd> NAiL: kexec is enough to implement CoreDump|home's suggestion
Feb 15 23:11:06 <NAiL> yes, but that slows down boot considerably.
Feb 15 23:11:19 <nbd> yeah
Feb 15 23:11:19 <CoreDump|home> how often do you boot a slug?
Feb 15 23:11:29 <NAiL> shush ;)
Feb 15 23:11:33 <CoreDump|home> =)
Feb 15 23:12:25 <NAiL> Hopefully, the guy that hacked u-boot to work on the ts-101 can also hack it so it'll try hdd first, then boot from flash if unsuccssful
Feb 15 23:13:15 <CoreDump|home> NAiL: you could always default to boot from flash and have the flash pivot_root to HDD if there is one -> problem soved
Feb 15 23:13:44 <NAiL> yeah, but then the kernel has to be in flash, which kinda sucks when debian is installed
Feb 15 23:14:28 * NAiL is eing herded to bed by gf
Feb 15 23:14:33 <CoreDump|home> =)
Feb 15 23:14:33 * nbd still does not quite believe in debian on small embedded hardware :)
Feb 15 23:14:34 <NAiL> s/eing/being/
Feb 15 23:14:38 <CoreDump|home> NAiL: have fun
Feb 15 23:14:40 <NAiL> Nite all
Feb 15 23:14:43 <CoreDump|home> n8
Feb 15 23:14:54 <NAiL> nbd: Atleast it's not arm. It's PPC, so it's got FP
Feb 15 23:15:17 <nbd> eats so much storage and ram :)
Feb 15 23:15:21 <AdamBaker> I've not tried using u-boot with a HD but it is trivial to make it try 2 flash images so it shouldn't be too hard to try HD then flash
Feb 15 23:15:48 <cbpage> i had a nutty idea an hourish ago... OE can build x86 right?  if so slugos86 would be doable ;)
Feb 15 23:16:07 <CoreDump|home> cbpage: that is indeed doable
Feb 15 23:16:16 <AdamBaker> All I had to do was set bootcmd to "if iminfo first-address; then; bootm first-address; else bootm second-address"
Feb 15 23:16:55 <rwhitby> cbpage: slugos is not (yet) machine independent like that.  I'm still cleaning that up - there are a lot of assumptions that you're running on an ixp4xx
Feb 15 23:17:14 <cbpage> *nod*  like what?
Feb 15 23:18:30 <cbpage> i'm thinking something like slugos at least, on a small USB stick on something like a terminator c3, which is now $93 shipped (RAM not included, but $20-30 for 256 would do) from newegg here in the US
Feb 15 23:22:06 <cbpage> i also think we'll all but see 64-128mb usb sticks in crackerjack boxes any day now ;)
**** ENDING LOGGING AT Fri Feb 16 02:59:57 2007