**** BEGIN LOGGING AT Thu Mar 19 03:00:02 2020 Mar 19 05:12:09 Slow wifi on 19.07.2 for only mamba device on my fresh build that I specifically curated to be based on the 19.07.2 commit Mar 19 07:35:27 anyone working on reworking the openwrt.org website? Mar 19 07:35:27 ynezz: ? Mar 19 08:00:09 aparcar[m]: who? :) Mar 19 08:00:33 aparcar[m]: the last attempt was done by the Thomas IIRC Mar 19 08:02:09 ynezz: is he here? Mar 19 08:02:22 no, you can reach him on the forum Mar 19 08:02:35 @tmomas Mar 19 08:02:41 or via email Mar 19 08:02:44 thanks Mar 19 08:02:49 just reply to that thread? Mar 19 08:02:57 his approach was to use an off-the-shelf bootstrap theme and colorize it somewhat Mar 19 08:03:10 I think this will not lead to a satisfying result Mar 19 08:03:32 eventually someone somewhere has to sit down and write actual CSS to implement the logo design rules Mar 19 08:03:48 what about a static wiki rendered via markdown :)? Mar 19 08:03:50 no amount of component stacking will get around that Mar 19 08:04:00 why? Mar 19 08:04:10 sounds like yet another component stacking approach to me Mar 19 08:04:30 around what? Mar 19 08:04:31 throw out years of work, replace with a sub-par solution, stop half way end up with something broken Mar 19 08:04:45 what exactly does a static markdown rendered wiki solve? Mar 19 08:06:15 remember that we started with this approach (asciidoc(tor)) at that time Mar 19 08:06:25 it was quickly abandonned because the barrier to entry was way too high Mar 19 08:06:28 simplifies review process, wiki workflow is more similar to working with the openwrt codebase, less maintenance Mar 19 08:06:52 wiki has good review process as well, even reverts :p Mar 19 08:07:06 oh, some people don't like the web editor I heared Mar 19 08:07:26 you cant please everyone Mar 19 08:07:27 the years of work are the content but not the wiki itself, not? Mar 19 08:07:55 yep, but current task at the table is to refresh the wiki style Mar 19 08:08:05 not to rewrite half of the stack :) Mar 19 08:08:22 but...but Mar 19 08:08:27 in the end we still would need a wiki Mar 19 08:08:31 I assume, that its not that hard to use dokuwiki backend, yet make it looking like that alpine site for example Mar 19 08:08:34 so now we have to develope the css twice Mar 19 08:08:38 okay I'll ask thomas about the state and try to make some web person I know work on that Mar 19 08:08:40 once for the markdown, once for the wiki Mar 19 08:09:04 zero effort saved, a lot of new uncertainity and work introduced Mar 19 08:09:10 looks like https://bugs.openwrt.org/index.php?do=details&task_id=296 isn't present (at least on ubnt_bullet-m-ar7240) ... was just trying to see if my experimental dts hackery was even needed, evidence so far is no. Mar 19 08:09:38 jow: what markdown? From my understanding you write markdown once and it is rendered into a wiki Mar 19 08:10:17 AFAIK it's possible to convert freely between markdown a dokuwiki markups Mar 19 08:10:25 so you propose the convert the entire wiki, including all user contributed content to markdown, then from then on only allow edits via pull requests? Mar 19 08:11:41 jow: yea, gitlab/github also support web editors to write in markdown. I'd think whoever understand the dokuwiki syntax easily (if not already) understands markdown Mar 19 08:12:16 sorry, but I am not going to review autogenerated pull requests for wiki pages Mar 19 08:12:30 exactly, another maintenance burden Mar 19 08:14:01 jow: what do you mean by auto generated? the conversion script or the people using gitlab/github web editors? Mar 19 08:14:25 someone would need to merge that stuff Mar 19 08:14:59 aparcar[m]: you claimed an easier review process for changes Mar 19 08:15:05 well someone now has to keep an eye on the recently edited sites on the wiki right now Mar 19 08:15:22 if nobody going to review stuff and any change is simply merged then why do we need it in the first place? Mar 19 08:15:31 what problem does it solve? Mar 19 08:16:29 the wiki was rebooted three or four times throught the last 11 years Mar 19 08:16:40 the end result never changed substatially Mar 19 08:17:05 I doubt that switching to some git-whatever workflow would make a huge difference either Mar 19 08:17:47 and the project would lost a lot of valuable people Mar 19 08:18:16 docs people are not interested in that workflow Mar 19 08:18:45 wiki audience is forum audience, users Mar 19 08:20:35 the power of that wiki engine is not visible until you start using it Mar 19 08:21:32 I don't like that default markup as well, but I don't write the content, so I don't care Mar 19 08:21:56 its close enough to markdown Mar 19 08:22:04 === for headlines, ** for bold etc. Mar 19 08:22:09 not that complicated Mar 19 08:22:25 I usually write my text in an editor anyway and simply copy-paste it Mar 19 08:22:35 then format it as needed Mar 19 08:22:47 What I'd really like to see is all uci option automatically added, even if there's no description. But that's possible with current engine too. Mar 19 08:23:16 from all the packages? Mar 19 08:23:52 Where at all possible, yes. Mar 19 08:29:58 well I haven't been around here over the last 11 years but only know the last iteration. Having this precious Git workflow which has to be ISDN X-less mail compatible but then an entirely different approach for documentation seems like an improvable situation for me. Like bringing devs and actual documenting users more together. Mar 19 08:30:28 yeah but it is wishful thinking Mar 19 08:30:38 the devs still won't work on it and users will be alienated Mar 19 08:32:20 ok Mar 19 08:32:29 I think, that wiki and some (sphinx based?) in the tree, more developer oriented documentation can cooexist Mar 19 08:32:42 sure, it can Mar 19 08:32:57 but 90% of the work is still *writing* it Mar 19 08:33:02 :) Mar 19 08:33:48 maybe we should apply here and get you two paid for that https://developers.google.com/season-of-docs/ Mar 19 08:34:06 I'm not interested, thanks :) Mar 19 08:38:43 jow: did you look at the new luci-app-attendedsysupgrade? I tried it with my current router and it seems to work Mar 19 08:38:46 * russell-- recommends someone read https://en.wikipedia.org/wiki/The_Wiki_Way Mar 19 08:39:06 (the book, not the wiki page about it) Mar 19 08:39:18 russell--: ah :P Mar 19 08:39:20 hehe Mar 19 08:39:52 aparcar[m]: seen it yes. Converting it is on my backlog Mar 19 08:40:13 jow: ack & thanks Mar 19 08:49:02 https://meta.wikimedia.org/wiki/Cunningham%27s_Law Mar 19 08:50:17 russell--: thats how I send patches Mar 19 09:02:16 tmn505: ping Mar 19 09:06:40 lol Mar 19 09:16:24 day 5 - still no zombies Mar 19 09:18:57 no injuries as well? Mar 19 09:29:59 nope Mar 19 09:30:03 boring really ;) Mar 19 09:30:46 I got just another OOPs Mar 19 09:30:46 I was one of those people trying to "reboot" the documentation a few years ago, and it failed Mar 19 09:31:02 it didn't aim at replacing the whole wiki though, just the developer documentation Mar 19 09:31:23 that is, until somebody else came and tried to apply it to the whole wiki... Mar 19 09:31:42 I really think documentation is content first, not format first Mar 19 09:32:05 a bunch of formatted ASCII text files would likely be more than sufficient Mar 19 09:32:23 like RFC documents Mar 19 09:33:16 when the discussion diverges from content to tooling you have managers on the call Mar 19 09:33:58 you mean like browsing the Git repository to access the documentation? Mar 19 09:34:25 ynezz: no I mean focussing on writing documentation and let others deal with presenting the content later on Mar 19 09:34:49 like writing a 20 line php script outpuztting those .txt file as browsable html pages, or batch-reformat them to asciidoc for rendering Mar 19 09:35:11 whats wrong with this approach https://lede.readthedocs.io/en/latest/ ? Mar 19 09:35:17 it's already prepared Mar 19 09:35:23 looks like this was my attempt at the time: https://files.polyno.me/openwrt/doc/ Mar 19 09:35:31 ynezz: nothing Mar 19 09:35:34 source is formatted ASCII text, it's already done Mar 19 09:35:40 but the situation underlines my point excatly Mar 19 09:35:52 three different prepared approaches, still no documentation Mar 19 09:36:13 as I see it, nobody was willing to make a decision Mar 19 09:36:24 so I've this on my TODO list Mar 19 09:36:29 ok, I decide. Lets use https://lede.readthedocs.io/en/latest/ Mar 19 09:36:34 can we write documentation now? :) Mar 19 09:36:39 :) Mar 19 09:36:58 at the moment I start writing ugpiod, I plan to tackle this Mar 19 09:37:53 undecided how to tackle the external C project docs Mar 19 09:38:11 should that be in the master tree or separately in the external project tree? Mar 19 09:38:23 external C project as in uci etc.? Mar 19 09:38:26 yes Mar 19 09:38:30 procd etc. Mar 19 09:38:36 put it in their respective repositories Mar 19 09:38:54 but then you would like to merge it somehow into the master docs Mar 19 09:39:02 to create one place Mar 19 09:39:44 make a cronjob Mar 19 09:39:55 CI job, yes Mar 19 09:39:56 :) Mar 19 09:46:24 +1 for starting with userspace components, it's a well-defined task Mar 19 09:46:43 this is what I had started to work on here: https://files.polyno.me/openwrt/doc/userspace/index.html Mar 19 09:47:12 ah, nice Mar 19 09:47:29 (arguably borrowing a lot from "techref" on the wiki) Mar 19 09:47:50 is it somehow possible to source project inside one project? Mar 19 09:48:27 I mean, having one docs Git repo with Git submodules Mar 19 09:48:45 so the docs for procd could reside inside procd repo Mar 19 09:49:07 and could be used/source inside the main docs repo to create the final all-in-one docs Mar 19 09:49:19 or how would you approach it? Mar 19 09:49:56 openwrt/docs would contain the main/overal/common stuff, including inside procd/docs, ubus/docs etc. Mar 19 09:50:02 sure, you just need to uniformize things a bit (like a "docs/" subfolder in each repo) Mar 19 09:50:28 and either use submodules or script something that gets the doc out of each repo Mar 19 09:50:53 I love how nobody likes my ideas but then it usually shifts in a direction I intended Mar 19 09:50:54 what would be nice is allowing cross-references across repositories Mar 19 09:51:56 what is needed for that? Mar 19 09:52:16 aparcar[m]: the sticking point is the scope: replacing the whole wiki is a bad idea, but starting with developer documentation is much more feasible and desirable Mar 19 09:52:58 zorun: yea I should formulate my ideas better. Mar 19 09:54:04 ynezz: nothing special if all subfolders/submodules are there during HTML generation Mar 19 09:54:31 so that linking to "procd/foo/bar" should work from the main repo Mar 19 09:55:00 well, maybe add symlinks like "procd → repos/procd/docs" to avoid keeping the "docs" in all links Mar 19 09:55:13 I do something similar for the LXR generation Mar 19 09:55:17 it does not look that difficult Mar 19 09:55:25 but making that ref links working during the time is going to be a challenge :) Mar 19 09:55:31 all repos clones somewhere plus a symlink tree which serves as index repo Mar 19 09:57:00 zorun: I assume, that sphinx is somehow able to detect the broken ref links Mar 19 09:57:11 jow: does LXR count as a fourth different approach? :) Mar 19 09:57:32 zorun: I'd say no unless you intend to express documentation as indexable C code Mar 19 09:58:00 https://lxr.openwrt.org/source/procd/ Mar 19 09:58:22 it can be complementary I guess Mar 19 09:58:28 yeah, it happens to render README files if it finds some Mar 19 09:59:50 maybe have a look at https://www.mkdocs.org/ too as it is simpler than sphinx Mar 19 10:00:19 should we vote about it? :) Mar 19 10:01:11 no Mar 19 10:01:43 we're discussing form over content again Mar 19 10:01:54 or you're rather :) Mar 19 10:02:10 pick one stick to it and populate Mar 19 10:02:30 well, that was my point Mar 19 10:02:31 So but agreeing on Markdown could be a step Mar 19 10:02:31 presumably it is easier to convert into something else if the content is in some form of markup/down to begin with Mar 19 10:02:38 *easy Mar 19 10:03:26 the requirements are simple too: needs to support tables, lists, some basic formatting (bold, italic, underline, strike through), preformatting single- and multiline Mar 19 10:03:31 ability to embed pictures Mar 19 10:03:47 maybe syntax highlighting for preformatted blocks Mar 19 10:04:18 I guess all available tools handle that Mar 19 10:05:04 aparcar[m]: mkdocs looks nice Mar 19 10:07:11 I remember that Sphinx had a page explaining why markdown was a bit idea, but I can't find it again Mar 19 10:12:33 hmm. more data rolling in (repeatedly rebooting ubnt_bullet-m-ar7240) some fraction of the time eth0 just doesn't come up, but when it does, it's almost always (one case out of ~100-ish with 10Mbps/HalfDuplex) 100Mbps. I have a script toggling the PoE gpio on an erx to power cycle the bullet Mar 19 10:13:30 anyway, +1 for markdown, it's definitely easier to write than ReST... Mar 19 10:14:32 ah, yeah, here's an example of what i see when it fails: [ 31.746937] Generic PHY mdio.0:1f:04: Master/Slave resolution failed, maybe conflicting manual settings? Mar 19 10:53:04 day 3 and my freenas thumbdrive fails on me. Murphy's law. Mar 19 10:58:22 no zfs redundancy? Mar 19 11:06:37 russell--: not on the boot drive. I was lazy and assumed I'd be willing to shoulder a reinstall + config reupload, which is what I'm doing now. Mar 19 11:06:49 all the while ordering some more drives to setup redundancy :) Mar 19 15:03:22 asked this but Colloquy crashed so I didn’t see the answer… what’s a good forum to discuss tc and traffic shaping? I’m trying to use htb to split bandwidth between my production network and my guest network, but I want unused bandwidth from the guest network to be available to the production network. Mar 19 17:58:00 jow: ping Mar 19 18:16:50 russell--: ath9k_htc works on BBB if kernel is built with CONFIG_MUSB_PIO_ONLY=y instead of CONFIG_USB_TI_CPPI41_DMA=y Mar 19 18:17:45 Hey ldir. Is it possible you know useful links for philipp64's question? Mar 19 18:20:52 PaulFertser: I'm afraid I don't. It's a good question and I don't know how I'd solve it. Mar 19 18:22:34 I'd have more questions though, namely, is the guest network guaranteed to have a certain bandwidth? Is it ok for the guest network to exceed its allocation as long as the production network doesn't need it. Mar 19 18:23:29 I'd basically say "production net has higher priority than guest" and the actual bandwidths are immaterial. Mar 19 18:25:25 ldir: can't speak for philipp64 but I've been contemplating similar setups in the past and usually it's the other way around: the prod network must have guaranteed minimum bw; the guest cannot borrow, but the reverse is possible (prod can borrow on guest) Mar 19 18:26:40 yes, so if production has higher priority then that is satisfied. The question is can 'prod' starve 'guest' completely. Mar 19 18:27:37 usually it's not satisfied if guest can borrow on prod. Typically you don't want guest to be able to exceed a maximum bw Mar 19 18:28:15 this also has latency implications (guaranteed bw for prod that guest cannot use means that when prod goes from idle to loaded there's no latency while the shaper "adjusts") Mar 19 18:33:14 f00b4r0 wan3? Mar 19 18:33:41 in reverse Mar 19 19:10:25 PaulFertser: thanks, i'll try that. Mar 19 19:10:47 ldir: I’m thinking that “guest” can use up to X amount of bandwidth, but if “guest” doesn’t use it, “production” should get it back. production should always have at least (total - X). Mar 19 19:26:35 ldir: pong Mar 19 19:27:33 jow: Can we arrange a time to talk about SSL certs? Mar 19 19:28:08 yes, tomorrow would be suitable Mar 19 19:28:21 great - any particular time? Mar 19 19:28:34 I'm free most of the day Mar 19 19:28:40 1-2pm Mar 19 19:28:58 is that GMT or CET ? Mar 19 19:29:06 cet :P Mar 19 19:29:12 sorry Mar 19 19:29:30 no problem :-) Glad I asked! Mar 19 19:29:46 12-1300 ish GMT Mar 19 22:16:25 blogic: you around? Mar 19 22:22:24 PaulFertser: no panics (so far), but: http://paste.debian.net/1135659/ Mar 19 22:38:51 is there a uci mechanism for specifying flags? e.g. in "iw phy0 interface add mon0 type monitor flags fcsfail otherbss" the fcsfail and otherbss part? Mar 19 22:50:39 package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh ... looks like no Mar 19 23:58:43 Hauke: ping **** ENDING LOGGING AT Fri Mar 20 02:59:57 2020