**** BEGIN LOGGING AT Sun Jun 26 23:59:57 2005 Jun 27 02:27:32 hi all Jun 27 02:27:58 is #oe switch to monotone a done issue? Jun 27 02:29:42 What is the nslu2-linux policy regarding the move? We follow whatever decision oe makes? Jun 27 02:30:47 we are pushing for monotone, and have our new repos ready to go Jun 27 02:31:18 and have driven some of the policy for #oe usage to be best for us too Jun 27 02:33:09 How long is this testing phase going to last and what is the best way to access the development branch of openslug until the final decision is reached? Jun 27 02:33:47 hanjo, youre openslug right? Jun 27 02:33:47 use the Master Makefile Jun 27 02:34:00 dyoung, yes Jun 27 02:34:25 in that case, you probably just want to use the Master Makefile at http://www.nslu2-linux.org/Makefile Jun 27 02:34:28 testing will end on July 1 :-) Jun 27 02:35:10 then you can "make openslug-setup; make openslug-build" Jun 27 02:35:33 or maybe thats openembedded-setup; check the makefile. :-) Jun 27 02:35:46 Thx. I'll take a look at that. Jun 27 02:36:38 dyoung: debating whether the risk of cascaded mtn repos outweighs the convenience Jun 27 02:36:42 it'll make all of it if you type "make". Jun 27 02:37:02 and all of it for me doesnt finish yet. And it takes 10G. Jun 27 02:37:21 re NAiLs checkin on cron init into nslu repo instead of openembedded repo due to being in top level dir Jun 27 02:37:51 Oh, you mean the chance of doing "mt add foo/some/file" rather than "cd foo; mt add some/file" ? Jun 27 02:37:54 yeah.. Jun 27 02:39:05 yeah Jun 27 02:39:18 can we un-monotone-ify the top level directory? Jun 27 02:39:39 hopefully we can get them to exclude that case if foo is in the top-level ignore Jun 27 02:39:45 I guess that makes it hard to do stuff. Jun 27 02:40:03 top-level repo includes openslug and unslung infrastructure files too Jun 27 02:40:22 we merged thse three into one Jun 27 02:41:33 we could unmerge them again, but then you don't get an auto-updating Makefile for free (or other top-level files we add) Jun 27 02:42:02 I consider it a bug so I'm thinking of leaving it Jun 27 02:42:31 it's not a fatal problem - you don't loose data, you just can't find it ... Jun 27 02:42:37 yeah Jun 27 02:42:41 I would leave it Jun 27 02:42:50 more incentive to fix it Jun 27 02:43:06 because there was some talk in the last 2 days about a similar bug in #monotone. Jun 27 02:43:29 lost adds or something; i wanst npaying attention. Jun 27 02:43:46 what version of monotone are you using? Jun 27 02:44:13 0.19 Jun 27 02:48:04 Ok, running make openslug-build now. I hope this is not going to mess up my existing tree? Jun 27 02:48:33 I hope you did it in a new empty directory ... Jun 27 02:49:59 I hope you've told me that sooner :) Jun 27 02:51:49 hanjo: you've still got plenty of time as it would still be downloading the db Jun 27 02:52:19 dunno what motone does if you co over an existing dir Jun 27 02:53:11 that's the only step which could clobber data Jun 27 02:54:17 in an empty dir it gives me: [openembedded@server slug_devel]$ make openembedded-setup Jun 27 02:54:18 [ -e openembedded/conf/machine/nslu2.conf ] || monotone --quiet co -b org.openembedded.nslu2-linux openembedded Jun 27 02:54:18 monotone: misuse: no database specified Jun 27 02:55:16 Ah, yo probably need to do make monotone-setup. Jun 27 03:00:38 is twente the only available server? its realy slow Jun 27 03:01:03 you think that's slow wait till you get to the nslu2 bits. Jun 27 03:01:06 :-) Jun 27 03:01:23 Its going to be 21MB or so from ewi Jun 27 03:01:40 then another 6 or 7MB from mtn.nslu2-linux Jun 27 03:02:01 Oh, I see what you ment ... :) It is slow! Jun 27 03:04:01 it actualy stopped on 20.7 doung a pull from mtn.nslu2-linux Jun 27 03:11:35 (I hope) it'll eventually finish... Jun 27 03:12:13 hanjo, you can save some time by symlinking downloads to your old downloads directory so it doesnt have to re-download source you already have. Jun 27 03:13:17 ~seen Jacmet Jun 27 03:13:17 jacmet is currently on #openjtag (1d 20h 22m 25s) #elinux (1d 20h 22m 25s) #nslu2-linux (1d 20h 22m 25s) Jun 27 03:53:03 http://wl500g.info/showthread.php?p=17532#post17532 <- new asus router Jun 27 03:53:43 built in BT Client? Jun 27 03:53:55 yep, and 3 USB 2.0 ports Jun 27 03:54:12 USB RAID capability? Jun 27 03:54:14 wow. Jun 27 03:54:17 you've got my attention now Jun 27 03:54:38 looks like it would mount vertically too :-) Jun 27 03:54:58 BCM 4780 Jun 27 03:55:24 Hmm, we need to get a few for development. Jun 27 03:55:45 err, for "product enhancement". Jun 27 03:56:39 dyoung-zzzz: we'll need some to test Optware compatibility Jun 27 04:27:17 has anyone had anyluck with exporting nfs partitions on openslug? Jun 27 04:36:43 haven't tried Jun 27 04:38:38 the nfs kernel module loads but mountd is writing this to the log Jun 27 04:39:32 Dec 4 23:59:58 minoc user.warn mountd: getfh failed: No such device Jun 27 04:40:05 only thing i can find on google suggests its an nfs kernel module problem Jun 27 05:01:48 kared: portmapper is running ? Jun 27 05:02:07 yeah Jun 27 05:02:12 portmapper and mountd Jun 27 05:02:33 strace -fF mountd it becomes then :) Jun 27 05:04:10 ah did you user kernel or userspace nfs ? Jun 27 05:08:44 sh: strace: not found <-- probably need to find a pkg for that Jun 27 05:09:10 umm i just installed nfs-utils from openembedded not sure if its using userspace or kernel Jun 27 06:01:48 urgs, my external hdd-box has no serial :( Jun 27 06:08:21 I see the bk server is no longer responding so I guess it's safe to say that the switch to svn has been done right? Jun 27 06:09:30 VoodooZ_Work: we haven't touched the bk server, so bitmover must have turned it off Jun 27 06:09:38 and we're switching to monotone Jun 27 06:10:27 "mkdir /home/slug ; cd /home/slug ; wget http://www.nslu2-linux.org/Makefile ; make setup ; make update ; make openslug-build" Jun 27 06:11:11 strange. Jun 27 06:11:25 ok. I'll read up on it. Jun 27 06:11:33 It's a bit early for them to turn it off Jun 27 06:11:36 Still got a couple of days left Jun 27 06:11:38 I just know that bk pull times out. Jun 27 06:11:47 unless our server is down? Jun 27 06:12:09 VoodooZ_Work: be aware that the monotone repo will be regenerated just after July 1. Jun 27 06:12:42 The bkbits server is down at the moment. Must be for maint or it's just broken Jun 27 06:12:43 ok. Hopefully I won't have to redo my tree as I have lots of private changes in there. Jun 27 06:12:50 Tiersten: thanks. Jun 27 06:14:24 VoodooZ_Work: I kept suggesting that you start a voodooslug distro ... Jun 27 06:15:39 I know but there's not enough difference between the two. It's just a bunch of private tweaks. Jun 27 06:15:53 Are you saying the whole OE tree is about to change? Jun 27 06:16:08 VoodooZ_Work: the smaller the difference, the easier to create voodooslug distro Jun 27 06:17:34 the structure of the tree isn't changing. the repo it's stored in definitely is Jun 27 06:17:54 sure but lazyness prevails! :) I'm trying to put the little spare time I have on the actual robot instead of the darn OS like I've been doing for the last year. Jun 27 06:18:04 I see. Jun 27 06:18:47 VoodooZ_Work: keeping local tweaks is the opposite of lazy. then you have maintain them instead of getting someone else to do it. Jun 27 06:18:58 hehehe true. Jun 27 06:19:12 why do you think I started nslu2-linux? Jun 27 06:19:17 :) Jun 27 06:19:30 I do like control though. Jun 27 06:19:49 control -> voodooslug Jun 27 06:20:26 sounds good but I'm not sure where to start. Jun 27 06:22:03 anyways, we'll see how it goes when the switch is upon us and I have no more choices. Jun 27 06:22:15 rwhitby-away: You been taking lessons from Linus about backups? :) Jun 27 06:23:47 Tiersten: I usually don't need to backup, cause all my work is replicated many times across the internet in repos. Jun 27 06:24:06 That's exactly his philosophy Jun 27 06:24:17 Put it up on a FTP site and let the world do backups :) Jun 27 06:25:47 Rest assured that I have now backed up my private keys onto different media ;-) Jun 27 06:26:05 heh. you need to talk to ByronT about that Jun 27 06:26:21 heh Jun 27 06:56:44 * jf-work entering logger mode Jun 27 07:00:50 jacques: you wanted something? Jun 27 07:02:07 Jacmet, hi, I am interested in your work running the slug little-endian Jun 27 07:02:27 Jacmet, are you setting the endianness in the bootloader or the kernel ? Jun 27 07:02:38 jacques: ok, I'm working on a webpage about it Jun 27 07:02:48 jacques: in the kernel startup Jun 27 07:02:57 Jacmet, great, I would love to see it - in kernel startup - perfect Jun 27 07:03:29 jacques: I did a arch/arm/boot/compressed/little-endian.S like the big-endian.S Jun 27 07:04:09 aha, are your changes available anywhere? Jun 27 07:04:50 jacques: well, I would like to finish up the webpage first - it Jun 27 07:04:52 also, did you try running the CSR (ixp425-eth stuff) in LE mode ? Jun 27 07:04:58 it's a bit of a mess at the moment ;) Jun 27 07:05:08 Jacmet, OK no problem, I understand Jun 27 07:05:32 * rwhitby-away always wonders why people are reluctant to show half-finished information ... Jun 27 07:05:40 jacques: Yes, I tried - I got it to compile, but it gives a kernel panic - I'm currently using a usb->ethernet adapter Jun 27 07:06:07 * rwhitby-away usually puts up half-finished information so that someone else will finish it ... Jun 27 07:06:34 rwhitby-away: well, I'm not really - it'll probably just take longer to explain it than finishing up the webpage Jun 27 07:07:05 jacques: but anyway, you can have a sneak preview at http://peter.korsgaard.com/articles/debian-nslu2.php ;) Jun 27 07:07:22 Jacmet, thanks! Jun 27 07:07:47 jacques: I'm planning on finishing it in a day or two - going on holiday on friday Jun 27 07:09:05 ah, I had not expected this: "The kernel image furthermore needs to be byteswapped before upload as it is loaded into memory by RedBoot running in big endian mode, but needs to be read by the Linux kernel running in little endian mode." Jun 27 07:09:45 jacques: Yes, that also took me a little while to find out - it makes perfectly sense now afterwards ;) Jun 27 07:09:56 :-D Jun 27 07:10:15 Jacmet: nice work! Jun 27 07:10:37 what symptom did you get before you byteswapped the kernel ? Jun 27 07:11:11 * rwhitby-away wonders if we could create a debianslug distro in OE ... Jun 27 07:11:17 rwhitby-away: thanks - It still needs some text about putting it into flash and making it easy to use and so on.. Jun 27 07:11:37 jacques: hmm, I think I just didn't got any output on the serial console Jun 27 07:11:52 the bootloader jumped to kernel and then nothing? Jun 27 07:12:01 rwhitby-away: well, you don't really need to as it's all just an apt-get away .. Jun 27 07:12:31 jacques: yes, I think so - it's a few weeks ago (I have quite limited time to work on it) Jun 27 07:12:39 ok Jun 27 07:12:44 * Jacmet just had a daughter ;) Jun 27 07:12:50 Jacmet: I was talking about getting OE to create a flashable image which is the kernel and netinstaller. Just boot and run Jun 27 07:13:04 Jacmet: congrats. I have a six month old daughter myself. Jun 27 07:13:41 rwhitby-away: then you know what I'm talking about ;) Jun 27 07:13:49 rwhitby-away: ok Jun 27 07:14:01 hmmmm /me sees debian + nslu2 :) Jun 27 07:14:53 jacmet: why connect a "Remember to connect your USB ethernet adapter and USB hard drive: Jun 27 07:14:57 ? :) Jun 27 07:15:03 the thing has internal ethernet ;) Jun 27 07:15:13 hmm, what would be the best way to indentify my external disk with udev if the box doesn't use a serial? Jun 27 07:15:37 Fuzzel: because the npe isn't currently working in little endian mode on 2.6 Jun 27 07:15:41 Fuzzel, internal ethernet depends on intel binary stuff Jun 27 07:15:46 aah Jun 27 07:15:49 okay that makes sense Jun 27 07:16:05 well I have a usb wireless thing on order anyway Jun 27 07:16:20 which one? Jun 27 07:16:32 * rwhitby-away has a zd1211-based usb wireless thing Jun 27 07:16:38 Fuzzel: it should be possible to get the NPE working, but I haven't had time to play around with it that much - and I had an USB-> ethernet adapter already Jun 27 07:16:56 Jacmet, that page looks great! what are you talking about it's not ready? :-) Jun 27 07:17:21 netgear wg111 Jun 27 07:17:29 which is supposed to work Jun 27 07:17:38 jacques: it's ready for developers to follow, but not ready for the majority of the mailing list readership ... Jun 27 07:17:40 jacques: well, the end of the document could use a bit more work ;) Jun 27 07:17:41 and otherwise my laptop suddenly has some better wireless :) Jun 27 07:18:18 jacques: And I rather finish it up than answering a bunch of silly emails about it .. Jun 27 07:18:18 * jf-work entering logger mode Jun 27 07:18:47 Jacmet, yes I think there will be quite some interest in this Jun 27 07:19:14 I am very sure .. .because of the debian component :) Jun 27 07:19:47 yes, the slug is quite cheap for a debian box Jun 27 07:26:24 night all Jun 27 07:26:30 `night rwhitby-asleep Jun 27 07:26:38 jacques: I'll tell you when I update the page Jun 27 07:28:40 Jacmet, thanks :-) Jun 27 07:28:57 nice work Jun 27 07:30:27 thanks Jun 27 07:31:41 Jacmet: when you're ready, I'd be happy to create a DebianSlug wikigroup alongside OpenSlug and Unslung ... Jun 27 07:32:19 www.nslu2-linux.org/wiki/DebianSlug/HomePage ... Jun 27 07:37:05 rwhitby-asleep: ok Jun 27 07:38:55 gnite, rwhitby-asleep :) Jun 27 07:39:36 Jacmet: congrats! Jun 27 07:43:15 hi NAiL_ Jun 27 07:43:24 gn8 rwhitby-asleep Jun 27 07:43:30 NAiL_: hi, and thanks Jun 27 07:45:58 jacmet: hmmm the serial mod can be avoided can't it? one can telnet into redboot too afaik Jun 27 07:48:38 Fuzzel: yes. arping -f ip && telnet ip 9000, switch on slug, get ready with ctrl-c Jun 27 07:49:05 I have the feeling I've done that a gazillion times Jun 27 07:49:38 thought so :) Jun 27 07:49:57 I don't want to wreck the case :) Jun 27 07:51:00 You don't need to mod the case tho Jun 27 07:58:08 03bzhou * 10unslung/make/monotone.mk: monotone built Jun 27 07:58:17 heh, neat Jun 27 08:02:08 nice Jun 27 08:10:07 mr_claus: Does cron fail to install? Jun 27 08:10:14 NAiL_: yes Jun 27 08:10:30 how? Why? Jun 27 08:10:58 NAiL_: i think it's because the command "install -s ..." will be used which means to strip the file while installing Jun 27 08:11:12 NAiL_: perhaps the strip command of the native compiler will be used Jun 27 08:11:59 mr_claus: hmm... I can't see this -s switch Jun 27 08:12:12 NAiL_: i will take a look again Jun 27 08:12:57 $(INSTALL) -c -m 111 $(INSTALLOWN) -s cron ....... Jun 27 08:13:00 mr_claus: I think I did the last change to cron, but that was just installing an init script Jun 27 08:14:01 NAiL_: cron and crontab will be installed with "-s" Jun 27 08:14:13 mr_claus: yeah, found it. in the patch Jun 27 08:14:27 NAiL_: i think the straight forward way is to use sed to take the "-s" out Jun 27 08:15:16 Well... It works for me (tm) Jun 27 08:15:24 NAiL_: then it's much simpler, change the patch :) Jun 27 08:15:43 NAiL_: did you take the "-s" out? Jun 27 08:16:05 No, it was installed the same way, which makes me wonder why yours faul Jun 27 08:16:07 fail Jun 27 08:17:35 install: strip failed Jun 27 08:17:36 make[2]: *** [install] Error 1 Jun 27 08:17:52 strip: Unable to recognise the format of the input file Jun 27 08:17:54 What distro are you running? Jun 27 08:18:00 debian sarge Jun 27 08:18:06 Yeah, it's trying to strip it with the host strip Jun 27 08:18:38 that's what i mean, install is using the host strip by default Jun 27 08:19:34 Fuzzel: yes, you can telnet into Redboot, but the debian installation is also through the serial console Jun 27 08:19:45 Fuzzel: perhaps you could do it through netconsole Jun 27 08:20:11 Jacmet: netconsole only does logging. It's not a proper "console" per se Jun 27 08:20:15 Fuzzel: I'm thinking on providing a preinstalled base image so you don't need the serial mod Jun 27 08:20:53 NAiL_: ok, I've never used it Jun 27 08:21:20 NAiL_: did you some tests with udev? Jun 27 08:21:29 serial console is imho not such a big deal either - but for others it might ;) Jun 27 08:22:24 mr_claus: udev is running great since I installed it. It's installed on all new openslug builds by default now Jun 27 08:22:42 which reminds me, I need to fix so that udevutils are built and installed as well Jun 27 08:23:18 NAiL_: yes, i have done it, only RDEPENDS need udev-utils included while building Jun 27 08:23:40 NAiL_: but now i try to use permanent device naming and it's not working Jun 27 08:24:26 mr_claus: Could you add some notes on the bug on slugbug? I've gotta go out for a little while to buy food & stuff Jun 27 08:24:56 NAiL_: which bug? the "-s" of cron? Jun 27 08:25:13 udev, so I'll remember that it needs fixing ;) Jun 27 08:25:43 NAiL_: i dont know if there is something wrong here, i think i'm to stupid to create richt rulesets :) Jun 27 08:26:13 Anyone else running openslug? Can anyone verify if cron compiles/does not compile? Jun 27 08:26:35 Ah, I haven't done that yet. I'll be looking into that this evening. Jun 27 08:27:02 bbiaw Jun 27 08:27:23 happy shopping :) Jun 27 08:40:15 NAiL_: udev with persistent naming is working now Jun 27 08:40:54 can anybody verify if udevinfo -a -p /sys/bus/.... gives information about the serial of the external harddisk? Jun 27 08:45:58 mr_claus: udevinfo -a -p /sys/block/sdb/sdb1 Jun 27 08:47:16 NOTE: package cron-3.0pl1: completed Jun 27 08:47:36 I don't get why yours fail and mine doesn't. Jun 27 08:49:56 kergoth: ping? Jun 27 08:57:24 mr_claus: udevinfo -a -p /sys/block/sdb/sdb1 |grep SYSFS{serial}. The first line should be the serial of the device Jun 27 08:57:40 In my case, it seems to be the serial of the hdd enclosure Jun 27 08:58:08 jbowler:) Jun 27 08:58:20 NAiL :) Jun 27 08:58:38 Wow, lots of changes Jun 27 08:58:57 (Well, they look small, but that's a lot of stuff over 36 hours). Jun 27 08:58:57 Samba now compiles and runs like clockwork (Well, almost) Jun 27 08:59:52 Yes - and the stuff in the site looks minimal. Did you find out anything about the 64bit (LFS) support config? Jun 27 09:00:20 No. I have it running on my build due to a *ugly* configure.in hack Jun 27 09:01:34 Basically, I ignore all the LFS tests and just set the CPPFLAGS myself. But that's probably not anything all other distros would like :P Jun 27 09:02:36 I've recompiled samba at least 40 times to try to get LFS working with the site vars. No luck. Jun 27 09:02:45 NAiL: my box use no serial and i cannot get the serial of the disk itself Jun 27 09:03:06 mr_claus: Could you paste the output of udevinfo on pastebin? Jun 27 09:04:17 64 bit support: it should be able to work it out itself, because the headers define appropriate macros. Jun 27 09:04:52 configure figures that LFS support is "cross". And then it doesn't add the appropriate CPPFLAGS Jun 27 09:05:28 NAiL: http://paste.uni.cc/7350 Jun 27 09:07:11 Hum. LFS_SRC_URI="" LFS_SRC_URI_openslug="configure.in.lfs.patch;patch=1" ... SRC_URI = ".... ${LFS_SRC_URI} ..." Jun 27 09:07:22 mr_claus: Hmm... I guess the most unique identifiers would be model and revision Jun 27 09:07:42 Maybe nslu2 not openslug - LFS support in libc is a compile time option (at least with uclibc). Jun 27 09:07:59 jbowler: Aha, that'd enable my ugly hack only on the slug, right? Jun 27 09:09:16 Right - on nslu2 only (with _nslu2), so unslung, openslug but nothing else. Jun 27 09:09:52 Any other distro can add it just by adding another _distro line. Jun 27 09:09:57 neato Jun 27 09:10:23 Well, sort of ugly, but safe in the OE environment. Jun 27 09:10:32 hehe, yeah. Jun 27 09:11:57 I see the cron build failing as before - it invokes my installed (host) install which cannot handle -s on the armeb executable. Jun 27 09:12:57 aha... so it's the "install" binary that screws it up? Jun 27 09:13:14 not make calling the wrong strip? Jun 27 09:13:38 Why does it work here? Jun 27 09:13:49 Is your install a shell script? Jun 27 09:14:25 nope Jun 27 09:14:49 Try: Jun 27 09:14:59 strings /bin/install | egrep STRIP Jun 27 09:15:21 no hits Jun 27 09:16:30 Hum. STRIP is set as an environment variable in temp/run.do_install to armeb-linux-strip, which will work. Jun 27 09:16:57 Many packages use the MIT/GNU install.sh, which expects STRIP or STRIPPROG and works. Jun 27 09:17:27 jbowler: btw: http://paste.uni.cc/7351 <-- like that? Jun 27 09:17:29 But my do_package task fails as follows: Jun 27 09:17:31 | install -c -m 111 -s cron /home/work-tmp/jbowler/nslu2/osuclibc/work/cron-3.0pl1-r2/image/usr/sbin/ Jun 27 09:17:31 | strip: Unable to recognise the format of the input file /home/work-tmp/jbowler/nslu2/osuclibc/work/cron-3.0pl1-r2/image/usr/sbin/cron Jun 27 09:17:44 yeah, same as mr_claus Jun 27 09:19:06 NAiL: yes, I'd call it configure.lfs.patch (without the nslu2) though, because it's not really nslu2 specific - if you put a comment in then other distros might use it and OE can just put it in for everything if they want. Jun 27 09:19:23 ok, done Jun 27 09:20:21 hmm, its hard to find docs which include all informations about VARIABLES which could be used with hotplugging Jun 27 09:21:50 mr_claus: Do you need more than $DEVNAME and $ACTION? Jun 27 09:23:10 NAiL: the symlink would be nice instead of devname Jun 27 09:24:02 NAiL: BUS="scsi", KERNEL="sd*", SYSFS{model}=="B250R0", NAME="%k", SYMLINK="exta%n" Jun 27 09:24:16 NAiL: i want to get "exta" instead of "sda" Jun 27 09:24:52 aha Jun 27 09:25:06 jbowler: Hmm... the patch didn't get applied? Jun 27 09:28:41 It doesn't for me either. I thought that trick had worked though. Jun 27 09:29:15 Oh, I remember - in my case I didn't create the file, and bb is silent if it doesn't find the file (!) Jun 27 09:29:53 hmm.. Jun 27 09:30:22 is there a special reason why the command "file" will not be included? Jun 27 09:30:51 Which is, of course, another way of doing the same thing - create the patch in files/nslu2/configure.lfs.patch - but that's really obscure. Jun 27 09:31:09 No. Still can't get it to work... Jun 27 09:37:50 Two problems: the syntax I gave was wrong (it should have a file:// in front) and the SRC_URI is assigned by :=, not = Jun 27 09:37:51 * mr_claus is away: "sport" Jun 27 09:39:15 jbowler: The first one I've fixed already :) Jun 27 09:39:53 This works: http://paste.uni.cc/7352 Jun 27 09:43:31 eeeyh... neat. Jun 27 09:43:44 bb -cclean samba && bb samba <-- cleans outs and builds. Jun 27 09:44:07 Now it applies. Thanks. Jun 27 09:50:41 * NAiL is getting kinda used to compiling samba now Jun 27 09:51:45 jbowler: btw, any idea on how to fix cron? I've heard about the strip problem before... Jun 27 09:52:55 Isn't there some kind of ... "Common Pitfalls with OE"? ;) Jun 27 09:53:53 I'm trying a fix. I just copied the automake install-sh into files and used it... Jun 27 09:54:24 Remarkable, worked first time :) Jun 27 09:55:18 haha :) Jun 27 09:56:40 Hum. It seems to be ignoring the -m 4111 - it's doing -m 4555. Now I think that is reasonable, but... Jun 27 10:00:34 NAiL: can you mt sync and try org.openembedded.nslu2-linux.testing (for the cron fix). Jun 27 10:03:43 hmm.. how do I try .testing? Jun 27 10:03:45 Upgrading ¾ÿþ,¾ÿÿ samba on root from 3.0.14a-r5 to 3.0.14a-r6... Jun 27 10:03:59 And what's up with ipkg adding those characters? Jun 27 10:07:32 There doesn't seem to be an mt command to do this. Jun 27 10:09:27 hmm.. Jun 27 10:09:41 I just editing MT/options to add the .testing suffix. Seems to work. Jun 27 10:11:09 Didn't get any revs from .testing Jun 27 10:11:18 Getting back is tricky because 'mt update' is apparently unwilling to go backward. Jun 27 10:11:52 What does mt heads say is the head revision? Jun 27 10:11:55 yes, I see that now.. Jun 27 10:12:02 monotone: branch 'org.openembedded.nslu2-linux' is currently merged: Jun 27 10:12:02 e9d7db881168ed183815c8736437d2e85b468ad8 oyvind@repvik.org 2005-06-27T17:06:37 Jun 27 10:12:06 [g2]:) Jun 27 10:12:29 <[g2]> hey NAiL Jun 27 10:12:30 <[g2]> :) Jun 27 10:12:32 You didn't change MT/options then ... Jun 27 10:12:43 <[g2]> hey jbowler Jun 27 10:12:46 monotone: including branch org.openembedded.nslu2-linux.testing Jun 27 10:12:46 monotone: [certs: 216] [keys: 7] Jun 27 10:12:57 hi [g2] Jun 27 10:13:29 NAiL: it's possible to ' Jun 27 10:13:37 <[g2]> BTW I was going to try and ping kergoth and the OE guys about the kernel headers Jun 27 10:14:04 get back' by changing MT/revision to the required head, the working tree then contains all the changes (from .testing) as uncommited. Jun 27 10:14:15 This is, of course, correct... Jun 27 10:14:58 [g2]: You checked the samba .bb re. swat? Jun 27 10:15:53 <[g2]> NAiL, not yet Jun 27 10:16:12 PACKAGES =+ "swat" Jun 27 10:16:12 FILES_swat = "${sbindir}/swat ${datadir}/swat ${libdir}/*.msg" Jun 27 10:16:46 Think that's all you need Jun 27 10:17:05 That's in there isn't it? Jun 27 10:17:22 in the samba.bb? yes. Jun 27 10:17:31 Just using that as an example :) Jun 27 10:17:35 <[g2]> so PACKAGES =+ "kernel-headers" Jun 27 10:18:41 yeah Jun 27 10:19:22 jbowler: I'm not getting the cron stuff though.. Jun 27 10:20:10 What does mt heads output? Jun 27 10:20:22 still the same Jun 27 10:20:22 monotone: branch 'org.openembedded.nslu2-linux' is currently merged: Jun 27 10:20:22 e9d7db881168ed183815c8736437d2e85b468ad8 oyvind@repvik.org 2005-06-27T17:06:37 Jun 27 10:20:25 <[g2]> then I'll need to figure out which var points to the linux-x.y.z.a tree/include/{asm|asm-generic|linux} Jun 27 10:20:41 [g2]: Yeah, I was trying to figure that one out myself :P Jun 27 10:20:48 You have to edit MT/options to change the branch to .testing, then run mt update. Jun 27 10:20:56 [g2]: Should be in the kernel.bb though... Jun 27 10:21:47 fs openembedded # mt update Jun 27 10:21:47 monotone: already up to date at e9d7db881168ed183815c8736437d2e85b468ad8 Jun 27 10:21:47 fs openembedded # cat MT/options|grep branch Jun 27 10:21:47 branch "org.openembedded.nslu2-linux.testing" Jun 27 10:22:06 aha Jun 27 10:22:17 monotone: branch 'org.openembedded.nslu2-linux.testing' is currently merged: Jun 27 10:22:21 313c2118166a4b6bce29f3aa5bb771b3456cdb20 jbowler@nslu2-linux.org 2005-06-27T16:59:04 Jun 27 10:23:11 but I'm *still* not getting the cron stuff, even after sync, pull, update Jun 27 10:23:25 Ok, I've just realised how to do this without hand hacking MT/options: "mt --branch=org.openembedded.nslu2-linux.testing update" Jun 27 10:24:20 Hum, I'll test it on another db... Jun 27 10:24:27 . Jun 27 10:24:45 !ping Jun 27 10:25:42 * NAiL pings Eiffel Jun 27 10:25:50 NAiL: you have two heads Jun 27 10:25:58 :) Jun 27 10:26:07 jbowler: It only says one? Jun 27 10:26:49 If I had several heads, I could merge, right? Jun 27 10:26:54 fs openembedded # mt merge Jun 27 10:26:54 monotone: misuse: branch 'org.openembedded.nslu2-linux.testing' is merged Jun 27 10:27:18 Right, I'm thinking that e9d7db881168ed183815c8736437d2e85b468ad8 is not in my tree. Let me check. Jun 27 10:29:29 Yes. This is confusing monotone I think - your nslu2-linux and nslu2-linux.testing share a common ancestor. Jun 27 10:29:55 That shouldn't be confusing monotone :P Jun 27 10:30:43 btw, that configure.in patch I made.. It'll apply when people compile for unslung as well? Anyone running unslung care to build&test samba? :) Jun 27 10:30:59 "mt update" seems to be very basic - up-to-date means MT/revision is not earlier in the current branch? Jun 27 10:31:29 samba: no, I don't think so. unslung samba is in optware. Jun 27 10:31:49 Only the core image is shared (unslung-image), and samba isn't in that. Jun 27 10:31:55 ah, ok Jun 27 10:32:32 then it only affects openslug at the moment Jun 27 10:32:40 You should unedit MT/options. I'm not sure how much confusion will result from your current state... Jun 27 10:33:33 yeah, now I'm back to my own head :-) Jun 27 10:34:30 Running mt update with both --branch and the revision argument will work, but it should remove the changes you have commited already to nslu2-linux. Jun 27 10:39:00 NAiL: run these two commands: mt --branch=org.openembedded.nslu2-linux.testing update Jun 27 10:39:08 mt update 313c2118166a4b6bce29f3aa5bb771b3456cdb20 Jun 27 10:40:09 Did that on a diff repo, and then I got the correct revision on the first try Jun 27 10:41:02 To get back to the main (non testing) branch run: Jun 27 10:41:14 mt --branch=org.openembedded.nslu2-linux update Jun 27 10:41:22 mt heads Jun 27 10:41:30 mt update Jun 27 10:41:41 Where is the correct head (there might be more than one...) Jun 27 10:42:32 I'm fairly confident this doesn't trample on changes in the directory, though if you have changed a file locally which is also changed between the different heads I'm not sure what happens (I suspect it tries to merge). Jun 27 10:43:15 Yeah, non of my local changes have been damaged. Jun 27 10:43:57 <[g2]> NAiL, fyi Jun 27 10:44:00 <[g2]> I think it's the asm-arm, asm-generic and linux directories Jun 27 10:44:00 <[g2]> [g2]: -rw-rw-r-- 1 pb pb 1129408 Jun 27 12:36 tmp/deploy/ipk/linux-libc-headers-dev_2.6.11.1-r1_arm.ipk Jun 27 10:44:24 <[g2]> pb_ thinks that should be pretty equivalent to our headers Jun 27 10:44:28 [g2]: I'm in #oe too ;) Jun 27 10:44:39 <[g2]> I'll try to diff difference Jun 27 10:47:32 yeah Jun 27 10:48:42 My idea here is that org.openembedded.nslu2-linux.testing can be used for things like those samba changes I made which really should be checked out by someone else (I couldn't test them because I didn't have a working samba config). Jun 27 10:48:57 Then the changes can be mt propagated back into the main branch. Jun 27 10:49:44 So if the cron change seems to work (I think the perms are ok, but I'm not 100% sure) I will propagate them back and sync. Jun 27 10:58:16 I'll test as soon as the changes are in Jun 27 10:58:47 I don't understand - the changes are in... Jun 27 10:59:01 ah, ok. I haven't synced yet Jun 27 10:59:35 well... synced now, but it's not there.. let me check my joeblow repo Jun 27 10:59:37 I.e. they are in org.openembedded.nslu2-linux.testing (that has all the core changes) Jun 27 10:59:45 <[g2]> have you guys seen this one ? Jun 27 10:59:48 <[g2]> + bk pull Jun 27 10:59:48 <[g2]> Entire repository is locked by: Jun 27 10:59:48 <[g2]> RESYNC directory. Jun 27 11:00:10 <[g2]> that's the repo being locked right ? Jun 27 11:01:07 Which repo? Jun 27 11:01:27 <[g2]> openembedded.bkbits.net Jun 27 11:01:46 <[g2]> my bk parent Jun 27 11:02:03 <[g2]> bk parent Jun 27 11:02:03 <[g2]> Parent repository is bk://nslu2-linux.bkbits.net/openembedded Jun 27 11:02:09 <[g2]> ok... I was kinda close Jun 27 11:02:10 jbowler: I get my "own" head when syncing the joeblow repo Jun 27 11:04:20 jbowler: btw, should it be necessary to fix it in the cron build? Isn't this kind of a problem with the users setup? Jun 27 11:05:07 mr_claus: Which distro were you running? Jun 27 11:05:15 were/are Jun 27 11:05:27 NAiL: you need to run the two commands I gave to swap to the .testing branch Jun 27 11:06:40 monotone: selected update target 313c2118166a4b6bce29f3aa5bb771b3456cdb20 Jun 27 11:06:40 monotone: misuse: no common ancestor for b2301c08f9fcccfba81034a3eb7397a31e414ab1 and 313c2118166a4b6bce29f3aa5bb771b3456cdb20 Jun 27 11:06:43 cron: I don't even know what version of install actually works! The cron Makefile is broken for cross under bitbake, because there is no cross install. Jun 27 11:07:51 My install (/bin/install from coreutils) seems to work just fine. Jun 27 11:09:17 osuclibc:/home/nslu2/tmp/openembedded $ mt update b2301c08f9fcccfba81034a3eb7397a31e414ab1 Jun 27 11:09:18 monotone: selected update target b2301c08f9fcccfba81034a3eb7397a31e414ab1 Jun 27 11:09:18 monotone: misuse: revision b2301c08f9fcccfba81034a3eb7397a31e414ab1 is not a member of branch org.openembedded.nslu2-linux Jun 27 11:09:18 monotone: misuse: try again with explicit --branch Jun 27 11:10:51 NAiL: I.e. try it in the correct directory (openembedded, not org.nslu2-linux.dev) Jun 27 11:11:28 I did. Jun 27 11:12:50 The revision b2301c08f9fcccfba81034a3eb7397a31e414ab1 does exist in my db (recently synced) but it does not exist on the org.openemebedded.nslu2-linux branch. Jun 27 11:14:00 Compare the output of "mt list certs" for the two revisions (in particular the 'branch' certificate). Jun 27 11:14:23 ah, now the files are there... But it's been saying it's up to date a dozen times Jun 27 11:15:42 'up to date' seems to mean that the revision of your working copy is NOT an ancestor of the head of the branch. Jun 27 11:16:08 So that includes the case where working-rev and branch-rev have a common ancestor but working-rev is on a different branch. Jun 27 11:16:57 So what head revision do you have now (on org.openembedded.nslu2-linux?) Jun 27 11:17:28 building right now, will check in a while Jun 27 11:18:07 ;-) I just built cron Jun 27 11:19:58 nice :) Jun 27 11:21:18 I'd really like to figure out the difference between your/mr_claus' environment and mine. Jun 27 11:21:57 Well, that's kind of easy - take any armeb executable and try the command "install -s /tmp" Jun 27 11:22:38 On my system: $ install -s busybox /tmp Jun 27 11:22:38 strip: Unable to recognise the format of the input file /tmp/busybox Jun 27 11:22:38 install: strip failed Jun 27 11:23:09 Then: osuclibc:/tmp $ strip busybox Jun 27 11:23:09 strip: Unable to recognise the format of the input file busybox Jun 27 11:23:26 strip: Unable to recognise the format of the input file /tmp/dropbearmulti Jun 27 11:23:47 But when installing cron, it manages (on my system) to pick the right "install" Jun 27 11:24:14 Ok, so now try: STRIP=echo install -s dropbearmulti /tmp Jun 27 11:24:15 or, install manages to pick the right strip Jun 27 11:25:05 nope, no joy Jun 27 11:26:24 ... run (in the cron work directory) temp/run.do_install* Jun 27 11:26:57 (that's in the cron*r2 directory - the one without my fix). Jun 27 11:27:39 fails Jun 27 11:27:44 yeah Jun 27 11:28:11 (it hasn't built -r3 yet, building a lot of other stuff first) Jun 27 11:30:11 ... it shouldn't fail! Jun 27 11:30:26 It works when it runs through bitbake... Jun 27 11:30:30 but ... Jun 27 11:30:34 * NAiL is stumped Jun 27 11:30:48 I've got a perfectly working, stripped ipk of r2 Jun 27 11:31:54 Look at temp/log.do_install* - this is the log of the one which succeeded. What's the fifth line? Jun 27 11:33:10 hmm Jun 27 11:33:17 ? Jun 27 11:33:48 Can't be. The log says it failed, but the binary *IS* stripped. Jun 27 11:34:26 install -c -m 111 -s cron /root/slug/openslug/tmp/work/cron-3.0pl1-r2/image/usr/sbin/ Jun 27 11:34:29 strip: Unable to recognise the format of the input file /root/slug/openslug/tmp/work/cron-3.0pl1-r2/image/usr/sbin/cron Jun 27 11:34:29 What do you mean by 'the log says it failed' - how can the log say it failed if the build succeeded? Jun 27 11:35:10 ok, I'm rerunning fs openslug # bb -cclean cron && bb cron Jun 27 11:35:49 Packaged contents of cron into /root/slug/openslug/tmp/deploy/ipk/cron_3.0pl1-r2_armeb.ipk Jun 27 11:35:54 NOTE: build 200506272034: completed Jun 27 11:35:57 Yes, but I don't understand what you said before - there should be nothing after line 5 of the log if it failed at the install. Jun 27 11:36:22 The install didn't fail, but strip did apparently not succeed. But the binary *is* stripped?!? Jun 27 11:36:50 install -c -m 111 -s cron /root/slug/openslug/tmp/work/cron-3.0pl1-r2/image/usr/sbin/ Jun 27 11:36:53 strip: Unable to recognise the format of the input file /root/slug/openslug/tmp/work/cron-3.0pl1-r2/image/usr/sbin/cron Jun 27 11:36:56 install: strip failed Jun 27 11:37:00 That's from the log from my just-finished build. Jun 27 11:37:27 Ok, you have a broken install - it doesn't check the return code from strip. Is this Debian? Jun 27 11:37:58 no, gentoo Jun 27 11:38:26 aha Jun 27 11:38:31 in log.RUNSTRIP: Jun 27 11:38:32 fs temp # cat log.RUNSTRIP.29098 Jun 27 11:38:32 armeb-linux-strip: /root/slug/openslug/tmp/work/cron-3.0pl1-r2/install/cron/./etc/init.d/cron: File format not recognized Jun 27 11:38:35 armeb-linux-strip: Warning: '/root/slug/openslug/tmp/work/cron-3.0pl1-r2/install/cron/./var/cron/tabs' is not an ordinary file Jun 27 11:39:01 It tries to strip all the files. It succeeds with the binary Jun 27 11:40:01 Why on earth does it try to strip the crontab? Jun 27 11:40:07 And that is *BOUND* to fail. Jun 27 11:40:41 ehrm, not crontab.. init script ;) Jun 27 11:43:00 It's a safety measure in classes/package.bbclass. It can be stopped by setting INHIBIT_PACKAGE_STRIP Jun 27 11:44:16 Ok, so if you run install -s dropbearmulti /tmp; echo $? what results? Jun 27 11:44:54 And what does install --version say? Jun 27 11:45:07 haha Jun 27 11:45:10 jbowler:$ install --version Jun 27 11:45:10 install (coreutils) 5.2.1 Jun 27 11:45:10 Written by David MacKenzie. Jun 27 11:45:29 0 Jun 27 11:45:34 install (coreutils) 5.2.1 Jun 27 11:45:34 Written by David MacKenzie. Jun 27 11:45:47 So it returns 0, even when failing to strip Jun 27 11:45:57 Hum, I had better check my status code too then... Jun 27 11:46:03 * NAiL takes a look at gentoo's coreutils package Jun 27 11:46:21 1! Jun 27 11:46:55 Try strip /tmp/dropbearmulti - I get a return code of 1 Jun 27 11:47:08 osuclibc:/tmp $ strip --version Jun 27 11:47:09 GNU strip 2.15.92.0.2 20040927 Jun 27 11:47:34 fs coreutils # strip --version Jun 27 11:47:34 GNU strip 2.15.92.0.2 20040927 Jun 27 11:47:37 (BTW I'm running getoo as well) Jun 27 11:48:08 What's the return code? Jun 27 11:49:00 strip: Unable to recognise the format of the input file cron Jun 27 11:49:00 1 Jun 27 11:49:32 Now I don't understand. The only thing I can think is that your install is using a different strip somehow. Jun 27 11:49:48 ok, I'll check strace Jun 27 11:50:10 My strip: file /usr/bin/strip Jun 27 11:50:13 /usr/bin/strip: symbolic link to `i686-pc-linux-gnu-strip' Jun 27 11:50:30 fs sbin # file `which strip` Jun 27 11:50:30 /usr/bin/strip: symbolic link to `i686-pc-linux-gnu-strip' Jun 27 11:51:56 emerging strace first will probably help :-P Jun 27 11:53:18 But, since the binary is stripped (not by install), do we need the -s on install? Jun 27 11:54:28 There's no need for the -s but it's an unnecessary patch to the Makefile - it seems better to make the change in the .bb Jun 27 11:55:53 I think the difference has to be in the install program itself. On my system /bin/install is the real executable (/usr/bin/install is a link). Jun 27 11:56:22 same as mine Jun 27 11:56:57 What happens if you run /bin/install -s dropbearmulti /tmp - does it still give a 0 return code? Jun 27 11:57:41 For that matter, what about "env -i /bin/install -s busybox /tmp" Jun 27 11:58:01 (or dropbearmulti, whatever) Jun 27 11:58:36 fs cron3.0pl1 # env -i /bin/install -s cron /tmp/ ; echo $? Jun 27 11:58:37 strip: Unable to recognise the format of the input file /tmp/cron Jun 27 11:58:37 /bin/install: strip failed Jun 27 11:58:37 0 Jun 27 11:59:29 Ok, so maybe when bitbake runs you have /usr/bin/X11R6 on your path ahead of /usr/bin and /bin? Jun 27 11:59:49 You can check the PATH in temp/run.do_install Jun 27 12:01:31 On my system /usr/X11R6/bin/install is just a link to /bin/install, but X11 is the source of that install.sh script. Jun 27 12:01:55 X11R6 isn't in my path at all Jun 27 12:02:16 (in do_install or otherwise) Jun 27 12:03:52 Is your gentoo install up-to-date? Jun 27 12:04:00 Mine isn't, so there might be some change there Jun 27 12:04:49 I am emerged to the big init files change (the one with 37 new config files). Jun 27 12:05:05 I think that coreutils changed around then - problem is that our version numbers match. Jun 27 12:05:18 the revs may not match, so there might be a patch Jun 27 12:05:55 which coreutils revision do you have? Jun 27 12:06:00 * sys-apps/coreutils Jun 27 12:06:00 Latest version available: 5.2.1-r6 Jun 27 12:06:00 Latest version installed: 5.2.1-r6 Jun 27 12:06:39 Latest version available: 5.2.1-r6 Jun 27 12:06:39 Latest version installed: 5.2.1-r5 Jun 27 12:06:55 Let's see if it breaks when I update ;-) Jun 27 12:08:57 There's like 30 patches applied, so there might be something that has changed between the revs Jun 27 12:09:02 Ok, I've got to go and get my fire extinguishers recertified (fire season started today), so if the cron looks ok I'll propagate that change when I get back (and, probably, propagate everything to OE). Jun 27 12:09:19 Yeah, ok Jun 27 12:09:42 I'll see if it was a freak occurence that my build worked Jun 27 12:09:59 If it was, I'll drop it and just install debian. Was planning to do that anyways Jun 27 12:10:27 * Applying various patches (bugfixes/updates) ... Jun 27 12:10:27 * 001_all_coreutils-mdk-lug.patch ... [ ok ] Jun 27 12:10:31 * 002_all_coreutils-mdk-spacedir.patch ... [ ok ] Jun 27 12:10:35 wwoooo. Jun 27 12:10:52 <-- almost pasted 50 lines of patching Jun 27 12:14:43 <[g2]> NAiL, jbowler jacques did someone cut openslug over to glibc 2.3.5 in bk ? Jun 27 12:15:24 I don't know, I've stopped using bk... Jun 27 12:16:00 <[g2]> and what's happened to the changeset idea ? Jun 27 12:16:25 <[g2]> did we lose changeset e-mails with the monotone conversion ? Jun 27 12:17:08 [g2]: hang on Jun 27 12:18:32 Related to this: ? Jun 27 12:18:32 17:52 < CIA-9> pb * r1.3638.1.2 openembedded/packages/glibc/glibc-cvs-2.3.5/ (dyn-ldconfig-20041128.patch ldsocache-varrun.patch): forgotten files Jun 27 12:18:36 17:52 < CIA-9> pb * r1.3638.1.1 openembedded/packages/glibc/ (4 files in 2 dirs): glibc updates Jun 27 12:18:57 Or does openslug specify which glibc version to stick to? Jun 27 12:20:22 jbowler: Still get returncode 0 from install, even though strip fails Jun 27 12:21:38 oh well.. It seems to be local to me :-P Jun 27 12:22:19 It must happen for someone else too, but I believe some versions of install used to do this anyway (ignore strip return codes). Jun 27 12:22:41 Still, it shouldn't be using the host install anyway - so my change should be safe. Jun 27 12:22:59 yeah Jun 27 12:23:17 what the?! Jun 27 12:23:59 Now samba doesn't work with large files again. Jun 27 12:24:51 oh well.. Jun 27 12:27:31 heey Jun 27 12:27:48 How much did people get transferring files to the slug again? Jun 27 12:28:07 I'm getting ~7MB/sec writing to the slug via samba Jun 27 12:28:30 <[g2]> NAiL, that's with OpenSlug ? Jun 27 12:28:39 yeah Jun 27 12:28:58 <[g2]> cool Jun 27 12:29:19 <[g2]> how about dropbear ? Jun 27 12:29:41 dunno, can't test that right now, moving a few gb to the slug ;) Jun 27 12:29:58 Backing up the needed stuff from my dev box. Gonna debify'it Jun 27 12:32:51 uh... scrap that... Midnight commander is apparently not doing the maths properly Jun 27 12:33:22 It if was, I just transfered stuff with ~30MB/sec to my slug. I don't really believe that :-P Jun 27 12:45:39 ka6sox-office: ping? Jun 27 12:58:34 * mr_claus is back (gone 03:20:51) Jun 27 12:58:40 NAiL: debian sarge Jun 27 12:58:56 mr_claus: yes? Jun 27 12:59:06 oh Jun 27 12:59:07 DUH Jun 27 12:59:26 you answered. Thought you were saying something about what debian I should install :-P Jun 27 13:00:11 NAiL: you asked :) Jun 27 13:00:17 exactly Jun 27 13:00:30 It looks like cron works on *my* box. And my box only :) Jun 27 13:00:41 jbowler's gonna push a change later, probably Jun 27 13:00:48 NAiL: haha, thats not enough :) Jun 27 13:01:24 NAiL: do you know the buildroot system of uclibc? Jun 27 13:01:38 NAiL: the unslung path looks like the buildroot system Jun 27 13:01:49 mr_claus: no. Atleast, not yet. Jun 27 13:02:46 NAiL: not today, but the build environment which is distributed with cvs from sourceforge looks a bit like the buildroot environment Jun 27 13:03:04 NAiL: as i started first time with the buildroot system it never worked with gentoo Jun 27 13:03:33 NAiL: then we found the solution, the CC variable was set on gentoo :) Jun 27 13:03:46 NAiL: sometimes only small things can be a big problem :) Jun 27 13:03:54 Yeah, I think we ran into that problem with openwrt Jun 27 13:04:16 haha Jun 27 13:04:24 NOTE: package cron-3.0pl1: failed Jun 27 13:04:24 ERROR: Build of cron failed Jun 27 13:04:31 Now it doesn't work anymore :P Jun 27 13:05:12 *something* happened between coreutils -r5 and -r6 that breaks it (Or fixes it, depends) Jun 27 13:05:31 r5/r6 on gentoo Jun 27 13:06:09 i stopped working with gentoo because i dont want to wait for days to upgrade my system Jun 27 13:06:24 it's a nice system but it needs a very long time to upgrade Jun 27 13:06:45 hehe, yeah Jun 27 13:07:05 And it sets a heap of environment variables too. This confuses a lot of build systems ;-) Jun 27 13:08:57 yes, i moved my system back to debian, with the disadvantage of older software Jun 27 13:11:34 Yeah, I really don't care much about the bleeding edge on my dev box though, as long as the dev tools are up to date Jun 27 13:40:19 [g2]: Whatcha find out with the headers? Jun 27 13:49:22 odd Jun 27 13:49:54 Samba doesn't show files >2GB. But it has no problems receiving them Jun 27 14:12:04 <[g2]> NAiL, they're in the latest pull from bk Jun 27 14:12:53 <[g2]> I haven't tested yet Jun 27 14:42:46 Hi: This is a repost from the general list: When monotone building 'make', unslung built fine, but openslug-build fails in 'cron' saying it cannot recognize the input file format when striping .../sbin/cron. ? Jun 27 14:45:02 yes Jun 27 14:45:12 We know :) Jun 27 14:45:49 Nail: OK, I will wait and watch, thanks Jun 27 14:46:08 temporary solution is to remove cron from OPENSLUG_PACKAGES in openembedded/packages/meta/openslug_packages.bb. The more permanent solution is to wait a few hours (probably) Jun 27 14:46:30 There is a fix, and it'll probably be pushed in a little while. Jun 27 14:46:55 Hi, I recieved a rewuest to allow logging of this channel on loglibrary.com. Is that ok with you all? Jun 27 14:47:26 *request Jun 27 14:47:41 dyoung made the request Jun 27 14:49:33 dyoung-zzzz: ping? Jun 27 14:51:50 I wouldn't mind, if the bot is on a very stable host. Jun 27 14:54:32 gernika_x, Hi. Jun 27 14:54:45 hi dyoung Jun 27 14:55:20 gernika_x: I own this channel, and hereby grant permission to log Jun 27 14:55:39 ok. sounds good. Jun 27 14:55:43 rwhitby, Thanks. Jun 27 14:55:49 gernika_x: thx Jun 27 14:56:04 I have approved the request. Jun 27 14:56:06 gernika_x: we will be sure to pass along a donation for your efforts. Jun 27 14:56:26 much appreciated, rwhitby Jun 27 14:56:42 the pleasure is all ours :-) Jun 27 14:57:36 gernika_x: if you ever need to contact anyone in this channel, those with the "nslu2-linux" project cloak are authorised to speak on behalf of the project. Jun 27 14:58:05 ok, that's good to know. Thanks. Jun 27 15:06:47 gernika_x, Can we ask the existing loglibrarybot to join this channel? Jun 27 15:14:26 Hi. Has anyone looked into using pkg-config or a workalike for cross builds? Jun 27 15:16:34 dyoung-zzzz, I'd like to avoid that if at all possible. Since loglibrarybot has to log many channels, if something goes wrong in one, it causes everyone else to suffer, so I'd like to avoid making it log more channels. Jun 27 15:27:59 What kind of bot is used? Jun 27 15:45:34 <[g2]-away> NAiL, read loglibray :) it's a python bot :) Jun 27 15:45:52 [g2]-away: figured that out after a while :) Jun 27 15:46:14 I just started wondering if it could be integrated with the changeset thingy in some way Jun 27 15:47:56 <[g2]-away> gernika_x, how much memory does loglibrary use ? Jun 27 15:54:29 * NAiL waves goodbye to his gentoo dev-box and boots with a debian install-cd Jun 27 16:13:00 rwhitby-web: I'd like to set up my dev-box to match nudi as much as possible. Anything in particular I need to do? Jun 27 16:15:11 Debian Etch Jun 27 16:16:09 then install the stuff in the Debian instructions at http://www.nslu2-linux.org/wiki/OpenEmbedded/RequiredSoftware Jun 27 16:16:18 then you will have the same dev environment as I do. Jun 27 16:16:36 (and nudi is very close to that too - it's running Sarge) Jun 27 16:16:43 ok :) Jun 27 16:16:50 but you need Etch to get the latest monotone Jun 27 17:12:43 cool. The box is up, and I'm running remote x-sessions. /me likes. Jun 27 18:52:05 hmm.. how do I add a user when installing an ipkg? adduser automatically asks for passwd, so I can't script it... Jun 27 18:55:33 NAiL: I don't think that will work in general. adduser (at least the tinylogin variety) won't necessarily add the user in the correct place (e.g. consider a system which uses NIS or openldap). Still, the full adduser (Debian) has --disabled-password. Jun 27 18:57:21 I need to add a user (ie. ntpd), so that openntpd works properly Jun 27 18:58:02 s/properly/"at all"/ Jun 27 19:02:08 Presumably the user has to have write access to files owned by the user (i.e. the user creates and updates files). Jun 27 19:02:45 It's possible something like an ftpd package already does this. Jun 27 19:03:00 It's also possible to modify the base /etc/passwd to included ntpd. Jun 27 19:03:19 ah, no. It doesn't need write access to anything actually. It's just for privilege separation/chroot-stuff. But you can't disable that.. Jun 27 19:03:32 I considered the last option. It'd make it a *lot* easier ;D Jun 27 19:03:34 Oh, then just run as nobody... Jun 27 19:03:53 hmm... Jun 27 19:04:17 Why didn't I think of nobody? It's obvious as... Jun 27 19:06:58 Nah, nobody would think of that :) Jun 27 19:07:31 daemon is the other candidate, but I think daemon may have some priveleges. Jun 27 19:09:00 yeah, nobody'll work fine Jun 27 19:09:42 openntpd requires an empty dir to chroot into, that is owned by the user it switches to. Jun 27 19:10:19 That took me some time to figure out, because there's no docs and the error message is not helpful :) Jun 27 19:11:12 Fortunately, openntpd is ported by a very pleasant person who was more than willing to answer any questions. Jun 27 19:15:55 <[g2]> NAiL, nice update on the dev_inst.sh script Jun 27 19:16:11 That has to be created in the postinst step too then. Jun 27 19:18:21 [g2]: dev_inst.sh? Jun 27 19:18:34 aah Jun 27 19:18:34 <[g2]> http://www.nslu2-linux.org/wiki/HowTo/OpenSlugDevInst Jun 27 19:18:45 I was thinking monotone Jun 27 19:18:48 ;) Jun 27 19:18:57 <[g2]> monotone on the brain Jun 27 19:19:12 Been working a bit with mt lately, you see ;) Jun 27 19:19:15 can we put that script into a file in a repo somewhere? Jun 27 19:19:38 rwhitby-web: The script is planned for obsoletion Jun 27 19:19:41 <[g2]> rwhitby-web, I"m testing with the latest from bk and the linux headers generated by OE Jun 27 19:20:07 NAiL: what's going to replace it? Jun 27 19:20:12 <[g2]> if it works then we can put the proper script in there Jun 27 19:20:51 [g2]: ah, ok. cool. Jun 27 19:22:06 * rwhitby-web would just put it in the repo even if it's not working, and hope someone else fixes it ... Jun 27 19:22:29 It's working, afaik Jun 27 19:23:00 I'd make a neat ipkg that pulled all the tools as deps :-D Jun 27 19:23:27 NAiL: that's an even better idea. Jun 27 19:23:34 and do the fixup stuff in the postinst. Jun 27 19:24:01 there's not much fixup to do, except head -n 1 the two .so files, iirc Jun 27 19:24:23 but that will (afaik) be unneccessary when the next glibc rev is installed? Jun 27 19:24:44 <[g2]> 2.3.5 built with the latest pull Jun 27 19:24:53 <[g2]> at least the native side Jun 27 19:25:03 <[g2]> s/native/development host/ Jun 27 19:25:21 <[g2]> I didn't wipe tmp can see the target build Jun 27 19:25:32 <[g2]> and strace was broken again Jun 27 19:27:49 hey dyoung-web Jun 27 19:28:01 morning. Jun 27 19:28:03 I got a chance to talk to graydon on #monotone. Jun 27 19:28:16 Oh cool, productive? Jun 27 19:28:17 http://www.loglibrary.com/show_page/latest/106 Jun 27 19:28:26 but he had to leave before we got to a conclusion Jun 27 19:28:41 if you see him, you could pick it up where I left it. Jun 27 19:29:07 <[g2]> since it's a pythong script that'll run on a FAT slug Jun 27 19:29:10 jbowler-away: is over there too now :-) Jun 27 19:29:57 What concerns me at the moment is that a perfectly innocent dev action with a branch commit can totally destroy the database... Jun 27 19:30:33 For example if I makes some changes, then do mt --db=jbowler.db --branch=org.openembdded.nslu2-linux commit Jun 27 19:30:41 (Deliberate spelling error) Jun 27 19:31:10 At that point if I don't realise and sync no one will be able to pull from anywhere... Jun 27 19:31:32 [g2] yeah. Jun 27 19:31:36 <[g2]> jbowler-away, is that what happened earlier ? Jun 27 19:31:57 That's a variant of what happens to the OE database - and it's still in that state. Jun 27 19:32:12 <[g2]> dyoung-web, yeah what :) strace is broken again or something else Jun 27 19:32:14 That's why (I believe) OE now exports 'org', not 'org.openembedded'. Jun 27 19:32:34 [g2] yeah, except I dont have a fatslug yet. Jun 27 19:33:03 <[g2]> any luck with your toy budget :) Jun 27 19:34:03 jbowler-away: we can put access control on the branches in the .monotonerc file on the server Jun 27 19:34:07 <[g2]> dyoung-web, or are you just getting back on my ping earlier today Jun 27 19:34:35 rwhitby-web: I don't think that will work Jun 27 19:35:00 jbowler-away: why not? you can prevent write access to anything other than the official branches Jun 27 19:35:06 I don't know but I think my failure case happens because the new (typo) branch cannot be written. Jun 27 19:35:37 jbowler-away: the current oe repo failure is a combination of two things: Jun 27 19:36:10 1) we committed to org.nslu2-linux.* and they pulled from us when they weren't serving org.nslu2-linux Jun 27 19:36:17 2) I replaced my public key Jun 27 19:36:27 #1 caused the missing manifests Jun 27 19:36:31 #2 caused the sig errors Jun 27 19:36:53 Yes, I had hoped that (2) caused (1), but I think (1) happens without (2). Jun 27 19:36:53 aaaa Jun 27 19:37:07 I expect they will go back to only serving org.openembedded.* when they create the official db Jun 27 19:37:25 yes #1 happened well before #2 Jun 27 19:37:40 #1 happened well before # Jun 27 19:37:42 #2 Jun 27 19:38:09 Before I went ahead with #2, I made sure that they were going to recreate the repo from scratch on July 1 from bk Jun 27 19:38:13 re Jun 27 19:38:27 if they were not going to do that, then I would have had to give up the old id and use a new id Jun 27 19:38:28 Hum, ok, one of my tests just seemed to disprove what I thought - I have oe.db exporting org.openembedded and I can pull and get the branches. Jun 27 19:39:11 yes, but what you pull will be missing revisions which were originally committed on the branches which are not being served. Jun 27 19:39:28 Ok, that's because you fixed up the nslu2 db so that none of the branch org.nslu2-linux.openembedded appears in org.openembedded.nslu2-linux. Jun 27 19:40:07 and you won't be able to see that on the server (or the viewmtn running off the server db), you will only see the missing revisions on the client which pulls and only gets half the branches. Jun 27 19:40:09 That's testable, I'll run a db check on my new db. Jun 27 19:40:39 Here's a scenario which is still working: Jun 27 19:41:09 1) User with write access creates a branch (by commit of org.openembedded.nslu2-linux) called (say) com.kalmiopsis.openembedded. Jun 27 19:41:18 User does work on this branch (it's entirely local) Jun 27 19:41:41 yep Jun 27 19:41:57 3) User decides work is globally useful and (in haste maybe) does mt propagate com.kalmiopsis.openembedded org.openembedded.nslu2-linux Jun 27 19:42:04 4) User does a sync to mtn.nslu2-linux.org Jun 27 19:42:28 Doesn't that leave org.openembedded.nslu2-linux with missing revisions? Jun 27 19:43:38 It's a likely scenario because someone who needs a branch needs a globally unique name, and if they don't feel like asking for one which is a sub-branch of org.openembedded.nslu2-linux they will end up in this situation (up to step (2)) Jun 27 19:44:24 (My new db has 16 unreferenced manifests) Jun 27 19:45:53 so that is a valid scenario, and yes that will leave org.openembedded.nslu2-linux with missing revisions. But because the server wasn't serving com.*, then it should accept revisions on com.*, nor should it accept descendants of revisions on com.*, so the server should end up unchanged. Jun 27 19:46:20 if you try and push again, it will look like it goes, but it just ignores that stuff again Jun 27 19:46:37 In other words the propagate and push seem to work fine, but the server hasn't changed. Jun 27 19:47:00 however, if the admin of that server *pulls* from your repo, then they will get those revs, but not serve them. that is the error condition which we have with #oe right now Jun 27 19:47:18 exactly Jun 27 19:47:44 This sucks. A user creates a branch and then they are effectively locked out, and it's very difficult to work out what is going on. Jun 27 19:48:29 An expert could probably fix it by recursively adding branch certificates to all the revisions... Jun 27 19:48:31 well that's my theory on what has happened anyway. it would be good if you could prove or disprove that theory somehow Jun 27 19:48:54 Yes. I think I can. Jun 27 19:49:23 I'll try and get a really simple three file example. Jun 27 19:49:42 yeah, then we can discuss it with the #monotone guys too Jun 27 19:50:26 in any case, the netsync protocol should complain when it is pushing stuff which is not being accepted Jun 27 19:50:44 Yes, and double --debug (server and client) shows nothing that I can see. Jun 27 19:51:10 Difficult to know though with the full OE tree (2000 lines of debug from one sync!) **** BEGIN LOGGING AT Mon Jun 27 20:57:45 2005 Jun 27 21:00:09 ka6sox-office: ping? Jun 27 21:02:04 <[g2]> nite all Jun 27 21:03:34 uh, NAiL, ka6sox is gone for a few weeks Jun 27 21:03:45 oh... that bad... :P Jun 27 21:04:44 ok, than I'll retire as well Jun 27 23:10:29 re Jun 27 23:10:41 jbowler: had network problems and got cut off mid-conversation with you Jun 27 23:15:20 jbowler-away: ping? Jun 27 23:16:57 pong Jun 27 23:17:11 Yes, did you push cron? Jun 27 23:18:31 Propagate it? Not yet: does it seem to work? Jun 27 23:20:31 yep, works here Jun 27 23:21:00 Ok, propagating into the main branch Jun 27 23:24:57 Ok, synced (testing == main branch and vice versa). I get a warning about the rwhitby key(s). Jun 27 23:27:05 monotone: branch 'org.openembedded.nslu2-linux' is currently merged: Jun 27 23:27:05 b427f8853818237e0b04cedd18f9256e47064135 jbowler@nslu2-linux.org 2005-06-28T06:21:43 Jun 27 23:28:00 but the changes aren't in my new repo... Jun 27 23:28:24 duh Jun 27 23:28:28 now they are ;) Jun 27 23:28:37 That's the right head. Jun 27 23:28:54 Yeah, woke up a few minutes ago. Forgot mt update Jun 27 23:29:10 Ah, good morning! Jun 27 23:29:25 Going back to sleep again though. Probably awakened by the build failing ;-) Jun 27 23:32:20 hmm.. last time it was executable. Now it wasn't. Jun 27 23:32:54 This time it failed with "permission failed" or something. chmod +x fixed that Jun 27 23:33:42 install-sh ? Jun 27 23:34:03 yeah Jun 27 23:36:01 It always was executable in my tree, but in a new tree it isn't. Jun 27 23:36:34 It's dropping the file attributes in the propagate. Jun 27 23:37:34 Maybe it never keeps them. Jun 27 23:38:33 No, it does for some files. Jun 27 23:40:44 That's .. nice. Jun 27 23:40:51 Predictability is good :-P Jun 27 23:41:23 According to the manual the attributes have to be set explicitly in a .mt-attrs file... Jun 27 23:42:05 you gotta be kidding me? Jun 27 23:43:20 And the 'execute' is there, in my copy. Jun 27 23:44:04 Blurgh, I didn't commit it because I did 'commit .' in the packages/cron directory! Jun 27 23:44:12 haha Jun 27 23:44:24 I was just about to ask if that was committed ;) Jun 27 23:45:02 Where's the .mt-attrs located? Jun 27 23:45:10 The top level directory!!! Jun 27 23:45:18 yeah, found it Jun 27 23:45:31 sync/update: 54165f3460e4f291a2bda5d72a0c9ee0808c9b7f Jun 27 23:46:20 And that will actually change the cron install-sh (on the update) Jun 27 23:46:34 got it Jun 27 23:47:21 removing cron and rebuilding Jun 27 23:47:47 Sigh. Looks like there are lots of cases where something fool-proof with bk is far from fool-proof with monotone. Jun 27 23:47:57 NOTE: package cron-3.0pl1: completed Jun 27 23:47:57 NOTE: build 200506280846: completed Jun 27 23:48:20 One thing about not using autotools, the package build is PDQ Jun 27 23:48:39 PDQ? Jun 27 23:48:52 Pretty Damn Quick Jun 27 23:48:58 aah Jun 27 23:52:15 * NAiL goes back to sleep Jun 27 23:52:33 g'nite **** ENDING LOGGING AT Mon Jun 27 23:59:56 2005