**** BEGIN LOGGING AT Wed Jun 17 02:59:57 2009 Jun 17 03:14:56 how do I build a package against 8.09.1 and not trunk Jun 17 03:27:01 brontide: checkout the 8.09.1 tag Jun 17 03:27:36 then if I do a full build I should be compatible with 8.09.1 Jun 17 03:27:53 or can I just build specific packages Jun 17 03:30:04 select your target in menuconfig, then run make. once that's done you can edit the dropbear package how you want and run make again to build it. Jun 17 03:30:52 if you don't tell it to build all packages, a "full" build doesn't take that long, it's mostly building the toolchain Jun 17 03:31:35 Thanks. Another dumb question. like freebsd ports the souce is downloaded at compile time, how do I get it to download and then give me control? Jun 17 03:31:45 so I can apply another patch Jun 17 03:32:24 make package/dropbear/prepare <-- downloads the source, extracts it and applies all patches Jun 17 03:32:59 (or you can drop the premade patch into package/dropbear/patches and have it applied by the build system) Jun 17 03:33:30 I looked it over and it sppears to be patched at a different level, so unless it can automagically detect a -p1 Jun 17 03:34:17 I will defeintly make a new patch from the final set so I don't have to do this again Jun 17 03:35:28 hmm... wait... it might be at the same patch level. I'll have to give it a shot at least and see what happens. Jun 17 03:38:05 quilt is used to handle the patches. if you are familiar with quilt you can run: make V=99 QUILT=1 package/dropbear/prepare then cd into the dropbear build dir and monkey around w/ quilt, once done pop back to the 8.09.1 dir and run: make V=99 QUILT=1 package/dropbear/update Jun 17 03:38:36 otherwise you can do it the old fashioned way, probably won't make much difference for a single patch :) Jun 17 03:38:47 svn co -r 8.09.1 svn://..../; make menuconfig and select target; muck around in package and make again ( in theory ) :-) Jun 17 03:39:18 That should keep me busy for a few minutes Jun 17 03:40:44 svn -r 8.09.1 no go... trying 16278 Jun 17 03:41:02 much better Jun 17 03:43:42 svn co svn://svn.openwrt.org/openwrt/tags/8.09.1 Jun 17 03:46:45 Patches that I'm hoping to play with are openssh high performance patches at first that may seem a little silly, but I believe that the window scaling should give a little more breathing room as well as the none cypher for poor-man's ftp over a single socket connection Jun 17 03:50:27 oh, I figured you were patching dropbear :) Jun 17 03:50:54 Not today ;-) Jun 17 04:07:36 wow, unchartered territory for me. built a native tool chain for the wgt from the uclibc buildroot, chrooted in, goal is to configure perl Jun 17 04:23:52 How does one add a package with no upstream? Jun 17 04:25:00 just files/scripts? check out ddns-scripts Jun 17 04:25:19 I meant with no download site Jun 17 04:25:45 Still, it might give you the info you need since it's a no site Makefile Jun 17 04:25:54 ok, cool Jun 17 04:44:06 copied openssh into my own feed http://hanez.org/openwrt-building-software-packages.html , but make package/openssh/compile will only build the one from the default package feed even if I feeds update -p mypacakges Jun 17 04:51:58 then run ./scripts/feeds install -p mypackages openssh or ./scripts/feeds install -a -p mypackages (to install all packages from that feed) Jun 17 04:52:30 didn't seem to work so I'm patching the default feed this time Jun 17 04:54:26 Now that I have the right patch it went right in with only a 2 line fuzz on one Jun 17 08:46:49 florian * r16486 /trunk/ (4 files in 4 dirs): [kernel] use 2.6.27.5 Jun 17 09:57:32 kaloz * r16487 /trunk/target/linux/ (ar71xx/config-2.6.30 generic-2.6/config-2.6.30): add missing initramfs symbols to the generic 2.6.30 config Jun 17 11:09:12 jow * r16488 /trunk/package/base-files/ (Makefile files/lib/upgrade/common.sh): [package] sysupgrade: sync *before* mtd write, only fallback to sysrq-trigger if standard reboot fails Jun 17 11:12:04 jow * r16489 /branches/8.09/package/base-files/ (Makefile files/lib/upgrade/common.sh): [8.09] merge r16488 Jun 17 11:44:26 danage: headlines better now? Jun 17 11:44:37 :) Jun 17 11:45:17 it seems theres less space above headlines now, and more below... Jun 17 11:45:38 1em above, 0.5 below Jun 17 11:45:58 ok hang on, i'm editing, i'll check in a second Jun 17 11:46:05 kk Jun 17 11:50:19 does nuwiki need a nulogin, or will the old one work? Jun 17 11:51:49 new login, we hadn't access to the old user database Jun 17 11:52:05 ah, ok Jun 17 11:52:14 xMff: i think it's pretty good. perhaps it could even be scaled down a bit, but i guess it depends much on the system you are using to look at the pages Jun 17 11:54:48 danage: ok Jun 17 11:55:27 sn9: pm me your user name if you want administrative privileges Jun 17 11:56:09 sn9: want to help me invent a procedure for article revisions? Jun 17 11:56:10 will the user name have any bearing on anything outside nuwiki? Jun 17 11:56:34 sn9: most likely not Jun 17 11:59:36 xMff: when a gardener clicks edit on an existing article, he/she cannot edit it. copy and paste is possible, correct? could there be a feature of bouncing the respective edit under a SIMILAR name to inbox? would that procedure make sense? Jun 17 12:00:47 not sure whether there is something that implements that kind of behaviour Jun 17 12:03:57 danage: as I think of it, gardeners *can* edit articles Jun 17 12:04:14 oh, why couldn't i earlier? special page? Jun 17 12:04:30 i probably misunderstood the procedure thhen Jun 17 12:04:40 no, meta: is a special purpose namespace, where to edit makes no sense for everybody Jun 17 12:04:45 which is good, because i can write it down as soon as i do :) Jun 17 12:04:51 :) Jun 17 12:05:13 so when a gardener edits a page in wiki, what happens? auto-bounce to inbox? Jun 17 12:05:30 no, it gets edited, mods only see it via recent changes Jun 17 12:06:01 so - what's the purpose of inbox then? Jun 17 12:06:08 only *new* articles get restricted via inbox, to make sure they are placed correctly in the hicharchy/namespaces structure Jun 17 12:06:17 oooooooh Jun 17 12:06:23 duh Jun 17 12:06:53 mods take more care of a non-redundant placing of docs then of the docs itself. Jun 17 12:07:09 ok misunderstanding, everything is fine then Jun 17 12:07:16 otherwise it would be a huge moderation overhead imho Jun 17 12:07:19 kewl :) Jun 17 12:07:33 agreed Jun 17 12:12:35 hmm, i changed the settings to show full names in logs the way the old wiki did, but now it won't show usernames at all :( Jun 17 12:13:07 only fullnames? Jun 17 12:13:28 i see my fullname below my last edit Jun 17 12:14:14 there is no option to show both, i guess Jun 17 12:14:39 one picks from username, fullname, or e-mail Jun 17 12:17:20 i saw my username before that Jun 17 12:19:55 Username I'd prefer Jun 17 12:21:02 i saw the "phaidros" username before, but now i can't tell which user that was Jun 17 12:21:20 me too Jun 17 12:21:32 me :) Jun 17 12:21:37 i would prefer it too Jun 17 12:21:47 sn9: are you changing this for all of us? why? Jun 17 12:22:45 phaidros: i created meta:moderating and meta:templates - are the levels correct and do you think that's ok in terms of structure? Jun 17 12:23:43 danage: sn9 Having fun ;-) Jun 17 12:23:45 I tried out the hpn openssh patchs last night http://www.psc.edu/networking/projects/hpn-ssh/news.php - they applied cleanly with only 4 lines of fuzz. That provides a small 5-10% speedup for window scaling and poor man's ftp using the none/switch cipher ( another 5-10% speedup ) Jun 17 12:26:53 danage: makes sense to me :) Jun 17 12:27:29 jsut trying to find where that dumb 'playground' link in the edit window is set .. ^^ Jun 17 12:29:14 ah: inc/lang/en/edit.txt Jun 17 12:29:16 ! Jun 17 12:32:07 anyone know more ways to push the router. I was at 1.4mbps over wifi and it seemed like the CPU was pinned even doing non-encrypted stuff Jun 17 12:56:36 oooh, nice new wiki :) Jun 17 13:02:36 yeah Jun 17 13:11:29 moonflux: it's gonna rock massive soon Jun 17 13:12:14 danage: nice work Jun 17 13:12:46 not me, i did the least part Jun 17 13:13:23 well, nice work of everybody involved ;) Jun 17 13:13:34 one idea (and I volunteer to implement it): redirect anything starting with an uppercase letter to the oldwiki: namespace so the old links continue to work Jun 17 13:17:01 florian * r16490 /trunk/target/linux/brcm63xx/image/Makefile: [brcm63xx] generate experimental images for bcm6338 boards, thanks to Daniel Dickinson Jun 17 13:20:44 phaidros: in meta:revising, i think, we should add guidelines step by step as issues occur. it's hard to come up with practical guidelines from scratch. i think we should enhance the section as the wiki kicks off Jun 17 13:42:29 danage: agreed. do you have some scenario in mind already? Jun 17 13:43:09 i think it should end up to be a collection of things people need to be made aware of and to watch, i.e. common mistakes Jun 17 13:45:45 ok Jun 17 13:46:47 schau mal ich hab ein paar kosmetische änderungen an structure gemacht Jun 17 13:47:10 <[florian]> danage: no news on the bcm6345 front, at least until tonight :) Jun 17 13:47:47 ^sorry for german above: phaidros i made some cosmetic changes to meta:structure Jun 17 13:48:20 [florian]: i'll be home later working on wiki if you need testing let me know Jun 17 13:49:28 <[florian]> danage: ok Jun 17 13:50:53 danage: struct ok Jun 17 13:51:12 the TOC looked sucky so made one more change Jun 17 13:51:22 ok. Jun 17 13:51:28 it's now in accordance with meta:start Jun 17 13:51:37 but for this reviewing process we should have a workflow .. Jun 17 13:51:53 go for it, edit away... :) Jun 17 13:52:02 so at leastt mods can follow each other .. lol, following reminds me to twitter .. that'd be fun .. Jun 17 13:52:29 danage: // within == does not work as it seems Jun 17 13:52:48 where? Jun 17 13:52:59 meta:structure Jun 17 13:53:07 phaidros: you mean like peer review? mods checking on each other? Jun 17 13:53:23 i have no idea so far for a reviewing proces, but this is crucial as changes of general things have alot of dependencies ;) Jun 17 13:53:37 has there been some more discussion on whether openwrt specific package documententation should be allowed in wiki? Jun 17 13:53:42 i am a large supporter Jun 17 13:54:10 phaidros: by review do you mean changes to meta pages? Jun 17 13:54:16 yes should be allowed, esp. since configuration methods differ for many packages (uci vs. native) Jun 17 13:54:18 danage, nope, and I'd wait for the mailinglist for that to discuss .. more sustainable :) Jun 17 13:55:15 ack Jun 17 13:55:21 danage: yes, meta. for doc: I dunno if that wouldn't just be to much review work, ppl should follow recent changes for that Jun 17 13:55:41 but, me haz no idea rly Jun 17 13:56:08 phaidros: i agree, there should be a procedure for that, otherwise it may break the whole system Jun 17 13:56:20 ack Jun 17 13:56:58 seems we are hitting all the progress projects like wikipedra had to go through directly from start :) Jun 17 13:57:33 yeah but thats an advantage Jun 17 13:57:42 oki, afk for kinderwagen now :) Jun 17 14:00:38 Hi guys... one question... now in wireless setting "wireless.network = none" is invalid value? or is a valid settings? Jun 17 14:01:25 it's invalid Jun 17 14:01:34 openwrt would try to find an interface named "none" Jun 17 14:02:40 thanks xMff, so good use is crate new interface and set wireless.... Jun 17 14:02:59 yes Jun 17 14:42:26 juhosg * r16491 /trunk/package/wireless-tools/ (2 files in 2 dirs): [package] wireless-tools: fix a bug in iwconfig power command Jun 17 15:02:09 http://usemod.com/cgi-bin/mb.pl?SoftSecurity Jun 17 15:17:58 florian * r16492 /packages/net/openvpn/Makefile: [package] update openvpn to 2.1_rc18 (#5340) Jun 17 15:22:38 florian * r16493 /packages/libs/libpng/ (Makefile patches/100-config_fix.patch): [package] update libpng to 1.2.37 (#5359) Jun 17 16:03:10 florian * r16494 /packages/net/imspector/ (6 files in 3 dirs): [package] update imspector to 0.8 (#5357) Jun 17 16:55:49 xMff: I guess this is a bug, in state wireless keep the wireless.cfg...up=1 after wireless is disabled Jun 17 17:29:47 xMff: this issue happend when some value was changed in wireless wifi-iface because uci change the value of cfg, so I guess that can be fixed if in state wireless use the device name insted cfgname Jun 17 19:13:51 phaidros: so should i commence some of the dirty work that has to be done? i'm thinking TOH concept? Jun 17 19:14:27 sn9: ideas? Jun 17 19:15:56 about? Jun 17 19:17:12 TOH concept Jun 17 19:17:52 you think the toh concept needs improvement? Jun 17 19:18:46 danage: probably would be good with a more unified structure? Jun 17 19:19:32 indeed i do Jun 17 19:20:05 one simple huge cluttered table is not very good in terms of presentation Jun 17 19:20:17 it was split up before Jun 17 19:20:33 also, as far as i remember, the oldwiki toh doesn't link to the particular article for each router Jun 17 19:20:50 it does but under WiP/Supported on the right side Jun 17 19:20:59 i think the table rows need to fit a standard browser window Jun 17 19:21:11 I always klicked on the left and wondered why I ended up on the vendor page :) Jun 17 19:21:15 xMff: ah ok, it needs clarification then Jun 17 19:21:23 so that's something Jun 17 19:22:08 the problem is, once wiki tables get very big, editing them can become a pain in the ass Jun 17 19:22:49 a solution could be to create separate tables per platform and then, perhaps, put them on separate pages Jun 17 19:23:08 this was already done in oldwiki Jun 17 19:23:31 danage: one table per vendor, so editing as a block .. would ease that part at least Jun 17 19:23:38 yeah Jun 17 19:23:39 but I just reassembled the monolithic toh because I was too tired to figure out how to do mass includes in dokuwiki Jun 17 19:23:43 ok so that can be kept. was there a bootloader column? Jun 17 19:24:03 oh the toh is up? Jun 17 19:24:22 oldwiki:completetableofhardware Jun 17 19:24:38 maybe start with a draft what specs are needed about a certain machine. then one can se if it should all go in a table or sumth diff Jun 17 19:24:50 see Jun 17 19:24:52 yeah Jun 17 19:25:12 listing them by vendor makes sense, then add categories for platform? Jun 17 19:26:40 categories as in wiki term? Jun 17 19:27:24 yes Jun 17 19:28:50 dunno yet, what's the best purposes fo categories and tags Jun 17 19:29:04 me neither Jun 17 19:29:42 stuff ppl. are interested in Jun 17 19:29:46 has it usb Jun 17 19:29:53 has it braodcom, atheros Jun 17 19:29:58 is it > 4mb Jun 17 19:30:28 that -> tag? Jun 17 19:30:37 danage: thats by the way a good start for templates .. Jun 17 19:30:38 think so Jun 17 19:30:55 toh template... Jun 17 19:31:42 btw, has anyone an idea if there is a way to have an easy page with e.g. checkboxes to choose what kind of hardware it is? ([ ]4mb [ ]8mb and such) Jun 17 19:31:58 so people do not forget to set all those tags/categories .. Jun 17 19:32:41 don't think so, it's a dump wiki after all Jun 17 19:32:45 *dumb Jun 17 19:33:09 it might end up being among the tasks of moderators Jun 17 19:33:15 indeed Jun 17 19:33:15 hm, couldn't advanced templates anyhow help? Jun 17 19:33:23 true Jun 17 19:33:29 florian * r16495 /packages/libs/libtorrent/ (Makefile patches/010-bencode_check_info_only.patch): [package] update libtorrent to revision 1094 (#5346) Jun 17 19:33:31 no advanced moderators can help ;) Jun 17 19:33:44 well :) Jun 17 19:34:06 florian * r16496 /packages/net/rtorrent/Makefile: [package] update rtorrent ro revision 1094 (#5346) Jun 17 19:34:59 I wouldn't focus that much on the toh since there are already plans to do it in an entirely different way Jun 17 19:35:28 not as wiki but as a real database instead Jun 17 19:35:45 searchable, standardized, confirmed, ... Jun 17 19:36:00 yep, any progress / news on that? Jun 17 19:36:11 !yet Jun 17 19:37:44 what's really important right now is a what version for which model page or sth. like that, to have some clarfication on the endless bcm47xx vs brcm-2.4 stuff, or bin vs. trx etc Jun 17 19:41:59 ok Jun 17 19:42:25 also, we need a MANAGED CLIENT MODE MUST USE WDS in bold and red somewhere Jun 17 19:42:35 *bridgwe Jun 17 19:43:44 yes, something like that Jun 17 19:44:01 I want to contribute some uci documentation at some point but still lack time to do so Jun 17 19:44:38 florian * r16497 /packages/net/transmission/Makefile: [package] update transmission to 1.72 (#5363) Jun 17 19:44:53 until there's a proper structure it wouldn't be noticed much anyways Jun 17 19:44:59 yep Jun 17 19:46:38 is there an option to disable PKG_MD5SUM check? Jun 17 19:46:56 i'm using wireless-git daily snapshot and the only thing I need update is the md5sum Jun 17 19:47:43 xxiao: remove the PKG_MD5SUM line Jun 17 19:47:45 just remove the md5sum line? Jun 17 19:52:28 Bartman007: seems like that is working, i just removed the PKG_MD5SUM from Makefile and it ignores the check then. was looking at download.pl... Jun 17 19:54:52 does openwrt.org have an ipkg repo that is updated daily? it took me 15 hours to compile everything(except that 12 pkgs failed) Jun 17 19:56:02 florian * r16498 /packages/utils/oprofile/: remove empty directory Jun 17 19:57:32 found http://downloads.openwrt.org/snapshots/trunk looks like it's daily updated. great Jun 17 20:09:04 xxiao: the repos should be updated daily, but that requires compilation to complete successfully. Jun 17 20:11:41 i'm sure some of the packages will fail though, about 12 of them in my testing Jun 17 20:12:41 googled and found no answer: can I add two src in opkg.conf, and the first one will take precedence over the second one, say, if two pkgs are at both repos, only the first one will be used. Jun 17 20:12:53 i want to have a mixed pkg repo to play with Jun 17 20:14:03 ipkg/opkg don't handle multiple versions of packages well Jun 17 20:14:41 I think ipkg only handled the first version it came across, I don't know if I've checked to see how opkg behaves. Jun 17 21:57:08 nbd * r16499 /trunk/package/base-files/files/etc/sysctl.conf: change sysctl.conf to disable tcp ecn by default (based on discussion with marek who stumbled upon this, it creates hard-to-debug connectivity issues with providers/servers that still use buggy equipment) Jun 17 23:19:05 mirko * r16500 /feeds/desktop/apps/tangogps/ (. Makefile): add package for mapping application Jun 18 00:05:52 xxiao: did you file a ticket for those orinoco wireless failures? **** ENDING LOGGING AT Thu Jun 18 02:59:57 2009