**** BEGIN LOGGING AT Wed May 20 02:59:59 2015 May 20 03:16:04 luka: the libdaq tarball as specified in the Makefile is a 404 May 20 03:18:07 luka: same for snort May 20 06:59:32 build #5 of ramips is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/5 May 20 07:24:38 build #5 of ramips.mt7628 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/5 May 20 09:26:35 build #4 of mpc83xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/4 May 20 09:51:56 build #4 of ep93xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/4 May 20 10:27:50 Hello! I have a question about the ubus C API. Can anyone help out? May 20 10:30:26 br1: my guess is "yes" May 20 10:30:57 br1: i can see a lot of ppl on # May 20 10:31:07 br1: there is some chance few of them know C API May 20 10:31:42 Is it guaranteed that the callback of ubus_invoke is called before invoke returns? May 20 10:32:21 e.g. ubus_invoke(ctx, id, "status", NULL, receive_call_result_data, NULL, 3000); May 20 10:32:58 it seems like the callback 'receive_call_result_data' is called instantly but is it guaranteed? May 20 10:33:42 br1: couldn't you start with that question? ;) May 20 10:34:28 rmilecki: ok ok May 20 10:34:33 br1: http://lxr.mein.io/source/ubus/libubus.h#L275 May 20 10:34:43 br1: you have ubus_invoke & ubus_invoke_async May 20 10:34:47 I guess it answers your question May 20 10:36:10 yes i've seen that but ubus_invoke_async does not have a callback function... May 20 10:36:53 or well, it's inside ubus_request struct May 20 10:40:57 rmilecki: thanks May 20 14:24:32 build #5 of ipq806x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ipq806x/builds/5 May 20 14:50:45 build #4 of brcm63xx.smp is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/4 May 20 15:09:41 build #5 of brcm63xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/5 May 20 16:09:58 luka: ok, i tried building squid 3.5.4 for mips64, and if the final hunk of the cross compile patch is manually removed, it builds. also, the mime patch is a bit silly May 20 16:10:44 luka: the configure args need some cleanup too May 20 16:15:06 DonkeyHotei: please send a pull request on github then May 20 16:16:06 luka: i plan to, once i can find a solution to the openssl issue May 20 16:17:33 luka: what about snort and libdaq. though? May 20 16:30:55 build #4 of mpc52xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/4 May 20 16:53:50 yay rc1 May 20 16:58:32 DonkeyHotei: i will ping felix to add those to openwrt mirror May 20 16:59:13 luka: there are 2 alternatives: 1) the old binaries are on sourceforge 2) version bump May 20 16:59:35 luka: s/binaries/tarballs/ May 20 17:01:05 DonkeyHotei: i was just looking at it May 20 17:10:46 DonkeyHotei: fixed May 20 17:32:23 how do you insert a patch into a series with quilt?! May 20 17:32:35 in the middle? May 20 17:32:48 yeah, I have 7xx- for machines May 20 17:33:00 and there's platform/90x for some other things May 20 17:33:29 if the series is not applied yet, then "quilt push generic/123-name-of-patch-just-before-yours.patch" May 20 17:33:44 if it is not fully applied then "quilt pop generic/123-name-of-patch-just-before-yours.patch" May 20 17:34:08 ok, I got some weird warning about refresh earlier :| May 20 17:34:09 then quilt new generic/124-my-inbetween.patch; quilt edit foobar.c; quilt refresh May 20 17:34:23 or quilt import from an existing patch file May 20 17:34:45 then quilt push; quilt refresh until you're at the end of the series again May 20 17:34:46 when dyou re-push the remainder of the series? May 20 17:34:51 or quilt push -a May 20 17:34:53 hrm, will try this again. May 20 17:34:59 if it applies cleanly or some fuzz May 20 17:35:04 it seems to be a struggle every time I try this :) May 20 17:36:23 in general the semantics for push and pop are easy May 20 17:36:30 push w/o argument pushes one patch May 20 17:36:48 push with a patch name pushes until and including that patch May 20 17:36:57 push with -a pushes all May 20 17:37:00 same with pop May 20 17:37:27 I must have done "add" instead of "new" or something itw as all very confusing May 20 17:37:47 right May 20 17:37:56 add adds a new file to the current patch on top May 20 17:38:08 like git add adds a file to the to-be-committed changeset May 20 17:38:36 yeah, but git doesn't need the "new" bit to start with, which I missed May 20 17:39:04 seems to be going now, thanks. May 20 17:41:54 so, if I've added profiles, what target needs to be remade to let them be selected in make menuconfig? May 20 17:43:51 karlp: try touching the main target Makefile (target/linux/*/Makefile) May 20 17:44:46 that's it, beautiful May 20 18:26:38 build #4 of kirkwood is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/4 May 20 18:39:35 luka: no version bump for snort/libdaq? May 20 19:03:23 build #4 of ar71xx is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/4 May 20 19:25:04 cyrus r45705 trunk/target/linux/generic/patches-4.0/667-ipv6-Fixed-source-specific-default-route-handling.patch * generic/4.0: fix error during kernel patch application May 20 19:52:04 build #6 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/6 May 20 19:52:16 build #6 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/6 May 20 19:52:35 build #6 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/6 May 20 19:56:45 build #6 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/6 May 20 20:32:39 build #6 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/6 May 20 21:40:12 build #4 of at91 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/4 May 20 21:57:43 build #5 of ramips.mt7620 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/5 May 20 22:09:37 build #4 of ramips.rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt305x/builds/4 May 20 22:17:06 cyrusff: http://patchwork.ozlabs.org/patch/474661/ May 20 22:50:15 nunojpg r45706 packages/net/usbip * usbip: moved to github May 20 22:58:48 build #5 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/5 May 20 23:03:19 Hey, using git cherry-pick for the first time. Trying to do a pull request for a commit to packages/trunk to go to packages/for-15.05. May 20 23:03:38 Should I cherry pick the original commit, or the commit where it was merged? May 20 23:05:05 original May 20 23:05:40 I figured as much. Thanks. *goes to fix it* May 20 23:07:11 jow_laptop: Hey, I'm seeing several luci apps going into the packages feed. What's the preference there? I assumed all luci apps should go into the luci repo May 20 23:09:07 a while ago I decomposed the luci source tree into individual packages which are self contained, this offered the possibilitiy to host luci packages alsewhere May 20 23:09:16 *elsewhere May 20 23:09:26 right now its merely a convention May 20 23:10:17 people simply started to make luci module PRs on packages.git and no one intervened May 20 23:10:45 not sure whether we should urge their maintainers to relocate them to luci.git May 20 23:11:39 because in the end those luci mods in packages.git cause inter-feed dependencies, something that should be avoided if possible May 20 23:11:49 just seems strange that they are getting pushed to both places. May 20 23:12:02 it is, sloppyness on my side :) May 20 23:12:15 Well, a lot of the luci apps are dependent on packages, too May 20 23:12:23 true May 20 23:12:28 like my fwknopd work. May 20 23:12:45 maybe we should simply move all 3rd part luci mods to packages.git and only keep the base stuff in luci.git May 20 23:12:51 it makes a measure of sense for the luci app to live in the same repo as the package May 20 23:13:05 but also makes sense to keep all the luci stuff together. *shrugs* May 20 23:13:16 well - thats my problem :) May 20 23:13:37 no strong preference and no rules (either is fine) so it came down to this May 20 23:14:32 lol I understand. I'm sure there will eventually be a great migration one direction or the other. May 20 23:14:34 packages.git has more active reviewers and committers so maybe the non-core luci work should move there May 20 23:14:41 Time will tell which is the better solution May 20 23:15:30 That is true. Do the reviewers on packages.git know luci well enough to point out problems? May 20 23:17:51 does the above apply to luci apps in routing/packages.git too? May 20 23:24:29 jbennett: not sure May 20 23:28:35 anyhow either way is fine for me personally, I get all github notifications qanyway so from my pov it does not matter if something happens in packages.git or luci.git May 20 23:29:19 *shrugs* ok, works for me May 20 23:30:15 but I do agree that we maybe should open a discussion about that on the devel list May 20 23:30:34 maybe also suggest to merge openwrt-routing/packages.git with openwrt/packages.git May 20 23:31:03 but only if the routing maintainers agree May 20 23:32:00 or at least move the routing feed under the umbrella of the openwrt org, so openwrt-routing/packages.git -> openwrt/routing.git May 20 23:32:11 anyhow, cosmetics mostly May 20 23:35:24 That would make the feeds more intuitive. May 20 23:36:27 openwrt-management looks to be similar May 21 00:10:52 jow_laptop: i'm fine with both move and merge May 21 00:11:07 good night May 21 00:11:11 and happy rc1 day May 21 00:54:52 build #4 of adm5120 is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/4 May 21 02:54:51 build #4 of gemini is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/4 **** ENDING LOGGING AT Thu May 21 02:59:58 2015