**** BEGIN LOGGING AT Mon Dec 25 02:59:57 2006 Dec 25 14:10:28 am i the only one having trouble with nfs on Debian/NSLU2? Dec 25 15:06:48 Anyone got a slug running and accessible right now? Dec 25 15:07:35 I'd like to see if 'lspci -v|grep "Debug"' outputs anything Dec 25 15:08:29 * NAiL hopes for "Capabilities: [58] Debug port" Dec 25 15:09:29 NAiL, nothing here. Debian/NSLU2 Dec 25 15:10:36 shame Dec 25 15:11:00 it doesn't matter which os is running unfortunately Dec 25 15:11:32 If it had a debug port, one of the usb2-ports on the NSLU2 could be used for very early debugging Dec 25 15:12:49 likewise: morning ;) Dec 25 15:13:09 NAiL: good morning all :-) Dec 25 15:13:15 likewise: do you have an epia board booted? Dec 25 15:13:26 NAiL: I can, in a minute? why? Dec 25 15:13:58 I want to check if the usb-controller has the "Debug port" capability Dec 25 15:14:32 NAiL: booting. tell me what to check, I have never used that. Dec 25 15:15:04 do lspci -v|grep Debug Dec 25 15:15:27 If it has, it should show "Capabilities: [58] Debug Port" Dec 25 15:15:57 (Which basically enables one of the ports to be used as a debug port without using a full usb-stack) Dec 25 15:16:30 It can only send 8-byte packets, but that should be more than enough for me to set up my LCD display as a debug device ;) Dec 25 15:17:52 I don't envision me writing an usb-stack just to get the lcd-display working, tbh Dec 25 15:17:55 NAiL: bugger, negative. Dec 25 15:18:04 dang Dec 25 15:18:26 NAiL: the intel spec reads for EHCI (only?). Dec 25 15:18:39 possibly... Is the via ochi? Dec 25 15:18:52 NAiL: lspci -v gives me only "Capabilities: [80] Power Management version 2" Dec 25 15:19:03 0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI]) Dec 25 15:19:16 0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI]) Dec 25 15:19:30 hmm, ok, the USB2.0 one *is* EHCI Dec 25 15:21:00 still, if it doesn't have the capability, it's a lot more work Dec 25 15:28:24 oh well Dec 25 15:28:48 It doesn't take too long for it to boot far enough for me to initialize the display in userspace anyway ;) Dec 25 15:29:11 likewise: any experience with boot speed from CF btw? Dec 25 15:29:23 NAiL: yes, but I can't remember :-) Dec 25 15:29:26 hehe Dec 25 15:29:39 that's the reason I moved the HD to hdc. hda is a CF. Dec 25 15:29:46 I've ordered a 4GB CF card to use as hda Dec 25 15:30:08 NAiL: you aim for a silent mythtv? Dec 25 15:30:21 not completely, but *very* quiet. Dec 25 15:30:27 silent when idle :-) Dec 25 15:30:35 yeah :) Dec 25 15:30:48 well.... not quite Dec 25 15:30:57 There's gonna be a 120mm fan inside the PSU Dec 25 15:31:14 NAiL: I am interested in this as well: http://gnunilink.sourceforge.net/ Dec 25 15:31:23 and the optical drive isn't going to be completely quiet. I'm adjusting it to 2x though. Dec 25 15:31:43 i.e. some box acting as a audio server to my sony radio, in-car. Dec 25 15:32:03 NAiL: but that will probably where the EFIKA will end up :-) Dec 25 15:32:18 ooooh, neat-oh Dec 25 15:33:22 btw, there's some table in the bios related to ACPI. It would appear that suspend can work if that is copied as well. Dec 25 15:33:56 "suspend" == hibernate though Dec 25 15:34:04 but that can still reduce boot time a bit Dec 25 15:52:10 NAiL: I did copy the ACPI table. Dec 25 15:52:25 NAiL: I found the notes I wrote down when I did all this. Lemme send it to you. Dec 25 15:56:01 NAiL: http://www.sidebranch.com/twiki/bin/view/Main/EpiaLinuxBIOS Dec 25 16:08:53 thx Dec 25 18:03:24 03bzhou * r4826 10optware/trunk/make/nginx.mk: nginx: 0.5.4 -> 0.5.5 Dec 25 21:55:08 Hello! Dec 25 23:14:00 Hello eno, I saw you working on the new pkg build on and off thru the last couple of days! Very dedicated! Thank you! Dec 25 23:14:52 hi chacko, actually i need some help Dec 25 23:15:28 Yes? Dec 25 23:15:38 in coming up a word that describes whether for a certain optware platform, writing out of /opt is allowed Dec 25 23:16:00 i'm not a native English speaker Dec 25 23:16:27 something like OPTWARE_TRESPASS_ALLOWED Dec 25 23:16:48 set to true for optware/nslu2, and set to false for optware/slugosbe Dec 25 23:16:48 Really? I would not have guessed! Anyway, tell me again what you are looking for Dec 25 23:18:05 this is so that there won't be /usr/bin/ symlinks for optware/slugosbe Dec 25 23:18:37 on optware/nslu2, we have /usr/bin/perl symlink to /opt/bin/perl for example Dec 25 23:18:37 Not clear... Do you want something to allow/disallow write TO /opt/ subtree? Dec 25 23:19:15 I want a variable that allow/disallow write OUTSIDE of /opt/ subtree Dec 25 23:20:26 the variable will then be used in optware/Makefile, set to different values for different platforms Dec 25 23:21:06 Let me try by an example: In SlugOS/BE, when I run ipkg (normal), it will write to pretty much every where, right? Dec 25 23:21:32 i'm only talking about /opt/bin/ipkg Dec 25 23:22:04 so on optware/slugosbe, we don't want /usr/bin/perl to link to /opt/bin/perl Dec 25 23:22:30 while on optware/unslung, we would like to have /usr/bin/perl link to /opt/bin/perl Dec 25 23:22:50 perl, python, env, and a couple of symlinks Dec 25 23:23:04 When I try your new OPKG (that is my new name for the /opt/bin/ipkg), for installing optware on slugosbe, it will write most of the stuff to the /opt/ subtree, and some stuff such as symbolic links and others to outside the /opt/ right? Dec 25 23:23:14 yes Dec 25 23:24:11 when the new feed is up, during build time, i'd like to suppress writing outside /opt/ for optware/slugosbe Dec 25 23:25:49 i came up with OPTWARE_TRESPASS_ALLOWED, which will be true for optware/unslung, and false or undefined for optware/slugosbe Dec 25 23:26:00 But, when I use OKPG, on slugosbe, I need to get the links from /usr/bin/perl to the /opt/ locatiions, NO? Dec 25 23:27:00 maybe you want, but when openslug also provides perl, i would like to forbid optware to write outside of /opt in any case Dec 25 23:27:17 better safe than sorry Dec 25 23:27:47 if you really want to link /opt/bin/perl to /usr/bin, you can do it manually and i suppose you know what you're doing Dec 25 23:28:00 Right!! So, perhpaps opkg needs to first check if the same pkgs have been installed by ipkg already? Dec 25 23:28:17 i don't want to make it that complicated Dec 25 23:28:41 i just want to forbid writing outside of /opt/ in the first place Dec 25 23:29:37 if you look closely, all optware python packages are explicitly using /opt/bin/python2.4 in #! Dec 25 23:29:45 But if we require, the user to manually setup needed links, it would be too complicated, IMO. Perhaps the user can set OPTWARE_TRESPASS_ALLOWED before running a particular opkg? Dec 25 23:31:04 it would be very difficult to maintain the packages if we have OPTWARE_TRESPASS_ALLOWED as a runtime parameter Dec 25 23:31:41 my intention is to stay simple, have OPTWARE_TRESPASS_ALLOWED as a build time Makefile variable Dec 25 23:32:39 kinda like fink and darwinports on mac os x Dec 25 23:32:46 or sunfreeware on solaris Dec 25 23:32:56 Eno, my problem is trying to get clear on build time, and user time... Are you talking about this only for when you build the pkgs, or for the users like me who would use the pkgs you built from a future new stream? Dec 25 23:33:21 at this point, only at build time Dec 25 23:34:09 Let us assume you do your proposed 'simple' method for build time. How do you see that work for a user at opkg install time? Dec 25 23:34:23 for files or symlinks outside of /opt, it's very hard to say whether it's the responsibility of openslug packages or optware packages Dec 25 23:35:08 any optware perl packages should use /opt/bin/perl Dec 25 23:35:19 any optware python packages should use /opt/bin/python Dec 25 23:35:36 and so on and so forth Dec 25 23:35:51 optware should be as self-contained as possible Dec 25 23:36:39 So, let us say, I as an opkg user of perl on slugosbe, will make a symbolic link of /bin/usr/perl to the /opt/bin/perl manually ? Dec 25 23:37:13 you don't have to, and usually you don't need to Dec 25 23:38:15 you can refer to /opt/bin/perl explicitly, or have /opt/bin in the PATH before /usr/bin Dec 25 23:38:25 So when I type perl on command line, if no regular perl was not available, it would have automatically picked up /opt/bin/perl, since /opt/bin will be in the path after /bin? Dec 25 23:39:12 if you want to be absolutely sure about which perl you're using, you should use explicit /opt/bin/perl Dec 25 23:40:22 My view of the usecase for the new opkg pkgs is like this: When one needs perl, he will try to ipkg install perl, and if it is available, done. If not, Dec 25 23:40:38 whether you set PATH to /opt/bin:/usr/bin or /usr/bin:/opt/bin is your choice Dec 25 23:41:09 in your case, you should set /usr/bin:/opt/bin Dec 25 23:41:37 he will check if opkg perl is available, and then try to install opkg perl. By setting the path to /usr/bin:/opt/bin, the right pkg will be picked up. Dec 25 23:42:19 but remember, other user maybe different, some user may require specifically perl 5.8.8, or optware only perl module package Dec 25 23:42:37 in that case, he/she might want to set /opt/bin before /usr/bin Dec 25 23:43:39 so do you think OPTWARE_TRESPASS_ALLOWED conveys the meaning well enough for other optware developer to understand? Dec 25 23:45:54 In those rare cases, when a user wants to use an opkg perl, even when an ipkg perl is available, yes, those users can manually call the specific /opt/bin one, or put simbolic links... My recommendation to strongly suggest to the users, that they use the native (ipkg) pkgs whenever available, and use the optware only when they are not available. In the case of apache and php, apache was available under ipkg too, but since it inter Dec 25 23:47:41 i don't share the view that optware pkgs are not "native" Dec 25 23:48:29 when the new optware/slugosbe feed is up, all will be build with the exactly the same toolchain Dec 25 23:48:31 I understand... I used the word native only to distinguish the two sets here for explantion, Dec 25 23:49:30 right Dec 25 23:50:15 some healthy competition is good Dec 25 23:50:35 for both openslug packages and optware Dec 25 23:50:57 So if you use your proposed scheme, then it would be nice to have two additional stuff: (1) before install give a msg when it needed to tresspass outside /opt/ since it will not do that and (2) after install list all the ones tresspasses it did not do!! Dec 25 23:52:56 Just getting a complete detailed lists of the paths that I need to test manually, will reduce the potential for erros significantly... Dec 25 23:53:04 Do you like to talk on the phone? Dec 25 23:54:01 i should've made myself more clear, i simply want to forbid trespassing on optware/slugosbe Dec 25 23:54:24 and keep the trespassing behavior as is for optware/unslung Dec 25 23:55:07 i can search all the pkg.mk files for any trespassing Dec 25 23:56:07 and since i don't offer trespassing, i may not please all the users, but at least i won't offend any Dec 25 23:56:21 Eno, I did understand that. What I am suggesting is, since under those conditions it would be an 'incomplete install' compared to the unslung install, WE NEED TO LIST THOSE INCOMPLETE ONES RIGHT THERE. Otherwise, it woulf be difficult for most mortals to do this easily :) Dec 25 23:57:53 i don't think we should consider optware/unslung trespassing behavior standard, rather it should be the exception Dec 25 23:57:53 Yes, you prevent some harm being done... But an incomplete install is a similar harm for the one who is trying to istall it, no? Dec 25 23:58:22 I assume there will two feeds, and slightly different step or name to install using your new feed? Dec 25 23:58:33 the installation is complete without /usr/bin/ stuff Dec 25 23:58:45 yes Dec 26 00:00:07 it will be an entirely separate feed called optware/slugosbe Dec 26 00:00:08 You think of the installation as just the pkgs and files, I consider everything done by the ipkg install (including the symbolic links setups, etc) as part fo the isntall :) That is where we a different view, I think. Dec 26 00:00:56 the optware/slugosbe has three bootstrap options: Dec 26 00:01:09 1. from a special openslug package Dec 26 00:01:41 continue Dec 26 00:01:41 2. a bootstrap shell script like ds101-bootstrap Dec 26 00:01:51 3. manual feed setup Dec 26 00:01:59 I have no idea bout 2. :( Dec 26 00:02:35 think of 2 as the automation of 3 Dec 26 00:02:40 Do you see the need for a user to get at the time of install, the 'prevented' tresspasses? Dec 26 00:02:49 no Dec 26 00:02:52 :-) Dec 26 00:03:33 Some pgk may have tens or hundres of symbolic links needed for proper operation !! Dec 26 00:03:34 they only need /usr/bin/env which is provided by openslug already Dec 26 00:04:17 tens or hundreds of symlinks are maintenance nightmares Dec 26 00:04:46 You look at a pkg like the netpbm? Dec 26 00:04:57 if you can give an example, i maybe can give you a counter-example as how to workaround the need of that many symlinks Dec 26 00:05:17 Most development pkgs have similar situation Dec 26 00:06:12 Are you against listing those 'incompletes' because it is difficult for you to do, or you do not see any value for the user? Dec 26 00:06:45 i have not seen enough value for the users, it's also not easy to do Dec 26 00:09:22 As a user, I will be hardpressed to try a pkg install, if I do not not even know the some links are not allowed, and not done under some condition, but do not know which. Perhpaps some clever guy will write a script, which will compare the unslug install list and the slugosbe install list, and show the diff. I HOPE! Dec 26 00:10:23 if you setup your PATH correctly, why do you need symlinks? Dec 26 00:10:54 i'm looking at openslug netpbm package file list right now Dec 26 00:11:04 I think the problem can be simplified, if you push this no tresspass test to run time!! Dec 26 00:11:31 i don't understand why you need symlinks for netpbm Dec 26 00:14:27 All those /usr/bin/xxx are symlinks to netpbm, in my install here. Dec 26 00:15:51 Doing this at run time should be relatively easy (? my guess :) ) since you have complete control over the pkg install software for this stream ?? Dec 26 00:15:56 then if we have an optware netpbm package, all /opt/bin/xxx are symlinks to /opt/bin/netpbm Dec 26 00:16:12 what is the problem? Dec 26 00:17:29 let me tell you, symlink files across different feeds will cause endless pains Dec 26 00:18:24 i don't want to solve a problem that does not really exist Dec 26 00:19:29 I hope you are right that a problem does not exist. I really mean this :) Dec 26 00:20:13 If there is a problem then we will find out, and eventually somebody will try to solve it ... Dec 26 00:20:38 i'll push this build time OPTWARE_TRESPASS_ALLOWED Makefile variable for now Dec 26 00:21:34 we'll reconsider the runtime option if there're enough feedback asking for it Dec 26 00:21:46 BTW, the symblinks in netpbm, the way you mentioned, shoud work fine, since for me thoser exes will be picked up from the /opt/bin path ok. Dec 26 00:22:20 OK, thanks. Dec 26 00:22:31 thanks for the discussion Dec 26 00:23:39 The name OPTWARE_TRESSPASS_ALLOWED probably my be clearer with OPTWARE_WRITE_OUTSIDE_OPT_ALLOWED Dec 26 00:25:29 So, how is the new build coming? Many problems? Good progress? Dec 26 00:26:21 ok, i'll use OPTWARE_WRITE_OUTSIDE_OPT_ALLOWED, it's longer but more explicit Dec 26 00:27:03 $ ls -l slugosbe/builds/*.ipk | wc -l Dec 26 00:27:03 436 Dec 26 00:27:54 What is the total under unslung (that is 436 out of howmany)?? Dec 26 00:28:03 when i checked in the OPTWARE_WRITE_OUTSIDE_OPT_ALLOWED change, we are ready to open the feed Dec 26 00:28:25 $ ls -l nslu2/builds/*.ipk | wc -l Dec 26 00:28:26 677 Dec 26 00:28:30 Wow!! Good job!! Dec 26 00:29:07 perl and thus all perl packages are not built for slugosbe Dec 26 00:29:36 that's 44 packages Dec 26 00:30:34 I tried to open a DCC to you but does not work... Could you please try a private DCC to me? Dec 26 00:30:37 lot more can be fixed to build gradually by excluding -I/opt/include from CPPFLAGS Dec 26 00:34:19 I saw your window, saw your msg, can you see my replies there? Dec 26 00:36:28 Eno, still there? Dec 26 00:36:31 no Dec 26 00:37:05 Hmm... I wonder I need to open any ports in my router/firewall? I am very new to irc... Dec 26 00:37:06 could be the network setting or irc client setting of either of us Dec 26 00:37:49 i'm not that familar with irc either, but i've used msg with others Dec 26 00:38:18 i'm chatting from irssi running on the slug Dec 26 00:38:37 Thanks, I will check it out ... Dec 26 00:39:19 When you have the feed open, please send me an email, you have my email address t4ch... Dec 26 00:39:31 alright, will do Dec 26 00:39:54 And how to get started too, I am not very savvy with the feeds :) Thank you Dec 26 01:11:00 03bzhou * r4827 10optware/trunk/ (6 files in 2 dirs): added OPTWARE_WRITE_OUTSIDE_OPT_ALLOWED, and set to true ONLY on nslu2 **** ENDING LOGGING AT Tue Dec 26 03:00:00 2006