<mangix>
not mentioned in the commit message is that ccache is broken with it, as I later found out.
hbug__ has joined #openwrt-devel
hbug_ has quit [Ping timeout: 240 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
lukedashjr has joined #openwrt-devel
luke-jr has quit [Ping timeout: 265 seconds]
luke-jr- has joined #openwrt-devel
lukedashjr has quit [Ping timeout: 240 seconds]
luke-jr- is now known as luke-jr
ByteEnable has quit [Quit: Leaving]
Nyakajima has quit [Excess Flood]
Nyakajima has joined #openwrt-devel
SergioCabral has joined #openwrt-devel
victhor has quit [Ping timeout: 264 seconds]
Tusker has joined #openwrt-devel
dxld has quit [Quit: Bye]
dxld has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 240 seconds]
luke-jr has quit [Ping timeout: 256 seconds]
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 260 seconds]
<aparcar[m]>
mangix: okay I'll check it out
luke-jr has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<russell-->
has anyone heard from KanjiMonster recently? looks like, other than join/quits in the channel, he fell off the edge of the planet back in March or so
valku has joined #openwrt-devel
daregap has joined #openwrt-devel
nitroshift has joined #openwrt-devel
dorf_ has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
kakaka has quit [Remote host closed the connection]
kakaka has joined #openwrt-devel
dorf_ has quit [Remote host closed the connection]
dorf_ has joined #openwrt-devel
goliath has joined #openwrt-devel
DeX77 has quit [Ping timeout: 240 seconds]
DeX77 has joined #openwrt-devel
<mangix>
didn't know the planet had an edge
philipp64 has joined #openwrt-devel
mattsm has quit [Killed (kornbluth.freenode.net (Nickname regained by services))]
mattsm has joined #openwrt-devel
Tusker has quit [Ping timeout: 256 seconds]
dorf has joined #openwrt-devel
decke has joined #openwrt-devel
dorf_ has quit [Remote host closed the connection]
aptanet has quit [Ping timeout: 240 seconds]
nast has quit [Read error: Connection reset by peer]
aptanet has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dedeckeh has joined #openwrt-devel
dorf has joined #openwrt-devel
Tusker has joined #openwrt-devel
valku has quit [Quit: valku]
Ycarus has joined #openwrt-devel
aptanet has quit [Ping timeout: 260 seconds]
whaletales has joined #openwrt-devel
agb has quit [Ping timeout: 260 seconds]
agb has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
quark_ has quit [Ping timeout: 272 seconds]
ivanich has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
quark_ has joined #openwrt-devel
eduardas has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
quark_ has quit [Read error: Connection reset by peer]
quark_ has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
nitroshift has joined #openwrt-devel
zjason has quit [Ping timeout: 272 seconds]
feriman has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
victhor has joined #openwrt-devel
adrianschmutzler has joined #openwrt-devel
<Tusker>
adrianschmutzler: good morning Adrian, wanted to check with you in regards to PR 3380, in regards to eth0 vs eth1, WAN vs LAN, and what the standard practise is for OpenWRT policy ?
dorf has joined #openwrt-devel
<adrianschmutzler>
Tusker: The standard policy is make it like the vendor does, if possible
<adrianschmutzler>
(and reasonable)
<adrianschmutzler>
but I haven't read your most recent comment yet
<Tusker>
let me check my notes for when I was running factory firmware
<adrianschmutzler>
The commit message at least states that the MAC addresses are from vendor firmware
<adrianschmutzler>
and with a switch it's typically not a problem to identify lan/wan
<adrianschmutzler>
the latter is typically only a problem for two-port devices
<adrianschmutzler>
but let me just go through my mails and maybe discuss that in half an hour
<Tusker>
OK, sure, will stand by
dangole has quit [Remote host closed the connection]
<Tusker>
factory firmware has LAN linked to eth1 showing up in the br0 bridge, so it at least matches the factory firmware.
<Tusker>
anyway, I need to get some sleep, will respond to any question/query/concern on github when you have some time
<adrianschmutzler>
maybe it's just fine now and I merge it :-)
<adrianschmutzler>
but I have to do this carefully, otherwise you can never be sure whether you have a +1/-1 in the right place
<Tusker>
let me know, I can test anything you want
<Tusker>
I have uart connected
<adrianschmutzler>
I will have a look shortly. but you may leave, I don't think another day delay will be a problem here
<adrianschmutzler>
btw, what was the conclusion out of the two related versions?
<adrianschmutzler>
f9j1108v2 and f9k1115v2
<adrianschmutzler>
so, would it make sense to create a DTSI right away?
<Tusker>
F9J1108V2 seems to be a model that comes with an ADSL modem inside the power plug pack... the first one I bought had a normal power adapter, but this new one I bought has this weird ADSL plug pack.
<Tusker>
yes, they are pretty much the same hardware from what I can see, and reading the forums, it looks like the only difference is really the firmware magic
<Tusker>
I don't have a F9K1115V2 to test though, but having a combined DTSI makes sense to me
<adrianschmutzler>
So, I would just move everything to a dtsi and only keep compatible/name in the DTS?
<adrianschmutzler>
okay, then I might go along this road
<adrianschmutzler>
also matches ar71xx btw ...
<Tusker>
would it make sense to just create two factory images in the recipe ?
<Tusker>
and leave the DTS as is ?
<adrianschmutzler>
that's a regular, philosophical and controversial question
<adrianschmutzler>
I personally am in favor of having separate "devices" in OpenWrt for separate "devices" in the real world. Otherwise, you are getting into trouble if you have to split stuff later ...
<adrianschmutzler>
(e.g. because you have overlooked another difference beforehand)
<Tusker>
good point
<adrianschmutzler>
And I have made the experience that many problems of ar71xx arose from having that kind of boards, where different devices were treated as a single "board"
<Tusker>
it could be that the F9K1115V2 has additional LEDs too
<adrianschmutzler>
and that's exactly one of the things that are typically overlooked first and then create problems later: LEDs and buttons
<Tusker>
*nods* I'll leave it to you to handle it in the best way
quark_ has quit [Ping timeout: 240 seconds]
<Tusker>
OK, bed time for me, danke
Tusker has quit [Quit: Time wasted on IRC: 4 hours 56 minutes 24 seconds]
<adrianschmutzler>
final question
<adrianschmutzler>
why is the setting in 02_network separate again?
<adrianschmutzler>
looks the same as c5/c7?
<adrianschmutzler>
or was this just for testing?
<stintel>
ynezz: does your sps30 also show the same values for pm2.5 and pm10? apparently I'm not the only one
rsalvaterra1 has joined #openwrt-devel
dxld has quit [Quit: Bye]
rsalvaterra1 has quit [Client Quit]
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 246 seconds]
dxld has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
eduardas has quit [Excess Flood]
eduardas has joined #openwrt-devel
eduardas has quit [Client Quit]
gnustomp has quit [Read error: Connection reset by peer]
gnustomp has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
<nick[m]1>
jow I wrote the netifd extension adding segment routing support (and the kernel config extension to add lwrunnel) .is there still something missing or should I change something? I adopted the naming scheme as u wrote to ip6segmentrouting
valku has joined #openwrt-devel
<jow>
nick[m]1: no it looks fine, but I didn't do any patch sweeps again since then
<rr123>
https://libwebsockets.org/lws-api-doc-master/html/md_READMEs_README_8build.html#wolf interested in building libwebsockets with wolfssl as that's where openwrt is going with default ssl these days, that requires adding '--enable-opensslextra' for wolfssl, I can submit patches to enable them, is it ok to add that 'opensslextra' flag to wolfssl?
feriman has quit [Ping timeout: 256 seconds]
<karlp>
you can try,but it's a train wreck last time I tried.
<karlp>
I've been considering dropping wolf from lws actually
<karlp>
lws is a trainwreck itself, but *shrugs*
<karlp>
I've sent patches to lws a few times to try and keep wolf building, but it's.. special
<karlp>
I take it the current wolf builds don't work?
<karlp>
oh, nvm, there's mbedtls ones
<karlp>
I must have removed wolf las ttime I stopped working
<karlp>
so sure, if you can get it to work again, fine with me
<karlp>
I added mbedtls as that's what openwrt was doing _then_
<rr123>
wolfssl Makefile actually has that flag on by default, the --enable-opensslextra
<karlp>
you'll probably have to try on 4.1.x or something, which wasn'tworking on half our apps lsa ttime I tried, so its still on my list to try "latest again latest" lws and see what it's like today
<rr123>
lws is still 3.1.0 in openwrt, yes I'm to try 4.1-stable now
<karlp>
no, I reverted to 2.4
<karlp>
you shouldn't hve 3.1 anymore
<karlp>
or did we go back rom 3.2 to 3.1
<karlp>
I can't keep track, lws is a garbge fire
<karlp>
mosquitto has committed to replcaing it, and I'll drop maintaining lws as soon as that happens.
decke has quit [Quit: Leaving.]
<rr123>
i'm new to lws but it seems used in quite a lot places, garbage fire wise, is it lws' problem? i'm trying to use it to play with a UI idea, like what owsd does
<dorf>
jow: I'm noticing some changes to luci's markup with the latest stable commit.. intentional?
<dorf>
the ifacebox containers on the interface page are now borked with my bootstrap mods.
<dorf>
(for example)
jas4711 has quit [Ping timeout: 260 seconds]
<dorf>
haven't yet had chance to review other differences, but that one jumped off the page.
<nick[m]1>
jow: okay thanks! :)
jas4711 has joined #openwrt-devel
<jow>
dorf: I don't follow
<karlp>
it's used in places because there's not a lot of options.
<karlp>
ask the developers of all those packages or the maintainers if hey're happy with it.
<jow>
but yes, openwrt-19.07 and master are likely diverged
<jow>
I wish the WS protocol were easier to implement
<jow>
but I wouldn't dare to touch it with a ten foot pole
<karlp>
yeah, mosq is considering it as these days, without having to support all the earlier draft versions, it's... potentialyl feasible
<karlp>
there's a couple of options for client libs, but virtually nothing else for server side.
<jow>
I briefly took a look at the spec and the design is ... horrible
<karlp>
well, whe you're starting poitn is "must go inside an existing http connect..." :)
<karlp>
lets' add allll the string parsing and headers and garbage and so we can set up some binary magics
<rr123>
libwebsockets-4.1.6/lib/tls/openssl/openssl-server.c:421:38: error: dereferencing pointer to incomplete type 'lws_tls_ctx' {aka 'struct WOLFSSL_CTX'} x = sk_X509_value(vhost->tls.ssl_ctx->extra_certs, 0);
<rr123>
it actually failed to build, going to send this to lws mailing list before I study its code
<dorf>
jow: I just pulled the latest stable updates via opkg, a whole bunch of luci related stuff.. interfaces were tidy before, now I get this: https://ibb.co/CB5Jw2k .. just wondering what changed.. looks like new markup.
<karlp>
ctrl-shift-r?
<karlp>
the divs -> tables will be a big change ?
<dorf>
yeah, that's what got me there :)
<dorf>
(ctrl+shift+r)
<karlp>
press it a few more times ;)
<dorf>
haha, funny.
<karlp>
I've never opkg updated luci, did you rm -rf /tmp/luci* or anything?
<dorf>
no, just a straight update and hard refresh in the browser. usually works.
<dorf>
could be one of my local changes.. probably that. easy enough to remedy, no doubt.
<dorf>
re divs -> tables, I think jow's retaining all the pseudo table classes for now, so the transition should be fairly painless.
<dorf>
ah, fixed. a nasty little "position: relative" that shouldn't be there :)
<dorf>
sorry for the distraction.
dxld has quit [Quit: Bye]
dxld has joined #openwrt-devel
<jow>
karlp: essentially s/\.(table|tr|td)/\1/g
<jow>
karlp: I'll keep the CSS classes for a few more months though
<jow>
so instead of <div class="tr"> the markup is <tr class="tr"> currently
jas4711 has quit [Remote host closed the connection]
Borromini has quit [Quit: leaving]
<rr123>
karlp: fyi now wolfssl builds with lws, will see how to check it does not break anything
Misanthropos has quit [Ping timeout: 256 seconds]
Dracos-Carazza_ has joined #openwrt-devel
Borromini has joined #openwrt-devel
<Borromini>
jow: hi. when you suggested to rename the interface, were you talking about the 'option ifname' line or about the 'config interface' line itself?
<Borromini>
since they're both wan...
Dracos-Carazza has quit [Ping timeout: 256 seconds]
Misanthropos has joined #openwrt-devel
feriman has joined #openwrt-devel
<jow>
Borromini: config interface itself
<Borromini>
ok, thanks. right bet then ;)
CrazyLemon has quit [Ping timeout: 246 seconds]
<philipp64>
jow: I’ve got an interface alias section for an xfrm tunnel, to set an IPv4 on it and enable multicast… the address gets set but not multicast… where can I start digging to debug this?
<aparcar[m]>
ideally simple and non controversial, I already burned my fingers this week
philipp64 has joined #openwrt-devel
<rsalvaterra>
Ah… can't promise you that. :P
<jow>
sigh, more option bloat
<rsalvaterra>
jow: I'm open to sugestions.
<jow>
yeah, don't micro-optimize
<rsalvaterra>
jow: potentially halving the size of dropbear isn't a micro-optimisation…
<rsalvaterra>
I mean, people were trying to package TinySSH a while ago.
<jow>
halving how? by dropping RSA?
<rsalvaterra>
Suggestion: how about a minimal variant?
<rsalvaterra>
jow: Dropping RSA would be a user choice, at compilation time, not the default…
<adrianschmutzler>
and please don't extend this review-bargaining
<rsalvaterra>
adrianschmutzler: Noted, didn't mean to put it that way, sorry.
<aparcar[m]>
I started it, sorry I guess
<jow>
I am not opposed to optimizations per so, but the proliferation of compile time knobs quickly turns into an unmaintained mess over time
<aparcar[m]>
gentroo?
<jow>
five to ten years down the road we'll probably find out that most of these options stopped working years ago
<jow>
because nobody actually changes them
<jow>
which actually happened already, frequently
<rsalvaterra>
jow: The fstools options scare me, for example. :/
<philipp64>
jow: tried both ways, no joy.
<aparcar[m]>
jow so only better defaults then?
<jow>
philipp64: let me check the netifd source
<rsalvaterra>
jow, adrianschmutzler, how about my proposal of adding a no-knobs dropbear-minimal variant, supporting only ChaCha20-Poly1305, like TinySSH?
<jow>
a few weeks later people want to add just one more feature to the tiny variant because some random iot device does not support the cipher
<jow>
see recent discussion about shuffling various hostapd features in mini/basic/full
<rsalvaterra>
I have my part in the hostapd mess, yes…
<rr123>
dropbear for me is a small server, for client I re-enabled ssh actually, for the fancy certificate authentication, which is great if you have a few devices to manage
<jow>
and later there's the desire to have a mini-rsa variant because it has to operate in a legacy env wheren othing does EC
<jow>
but since some crap backup solution uses scp to backup stuff, compression support would be desirable
<jow>
so it's mini-rsa-zlib then
<rr123>
i hope dropbear can add certificate support as openssh client is still too large in size
<rsalvaterra>
jow: Dear God, no.
<rsalvaterra>
So, this is a bit of a dilemma…
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<rsalvaterra>
I don't mind carrying the patches in my tree, but I had lots of "fun" rebasing them as needed…
<rr123>
just noticed uhttpd is 3MB in RSS size, lighttpd uses 4MB
<rsalvaterra>
aparcar[m]: I haven't tested the patch series, but I like the simplification, yes.
<aparcar[m]>
rsalvaterra: your patch series or the one on github?
<adrianschmutzler>
rsalvaterra: I cannot comment on these patches
<rsalvaterra>
rr123: And BusyBox's HTTP server? :)
<jow>
rr123: with or without uhttpd-mod-lua ?
<rsalvaterra>
aparcar[m]: The one from Konstantin, on GitHub, yes.
<rr123>
jow: uhttpd-mod-lua is enabled
<jow>
rr123: that's a bit unfair then as half of luci will be preloaded
<jow>
and resident in memory
<adrianschmutzler>
I just wanted to prevent that one-review-for-another gets out of hand at some point
<rr123>
i see, no wonder
<adrianschmutzler>
it's perfectly valid to ask for review btw
<rsalvaterra>
adrianschmutzler: Fully agree, mea culpa. :)
Darkmatter66 has joined #openwrt-devel
<adrianschmutzler>
even your request was okay, I'm just afraid of what can result if you go down this road ...
philipp64_ has joined #openwrt-devel
<rsalvaterra>
adrianschmutzler: To be honest, my first thought was "wait, if I'm reviewing the dropbear patches and no one else is, who's reviewing my patches?". :P
philipp64 has quit [Ping timeout: 240 seconds]
philipp64_ is now known as philipp64
<adrianschmutzler>
and that's why nobody reviews any patches ;-)
<rsalvaterra>
Eheheh!
<adrianschmutzler>
but the question is perfectly okay, unless you reach a point where you really start to "buy" reviews with other reviews
<aparcar[m]>
I review patches :o
<rsalvaterra>
aparcar[m]: And merge too! ;)
<adrianschmutzler>
anyway, didn't want to discuss this issue that extensively, actually
<aparcar[m]>
adrianschmutzler: I'll not establish a #review4review culture
<rsalvaterra>
Yeah, I guess we'll all pay more attention to those situations.
<adrianschmutzler>
On the contrary, it would be a big help if more non-committer would do (full) reviews
<Tapper>
You lot could have me doing reviews for patches. hahahahaahah I spell better than I code!
<rsalvaterra>
Oh, a volunteer!
<Tapper>
and I code better than I read code!
philipp64 has quit [Ping timeout: 256 seconds]
<adrianschmutzler>
so, you can focus on commit messages (and probably will kill yourself after a week ...) ;-)
philipp64 has joined #openwrt-devel
<Tapper>
I will just turn my screen reader up to the fastest speed and if it sounds good I will OK the patch! lol
<Tapper>
It make my screen reader beet box!
<rsalvaterra>
adrianschmutzler: I could do reviews too, but sometimes I feel I'm not qualified enough… :P
<rsalvaterra>
I mean, I understand the idea of the dropbear_headers define, but it makes my eyes bleed.
<adrianschmutzler>
well, only review if you feel qualified, of course.
<aparcar[m]>
rsalvaterra: just review the 5 other commits in that PR and I'll do the makefile magic (including consulting jow for all the special meanings)
<adrianschmutzler>
but there are frequently cases where I have the impression that people are available that could review easily and thereby reduce the time required by committers
<adrianschmutzler>
which would improve the overall throughput
philipp64 has quit [Ping timeout: 272 seconds]
philipp64_ has joined #openwrt-devel
<aparcar[m]>
adrianschmutzler: can we give people label rights without commit rights?
<adrianschmutzler>
aparcar: i don't know, but I don't really think that would make such a big difference
<adrianschmutzler>
I just see that there are a lot of experts in the room that can provide value on specific subjects
<aparcar[m]>
labels are a nice system which only seem useless when barely used. I usually just review whatever is tagged with build/tools/scripts
<adrianschmutzler>
while committers might not be competent on every area of the whole project
<adrianschmutzler>
these two groups could perfectly work together for some submissions
<adrianschmutzler>
I'm not aware how other committers use labels. I only need them for filtering _after_ a first look, and typically I only filter targets and releases
<adrianschmutzler>
ynez seems to actually use them for status tracking
<rsalvaterra>
Well, this is probably an unpopular opinion, but… I really prefer email patches. It's so much easier to provide feedback on a reply. :)
<rsalvaterra>
This new-fangled pull-request thing…
<rsalvaterra>
And here I am, just sipping my tea. :P
<aparcar[m]>
stintel: my roomates made brownies which is also a plus
<dorf>
rsalvaterra: I never did like how links renders my css :| that's a deal break for me :)
lmore377 has quit [Ping timeout: 256 seconds]
<rsalvaterra>
CSS is the work of the devil. I'd rather read 8051 assembly.
<stintel>
aparcar[m]: re: removal, sure, how I understand it is that it's really only useful in combination with clang
<aparcar[m]>
ok
<philipp64_>
rsalvaterra: the most prolific processor ever, if I’m not mistaked.
<philipp64_>
* mistaken
<dorf>
miso stake!
<dorf>
or even miso steak!
<rsalvaterra>
philipp64_: Not the best to start learning, though… like I did at the university. :P
<philipp64_>
stintel: hate to be the squeaky wheel… is there anyone you could delegate review of PR 14028 to?
<philipp64_>
dorf: is that another non-meat travesty?
<stintel>
good ol
<stintel>
good ol' ribeye!
<rsalvaterra>
philipp64_: I don't know if ARM already already surpassed it, though…
<dorf>
philipp64_: quite the opposite. miso + steak :)
<philipp64_>
mmm… ribeye
<stintel>
philipp64_: well dunno, I really don't use the uci implementation and seems dedeckeh has no time
<dorf>
or miso infused steak perhaps. miso definitely features, as does meat.
<stintel>
if I manage to figure out why wireguard is being so horribly unusable on 1 of my devices ... I'll let you take over maintainership and be done with it
<philipp64_>
rsalvaterra: doubtful… every PC (keyboard controller), smart refrigerator, washing machine, elevator, etc. has an 8051 in it.
<rsalvaterra>
stintel: What's wrong with WireGuard?
<philipp64_>
stintel: me?
<stintel>
rsalvaterra: it stops responding completely if I make config changes and ifup the interface
<philipp64_>
uh…. walked into that one.
<stintel>
it goes down and I need to reboot the bloody router to make it come up again
<rsalvaterra>
stintel: I just do /etc/init.d/network restart…
<philipp64_>
DM me your config?
<stintel>
the config is fine, the tunnel works fine on boot, but if I want to make config changes and ifup, it dies
<philipp64_>
sounds like the closeaction is wrong.
<stintel>
rsalvaterra: well yeah network restart is almost as intrusive as rebooting, especially on my HA network, it triggers failover to the other router etc
<philipp64_>
on the peer, I mean.
<stintel>
philipp64_: I'm talking about wireguard now
<philipp64_>
ah.
<philipp64_>
I know nothing about that.
<stintel>
my strongswan configs are rock solid
<rsalvaterra>
stintel: Wait, ifdown/ifup? Not ip link…?
<stintel>
rsalvaterra: yes, the openwrt integration ..
<rsalvaterra>
Ok… never messed with it directly…
<stintel>
actually the 1 tunnel I configured is up atm, and stable for a couple of days already, but not being able to reconfigure without full network restart is not acceptable
<stintel>
now where will I test this ...
<karlp>
rr123: the tests are mosquito: mqtt over websockets, and ttyd
<karlp>
they both exercise different parts of lws and sometimes one worksand the other doesn't
<karlp>
then, if you're really keen, try actually using the ssl portions :)
<philipp64_>
anyone here banging on OLSR?
<rsalvaterra>
Speaking of interfaces (and not directly related to OpenWrt), I'm seen some really nasty stuff on my dad's laptop… If I reboot my router, the Wi-Fi card's firmware fatally crashes on disassoc.
<rsalvaterra>
*I'm seeing
<stintel>
sounds like Intel
<rsalvaterra>
It *is* Intel.
<Borromini>
<3 Intel
<rsalvaterra>
Obviously. :P
<stintel>
shoot the card and get ath9k
<rsalvaterra>
stintel: BIOS whitelist.
<stintel>
shoot the laptop :(
<rsalvaterra>
Lenovo sh*t.
<rsalvaterra>
Never again.
philipp64 has joined #openwrt-devel
<rsalvaterra>
stintel: Yeah, rsync is needed to build Linux since v5.6, or so… :P
philipp64_ has quit [Ping timeout: 256 seconds]
* rsalvaterra
can't believe his zram kernel patch is already at v7…
<rsalvaterra>
I understand why Linus hates kconfig with such a passion…
<aparcar[m]>
rsalvaterra: do you have a link to your zrm patch?
ivanich has quit [Remote host closed the connection]
Namidairo_ has joined #openwrt-devel
Namidairo has quit [Read error: Connection reset by peer]
Tusker has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gch981213886000 has quit [Read error: Connection reset by peer]
gch9812138860009 has joined #openwrt-devel
andi- has quit [Ping timeout: 264 seconds]
<aparcar[m]>
does patchwork has an mass export function?
<philipp64>
Anyone here a procd guru? I’m having an issue with an init.d script not being run properly at boot-up…
lmore377 has quit [Ping timeout: 240 seconds]
dedeckeh has quit [Remote host closed the connection]
<Tusker>
philipp64: not a guru, but what does not properly mean ?
novski__ has quit [Quit: Connection closed for inactivity]
ivanich has joined #openwrt-devel
<philipp64>
I’ve enabled the service, but it doesn’t seem to do anything until I do a ‘start’ explicitly from the command-line.
<jow>
pastebin the script somewhere
<philipp64>
I’m not sure if it’s running too early, or not seeing an interface state transition change, or what.
<Tusker>
could be a $PATH issue, where 'login' gives you /usr/sbin or whatever already and procd doesn't have it
<Tusker>
echo $PATH > /tmp/sillyprocdpath.log
<philipp64>
here… it’s a mangled version of the isc-dhcp/files/dhcpd.init script that converts ‘host’ and ‘domain’ config records into A and PTR records for Bind… http://paste.ubuntu.com/p/bDbkhvh4hD/
<philipp64>
I commended out USE_PROCD in this version but I can’t remember why…
<jow>
line 539 looks like a likely culprit
<jow>
the init script will run long before wan is brought up in many cases
t4h4[m] has quit [*.net *.split]
decke[m] has quit [*.net *.split]
svth has quit [*.net *.split]
gaspode has quit [*.net *.split]
Olipro has quit [*.net *.split]
hexa- has quit [*.net *.split]
<philipp64>
that implies I need 604-605?
Olipro has joined #openwrt-devel
Olipro has joined #openwrt-devel
Olipro has quit [Changing host]
<jow>
yes
<jow>
assuming the script we're looking at in this paste actually is /etc/init.d/fake-dns
<philipp64>
I think I was hoping that named would detect its config file had changed and auto-reread it, but that requires “procd_set_param file $config_file” doesn’t it?
ivanich has quit [Quit: Konversation terminated!]
<jow>
philipp64: well the thing is that the init script bails out on boot before registering anything with procd
<jow>
it will try to resolve the search domains which fails if wan is not up
<jow>
and then it exits
<philipp64>
do I need “start_service()” instead of “start()”?
<jow>
that should help yes
DeX77 has quit [Ping timeout: 264 seconds]
<jow>
this way the trigger registration should still run
<philipp64>
btw, the WAN interface is an ethernet (G.PON) with a statically assigned IP address, so it should come up quickly...
<jow>
thne maybe the issue is somehwere lese
<rr123>
i was trying to get ftldns(pihole dnsmasq) running with procd, ftldns forks dnsmasq internally and there are a dozen of them are running after reboot, never understand why that happened, but I can manually start ftldns and run it just fine, procd script made something happen for sure
andi- has joined #openwrt-devel
DeX77 has joined #openwrt-devel
<philipp64>
jow: does stderr from the PROCD-enabled scripts get logged to syslog?
Borromini has joined #openwrt-devel
<philipp64>
and how do I tell if a script implements ‘reload’ or not?
<philipp64>
I’d rather ‘reload’ named than restart it… seems gentler.
<philipp64>
I guess a missing reload_service() func is a good indicator...
<Hauke>
philipp64: when you set stderr 1 in your procd script stderr wil to to syslog