**** BEGIN LOGGING AT Sun Jan 12 02:59:58 2020
Jan 12 03:12:19 <m4t> any way to keep the kernel modules from getting repackaged on a simple 'make package/somepackagename/compile' ?
Jan 12 03:15:30 <m4t> https://paste.ee/p/qGmy1#GrsWcsArVESZhfRa4CIh0cawudFVi6xd
Jan 12 03:15:33 <m4t> :(
Jan 12 03:16:43 <m4t> and for whatever reason the checksums on all the .ipk changed even though they weren't rebuilt
Jan 12 03:17:33 <m4t> actually - i take the checksum thing back - i thought i was ignoring mtime with rsync by adding -c, but i also had -avp, which was needed to update the mtime on the remote side
Jan 12 03:17:43 <m4t> kmod packages were likely identical
Jan 12 08:26:16 <m4t> is https://github.com/openwrt/packages/blob/master/net/mstpd/files/etc/init.d/mstpd.init#L93 correct? it doesn't seem to ever get triggered after starting the daemon
Jan 12 08:26:58 <m4t> looking at procd, it does service_event("instance.stop", in->srv->name, in->name) whereas there is also this used trigger_event("instance.update", b.head);
Jan 12 08:27:35 <m4t> can you use procd_add_raw_trigger for a service_event() just the same as a trigger_event()?
Jan 12 08:29:35 <m4t> seems, no, you can't. service_event() just does ubus_event_bcast() where trigger_event() actually seems to execute something in response i.e. json_script_run()
Jan 12 08:49:05 <PaulFertser> Is there any reason to not enable *STBC* ht_capab by default?
Jan 12 08:52:49 <PaulFertser> Another related question: when I shouldn't enable short GI?
Jan 12 08:59:27 <PaulFertser> I see RX-STBC seem to be always auto-enabled. But TX-STBC is not, how one is supposed to decide whether it's good or bad to enable?
Jan 12 09:01:07 <PaulFertser> https://openwrt.org/docs/guide-user/network/wifi/basic doesn't seem to list any options that directly affect the generated ht_capab list :(
Jan 12 09:02:39 <PaulFertser> I can't add them myself because I'd like to see some reasonable advice there, not just the options. E.g. I can't even tell in what cases short GI is bad.
Jan 12 09:06:27 <PaulFertser> I guess I'm also confused because before "wifi detect" would automatically put everything in /etc/config/wireless and now they're not there but automatically added to hostapd.conf on generation, so much less visible.
Jan 12 09:10:30 <PaulFertser> You want me to just believe that whoever changes mac80211.sh puts right defaults in there, right? :)
Jan 12 09:38:01 <Pepe> I'm trying to vote for new OpenWrt logos, but I'm pressing button "Vote now!" and it does nothing. Is there any way how to check that I voted? The number of voters is not increased.
Jan 12 09:39:56 <Pepe> Ofc, I tried logout, signin again and also different browser.
Jan 12 09:45:47 <mangix> where is this logo?
Jan 12 09:45:58 <Borromini> https://forum.openwrt.org/t/refresh-project-identity-new-openwrt-project-logo/52072/33 < mangix
Jan 12 09:53:13 <Pepe> mangix:  https://forum.openwrt.org/t/refresh-project-identity-new-openwrt-project-logo/52072
Jan 12 09:53:25 <Pepe> oh, Borromini was again faster. :D
Jan 12 09:53:30 <Borromini> :P
Jan 12 09:53:38 <mangix> I don't like these logos.
Jan 12 09:53:49 <Borromini> hehehe
Jan 12 09:53:59 <Borromini> i like the bird one, but it could use some tweaking
Jan 12 09:54:57 <mangix> C1's the best looking one, but I still don't like it.
Jan 12 09:58:43 <mangix> YBH they all look like snake oil logos
Jan 12 09:58:49 <mangix> *TBH
Jan 12 09:59:25 <mangix> speaking as someone who can't create anuthing better
Jan 12 10:23:41 <pkgadd> Pepe: you need to select your choice first (hit the checkbox in front of the logo), vote now just submits your previous selection
Jan 12 10:25:27 <Pepe> Yes, I know, but it still does not work. :/
Jan 12 10:43:53 <Borromini> Pepe: no script blocking extensions or anything active?
Jan 12 10:47:19 <Pepe> Nope. Tried even that one. =/ Let's hope I'm counted as voter. Would be good if it "Vote now" button disappears or at least said "You voted", but that's problem of the plugin used in Discourse.
Jan 12 11:05:14 <mangix> try clearing cookies
Jan 12 11:05:31 <mangix> ah i see you tried that
Jan 12 11:05:59 <mangix> Maybe try a VPN.
Jan 12 11:15:19 <zorun> when I voted, the vote counter immediately increased, but there was no other indication (the button stayed the same, and there was no message)
Jan 12 12:11:17 <ynezz> looking forward to see the voting results
Jan 12 13:39:46 <owrt-snap-builds> build #262 of octeontx/generic is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/octeontx%2Fgeneric/builds/262  blamelist: Tobias Schramm <tobleminer@gmail.com>
Jan 12 13:43:41 <owrt-snap-builds> build #263 of ath25/generic is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/263  blamelist: Tobias Schramm <tobleminer@gmail.com>
Jan 12 14:01:40 <owrt-snap-builds> build #260 of oxnas/ox820 is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/260  blamelist: Tobias Schramm <tobleminer@gmail.com>
Jan 12 14:04:25 <KanjiMonster> blocktrron: ^
Jan 12 14:23:25 <owrt-snap-builds> build #258 of at91/sam9x is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/258  blamelist: Tobias Schramm <tobleminer@gmail.com>
Jan 12 14:28:07 <olmari> Is there an way to "force" openwrt to keep IPv6 subnetting and so on when using 6in4 tunnel?
Jan 12 14:28:58 <olmari> Or the rootissue is that if wan is for wahtever reason borked, out LAN stops working too (with all of the diffirent VLANs and subnetting), and I think rootcause is that we do have 6in4 tunnel and when wan goes, so goes ipv6
Jan 12 14:30:45 <blocktrron> KanjiMonster: will look into it
Jan 12 14:30:47 <DonkeyHotei> obviously you cannot use 6in4 wan without ipv4 wan
Jan 12 14:32:19 <olmari> DonkeyHotei: I know IPv6 address will fail (from/to internet) at the moment WAN is down, but in this location there should be no need to touch anything in lan side if wan has issues, it will become back when it does
Jan 12 14:32:46 <DonkeyHotei> lan side should also have ula addresses
Jan 12 14:32:57 <olmari> I don't so much care about IPv6 in itself on the failure moment, but whole LAN is down so to speak, all the subnetting does not reach anywhere and all
Jan 12 14:33:44 <olmari> which I suspect happends because of 6in4 tunnel and how it works to downstream
Jan 12 14:34:38 <olmari> --> 6in4 tunnel goes away (with wan fail), owrt fiddles with LAN side so much there disappears all subnetting and whatnot there is
Jan 12 14:34:52 <olmari> subnetting == VLANs and zone forwards and so on
Jan 12 14:35:44 <olmari> I will be testing more on some time within the next week, but this is irritating situation
Jan 12 14:36:26 <olmari> as the WAN is LTE on that location... no amount of good modemds will help when even on occasional fast WAN-hiccup even all of LAN is kinda useless
Jan 12 14:36:36 <DonkeyHotei> lan side should also have ula addresses
Jan 12 14:36:57 <olmari> and I will fully accept it's PEBKAC...
Jan 12 14:37:13 <olmari> I think it has, but need to add that to the checklist
Jan 12 14:38:44 <olmari> That being said, I also feel in this case in general the IPv6 LAN-side config could be made "static" as address and address-space is always the same, it doesn't matter if tunnel is down for the LAN-side
Jan 12 14:39:12 <olmari> ..which is not exactly same thing, but relating thing to this issue :)
Jan 12 14:40:22 <SwedeMike> olmari: RFC7084 says to announce GUA with zero lifetime in case of WAN failure.
Jan 12 14:40:51 <SwedeMike> so that clients stop using those addresses for new connections
Jan 12 14:41:42 <olmari> well I can live very much with said IPv6 addressing even being gone, but I don't ge why all of the lan dies, no zones forward that should, on any IP-version
Jan 12 14:41:59 <SwedeMike> yeah, that shouldn't happen.
Jan 12 14:42:08 <DonkeyHotei> SwedeMike: is that why tcp connections don't resume on wan restoration on ipv6 like they do on ipv4?
Jan 12 14:42:12 <SwedeMike> IPv4 and ULA should still work
Jan 12 14:42:40 <SwedeMike> DonkeyHotei: errr... they do?
Jan 12 14:43:19 <SwedeMike> DonkeyHotei: existing connections should not be torn down when this happens
Jan 12 14:43:39 <SwedeMike> DonkeyHotei: what operating system are you experiencing this in?
Jan 12 14:43:49 <DonkeyHotei> gnu/linux
Jan 12 14:44:00 <olmari> That is the root issue I'm having, but at this moment I can only guess and dig further what causdes it, so far I've narrowed my suspections to said 6in4 tunnel and further distribution downstream, but at this time I can't be on premises to dig and I figured I might as well try ask here if any insights.. and there already has =)
Jan 12 14:44:21 <DonkeyHotei> (on windows they always got torn down even on ipv4)
Jan 12 14:44:48 <SwedeMike> DonkeyHotei: if there is no connection manager doing anything special, the linux kernel is very hesitant to tear down a connection.
Jan 12 14:45:23 <DonkeyHotei> i attributed it to be related to dhcpv6
Jan 12 14:46:20 <SwedeMike> DonkeyHotei: dhcpv6 addresses aren't even deconfigured when this happen, they have their own lifetime.... unless of course again the connection manager does something
Jan 12 14:46:34 <DonkeyHotei> i no longer have a native ipv6 connection, but during the two periods that i had one, this was my experience
Jan 12 14:56:20 <olmari> To reiterate, root issue is that all zone forwarding and whatnot relating alltogether on all of LAN-side gets practically nonexistant when there is WAN-hiccup (2 physical ethernet adapters on the x86 machine), there is managed switch on network having VLAN config, but it isn't routing one, so openwrt router is the actual thing doing zone forwads and whatnot
Jan 12 14:56:51 <olmari> ..but it also indeed means that when openwrt does not like something.. yeah :)
Jan 12 14:57:41 <DonkeyHotei> [Sun 2020-01-12 06:42:11 AM PST] <SwedeMike> IPv4 and ULA should still work
Jan 12 14:59:01 <olmari> DonkeyHotei: should, they don't... it's like owrt shuts down all of lan in parctical means (I don't know what really happends).. no ping reach across zones and so on
Jan 12 15:00:14 <olmari> also AFAIK router is "unavailable" from any IP from any zone (that is normally accessible) too, which feels extra odd, but streghtens the thing that owrt does something
Jan 12 15:00:42 <olmari> switch keeps working, all of things on their respective VLANs can reach eachothers
Jan 12 15:38:06 <owrt-snap-builds> build #253 of arc770/generic is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/253  blamelist: Tom Brouwer <tombrouwer@outlook.com>, Christian Lamparter <chunkeey@gmail.com>, Tobias Schramm <tobleminer@gmail.com>
Jan 12 15:52:35 <owrt-snap-builds> build #247 of pistachio/generic is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/247  blamelist: Tom Brouwer <tombrouwer@outlook.com>, Christian Lamparter <chunkeey@gmail.com>, Tobias Schramm <tobleminer@gmail.com>
Jan 12 16:30:23 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Jan 12 16:43:11 <owrt-snap-builds> build #235 of at91/sama5 is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/235  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Tom Brouwer <tombrouwer@outlook.com>, David Bauer <mail@david-bauer.net>, Christian Lamparter <chunkeey@gmail.com>, Tobias Schramm
Jan 12 16:43:11 <owrt-snap-builds> <tobleminer@gmail.com>
Jan 12 17:04:53 <owrt-snap-builds> build #228 of layerscape/armv8_64b is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/228  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Tom Brouwer <tombrouwer@outlook.com>, David Bauer <mail@david-bauer.net>, Christian Lamparter <chunkeey@gmail.com>,
Jan 12 17:04:54 <owrt-snap-builds> Tobias Schramm <tobleminer@gmail.com>
Jan 12 17:16:57 <ynezz> IANAL, can I change From: to match SoB: ? From: Dainis Jonitis <jonitis@gmail.com> Signed-off-by: Dainis Jonitis <dainis.jonitis@ubnt.com>
Jan 12 17:17:38 <Hauke> ynezz: I did this multiple times
Jan 12 17:18:01 <ynezz> I just remember some horror story with some revert in the past, so just cross-check
Jan 12 17:18:04 <ynezz> :)
Jan 12 17:18:08 <ynezz> thanks
Jan 12 17:19:36 <ynezz> perhaps that revert was due to missing SoB (don't remember)
Jan 12 17:20:57 <owrt-snap-builds> build #241 of ramips/rt3883 is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/241  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Tom Brouwer <tombrouwer@outlook.com>, David Bauer <mail@david-bauer.net>, Christian Lamparter <chunkeey@gmail.com>, Tobias Schramm
Jan 12 17:20:57 <owrt-snap-builds> <tobleminer@gmail.com>
Jan 12 18:20:03 <owrt-snap-builds> build #239 of mediatek/mt7623 is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/239  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Tom Brouwer <tombrouwer@outlook.com>, David Bauer <mail@david-bauer.net>, Christian Lamparter <chunkeey@gmail.com>, Tobias
Jan 12 18:20:03 <owrt-snap-builds> Schramm <tobleminer@gmail.com>
Jan 12 18:31:17 <jow> ynezz: that discussion was about adding a sob on the authors behalf on good faith, which turned into a discussion on principles
Jan 12 18:31:23 <jow> so we ended up simply reverting that commit
Jan 12 19:23:49 <jow> ynezz: please don't bump libubox without adding an soversion first this time
Jan 12 19:24:06 <jow> just seen that you've taken that 64bit int patch
Jan 12 19:41:43 <ynezz> jow: thanks for reminder, https://gitlab.com/ynezz/openwrt-libubox/commit/708337b911446e077e2a4b01c31cb46b1bfcdbb4
Jan 12 19:45:40 <ynezz> (untested currently, will test it once I prepare the version bump in the main tree)
Jan 12 19:49:18 <jow> ynezz: I'd suggest SOVERSION == VERSION
Jan 12 20:10:55 <aparcar[m]> looks like we missed the step to a 21th century open source project https://news.ycombinator.com/item?id=22018408 heh
Jan 12 20:11:58 <aparcar[m]> Hauke: I"ve never worked with the openwrt.org/toh except when parsing it for https://aparcar.github.io/openwrt-devices/
Jan 12 20:16:48 <aparcar[m]> looking at 2090b8af0a2a796343523e686797c6dd861ed4bf (and many other device addings) it would be convinient to have the device data already in YAML so it's allows (semi)automatic creation of these devices tables. woul it make sense to define this as a "rule"?
Jan 12 20:22:02 <karlp> aparcar[m]: where in that big ycombinator link is this "21th century" thing?
Jan 12 20:25:22 <aparcar[m]> karlp: more like reading between the lines :)
Jan 12 20:27:17 <karlp> maybe I don't understand what you mean by becoming a 21st centrury open source project either then :)
Jan 12 20:27:20 <jow> "the project sucks because people wanted me to fix whitespace and add a S-o-b to my drive by PR"
Jan 12 20:27:26 <karlp> openwrt's much better than it was.
Jan 12 20:27:31 <jow> thats what I read between the lines
Jan 12 20:27:41 <karlp> but it will take a long time to erase some of those memories for some people.
Jan 12 20:27:58 <karlp> keeping the brand keeps those memories too
Jan 12 20:28:45 <rotanid> not keeping the brand in term leaves people behind, see libreoffice
Jan 12 20:28:59 <rotanid> maybe just ignore the noise on ycombinator? ^^
Jan 12 20:29:09 <karlp> I know, I was for keeping the brand, it just has it's downsides :)
Jan 12 20:29:38 <jow> also is the mailing list really that hostile?
Jan 12 20:29:46 <karlp> certainly not now.
Jan 12 20:29:47 <jow> I thought the main complaint is the lack of any feedback
Jan 12 20:29:53 <karlp> I feel that's all old memories stuff.
Jan 12 20:30:49 <karlp> I mean, it's still a mailing list, so that's still automatically horrible for lots of people :)
Jan 12 20:32:15 <ynezz> aparcar[m]: welcome back, you got electricity finally? :p
Jan 12 20:33:15 <aparcar[m]> ynezz: heavy storms here 🙂 I got all cought up in other stuff but hopefully spend more time at the lovely openwrt community again
Jan 12 20:34:46 <owrt-snap-builds> build #249 of ramips/rt288x is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/249  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Tom Brouwer <tombrouwer@outlook.com>, David Bauer <mail@david-bauer.net>, Christian Lamparter <chunkeey@gmail.com>, Tobias Schramm
Jan 12 20:34:46 <owrt-snap-builds> <tobleminer@gmail.com>
Jan 12 20:35:46 <ynezz> I think, that 200pts on HN is very nice, so it was probably on the front page for some time as well
Jan 12 20:40:07 <ynezz> not commenting on comments :)
Jan 12 20:41:22 <ynezz> some complaints seems legit, reminds me whats the status of openwrt-announce@ ?
Jan 12 20:43:37 <ynezz> this https://news.ycombinator.com/item?id=22019903 is probably FS#2423
Jan 12 20:45:59 <ynezz> it's quite interesting, that nobody has mentioned Rust as it's quite common on HN
Jan 12 20:46:48 <Tapper> The openwrt community is much better than it was in the old days.
Jan 12 20:47:05 <Tapper> I mene you lot put up with my spelling for one thing! lol
Jan 12 20:47:33 <DonkeyHotei> it was more tolerant in the old days
Jan 12 20:48:00 <ynezz> DonkeyHotei: what does it mean?
Jan 12 20:48:09 <aparcar[m]> I think we should inform more tech sites, lwn.net posted something ( jow https://lwn.net/Articles/809225/ ) however sites like heise.de, golem.de or even distrowatch.org haven't posted anything
Jan 12 20:48:34 <Tapper> We all could remember to be as nice as we can to people and explain what we need from them to get there packages or fixes in to openwrt
Jan 12 20:49:37 <aparcar[m]> Also I think people prefer bots telling them about bad code style then humans, I don't know why..
Jan 12 20:50:16 <ynezz> its too personal
Jan 12 20:50:58 <aparcar[m]> so let's spawn some more bots
Jan 12 20:51:12 <aparcar[m]> less humans = more community
Jan 12 20:52:31 <blocktrron> :D
Jan 12 20:53:09 <ynezz-bot> now, that was too clanish
Jan 12 21:02:13 <Borromini> lol
Jan 12 21:14:09 <Hauke> after sending the 19.07 announcement to the mailing list I informed, lwn, phoronix and heise
Jan 12 21:14:45 <Hauke> I think lineageos generates the device wiki pages automatically
Jan 12 21:15:01 <Hauke> at least we need the possibility to update the how to flash partt
Jan 12 21:15:57 <DonkeyHotei> the lineageos device wiki is not a good role model
Jan 12 21:20:17 <aparcar[m]> DonkeyHotei: why not?
Jan 12 21:21:14 <DonkeyHotei> most of the useful info that is device-specific is completely absent from it
Jan 12 21:22:12 <DonkeyHotei> apparently as a side effect of the way they generate the pages automatically
Jan 12 21:22:54 <aparcar[m]> DonkeyHotei: I like to have as much as possible generic based on templates but still alow custom comments or device specific info, what do you think?
Jan 12 21:23:26 <DonkeyHotei> we already have the hwdata pages
Jan 12 21:24:16 <aparcar[m]> right now we have like 5 (maybe 20) different step by step installation for tp-routers, which boil all down to the same.  A single template could solve a lot a maintainance
Jan 12 21:25:42 <aparcar[m]> DonkeyHotei: so this is a page rendered on metadata, https://aparcar.github.io/openwrt-devices/devices/tp-link_tl-wdr4300/ The installation uses a template. Comments are also possible. Anyone who owns this device or considers to get it finds the information at a single "clean" place
Jan 12 21:26:29 <aparcar[m]> The Wiki partly merges, partly duplicates these information, which becomes always a tedious research job to know what is the most recent info
Jan 12 21:27:02 <DonkeyHotei> that page is not so different from hwdata
Jan 12 21:27:52 <DonkeyHotei> it's kinda in between hwdata and the lineageos device wiki
Jan 12 21:28:05 <aparcar[m]> DonkeyHotei: yes because it scraped the hwdata 🙂 however it unites all relevant info
Jan 12 21:28:18 <aparcar[m]> DonkeyHotei: yes the design is borrowed from lineage os until we have our own
Jan 12 21:28:56 <DonkeyHotei> scraping is not needed since hwdata is a database already
Jan 12 21:31:53 <aparcar[m]> DonkeyHotei: with no api afaik
Jan 12 21:32:43 <DonkeyHotei> i'm sure there is something
Jan 12 21:33:05 <aparcar[m]> DonkeyHotei: anyway that is not the point, my point i sto simplify the overview and make it more appealing. The current one may be functional and treasure of knowledge, however not easily usable for new people
Jan 12 21:34:45 <DonkeyHotei> not to mention incomplete
Jan 12 21:35:33 <DonkeyHotei> there is absolutely no git to wiki pipeline
Jan 12 21:36:04 <DonkeyHotei> that would be ideal
Jan 12 21:47:55 <aparcar[m]> DonkeyHotei: I just wrote a mail for that on openwrt-devel, please comment
Jan 12 21:50:26 <aparcar[m]> ynezz-bot: please comment as well
Jan 12 21:51:18 <ynezz> IIRC I've commented previous attempt
Jan 12 21:52:02 <ynezz> anyway, having it in separate YAML file makes more sense, as you can validate easily then in the commit description
Jan 12 21:53:12 <ynezz> YAML is PITA, so some automatic help in the form of `make lint-yaml-descriptions` could make maintainer's life easier
Jan 12 21:53:55 <ynezz> theres some ongoing YAML party in kernel, so lets steal something (good parts) from them
Jan 12 21:54:17 <aparcar[m]> where is the yaml party_
Jan 12 21:54:19 <aparcar[m]> ?
Jan 12 21:55:13 <ynezz> kernel tree
Jan 12 21:57:15 <aparcar[m]> ack
Jan 12 21:57:30 <DonkeyHotei> aparcar[m]: http://lists.infradead.org/pipermail/openwrt-devel/2020-January/021175.html
Jan 12 21:58:00 <aparcar[m]> ynezz: you have an idea how to integrate dt linting in "the" ci? https://www.spinics.net/lists/devicetree-compiler/msg02791.html
Jan 12 22:00:54 <ynezz> aparcar[m]: sure, `make ci-lint-dts` :)
Jan 12 22:01:41 <ynezz> its a looot of work hidden in the details
Jan 12 22:01:57 <ynezz> if it should be usable
Jan 12 22:02:33 <aparcar[m]> So I just bump that dts thred and hope they fix it
Jan 12 22:03:19 <ynezz> oh, this is "just" code style check, right?
Jan 12 22:04:49 <aparcar[m]> ynezz: I'm having the bot community in mind
Jan 12 22:20:24 <ynezz> aparcar[m]: right, but then you'll get "they're bot community is hostile" :)
Jan 12 22:20:32 <ynezz> s/they're/their/
Jan 12 22:20:56 <aparcar[m]> no I
Jan 12 22:20:57 <ynezz> what about some automagic solution for maintainers?
Jan 12 22:21:23 <ynezz> make check-fix-last-commit
Jan 12 22:21:31 <aparcar[m]> no I'm sure it won't work like that. Just add an account called openwrt-bot and make your comments, stick to templates and nobody will be offended by style comments
Jan 12 22:22:22 <ynezz> yep, which would result in X new PRs for every whitespace change :)
Jan 12 22:22:28 <ynezz> in some cases
Jan 12 22:26:03 <ynezz> so just fix the whitespace "mess", ammend the commit and add [fixed DTC style issues] comment, done
Jan 12 22:29:53 <DonkeyHotei> ynezz: well, in that regard, github PR's are an improvement over patchwork
Jan 12 22:56:57 <mangix> ynezz: was rpcd crashing fixed yet?
Jan 12 22:59:47 <ynezz> mangix: uh, whats wrong?
Jan 12 23:00:00 <mangix> do_page_fault(): sending SIGSEGV to rpcd for invalid read access from 39383830
Jan 12 23:00:08 <ynezz> ok, and?
Jan 12 23:00:17 <mangix> I can't access LuCI because of this
Jan 12 23:00:30 <mangix> it's definitely related to all of these "cleanups"
Jan 12 23:00:41 <ynezz> which cleanups?
Jan 12 23:00:55 <mangix> libubox and whatnot
Jan 12 23:02:08 <mangix> https://gist.github.com/neheb/903d07b5f7b7e9796e026bafe819d68c then it asks me to login again.
Jan 12 23:02:32 <ynezz> ok, I'm about to go into bed
Jan 12 23:02:52 <ynezz> if you can provide something more useful then this, I can take a look at it next week
Jan 12 23:03:31 <ynezz> something I can reproduce here should be enough :)
Jan 12 23:03:53 <ynezz> versions, hardware, etc.
Jan 12 23:03:55 <mangix> It's probably because my builds use -O2 instead of -Os
Jan 12 23:06:09 <ynezz> whatever, just open bug on bugs.openwrt.org
Jan 12 23:07:55 <ynezz> oh wait, it's crash in luci.so
Jan 12 23:08:23 <mangix> oh you're right
Jan 12 23:09:10 <stintel> try making sure if it's -O2 vs -Os and add that info to the bugtracker ?
Jan 12 23:09:38 <stintel> ynezz: have a good night :)
Jan 12 23:09:54 * stintel back in Sofia
Jan 12 23:10:31 <mangix> reminds me of this: https://github.com/openwrt/openwrt/pull/2045#issuecomment-515789136
Jan 12 23:10:53 <mangix> I build with only -O2. None of the other options
Jan 12 23:11:57 <mangix> -O2 -mips32r2 -mtune=74kc . There we go.
Jan 12 23:13:38 <DonkeyHotei> i once found a package that broke only with -O3
Jan 12 23:25:40 <stintel> just one? :P
Jan 12 23:35:24 <DonkeyHotei> hmm, can't find the fix commit in git log
Jan 13 00:35:53 <Hauke> mangix: did you check in which line it is failing?
Jan 13 00:36:17 <Hauke> the log message shows the EPC and RA address and the offset in the luci.so
Jan 13 00:36:27 <Hauke> with these information you can get the line from gdb
Jan 13 01:00:15 <owrt-snap-builds> build #189 of brcm63xx/smp is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/brcm63xx%2Fsmp/builds/189
Jan 13 01:14:14 <mangix> Hauke: no idea how that's done
Jan 13 02:35:17 <owrt-1907-builds> build #82 of zynq/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/zynq%2Fgeneric/builds/82  blamelist: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
**** ENDING LOGGING AT Mon Jan 13 02:59:57 2020