**** BEGIN LOGGING AT Fri Sep 18 14:26:43 2020
**** BEGIN LOGGING AT Fri Sep 18 14:31:50 2020
**** ENDING LOGGING AT Fri Sep 18 14:50:49 2020

**** BEGIN LOGGING AT Fri Sep 18 14:50:49 2020
**** BEGIN LOGGING AT Fri Sep 18 14:51:33 2020
**** BEGIN LOGGING AT Fri Sep 18 15:04:06 2020
**** BEGIN LOGGING AT Fri Sep 18 15:10:43 2020
**** BEGIN LOGGING AT Fri Sep 18 15:13:49 2020
Sep 18 15:20:07 <nick[m]2> is ist problamtic to build a zyxel nbg6617 with 4.19 kernel? when I flashed the image, I did not receive anything on vlan interface
Sep 18 15:24:37 <rotanid> which image?
Sep 18 15:26:17 <rotanid> vlan on nbg6617/ipq40xx may be broken in OpenWrt 19.07.4, use 19.07.3 until it is fixed. see https://bugs.openwrt.org/index.php?do=details&task_id=3273
Sep 18 15:27:16 <rotanid> but there are not much reactions from maintainers so far, also on the forums: https://forum.openwrt.org/t/vlan-tagging-on-ipq40xx-gl-b1300-no-longer-works/69569
**** BEGIN LOGGING AT Fri Sep 18 15:49:59 2020
**** BEGIN LOGGING AT Fri Sep 18 16:08:05 2020
**** BEGIN LOGGING AT Fri Sep 18 16:42:12 2020
Sep 18 16:48:04 <nick[m]2> I'm able to run vlan on 19.07.4
Sep 18 16:48:05 <nick[m]2> finally xD
Sep 18 16:48:13 <nick[m]2> rotanid: thanks!
Sep 18 16:49:22 <rotanid> how did you do it? manual patching?
Sep 18 16:49:25 <rotanid> nick[m]2:
Sep 18 16:49:49 <nick[m]2> I have no idea, I compiled openwrt master with 4.19 kernel
Sep 18 16:49:58 <nick[m]2> and then did that tagging of wan port
Sep 18 16:50:00 <nick[m]2> to vlan 2
Sep 18 17:13:23 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
Sep 18 17:49:59 <adrianschmutzler> rmilecki: did you have a chance to look at the partial writes stuff? or should I wait for the weekend?
**** BEGIN LOGGING AT Fri Sep 18 18:00:13 2020
**** BEGIN LOGGING AT Fri Sep 18 18:20:28 2020
**** BEGIN LOGGING AT Fri Sep 18 18:24:41 2020
**** BEGIN LOGGING AT Fri Sep 18 18:49:37 2020
Sep 18 19:06:24 <Grommish> Anyone have an opinion on the best way to pcap?  just tcpdump?
Sep 18 19:08:18 <nick[m]2> blocktrron hey, I saw your commit regarding ipq40X vlan tagging. I plugged just a cable in the wan port and enabled vlans with 'eth1.42'... today I realized that sending speed is very slow at around 1.5 mbits. Sadly I installed the router on a church. XD receiving is total fine. I think I did not include your commit. I'm not sure if it will break my device setup completely or fix the performance issue. Since it is a
Sep 18 19:08:19 <nick[m]2> Fritzbox 4040 it has more than one port. But the wan port is somehow wired to vlan2. So I think I need double vlan tagging stuff? I would just test myself, but I can not easily get on that church roof ^^
Sep 18 19:09:57 <nick[m]2> https://github.com/openwrt/openwrt/commit/2e6c236abd0bebe82bf9020941f34344acb3ae1f#diff-f83986d4a7afa03d3712dcc845e06900
Sep 18 19:13:01 <nick[m]2> But maybe it is completely unrelated
Sep 18 19:28:01 <blocktrron> nick[m]2: completely unrelated, this commit only affects devices with RGMII PHY
Sep 18 19:28:32 <blocktrron> There was a commit regarding the double tagging behavior some weeks ago, maybe this makes a difference
Sep 18 19:29:42 <blocktrron> I'll have a look later. I have a 4040 around here
Sep 18 19:31:22 <nick[m]2> that would be so nice, if u could have a look. otherwise I will have to climb that church somehow. xD but sounds like double tagging since the wan port is mapped to vlan2. so v2(v42(data)) ? But not sure.
**** BEGIN LOGGING AT Fri Sep 18 20:16:31 2020
**** BEGIN LOGGING AT Fri Sep 18 20:21:25 2020
**** BEGIN LOGGING AT Fri Sep 18 20:49:22 2020
Sep 18 21:15:57 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
**** BEGIN LOGGING AT Fri Sep 18 21:23:15 2020
**** BEGIN LOGGING AT Fri Sep 18 21:52:14 2020
**** BEGIN LOGGING AT Fri Sep 18 21:56:11 2020
Sep 18 22:01:27 <aparcar[m]> mangix: ping
Sep 18 22:01:28 <aparcar[m]>   * print_dependents_warning: Package zstd is depended upon by packages:
Sep 18 22:01:28 <aparcar[m]>  * print_dependents_warning: 	boost-iostreams
Sep 18 22:01:34 <aparcar[m]> should I change something about the CI runtime test?
**** BEGIN LOGGING AT Fri Sep 18 22:03:31 2020
Sep 18 22:08:03 <mangix> I have no idea
Sep 18 22:08:16 <mangix> there are similar errors with the python packages
Sep 18 22:08:56 <mangix> as for the zstd thing, I have a patch that changes it to libzstd, as it should be
**** BEGIN LOGGING AT Fri Sep 18 22:10:50 2020
Sep 18 22:12:23 <mangix> hmmmmm how do I get the artifacts?
Sep 18 22:12:49 <aparcar[m]> which artifacts?
Sep 18 22:12:58 <mangix> https://github.com/openwrt/packages/actions/runs/261811547
Sep 18 22:13:51 <aparcar[m]> oh maybe they're only stored on success
Sep 18 22:13:54 <aparcar[m]> I'll look at the cofig
Sep 18 22:16:46 <mangix> yeah I want to know which packages get selected
Sep 18 22:17:20 <aparcar[m]> now the artifcts are there
Sep 18 22:17:38 <aparcar[m]> I think you can't download them until the action is finished, because later actions can modify previously created artifacts
Sep 18 22:17:55 <mangix> yeah but that one is finished
Sep 18 22:18:15 <aparcar[m]> no
Sep 18 22:18:17 <aparcar[m]> now it is
Sep 18 22:18:22 <aparcar[m]> but the circleci was still running
Sep 18 22:18:43 <mangix> CircleCI will always fail on boost since it uses too little RAM
Sep 18 22:18:59 <aparcar[m]> and via API the circleCI could push an artefact which overwrites an GitHub CI created artefact
Sep 18 22:19:16 <aparcar[m]> it doesn't matter if fail or not, it just about an active job is running or not
Sep 18 22:19:22 <aparcar[m]> (my understanding)
Sep 18 22:19:41 <aparcar[m]> anyway I see plently of artefacts here now https://github.com/openwrt/packages/actions/runs/261811547
Sep 18 22:19:48 <mangix> OK
Sep 18 22:20:03 <mangix> zstd shows up in the artifacts
Sep 18 22:20:09 <mangix> why is it even selected.........
Sep 18 22:21:16 <aparcar[m]> shrug
Sep 18 22:21:54 <aparcar[m]> I'll migrate some more CircleCI tests over to GitHub tests and make a chain. If you do some boost and gnunet PRs you basically DDoS the CI
Sep 18 22:23:14 <mangix> according to make menuconfig, only boost-iostreams selects zstd, which this PR changes
Sep 18 22:24:10 <mangix> hmmm all of the xz-utils are selected too. only liblzma should be selected.......
**** BEGIN LOGGING AT Fri Sep 18 22:46:59 2020
Sep 18 23:14:31 <aparcar[m]> mangix: I think it automatically selects all packages from the packages_ci stream, wondering if it selects some packages from the upstream packages feed...
Sep 18 23:20:20 <aparcar[m]> mangix: I could modify gh-openwrt-sdk to exclude the packages.git feed and only include the CI one, but I think the root problem is somewhere else
**** BEGIN LOGGING AT Fri Sep 18 23:57:36 2020