**** BEGIN LOGGING AT Sat Sep 02 02:59:56 2006 Sep 02 08:18:25 NAiL: ping? Sep 02 08:18:33 one more patch for slugos tree Sep 02 08:18:49 OpenNTPD .bb file isn't quite correct Sep 02 08:19:13 It has a dependency on OpenSSL, which isn't taken into account by the DEPENDS Sep 02 08:19:51 However, I reckon the best way to fix that is to configure OpenNTPD with its own crypto, bypassing the need for OpenSSL (that is how I am fixing it here) Sep 02 08:20:46 To do that, add '--with-builtin-arc4random --without-ssl-dir' to the end of the configure flags Sep 02 08:21:35 Thus, no external SSL library requirement, though with a marginally heavier executable Sep 02 08:22:26 I need to pass the patch upstream too, but they're not as friendly at #oe :) Sep 02 08:22:34 cya Sep 02 09:09:57 More breakage, unfortunately Sep 02 09:10:15 nfs-utils-1.0.6 fails to compile under uclibc Sep 02 09:10:31 http://pastebin.com/781879 Sep 02 09:56:18 Two solutions - Busybox 1.2 versions provide nfs-utils replacement (though included 1.0 does not) OR fix the underlying issue Sep 02 09:56:40 I'm trying to build nfs-utils-1.0.10 for now Sep 02 11:23:45 hopefully solved this problem with a little help from #oe :) Sep 02 11:25:23 Removing the unsupported call in the source code if uclibc is the c library seems to work fine, according to Gentoo and OpenWRT Sep 02 11:27:09 Patch here: http://dev.gentoo.org/~solar/uclibc/nfs-utils-1.0.6-uclibc.patch Sep 02 11:28:01 suggest including it in SlugOS SVN as it doesn't affect glibc builds and without it, uclibc compile fails Sep 02 11:54:49 OK, my little monologue here today is summarised in these two OE bugs: Sep 02 11:54:54 http://bugs.openembedded.org/show_bug.cgi?id=1377 Sep 02 11:54:56 http://bugs.openembedded.org/show_bug.cgi?id=1378 Sep 02 11:55:32 I'd recommend adding both changesets to the SlugOS SVN, as both have now made their way into HEAD Sep 02 11:55:58 Next step, file a bug for the HEAD breakage of uClibc builds Sep 02 11:57:08 openntpd builds on slugos-ltu without your fix? Sep 02 11:57:37 nfs-utils does not though... Sep 02 11:58:25 * NAiL is syncing the last part of the 3.10-beta feeds, all of which now build successfully Sep 02 11:59:07 NAiL: It does, but only if coincidentally, crypto support has already been built Sep 02 11:59:32 which, it usually has, but not if openntpd is added to rdepends in local.conf, as I did Sep 02 11:59:52 http://packages.debian.org/stable/net/openntpd Sep 02 12:00:03 it depends on libssl, by default Sep 02 12:00:41 to get around that, build the little bit of crypto that it needs straight into the executable Sep 02 12:02:01 I prefer depending on libssl, since libssl is usually present in most situations and is well-tested Sep 02 12:02:26 perhaps, but the fix now in head works the other way :) Sep 02 12:02:34 I know Sep 02 12:02:46 you can always change HEAD back Sep 02 12:02:53 That's why koen should've asked the openntpd MAINTAINER :-P Sep 02 12:04:05 libssl isn't built always, actually Sep 02 12:05:34 My ucslugc build saves lots of space by managing not to include it Sep 02 12:06:27 dropbear uses its own crypto, and nothing else needs it in the default package list Sep 02 12:08:11 until you install something common like openssh, openvpn, python, ssmtp, vsftp, wpa-supplicant, tcpdump, mutt, nail, links, hostap, git, cups, cyrus-sasl, bind, centericq, apache, asterisk, ctorrent, ctrlproxy, just to mention a few. Sep 02 12:10:00 none of which are in the default package list in the image :) Sep 02 12:10:13 I'll test my version and report back to tell you how it works Sep 02 12:10:30 is openntpd in the default image? Sep 02 12:11:12 no, but it would probably be a useful addition to the default install Sep 02 12:11:45 Now that the tickadj stuff is gone and the clock is semi-precise, ntp isn't cruical Sep 02 12:11:48 crucial Sep 02 12:12:37 especially for uclibc, which aims to be as tiny as humanely possible Sep 02 12:13:08 but time is always crucia (logs)l and it is only 50.3KB Sep 02 12:13:15 but that's just my opinion Sep 02 12:13:31 exactly Sep 02 12:13:36 some people don't care much about time Sep 02 12:13:40 and pulling in ~1MB of libraries for a 50KB executable seems a little strange, for me Sep 02 12:14:08 I'll test and get back, seems easiest solution Sep 02 12:14:22 yeah Sep 02 12:19:02 blaster8: ok, the size issue wins Sep 02 12:20:19 03nail 07slugos-3.10-beta * r341 10slugos/openembedded/packages/openntpd/openntpd_3.7p1.bb: openntpd: Use built-in crypto instead of openssl which might not have been built Sep 02 12:22:26 03nail 07slugos-3.10-beta * r342 10slugos/openembedded/packages/nfs-utils/ (files/nfs-utils-1.0.6-uclibc.patch nfs-utils_1.0.6.bb): nfs-utils: fix uclibc breakage, remove dependency on kernel module (can be built-in). Sep 02 12:23:39 03nail 07slugos-3.10-beta * r343 10slugos/openembedded/packages/meta/slugos-packages.bb: slugos-packages: Re-add nfs-utils to ucslugc feed Sep 02 12:23:45 blaster8: thanks for the work :) Sep 02 12:25:45 as I say, my next unrealistic goal is to sort out (or at least document) ucslugc breakage in HEAD ;) Sep 02 12:38:04 * NAiL closes bug #12 Sep 02 12:38:17 all slugos feeds have been successfully rebuilt and cleaned Sep 02 12:45:54 anyone building slugos on x86_64? Sep 02 12:56:48 03nail 07slugos-3.10-beta * r344 10slugos/openembedded/packages/meta/slugos-packages.bb: slugos-packages: cleanup in package lists Sep 02 13:51:26 03nail 07slugos-3.10-beta * r345 10slugos/openembedded/packages/zd1211/ (12 files in 5 dirs): zd1211: Add svn rev 83, remove deprecated revisions Sep 02 13:51:37 blaster8: you wouldn't happen to build on x86_64, would you? :) Sep 02 13:56:31 absolutely not :) Sep 02 13:56:44 I'm running on Gentoo Pentium 4 Sep 02 13:57:55 dang :P Sep 02 13:58:06 The only oddity is that my system GCC is 'hardened' Sep 02 13:58:15 Getting the weirdest error when building on ubuntu x86_64: https://trac.nslu2-linux.org/slugos/ticket/17 Sep 02 13:58:19 i.e. SSP protection enabled Sep 02 13:58:50 There is something odd about bitbake Sep 02 14:00:20 well, something isn't 64-bit safe, then Sep 02 14:00:38 apparently not Sep 02 14:00:46 but I can't figure out what causes it to fail either Sep 02 14:02:13 log_check seems a prime target Sep 02 14:03:19 have you seen the source? That's fun... :-P http://pastebin.ca/158941 Sep 02 14:03:34 It somehow magically fails on line 16 Sep 02 14:03:53 the test is true, even if the keyword isn't there Sep 02 14:03:59 but *only* on x86_64 ... Sep 02 14:04:02 my eyes hurt Sep 02 14:05:38 well, debugging-wise Sep 02 14:06:01 hmm Sep 02 14:06:05 one option is that ubuntu has managed to package an obscurely broken grep Sep 02 14:06:13 pepijn: I was gonna ask you something, but of course I forgot :-P Sep 02 14:06:36 blaster8: well, I tried grepping manually and got the result I expected Sep 02 14:06:41 damn Sep 02 14:06:45 NAiL: then just ask when you do remember (and /me is around) ;) Sep 02 14:06:51 aha... HP Sep 02 14:07:02 hi all. is it possible that if my nsul2-hdd got full (had some beeping the last days), then i cant access the nslu2 at all anymore? it cant be found in the network, even after restart. Sep 02 14:07:29 yes :) Sep 02 14:07:37 pepijn: doesn't the correct backend get installed? Sep 02 14:07:59 huh? Sep 02 14:08:04 balster: i hope you dont mean my question as a yes :( Sep 02 14:08:52 sorry, I think I do Sep 02 14:09:22 blaster: aargh, my fault.. what can i do now? is there a solution (faq online or something) ? Sep 02 14:09:24 pepijn: I'm assuming you're pepijnonline? Sep 02 14:09:47 Wipmac: what's the hard drive formatted as? Sep 02 14:10:20 i am playing with ejabberd based irc chat Sep 02 14:10:27 blaster: not fat, this linux standard Sep 02 14:10:36 ext3 Sep 02 14:10:43 or 2 ..dont remember Sep 02 14:10:50 right, do you have a linux computer to hand (if no, don't worry) Sep 02 14:10:59 :) osx Sep 02 14:11:04 yay Sep 02 14:11:23 http://sourceforge.net/projects/ext2fsx/ Sep 02 14:11:26 is your friend Sep 02 14:11:27 i could boot knoppix if os aint a go Sep 02 14:11:42 * pepijn is just 'pepijn' Sep 02 14:11:59 *is the split personality of 'pepijn'* Sep 02 14:12:06 not use who pepijnonline is Sep 02 14:12:14 s/use/sure/ Sep 02 14:12:15 pepijn meant: not sure who pepijnonline is Sep 02 14:12:20 blaster: under xp its a nogo? Sep 02 14:12:37 pepijn: ok, so you don't have a HP PSC 1410? Sep 02 14:12:54 Wipmac: http://www.fs-driver.org/index.html Sep 02 14:13:02 I said yay because I run OS X too Sep 02 14:13:35 i see :) on an intel cpu i suppose? me too Sep 02 14:13:43 NAiL: nope Sep 02 14:13:46 no, ppc Sep 02 14:13:46 not me Sep 02 14:13:58 No random shutdown mooing Macbook for me Sep 02 14:14:05 lol Sep 02 14:14:07 until Rev C, that is Sep 02 14:14:16 youre right Sep 02 14:14:18 12" PB Aluminium Sep 02 14:14:22 Rev C Sep 02 14:14:40 droppable, and fully disassembled twice to fix things Sep 02 14:14:46 heh Sep 02 14:14:51 and slightly bent Sep 02 14:14:55 and a few extra screws Sep 02 14:14:55 pepijn: does powertech still exist? ;) Sep 02 14:14:59 lol. Sep 02 14:15:12 so after i have access to that usb-ext2 drive .. what do i do? Sep 02 14:15:18 oh yes, and providing great service to my company Sep 02 14:15:19 backup anything important Sep 02 14:15:23 delete some thinbgs? Sep 02 14:15:24 remove a few big files Sep 02 14:15:30 try booting again Sep 02 14:16:13 so if i boot without hdd at all i should also have acces to the nslu2 again i suppos Sep 02 14:16:36 yes, though it will probably beep disapprovingly at you Sep 02 14:17:22 :) if someone buys a neat NAS-Device today, what would he buy? still an nslu2!? Sep 02 14:17:38 I'm planning to buy a thecus n2100 Sep 02 14:17:48 expensive, but it's a way more powerful device ;-) Sep 02 14:18:06 Wipmac: If he wanted to run custom linux, NSLU2 is still best supported Sep 02 14:18:11 (2xgblan, 600mhz iop cpu, DDR-slot, s-ata, two internal drives) Sep 02 14:18:25 nail: wow - but lota $ Sep 02 14:18:42 yeah Sep 02 14:18:52 also a minipci slot Sep 02 14:18:52 I've finally mounted my megaslug, after about a year off the project Sep 02 14:19:10 been away for some time - didnt even know there is a megaslug out Sep 02 14:19:17 joke ;) Sep 02 14:19:20 lol Sep 02 14:19:23 got me Sep 02 14:19:29 I'm building an integrated backup thingy Sep 02 14:19:58 NSLU2 running of internal flash, with Microdrive for swap and logs Sep 02 14:20:25 then USB 400GB Hard Drive which can be powered on and off from the command line Sep 02 14:20:47 the power lines are sent through a relay which is software controlled Sep 02 14:21:04 hmm, can we all power the hdd of the slug up/down!? Sep 02 14:21:07 and an 20x2 LCD on the front, and custom LEDs for status Sep 02 14:21:13 not easily Wipmac Sep 02 14:21:27 blaster:your project sounds nice Sep 02 14:21:31 similar reasons to why you can't flash firmware easily in a USB Case Sep 02 14:21:39 it's hard work Sep 02 14:22:17 basically the USB to ATA chipsets do not emulate all of the scsi instructions that they could Sep 02 14:22:36 03bzhou * r3998 10optware/trunk/make/dcraw.mk: dcraw: upstream upgrade to 1.344 Sep 02 14:23:00 so they do not necessarily emulate those required for spindown controlled by the OS Sep 02 14:23:24 my version is better, because the USB-ATA bridge is powered down too, which means it is less likely to burn out :) Sep 02 14:23:25 yep. there has been some talk back in the days where ppl wanted to spin their harddrives up/down so they spin only when they need it. guess theres no solution to this yet, as long as the hdd itself hasnt that thing built in.. even though all our hdd's support smart these days. but guess its the reason u say..the usb2ata chipset Sep 02 14:24:04 i wouldnt care if my usb-ata bridge would burn down :) Sep 02 14:24:17 HD spin down is a mixed blessing anyway Sep 02 14:24:47 the spin-up spin-down cycle is much more wearing than running the HD all the time spun up, under most circumstances Sep 02 14:24:52 I won't use spindown on my thecus... Can't be bothered waiting for it to spin up :P Sep 02 14:25:01 true nail Sep 02 14:25:06 and, as NAiL points out it takes time Sep 02 14:25:36 the main positive is heat production and general power saving, but thinking that you're lengthening the life of the drive is probably not sensible Sep 02 14:25:36 but going out of your house and joping it wont burn down, cuz your 5400 rpm samsung is gettin too hot is also no good solution... ;) Sep 02 14:26:10 blaster8: the power savings aren't that great, unless you leave it spun down for extended periods of time Sep 02 14:26:37 the spinup load is equivalent to a fair bit of spinning time Sep 02 14:26:48 well, my backup drive will come online once a day, which is probably enough Sep 02 14:27:15 yeah, that'll save power Sep 02 14:27:35 but for a disk that is in use semi-regularly during a day, leaving it spinning is the better option Sep 02 14:27:59 are there nas-devices allowing that spinup/down thingy? Sep 02 14:28:37 most (if not all) of the devices with internal IDE/S-ATA disks probably support it Sep 02 14:28:55 because you can use hdparm to talk to the hard disk, which is more reliable Sep 02 14:29:00 ah, remember - the usb2ata was the problem Sep 02 14:29:00 and can be set at each boot Sep 02 14:29:00 like the thecus n2100, nas100d, ds101*, dsm600g etc. Sep 02 14:29:23 but then the NSLU2 is much cheaper and smaller Sep 02 14:29:51 so whats the next best thing to the nslu2 - also $-wise Sep 02 14:29:54 but also requires external disks, which makes my room a cable mess :-P Sep 02 14:30:39 not if you spend about a week carefully putting it into a custom box :rollseyes: Sep 02 14:30:46 haha Sep 02 14:30:47 no Sep 02 14:30:59 wow Sep 02 14:31:02 * NAiL got a sick idea Sep 02 14:31:58 btw, you really need to step through that failing script on a 32 bit (working) box and your Ubuntu box, with the correct environment setup (just in case) to find out what the heck is going on Sep 02 14:32:10 hahaha Sep 02 14:32:30 the slug (and the 2.5" disks I have) all fit in a DVD case. Sep 02 14:33:12 How's that for a custom case? :-P Sep 02 14:33:40 it'd be neat ;) Sep 02 14:34:28 i got something like unslung 4.x i guess..would it be worth updating to 6.x? Sep 02 14:34:56 3.x ! Sep 02 14:35:12 yes Sep 02 14:35:20 but it is less of an upgrade and more of a reinstall Sep 02 14:35:30 which is probably what you need anyway :p Sep 02 14:35:43 grrr ;) Sep 02 14:35:46 after you've backed up your files, of course Sep 02 14:36:12 make sure you upgrade using something like redboot upgrade mode rather than any functionality built into unslung Sep 02 14:36:19 it's for the best, honestly Sep 02 14:36:21 well - but i use the nslu2 as a backup drive - so i dont wanna backup the backup now.. Sep 02 14:36:44 well, if there's nothing to backup, then go right ahead Sep 02 14:37:11 you mean backuping linux things running on the nslu2? ipkg's etc.. nah, i gave up on that .. Sep 02 14:37:16 do you have any windows machines, or only OS X Sep 02 14:37:21 xp and osx Sep 02 14:37:35 OK, follow these instructions: Sep 02 14:37:35 http://www.nslu2-linux.org/wiki/HowTo/RecoverFromABadFlash Sep 02 14:38:01 Flash Unslung 6.8: http://www.slug-firmware.net/u-dls.php Sep 02 14:38:19 or openslug? :) Sep 02 14:38:34 but thats a completely differnt thing right..hmm Sep 02 14:38:41 unless you know what you're doing Sep 02 14:38:49 I'd use unslung, it's well maintained Sep 02 14:38:49 :) yep Sep 02 14:38:55 so ibetter NOT do it.. Sep 02 14:39:33 and make sure you read the README and http://www.nslu2-linux.org/wiki/Unslung/WhichUSBPortforUnslung6 Sep 02 14:39:35 blaster: so u think my nslu2 wont boot nomore, even if i delete some large file(S) on its hdd.. ? Sep 02 14:39:45 i c..ok! Sep 02 14:40:39 why should i want 6.8 anyway if i have 3.x? Sep 02 14:40:57 usb hub support, ntfs support... Sep 02 14:40:59 if you need that Sep 02 14:40:59 because Unslung 6.8 is more up-to-date Sep 02 14:41:11 whether that is good or bad is another matter Sep 02 14:41:33 personally I am always attracted to shiny new versions of software Sep 02 14:41:45 well - i wonder what it would change for me.. is it faster with data transmission on the lan? Sep 02 14:41:46 but that is not always sensible Sep 02 14:41:54 probably not Sep 02 14:42:19 me normally too - but in case of such a sensitive girl like the nslu2 - where i can destroy a lotta things i tend to better not install things too often . Sep 02 14:42:19 it's upgrade mechanism isn't broken, and it is based on the latest Linksys firmware Sep 02 14:42:22 and the clock works Sep 02 14:42:48 I'd recommend a fresh install of 6.8, with the procedure above Sep 02 14:42:56 then don't fill up the hard drive again Sep 02 14:43:07 ok .. i will consider that . first i will boot knoppix on my laptop an connect the hdd and see if nslu2 boots after dleting things. ok? Sep 02 14:43:23 give it a try Sep 02 14:43:35 chances are 90:10 that it will work? Sep 02 14:43:50 don't know, in all honesty, but it probably will Sep 02 14:43:59 nice thx! bbl! Sep 02 14:51:12 03bzhou * r3999 10optware/trunk/make/py-psycopg2.mk: py-psycopg2: upstream upgrade to 2.0.5.1 Sep 02 15:14:05 damn - from the knoppix desktop all the files on the ext2 nslu2 drive are "locked" so i cant delete them.. any clues? Sep 02 15:14:20 are you root? Sep 02 15:14:28 is the filesystem mounted rw? Sep 02 15:14:54 in the terminal window i can do "su" Sep 02 15:15:11 i just plugged thusb drive - thats all -- didnt check the file sys Sep 02 15:15:19 how would i do that? Sep 02 15:15:35 su - Sep 02 15:15:44 cd to wherever the fs is mounted (see "mount") Sep 02 15:15:50 rm whatever files you wish Sep 02 15:16:20 its not mounted i guess - the path to the files is something like "/knoppix/Desktop/sda1" Sep 02 15:17:04 with "mount" there is no sda (as i rememeber) Sep 02 15:20:30 am I the first that noticed that the cyrus-sasl ipks don't install the plugins? Sep 02 15:21:32 the cyrus-sasl ipk installs saslauthd and the cyrus-sasl-libs contains files that belongs into a cyrus-sasl-devel package Sep 02 15:21:48 no .so files Sep 02 15:32:03 hi Sep 02 15:39:03 hi Sep 02 15:43:41 do you have a postfix binary for me, witch runs on a ds1o1? :) Sep 02 15:44:16 no, I have no ds101 so I don't have a toolchain for it Sep 02 15:47:12 samsn: "ipkg install postfix" .... Sep 02 15:47:27 samsn: please try to read up a bit on the wiki Sep 02 15:48:36 and, if you're going to ask end-user questions, please read the topic... Sep 02 15:51:31 ah sorry.. Sep 02 16:36:25 03bzhou * r4000 10optware/trunk/make/imagemagick.mk: imagemagick: upgrade to 6.2.9-3, some cleanup Sep 02 17:08:01 * NAiL attempts to upgrade samba Sep 02 17:38:32 03bzhou * r4001 10optware/trunk/make/samba.mk: samba: upstream upgrade to 3.0.23c Sep 02 17:38:36 eno: can you help me with the cyrus-sasl-ipk? Sep 02 17:38:51 configure shows always: Sep 02 17:38:53 checking dynamic linker characteristics... no Sep 02 17:38:54 checking if libtool supports shared libraries... no Sep 02 17:38:54 checking whether to build shared libraries... no Sep 02 17:39:17 gda_, i'll be back in 5 minutes Sep 02 17:39:54 I tried to set some variables, but didn't help, can you take a short look and tell me whether I shall patch the check out? Sep 02 17:39:59 I can wait Sep 02 17:45:38 03nail 07slugos-3.10-beta * r346 10slugos/openembedded/packages/samba/ (3 files in 2 dirs): samba: upstream upgrade to 3.0.23c Sep 02 17:46:06 7 minutes between optware and slugos samba upstream upgrade ;) Sep 02 17:51:34 keep nudi busy Sep 02 17:51:50 Yup, stable feeds are building now Sep 02 17:52:08 k, gda_, i can replicate the configure problem Sep 02 17:52:16 but on nslu2 it is fine Sep 02 17:52:42 on ds101g, it has problem Sep 02 17:57:03 am looking at builds/cyrus-sasl/config/ltconfig Sep 02 17:57:37 03nail 07slugos-3.10-beta * r347 10slugos/openembedded/packages/zd1211/ (10 files in 3 dirs): zd1211: Clean up duplicate files Sep 02 18:04:58 eno: yes, I have looked into it too Sep 02 18:06:30 eno: can you compare and see where is the difference between nslu2 and ds101g configuration Sep 02 18:06:32 ? Sep 02 18:09:41 gda_: see builds/cyrus-sasl/config/ltconfig line 2043 Sep 02 18:11:16 for some reason, it hardcoded linux-gnu powerpc not supporting dynamic_linker Sep 02 18:11:27 i think you need to patch that line Sep 02 18:13:10 simply delete that line Sep 02 18:14:34 it's also in builds/cyrus-sasl/saslauthd/config/ltconfig Sep 02 18:20:28 my good it is that simple, sorry for beeing stupid again, thanks eno Sep 02 18:20:39 np Sep 02 18:23:32 Just trimmed lcdproc down to a very reasonable size Sep 02 18:23:59 any1 with ds101 here? Sep 02 18:24:12 not anymore :( Sep 02 18:24:27 It's a strange package, the maintainer seems to have used some mad h4ckz to select which drivers to compile Sep 02 18:24:49 looks like imagemagick builds fine for ds101, but it is on the broken list (optware) Sep 02 18:24:55 he has a special environment variable, which if not set leads to compiling all the drivers Sep 02 18:25:08 blaster8: OE? Sep 02 18:25:12 yes Sep 02 18:25:19 that behaviour is fair enough Sep 02 18:25:29 except for the big list of runtime dependencies Sep 02 18:25:45 including libusb which in turn requires libstdc++ Sep 02 18:26:11 (though that's not actually specified in the .bb file, d'oh) Sep 02 18:27:52 so anyway, I've made a package for personal consumption only which disables usb and all drivers except for the hd44780-i2c driver Sep 02 18:28:04 thus saving more MB :) Sep 02 18:28:53 I guess the drivers should be split off into separate packages ;) Sep 02 18:29:00 well, preferably Sep 02 18:29:12 but there are a lot of drivers, so that's not exactly neat either Sep 02 18:29:18 time to bring on the USE flags :p Sep 02 18:29:43 how many drivers are there? Sep 02 18:29:49 approx? Sep 02 18:29:53 hold on Sep 02 18:30:20 ~20 I reckon Sep 02 18:30:32 but they could be grouped into maybe 6 similar sets, I reckon Sep 02 18:30:35 let me see Sep 02 18:30:37 eno: it works, of course :) have to wether my postfix problems are solved with this Sep 02 18:30:49 s/to/to see" Sep 02 18:31:18 blaster8: grouping them isn't a bad idea. It's definitely better than installing all Sep 02 18:31:25 37 (!) Sep 02 18:31:41 but a lot aren't really applicable (time for lcdproc-misc, I reckon) Sep 02 18:31:55 how are they not applicable? Sep 02 18:32:12 let's have a look Sep 02 18:33:33 03gda * r4002 10optware/trunk/ (2 files in 2 dirs): cyrus-sasl: didn't build right on ds101g Sep 02 18:34:15 Here's a plan Sep 02 18:34:26 the drivers are separate loadable objects Sep 02 18:35:14 so one possibility would be to split lcdproc Core and separate lcdproc Driver packages, which are dependent on the Core being installed Sep 02 18:35:22 harder to maintain but possibly neater Sep 02 18:35:40 not that much harder. Stuff like that is done in a lot of packages Sep 02 18:35:52 eg. samba Sep 02 18:35:55 true, but the lcdproc build isn't set out like that Sep 02 18:36:25 to do it easily we would probably have to build lcdproc twice, but install different things each time Sep 02 18:36:47 or we are into patching makefiles (yay) Sep 02 18:36:47 imho, all the drivers could be split into separate packages ;-) Sep 02 18:36:58 how about no on that one :) Sep 02 18:37:14 I reckon we can group the drivers, people can always manually delete the ones they don't want Sep 02 18:37:16 you don't need to build it twice... it's just hacking the packaging step a bit Sep 02 18:37:37 what groups do you propose? Sep 02 18:37:44 I'm working them out Sep 02 18:38:27 eg. FILES_${PN}_usbdrivers = "usbdriver1.so usbdriver2.so" Sep 02 18:39:33 DEPENDS_${PN}_usbdrivers = "${PN}" Sep 02 18:41:07 FILES_${PN}_hd47780 ;) Sep 02 18:45:30 10 groups Sep 02 18:45:46 and then an 'all' package as well Sep 02 18:45:48 just in case Sep 02 18:46:06 no problem Sep 02 18:46:13 I'll pastebin Sep 02 18:46:18 cool Sep 02 18:46:51 http://pastebin.ca/159152 Sep 02 18:47:30 the names to the right need to be added after --enable-drivers= Sep 02 18:47:41 then the driver names separated by commas Sep 02 18:48:14 finally --disable-libusb should be added for all except hd44780usb Sep 02 18:48:56 then of course, the hd44780usb package has an rdepends for libusb Sep 02 18:56:45 http://pastebin.ca/159156 Sep 02 18:58:17 now, I don't know how to make the driver .bb files without simply using the same bb file again and using install for different files from the build Sep 02 18:58:44 though this means that lcdproc is built twice in seperate work directories Sep 02 19:00:45 you need to compile lcdproc twice to get all drivers? Sep 02 19:00:49 no Sep 02 19:01:25 but I don't know how to use one work folder for multiple packages Sep 02 19:01:31 hold on Sep 02 19:01:33 aah Sep 02 19:01:45 worked it out (!) Sep 02 19:01:57 that's what FILES_ is for Sep 02 19:02:01 indeed Sep 02 19:02:09 anyway, you better do that ;) Sep 02 19:02:12 hehe Sep 02 19:03:13 let me see if I understand the pastebin stuff Sep 02 19:03:19 I'd recommend calling the driver packages lcdd-driver-$INSERTNAMEHERE Sep 02 19:03:25 ignore the second pastebin Sep 02 19:03:38 I just opened the first ;) Sep 02 19:03:58 CFontz - CFontz CFonts633 CFontzPacket <-- what are the driver filenames? Sep 02 19:04:02 better look here: http://www.openembedded.org/repo/org.openembedded.dev/packages/lcdproc/lcdproc_0.5.0.bb Sep 02 19:04:20 ok, the bit on the left is for the package name Sep 02 19:04:53 the driver filenames I don't know yet Sep 02 19:05:06 ah, ok Sep 02 19:05:15 I'll tell you in one minute Sep 02 19:06:49 What's the original package name? lcdproc or lcdd? Sep 02 19:07:00 lcdproc Sep 02 19:07:03 nm Sep 02 19:07:12 lcdd-driver-* makes sense Sep 02 19:07:13 which then creates lcdd out of part of the whole combined tree Sep 02 19:07:25 ok, nice and easy Sep 02 19:07:38 CFontz => CFontz.so Sep 02 19:07:40 etc Sep 02 19:07:44 lcdproc should install everything, lcdd and lcdd-driver-* should install selectively, right? Sep 02 19:08:05 lcdproc should require lcdd Sep 02 19:08:59 lcdd-driver-* should require lcdd Sep 02 19:09:06 yeah Sep 02 19:09:22 so.. Sep 02 19:09:24 and lcdd should perhaps be renamed to lcdd-core Sep 02 19:09:59 FILES_lccd-driver-cfontz = "/path/to/drivers/CFontz*.so" Sep 02 19:10:10 you tell me ;) Sep 02 19:10:16 one last issue presents itself Sep 02 19:10:52 we do need to build twice, as the flag to add or remove usb support is set at configure time Sep 02 19:11:04 hmm Sep 02 19:11:13 or hack makefiles (yay) Sep 02 19:11:18 could it be fixed with a patch? :) Sep 02 19:11:26 exactly Sep 02 19:12:54 FILES_lccd-driver-cfontz = "${libdir}/CFontz*.so" Sep 02 19:12:56 just build a special no-usb version of the hd44780 driver in addition to the the usual libusb-depending version Sep 02 19:12:57 to be exact :) Sep 02 19:13:17 is hd47780 the only driver with the usb/no-usb problem? Sep 02 19:13:23 unfortunately they are in server/drivers/*.so Sep 02 19:13:36 and need to go into ${libdir}/lcdproc/ Sep 02 19:13:48 install -d ${D}${libdir}/lcdproc Sep 02 19:13:48 for i in server/drivers/*.so; do Sep 02 19:13:48 install -m 0644 $i ${D}${libdir}/lcdproc/ Sep 02 19:13:48 done Sep 02 19:13:58 that's the one Sep 02 19:14:04 FILES_lccd-driver-cfontz = "${libdir}/lcdproc/CFontz*.so" Sep 02 19:14:10 Getting there :-P Sep 02 19:14:16 about the hd44780, I think so, but don't explicitly know Sep 02 19:14:22 more source reading :) Sep 02 19:16:10 IOWarrior depends on libusb (no optional extra like hd44780) Sep 02 19:17:43 as does the 'all' package (which should just put in every .so it finds) Sep 02 19:18:29 yeah Sep 02 19:18:50 but since we're splitting off the packages into groups, I see no reason not to build "all" Sep 02 19:19:04 we will build all of the drivers Sep 02 19:19:18 and we will have a package to install all of the drivers Sep 02 19:19:25 and also packages to install specific drivers Sep 02 19:19:31 that's how I see it Sep 02 19:19:49 now, for the annoying bit (Makefile hackery) Sep 02 19:21:04 http://pastebin.ca/159179 Sep 02 19:21:25 list of all the driver packages and what files they contain Sep 02 19:21:34 nearly Sep 02 19:21:43 we'll probably have to change hd44780 slightly Sep 02 19:22:15 won't having a hd47780 and hd47780-usb .so work? Sep 02 19:22:19 hd44780.so will have usb support Sep 02 19:22:34 hd44780nousb.so will not have usb support Sep 02 19:22:40 ok Sep 02 19:23:06 but hd44780nousb.so will be installed to hd44780.so inside the package Sep 02 19:23:40 and if 'all' grabs hd44780nousb.so as well, no-one is going to kill us Sep 02 19:23:55 huh? Sep 02 19:24:29 I can't parse that ;) Sep 02 19:24:39 can hd44780nousb.so be renamed to hd44780.so as it's installed? Sep 02 19:24:58 and then the two hd44780 packages 'conflict' each other Sep 02 19:25:03 pkg_postinst() { mv } Sep 02 19:25:15 fine by me Sep 02 19:25:46 so the patch we need has to be that: Sep 02 19:26:20 # USB / no USB trickery Sep 02 19:26:20 CONFLICTS_lcdd-driver-hd47780nousb = "lcdd-driver-hd47780" Sep 02 19:26:20 CONFLICTS_lcdd-driver-hd47780 = "lcdd-driver-hd47780nousb" Sep 02 19:26:52 but... Sep 02 19:26:53 Patch: when --enable-libusb is set (as it will be in our build), a second version of the hd44780 driver is built without libusb support and called hd44780nousb.so Sep 02 19:27:05 now to turn that into 'make' language (uggh( Sep 02 19:32:18 http://pastebin.ca/159186 Sep 02 19:32:25 The added stuff to lcdproc .bb Sep 02 19:33:05 03gda * r4003 10optware/trunk/ (make/postfix.mk sources/postfix/master.cf): postfix: configuration upgrade Sep 02 19:33:06 actually, the pkg_postinst stuff shouldn't be necessary Sep 02 19:33:13 (and anyways, it'd wrong ;) Sep 02 19:33:33 should've been pkg_preinst Sep 02 19:34:39 you need to remove the DEPENDS mess (and the OECONF mess) Sep 02 19:35:15 ok, I'm going to add an extra configure flag, to start with Sep 02 19:35:36 hmm Sep 02 19:35:57 RDEPENDS needs to contain libusb and (n)curses Sep 02 19:41:29 Trying to compile Sep 02 19:41:36 (hoping it'll bomb out during packaging) Sep 02 19:42:56 it doesn't need libusb to compile (knows from past experience) Sep 02 19:43:06 at least, I don't think so] Sep 02 19:44:47 hmm... Sep 02 19:44:56 there's a bunch of missing drivers with the current setup Sep 02 19:45:24 --enable-drivers=all ?? Sep 02 19:45:56 CwLnx, glk, icp_a106, imon, joy, lb216, lcdm001, lcterm, ms6931 etc aren't packaged in any packages except all Sep 02 19:46:04 'all' Sep 02 19:46:21 sounds correct Sep 02 19:46:43 a lot of those are not relevant to the nslu2 Sep 02 19:47:42 no, but OE doesn't only build for the nslu2 ;) Sep 02 19:48:33 http://lcdproc.sourceforge.net/docs/current-user-html/c396.html Sep 02 19:48:44 designed to fit in 5.25" HD bays Sep 02 19:48:53 http://lcdproc.sourceforge.net/docs/current-user-html/x1147.html Sep 02 19:48:58 used in gaming keyboards Sep 02 19:49:12 not vital to embedded devices, IMO Sep 02 19:49:22 if you want to package all of them, go ahead, though Sep 02 19:49:30 OE isn't even restricted to embedded ;-) Sep 02 19:49:47 Yeah, I'll look at packaging the rest of them later Sep 02 19:49:56 just need to get the packaging to work in general ;) Sep 02 19:57:01 getting anywhere with the makefile foo? Sep 02 19:57:27 no Sep 02 19:57:35 not for lack of trying Sep 02 19:57:49 that fact that I know nothing about makefiles isn't helping me Sep 02 19:57:53 still it's one way to learn Sep 02 19:58:03 Packaged contents of lcdd-driver-cfontz into /home/repvik/slug/releases/slugos-3.10-beta/debianslug-nslu2.tmp/deploy/ipk/lcdd-driver-cfontz_0.5.0-1_arm.ipk Sep 02 19:58:07 Packaged contents of lcdd-driver-bayrad into /home/repvik/slug/releases/slugos-3.10-beta/debianslug-nslu2.tmp/deploy/ipk/lcdd-driver-bayrad_0.5.0-1_arm.ipk Sep 02 19:58:11 yay ;-) Sep 02 19:58:34 well done Sep 02 20:07:43 OK, I don't have a damn clue how to sort this out Sep 02 20:08:54 time to make a completely new driver Sep 02 20:15:26 ok, now I've set up all the drivers to be packaged Sep 02 20:15:33 let's see if I spelled something wrong :P Sep 02 20:17:08 I will be a while, but I now have a plan Sep 02 20:19:33 ok, I think I've got it now. The only packages missing are IOWarrior and hd44780nousb Sep 02 20:21:45 iowarrior isn't build with "all" Sep 02 20:26:46 no idea why, no great loss Sep 02 20:26:57 I've committed the modified .bb to OE Sep 02 20:27:11 did you specify --enable-libusb ? Sep 02 20:27:15 the only missing part is getting the hd44780 stuff to build two packages Sep 02 20:27:34 sorting that out gradually here Sep 02 20:27:37 no, forgot that :-P Sep 02 20:28:50 there Sep 02 20:29:16 the oe server now has the updated .bb Sep 02 20:30:02 --enable-libusb is definitely necessary Sep 02 20:30:34 yeah, made a second commit Sep 02 20:38:06 03nail 07slugos-3.10-beta * r348 10slugos/openembedded/packages/meta/slugos-packages.bb: slugos-packages: Rephrase SLUGOS_PACKAGES comment to avoid misunderstandings Sep 02 20:38:24 03nail 07slugos-3.10-beta * r349 10slugos/openembedded/packages/meta/slugos-native.bb: slugos-native: Move libc6-dev to linux section, since it won't work with uclibc Sep 02 20:39:15 * NAiL is finally getting work done Sep 02 20:39:19 feels great :) Sep 02 20:47:14 03gda * r4004 10optware/trunk/ (make/amavisd-new.mk sources/amavisd-new/amavisd.conf): amavisd-new: small config file fix Sep 02 21:02:44 03nail 07slugos-3.10-beta * r350 10slugos/openembedded/packages/glibc/glibc-package.bbclass: glibc-package.bbclass: Add libc6* to PACKAGES_DYNAMIC so slugos-native will actually build Sep 02 21:16:01 ok Sep 02 21:16:03 this hacking thing is a bit beyond me Sep 02 21:16:05 there appears to be no clean way of doing it Sep 02 21:16:11 so a suggestion Sep 02 21:16:26 two lcdproc .bb files Sep 02 21:16:44 one with --disable-usb, one with --enable-usb Sep 02 21:18:40 the one with --enable-libusb only has to provide driver packages for hd44780 and IOWarrior Sep 02 21:21:16 and I would select --enable-drivers=bayrad,CFontz,CFontz633,CFontzPacket,CwLnx,glk,hd44780,icp_a106,imon,IOWarrior,joy,lb216,lcdm001,lcterm,ms6931,mtc_s16209x,MtxOrb,NoritakeVFD,pyramid,sed1330,sed1520,serialVFD,sli,stv5730,t6963,text,tyan,ula200 Sep 02 21:21:27 I'll make some bb files and get back to you Sep 02 21:24:24 03nail 07slugos-3.10-beta * r351 10slugos/openembedded/packages/glibc/glibc_2.3.5+cvs20050627.bb: glibc: Force rebuild Sep 02 21:36:49 http://pastebin.ca/159269 Sep 02 21:36:53 http://pastebin.ca/159272 Sep 02 21:37:25 basically this creates a new package - lcdproc-usb Sep 02 21:37:49 can you specifically check the last 6 lines of each .bb file Sep 02 21:38:14 why this: Sep 02 21:38:17 I have commented out part of the install that I don't think is necessary given our plan to install drivers separately - can you check? Sep 02 21:38:20 # Sep 02 21:38:20 # for i in server/drivers/*.so; do Sep 02 21:38:20 # Sep 02 21:38:20 # install -m 0644 $i ${D}${libdir}/lcdproc/ Sep 02 21:38:20 # Sep 02 21:38:23 # done Sep 02 21:38:38 #done shouldn't be commented Sep 02 21:39:13 I thought that part would lead to the drivers going into the lcdproc package Sep 02 21:39:13 if you don't install them, there's no easy way to split them into separate packages Sep 02 21:39:20 but bitbake is cleverer than I thought Sep 02 21:39:28 ignore that commenting then Sep 02 21:39:31 no, the install part comes before the packaging part :) Sep 02 21:39:39 deep breaths :) Sep 02 21:40:31 the one thing that is definitely not in place is a CONFLICT variable to stop both being installed at the same time Sep 02 21:40:51 well, you won't need that many, I guess... Sep 02 21:40:58 since there's not that many usb-drivers Sep 02 21:41:04 hmm Sep 02 21:41:16 true Sep 02 21:41:34 but it is a rather... clunky way to do it Sep 02 21:42:03 have a look at the source if you want, but it's a bit of an autotools nightmare Sep 02 21:42:39 and adding a new driver with just the hd44780 usb support will probably confuse more people as suddenly the lcdproc documentation isn't valid Sep 02 21:43:17 On this one, we have to blame lcdproc for being hard to package, I think Sep 02 21:44:58 how big is the cost of just enabling usb? Sep 02 21:45:07 huge Sep 02 21:45:12 libstdc++ is pulled in Sep 02 21:45:18 gah Sep 02 21:45:33 not great for embedded really Sep 02 21:45:38 no Sep 02 21:46:43 *man* Sep 02 21:46:53 that seriously is an autotool nightmare Sep 02 21:46:54 now, why the heck libstdc++ is pulled in is another matter Sep 02 21:47:56 hmm Sep 02 21:48:16 I think I can hack the Makefile Sep 02 21:48:18 but.. Sep 02 21:48:30 CFontz,CFontz633,CFontzPacket,hd44780,IOWarrior,text <-- text? Sep 02 21:48:41 does the text driver use USB? Sep 02 21:49:56 from the Makefile, it looks like only IOWarrior and hd44780 uses usb Sep 02 21:50:01 no Sep 02 21:50:06 but I put it there for testing Sep 02 21:50:46 technically none of the CFontz drivers use libusb either Sep 02 21:51:44 but there are CFontz displays controlled by CFontz-packet.so which have a USB interface Sep 02 21:51:57 and I didn't want to confuse people, to be honest Sep 02 21:53:51 they'll be less confused if there's only a cfonts package than a cfonts and cfontsnousb, I'd say Sep 02 21:54:04 *z Sep 02 21:54:21 agreed, go for it Sep 02 21:55:53 http://pastebin.ca/159287 Sep 02 21:56:13 I think there will only be one -nousb package... iowarrior seems to only use usb Sep 02 21:57:04 http://pastebin.ca/159288 Sep 02 21:57:19 hd44780 optionally uses usb Sep 02 21:57:36 yeah, optionally Sep 02 21:57:45 but both versions need to be built Sep 02 21:57:47 so it needs hd44780 and hd44780-nousb Sep 02 21:57:55 well, basically Sep 02 22:00:04 ok Sep 02 22:00:11 OK, look at this one Sep 02 22:00:12 http://pastebin.ca/159289 Sep 02 22:00:27 should be right, apart from the lack of the conflicts variable Sep 02 22:01:11 I'll have to look into this tomorrow if I get the time.. Bit sleepy to focus Sep 02 22:01:42 OK, shall I file a bug Sep 02 22:01:48 I don't have access to slugbug for some reason Sep 02 22:01:53 OE? Sep 02 22:01:58 slugbug doesn't work at all Sep 02 22:02:08 aah Sep 02 22:02:17 we use trac nowadays, but only developers can file bugs Sep 02 22:02:23 handy that :) Sep 02 22:02:36 send a bug-report to nslu2-linux mailinglist Sep 02 22:02:54 or to you? Sep 02 22:03:31 nah, I read the list. Sending it to the list has the added benefit of showing it to other people ;) Sep 02 22:23:41 http://bugs.openembedded.org/show_bug.cgi?id=1381 Sep 03 01:50:46 03mwester * r358 10kernel/trunk/patches/2.6.17/defconfig: Added back in the ARTOP IDE driver for the dsmg600a, as well as the via velocity driver. Sep 03 01:51:56 03mwester * r359 10kernel/trunk/patches/2.6.17/ (3 files): Added the via velocity patches and the IDE driver for the ARTOP IDE. Sep 03 02:39:08 hello there Sep 03 02:39:52 is there a know issue about openslug3.10beta and ipkg upgrade ? Sep 03 02:40:12 yesterday this destroyed my slug....Had to do a fresh install Sep 03 02:40:44 now it is working (ipkg upgrade on the fresh install work) but now NFS server is not able to start Sep 03 02:41:08 missing nfsd module....eventhough nfds-kernel-module package is installed Sep 03 02:41:16 anyone ? **** ENDING LOGGING AT Sun Sep 03 02:59:57 2006