**** BEGIN LOGGING AT Sun Jan 29 02:59:58 2012 Jan 29 04:19:29 build #121 of ps3 is complete: Failure [failed compile_6] Build details are at http://buildbot.openwrt.org:8010/builders/ps3/builds/121 Jan 29 09:26:53 jow_laptop: ping Jan 29 10:07:17 build #91 of mpc52xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/91 Jan 29 11:08:49 in build_dir/linux-3.1.9/drivers/net/wireless/ath/ath9k, should i expect the objects to build next to the source if i have the modules included in menuconfig? Jan 29 11:21:07 btsimonh: no, unless you modified the kernel config. ath9k will be usually built from build_dir/compat-wireless-/... Jan 29 11:21:38 sorry, build_dir/linux-/... Jan 29 11:22:08 :) thankyou, still working my way around the build tree... Jan 29 11:24:32 but (almost) everything else that isn't a wifi related you can expect in .../linux-3.1.9/... Jan 29 11:28:39 and so also make target/install won't build it? Jan 29 11:29:51 nope, you need to call package/mac80211/compile Jan 29 11:30:03 iirc Jan 29 11:30:52 iirc? Jan 29 11:31:49 if I recall correctly Jan 29 11:31:55 or remember Jan 29 11:34:33 a complete make has done it, as expected, but if i've asked it to make the modules part of the kernel, then would need to make package/..., then make target/.., probably quicker just to make. i'll see how I get on Jan 29 12:29:07 I want to select two packages, +kmod-usb-serial +kmod-usb-serial-option, but since the second depends on the first, my package is hidden until I manually select kmod-usb-serial Jan 29 12:29:13 any way to go around this? Jan 29 12:32:24 btsimonh: you mean part of the image? then a make package/.. and target/... won't be enough, you'll also need to call whatever recreates the rootfs, so a full make will be easier Jan 29 12:44:55 hi guys. i have installed kmod-block2mtd and "modprobe block2mtd block2mtd=/dev/sda1,65536" works fine. To get it inserted at boot, I added /etc/modules-boot.d/65-block2mtd with content "block2mtd", that works so far. Where would I place the module options? Adding it to that 65-block2mtd file caused block2mtd not to be loaded on bootup. Jan 29 13:24:18 jow * r29938 /branches/backfire/include/cmake.mk: [backfire] cmake: fix compiler paths after toolchain relocation (#10870) Jan 29 14:35:55 <[florian]> mbs_: right now there is no infrastructure for inserting module parameters on a per-module basis Jan 29 14:36:05 <[florian]> there has been some patches around to do that Jan 29 14:37:27 so i would need to make an init script to echo my parameters to /sys/modules/block2mtd/parameters/block2mtd , right? Jan 29 14:37:47 doing that manually works so far Jan 29 14:39:02 mbs_: /etc/modules-boot.d/ does not really sounds like openwrt Jan 29 14:39:48 mbs_: besides that the way to append parameters is writing them to the appropriate module file, e.g. echo "block2mtd block2mtd=/dev/sda1,65536" > /etc/modules.d/65-block2mtd Jan 29 14:40:21 mbs_: it wil lget transformed to "insmod block2mtd block2mtd=/dev/sda1,65536" Jan 29 14:40:44 if that fails during boot than maybe the deps aren't loaded yet Jan 29 14:41:04 jow: /etc/modules-boot.d is what my router offers, besides /etc/module.d Jan 29 14:41:43 mbs_: ah right, I believe it is for pivoting Jan 29 14:42:29 i tried exactly that line in 65-block2mtd, located in /etc/modules.d as well as in /etc/modules-boot.d, it didn't work Jan 29 14:42:39 right Jan 29 14:42:40 define didn't work Jan 29 14:42:45 not loaded? Jan 29 14:43:28 well, block2mtd just got loaded when 65-block2mtd was placed in modules-boot.d Jan 29 14:43:46 but adding the options caused it not to load Jan 29 14:44:13 nothing on dmesg| grep mtd which would have pointed to something Jan 29 14:44:47 and placing 65-block2mtd to modules.d didn't insert the module at all Jan 29 15:00:30 florian * r29939 /trunk/target/linux/au1000/ (6 files in 4 dirs): [au1000] add support for 3.2 kernel Jan 29 15:00:31 florian * r29940 /trunk/target/linux/generic/config-3.2: [kernel] add another 3.2 framebuffer symbol Jan 29 15:00:35 florian * r29941 /trunk/target/linux/ep93xx/ (6 files in 2 dirs): [ep93xx] add 3.2 support Jan 29 15:00:38 florian * r29942 /trunk/target/linux/ep93xx/profiles/ (. 00-default.mk 01-simone.mk): [ep93xx] add default and Sim.One profiles Jan 29 15:01:19 hauke * r29943 /branches/backfire/target/linux/brcm47xx/patches-2.6.32/180-fix-cardbus-in-hostmode.patch: Jan 29 15:01:19 brcm47xx: backport r29923 Jan 29 15:01:19 fix cardbus host controller Jan 29 15:01:27 ok, adding a line `echo "block2mtd block2mtd=/dev/sda1,65536" > /etc/modules.d/65-block2mtd` into /etc/rc.local somehow solved my issue so far Jan 29 15:02:22 uhh guys Jan 29 15:03:01 http://dpaste.com/694709/ Jan 29 15:03:09 i gue the feeling i'm missing something Jan 29 15:03:13 get* Jan 29 15:09:34 * Weedy pokes jow_laptop Jan 29 15:21:36 + /sbin/uci -P /var/state -q get firewall.core.wan_tcpmss Jan 29 15:21:36 + RET=0 Jan 29 15:21:36 + [ 0 -ne 0 ] Jan 29 15:21:36 + return 0 Jan 29 15:21:36 + [ 1 == 1 ] Jan 29 15:21:39 + fw add i m zone_wan_MSSFIX TCPMSS $ { -o pppoe-wan -p tcp --tcp-flags SYN,RST SYN --clamp-mss-to-pmtu } Jan 29 15:21:49 so why are you not in -vnL Jan 29 15:45:51 Weedy: no -t mangle given ? Jan 29 15:49:39 ahh there it is Jan 29 15:49:52 so why is my imgur still broken Jan 29 15:50:05 3.2.1 is iffy Jan 29 16:22:46 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html Jan 29 17:23:02 what is the difference between madwifi and ath9k? Jan 29 17:23:29 madwifi is old and unmaintained, ath5k is linux upstream Jan 29 17:23:41 ath9k Jan 29 17:23:49 also, madwifi doesn't support 802.11n hardware properly Jan 29 17:23:54 ath9k does Jan 29 17:33:11 so I have atheros AR5416 with devid ff1c, maybe AR5008? ath9k only supports 0023-0034? I added to table in ath9k/pci.c, and will wotk on eeprom. but Am I heading the right way? Is it common to find a chip with strange deviceID and have to patch this kind of thing up? Jan 29 17:36:15 usually this strange devid only shows up on devices that don't have an eeprom Jan 29 17:36:40 in the eeprom there's a section containing register writes that the card applies by itself on reset Jan 29 17:36:58 if the eeprom data is in flash, then the software can emulate this bootstrap sequence by applying the register writes itself Jan 29 17:37:02 the ar71xx platform code does that Jan 29 17:40:17 yes, the eeprom is in nand. I've read the nand into memory, now ath says 'no band has been marked as supported in eeprom', so eeprom passed initial tests :). Jan 29 17:41:46 ar71xx -> mips/ar7/ ? Jan 29 17:42:12 jow * r29944 /trunk/scripts/ext-toolchain.sh: [scripts] ext-toolchain.sh: support --wrap with src == dest Jan 29 17:43:01 jow * r29945 /trunk/scripts/patch-specs.sh: [scripts] patch-specs.sh: fallback to ext-toolchain.sh --wrap if spec file patching is not possible (gcc < 4.3.0) Jan 29 17:43:12 maybe there's an endian swapping issue somewhere Jan 29 17:44:36 eeprom should not pass magic with endian swap? Jan 29 17:46:51 well, the 'no band has been marked as supported in eeprom' is a sure sign that something is wrong Jan 29 17:46:55 ;) Jan 29 17:48:10 i'm wondering if they set the band from openrg in the original firmware. Not much open source on wireless aspects though :(. Where is ar71xx? can only find header... Jan 29 17:49:06 i've never seen a firmware or software that overrides the eeprom supported bands capability Jan 29 17:50:24 i'll need to work through the eprom binary and code :). or maybe the eeprom is in some old format not understood by ath9k... Jan 29 17:50:37 i don't think so Jan 29 17:50:49 the eeprom format typically stays the same for the chipset Jan 29 17:52:30 got to nip out; I'll work it though and ask more later :( I'm proud of my nand load though. But really need to read the mtd name rather than a fixed /dev/mtdx... Jan 29 18:08:28 build #115 of ppc44x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/115 Jan 29 18:53:14 jow * r29946 /trunk/scripts/ext-toolchain.sh: Jan 29 18:53:14 [scripts] ext-toolchain.sh: rework generated gcc wrapper Jan 29 18:53:14 Only append -L and -Wl,-rpath-link flags if the command line contains -l, -L, -shared or -static flags; Jan 29 18:53:14 this is needed to suppress "-rpath-link: linker input file unused because linking not done" on each cc invocation. Jan 29 19:28:13 jow * r29947 /trunk/scripts/download.pl: [scripts] download.pl: remove ftp.geo.kernel.org mirror, it does not resolve Jan 29 20:19:08 jow * r29948 /trunk/scripts/patch-specs.sh: [scripts] patch-specs.sh: gcc 3.4.6 has an additional "(OpenWrt-2.0)" after the version tag, cope with that Jan 29 20:21:48 jow * r29949 /branches/backfire/scripts/ (download.pl ext-toolchain.sh patch-specs.sh): [backfire] scripts: merge r29944 - r29948 Jan 29 20:22:59 jow * r29950 /branches/backfire/toolchain/gcc/patches/3.4.6/ (9 files): [backfire] toolchain: fix gcc 3.4.6 (brcm-2.4) after relocation from usr/, refresh patches while being at it Jan 29 21:27:00 build #121 of pxcab is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/121 Jan 29 22:45:36 out of ideas now. Have Atheros 9160-BC1A 802.11b/g/n, pci. Gives 168c:ff1c as PCI id. eeprom is in nand, and first few bytes include 16 8c 00 27 = 9160 Jan 29 22:47:06 I've loaded the eeprom data. but code looks in byte location 206, which is zero, and rejects the eeprom. i modded the code to say 'g compatible', and it runs up. Jan 29 22:47:37 nbd: ping Jan 29 22:47:42 philipp64|laptop: ponh Jan 29 22:47:44 pong Jan 29 22:48:08 but then after enabling the radio through luci, and setting to GB, all seems ok, except there is no wireless signal. Jan 29 22:51:15 nbd: I've given up on trying to get my platform drivers committed into Openwrt after 3 months of waiting, and just got them all into linux-next instead... so that's 3 patches we can kill... I just need the configs to go into Openwrt to support them. these patches don't affect other platforms than the ones I'm willing to take responsibility for... so it would be Jan 29 22:51:48 helpful for me to know if these are all the requirements (being satisfied) to get this commit done or if there are other considerations that I'm not aware of. Jan 29 22:52:25 what platform drivers? Jan 29 22:52:43 net5501, alix, and geos. they are all in 1795. Jan 29 22:53:32 3.3 supports geos. 3.4 (unless Andrew Morton works quickly) will support the alix2 and net5501 changes as well. Jan 29 22:54:53 my patches sit in the queue and I have no idea what I can do to make things go smoother for everyone involved, since I don't get much feedback either way. Jan 29 22:55:26 ok, i'm not sure adding config options to config-default for a version that's not the default in the makefile is a good idea Jan 29 22:55:35 since a simple make kernel_oldconfig will throw them away immediately Jan 29 22:56:31 ok, and that's the damed-if-I-do-and-damned-if-I-don't situation that's confusing. Jan 29 22:56:46 I was told I would have better luck if I just "upstreamed my drivers"... Jan 29 22:56:52 by whom? Jan 29 22:57:06 i mean, upstreaming your drivers is obviously a good approach Jan 29 22:57:22 but this does not have much to do with openwrt acceptance per se Jan 29 22:57:30 which I've done.. but now I'm stuck because x86 is forever in 2.6.39 because Kaloz has one platform that he hasn't had time to update. Jan 29 22:57:31 also, i'm not saying it's wrong to prepare for 3.3 Jan 29 22:58:08 first the generic patches need to be ported to 3.3 Jan 29 22:58:15 as well as the generic config Jan 29 22:58:35 sorry, which "generic patches" are we talking about? Jan 29 22:58:40 the generic openwrt patches Jan 29 22:58:44 if you want to test 3.3 Jan 29 22:58:55 ah. well, that's beyond my control. Jan 29 22:59:24 if you want to use your upstreamed drivers on older versions, you can also create backport patches Jan 29 22:59:32 locally I take *my* platform patches that have been submitted (and accepted) for 3.3 and build those against 3.2.1. Jan 29 22:59:39 and it works. Jan 29 22:59:50 ok Jan 29 22:59:54 you could copy config-default to config-3.2 Jan 29 22:59:55 and refresh it Jan 29 23:00:00 with make kernel_oldconfig Jan 29 23:00:03 and enable your drivers there Jan 29 23:00:12 so in 6 months from now (ducks) when my patches are finally accepted, and 3.3 comes out... the stars will finally be in alignment. Jan 29 23:00:27 (after you've made the backport patches) Jan 29 23:00:45 you can do that without enabling 3.2 by default, and that way the config changes could go in Jan 29 23:01:02 and what do those steps do? Jan 29 23:01:10 I mean, what's the goal? Jan 29 23:01:29 the goal is to keep the delta between your local changes and openwrt down to simply changing the kernel version in the makefile Jan 29 23:01:38 we could even change the kernel version for the subtargets that you're using Jan 29 23:01:42 assuming that kaloz has no claim on them Jan 29 23:02:12 ok, but most of those changes are ones that I've been trying to get in since 3.0 came out... so they're not specific to my drivers. Jan 29 23:03:44 the amount of changes to support my drivers is actually less than 10% of the total diff. Jan 29 23:03:56 also, logical separation of changes is a good idea Jan 29 23:04:28 yeah, I tried that too. my patches just sit in the queue. Jan 29 23:05:03 whatever approach I take, someone has a reason why it doesn't work for them. Jan 29 23:05:15 it would be nice to have a strict acceptance list that I could shoot for. Jan 29 23:05:47 also, why did you add ocf-crypto-headers to the default package list? Jan 29 23:05:58 it doesn't even generate an .ipk file Jan 29 23:07:03 because without it, the kmod-crypto-ocf won't build. it's a requirement. Jan 29 23:07:37 that doesn't make any sense Jan 29 23:07:49 and without kmod-crypto-ocf, application space programs can't use hardware acceleration for 3des, sha1/2, and aes128. Jan 29 23:08:03 kmod-crypto-ocf is built from the kernel tree Jan 29 23:08:22 and it has no ties to the staging dir, which is where ocf-crypto-headers installs its header file Jan 29 23:08:47 I'm not adding ocf-crypto-headers now... that's not in my new patch. Jan 29 23:08:49 also, it does not make sense to explicitly enable something that is *only* meant to be used as a dependency for other stuff Jan 29 23:08:54 that's already there. Jan 29 23:09:16 which new patch? Jan 29 23:09:20 i'm looking at 1795 Jan 29 23:10:34 net5501 as a config was thin and untested. I took the config from alix2 which is known to work and used that as a starting point. Jan 29 23:11:05 ok. if there's crap in an existing makefile that you copy from, don't carry it over Jan 29 23:11:13 instead, get rid of it at the source Jan 29 23:11:21 other than net5501 having a PCI slot and alix2 having a mini-PCI slot, they are almost identical designs. Jan 29 23:11:35 there's some other crap that could be cleaned up Jan 29 23:11:35 e.g. Jan 29 23:11:35 NET5501_GPIO = $(if $(findstring 2.6.32,$(LINUX_VERSION)),gpio-cs5535,gpio-cs5535-new) Jan 29 23:11:47 2.6.32 is not the default, nor will it ever be again Jan 29 23:11:51 for x86 Jan 29 23:11:54 so this part is obsolete Jan 29 23:12:01 and I'll get rid of them when 2.6.39 gets retired. Jan 29 23:12:10 but 3.0 had a bunch of drivers be renamed. Jan 29 23:12:32 btw. it might be easier for you if you start using git Jan 29 23:12:36 what's called gpio-cs5535 in 2.6.39 is actually different *SOURCE* code than what builds that driver in 3.0. Jan 29 23:12:40 because then you can maintain your changes on top of the openwrt tree, rebase them Jan 29 23:12:46 and send them as a patch series with git-send-email Jan 29 23:12:49 anyway, you said break up the patches into logical bits. Jan 29 23:12:54 that's what I'm trying to do. Jan 29 23:13:04 I'm trying to support 3.3 functionality. Jan 29 23:13:20 ok, there's no point in adding 3.3 stuff to the x86 target, when the generic stuff isn't even in yet Jan 29 23:13:25 I'm not trying to do a fix-everything-that-might-be-wrong-and-deprecate-old-drivers all at once. Jan 29 23:13:37 right Jan 29 23:13:54 but don't carry over obsolete code via copy&paste Jan 29 23:14:13 except for the handful of people that have told me they're pulling my patches directly from the LKML and building OpenWRT that way. Jan 29 23:14:45 I don't know what to say. If I make too many changes, then it's risky and possibly destabilizing and harder to test. Jan 29 23:15:11 if I pare it down to a single objective, then I have to defend why I didn't fix everyting else that's wrong with the platform. Jan 29 23:15:20 i realize that the patch submission process has been somewhat frustrating for you, mostly because nobody of the core devs properly takes care of the x86 target Jan 29 23:15:24 so let's work on fixing this Jan 29 23:15:25 maybe it's just easier to give up. Jan 29 23:15:43 you don't have to fix everything that's wrong with the platform Jan 29 23:16:10 when we deprecate 2.6.39, then that will be a good time to make the gpio-cs535 driver go away. Jan 29 23:16:37 it's worth noting that 2.6.39 is the last version that the ath5k driver doesn't crash on bootup when used with the LED drivers. Jan 29 23:16:41 i said the check doesn't make sense because the version check refers to 2.6.32, not 2.6.39 Jan 29 23:17:02 so no need to rip it out in existing code if you don't want to make too many changes at once Jan 29 23:17:13 but don't copy&paste it into other code where you are making changes Jan 29 23:17:28 like I said, I took the alix2 driver and copied it over, and made 3 minor changes. Jan 29 23:17:43 the GPIO mask changed, and a couple of other minor things. Jan 29 23:17:59 i know that Jan 29 23:18:12 my point still stands Jan 29 23:18:13 ;) Jan 29 23:18:16 can't the gpiomask value be passed from grub? Jan 29 23:18:33 and if I knew that my patch would be accepted in a timely way, I'd already have submitted a 2nd one to deprecate the GPIO stuff! Jan 29 23:19:03 but as it is now, I have no faith that *any* of my patches will be accepted, so I've narrowed it down to one which I'm really, really hoping will be accepted. Jan 29 23:19:12 so how about making a workflow for you where maintaining a few patches locally and occasionally re-sending them takes very little effort? Jan 29 23:19:33 git does make this very easy Jan 29 23:19:34 I don't know what that means. Jan 29 23:19:50 I've had to update my geos driver from 2.6.39 to 3.0 to 3.1 to 3.2 to 3.3... Jan 29 23:20:19 there is no "easy workflow" when you have to keep retooling your patches to keep them current when they sit in the queue for 5 months. Jan 29 23:20:20 i'm not talking about using git for kernel stuff here, i'm talking about making your openwrt checkout with git Jan 29 23:20:46 what you don't know about me is this. Jan 29 23:21:32 I contribute patches to wpa_supplicant, firefox, thunderbird, gcc, binutils, fedora, mimedefang, spamassassin, postfix, sendmail, Perl/CPAN, etc. Jan 29 23:21:55 I work daily with svn, cvs, rcs, hg, git, p4.... Jan 29 23:22:09 clearcare, source depot... Jan 29 23:22:13 *clearcase. Jan 29 23:22:30 I don't have time to become an expert in 8 different types of SCM. Jan 29 23:23:08 you don't have to be an expert Jan 29 23:23:17 when I have to jump through too many hoops (over over hurdles, your pick) it stops being worth the trouble. Jan 29 23:23:40 well, i'm not talking about complicated stuff here Jan 29 23:23:44 ah, but I do... because otherwise I get told my patches can't be accepted because I didn't order them correctly. Jan 29 23:23:54 there have obviously been some misunderstandings in the past Jan 29 23:24:10 because several people have told you different things and you built up various assumptions based on that Jan 29 23:24:26 I learned recently that when I submit linux kernel patches, I have to do a separate "git checkout -b " so that there's no implied ordering. Jan 29 23:24:55 I don't need to do that for CVS or SVN or HG or RCS... Jan 29 23:25:22 as long as the patches don't overlap the same regions in the same files, they can be applied in different order. Jan 29 23:25:34 only GIT implies ordering. who knew? Jan 29 23:25:40 huh? that sounds weird to me Jan 29 23:25:43 not me. because I don't work in linux kernel all day. Jan 29 23:25:47 why create one branch per patch? Jan 29 23:25:53 when you can just have one branch containing all of your work Jan 29 23:25:56 well, that's was Andres Salomon told me. Jan 29 23:26:21 look on the platform-x86-driver mailing list. Jan 29 23:27:03 so everyone has their own favorite set of criteria which the "amateur" (which I freely admit I am) has to have memorized or your work won't be accepted. Jan 29 23:27:18 it's a pretty daunting level to set the bar at. Jan 29 23:27:33 actually, submitting patches to openwrt (on an SCM usage level) can be done pretty much in the same way as submitting patches to the kernel Jan 29 23:27:58 except that I don't have a branch that you can pull from. :-) Jan 29 23:27:58 there's a semi-official git tree on my server (which all the openwrt git users use) Jan 29 23:28:08 git://nbd.name/openwrt.git Jan 29 23:28:58 this tree is also mentioned on dev.openwrt.org Jan 29 23:29:03 under GetSource Jan 29 23:29:11 I'd love to have time to fix the led issue with ath5k but all of my time is spent having to forward-port patches which languish, etc. Jan 29 23:29:22 or else reading tutorials on N different SCM's. Jan 29 23:30:04 ok, we're getting off piste... Jan 29 23:30:36 what do I need to do to support the geos, alix2, and net5501 platforms in Openwrt? let's start with that. Jan 29 23:31:01 i could describe to you the process that i use for maintaining my patches against linux-wireless, because you could use the same process for maintaining your patches against openwrt Jan 29 23:31:29 since it requires very little effort to maintain a whole list of changes, forward-port them and send them Jan 29 23:31:52 without having to constantly run diff commands manually and copy&paste changelog info and crap like that Jan 29 23:32:37 anyway, to answer one of your questions: kmod-crypto-ocf depends on OPENSSL_ENGINE. Jan 29 23:33:10 OPENSSL_ENGINE depends on ocf-crypto-headers Jan 29 23:34:01 no, it doesn't Jan 29 23:34:09 not as a menuconfig dependency Jan 29 23:34:18 openssl has a build dependency on ocf-crypto-headers Jan 29 23:34:26 jow * r29951 /trunk/rules.mk: [buildroot] rules.mk: filter "." and "./" entries from $PATH, prevents toolchain build issues and likely other problems Jan 29 23:34:38 which means that regardless of what you do in your platform defaults, ocf-crypto-headers is always going to be built before openssl Jan 29 23:34:44 no matter if it's selected or not Jan 29 23:34:53 meaning, you don't have to explicitly enable it either way Jan 29 23:35:58 jow * r29952 /branches/backfire/rules.mk: [backfire] rules.mk: merge r29951 Jan 29 23:36:05 well, I tried building it a year ago and it wouldn't build without that. Jan 29 23:36:15 maybe there's a dependency issue that's been fixed in the meantime. Jan 29 23:36:21 but let me ask again, since maintaining logically separated patches and sending them when using an svn checkout is annoying as hell, do you want me to show you some very easy steps to avoid that frustration, even when you have to keep some changes around for a while? Jan 29 23:36:34 could save you some trouble Jan 29 23:37:15 is it a sure fire path to getting my patches accepted? because right now I'm focused on that. Jan 29 23:37:25 it will make it a lot easier Jan 29 23:37:38 I'll circle back around to "nice to have" when my patches aren't sitting around for 3 months. Jan 29 23:38:20 the idea behind this is, if somebody asks you to make a minor change, resending the patches only takes a minute with few commands Jan 29 23:38:27 instead of having to constantly redo the same work over and over again Jan 29 23:38:36 i think that's more than just a nice-to-have Jan 29 23:39:19 right now it only takes me a few minutes anyway. I revert the commit, reapply it, apply the additional changes, and then make a new diff. Jan 29 23:39:42 what would make my life *much* easier is this: Jan 29 23:39:59 I send in a patch, and it works when I submit it, but it sits around for 3 months. Jan 29 23:40:02 yeah, and with the workflow that i'm using for kernel patches, you can maintain a stack of several patches and resend them with one command Jan 29 23:40:14 and you can even edit any one of those patches effortlessly Jan 29 23:40:16 in the mean time, 3.x is no longer the latest version, it's now 3.x + 0.1. Jan 29 23:40:33 and whenever you want to update to a newer version of openwrt, it's just one simple git fetch; git rebase origin/master Jan 29 23:40:35 so I'm told my patch is no longer acceptable because it no longer works with HEAD. Jan 29 23:40:38 instead of having to manually mess with local changes Jan 29 23:41:36 so I asked you if this was a guarantee that my patches would get in, and your answer was "no, it will just make my life easier". Jan 29 23:41:45 i didn't say no Jan 29 23:41:56 but that in combination with a few other things will get your patches in Jan 29 23:42:05 from my perspective, I'm just watching the goal posts recede towards the horizon... Jan 29 23:42:39 the thing is, i think i have a pretty good idea why maintaining your changes locally is so frustrating for you Jan 29 23:42:40 and "a few other things" depends who I'm talking to, and seemingly gets longer every time I ask. Jan 29 23:42:47 not having the patches in the tree isn't the only problem Jan 29 23:42:59 but maintaining them the way i assume you do is a big part of the problem Jan 29 23:43:02 since it's annoying Jan 29 23:43:17 it's frustrating for one simple reason: even when I think that I've done what everyone has asked of me, they still sit around. Jan 29 23:43:34 if I ask a lot to have them committed (before they get stale), I'm told I'm pushy. Jan 29 23:43:51 if I try not to be pushy, then they get ignored and become stale over time. Jan 29 23:44:01 there's no winning course of action here. Jan 29 23:44:02 yeah, but you're treating everything people tell you like it's coming from exactly the same source Jan 29 23:44:55 well, as far as I can tell, there's a "big 3" that tend to make 90% of the major changes to OpenWRT infrastructure: Jo-Philipp, yourself, and Florian. Jan 29 23:45:12 yeah, and even among us three there are different views, different ways to get things done Jan 29 23:45:20 and different ideas on how to achieve this Jan 29 23:45:23 I take it as faith that the 3 of you have at least agreed on the canonical requirements of what is needed. Jan 29 23:45:46 there are different ways of doing stuff Jan 29 23:45:51 then nothing I do can fix your internal disagreements, and it's not even worth trying. Jan 29 23:46:01 *I can do will fix Jan 29 23:46:17 you can't get it fixed because you're locked onto the wrong problem Jan 29 23:46:24 there's an expression in English: "not knowing what foot to dance on". Jan 29 23:46:33 that's how I feel 90% of the time. Jan 29 23:46:33 you don't need to fix 'disagreements' in the way we do things Jan 29 23:46:44 you also don't need to everything that everybody tells you Jan 29 23:47:11 if it were that simple, then the 3 of you would have agreed on the minimal set of requirements... Jan 29 23:47:13 right? Jan 29 23:48:06 well, whenever i tell you things to get you closer to having your patches merged, you say you tried that and act like because the patches weren't accepted that was the wrong thing to do Jan 29 23:48:10 what contributors want to hear is: "fix (a), (b), and (c) and we'll accept your patch" Jan 29 23:48:25 they don't want to hear, "you could have better process at your end, try this..." Jan 29 23:48:38 I mean, if they asked, they might want to hear that... Jan 29 23:49:04 but what they want to hear first and foremost is a go/no-go appraisal. Jan 29 23:49:46 well, much earlier in this discussion i gave you a list of things to do Jan 29 23:49:58 you told me that if I copy config-default to config-3.2 and work with that, it would make testing easier. Jan 29 23:50:00 and if you do those, i can probably take your patches without much discussion Jan 29 23:50:17 you told me that working in git instead of svn might make things easier. Jan 29 23:50:18 depending on what the result of making those changes looks like Jan 29 23:50:38 let me reiterate Jan 29 23:50:47 you told me that my patches should be logically separated, but by the way there's some old cruft relating to 2.6.32 in my patch. Jan 29 23:50:48 yes, copy config-default to config-3.2 if you want to use 3.2 + your backports Jan 29 23:50:54 and logically separated patches Jan 29 23:51:03 and not copy&pasting old 2.6.32 related stuff Jan 29 23:51:48 what I don't understand is this: can we get geos and net5501 and alix supported in 3.3, and then circle back and clean up the obsolete stuff? Jan 29 23:52:17 working in git instead of svn is just a way for you to be able to resend a patch series instead of a single patch (also making it easier for us to accept the changes), without having to do manual local diff hackery Jan 29 23:52:20 the 2.6.32 doesn't stop 3.2 or 3.3 from working. Jan 29 23:52:31 blocking on the 2.6.32 cleanup however does. Jan 29 23:52:37 I'm trying to prioritize here. Jan 29 23:53:29 you're asking me to invest more time and effort into how I work with Openwrt without any reason to do so. Jan 29 23:53:33 well, the goal is to have a series of small easy to review patches Jan 29 23:53:43 that don't mash together a variety of different things in one patch Jan 29 23:53:54 if my patches were actually going in, then it would make sense for me to try to increase my velocity. Jan 29 23:53:54 and to have those patches not add more obsolete stuff Jan 29 23:54:07 when I'm at a standstill, however, that approach makes a lot less sense. Jan 29 23:54:27 small easy to review patches are equally likely to sit in the queue. Jan 29 23:54:30 trust me on that. Jan 29 23:55:06 I had 3 separate patches that each clean up their respective platforms, and those didn't go in either. Jan 29 23:55:22 yeah, the thing is, i don't usually go through patchwork often Jan 29 23:55:33 unless patches show up that interest me, or i decide to take on specific patches Jan 29 23:55:57 ok, so again I can make a whole lot of changes to how I work... Jan 29 23:56:23 but if the main blockers are (1) people seldom review patchwork and (2) no one much gives a damn about x86... Jan 29 23:56:45 then it's definitely a proposition of diminishing returns for me to spend a lot of effort changing the ways that I work. Jan 29 23:57:02 so right now i don't really know what you want from me. i'm usually fairly busy with my own stuff. i offer to tell you how you can change your patches so that i can get them in easily without much discussion Jan 29 23:57:03 it's a fairly significant learning curve involved. Jan 29 23:57:15 and you tell me you don't want to make changes because you've invested too much already Jan 29 23:57:29 no, you've told me how I *might* get them in. Jan 29 23:57:47 there's been no explicit commitment. Jan 29 23:58:15 ah, ok, so you need something more explicit there Jan 29 23:58:25 what I find is I go back and make some changes, but then the original person who asked for the changes isn't around or is busy, so I ask person B, and he comes up with a whole new set of changes to make. Jan 29 23:58:33 so if you submit a patch series matching the things that i described to you and i have no futher objections, i will commit your patches Jan 29 23:59:08 you can decide whether you want to use git or not, but i'm pretty sure it'd make your life easier when dealing with multiple pending patches Jan 29 23:59:22 is that enough commitment for you? Jan 29 23:59:35 see, there we go "it would" (as in it might), not "it will". :-) Jan 29 23:59:41 lack of determinism. Jan 29 23:59:59 huh? Jan 30 00:00:06 never mind. semantics. Jan 30 00:00:32 i don't usually think in terms of 'will' or 'won't'. i think in probabilities Jan 30 00:01:05 yeah, me to. "unlikely" and "extremely unlikely". ;-) Jan 30 00:01:08 i usually don't subscribe to the black-and-white type of mindset Jan 30 00:01:45 so I need to branch from git://nbd.name/openwrt.git... Jan 30 00:01:58 yeah, you can do that Jan 30 00:02:06 and I need to submit patches that support which releases? Jan 30 00:02:09 btw. with commitment i wasn't talking about the sentence mentioning git Jan 30 00:02:20 i was talking about "so if you submit a patch series matching the things that i described to you and i have no futher objections, i will commit your patches" Jan 30 00:02:24 because Kaloz seems to be permanently anchoring x86 to 2.6.39... Jan 30 00:02:31 not sure what I can do to fix that... Jan 30 00:02:51 as i said earlier, a subtarget can override the kernel version Jan 30 00:03:40 so x86 default can be 2.6.39 and net5501 can be 3.2 Jan 30 00:03:54 as long as the x86 target supports 3.2 by having a proper config file for that Jan 30 00:04:18 does config-3.2 even work in x86/ ? I didn't think it did. Jan 30 00:04:35 whereever there's a config-default, there can be a config- as well Jan 30 00:04:38 in any case, the changes I made to config-default work for 2.6.39, 3.0, 3.1, and 3.2. Jan 30 00:05:16 except that if you add stuff that is only recognized by one kernel version, running kernel_menuconfig or kernel_oldconfig in another version will nuke those changes Jan 30 00:05:37 I think it would be less work you me, you, Jo, and Florian if x86 could keep up with linux HEAD, by the way. Jan 30 00:05:48 despite having ath5k be broken. Jan 30 00:06:09 yeah, but running HEAD is not good for a production system Jan 30 00:06:10 ;) Jan 30 00:06:11 sorry, don't follow... Jan 30 00:06:24 fine, LATEST or STABLE. Jan 30 00:06:32 if I add: Jan 30 00:06:35 treat config-default or config- as a generated file Jan 30 00:06:46 # CONFIG_SOME_OPTION_ONLY_IN_3_2 is not set Jan 30 00:06:50 how is that a problem? Jan 30 00:07:07 generated from... where? Jan 30 00:07:08 if somebody using 2.6.39 runs make kernel_menuconfig and changes stuff, it will throw away this line Jan 30 00:07:34 ok... so what if it does? why is this a problem? Jan 30 00:07:55 because you're adding surprises for people that use a standard openwrt workflow for changing the kernel config Jan 30 00:08:31 developers expect that they can make a change to the kernel config using make kernel_menuconfig and just commit that Jan 30 00:08:37 without throwing away other people's changes Jan 30 00:09:21 I'm entirely confused. let's look at r28599. Jan 30 00:09:56 ok, but then config-default would be from the very first linux version ever... Jan 30 00:10:15 and config-2.9.39 would be everything added since... Jan 30 00:10:33 no, config-default always refers to the default version Jan 30 00:10:41 and config-3.0 would be everything from config-2.6.39 *plus* everything added since that... Jan 30 00:10:44 so whatever version is mentioned in the makefile Jan 30 00:11:01 at least that's the way it's supposed to work Jan 30 00:11:21 it's possible to have one file cover multiple versions, but don't want that, for reasons i mentioned above Jan 30 00:11:43 s/don't want that/I don't want that/ Jan 30 00:11:46 I'm just trying to have x86 keep up with the same versions everyone else is using. Jan 30 00:11:55 usually I had the impression that config-defaults gets dropped anyway when versioned configs occur Jan 30 00:11:58 don't want to be the red-headed stepchild, after all. Jan 30 00:12:05 x86 is unpopular enough as it is. Jan 30 00:12:13 so -default gets forked into -2.6.39 and -3.0 Jan 30 00:12:36 yeah, that can work too Jan 30 00:12:39 i don't mind either way Jan 30 00:12:45 as long as one config is not shared across multiple versions Jan 30 00:12:50 ok, so I need to add a config-3.2... that said, the config-default for 2.6.39 was wrong too. Jan 30 00:13:02 wrong? Jan 30 00:13:33 nvm. Jan 30 00:14:40 for the record, x86 has never had *any* versioned configs, so I was hesitant to do anything that makes things more complicated. Jan 30 00:14:49 or more of a maintenance headache. Jan 30 00:15:25 yeah, it's got a lot of explicit processor features that get defaulted on when you select the correct processor. Jan 30 00:15:42 the reason is that net5501 was originally building from a generic X86 processor. Jan 30 00:16:48 when "CONFIG_MGEODE_LX=y" got added, a lot of those explicit options became redundant. Jan 30 00:17:25 +1 for versioned config Jan 30 00:17:53 so you wanted to talk about r28599 Jan 30 00:18:05 nbd: do you still have 1795 up? Jan 30 00:18:09 yes Jan 30 00:18:19 if you look at net5501/config-default... Jan 30 00:18:42 ALL of those changes *except* CONFIG_NET5501=y are needed to correct config-default *for all versions*. Jan 30 00:19:11 supporting 3.3 and the net5501 driver would only require 1 additional line be added to config-3.2 Jan 30 00:19:36 if I submitting TWO patches, the 2nd one which only added 1 new file and one line in that 1 file... Jan 30 00:19:58 it's hard to see anyone looking at that and think, "why of course, that makes perfect sense, let me commit it right away". Jan 30 00:20:35 if you update net5501 to 3.2, it doesn't need to have a config-3.2 there Jan 30 00:20:40 so I can split it into 2 commits... or actually 6 commits, since there are 3 platforms involved... Jan 30 00:20:55 only the x86 target dir needs a config-3.2 then Jan 30 00:21:14 but then I see it as the probably of of my patches going in as 1/10**n for any given number of n patches outstanding. ;-) Jan 30 00:21:22 apart from that stuff like config files isn't the hold up, at least not for me. I rather see changes like "br2684ctl" and "bridge" in default packages and wonder why they're in there Jan 30 00:21:42 philipp64|laptop: your probability calculation is wrong Jan 30 00:22:00 because the naive view that it only depends on the number of patches has nothing to do with reality Jan 30 00:22:07 no, because you don't want CONFIG_NET5501=y being turned on except for the x86/net5501/ target. Jan 30 00:22:16 so? Jan 30 00:22:53 jow_laptop: br2684ctl is there because a dsl driver is there Jan 30 00:22:56 naive? if you rarely go through patchwork, then what's the probability you'll go through it if it's twice as long? or 3 times as long? Jan 30 00:23:19 I'm just trying to be realistic and not add to your burden disproportionately. Jan 30 00:23:27 nb but it does not exist anymore Jan 30 00:23:33 philipp64|laptop: if you're able to send patches as a series rather than spread as individual patches, that makes it a lot easier for me Jan 30 00:23:40 I know that if I have a list of 10 patches to review, I'm more like to do it than 30. Jan 30 00:23:45 because if they're properly formatted, i can export the whole patch series thread to an mbox file and run git-am on it Jan 30 00:23:46 *nbd: ^ Jan 30 00:23:52 without having to pick them apart manually Jan 30 00:24:10 oh nvm, it was folded into linux-atm while keeping the name Jan 30 00:24:20 ok, not sure what the distinction is.. we're still talking about using patchwork as the submission mechanism, right? Jan 30 00:24:31 patchwork is for tracking patches Jan 30 00:24:33 and there's still the requirement that the patches be logically separated... Jan 30 00:24:38 i actually grab the patches using my email client Jan 30 00:25:15 and since i have lots of stuff to do besides occasionally accepting patches, i'm more inclined to merge patches which require the smallest amound of work on my part Jan 30 00:25:25 and git is good at generating such patches Jan 30 00:25:29 jow_laptop: bridge and br2684ctl are in there because the geos contains on-board DSL. Jan 30 00:25:46 no need to specify bridge Jan 30 00:25:50 it's part of the default package set Jan 30 00:25:59 openwrt uses bridging on almost all targets Jan 30 00:26:17 br2684ctl is fine Jan 30 00:26:58 why kmod-ledtrig-netfilter ? Jan 30 00:27:07 ok, wasn't sure about "bridge". Jan 30 00:27:21 whats the deal with those reboot -f handlers for the reset button? Jan 30 00:27:25 I see people committing libx264 and qt to Openwrt, and I think... "what the fuck?" Jan 30 00:27:43 and then I'm told that they're running Openwrt on kindle and fire... Jan 30 00:28:02 then I think, maybe bridging isn't on by default for all platforms... Jan 30 00:28:07 the geos system config should get a ntp config as well, the rdate section should be removed Jan 30 00:28:35 is that something new? Jan 30 00:28:50 no Jan 30 00:29:19 just compare target/linux/x86/geos/base-files/etc/config/system with target/linux/x86/net5501/base-files/etc/config/system in your patch Jan 30 00:31:51 ok, patched. Jan 30 00:32:14 btw... how do I make sure that config-default is canonical for the current version? Jan 30 00:32:32 because it seems to me that different versions reorder symbols, etc. Jan 30 00:32:44 so version bumps shouldn't cause pointless churn, right? Jan 30 00:33:01 the config-default vs config- thing works like this Jan 30 00:33:19 for every folder that the build system picks up a config file from, it first checks if there's a config- Jan 30 00:33:27 if there is one, it uses it, if not, it falls back to config-default Jan 30 00:33:40 also symbol ordering is LC_ALL=C sort Jan 30 00:33:58 or rather perl sort which should be the same to LC_ALL=C sort Jan 30 00:34:28 ah... so it doesn't take the union of config-default + config-3.2... Jan 30 00:34:35 correct Jan 30 00:34:35 right Jan 30 00:34:52 that's a pain. Jan 30 00:35:06 why? Jan 30 00:35:09 because the longer x86 stays stuck at 2.6.39... the more files I have to backpatch. Jan 30 00:35:43 * nbd repeats Jan 30 00:35:55 you can upgrade the net5501 target to 3.2 Jan 30 00:35:59 and leave the rest at 2.6.39 Jan 30 00:36:02 why not make 3.2.1 the default for x86, and have Kaloz set 2.6.39.4 for ep89031 (or whatever)? Jan 30 00:36:21 except that alix2, net5501, and geos are ALL coming out on 3.2 or 3.3. Jan 30 00:36:47 the idea is for now to upgrade only those subtargets that you actually test Jan 30 00:36:54 and leave the rest alone Jan 30 00:37:02 because you then need to test kvm, net48xx, old wrap boards Jan 30 00:37:05 and I've been dinged for submitting patches that didn't cover all of the outstanding versions... Jan 30 00:37:16 isn't that right, Jo? :-P Jan 30 00:37:29 and since you're not the maintainer of the x86 target (and neither am I), i want to keep effective changes local to only your subtargets Jan 30 00:37:39 the net48xx and wrap haven't been manufactured in 4 years. Jan 30 00:38:42 so if I fix all of the errors in the net5501 driver, I need to submit fixes for config-default (for 2.6.39), then fork it for config-3.0, config-3.1, config-3.2, and config-3.3 (if I want to be proactive)... Jan 30 00:38:57 is that correct? Jan 30 00:38:58 huh? Jan 30 00:38:59 target 3.3 or maybe 3.2 Jan 30 00:39:08 you can leave out 3.3 for now Jan 30 00:39:16 since the generic support hasn't been ported yet Jan 30 00:39:24 and no need to deal with 3.0 and 3.1 Jan 30 00:39:32 we don't do version upgrades one by one Jan 30 00:39:36 we pick a new version and jump to that Jan 30 00:39:51 not to polemic, but if I submit a patch *now*, it might be accepted in time for 3.3 to come out. Jan 30 00:40:11 and 3.3 is when the net5501 driver appears in-tree. Jan 30 00:40:25 well, i told you i will commit your patches if you do what i say Jan 30 00:40:43 that means they bypass the long delay of waiting for somebody to pick them up Jan 30 00:40:56 right... but Kaloz is the one that chooses the default version for x86, and since I don't know what he's planning, I have no idea what versions I can skip. Jan 30 00:41:13 wtf? Jan 30 00:41:24 already told you which versions are relevant and where Jan 30 00:41:50 I should be taking notes... Jan 30 00:41:58 or just scroll back and re-read Jan 30 00:42:13 actually the relevant info in this case probably didn't even need scrolling ;) Jan 30 00:42:58 I am... trying to figure out if the crypto-headers and gpio-cs5535 thing was a showstopper or not. Jan 30 00:43:18 also, I've never used the make kernel_oldconfig (or whatever) thing... Jan 30 00:44:01 the 2.6.32 test I wanted to fix, but in 3.0 there is only *one* gpio driver for the cs5535. Jan 30 00:44:18 you don't need the test Jan 30 00:44:21 remove it Jan 30 00:44:31 so at some point, when the oldest version of 3.0 that's supported for the x86... Jan 30 00:44:39 unconditionally use gpio-cs5535-new Jan 30 00:44:53 we can rename gpio-cs5535-new to just gpio-cs5535 and be done with it. Jan 30 00:45:05 actually we can, yes Jan 30 00:45:09 I want to clean ALL of that up. Jan 30 00:45:15 since we don't support .32 anymore Jan 30 00:45:16 just not all at once. Jan 30 00:46:52 what exactly does "make kernel_oldconfig" do again? so I know how to test my changes correctly? Jan 30 00:47:47 make kernel_oldconfig and make kernel_menuconfig are wrappers around the kernel's oldconfig and menuconfig targets Jan 30 00:48:03 the build system merges the generic + platform + subtarget config, runs the target Jan 30 00:48:04 so if I see it correctly the -new driver is state of the art since 2.6.38 ? Jan 30 00:48:06 then splits them again Jan 30 00:48:19 gpio-cs5535-new Jan 30 00:48:27 you can specify which config you want to edit by adding CONFIG_TARGET=platform or CONFIG_TARGET=subtarget Jan 30 00:48:30 to the command line Jan 30 00:48:50 build #102 of au1000 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/102 Jan 30 00:50:53 jow_laptop: 2.6.39 had the drivers/char/ and drivers/gpio/ versions for the cs5535 chip. Jan 30 00:51:03 in 3.0, the drivers/char version was killed. Jan 30 00:51:30 and the name changes in 3.0. Jan 30 00:51:49 isn't this stuff all out of scope for the current patch discussion? Jan 30 00:51:50 but drivers/gpio is usable with 2.6.39 ? Jan 30 00:52:24 the whole drivers/char vs drivers/gpio stuff can be cleaned up later Jan 30 00:52:29 err... in 3.1.0. Jan 30 00:52:39 true too Jan 30 00:52:45 ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,3.1.0)),1) Jan 30 00:52:47 FILES:=$(LINUX_DIR)/drivers/gpio/gpio-cs5535.ko Jan 30 00:52:49 AUTOLOAD:=$(call AutoLoad,50,gpio-cs5535) Jan 30 00:52:50 else Jan 30 00:52:52 FILES:=$(LINUX_DIR)/drivers/gpio/cs5535-gpio.ko Jan 30 00:52:53 philipp64|laptop: so as I said, unconditionally use gpio-cs5535-new Jan 30 00:52:54 AUTOLOAD:=$(call AutoLoad,50,cs5535-gpio) Jan 30 00:52:55 endif Jan 30 00:53:09 we rename all users of it once we rename it from -new Jan 30 00:53:24 right, but I want to rename it to just gpio-cs5535. Jan 30 00:53:26 I'm trying to avoid needless churn. Jan 30 00:53:33 yeah, but that's a separate patch anyway Jan 30 00:53:48 i thought you wanted to focus on getting your pending changes in first Jan 30 00:53:50 and this is why my head hurts. Jan 30 00:53:52 exactly, and one that mustn't necessarily be yours Jan 30 00:54:10 because all of this was fresh in my mind 3 months ago when I looked at it. Jan 30 00:54:18 and in the meantime, I've moved on. Jan 30 00:54:20 sigh. Jan 30 00:54:49 so is this a blocking change to my current patch? Jan 30 00:54:56 is what? Jan 30 00:55:14 +NET5501_GPIO = $(if $(findstring 2.6.32,$(LINUX_VERSION)),gpio-cs5535,gpio-cs5535-new) Jan 30 00:55:23 yes, that. Jan 30 00:55:38 well, since you're going to resubmit the patches anyway, you might as well change that in the process Jan 30 00:55:57 also, I don't think I can explicitly name the default version of linux to 3.2 for Geos, for instance. Jan 30 00:56:12 why not? Jan 30 00:56:49 this is a trick question, right? Jan 30 00:57:28 because there's an ordering issue that causes target/linux/x86/Makefile to be included *after* the target Makefile... Jan 30 00:58:21 the subtarget can override variables from the main target makefile Jan 30 00:58:27 I can't put LINUX_VERSION:=3.2.1 into x86/geos/target.mk. Jan 30 00:58:32 I already tried and it doesn't work. Jan 30 00:59:03 the build system does not pick up menuconfig-related changes when changing subtarget makefiles at the moment Jan 30 00:59:06 that's a bug that i want to fix soon Jan 30 00:59:14 so you may need to do touch Makefile in x86/ Jan 30 00:59:26 and then run make oldconfig or make menuconfig Jan 30 00:59:35 see if that changes the kernel version config selection Jan 30 01:00:20 shouldn't a rm -rf tmp/ also fix it? Jan 30 01:00:28 yes Jan 30 01:00:46 but a simple touch is enough Jan 30 01:05:57 ok, so running "make kernel_oldconfig"... do I need to comment out any changes to LINUX_VERSION to do that? Jan 30 01:06:20 so that "old" really does refer to the default version? Jan 30 01:07:44 huh? "old" doesn't refer to the kernel version here Jan 30 01:09:08 ok, then don't understand what "make kernel_oldconfig" does. is it documented in the wiki? Jan 30 01:09:12 nope... just looked. Jan 30 01:09:23 do you know what make oldconfig in a kernel tree does? Jan 30 01:09:29 no idea. Jan 30 01:09:47 never had to use it. Jan 30 01:09:51 asks for the config selection for any new option that isn't in .config yet Jan 30 01:09:54 just "menuconfig" and "defconfig". Jan 30 01:13:34 ok, so I just reset x86/Makefile to 2.6.39.4 (the default), and re-ran "make kernel_oldconfig". Jan 30 01:13:53 x85/config-default had a bunch of changes show up Jan 30 01:13:58 x86 rather. Jan 30 01:14:38 I'm falling into this rat-hole where I'm fixing all sorts of things that have nothing to do with net5501 + 3.2 Jan 30 01:15:07 so I have no idea how I'm supposed to make config-3.2 be a lambda of config-default if config-default isn't even correct for the default kernel version. Jan 30 01:17:25 what I get is this... http://fpaste.org/a2pM/ Jan 30 01:17:48 do I need to fix this first? is this a blocking commit? Jan 30 01:18:00 it's blocking for updating to 3.2 Jan 30 01:18:26 you can just copy config-default to config-3.2 Jan 30 01:19:01 and with 3.2 selected run make kernel_oldconfig CONFIG_TARGET=platform Jan 30 01:24:05 "make kernel_oldconfig CONFIG_TARGET=net5501 LINUX_VERSION=3.2.1" ? Jan 30 01:24:19 ok, just posted a patch. Jan 30 01:24:27 short, sweet, to the point. Jan 30 01:26:28 nbd: ok, so I need to versions, right? x86/config-3.2 and x86/net5501/config-3.2 ? Jan 30 01:26:36 that patch is wrong Jan 30 01:26:44 since it updates config-default while the default is still 2.6.39 Jan 30 01:26:46 no, wait... the patch I just sent is wrong because it's for the net5501... Jan 30 01:27:04 I need to deselect the CONFIG_TARGET... Jan 30 01:27:34 well, for 3.2 you first copy config-default to config-3.2 in the target folder and then run that make kernel_oldconfig line again Jan 30 01:27:46 then it'll update config-3.2 and not config-default Jan 30 01:27:58 so I need to fix x86/ before I can do anything with x86/net5501 is seems... plus get Imre to sign off on that. Jan 30 01:28:14 as long as it only adds config-3.2, it doesn't interfere with imre Jan 30 01:28:26 since for 2.6.39, nothing will change Jan 30 01:28:58 but the config-default is wrong (for 2.6.39). Jan 30 01:29:02 in x86/ Jan 30 01:29:21 it's got symbols for later kernels. Jan 30 01:29:24 but it works right now in 2.6.39 the way it is in svn, right? Jan 30 01:29:52 so the work on adding your target for 3.2 does not depend on cleaning up the older config Jan 30 01:30:01 ok, but you just told me that if someone runs "make kernel_oldconfig", it shouldn't have any surprises in the way of disappearing symbols, right? Jan 30 01:30:02 so i'd recommend that you don't touch the existing config-default for now Jan 30 01:30:13 well, there are disappearing symbols right now. Jan 30 01:30:24 yeah, but nothing else depends on them right now Jan 30 01:30:29 that's the important part Jan 30 01:30:57 i need some sleep now we can continue tomorrow Jan 30 01:34:11 x86/config-default to x86/net5501/config-3.2? Jan 30 01:34:32 yes Jan 30 01:35:56 shit. can't pass LINUX_VERSION via the command line. Jan 30 01:37:39 but I can put it in x86/net5501/target.mk Jan 30 01:38:32 so the fact that the base x86/config-default is wrong... that doesn't affect me? Jan 30 01:38:41 right Jan 30 01:42:03 no, that's not right... because now the x86/net5501/config-3.2 file is huge and it picked up a LOT of new symbols. Jan 30 01:42:19 many more than the delta between 2.6.39 and 3.2.... Jan 30 01:43:47 385 lines. Jan 30 01:46:14 that can't be right. Jan 30 01:47:00 and a bunch of drivers that I don't need got turned on. Jan 30 01:47:09 fuck it. Jan 30 01:47:41 I give up. Jan 30 01:48:20 from a correctly configured x86/config-default for 2.6.39.4, there should be fewer than 40 config changes for the net5501 Jan 30 01:51:17 kernel_oldconfig is not intelligent enough to distribute symbols between subtarget and target config Jan 30 01:51:37 it will lump all into the most specific one and leave it to the operator to move them around Jan 30 01:51:54 you can select which one you want to update Jan 30 01:54:38 philipp64|laptop: btw, 385 symbols compared to what? Jan 30 01:56:14 the config-default I had for x86/net5501/config-default was previously 24 lines. Jan 30 01:56:31 24 lines of deltas to apply to x86/config-default. Jan 30 01:56:54 extra symbols to turn off or turn on... Jan 30 01:57:25 and that's x86/config-default being 2.6.39, but x86/net5501/config-default building for 3.2.1 Jan 30 01:57:58 and it's enabled things that I definitely don't want. Jan 30 02:02:51 why don't we get x86/config-default straightened out for 2.6.39, then add x86/config-3.2 and go from there? Jan 30 02:03:35 don't know Jan 30 02:05:34 I can split the existing default into 3.2 and 2.6.39 Jan 30 02:06:25 if you think that helps Jan 30 02:13:03 how about this? http://fpaste.org/RqOX/ Jan 30 02:13:38 jow * r29953 /trunk/target/linux/x86/ (config-3.2 config-default): [x86] create a config-3.2 for upcoming changes, rebase config-default to 2.6.39 Jan 30 02:15:26 better? Jan 30 02:15:31 yes. Jan 30 02:15:44 ok, this hopefully makes it less messy for you Jan 30 02:15:55 now to generate a config-default for net5501... I copy ../config-3.2 into net5501/config-default? Jan 30 02:16:13 then reduce config-default to just the deltas? Jan 30 02:16:25 thats the idea Jan 30 02:17:15 ... after rerunning make kernel_config? Jan 30 02:17:21 (for the new target.) Jan 30 02:17:44 or does net5501/config-default need to exist before the kernel_oldconfig? Jan 30 02:21:15 wait, "make menuconfig" or "make kernel_oldconfig"? Jan 30 02:24:12 for me kernel_oldconfig merges target/linux/generic/config-3.2 and target/linux/x86/config_default Jan 30 02:24:51 correction Jan 30 02:24:58 for me kernel_oldconfig merges target/linux/generic/config-3.2 and target/linux/x86/config-3.2 Jan 30 02:26:04 running make kernel_menuconfig updates target/linux/x86/config-3.2 Jan 30 02:26:32 svn diff on target/linux/x86/config-3.2 is more or less the delta you'd put into target/linux/x86/net5501/config-default Jan 30 02:26:44 once its saved there you can svn revert target/linux/x86/config-3.2 Jan 30 02:27:49 so to recap: Jan 30 02:27:58 svn up, make sure all is clean Jan 30 02:28:03 (reverted) Jan 30 02:28:16 select x86 / net5501 Jan 30 02:28:25 make kernel_menuconfig Jan 30 02:28:36 choose the features you want differently in net5501 Jan 30 02:28:43 compared to x86 generic Jan 30 02:28:45 exit, save Jan 30 02:28:59 svn diff target/linux/x86/config-3.2 and fold the deltas into target/linux/x86/net5501/config-default Jan 30 02:29:03 svn revert target/linux/x86/config-3.2 Jan 30 02:29:12 I still need to get the platform changes into target/linux/x86/net5501/config-default, right? Jan 30 02:50:59 jow_laptop: isnt 80211S support in WRT now ? Jan 30 02:57:19 OutBackDingo: you need to enable it, its off by default Jan 30 02:57:30 philipp64|laptop: yeah Jan 30 02:58:24 ok... thanks **** ENDING LOGGING AT Mon Jan 30 02:59:58 2012