**** BEGIN LOGGING AT Tue Jun 04 03:00:19 2019 Jun 04 04:21:55 i'm looking at parsing UCI sections using C library Jun 04 04:22:13 it seems most of code uses uci_to_blob + blobmsg_parse for that Jun 04 04:22:43 but I see there is also a uci_parse_section() helper Jun 04 04:23:48 any opinion on what should I use / why? Cc jo Jun 04 04:23:51 Cc jow Jun 04 05:53:47 rmilecki: hi Jun 04 05:53:51 use uci_to_blob Jun 04 05:54:04 rmilecki: its a wrapper that hides all the other stuff away Jun 04 05:54:11 rmilecki: parsing by hand is a pita Jun 04 05:54:36 rmilecki: i was real happy when uci_to_blob appeared Jun 04 05:58:39 blogic: i don't mean to parse manually Jun 04 05:58:44 blogic: i mean to use that helper Jun 04 05:58:46 did you see it? Jun 04 05:58:56 it works almost like with uci_to_blob() Jun 04 06:00:56 blogic: https://pastebin.com/VH2bMGUf Jun 04 06:11:37 rmilecki: sure but then you have uci api for parsing after Jun 04 06:11:43 working with blob is much easier Jun 04 06:12:08 well, all I need to do is tb[FOO_A]->v.string Jun 04 06:12:14 ok Jun 04 06:12:16 what parsing do you mean? Jun 04 06:12:21 that Jun 04 06:12:54 https://git.openwrt.org/?p=project/fstools.git;a=blob;f=block.c;h=39212d247fe46e07b4ea4113edf4687b59b7d4e7;hb=HEAD#l257 Jun 04 06:13:41 OK, so a gain from using blob is access to the blobmsg_get_* helpers I guess Jun 04 06:15:25 rmilecki: well Jun 04 06:15:38 you algo gain that you use the same api for ubus and config Jun 04 06:15:50 so imagine a daemon that loads its base config from uci Jun 04 06:15:57 then later you send updates via ubus Jun 04 06:16:05 you can use the same codepath for parsing Jun 04 06:16:06 OK Jun 04 06:16:08 I see Jun 04 06:16:10 thanks! Jun 04 06:16:14 like blockd managing mounts Jun 04 06:16:23 they can be in uci or passed at runtime via ubus Jun 04 06:16:33 yeah, I see that point now Jun 04 06:16:36 that is the root cause why uci_to_blob was added Jun 04 06:16:53 i ran out of HDD space Jun 04 06:17:23 searching why i found that in the last 2,5 years i accumulated a dl folder of ~120GB Jun 04 06:17:36 not openwrt but ~/Downloads Jun 04 06:18:06 Firefox/Chromium? :) Jun 04 06:18:13 keeping all the stuff? Jun 04 06:45:55 rmilecki: I always parsed stuff manually :) using uci_lookup_ptr(), checking flags etc. Jun 04 07:00:56 blogic: didn't know that $(if ifeq x y,...) is a valid make construct Jun 04 07:05:29 jow: neither did i Jun 04 07:05:38 jow: but it is Jun 04 07:06:23 jow: i tested it with "" "files" and "files2" Jun 04 07:06:31 but i can add qstrip i guess Jun 04 07:07:03 $(TOPDIR)/"files" == $(TOPDIR)/files hence it would work Jun 04 07:07:14 but i'll send a V2 with qstrip, its nicer to be clean **** BEGIN LOGGING AT Wed Jun 05 03:20:09 2019 Jun 05 07:19:20 Pepe: ok, I've missed that, reopened the task Jun 05 07:30:31 ynezz: Thanks! I think having the first press interrupt properly handled is the key. https://git.openwrt.org/484b050385 seems to fix the problem as gpio_keys_irq_work_func should generate event for every interrupt no matter what last_state is. Jun 05 07:30:46 When the first press interrupt is properly handled, priv->seen will consequently be set to the correct value in button_hotplug_event, so the corner case described in https://git.openwrt.org/2b8257fda6 should never happen in theory. Jun 05 07:31:23 Is there any release edge-triggered only button out there which won't get a press interrupt beforehand? In this case "seen" does not make much sense anyway as you will just be calculating seconds between button releases. Jun 05 07:35:42 well, seen value is computed by the `(seen - priv->seen) / HZ` expression Jun 05 07:36:34 so it's `(jiffies - 0) / HZ` for the first run Jun 05 07:37:19 kyli: ^ Jun 05 07:37:58 Yep I know, but the press should happen first, and seen is not used in press handling. Jun 05 07:38:30 What's important should be the seen for release. Jun 05 07:39:05 indeed, for the code found in the tree it doesn't matter, but still it's technically wrong Jun 05 07:39:37 I mean, why not to fix it if it was already discovered Jun 05 07:42:05 or I'm not 100% sure that it's wrong, it depends how you look at it, seen=jiffies for the first press might be as well correct Jun 05 07:42:58 I think I'm good with both ways. :) Jun 05 08:15:10 Just one thing: https://git.openwrt.org/2b8257fda6 should not be applied alone without https://git.openwrt.org/484b050385, otherwise it will then cause first long press to be interpreted as short press. (No way to FACTORY RESET with button, as the machine will reset itself on the first press of reset no matter how long you press it.) Jun 05 08:45:30 ynezz: Tested https://git.openwrt.org/484b050385 and it fixed the problem on previously failed device. Many thanks! Jun 05 08:49:11 nice, thanks, can I have your Tested-by: please? Jun 05 08:51:31 jow: I just wanted to take a look at FS#2291 and noticed, that you've already fixed it in `session: handle NULL return values of crypt()` long time ago, should I just bump rpcd package or you want to continue working on it? Jun 05 08:53:11 ynezz: yes, bumping the rpcd package is all that is needed Jun 05 08:53:37 jow: ok, will do it Jun 05 08:57:09 Kuan-Yi Li Jun 05 08:57:45 jow: have this in my local rpcd for ages http://paste.ubuntu.com/p/3d6JJVQYKb/ does it look ok? Jun 05 09:33:13 anyone seen this before? [ 8.017943] OF: fdt: not creating '/sys/firmware/fdt': CRC check failed Jun 05 09:36:48 stintel: are you using a flattened device tree? Jun 05 09:38:15 https://www.kernel.org/doc//Documentation/ABI/testing/sysfs-firmware-ofw Jun 05 09:38:40 Hellsenberg: EdgeRouter Lite (octeon), uses FDT afaik Jun 05 09:39:20 looks like the FDT has been modified by something at some point, and the crc32 fails Jun 05 09:39:34 either before runtime, or during runtime Jun 05 10:15:27 if I want to automate compilation/building of openwrt image with some changes to config files and add a certain amount of packages and a custom feed, is it image builder I should look into? or is there some other tool? Jun 05 10:22:17 SwedeMike: building new images from source is pretty quick from incremental updates, so i'd suggest doing that Jun 05 10:23:04 russell--: I have no problem with build time, but I want the image to be baked with the changed config files and updated packages etc. Jun 05 10:23:24 sure Jun 05 10:23:56 you have options Jun 05 10:24:03 find something you like Jun 05 10:24:21 i've been using uci-defaults scripts to apply config updates Jun 05 10:25:25 russell--: how do I maintain feeds.conf file and .config and these uci-defaults scripts? Everything you're saying seems fine, but how do I "package" this up in the best way? Jun 05 10:25:43 I'd like to keep the changes in a gitlab project or similar way Jun 05 10:25:49 i use a .config stub generated from scripts/diffconfig.sh Jun 05 10:26:21 i've got a script that generates a files overlay and the .config stub Jun 05 10:26:51 i move the files overlayy into the build tree, copy in the .config stub, run make defconfig and build Jun 05 10:28:25 * russell-- isn't claiming it's best but it work for me ... if i find something i like better, i change Jun 05 10:29:14 perfect is the enemy of good, etc Jun 05 10:29:46 analysis paralysis-- Jun 05 10:36:17 russell--: ok, sounds like a good start, will try. Jun 05 10:44:04 russell--: where in the build tree do you put the overlay files? ./build_dir/target-x86_64_musl/root.orig-x86/overlay/ ? Jun 05 10:56:12 ynezz: ack, looks good to me Jun 05 10:57:05 ok, going to push it together Jun 05 10:57:20 SwedeMike: a toplevel files/ directory Jun 05 10:57:50 files/etc/config/foo, files/etc/uci-defaults/run-this-on-boot.sh, files/usr/sbin/proprietary_binary etc. Jun 05 10:58:51 blogic: was working on making the files/ directory managed by scripts/env iirc, that would simplify the "packaging" aspect in the future Jun 05 11:10:46 env allows you to symlink the files dir Jun 05 11:10:56 my patch allows changing the path that is used Jun 05 11:23:55 blogic: so env already provides a way of having a custom files dir per env? what's the advantage of having a configure option for that? Jun 05 11:24:55 jow: thanks. Jun 05 11:33:27 KanjiMonster: that you need to populate the env and cannot drive it externally Jun 05 11:33:53 KanjiMonster: the idea here is that the ODMs requested a feature for a per customer include folder for overriding logos, defconfigs etc Jun 05 11:34:05 and they want to keep the config static and drive this from external Jun 05 11:34:19 blogic: ah, env != scripts/env Jun 05 11:34:19 using env requires a git tree internally that needs to popultaed Jun 05 11:34:29 KanjiMonster: yes, scripts/env Jun 05 11:34:55 should scripts/env be updated to follow the config option then? Jun 05 11:34:58 basically i explained to them that having a forked version of owrt is always bad, whether in the sdk tree, prpl or wherever else Jun 05 11:35:17 so we identified the reasons they fokd and I am just removing the argumentation that these things cannot be done Jun 05 11:35:22 thus reducing the delta Jun 05 11:35:54 KanjiMonster: in the process i was given a wealth of sdk patches to pretty much all packages we have adding some very cool features so i am going over all this stuff right now and upstreaming it Jun 05 11:36:08 the goal is that prplwrt will only be a collection of toolchains, kernels and driver packages Jun 05 11:36:30 basically stuff that is not ready for upstream, the rest goes into a public feed or directly into openwrt feeds Jun 05 11:58:20 KanjiMonster: yes I think scripts/env should be updated to not violate the principle of least surprise Jun 05 11:59:43 jow: I'll update the patch Jun 05 11:59:57 I wonder if it wouldn't make more sense to enhance scripts/env to easily use remote gits for storing the envs; then you could easily have a common git with config + files with a branch per customer Jun 05 12:05:46 ynezz: https://bugs.openwrt.org/index.php?do=details&task_id=2279 Jun 05 12:05:54 seems to work physically Jun 05 12:07:00 KanjiMonster: yes, i suggested that but that is not deployable as a tar file Jun 05 12:07:14 KanjiMonster: and it uses git which is voodoo to most these folks Jun 05 12:11:49 xback: so 'Works for me'? :) Jun 05 12:11:55 Voodoo that every sane entity wants ;p (A little spiking ;) ) Jun 05 12:12:07 ynezz: quickly building a plain openwrt version now Jun 05 12:12:11 just to be sure Jun 05 12:12:27 hm, just download it? Jun 05 12:12:33 but I suspect the guy is connecting the USB port to his pc, which will not work Jun 05 12:12:59 the port is meant to work in host mode Jun 05 12:13:13 a client usb cable is needed to add stuff to it (it's micro usb port) Jun 05 12:13:48 I've just asked timk (the reporter) to join this channel Jun 05 12:17:22 xback: so the power pin is enabled/on by default in the bootloader? Jun 05 12:17:38 xback: because it seems like you can cut off the power from RouterOS Jun 05 12:18:11 ynezz: correct Jun 05 12:18:15 it's enabled by default Jun 05 12:23:08 i understand the files/ discussion but the other one is beyong me Jun 05 12:38:15 This is very off-topic and might be ignorant me, but is there stil any activity in Prpl? I found the minutes from their meetings, etc., very interesting, but it has been very quiet lately Jun 05 12:40:56 kristrev: yes they are Jun 05 12:41:12 my rant at the summit carried fruits Jun 05 12:42:02 things are a bit non-technical at parts as these meetings tend to be held by architects and managers so its really detached from reality and code Jun 05 12:42:24 I have been contacted by mirkol and asked for some guidance which I have been giving Jun 05 12:42:28 ynezz: tested on plain openwrt. works for me :) Jun 05 12:42:35 blogic: Interesting, thanks for letting me know! Jun 05 12:43:04 the advantage is that the others all work for companies wanting to use it and their decisions and actions are driven by corporate decisions while i can just create code and solutions without asking permissin Jun 05 12:43:28 sounds like a good deal :) Jun 05 12:43:43 not such a good deal to be honest Jun 05 12:44:00 more doing it as its a mess that some one needs to tend to in our eco system Jun 05 12:44:08 ah, ok, I see you didn't mention the amount of freedom you have :) Jun 05 12:44:24 oh I have all the freedom i want, its just not much fun Jun 05 12:44:27 so their goal is to upstream as much of the stuff they have made as possible? Jun 05 12:44:33 correct Jun 05 12:44:48 I have here ~20 security fixes/enhancements to procd and ubus Jun 05 12:44:55 ACL stuff for uci/rpcd Jun 05 12:45:00 a websocket daemon Jun 05 12:45:13 a dsl_manager for LTQ written in c using ubus Jun 05 12:45:18 a ubus/tcp proxy Jun 05 12:45:34 there is an easymesh implementation nearly done Jun 05 12:45:47 there will be updated vendor kernels and drivers soonish Jun 05 12:46:02 working on upstreaming lots of hostapd patches Jun 05 12:46:13 that all sounds like very nice enhacements/tools Jun 05 12:46:17 I do a couple of hours every day Jun 05 12:46:58 even though I agree that cleaning up others people mess does not sound like the most entertaining thing in the world Jun 05 12:47:47 thanks for the update, looking forward to seeing the outcome Jun 05 12:51:20 hm, ubus/tcp proxy? Jun 05 12:52:20 probably for controlling ubus over the network? Jun 05 12:53:10 I think someone from Inteno suggested something like that a while ago Jun 05 12:54:09 subject of the thread I am think of is: "ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus" Jun 05 12:55:04 ah Jun 05 12:55:15 Just hope it still stays "micro" ;P Jun 05 12:55:34 without LDAP auth it might Jun 05 12:57:12 I have some of the Inteno-devices in my office. They are fairly beefy, so it will be interesting to see. But I am sure something heavy will not be the default Jun 05 12:58:27 ynezz: yes Jun 05 12:59:06 ynezz: basically you can expose remote ubus objects on your local bus Jun 05 12:59:42 this is done via web sockets/tls and you can do a "ubus call 192.168.1.2/system info" Jun 05 13:00:09 I requested some changes to the way their git is hosted and once done will send a PR for a package in the feed Jun 05 13:00:26 I've had the need for that more than once Jun 05 13:00:49 kristrev: they are called iopsys nowdays ;) Jun 05 13:02:09 I thought that iopsys was the software and Inteno the company, but I see now that Iopsys has been spun out Jun 05 13:02:28 has it ? Jun 05 13:02:35 no idea to be honest Jun 05 13:02:58 its just summin i learned when bruce started swearing during my summit rant Jun 05 13:03:52 Yeah, There seems to be an Inteno Group and everything Jun 05 13:04:37 My company was looking into integrating with Iopsys some years ago, or at least making use of their hardware, but the project kind of just disappeared into nothingness Jun 05 13:05:58 https://inteno.no/ Jun 05 13:07:43 blogic: ah, nice, so I can replace my mqtt/ubus bridge soon Jun 05 13:08:52 ynezz: yep Jun 05 13:09:13 also there is a patch to add capabilities support to procd allowing you to run most services as !root Jun 05 13:09:30 but that needs more cleanup Jun 05 13:09:44 in general all the stuff needs lots of cleanup but its something we can work with Jun 05 13:10:08 oh and I got patches to add proper full featured .11r/v/k to hostapd Jun 05 13:10:12 ah nice, I was looking into that (caps) not so long ago Jun 05 13:10:22 stintel: uisng a json backend Jun 05 13:10:47 so when a service starts it looks for $(name).json in the caps folder and loads the caps described inside the json Jun 05 13:11:00 still wondering if we want to put them into the init.d scripts instead Jun 05 13:11:15 but might get bloaty and its easier to tune them in json files Jun 05 13:13:40 Hm, I searched for Purple Foundation. The first hit on Google was ... not correct Jun 05 13:14:38 kristrev: prpl Jun 05 13:16:37 Yeah, I remembered as I arrived at the page of Dallas Purple Party Weekend :) Jun 05 13:37:39 blogic: if they're just copying commands out of a pdf, can we just call the pdf the "script" and they can copy cp/cat commands too? the pdf _is_ the script surely? Jun 05 13:43:19 I wonder if a solution would be acceptable that changes scripts/feeds to simply logically merge feeds.conf.local with feeds.conf.default Jun 05 13:43:49 that's jonas's idea, but john says we can't rely on them ahving a file. it must be copied from the pdf. (that's where I can't follow it) Jun 05 13:44:26 whether you copy /paste a command that creates a file or copy/paste a command that invokes a script that creates a file seems ~equivalent to me. Jun 05 13:44:27 maybe its about idempotence Jun 05 13:44:42 any echo whatever >> blah.conf solution is unreliable Jun 05 13:45:15 echo always-new > blah.conf.local would be slightly better Jun 05 13:45:46 but from the cli ux pov I'd also favor some ./scripts/feeds add whatever (though I do not really like the proposed comma separated parameter format) Jun 05 13:45:53 jow: KanjiMonster's last solution is good Jun 05 13:45:59 jow: its future proof Jun 05 13:46:13 the "src-" prefix is redundant for example, the name could be made optional and inferred from the url Jun 05 13:46:15 I'll merge that with mine and bjorns patch and resend later or tomorrow Jun 05 13:46:28 is kanjimonster jonas? Jun 05 13:46:41 seems so Jun 05 13:46:57 yes Jun 05 13:47:05 the type likely too (https://example.org/blah.git, git://exmaple.rog/blah, user@example.org:blah -> src-git) Jun 05 13:47:47 ./scripts/feeds add https://example.org/packages.git -> src-git example-org https://example.org/packages.git Jun 05 13:47:49 karlp: yes. /whois should show my realname ;P Jun 05 13:47:59 jow: I agree if it was something that was going to be used by a human, but given the lengths of the urls and names, and the described motivation, it's going to be copoied verbatim from a "not script" instructions file anyway. Jun 05 13:48:21 KanjiMonster:neat! so used it showing somethign ~irrelevant, didn't even think to check :) Jun 05 13:48:23 ./scripts/feeds add -t svn -n foo https://example.org/packages.git -> src-svn foo https://example.org/packages.git Jun 05 13:49:02 ./scripts/feeds add some/directory -> src-link directory /absolute/path/to/some/directory Jun 05 13:49:08 -r revision -b branch Jun 05 13:49:18 I wonder if a solution would be acceptable that changes scripts/feeds to simply logically merge feeds.conf.local with feeds.conf.default <- congrats, you just found my first suggestion ;P Jun 05 13:49:23 that would provide value (in conjunction with a check for already existing entries to achieve idempotence) Jun 05 13:49:32 just seems like a lot of scripting for such a thin usecase. Jun 05 13:50:22 managing feed entries is a genuine use case Jun 05 13:50:45 and once you start to add checks like "does entry exists? if yes replace, else add" etc. the bash scripting becomes tedious as well Jun 05 13:50:46 it is, but is it done interactively a lot? isn't it always ~static within a project? Jun 05 13:51:29 john ws talking about prpl having a tarball of a checkout, that doesn't seem like an environment that's goign tobe doing updates? Jun 05 13:52:05 from my scripting expirience with jenkins groovy and buildot pythong I'd say that command invocations that allow for argv list invocations is slightly easier and slightly more secure compared to shelling out Jun 05 13:52:17 a full tool for complete feeds entry management soundsd nice though sure. Jun 05 13:52:59 RunTask("scripts/feeds", "add", "waht", "ever") vs. RunTask("/bin/sh", "-c", "grep -q foo blah.conf || echo 'src-git foo http://exmaple.org' >> blah.conf") Jun 05 13:53:36 just a made up example, both is doable ofc Jun 05 13:54:49 in the end its all just bikeshedding, because we're touching a script here ;) my point is just that it might make sense to revisit the ux of scripts/feeds, scripts/env while we're touching it anyway Jun 05 13:55:31 jow: i did not want to mention that Jun 05 13:55:42 the only valid comment i see is from jonas Jun 05 13:55:43 well 2 Jun 05 13:55:52 1) make it future proof by using an include Jun 05 13:55:57 2) the dash in the name Jun 05 13:56:07 rest just seems like "I am bored" convo Jun 05 13:56:41 but hey, I'll change the patch to however it makes people happy, otherwise I would not have touched it in the first place Jun 05 13:58:17 I tried really hard to not bikeshed too much ;P Jun 05 13:58:52 KanjiMonster: :P Jun 05 13:59:07 I will fold it all into one single patch and resend later or tomorrow Jun 05 14:03:44 Hi, was wondering if someone could explain the difference betwene a device and an interface from netifd point of view? Jun 05 14:03:57 I think I understand interface is a logical network and is used to driver upper layer protocols and firewall Jun 05 14:04:08 Neighbor11111114: a device is a linux netdev, an interface is a logical IP config container applied to a netdev Jun 05 14:04:10 but what is a device and how is linked to a interface? Is a device literally a Linux interface of some sort? Jun 05 14:04:17 multiple interfaces may share the same netdev Jun 05 14:04:50 Amazing answer thanks jow. To share multiple netdev with an interface I assume you use a bridge? Jun 05 14:05:05 I presume you *must* use a bridge? Jun 05 14:05:17 no you can have for example multiple "config interface whatrever" with the same "option ifname ethXY" Jun 05 14:06:00 or have one "config interface primary; option ifname eth0" and another "config interface secondary; option ifname @primary" (where @primary will resolve to "eth0") Jun 05 14:06:20 jow: not sure if src-git can be always inferred from ssh or http(s) urls (svn at least uses svn+ssh for the former) Jun 05 14:06:26 Ok great thanks jow Jun 05 14:07:08 KanjiMonster: it can't, but a heuristic guess/default to get will likely cover 80% of the use case. One can still use "-t xxx" to override Jun 05 14:07:26 *to git Jun 05 14:07:32 blogic: what sort of era trees are prpl people using? 18.06? master+patches? 15.05 or earlier? Jun 05 14:08:34 18.06 and trunk Jun 05 14:08:53 trying to get stuff as close to trunk as possible Jun 05 14:15:08 jow: seems that hg also uses http(s):// and ssh:// URIs, bazaar uses at least bzr+ssh similar to svn - so I would suggest printing an error when getting a http(s) or ssh uri without a defined protocol, or at least a warning that the script assumes git for that Jun 05 14:27:06 having a lot of problems with ar71xx reboot/sysupgrade leaving me hung, on 18.06 branch. I recently updated along the 18.06 branch from a few months back, so I've got new 4.9 dot releases, but there's ntohing that should have changed this behaviour. anyone else heard/seen anything weird? Jun 05 14:27:41 it's only anecdotal at the moemnt, but it's starting to be often enough that I need to start looking further Jun 05 14:29:02 Neighbor11111114: Look at wan/wan6 for an example of multiple interfaces, same netdev Jun 05 14:29:29 great thanks kristrev Jun 05 14:34:00 karlp: is there swap, external mounts, usb devices or services frequently writing on the affected machines? Jun 05 14:35:30 yes, but nothing that's changed recently. Jun 05 14:36:04 just hung it again, before I'd even mounted the disk or turned on swap or the writing processes Jun 05 14:36:15 so it hangs on boot? Jun 05 14:36:23 yeah, but no bootloader print out. Jun 05 14:36:37 ah so some kind of warm reset issue Jun 05 14:36:49 https://zerobin.net/?365f3d9dbdf0d076#R0zX9yklwgwXXaubiC0TX7dvx8EXO9BTALAFZjDq41k= Jun 05 14:47:11 karlp: what device is that? Jun 05 14:47:53 this is over uart of ssh? Jun 05 14:47:58 s/of/or/ Jun 05 14:50:03 over uart. Jun 05 14:50:37 it's our eg200, so ~roughly a carambola2 module Jun 05 14:51:32 it's possibly it's also my test device that's giving up after a couple of years of this, I'll try a few more, and try some older versioins to try and verify, just not something I've seen before. Jun 05 14:56:52 jow translations are awsome. in a controller file, in the index routine, I can use _() without any import. in a call() handler that index registers, I must use luci.18n.translate() If I do local _ = luci.i18n.translate at the _top_ of the file, the index breaks because _ is a nil upvalue :) Jun 05 14:57:36 is there a way of having them both have the same call? Jun 05 14:57:36 yeah, thats because of the way how we cache the index() function out of scope Jun 05 14:57:59 will take a look Jun 05 14:58:03 I've currently got cache turned off in etc/cnfig/luci, but it's the in process caching right? Jun 05 14:58:17 its the /tmp/luci-indexcache Jun 05 14:58:33 thats basically the runtime compiled bytecode of all discovered controller index() functions Jun 05 14:58:38 ah, which is separate from what the config option turns off. Jun 05 14:58:45 yes, right Jun 05 14:58:53 will look into providing the _() alias everywhere Jun 05 14:59:59 looks like "local _ = luci.i18n.translate or _" at the top of my file works for now.... Jun 05 15:00:44 karlp: if it's of any help, I've added c2 to my ath79 testing devices recently, did quite a lot of sysupgrades from/to ar71xx/ath79 and didnt experienced anything like this Jun 05 15:01:20 ynezz: the c2 dev board they sell/sold? yeah, that's helpful thanks. Jun 05 15:01:30 yes, the devkit Jun 05 15:01:45 I'm still switching back and forth from ar71xx to ath79, bit of a hassle right now, but going to be good down the road :) Jun 05 15:01:47 pushed it to ath79 today Jun 05 15:01:58 oh, our eg200 has been on ath79 for a while :) Jun 05 15:02:16 the only c2 dev kti we have is in use doing other duty, couldn't do much testing with it. Jun 05 15:14:26 karlp: that confused me a bit, because my first association with eg200 is the inteno device (which is broadcom based) ;) Jun 05 15:16:36 blame someone who doesn't work here anymore for picking produc tnames and numbers I guess Jun 05 15:17:22 that inteno one looks newer than ours actually, but what's in a name anyway Jun 05 15:19:23 karlp: try this: http://sprunge.us/xZASRY Jun 05 15:26:32 that patched on 1806 ok, but still fails with "attempt to call global '_' (a nil value)" pointing to the usage of _ in the action() Jun 05 15:27:12 does it need something else from master luci? Jun 05 15:29:55 there shouldn't be needed anything else from master Jun 05 16:28:15 blogic: gmail found your 2/2 dangerous and moved it to spam ("It contains a suspicious link that was used to steal people's personal information. Avoid clicking links or replying with personal information.") Jun 05 16:34:47 KanjiMonster: scary Jun 05 16:35:06 KanjiMonster: i mean using gmail is scary ;-D Jun 05 16:36:42 typo in the description, i have a bad typo day Jun 05 16:46:02 I'm learning to hate auto-correct, between -- => – , smart quotes, correction to something spelled properly, but not what I meant and "Yes, I really meant 'bootargs'" Jun 05 16:47:13 with your example 2/2 patch, that shows how to use the custom toolchain, that's so they can point the openwrt build scripts to their source tree, presumably via a symlink? Jun 05 16:47:33 what does that simplify for them vs having it built externally and the toolchain_external configs? Jun 05 16:48:30 why do we have 3 ssl libs Jun 05 16:48:32 or 4 Jun 05 16:48:41 fair enough., that's a pserfectly suitable answer. Jun 05 16:48:48 thanks. Jun 05 16:49:09 because it is not a project where one person has ultimate power and decides how others should do stuff Jun 05 16:49:24 its about providing a build system that tries to match the needs of those using it Jun 05 16:49:48 in this case there has been a huge gap between commercial and community users due to their closed way of working Jun 05 16:50:02 so I started a discussion to find out what features they are missing Jun 05 16:50:27 one is the ability to build a tollcahin from scratch without having to fork the tree and patch lots of files thus not being future proof Jun 05 16:51:20 the discussion should be about how to solve that specific problem they have better not how you would solve the problem, which infact is a different problem Jun 05 16:51:31 yours is to use a toolchain, which can be binary or some other shape Jun 05 16:51:41 theirs is that it needs to be from source Jun 05 16:54:51 speaking of help, toolchain/Config.in still has LEDE text in it, if anyone wants to update it. Jun 05 16:55:04 karlp: sure, send a patch Jun 05 17:09:30 blogic: ideally custom toolchains would work similar to targets, especially the part where it can come from feeds - that way you can have both the target and the toolchain for it in one place Jun 05 17:12:09 KanjiMonster: spoke with felix, that is exactly what i intended and he explained to me why that is a bad idea Jun 05 17:12:53 however in my 40's I must admit, that the reason slipped my mind, but I recall that it made a lot of sense and I agreed with him that this is a better solution :-D Jun 05 17:12:56 gak, fixed that typo locally, forgot to regenerate the patch file :( sorry about that. Jun 05 17:14:04 KanjiMonster: it had to do with the fact that the toolchain folders are not included by the build system like packages and target folders, thus the parsing code wont work Jun 05 17:14:25 KanjiMonster: and patching that into the tree would be a real pain and cause regressions for a very rarely used feature Jun 05 17:14:36 KanjiMonster: that was the reason, i remembered Jun 05 17:15:05 there is essentially no metadata parsing for toolchains, that part is just raw Makefile foo essentially Jun 05 17:15:30 I do share the notion that feeds would be much better, but require lots and lots of hackery Jun 05 17:15:58 probably a complete redesign on how the toolchain is currently integrated Jun 05 17:16:44 correct Jun 05 17:16:52 turn them into interdependent packages Jun 05 17:17:09 and then use dependency to define the build order which will get tricky due to the gcc variants Jun 05 17:17:28 we would need to either patch the build variant code or duplicate the packages for each one of the gccs Jun 05 17:19:04 ideally adding support for a new gcc version is just throwing a new gcc11 folder in toolchain (or whereever it is suposed to be) Jun 05 17:19:33 correct Jun 05 17:20:02 I'll put thatonto my todo list but it'll take some time, at that point i can drop this patch and update whatever will be inside the prpl tree by then Jun 05 17:20:12 maybe a gsoc-project? ;D Jun 05 17:20:29 we want to pull them into the project, not scare them away Jun 05 17:20:47 there was a gsoc project for an asterisk channel driver for ltp in 2011 (?) Jun 05 17:21:19 amazingly i found out that one ot the ODMs forked it shortly after and has been maintaing, advancing and bug fixing it since and uses it in production Jun 05 17:21:34 it'll be in a public git shortly, we'll just switch over to that one Jun 05 17:21:47 pretty chuffed when i found out Jun 05 17:22:02 oh, that's nice Jun 05 17:22:13 (ltp = ltq?) Jun 05 17:22:26 looks like they added lots of the advanced features and made it work ontop of newer drivers Jun 05 17:22:34 (... = intel ) Jun 05 17:22:49 as i said, bad typo day, its boiling hot in my office Jun 05 17:23:02 nice Jun 05 17:23:12 it's boiling hot everywhere Jun 05 17:23:16 not here :P Jun 05 17:23:32 it's okayis here as well :P Jun 05 17:23:41 so germany is sweating huh Jun 05 17:24:04 The temperature isn't bad here right now (NC, USA), but the humidity is rather hellish today. Jun 05 17:24:15 34.5 degrees (c) here Jun 05 17:24:22 nie Jun 05 17:24:23 (Luckily, everything here has A/C, so not a huge deal.) Jun 05 17:24:24 nice* Jun 05 17:24:33 25° C, no AC Jun 05 17:24:36 boiling hot in myoffice too, but still a bit cool outside (11C), just glass west windows and broken AC. Jun 05 17:24:38 no AC either Jun 05 17:24:42 did get a fan for the first time in my life though Jun 05 17:24:48 KanjiMonster: that's brutal :( Jun 05 17:25:22 having 2 doors on opposite sides of my office is nice. can do without AC until it gets too hot outside Jun 05 17:25:39 26.8C/43% right now Jun 05 17:25:47 Borromini: 34.5 is outside (in the shadow), inside it's "only" 26 Jun 05 17:25:57 anyway, timer for dinner, bbl Jun 05 17:26:01 KanjiMonster: berlin as well? Jun 05 17:26:12 enjoy Jun 05 17:26:45 yeah Jun 05 17:37:54 re my reboot hang, rebuilt back on 4.9.167, reboot reboots every time. will try and bisect it further tomrrow. 4.9.179 hung on reboot, every time on this one. Jun 05 19:52:05 cotequeiroz: ping Jun 05 20:00:10 Pong. Jun 05 20:15:07 mangix: I will have to leave in ~50 minutes. Jun 05 20:21:12 Why do I dread sending patches to Linux? Jun 05 20:22:20 Because Tordvalds awesome outbursts? ;P Jun 05 20:22:54 At least I've got the MTD group as a buffer for those! Jun 05 20:44:17 cotequeiroz: nvm. Jun 05 20:44:45 cotequeiroz: I was going to mention an oniguruma problem, but it seems to not be the case Jun 05 20:45:08 KanjiMonster: booo-hisss /me places order for cool weather for the first week of July Jun 05 20:47:01 russell--: you gonna be in berlin? Jun 05 20:47:34 KanjiMonster: yes Jun 05 20:47:43 ah, nice Jun 05 20:48:04 but if it's a repeat of last year, well get constant 30+ the next few weeks/months Jun 05 20:48:05 russell--: don't get your hopes up. India got a record temperature this year. Jun 05 20:48:19 50 C Jun 05 20:49:33 tomorrow's supposed to be some thunderstorms and heavy rain, so maaaybe <30 a few days Jun 05 20:51:23 git revert global-climate-change Jun 05 20:51:46 sorry, wrong terminal Jun 05 21:19:51 unable to revert - conflicting commit trump-d-elected - -EFAKENEWS Jun 05 21:21:18 Yeah, this is no matrix... or well.. for some ;) Jun 05 22:07:05 i was about to quip that cant revert that because our technological society depends on it... will need to write a patch to make it work without climate destruction :P Jun 05 22:17:23 ldir: :) Jun 05 23:19:23 xback: hi, thanks for looking at the USB issue Jun 05 23:19:51 xback: i was using the supplied USB OTG cable, along with this: https://www.adafruit.com/product/954 (USB to TTL serial cable) Jun 05 23:20:14 so i was using it in host mode Jun 05 23:22:30 i'll try a usb flash drive and report back **** ENDING LOGGING AT Thu Jun 06 02:59:57 2019