**** BEGIN LOGGING AT Thu Nov 05 03:00:15 2015 Nov 05 03:59:31 build #134 of ramips.mt7621 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7621/builds/134 Nov 05 04:25:46 build #135 of lantiq is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/135 Nov 05 04:31:29 build #133 of oxnas is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/oxnas/builds/133 Nov 05 05:45:29 build #133 of ramips.rt3883 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/133 Nov 05 07:51:21 build #125 of netlogic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/125 Nov 05 08:15:45 build #120 of ar7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/120 Nov 05 08:58:34 build #125 of ar71xx.nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/125 Nov 05 09:14:18 build #134 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/134 Nov 05 09:18:35 build #134 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/134 Nov 05 09:22:12 build #134 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/134 Nov 05 09:56:28 build #120 of mxs is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/120 Nov 05 10:03:15 blogic r47388 trunk/target/linux/ ramips/dts/LINKIT7688.dts ramips/patches-3.18/0301-mt7688-detect.patch ramips/base-files/lib/ramips.sh ramips/patches-3.18/0300-mt7628_fixes.patch * ramips: minor tweak to the lks7688 baord name Nov 05 10:05:48 blogic r47389 trunk/target/linux/ ramips/patches-3.18/0301-mt7688-detect.patch ramips/patches-3.18/0300-mt7628_fixes.patch * ramips: fix previous commit Nov 05 10:07:05 blogic r47390 branches/chaos_calmer/ target/linux/ramips/base-files/lib/ramips.sh target/linux/ramips/dts/LINKIT7688.dts * ramips: minor tweak to the lks7688 baord name Nov 05 12:08:24 s/baord/board/ Nov 05 13:19:52 build #132 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/132 Nov 05 14:20:54 bah, damn mixups between luci.module.uci and uci lua bindings :| Nov 05 14:45:50 heh, uci import -m is faster and simpler than either of the lua binding apis... Nov 05 14:59:15 of course :) Nov 05 15:08:17 build #123 of xburst is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/123 Nov 05 15:23:51 jow_laptop: I'm having a difficult time finding what determines luci module ordering (namely, which module is first, and thus being the root module?) Nov 05 15:24:02 Could you nudge me in the right direction? Nov 05 15:27:21 undefined Nov 05 15:28:32 jow_laptop: just always yuk when you end up mixing both os.execute("uci blah") and the uci binding apis in the same luci code :( Nov 05 15:29:11 karlp: well but uci import does not need to convert between lua and back, perform all the apui checks etc. so its way faster Nov 05 15:29:29 I was't talking abotu speed of operation actually Nov 05 15:30:09 I was talking baout, "I spent a few hours dicking arodun with the luci.model.uci and uci bindings and couldn't find a way to reliably ensure a named typed section existed, and it's one line via the shell" Nov 05 15:30:27 speed of operation doesn't matter a jot when it's not being done all the time Nov 05 15:30:34 cursor:get("config", "name") == "expected-type" Nov 05 15:31:12 if x:get("network", "wan") == "interface" then print("Have a config interface wan") end Nov 05 15:31:26 well, it only came up because set_list doesn't create the sectoin if it doesn't exist. Nov 05 15:31:39 and uci doesn't have a "section()" method, Nov 05 15:31:44 only luci.model.uci Nov 05 15:32:07 set_list returning true when it doesn't do anything was decidedly unhelpful Nov 05 15:33:26 it just returns what uci.so's set() returns? Nov 05 15:33:51 which is true if the config file exists, regardless of whether the section exists, and false if the config file doesn't exist. Nov 05 15:34:13 if I try and set_list(cfg, section, option, list) and it says "true" I kinda expect it to have done so Nov 05 15:34:23 wehther the bug is in set or set_list isn't super interesting from a user point of view. Nov 05 15:34:31 jow_laptop: guessing undefined because it's a table? Nov 05 15:34:35 saik0: yes Nov 05 15:34:49 jow_laptop: what builds the table? :) Nov 05 15:35:14 saik0: dispatcher.lua Nov 05 15:35:51 karlp: yeah buts interesting for me :) uci.git vs luci Nov 05 15:39:16 set_list problem of mine was with luci.model.uci, Nov 05 15:39:27 uci:section was with uci.git, Nov 05 15:39:37 that was just my oen problem of tryign to use both. Nov 05 15:39:38 set_list() invokes uci set() Nov 05 15:39:50 and relays it return value Nov 05 15:40:28 anyhow, not wanting to split hairs here Nov 05 15:40:43 tbh I never actually relied on return values of set() Nov 05 15:40:59 well, I only even _looked_ because set_list wasn't setting the list :) Nov 05 15:41:01 or at least never considered them to be more than a formal argument check Nov 05 15:41:32 it all comes down to set_list() not doing anythign if the section doesn't exist, and returning a true/false that doesn't seemt o have any relation to that. Nov 05 15:41:50 yeah my point is that set() has the same problem Nov 05 15:42:44 all set_list() does is putting "{" and "}" around rthe value if its not a table Nov 05 15:43:39 so sugar for type(foo) == "table" and x:set(..., foo) or x:set(..., { foo }) Nov 05 15:44:13 so it needs a fix in libuci. From looking at the C binding code there it seems pretty clear why a wrong true status is returned Nov 05 15:44:56 my only poitn is taht a user of the luci mmodel and reference I have no idea how it's implemented or why, and I don't really care very much. but yes, I agree it's all uci's fault :) Nov 05 15:47:40 root@jj:~# lua -luci -e 'x=uci.cursor(); x:load("network"); print(x:set("network", "doesnotexistforsure", "blah", "1"))' Nov 05 15:47:44 true Nov 05 15:48:37 I'll look into a fix later Nov 05 15:49:01 in the meanwhile you can proactively check for the expected section & type with the uci:get(conf, name) == type pattern Nov 05 15:50:15 jow_laptop: the top level nodes of luci.dispatcher.createtree() Nov 05 15:50:18 ? Nov 05 15:53:36 saik0: the logic is that the first root node is claiming / Nov 05 15:53:53 iirc it boils down to the lexical order of the file globbing Nov 05 15:55:32 if you intend to override the root node in any case, use this in your toplevel controller: local root = node(); root.target = ... Nov 05 16:01:45 jow_laptop: ah, OK. Now I have two things I need to grok ;D Nov 05 16:03:22 saik0: my you can describe your high level objective Nov 05 16:05:48 s/my/maybe/ Nov 05 16:06:02 jow_laptop: for set non-existant, what I'd _like_ is for that to make any configs and sections it needs. I'm fine with it returning false and not doing it though too, I can work with that, it's jsut less friendly :) Nov 05 16:06:54 karlp: thats not possible without breaking the interface Nov 05 16:07:02 currently I've just gone with os.execute("echo mysectype mysecname | uci -q -m import myconfig") Nov 05 16:07:04 since you do not pass the intended type on set() Nov 05 16:07:51 the split on type and name on sections is inconsistent and annoying all over the place :) Nov 05 16:08:06 maybe a new api that's useful instead of having some things work on name and some on type? Nov 05 16:08:26 all things work on name except iterators Nov 05 16:08:34 or what inconstent functions do you have in mind? Nov 05 16:09:23 jow_laptop: Oh, yes it was to override root node. Thanks for the help. Just meant I realized I should also go poke around in Node to understand LuCI "internals" Nov 05 16:11:51 mostly that names are optional, so most of the time you canð't use the api methods, and its confusing because most things use the same name for type and name, so it's never easy to follow what param is what in what order. Nov 05 16:12:43 teh methods that all work on name make it look like "cfg x y" and x is _not_ what's on the "config blah wop" in the file Nov 05 16:13:08 it's probably all internally self consistent and pure and gloriosu, but I still have troubles with the name/type distinction after years Nov 05 16:14:59 I could provide explicit set_typed() and get_typed() Nov 05 16:15:08 those would also allow autocreating sections Nov 05 16:15:39 it might be partly that the only documentation is the subsignal luci stuff, and the uci command line help and experimentation, Nov 05 16:15:55 and grepping for existing users of various methods Nov 05 16:16:11 so x:set_type(conf, stype, opt, val) would attempt to set opt=val in @stype[0] Nov 05 16:16:33 and if @stype[0] does not exist it would create it using x:add(conf, stype) Nov 05 16:16:47 alternatively a 5 argument form of set() Nov 05 16:17:06 x:set(conf, stype, sname, opt, val) Nov 05 16:17:59 either is fine with me if they get documented somewhere Nov 05 16:43:03 one thing that I find difficult with the names is that ifyou specify a name, it effectively has to be unique, you can't have two sections with different types and the same names. Nov 05 16:43:30 c orrect Nov 05 16:47:00 so why does this only give me two? https://paste.fedoraproject.org/287332/67419611/ Nov 05 16:47:35 "uci show remake.plugins.banned_auto" shows me the entries from both config sections that have a banned auto, and are named plugins Nov 05 16:47:44 but the libuci code only gives me one of them. Nov 05 16:49:43 becase names must be unique Nov 05 16:49:49 globally unique, not unique within a type realm Nov 05 16:50:08 so why does uci at the command line at least handle all of them? Nov 05 16:50:57 it was intentionally made very forgiving to not brick the entire system when semantic failures occur in files Nov 05 16:52:36 so fun when things are consistent like this :) Nov 05 16:52:41 can I get an error when it loads the file that there was something wrong with it? Nov 05 16:52:55 uci_load didnt' say anything, Nov 05 16:52:57 C? Nov 05 16:53:28 I'd _like_ to either get the same behaviour with libuci in C as with uci on the cli, _or_ be able to know that something has happened that might make them not match Nov 05 16:53:44 uci says it's in strict mode by default, I take it that only applies to values given, not values read from the file Nov 05 17:02:00 uci.git lua bindings only show the last one too, at least it's consistent with the C version it's providing the binding for :) Nov 05 17:03:12 the lua binding and the cli do agree here Nov 05 17:03:14 both merge the both sections called "plugins" and report them as one Nov 05 17:03:59 with type "plugin_x" and duplicate list occurences merged Nov 05 17:07:11 http://pastebin.com/Uftvg5Xr Nov 05 17:18:48 hrm, get_all("test") workd, and merged them, but cusor:foreach("test", "plugins", function(s) print(pretty.write(s)) end) only prints one of them. Nov 05 17:19:16 as does uci show Nov 05 17:19:19 and your C code Nov 05 17:19:30 no, uci show showed them merged Nov 05 17:19:40 and? Nov 05 17:19:56 it reported only one section declaration for plugins, not two Nov 05 17:20:15 as does foreach() only report one instance Nov 05 17:20:24 right, but the show shows the values from both, Nov 05 17:20:30 foreach onlyt gives you one of them. Nov 05 17:21:05 yes because its restricted the the "plugins" type Nov 05 17:21:18 while uzci show or uci_foreach_element() perform an unrestricted iteration Nov 05 17:21:25 without any filtering Nov 05 17:22:05 * karlp sighs. that's all wonderful, it's just _very_ obtuse for someone who's not you or nbd it seems. Nov 05 17:22:08 I get your problem, no argument here Nov 05 17:22:23 and I had to learn it for years as well :D Nov 05 17:22:34 nobody ever told me anything Nov 05 17:22:38 it's just taken soooo long and I still struggle with it everyt time Nov 05 17:23:09 thanks for the patience with me Nov 05 17:23:28 I might harp on it, but it's realllly hard to learn with the current state of teh docs on this. Nov 05 17:23:57 and it makes it hard to know if I'm driving the api wrong, or the docs are wrong, or there's a bug in the binding, or the core. Nov 05 17:25:12 however, today I learned lua -lxxx to auto require things :) Nov 05 17:25:37 hm odd Nov 05 17:28:11 so the only api usage difference between your C code and using cursor:foreach() is that lua foreach uses uci_foreach_element_safe(&pkg->sections, ...) Nov 05 17:28:29 and a strcmp(s->type, type) in the loop to skip entries Nov 05 17:30:16 I got your problem with :foreach() Nov 05 17:30:29 it gives you the "notplugins" section Nov 05 17:30:50 because you asked for a section with type "plugins", and "notplugins" is tjhat Nov 05 17:31:24 you wanted cursor:foreach("test", "plugin_x", callback) and it will give access to the very same merged values you see in uci show Nov 05 17:31:51 so what happens, assuming your test config snipped pasted earlier Nov 05 17:32:27 - it constists of three sections, the the 1. and 3. being of type "plugins" and the 2. one being of type "plugin_x" Nov 05 17:33:42 - section 1 and section 2 share the same name, so libuci merges them under the type of the last section with the same name (t=plugin_x, n=plugins) Nov 05 17:34:07 - section 3 is the only remaining one with type plugins because 1's type has been overwritten by 2's type due to the name conflict Nov 05 17:35:13 so after consolidation you have section 1 with t=plugin_x, n=plugins, opts=(banned_auto, disabled, hoho) and section 2 with t=plugins n=notplugins, opts=(disabled) Nov 05 17:35:28 these are the two you see in your C code Nov 05 17:36:12 now by invoking cursor:foreach("test", "plugins", ...) you're iterating all *consolidated* sections of type "plugins" and that happens to be 3 Nov 05 17:36:51 if you closely watch the output of "uci show" you see the first line: test.plugins=plugin_x - (conf).(name)=(type) Nov 05 17:37:22 so what are the findings here? Nov 05 17:37:42 1) having same label for type and name is confusing and hides bugs Nov 05 17:38:05 2) uci's silent handling of name conflicts over sections with different types is counterintuitive and should result in a parse error Nov 05 17:38:40 2b) if a parse error is not aggreeable then it should at least keep the *first* type of a set of sections sharing the same name, not the last Nov 05 17:40:16 3) if you want to avoid the whole type vs. name headache you could consider using types only, and use the through luci.model.uci's get_first(), set_first() wrapper Nov 05 17:43:18 4) there's also a bug in foreach() - it is supposed to allow the type being nil in order to invoke the callback for *any* section of *any* type Nov 05 17:43:48 but for some reason it does not work for the cursor:foreach colon notation but does if invoked without implicit self Nov 05 17:44:08 x:foreach("conf", nil, cb) -> error Nov 05 17:44:15 x.foreach("conf", nil, cb) -> works Nov 05 17:45:17 ah I see why Nov 05 17:54:02 build #132 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/132 Nov 05 17:57:20 karlp: ok and now I understand why a 2nd section with the same name overwrites the type of a preior section with the same name, this is because libuci uses its own uci_set() while parsing the file and that will happily overwrite whatever exists Nov 05 17:58:20 http://pastebin.com/LGQvjSB0 Nov 05 18:03:37 karlp, nbd: proposed solution: http://pastebin.com/K8MY3uEU Nov 05 18:15:02 thanks for the writeup, just home and re-reading it now. Nov 05 18:15:20 yeah, 1) type==name is confusing. totally. Nov 05 18:15:25 2) totally. Nov 05 18:16:21 problem with using types only is that you've only got get_first, so yu just have to hope that you no-one added another of the same type, because there's no warnings on it. Nov 05 18:16:48 also, with no names, you have to deal with the @type[x]=cfga2342343sdf auto stuff all the time, and harder to use on the cli Nov 05 18:17:25 most of the apis seems to encourage usign names, but types will trip you up Nov 05 18:19:10 I sent a rfc path to you and felix Nov 05 18:19:14 *patch Nov 05 18:19:25 I think such a check would have prevented a lot of confusion Nov 05 19:02:24 build #112 of mvebu is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/112 Nov 05 19:38:41 yeah, looks good. Nov 05 19:39:17 one thing is whterh luci.model.uci coul dbe dropped/replaced by simply uci and extensions to uci? libuci and the lua bindings are substantially easier to install on desktop linux, and there's not that many differences? Nov 05 21:24:18 karlp: yes, we can think about migrating some of the support code Nov 05 22:26:16 nbd: i've got an IMAGE template with params that is getting called twice - any way to make them not able to be run in parallel? Nov 05 22:31:49 problem is they both copy build artifacts into a dir to create a ubifs and the two parallel calls are clobering each other. Another solution would be if I could figure out how to make the population of the dir a dependency both used Nov 05 22:32:53 tharvey: why not just use a different directory per image so they can run in parallel? Nov 05 22:33:16 that was my next choice if there was nothing better Nov 05 22:33:30 i think that's better than adding dependencies or serializing the build Nov 05 22:33:59 ok - will do that then Nov 05 23:16:57 build #112 of ar71xx.mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/112 **** BEGIN LOGGING AT Thu Nov 05 23:50:43 2015 Nov 05 23:53:15 build #120 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/120 Nov 06 00:08:48 build #113 of ath25 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ath25/builds/113 Nov 06 00:11:04 build #111 of mpc85xx is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/111 Nov 06 00:42:17 build #112 of adm8668 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/112 Nov 06 00:46:45 build #108 of adm5120 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/108 **** ENDING LOGGING AT Fri Nov 06 02:59:58 2015