**** BEGIN LOGGING AT Thu Jan 30 02:59:57 2020
Jan 30 05:51:22 <ds_shadof> that luci=wireguard is total disaster, always says 'Cannot save due to invalid values' when trying to add peers
Jan 30 05:52:45 <ds_shadof> nvm
Jan 30 10:41:01 <owrt-snap-builds> build #249 of mpc85xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric/builds/249
Jan 30 10:44:04 <owrt-snap-builds> build #249 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/249
Jan 30 13:35:22 <owrt-snap-builds> build #286 of brcm63xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/brcm63xx%2Fgeneric/builds/286
Jan 30 13:50:52 <owrt-snap-builds> build #287 of oxnas/ox820 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/287
Jan 30 13:51:28 <Ansuel> some devs working on 5.4? I need to report 2 fix for some broken patch present in the generic patchset. (They cause kernel panic)
Jan 30 13:52:21 <ldir> Can someone please point me at documentation that explains  boot()  entries in init.d scripts
Jan 30 13:53:03 <blogic> boot entry is like a start entry
Jan 30 13:53:22 <blogic> on system bootup it will call /etc/init.d/$foo boot
Jan 30 13:53:31 <blogic> by default boot() will call start()
Jan 30 13:53:44 <blogic> but in some cases you want to do something special on boot up
Jan 30 13:53:56 <blogic> in those cases you can simply define a boot()
Jan 30 13:53:58 <ldir> Am looking at a script that just returns in the boot case
Jan 30 13:54:15 <blogic> which script ?
Jan 30 13:54:24 <blogic> is there also a start() ?
Jan 30 13:54:35 <ldir> there IS a start
Jan 30 13:54:55 <blogic> in that case the service wont get strated on boot but requires a manual init.d/$foo start
Jan 30 13:55:03 <blogic> is this online somewhere?
Jan 30 13:55:19 <ldir> it's miniupnpd
Jan 30 13:56:25 <blogic> looks wrong
Jan 30 13:56:51 <ldir> it explains why it doesn't start at boot :-)
Jan 30 13:56:51 <blogic> yup, might have been valid if triggers get installed
Jan 30 13:57:04 <blogic> https://github.com/openwrt/packages/blob/master/net/miniupnpd/files/miniupnpd.init#L59
Jan 30 13:57:08 <blogic> just delete these 3 lines
Jan 30 14:01:59 <ldir> damn git blame has my name all over it... ahh due to the fact I was one who imported it from routing.  Hmm.  Why am I only hitting this now?
Jan 30 14:02:18 <blogic> lol
Jan 30 14:03:04 <blogic> i just stumbled over the cable of my headphones
Jan 30 14:03:12 <blogic> and now the right channel does not work anymore
Jan 30 14:03:21 <blogic> luckily it did not rip the laptop of the table
Jan 30 14:03:29 <blogic> and bose wants 40 euro for a replacement
Jan 30 14:03:37 <blogic> so i went for the china 10 euro option :-D
Jan 30 14:05:26 * ldir reboots
Jan 30 14:12:32 <jow> KevinDB: miniupnpd's boot() is a no-op because miniupnpd is supposed to be started by a hotplug event
Jan 30 14:12:52 <jow> boot() is too early, interfaces and firewall zones cannot be resolved yet
Jan 30 14:13:50 <blogic> ah
Jan 30 14:13:52 <blogic> ok :-)
Jan 30 14:20:47 <Ansuel> blockttron: can you help me ?
Jan 30 14:22:24 <KevinDB> jow: ah ok.  Hmm, so why doesn't it start.
Jan 30 14:23:11 <KevinDB> (it does now start... but isn't happy because of the reasons you mention... no addresses etc)
Jan 30 14:24:03 <jow> KevinDB: you need to debug the holtplug script
Jan 30 14:24:21 <KevinDB> will look :-)
Jan 30 15:25:46 <ldir> that hotplug script is hideous
Jan 30 15:33:00 <Tapper> blogic you can do better then bose cans mate.
Jan 30 15:33:25 <Tapper> I have never bin a fan of there sound.
Jan 30 15:33:30 <stintel> loving my PX7 :)
Jan 30 15:33:41 <Tapper> Are they USB?
Jan 30 15:33:53 <stintel> nah, I hate wired headsets
Jan 30 15:35:14 <Tapper> I am in love with my blogic dt770 pros!
Jan 30 15:35:56 <Tapper> beyerdynamic* lol
Jan 30 15:35:58 <karlp> stintel: those are..... not very cheap.
Jan 30 15:36:21 <Tapper> I know mate, werth every penny
Jan 30 15:37:01 <stintel> karlp: they aren't, but they're really good
Jan 30 15:37:01 <Tapper> beyerdynamic do make cheaper ones
Jan 30 15:37:01 <stintel> N/C is not the best. but oooh that sound
Jan 30 15:37:01 <karlp> Tapper: yours are less than half the price of stintels
Jan 30 15:37:10 <stintel> I got some discount because I know a guy, but still
Jan 30 15:37:13 <Tapper> what are stintels?
Jan 30 15:37:18 <stintel> PX7
Jan 30 15:37:56 <karlp> so are they jsut bluetooth or something audiophoolery custom?
Jan 30 15:37:58 <stintel> I had the PX before that and sounded really good, but very heavy which made them uncomfortable for long use. the PX7 improves that
Jan 30 15:37:59 <Tapper> OMG Bowers & Wilkins  are the cans of gods and I am not jocking
Jan 30 15:38:05 <Tapper> joking
Jan 30 15:38:26 <stintel> karlp: they're BT or jack, but with all the fancy APTx and sony's high-bitrate BT codec
Jan 30 15:38:31 <Tapper> They are the onley ones I would swop for mine
Jan 30 15:39:18 <stintel> good thing we have https://github.com/EHfive/pulseaudio-modules-bt these days
Jan 30 15:39:31 <stintel> because I don't do windows or mac os
Jan 30 15:39:46 <Tapper> Mine are just 3.5 mil jacks tho. They don't have any BT or sound gubbings
Jan 30 15:40:18 <Tapper> 250 oms so you have to have a good sound card or DAC to drive them
Jan 30 15:40:31 <Tapper> but the sound is badass.
Jan 30 15:55:52 <ldir> hmmm daemon.err procd: unable to find /sbin/ujail: No such file or directory (-1)
Jan 30 16:09:02 <ldir> aha! https://git.openwrt.org/?p=project/procd.git;a=commit;h=b44417c20c7fca5a7f7c581c04ac67bf5316e56e
Jan 30 16:11:11 <karlp> should be just a warning, "you don't have jails enabled" right?
Jan 30 16:13:17 <ldir> something like that I think.
Jan 30 16:21:33 <ldir> context in terms of process name would be helpful too.
Jan 30 16:22:13 <ldir> I just happen to know that the only process that's likely to want jailing is dnsmasq
Jan 30 16:27:10 * ldir must stop looking at startup logs
Jan 30 16:53:23 <ldir> hmm daemon.err procd: unable to enable jail for instance cfg01411c. Check /sbin/ujail: No such file or directory (-1) - an improvement but not quite what I was hoping for
Jan 30 16:57:14 <ldir> perhaps service name instead of instance name...or maybe even both.  Let's see if I can c well enough to get the service name.
Jan 30 16:57:36 <karlp> you want both if at all possible.
Jan 30 16:58:18 <ldir> Am I heading in the right direction though with the message do you think?
Jan 30 16:58:28 <karlp> ack "%s::%s" in the procd source gives you examples.
Jan 30 16:59:21 <karlp> I guess question is, "if you've asked procd for a jail, and it can't, is that an error"? vs "I've asked for procd for a jail, but i don't really care if it gets one or not"
Jan 30 16:59:38 <karlp> ie, should the caller be checking for jail availability and not asking procd for one if it's not available?
Jan 30 16:59:56 <karlp> layers of apis :)
Jan 30 17:02:59 <karlp> "unable to ennable jail for %s::%s: <unable to find JAILBIN> <Are jails enabled <globally|inyour build>" ?
Jan 30 17:05:25 <ldir> If a tree falls over in a forest and there's no one there to hear it, does it make a sound? :-)
Jan 30 17:06:34 * ldir goes to reboot again with a different version of procd
Jan 30 17:12:47 <ldir> progressing :-)
Jan 30 17:17:29 <ldir>  ERROR("Cannot jail service %s::%s. %s: %m (%d) Are jails enabled?\n",
Jan 30 17:17:29 <ldir>                                 in->srv->name, in->name, UJAIL_BIN_PATH, r);
Jan 30 17:29:40 <karlp> :+1:
Jan 30 17:30:01 <karlp> are jails "enabled" or "installed"? or what? (I've never used them)
Jan 30 17:31:01 <ynezz> hm, I've missed that, so easy fix is turning that ERROR into DEBUG
Jan 30 17:31:26 <karlp> well, I think debug is too low.
Jan 30 17:31:37 <karlp> you added the message because you couldn't debug it right?
Jan 30 17:31:43 <karlp> and debug isn't shown normally.
Jan 30 17:31:44 <ynezz> proper fix could be different jails detection
Jan 30 17:32:01 <ynezz> yes, spent about hour debugging missing ujail binary...
Jan 30 17:33:58 <adrianschmutzler> ynezz: do you see an easy way to address this: https://bugs.openwrt.org/index.php?do=details&task_id=2779&order=dateopened&sort=desc
Jan 30 17:34:12 <ynezz> I'm not big fan of this different codepaths triggered by binaries availability
Jan 30 17:34:34 <adrianschmutzler> just in case, otherwise I will try myself when I have more time
Jan 30 17:34:56 <ynezz> too long, short of time :)
Jan 30 17:35:27 <ynezz> you don't need device for this changes
Jan 30 17:35:42 <ynezz> you can compile uci natively
Jan 30 17:36:41 <ynezz> there are unit tests, so just extend them for this error/use case, fix, done
Jan 30 17:37:07 <adrianschmutzler> okay, didn't think in that direction, will have a look
Jan 30 17:37:15 <blogic> Tapper: had the head phones since they first came out 10 years ago
Jan 30 17:39:15 <ynezz> adrianschmutzler: http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020831.html there is example with libubox at the bottom
Jan 30 17:39:21 <ynezz> adrianschmutzler: just replace it with uci
Jan 30 17:40:01 <ynezz> adrianschmutzler: and then replace ci-native-checks in `make ci-native-checks -f Makefile.ci` with ci-native-build
Jan 30 17:41:00 <blogic> ynezz: can you create a wiki page with all your CI foo on it ?
Jan 30 17:41:13 <blogic> you told me twice already but i keep loosing the notes
Jan 30 17:41:26 <blogic> so having some formalized standard process documented would be amazing
Jan 30 17:41:28 <adrianschmutzler> ynezz: thanks, wanted to dive into that stuff anyway, so I have a reason now :-)
Jan 30 17:42:22 <ynezz> adrianschmutzler: or just `cd uci.git; mkdir build; cmake -D UNIT_TESTING=on ..; make build all test CTEST_OUTPUT_ON_FAILURE=1`
Jan 30 17:43:29 <ynezz> blogic: WIP https://gitlab.com/ynezz/openwrt-ci/#openwrt-ci and https://gitlab.com/ynezz/openwrt-ci/-/wikis/Example-of-adding-CI-support-to-fstools-project + that email
Jan 30 17:43:53 <ynezz> blogic: I plan to move openwrt-ci under openwrt projects soon, then document it
Jan 30 17:44:11 <blogic> amazing
Jan 30 17:44:12 <ynezz> and I would rather still get some feedback and iron out rough edges first
Jan 30 17:44:30 <blogic> I am building a u80211d just now
Jan 30 17:44:39 <blogic> its basically iwinfo but as a ubus daemon
Jan 30 17:44:44 <ynezz> ah, nice
Jan 30 17:44:49 <blogic> so i'll test ride it on that
Jan 30 17:45:08 <blogic> 'wifi' @157e0ce5
Jan 30 17:45:08 <blogic> 	"iface":{}
Jan 30 17:45:08 <blogic> 	"assoclist":{"ifname":"String"}
Jan 30 17:45:08 <blogic> 	"scan":{"ifname":"String"}
Jan 30 17:45:10 <blogic> :-D
Jan 30 17:45:19 <blogic> working on DFS/cac support just now
Jan 30 17:45:35 <adrianschmutzler> blogic: since you are here, do you have an opinion on that one: https://patchwork.ozlabs.org/patch/1222836/
Jan 30 17:45:41 <blogic> lemme look
Jan 30 17:45:58 <blogic> adrianschmutzler: Ack
Jan 30 17:46:18 <blogic> adrianschmutzler: MTK is working on 5.4 support and sent me the missing fixes for v4.19
Jan 30 17:46:31 <blogic> and felix pushed the wifi patches for mt7622 upstream today
Jan 30 17:46:38 <adrianschmutzler> blogic: Okay, I can't test it, but it looks like the device was removed by accident
Jan 30 17:46:46 <blogic> well
Jan 30 17:46:52 <blogic> its the emmc eval kit
Jan 30 17:46:57 <blogic> no one apart from me will have one
Jan 30 17:47:06 <blogic> but ok to keep it
Jan 30 17:47:13 <blogic> my7623 is EOL'ed
Jan 30 17:47:26 <blogic> there is a bootrom to calibrate ddr
Jan 30 17:47:35 <adrianschmutzler> the alternative would have been to remove the base-files references to this device
Jan 30 17:47:37 <blogic> and then fabs moved to a lower nm scale
Jan 30 17:47:46 <blogic> and the bootrom does not support the new timings
Jan 30 17:47:57 <blogic> so "not recommended for new designs"
Jan 30 17:48:18 <blogic> mt7623 suffers the same fate as mt7610 and brcm/northstar
Jan 30 17:48:36 <blogic> adrianschmutzler: i'd actually go for the alternatives
Jan 30 17:48:47 <blogic> MTK ships the bananapi now days as a mt7623 rfb
Jan 30 17:49:06 <blogic> there is only a handfull of those emmc-rfbs on the planet
Jan 30 17:49:14 <adrianschmutzler> blogic: so, remove the references instead?
Jan 30 17:49:16 <blogic> best guess they did a run of 250
Jan 30 17:49:24 <blogic> adrianschmutzler: yes, if you dont mind
Jan 30 17:49:40 <blogic> mt7623 is pretty dead
Jan 30 17:49:47 <adrianschmutzler> blogic: I don't care actually, just don't want to have half support
Jan 30 17:49:49 <blogic> it was the first arm SoC they built
Jan 30 17:49:56 <blogic> adrianschmutzler: agreed
Jan 30 17:50:09 <blogic> adrianschmutzler: I have been slacking on mediatek support recently
Jan 30 17:50:20 <blogic> but we will pick it up again soonish
Jan 30 17:50:45 <blogic> actaully talked to felix about it today, we will very likely work on the offloading stuff in the coming weeks
Jan 30 17:51:14 <blogic> not a secret, I consider MTK to be the best choice due to their upstream support and general company policies
Jan 30 18:01:26 <adrianschmutzler> blogic: https://patchwork.ozlabs.org/patch/1231542/
Jan 30 18:01:37 <adrianschmutzler> I've added the Acked-by already ;-)
Jan 30 18:05:45 <blogic> thanks
Jan 30 18:31:14 <Slimey> how is it decided if a device gets merged into 19.07.*
Jan 30 18:33:01 <adrianschmutzler> generally, it is not merged. Exceptions are made when you have a very good reason. (Some committers merge their stuff as well when they have backported it anyway.)
Jan 30 18:34:25 <adrianschmutzler> ... and sometimes I decided to backport when it's trivial, e.g. just a clone of an existing device
Jan 30 18:35:24 <Borromini> Slimey: afaik there's no new hardware support added once the initial stable gets pushed
Jan 30 18:35:27 <zorun> is there a general rule? as a downstream user I would like to see new devices in actively maintained stable releases, but of course if nobody spends time backporting devices, nothing will happen
Jan 30 18:36:11 <Slimey> Borromini so it might have been added in time to make the release is what you are saying?
Jan 30 18:36:20 <adrianschmutzler> there is no rule, but what I just wrote is the customary low
Jan 30 18:36:23 <zorun> there were new devices added between 19.07.0 and 19.07.1: https://openwrt.org/releases/19.07/notes-19.07.1#device_support
Jan 30 18:36:24 <adrianschmutzler> *law
Jan 30 18:37:49 <Borromini> zorun: afaik that is a singular notable exception. those devices seem to be clones of already supported devices in 19.O7
Jan 30 18:38:05 <Borromini> and ath79 is another corner case as well in a way
Jan 30 18:38:13 <adrianschmutzler> the devices added there were trivial in two cases 841 v10/v12, and the CPE220 v3 I backported for downstream anyway, so there was no reason to not merge it
Jan 30 18:38:30 <adrianschmutzler> that's why I decided to add them
Jan 30 18:38:44 <Slimey> https://github.com/openwrt/openwrt/pull/1359
Jan 30 18:38:46 <adrianschmutzler> so there was little/no additional time required
Jan 30 18:39:44 <adrianschmutzler> Well, BSAP1880 is a good example of something that would consume a lot of time to be backported, and I also think there were fixes afterwards that have to be checked
Jan 30 18:40:28 <adrianschmutzler> And note that it does not help much if you do the backporting, as I have to do almost the same work when reviewing it
Jan 30 18:42:01 <adrianschmutzler> sorry. but there has to be a limit at some point
Jan 30 18:43:02 <Borromini> Slimey: if you're a bit handy you can backport it yourself to 19.07
Jan 30 18:43:44 <Borromini> it's what i did with dir-878 support e.g. - building myself as well.
Jan 30 18:50:01 <Slimey> no worries i just didnt know
Jan 30 18:59:42 <karlp> ynezz: ldir making the procd_add_jail stuff abort might be better than hacking different code paths in C?
Jan 30 19:05:18 <zorun> if backporting is not too difficult and somebody does the work, I don't see why it shouldn't be accepted
Jan 30 19:22:00 <KevinDB> karlp: procd_add_jail would need to know if it's been built on a jail enabled system or not
Jan 30 19:22:07 <KevinDB> ldir
Jan 30 19:22:15 <ldir> oops
Jan 30 21:15:49 <Slimey> there wouldnt happen to be a tutorial for that im guessing :P Borromini Slimey: if you're a bit handy you can backport it yourself to 19.07
Jan 30 22:01:57 <DonkeyHotei> Slimey: the project members are in the process of voting on, among other things, whether there should be a 20.03 release, which would of course support it
**** ENDING LOGGING AT Fri Jan 31 03:00:42 2020