**** BEGIN LOGGING AT Thu Jul 25 02:59:57 2019
Jul 25 06:22:53 <jow> Slimey: can you pastebin me the output of "ubus call luci usb" and "ubus call luci leds" ?
Jul 25 06:31:13 <gch981213> jow: Got similar error message and here's the output: https://paste.ubuntu.com/p/Qmbc7Dxb22/
Jul 25 06:49:38 <jow> gch981213: thanks! fixed with https://github.com/openwrt/luci/commit/fd35e9a226965c1586228618d34597da0be48877
Jul 25 06:55:52 <ynezz> jow: BTW where can I find Dockerfile for buildslave (would like to check Python3 support)
Jul 25 06:56:21 <ynezz> I'm quite puzzled because it was usually available in docker hub, but can't see it now
Jul 25 06:57:07 <jow> https://git.openwrt.org/?p=buildbot.git;a=tree;f=docker/buildslave;h=93c8bd4e10691400aaa86a3e892990566794d24f;hb=de1247ce78808cbcbabb5c56f652f545b0d5f513
Jul 25 06:57:19 <ynezz> ah, there, thanks!
Jul 25 06:58:33 <ynezz> nice, so it's already there
Jul 25 07:02:55 <ynezz> so, any objections against switch to python3?
Jul 25 07:08:07 <jow> not at all
Jul 25 07:56:26 <mangix> jow: any other issue with https://github.com/openwrt/luci/pull/2883 ?
Jul 25 09:06:40 <MY_R> ynezz, so building images on python3 only box will work fine?
Jul 25 09:08:39 <stintel> +1 for py3
Jul 25 09:09:15 <nitroshift> stintel, 0/
Jul 25 09:09:25 <stintel> nitroshift: yo
Jul 25 09:09:38 <stintel> did you save my phone number now :D
Jul 25 09:10:16 <nitroshift> stintel, errrrr... no
Jul 25 09:10:18 * nitroshift hides
Jul 25 09:10:28 <nitroshift> lost my phone
Jul 25 09:10:32 <stintel> ahhh :D
Jul 25 09:16:45 <aparcar[m]> can i start procd with all it's sevices, ending up with an open shell, without running /sbin/init?
Jul 25 09:17:13 <aparcar[m]> to bring up all services in a CI environment
Jul 25 09:17:20 <aparcar[m]> ynezz: ideas?
Jul 25 09:18:14 <blogic> aparcar[m]: just start procd ?
Jul 25 09:18:21 <blogic> and not initd
Jul 25 09:18:40 <aparcar[m]> blogic: but procd never "ends" or forks itself so a shell pops up
Jul 25 09:18:45 <aparcar[m]> so the ci just waits forever
Jul 25 09:19:05 <stintel> fyi, it's "its services", common mistake
Jul 25 09:20:02 <aparcar[m]> stintel: thanks, normally I have this in mind
Jul 25 09:20:11 <blogic> stintel: your new ti IRC if you even notice those things ;)
Jul 25 09:20:25 <stintel> blogic: haha :D
Jul 25 09:20:34 <stintel> only here for 20 years
Jul 25 09:21:34 <aparcar[m]> blogic: so is it possible to start procd and make it fork or however this is done?
Jul 25 09:21:39 <blogic> aparcar[m]: ok, you want it to daemonize
Jul 25 09:21:44 <aparcar[m]> yea!
Jul 25 09:23:45 <blogic> aparcar[m]: https://pastebin.com/vsZ9GuQX
Jul 25 09:23:48 <blogic> try that
Jul 25 09:24:16 <aparcar[m]> blogic: ur fast
Jul 25 09:24:36 <aparcar[m]> *you're
Jul 25 09:25:42 <aparcar[m]> blogic: thanks! will try that after lunch
Jul 25 09:31:15 <aparcar[m]> blogic: should we bring this upstream anyway?
Jul 25 09:31:32 <blogic> bring what upstream ?
Jul 25 09:49:15 <ldir> blogic: I think Paul means put your rapidly produced patch in the procd repository - ie. make it part of procd
Jul 25 09:57:31 <blogic> ldir: once he tested it sure
Jul 25 10:59:52 <aparcar[m]> blogic: hey, the patch works however the result ins't as (I) expceted. A simple example is to run a docker container but tell it to run /sbin/procd -D instead of initd. It runs without an error but the container than just exists. I think the CI (and docker) needs a shell to work with, where it can paste in commands via stdin.
Jul 25 11:00:37 <aparcar[m]> hopefully that doesn't sound to odd.
Jul 25 11:01:20 <blogic> you said docker
Jul 25 11:01:44 <blogic> no idea, sorry
Jul 25 11:03:01 <aparcar[m]> 🙂 don't think about the docker. I just need procd to start services and then opens a shell. Is that feasible or only possible by a complex init process?
Jul 25 11:03:48 <blogic> the shell is spwaned by initd
Jul 25 11:05:24 <aparcar[m]> a) how can I make it spawn a shell
Jul 25 11:05:24 <aparcar[m]> b) using daemon causes it to have a pid != 1, so this is a problem, right? https://git.openwrt.org/?p=project/procd.git;a=blob;f=procd.c;h=3de62082bc62e4d21936a0cc5df0d93034a9d659;hb=HEAD#l77
Jul 25 11:06:21 <jow> why does it need a shell?
Jul 25 11:06:36 <jow> I thought docker container live as long as their root process lives
Jul 25 11:06:59 <jow> so procd without daemonizing sounds exactly what you want
Jul 25 11:07:07 <jow> +like
Jul 25 11:10:11 <aparcar[m]> jow: thanks for joining in. the gitlab runner do not support setting a docker CMD, which is the process running as pid 1. This means services like ubus/netifd would be missing. However, gitlab allows to set entrypoints [0], so my idea is to run procd (as a daemon) instead of initd. However this does not result in the spawning of a shell. [0]:
Jul 25 11:10:11 <aparcar[m]> https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#overriding-the-entrypoint-of-an-image
Jul 25 11:10:32 <aparcar[m]> maybe I got the wrong idea of the init process.
Jul 25 11:11:47 <jow> what about  sh -c 'procd -D; exec /bin/sh'   then?
Jul 25 11:12:22 <Tapper> It's so hot here that I cant build OpenWrt on my computer.
Jul 25 11:12:30 <aparcar[m]> jow: https://pastebin.com/05bCeYjV
Jul 25 11:12:40 <blogic> Tapper: because you are holding an ice cream in both hands ?
Jul 25 11:12:45 <Tapper> CPU over heats and shuts  down
Jul 25 11:12:51 <blogic> :-D
Jul 25 11:13:04 <olmari> It's jelly for your 2 icecream, it has 0
Jul 25 11:13:53 <Tapper> ice cream sounds good rite now.
Jul 25 11:15:51 <Tapper>       Motherboard                                       52 °C  (126 °F)
Jul 25 11:15:51 <Tapper>       CPU                                               57 °C  (135 °F)
Jul 25 11:16:03 <Tapper> That's at idle
Jul 25 11:16:16 <jow> aparcar[m]: I fear I don't understand the problem
Jul 25 11:16:46 <jow> the example documentation you linked tells how to disable the entrypoint entirely so that the container does not run any command at all
Jul 25 11:17:23 <aparcar[m]> jow: I'd like to tell it to actually run /sbin/procd -D && /bin/ash
Jul 25 11:18:01 <aparcar[m]> however that's no possible from what I understand. So I though of telling procd to fire up a shell before daemonizing itself into background
Jul 25 11:18:29 <jow> sh -c '/sbin/procd -D && exec /bin/sh'  should do exactly that
Jul 25 11:18:30 <aparcar[m]> jow: spoiler: using circleci it's possible to set CMD to /sbin/init which starts up openwrt just fine, with shell and everything
Jul 25 11:20:32 <jow> https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#setting-a-command-for-the-service
Jul 25 11:20:35 <jow> this looks like you want
Jul 25 11:24:30 <aparcar[m]> jow: from what I understand services are other containers which are then linked. like when i need a database backend. https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services
Jul 25 11:24:46 <aparcar[m]> therefore they are not really glued together the way procd would
Jul 25 11:25:19 <aparcar[m]> I found a solution to run it via https://stackoverflow.com/questions/54121031/multiple-commands-on-docker-entrypoint
Jul 25 11:25:20 <aparcar[m]> Now procd just has to even fire up thing when not running on pid 1, right?
Jul 25 11:25:58 <aparcar[m]> sorry for the mess, I'm just somewhat motivated that once we have openwrt smootly running in ci, automated testing could be vastly improved
Jul 25 11:31:13 <aparcar[m]> bueno, https://pastebin.com/8daHubZU so I'd suggest to ignore the pid 1 check when daemon mode is activated
Jul 25 11:32:36 <jow> blogic: why is the pid 1 check in procd i nthe first place? To prevent accidential execution later?
Jul 25 11:41:26 <aparcar[m]> jow blogic: I'd be happy if the -D daemonize command could go upstream and the pid1 check is removed entirely, replaced with a log warning or simply disabled when daemon mode is requested. Pleaes update me once you come up with something :)!
Jul 25 11:41:55 <aparcar[m]> jow: something else, is your github mirror script implemented via hooks or a cron? if the latter, could you pass me the script so i can setup a mirror to the gitlab testing/evaluation instance
Jul 25 11:46:45 <jow> hook
Jul 25 11:52:25 <blogic> jow: fietkauism
Jul 25 11:52:40 <blogic> i think he was testing stuff on mac ?
Jul 25 11:56:15 <ldir> telinit 0
Jul 25 11:56:49 <aparcar[m]> blogic: do you mind I post your daemon changes and remove pid1 check by that instance?
Jul 25 11:56:54 <blogic> oh bobie joes first speech is online
Jul 25 11:57:03 <blogic> ldir: make uk great again :-D
Jul 25 12:12:23 <stintel> lol
Jul 25 12:18:34 <blogic> stintel: its an amazing speec
Jul 25 12:18:38 <blogic> trump has a sidekick now
Jul 25 12:39:03 <stintel> I don't follow politics
Jul 25 12:39:06 <stintel> -ENOTIME
Jul 25 13:16:45 <Monkeh> stintel: -ENOTENOUGHBULLETS
Jul 25 13:17:35 <Monkeh> Totally need to define that somewhere
Jul 25 13:17:38 <stintel> -ETOOMANYIDIOTS
Jul 25 13:26:52 <blogic> Monkeh: L-)
Jul 25 13:28:30 <ssn> Hi
Jul 25 13:28:33 <ssn> Could this be merged please?
Jul 25 13:28:35 <ssn> https://patchwork.ozlabs.org/patch/1135461/
Jul 25 13:34:45 <blogic> ssn: there were changes requested, best mail the author and ask him to address these
Jul 25 14:12:19 <blocktrron> gch981213: your trigger finger was some seconds to fast :P https://github.com/openwrt/openwrt/pull/2230#discussion_r307314017
Jul 25 14:13:08 <gch981213> blocktrron: Oops...
Jul 25 14:14:14 <gch981213> missed that one. Will push a fix for it.
Jul 25 14:14:35 <blocktrron> np
Jul 25 14:14:57 <blocktrron> These types of diffs are really nasty to review...
Jul 25 15:04:51 <DonkeyHotei> blocktrron: i just noticed you did the .dts for the netgear ex6150, while i did the .dts for the netgear ex7300. they are similar and not consistent
Jul 25 15:11:07 <blocktrron> DonkeyHotei: huh? can you give me some context?
Jul 25 15:12:23 <blocktrron> They are completely different targets and share close to none similarities (ath79 vs. ramips/ipq40xx)
Jul 25 15:13:24 <DonkeyHotei> blocktrron: compare the gpio definitions and you'll see what i'm talking about
Jul 25 15:18:45 <blocktrron> you mean the shift register or the led naming?
Jul 25 15:18:57 <blocktrron> Yes, the LED naming is ugly, i'll admit that.
Jul 25 15:22:32 <blocktrron> Hmm, i should probably remove lines-inital-states from the ex7300 and fritz4020 dtsi. This was a hacky attempt to set the latch bit before using gpio hog for that
Jul 25 15:31:12 <DonkeyHotei> blocktrron: the toggle, too
Jul 25 15:31:43 <DonkeyHotei> and yes, i based it on the fritzbox definition
Jul 25 15:40:49 <Slimey> jow told me to run "ubus call luci usb" and "ubus call luci leds", I get Command failed: Not found
Jul 25 15:58:51 <Slimey> nm
Jul 25 17:42:39 <mangix> jow: ping
Jul 25 17:43:01 <jow> mangix: pong
Jul 25 17:43:17 <mangix> any thoughts on this one? https://github.com/openwrt/packages/pull/8680
Jul 25 17:44:28 <jow> looks sane to me
Jul 25 17:45:06 <mangix> ok
Jul 25 18:52:18 <Slimey> i've discovered that is a mtd partition has a name like "/var" the Save mtdblock contents in luci wont work
Jul 25 18:58:00 <jow> doesn't surprise me at all
Jul 25 18:58:04 <jow> the code is'nt very elegant
Jul 25 18:59:41 <jow> apart from that, it explicitely checks for names without "/" to prevent path traversal attacks
Jul 25 19:11:35 <Slimey> jow what did you think of my error under the led page
Jul 25 19:13:05 <jow> Slimey: I fixed it
Jul 25 19:13:12 <jow> happened on devices without usb
Jul 25 19:13:33 <jow> https://github.com/openwrt/luci/commit/fd35e9a226965c1586228618d34597da0be48877
Jul 25 19:13:39 <Slimey> ah
Jul 25 19:13:43 <Slimey> nice
Jul 25 19:47:07 <DonkeyHotei> is the length field of a device tree property supposed to include a null termination byte?
Jul 25 20:15:38 <nickpower[m]> hi, I added ubus binding to send a csa action frame to do a seamless handover with clients. Actions frames are sent and received by client, but nothing happens. Typically, CSA frames are not actions frames instead, the are inserted in beacon frames. I wrote this issue in the OpenWrt Forum, but noone has any idea. I would be happy if someone could have a look at this.
Jul 25 20:15:39 <nickpower[m]> https://forum.openwrt.org/t/csa-action-frame/38408
**** ENDING LOGGING AT Fri Jul 26 02:59:59 2019