**** BEGIN LOGGING AT Wed Oct 27 02:59:57 2010 Oct 27 06:21:23 pong cshore_ Oct 27 06:22:09 Hi.....sorry I wasn't here when I said...I've been having sleeping a lot due to medical issues and didn't wake up in time Oct 27 06:23:20 anyway, I've been thinking about the sysupgrade and I think to do it we need to somewhat restrict the extroot configuration Oct 27 06:23:22 heh, np. Now that I'm on vacation I manage to get up at 08am -_- Oct 27 06:23:55 heh Oct 27 06:26:27 The reason I say that is that I don't think it is possible to upgrade the root partition....I think it has to be wiped by sysupgrade (after recording the installed package names), and reinstall packages on first boot, which means that data that shouldn't get wiped out should go on another partition, and that we ought to use that other partition for storing the /etc stuff that should be kept (because for external root /etc stuff to kee Oct 27 06:27:01 post was truncated Oct 27 06:27:41 I don't think we can upgrade the root partition because as soon as the root partition is the root partition the boot process will be use, including kmods, and there's no network until we have the root partition Oct 27 06:28:11 I thought about something like this: write the same random md5sum to both ext overlay ad internal overlay when the extroot is first used Oct 27 06:28:19 sysupgrade will wipe the internal sum Oct 27 06:28:29 and reinstall packages on first boot, which means that data that shouldn't get wiped out should go on another partition, and that we ought to use that other partition for storing the /etc stuff that should be kept (because for external root /etc stuff to keep might be too big for ram/jffs) Oct 27 06:28:30 next time compare them and do not mount the extroot Oct 27 06:28:45 maybe show a warning in login Oct 27 06:29:02 ah, rather than automatic update just prevent use of the parition? Oct 27 06:29:07 *partition Oct 27 06:29:16 this gives at least a chance to strip kmods and the like from extroot Oct 27 06:29:24 right Oct 27 06:29:34 instead of not mounting it at all, maybe mount it to /overlay-disabled Oct 27 06:30:24 I like that better than automatically wiping the partition in the general case Oct 27 06:30:46 in a second step we can add some supplemental cleanup script which needs to be executed manually Oct 27 06:30:57 I'd like to make it option to do the automatic upgrade (but it has to be enabled by the user, who presumably knows what they are doing) Oct 27 06:31:44 That makes sense Oct 27 06:32:32 I'll be working on the automatic upgrade for Marc anyway, so I'm thinking we could use it, but only for users who know how to enable it and presumably have read the docs Oct 27 06:32:34 in general, we should also look into resyncing /etc/config when going from internal overalay to external overlay Oct 27 06:32:55 right, even for the first install Oct 27 06:33:04 same for /usr/lib/opkg/ Oct 27 06:33:05 so that the user doesn't have to remember to copy it manually Oct 27 06:33:48 hmmm...would we wipe all existing packages? Oct 27 06:33:50 actually... if the overlay partition is empty (only contains lost+found, nothing else) then we could copy the whole internal overlay Oct 27 06:34:17 but only files listed in /usr/lib/opkg/whatever Oct 27 06:35:16 i.e. so that we don't erase the partition or do you think it is reasonable to mkfs. /dev/?? Oct 27 06:35:32 no autoformat (maybe configurable) Oct 27 06:35:36 just checking for an empty fs Oct 27 06:35:41 ah, ok Oct 27 06:36:01 often people decide to use extroot after customizing the system Oct 27 06:36:07 right Oct 27 06:36:12 now that extroot is opkg installable it is even more likely Oct 27 06:36:17 right Oct 27 06:36:31 but we don't want to copy opkg over a non-empty partition Oct 27 06:36:37 so we need to check Oct 27 06:38:24 I wonder... current sysupgrade has a quite extensive conffiles tagging mechanism Oct 27 06:39:08 one could take a listing of all files on rom, strip all conffiles from that and remove any remaining file in this list from the overlay Oct 27 06:39:30 that would go in the cleanup script Oct 27 06:39:42 should we remove binaries too? Oct 27 06:39:48 if it works out very well we can consider making it automatic at some point Oct 27 06:39:50 yes Oct 27 06:40:05 uclibc does not guarantee binary compatibility Oct 27 06:40:12 that's what I thought Oct 27 06:40:48 so on after sysupgrade, we should remove any file which is in /rom and /overlay and not a conffile Oct 27 06:41:03 so basically the main reason we're not autoformating in the general case is that we might miss something that should be kept Oct 27 06:41:10 correct Oct 27 06:41:21 not all packages properly tag conffiles yet Oct 27 06:41:25 right Oct 27 06:41:43 I added the possibility to tag config directories recently Oct 27 06:41:53 and most users don't manually alter their keep list (which we should moved to system from luci and incorporate into command line) Oct 27 06:41:56 so one does not loose stuff like /etc/ppp/ for example Oct 27 06:42:01 cool Oct 27 06:42:49 Do you think /etc/config/system or /etc/config/sysupgrade? Oct 27 06:43:00 there is /etc/sysupgrade.conf now Oct 27 06:43:07 which one glob pattern per line Oct 27 06:43:10 *with Oct 27 06:43:14 ok, ok, that works Oct 27 06:43:29 then there is /lib/upgrade/keep.d/* Oct 27 06:43:37 same format, but populated by packages Oct 27 06:43:46 the third source is opkg list-changed-conffiles Oct 27 06:43:59 not UCI because the config is not necessarily available to sysupgrade because of the ram pivot Oct 27 06:44:05 correct Oct 27 06:44:33 https://dev.openwrt.org/changeset/23258 Oct 27 06:46:25 hmmm...opkg would have to be run before the ram pivot, right? Oct 27 06:46:34 it is Oct 27 06:46:43 oh, I missed that line, I see it Oct 27 06:48:08 are you sure we want to remove the conffiles though ? Shouldn't the config be kept for when the packages are reinstalled? Oct 27 06:48:22 or stashed someplace safe Oct 27 06:48:42 I do not want to remove them Oct 27 06:48:53 oh, I misunderstood Oct 27 06:49:06 I want to strip them from the "find /rom" list Oct 27 06:49:27 and then remove anything remaining from /overlay Oct 27 06:49:49 this gets rid of stuff like /lib/ or a reinstalled busybox Oct 27 06:50:23 oh I see. Oct 27 06:50:29 Does opkg list binaries? Oct 27 06:50:34 no Oct 27 06:50:45 unless somebody taggged said binaries as conffile Oct 27 06:51:12 ok, so the binaries will remain on the system ? Oct 27 06:51:22 except if on /rom? Oct 27 06:51:26 right Oct 27 06:51:55 ok, so we can't manually clean those because we don't know what they are so it's up to the user to do that Oct 27 06:52:01 the "remove from /overlay if already on /rom" prevents that old, now defunct binaries are shadowing the new ones in /rom Oct 27 06:52:37 right, and when you first boot those are the only ones what would be used by the system, so the other ones don't matter Oct 27 06:52:50 and will dissappear on opkg install or update Oct 27 06:53:04 or rather be replaced Oct 27 06:54:01 and we don't keep rc.d so there's no autostart of bad binaries Oct 27 06:54:23 bad binaries probably just segfault Oct 27 06:54:39 problem are bad kmods which prevent the good ones from being loaded Oct 27 06:54:40 true, it's only the kmods that are really likely an issue Oct 27 06:54:47 same for libraries Oct 27 06:54:52 right Oct 27 06:55:22 and as long as we're not shadowing that won't be an issue Oct 27 06:55:43 wait. we should probably delete /etc/modules.d or whatever it's called Oct 27 06:56:06 and probably /etc/rc.d as well Oct 27 06:56:22 right now both are not conffiles/confdirs Oct 27 06:56:36 so they would get removed automatically by the cleanup logic Oct 27 06:57:45 or maybe not Oct 27 06:57:51 why do you want that btw? Oct 27 06:58:13 hmmm....that won't work. If we delete every directory on /rom that will delete everything include /bin /usr etc Oct 27 06:58:23 not just files Oct 27 06:58:24 no, just files Oct 27 06:58:40 not directories Oct 27 06:58:45 ok, so if there are files in /etc/modules.d other than the ones on rom they will still be there Oct 27 06:58:53 yes Oct 27 06:58:58 which isn't a big issue Oct 27 06:59:04 and so the modules will try to be loaded which could oops the machine Oct 27 06:59:15 e.g. a module that is only on the overlay Oct 27 06:59:49 because the binary wouldn't be removed Oct 27 07:00:01 it'll only cause an oops/panic if the module is in a generic path, but compiled to a specific kernel, and still somehow manages to partially load. generally it'd just go "this kernel isn't what i'm expecting" and stop. Oct 27 07:00:21 hmmm....I've had bad luck with that then Oct 27 07:00:27 true Oct 27 07:00:29 nvidia? Oct 27 07:00:34 on openwrt? Oct 27 07:00:41 I've had panics because of that Oct 27 07:00:46 he didn't specify it as a specific openwrt issue.. :) Oct 27 07:00:55 what modules cshore_? Oct 27 07:00:56 EqUaTe: :P Oct 27 07:01:07 no, it was iptables IIRC Oct 27 07:01:17 or rather kmod-ipt-something Oct 27 07:01:22 the modules issues could be improved on the buildroot side Oct 27 07:01:38 the Kernel offers a few facilities to detect such mismatches Oct 27 07:01:47 embedded magic values etc. Oct 27 07:01:50 yeah Oct 27 07:02:03 maybe turning that on by default would be a good idea Oct 27 07:02:04 ok, if we're going not delete /etc/modules.d we need to do that Oct 27 07:02:57 I actually ran into the problem with a self-compiled kernel and having having the snapshots repository in opkg Oct 27 07:03:20 it didn't like the combination of a newer kmod and my kernel Oct 27 07:03:23 ah, theres another new feature Oct 27 07:03:33 all kmod-* packages are tagged as hold in opkg Oct 27 07:03:45 to prevent reinstalling them on opkg upgrade etc. Oct 27 07:04:03 well this was a new install of a kmod I wanted to add Oct 27 07:04:04 those packages tags can be used as another source to decide what to strip / not to strip Oct 27 07:04:16 right, strip all hold Oct 27 07:04:59 right, time to go to work Oct 27 07:05:00 bbiab Oct 27 07:05:00 how do you check if something is hold? Oct 27 07:05:08 opkg flag Oct 27 07:05:23 or grep /usr/lib/opkg/status Oct 27 07:06:06 so grep Hold: /usr/lib/opkg/status? Oct 27 07:06:35 build #16 of iop32x is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/16 Oct 27 07:07:27 hmnot quite Oct 27 07:14:02 The reason I ask is we'll need to grep the file on the old overlay since it won't be accessible to opkg at script time Oct 27 07:20:49 http://paste.openwrt.org/d524eb887 Oct 27 07:24:21 heh, that's more than my sed-fu knew Oct 27 07:26:05 though we want the files and not the package names Oct 27 07:27:47 Ok, so for the cleanup script we: Oct 27 07:27:47 hmmm....is there anyway to get them from opkg/status? Oct 27 07:29:00 yes Oct 27 07:29:02 moment Oct 27 07:31:47 So, for the cleanup script we: Oct 27 07:31:47 generate the conffiles list as for sysupgrade Oct 27 07:31:47 take the list of files on /rom and remove the conffiles Oct 27 07:31:47 find the list of hold binaries Oct 27 07:31:47 remove /rom less conffiles Oct 27 07:31:47 remove hold binaries (as found via your sed-fu) Oct 27 07:33:40 perhaps we should also remove /etc/rc.d from overlay-disabled ? Oct 27 07:37:44 build #16 of rdc is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/rdc/builds/16 Oct 27 07:46:04 http://paste.openwrt.org/d42b44a11 Oct 27 07:46:18 not sure Oct 27 07:47:23 does the package.list include binaries? Oct 27 07:47:35 yes, its a complete package manifest Oct 27 07:48:03 why not just remove everything except conffiles in the packages.lists on overlay-disabled? Oct 27 07:48:46 because it might contain custom scripts, not opkg managed bianries etc. Oct 27 07:49:18 you mean custom scripts overwriting a file that is in the opkg? Oct 27 07:49:33 ah you mean that Oct 27 07:49:56 yeah would probably work too Oct 27 07:50:07 except files/ Oct 27 07:50:14 those are not listed Oct 27 07:50:33 unless they happen to replace stuff listed in some package Oct 27 07:50:49 but they'd be on the rom anyway right? Oct 27 07:50:57 or do you mean files/ for the package? Oct 27 07:51:02 rom Oct 27 07:51:33 anyway, I don't think we need the hold stuff at all Oct 27 07:51:38 right Oct 27 07:52:07 just need to find an efficient way to substract one list from another Oct 27 07:54:16 (cat packages.list rom.list | sort | uniq -d >both.lst); cat both.list packages.list | sort | uniq -u Oct 27 07:54:21 only way I know Oct 27 07:54:55 at least when I do it by hand it's fast Oct 27 07:55:33 I use that all the time to generate a list of packages what were installed on a previous incarnation and are still available, so ought to be installed again. Oct 27 07:57:55 of course there's usually hand editing of the list do to changed needs but in principle it shouldn't be necessary Oct 27 07:58:02 *due Oct 27 08:00:44 for the number of packages available in OpenWRT speed won't be an issue....if it were 100's of thousands it probably would become and issue, but even on Debian, I use that with practically instantaneous operation. (although that's on a faster processor...on a PII is more like 1-2s) Oct 27 08:01:14 ok, so this: ( find /rom -type f | sed -e 's!^/rom!!'; find /overlay -type f | sed -e 's!^/overlay!!' ) | sort | uniq -d Oct 27 08:01:57 are you msising an ! on the s? Oct 27 08:02:09 oh no, I just didn't see it...font issues Oct 27 08:04:52 build #17 of sibyte is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/17 Oct 27 08:06:11 right, that would get you the list of files on on rom and overlay. Then you would take that list and remove the conffiles. Oct 27 08:07:42 ah found a cheap trick Oct 27 08:07:53 do tell Oct 27 08:08:04 cat delta.list conffiles.list conffiles.list | sort -u Oct 27 08:09:27 delta is the previously listed commands ? Oct 27 08:09:53 yes Oct 27 08:09:55 sorry Oct 27 08:10:02 ... | sort | uniq -u Oct 27 08:10:11 I was about to ask Oct 27 08:10:18 http://paste.openwrt.org/d113af2fe Oct 27 08:10:20 sort -u doesn't do what you expect Oct 27 08:12:19 build #16 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/16 Oct 27 08:13:03 when I was figuring out that technique (by reading man pages and thinking about it) I discovered sort -u didn't work Oct 27 08:17:34 hello Oct 27 08:19:07 would it be same for spacey names to do rm -f $(find-delta.sh) or do we need to get that list into a 0-terminated format and do cat 0term| xargs -0 rm -f ? Oct 27 08:19:26 ... | xargs rm -v Oct 27 08:19:30 ... | xargs rm -fv Oct 27 08:19:50 yes, spacy names will be an issue Oct 27 08:19:50 doesn't that fail for names with spaces though ? Oct 27 08:21:36 is there command we can use to replace the newline character with a NUL (ASCII 0)? Oct 27 08:22:38 e.g. find-delta.sh | newline-to-nul | xargs -0 rm -f ? Oct 27 08:24:10 find-delta.sh | while read line; do ...; done can cope with spacy names Oct 27 08:24:21 unless those contain newlines but well... Oct 27 08:24:30 I was hoping for something more efficient Oct 27 08:24:47 neither bb sort nor bb uniq support NUL Oct 27 08:25:11 don't need to just need newline-to-nul after the fact Oct 27 08:25:45 e.g. if you could sed -e 's/\n/\0/' or something Oct 27 08:26:40 OTOH this script is run manually and once Oct 27 08:26:54 so slow rm isn't necessarly that big an issue Oct 27 08:27:11 yes, also if you want some interactive mode, the while loop is useful Oct 27 08:27:17 right Oct 27 08:29:20 although I think for an interactive rm to be useful you have to have more patience for excessive number of files to pay attention to whether to keep or not. Oct 27 08:29:30 more patience that I have that is Oct 27 08:31:23 *than Oct 27 08:31:34 or instead of the interactive mode we offer another thing Oct 27 08:31:53 isntead of removing the files we move them to a folder /overlay/removed Oct 27 08:32:05 hmmm....good idea Oct 27 08:32:51 obviously we need to ignore it then Oct 27 08:33:23 right...just in case some put a removed file on the rom for some reason Oct 27 08:33:32 dir I mean Oct 27 08:33:56 ok so the cleanup part ism ore or less done Oct 27 08:34:12 only the detection of a sysupgrade is missing Oct 27 08:36:50 1) if no md5sum on jffs create one Oct 27 08:36:50 2) if no m5sum on overlay copy jffs md5sum, else Oct 27 08:36:50 (else) if md5sum on jffs different than md5sum on overlay mount --move /overlay /overlay-disabled and mount /tmp/overlay as /overlay (that's the jffs) Oct 27 08:37:09 wait Oct 27 08:37:18 2) is only if /overlay is empty Oct 27 08:37:34 right Oct 27 08:39:27 can you think of anything that misses? Oct 27 08:40:20 I presume if there is no md5sum but the overlay is not empty we treat it as a change (overlay-disabled) Oct 27 08:40:45 yes Oct 27 08:41:25 hmmm..what happens with pure-jffs (not squashfs)? Oct 27 08:43:01 empty is [ -z "$(find /overlay/ -mindepth 1 -maxdepth 1 ! -path '/overlay/lost+found')" ] Oct 27 08:45:30 correction, find /overlay/ -mindepth 1 -maxdepth 1 '(' ! -path '/overlay/lost+found' ! -path '/overlay/md5sum' ')' Oct 27 08:47:02 not sure how to deal with pure jffs2 images Oct 27 08:47:42 but aren't they mounted to /rom as well? Does it make any difference? Oct 27 08:47:56 I mean we're not comparing rom to internal overlay but rom to external overlay Oct 27 08:48:48 it doesn't make a difference for the cleanup script AFAICT Oct 27 08:49:58 for the md5sum part I think the only difference is the md5sum in on '/' instead of '/tmp/overlay' Oct 27 08:53:56 since that happens before pivot Oct 27 08:58:21 now for the automatic update (which is only done if the user configures the system to do so), I think it'd be a case of doing the same thing, except after init does the done script we'd execute the clean script update the md5sum, set a flag, and then on the next boot do an opkg update on all packages on overlay but not on rom Oct 27 08:59:20 sounds reasonable Oct 27 09:02:17 there would have to a conffile on the overlay I think, because the jffs is inaccessible before sysupgrade (not mounted for squashfs, or ro mount below the external overlay for pure-jffs) Oct 27 09:03:19 what conffile ? Oct 27 09:03:27 build #16 of ifxmips is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ifxmips/builds/16 Oct 27 09:03:46 a new one...that says do automatic upgrade (or not) Oct 27 09:04:48 not sure where to put it...maybe an uci setting in /etc/config/system? Oct 27 09:05:14 or fstab Oct 27 09:05:35 hmmm...right that makes sense since that's where extroot is defined Oct 27 09:07:29 oh, here's a question...do we want to add feature so that if the md5sum is not present on the overlay and the overlay is empty, to copy /tmp/overlay to the overlay ? (since if we have the overlay it means extroot has already been abled) ? Oct 27 09:08:00 yes, that would make sense Oct 27 09:17:40 what do you think of a package, that if is installed, extroot is enabled, and the device defined for extroot does not exist (and only in that case, since a case of bad uuid or label could be a corrupted fs that someone wants to try to recover, but an entirely missing partition is more likely to mean the device hasn't been created yet), then use sfdisk-fu (obviously sfdisk would have to be installed, so that condition would be part of Oct 27 09:18:20 auto formatting? Oct 27 09:19:10 right, but only if the package is installed...maybe also a config option set to use it....shouldn't happen accidentally Oct 27 09:22:47 I think that would got under Utilities/disc Oct 27 09:22:47 sounds useful but only nice-to-have-prio imo Oct 27 09:23:19 well I need it for what I'm doing for work, so I just wanted to see if you thought it'd be generally useful Oct 27 09:23:31 I see Oct 27 09:23:52 brb Oct 27 09:30:33 <[mbm]> openwrt boots to a script called preinit which handles the squashfs/jffs2 .. it just hooks in as an init script; if you wanted to go another level deeper you could replace the init on jffs2 with another preinit style script Oct 27 09:32:29 [mbm]: who are you directing that at? Oct 27 09:32:43 <[mbm]> seemed to be the discussion you were having Oct 27 09:34:49 [mbm]: we're discussing changes we'll be making to preinit and block-extroot....these things need to happen in preinit, not after all the action is over (preinit action that is) Oct 27 09:35:23 <[mbm]> my point is that you can chain preinit scripts Oct 27 09:35:52 <[mbm]> so with a preinit on jffs2 you could switch to another root device Oct 27 09:36:25 [mbm]: you could, but block-extroot already does that Oct 27 09:36:44 opcontrol --start --vmlinux=/Image Oct 27 09:36:44 The specified file /Image does not seem to be valid Oct 27 09:36:47 :| Oct 27 09:37:13 vmware? Oct 27 09:38:00 bcm63xx Oct 27 09:38:50 danitool: not CFE-based bootloader I take it? Oct 27 09:39:03 yes, redboot Oct 27 09:39:14 livebox? Oct 27 09:39:17 yes Oct 27 09:39:33 I'm afraid I have no idea for that.... Oct 27 09:40:28 <[florian]> danitool: is your /Image file the vmlinux kernel? Oct 27 09:40:52 yes, just renamed to allow redboot load it Oct 27 09:41:11 [florian]: hey Florian long time no see! Oct 27 09:41:14 <[florian]> cshore_: indeed Oct 27 09:41:21 instead of changing redboot command line.. Oct 27 09:41:22 <[florian]> danitool: is it compiled with debug info? Oct 27 09:41:28 no Oct 27 09:41:37 [florian]: could you put me in touch with Maxime to work on the vlan patch? Oct 27 09:41:37 <[florian]> well maybe you should start with that Oct 27 09:41:43 <[florian]> cshore_: sure Oct 27 09:42:11 oh debug, but should I enable all debug kernel options? Oct 27 09:42:46 <[florian]> I do not think so Oct 27 09:43:03 <[florian]> debug symbols and "Compiler kernel with debug info" should be enough if I recall right Oct 27 09:43:43 ok Oct 27 09:49:47 [*] Collect kernel debug information : this enables both options Oct 27 10:06:12 florian * r23651 /trunk/target/linux/generic/patches-2.6.35/ (009-decompress_unlzo_fix.patch 980-vm_exports.patch): [kernel] refresh 2.6.35 patches Oct 27 10:06:16 florian * r23652 /trunk/target/linux/brcm63xx/patches-2.6.35/ (270-board-96338W2_E7T.patch 300-wl_exports.patch): [brcm63xx] refresh 2.6.35 patches Oct 27 10:06:19 florian * r23653 /trunk/target/linux/brcm63xx/patches-2.6.35/170-board_livebox.patch: [brcm63xx] register uart driver on livebox (#8013) Oct 27 10:29:57 build #17 of adm5120 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/adm5120/builds/17 Oct 27 10:36:31 thepeople: It seems that curl is needed on the buildbots Oct 27 10:36:52 to support git/http Oct 27 10:43:17 acoul * r23654 /packages/net/quagga/patches/100-quagga_multipath_caching_policy.patch: net/quagga: fix multipath detection. (closes #8136) Oct 27 10:58:32 I just saw there's a ticket for znc modules, I guess this can now be closed: https://dev.openwrt.org/ticket/7901 Oct 27 10:59:40 'lo KanjiMonster Oct 27 11:00:05 hi EqUaTe Oct 27 11:00:15 how goes it? Oct 27 11:01:42 can't complain Oct 27 11:16:00 xMff: thanks Oct 27 11:18:04 jow * r23655 /trunk/package/hostapd/files/hostapd.sh: (log message trimmed) Oct 27 11:18:04 [PATCH] Set auth_algs in hostapd.conf, make it configurable for WEP Oct 27 11:18:04 Always set auth_algs in hostapd.conf. For WEP, auth_algs is configurable Oct 27 11:18:04 by setting the encryption parameter of a wifi-iface to contain "open" Oct 27 11:18:05 (1, open system), "shared" (2, shared key), or "mixed" (3, permits both Oct 27 11:18:05 open system and shared key.) For example, use "wep+shared" for shared Oct 27 11:18:06 key authentication. The default is default is "open" as it is more Oct 27 11:18:07 jow * r23656 /branches/backfire/package/hostapd/files/hostapd.sh: [backfire] merge r23655 Oct 27 11:23:42 xMff: should I point out some more tickets that can be just closed or just need some already existing patch/backport from trunk? ;) Oct 27 11:23:54 yeah Oct 27 11:24:01 Yep, please do so Oct 27 11:24:30 We really need more people working on tickets. Oct 27 11:25:09 https://dev.openwrt.org/ticket/7168 <- this was afaik fixed in the default configs (I don't remember whether the switch driver still allows vlan 0) Oct 27 11:25:56 https://dev.openwrt.org/ticket/7365 <- needs either http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=patch;h=d1ab903d2552b2362339b19203c7f01c797cb316 or a kernel update to 2.6.32.21 or later Oct 27 11:26:46 https://dev.openwrt.org/ticket/7980 <- still needs r23127 backported (although that's juhosg's domain probably) Oct 27 11:30:07 jow * r23657 /trunk/package/madwifi/files/lib/wifi/madwifi.sh: [package] madwifi: add wep+open, wep+shared format support to madwifi as well Oct 27 11:31:02 jow * r23658 /branches/backfire/package/madwifi/files/lib/wifi/madwifi.sh: [backfire] merge r23657 Oct 27 11:36:01 looks like r23127 is already backported Oct 27 11:37:04 at least there are no deltas Oct 27 11:37:40 oh nvm Oct 27 11:37:42 wrong dir Oct 27 11:38:44 jow * r23659 /branches/backfire/target/linux/generic-2.6/files/drivers/net/phy/ (rtl8366rb.c rtl8366s.c): [backfire] merge r23127 Oct 27 11:50:09 jow * r23660 /trunk/package/madwifi/files/lib/wifi/madwifi.sh: [package] madwifi: make wep-open the default Oct 27 11:51:00 jow * r23661 /branches/backfire/package/madwifi/files/lib/wifi/madwifi.sh: [backfire] merge r23660 Oct 27 11:53:47 https://dev.openwrt.org/ticket/7940 <- libpcap and tcpdump(-mini) are available for all archs in 10.03.1-rc3 => invalid Oct 27 11:57:18 mb * r23662 /packages/Xorg/xorg/app/xkbcomp/Makefile: xkbcomp links to libxkbfile. Add the dependency. This fixes compile failures. Oct 27 11:58:30 mb * r23663 /packages/Xorg/xorg/app/xkbcomp/Makefile: xkbcomp: Enable parallel build Oct 27 12:02:21 https://dev.openwrt.org/ticket/8085 <- rt-n16/bcm4718 will probably be never supported in backfire, at least not in the next time (also there is already a ticket for the rt-n16) Oct 27 12:08:43 https://dev.openwrt.org/ticket/7487 <- microSD support was added to trunk in r22863, but it seems to be still a bit unstable, so I think this should be at least pushed back to a later release Oct 27 12:10:33 KanjiMonster: it is online Oct 27 12:13:05 blogic: I mean more the integration into openwrt's processes and stuff. currently you have to know it exists, afaik there's no documentation pointing to it Oct 27 12:15:03 https://dev.openwrt.org/ticket/7830 <- @xMff you committed an improved switch/vlan page to luci trunk, perhaps this could be backported to backfire's 0.9? Oct 27 12:15:40 KanjiMonster: then fix wiki and point at it :) Oct 27 12:18:07 blogic: I would put something like this onto the dev-wiki, for which I lack an account ;) Oct 27 12:18:31 ok Oct 27 12:18:55 https://dev.openwrt.org/ticket/7129 <- I'm 99.9% sure this was fixed with https://dev.openwrt.org/changeset/22615 Oct 27 12:22:53 https://dev.openwrt.org/ticket/7960 is essentially a duplicate of https://dev.openwrt.org/ticket/7184 (except with no patch, and backfire target) Oct 27 12:23:39 KanjiMonster: my plan is to finish current luci trunk and switch to that Oct 27 12:23:47 KanjiMonster: I do not intend to maintain 0.9 anymore Oct 27 12:24:58 ah, even better Oct 27 12:25:18 https://dev.openwrt.org/ticket/8119 <- this is a trunk problem (and valid), but backfire is fine Oct 27 12:43:26 https://dev.openwrt.org/ticket/7798 <- invalid, just needs some explanation why this isn't easily "fixable" Oct 27 12:44:19 i'll do it Oct 27 12:45:39 shicking, 11k highly redundant text Oct 27 12:45:45 its going to blow up his box Oct 27 12:45:50 *shocking Oct 27 12:46:22 xMff: :) spezialexperten :) Oct 27 12:46:31 https://dev.openwrt.org/ticket/8119 still has the wrong milestone ;) Oct 27 12:54:30 https://dev.openwrt.org/ticket/8092 <- invalid, as first comment says Oct 27 13:17:15 acoul * r23664 /packages/net/quagga/patches/100-quagga_multipath_caching_policy.patch: net/quagga: fix r23654 Oct 27 13:24:44 acoul * r23665 /packages/net/quagga/Makefile: net/quagga: honor configure.ac patch changes Oct 27 13:41:19 mb * r23666 /packages/ (4 files in 4 dirs): Split python into a host and target build. Also add a HostPython macro to conveniently and safely invoke host python binary. Oct 27 13:42:13 mb * r23667 /packages/lang/ (4 files in 4 dirs): Fixup python-sip and pyqt4 to use the internal host-python. Oct 27 13:50:10 kaloz * r23668 /trunk/target/linux/ (13 files in 13 dirs): mark targets maintained by me Oct 27 14:08:12 lars * r23669 /trunk/target/linux/generic/config-2.6.36: [kernel] Add missing symbol to 2.6.36 config Oct 27 14:15:45 lars * r23670 /trunk/target/linux/xburst/patches-2.6.36/ (300-battery-fixes.patch 301-mfd-adc-fixes.patch): Oct 27 14:15:45 [xburst] ADC and battery fixes Oct 27 14:15:45 * Fix concurrent battery readings Oct 27 14:15:45 * Add missing kfree in battery driver remove Oct 27 14:15:45 * Fix disabling of a ADC component Oct 27 14:16:38 lars * r23671 /trunk/target/linux/xburst/Makefile: [xburst] Change kernel version to 2.6.36 Oct 27 14:32:42 mb * r23672 /packages/net/pure-ftpd/Makefile: pure-ftpd-tls needs openssl Oct 27 14:37:47 build #16 of kirkwood is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/16 Oct 27 15:08:39 nbd * r23673 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: Oct 27 15:08:39 mac80211: set GF flag in hostapd config if supported Oct 27 15:08:39 Signed-off-by: Helmut Schaa Oct 27 15:21:44 nbd * r23674 /trunk/package/hostapd/patches/453-ap_sta_support.patch: hostapd: do not restrict ht capabilities for ap+sta Oct 27 15:31:20 mb * r23675 /trunk/package/iptables/Makefile: iptables: Fix call to md5s Oct 27 15:44:51 mb * r23676 /packages/net/linuxigd/ (Makefile patches/003-Makefile-fix.patch): linuxigd: Fix compile failure. The library is libip4tc. not libiptc. Oct 27 15:50:59 hmpf, miniupnpd also fails due to this. I wonder where the breakage was introduced. Oct 27 15:51:44 the iptables userspace apis are braindead Oct 27 15:51:50 they change every version Oct 27 15:52:13 so far linuxigd, miniupnpd and a bunch of others broke with _every_ iptables update Oct 27 15:52:20 hm Oct 27 15:52:37 My confusion is that I _though_ I compiletested those recently. Oct 27 15:52:41 Maybe I'm wrong. Oct 27 15:52:47 thought Oct 27 15:52:56 libiptc should be a bundle of lib4tc and lib6tc Oct 27 15:53:24 ah hm. iptables does not build it, though. Oct 27 15:55:25 but something must be indeed wrong on your side Oct 27 15:55:41 miniupnpd and linuxigd compile fone on the buildbot Oct 27 15:55:44 fine Oct 27 15:56:04 Yeah something is wrong in the iptables build. It builds the library, but fails to install it. Oct 27 15:56:36 This is a fresh checkout, so I'm pretty sure "my side" is fine. Oct 27 15:56:49 maybe due to libtool's infinite wisdom Oct 27 15:57:28 :) Oct 27 15:57:39 libfool again ;) Oct 27 15:58:35 but then again, i usually prefer packages using autofools over packages using custom stuff Oct 27 15:59:06 because custom stuff usually breaks more frequently and requires more manual work for cross compiling Oct 27 15:59:18 yeah Oct 27 15:59:44 Hm, isn't there an svn command for reverting? svn revert doesn't seem to be what I want. Oct 27 16:00:00 what are you trying to do mb__? Oct 27 16:00:12 revery my latest commit Oct 27 16:00:18 revert Oct 27 16:00:35 you could try svn diff -r | patch -p0 -R Oct 27 16:00:46 svn merge -r 23676:r23675 packages/net/linuxigd packages/net/linuxigd Oct 27 16:00:51 ah, that works as well Oct 27 16:00:51 reverse merge Oct 27 16:00:56 that's better than svn diff Oct 27 16:01:02 Ah ok. I thought there was an easier way :) Oct 27 16:01:03 svn merge -r 23676:23675 packages/net/linuxigd packages/net/linuxigd Oct 27 16:01:04 thanks Oct 27 16:01:06 because svn diff sometimes generates diffs that patch can't apply Oct 27 16:01:20 if the commits do renames Oct 27 16:01:28 i wonder what crackhead came up with the idea of doing diffs that way Oct 27 16:04:10 ah crap. Now I fucked up the local SVN Oct 27 16:05:07 should have used a rubber Oct 27 16:05:20 :) Oct 27 16:07:06 mb * r23677 /packages/net/linuxigd/ (Makefile patches/003-Makefile-fix.patch): Revert r23676 Oct 27 16:07:12 * mb__ hits it with a wrench Oct 27 16:24:46 /usr/lib/libc.a: could not read symbols: File format not recognized Oct 27 16:24:51 whoot the hell Oct 27 16:25:33 lol Oct 27 16:25:53 either your build is referencing system files ... or you installed some owrt over your system Oct 27 16:26:01 file /usr/lib/libc.a Oct 27 16:26:05 what does it tell oyu ? Oct 27 16:26:22 it will tell you its an archive lol Oct 27 16:26:22 ar archive, of course :) Oct 27 16:26:52 haha Oct 27 16:27:03 I think stupid libtool is searching in the system for libs Oct 27 16:27:20 And this is why libiptc fails Oct 27 16:34:14 -L/usr/lib -lip4tc -lip6tc Oct 27 16:34:15 See this? Oct 27 16:34:22 I want to stab it Oct 27 16:37:21 mb__: this is a perfect heisenbug, I was never able to reproduce it Oct 27 16:37:47 once a buildbot had it, set up the same debian version in a vm with the same package list and couldn't reproduce it Oct 27 16:37:55 have fun Oct 27 16:39:31 I think its rpath related Oct 27 16:46:33 I'm pretty sure this is a libtool bug Oct 27 16:49:00 what else? ;) Oct 27 16:54:36 And you're right. It is related to rpath Oct 27 16:55:51 do we specify rpath-link ? Oct 27 16:56:02 if yes it should override rpath Oct 27 16:56:34 at least in my limited understanding, libtool with its infinite wisdom may know better Oct 27 16:57:43 Yeah, well. The problem, as far as I can see, is that libtool fails to properly pass the -rpath stuff to the compiler. Oct 27 16:58:21 hm Oct 27 17:00:17 http://wiki.debian.org/RpathIssue Oct 27 17:04:58 well that is debian politics Oct 27 17:05:06 or do you mean the workaround presented there? Oct 27 17:06:44 Yeah well ignore that Oct 27 17:06:59 I think that the path could actually be added by our libtool_fixup_libdir Oct 27 17:09:34 or well, it fails to fixup it properly... Oct 27 17:19:18 I think something weird happens that prevents this fixup to run Oct 27 17:31:50 ah I got it. The problem is that the broken libtool call happens before the fixup was run. Oct 27 17:37:34 build #16 of au1000 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/16 Oct 27 17:47:57 jow * r23678 /packages/net/kismet/Makefile: [packages] kismet: force linking against libnl-tiny (#8138) Oct 27 17:50:45 jow * r23679 /trunk/package/madwifi/files/lib/wifi/madwifi.sh: [package] madwifi: fix syntax error introduced by r23660 Oct 27 17:51:25 jow * r23680 /branches/backfire/package/madwifi/files/lib/wifi/madwifi.sh: [backfire] merge r23679 Oct 27 18:11:31 build #20 of ar71xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ar71xx/builds/20 Oct 27 18:13:02 cannot stat `libiptc/.libs/libiptc.so.0.0.0T': No such file or directory Oct 27 18:13:03 T Oct 27 18:13:08 TTTTTTTTT hell Oct 27 18:13:12 Why TTTTTTTTTT Oct 27 18:13:26 ? Oct 27 18:13:35 It says 0.0.0T <<<<<< Oct 27 18:13:38 Why T? Oct 27 18:14:00 That file doesn't exist, of course. But non-T does Oct 27 18:14:02 hm, bad sed expression? or bad tr Oct 27 18:17:05 No. It's libcrap Oct 27 18:20:18 I think I give up. I does not work Oct 27 18:20:30 This is the worst crap I saw ever Oct 27 18:20:49 this. Oct 27 18:22:55 It's so full of magic. It's basically impossible to find out what is going on without being the libtool author. Oct 27 18:23:43 build #20 of brcm63xx is complete: Failure [failed shell_4 compile_6] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/20 Oct 27 18:29:05 thepeople: There's the curl machine ;) Oct 27 18:40:46 mb__: the owner is not currently online, I am shutting down the bot til it gets fixed Oct 27 19:02:53 hell, it's also other packages that fail due to this libtool braindamage. Oct 27 19:10:06 * mb__ does make dirclean Oct 27 19:15:23 https://dev.openwrt.org/ticket/6580#comment:70 <- since there is the idea of a joint donation for buying a rt-n16 for openwrt, perhaps someone could take over the conversion to make sure the money/offer gets noticed Oct 27 19:16:14 glp: ^ Oct 27 19:16:58 there's a donate page in the trac wiki too Oct 27 19:18:10 xMff: yes Oct 27 19:18:33 KanjiMonster: ping me on the topic Oct 27 19:21:01 glp: I don't quite follow what you want me to do. Oct 27 19:21:49 KanjiMonster: did anybody make a specific donation yet, or is it going to happen? Oct 27 19:22:01 glp: ah, no, no donation yet. Oct 27 19:22:41 glp: just the idea of donating for it, and the offer of $20 Oct 27 19:22:46 KanjiMonster: when you get further, then send me an email and I'll help with the practical aspects Oct 27 19:23:04 glp: the donation wasn't my Idea ;) Oct 27 19:23:58 a (small) money donation would be best Oct 27 19:24:13 KanjiMonster: I'm just offering a way to ensure that it will be noticed in the "system" Oct 27 19:24:18 if one donates a device then thers always a certain obligation Oct 27 19:24:20 glp: ah, okay. Oct 27 19:24:50 we can then buy the hardware from the donated money and let it ship to a dev Oct 27 19:25:06 I'd pay 50-60 Eur Oct 27 19:25:09 too Oct 27 19:26:02 bah I read that crap... "Open Source WLAN Router" Oct 27 19:26:16 and then over 100 eur and broadcom inside Oct 27 19:26:48 Didn't Broadcom go open source on some 11n wlan chipsets? Oct 27 19:27:11 yeah but for stuff yet newer than whats in those router Oct 27 19:27:28 s Oct 27 19:31:54 xMff: the whole bcm4716/7/8 line is quite popular unfortunately Oct 27 19:34:08 glp: Should I tell him to just donate, or is there something he should do to somehow "mark" the donation? Oct 27 19:35:01 KanjiMonster: he can send me an email when the donation is made :-) Oct 27 19:35:08 okay Oct 27 19:42:33 xMff: So I did a dirclean and after that libtool works again. Oct 27 19:42:42 That is hell of a weird thing Oct 27 19:43:19 mb * r23681 /trunk/package/libtool/Makefile: libtool: Force nonparallel build. Oct 27 19:49:57 mb__: as I said, the perfect heisenbug Oct 27 19:50:57 The interesting thing is that is was 100% reproducible before doing dirclean Oct 27 19:53:45 I ordered an RT-N16 now Oct 27 19:53:58 lets hope I get some money back through donations :P Oct 27 20:03:00 xMff: cool you got an rt-n16 Oct 27 20:03:04 shame it's only single-band.. Oct 27 20:03:57 Hauke: not yet, but will arrive the next days. I will attempt some porting... I can send it to you if I don't get further Oct 27 20:04:22 xMff: great! Oct 27 20:04:45 xMff: there was done some part of the porting already Oct 27 20:04:52 there is something on the mailing list Oct 27 20:05:23 I will leave now bye Oct 27 20:05:29 ciao Oct 27 20:10:20 And while we are at it the topic, I still think the newer bcm47xx should probably get a subtarget, since they have mips 74kec cores instead of 4kec, which allow some additional optimizations (mips32r2, dsp r..2?) ;) Oct 27 20:10:22 [florian], got a dg834g v3 arriving in a few days so I can have a look at this mangling switch Oct 27 21:26:19 lars * r23682 /trunk/target/linux/kirkwood/patches/200-iconnect.patch: Oct 27 21:26:19 [kirkwood] Adds leds and gpio keys support for Iomega iConnect. Oct 27 21:26:19 Signed-off-by: Wojciech Dubowik Oct 27 21:28:18 lars * r23683 /trunk/package/uboot-kirkwood/files/ (3 files in 2 dirs): Oct 27 21:28:18 [uboot-kirkwood] Fixed support for Iomega Oct 27 21:28:18 * Added configuration file. Oct 27 21:28:18 * Set blue power led during bootup Oct 27 21:28:18 * enabled pci express Oct 27 21:28:19 Signed-off-by: Wojciech Dubowik Oct 27 21:43:55 mb * r23684 /packages/multimedia/minidlna/Makefile: minidlna: Disable parallel build due to broken internal deps Oct 27 22:09:27 [florian]: ping Oct 27 23:24:03 build #16 of ep93xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/16 Oct 28 00:52:58 build #18 of gemini is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/18 Oct 28 02:16:28 build #16 of mpc52xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/16 **** ENDING LOGGING AT Thu Oct 28 02:59:57 2010