**** BEGIN LOGGING AT Thu Dec 17 02:59:57 2020 Dec 17 03:48:57 ynezz: https://github.com/openwrt/openwrt/commit/e52d0487e88c3c8c57e1310d1a02b18eae0d142e is totally broken on arch linux Dec 17 03:49:46 a bunch of autotools packages try to link to host libraries Dec 17 04:42:55 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 97.3% packages reproducible in our current test framework.) Dec 17 06:44:11 aparcar[m]: did you read my email? :P Dec 17 06:44:18 yes Dec 17 06:44:25 maybe I missunderstood it Dec 17 06:44:29 but you naked it Dec 17 06:44:53 but then hauke dropped support for 5, meaning 6 is the minimum anyway isn't it? Dec 17 06:45:13 it's host Vs target Dec 17 06:45:33 we don't build complete toolchain for the host Dec 17 06:45:41 those 5 patches were for target Dec 17 06:45:56 s/5/v5/ Dec 17 06:46:05 oh Dec 17 06:46:19 than this was entirely unrelated Dec 17 06:46:24 *then Dec 17 06:56:28 mangix: AFAIU that commit has just exposed issues which should be fixed Dec 17 07:06:33 so I'm running latest master on realtek switch with following DSA configuration http://sprunge.us/XT1ZEQ and it seems like the VLANs are not isolated properly as I'm seeing broadcast/multicast traffic from vlan10/router-lan on vlan200/testbed-lan Dec 17 07:08:20 how do I build ncurses with the binaries tic and tput? I've tried adding the suggestion to the Makefile at https://forum.openwrt.org/t/unable-to-compile-libncurses-with-tic-tput/48949 but it still builds just the libs Dec 17 07:08:37 basically for the start I'm trying to separate 28 port switch into 3 smaller 4-port switches and then continue to add more stuff Dec 17 07:15:47 Strykar: do you need tic and tput on the target? Dec 17 07:16:58 Strykar: or on the host? The install section is not related to building anyway. Dec 17 07:18:07 PaulFertser: on the target Dec 17 07:21:42 Strykar: then you need to modify Install section Dec 17 07:22:25 Strykar: and change --without-progs to --with-progs probably Dec 17 07:22:59 PaulFertser: isn't that what the define Host/Install was doing? I have changed to --with-progs, this is the Makefile - https://gist.github.com/Strykar/5cbcccdbb185d2689bb0d7f0c3c4abf7 Dec 17 07:24:20 Strykar: Host/Install is unrelated to what gets packaged in ipk to be installed on target. Dec 17 07:27:41 PaulFertser: so it should be under "define Package/libncurses/install"? Dec 17 07:55:21 that only builds ncursesw6-config Dec 17 08:03:56 uh, i just installed luci-app-ddns and ddns-scripts-cloudflare and it done successfully. it is forever looping now in background doing 'opkg --force-removal-of-dependent-packages --force-overwrite --nocase info ddns-scripts'. why? Dec 17 08:23:13 ynezz: sure but someone has to fix them :\ Dec 17 08:23:47 i try to add a spi device to my Linkit Smart 7688 but `ls /dev/*spi*`does not show any available spi where the docs say the MT7688N has two. Do i have to enable it somehow? Dec 17 08:23:53 https://www.irccloud.com/pastebin/foU1hnRO/ Dec 17 08:29:29 novski__: you are missing the spi-dev driver most likely Dec 17 08:34:42 Strykar: you can run with V=sc to see what exactly is getting built Dec 17 08:35:17 Strykar: and you can run the build manually on your host system to see what arguments are needed for the tools you're interested in. Dec 17 08:39:19 ynezz: is it even a supported syntax for switch bridge? shouldn't you use type = 'bridge' and tag ports with ifname.iftag ? Dec 17 08:40:44 https://openwrt.org/docs/guide-user/base-system/basic-networking bridge_empty might be needed if you create an empty bridge at first Dec 17 08:45:39 damex: it seems like it is supported syntax for DSA, because netifd creates the network as requested Dec 17 08:46:30 just some bits are missing, possibly /sys/devices/virtual/net/switch/bridge/multicast_router should be set to 0 as well Dec 17 08:46:35 ynezz: any docs? because with dsa you're supposed to create bridge over that interfaces and proper dsa management is not implemented yet Dec 17 08:47:41 `bridge vlan` output http://sprunge.us/JUwbO7 Dec 17 08:48:00 PaulFertser: right, I havent managed to package it, but I did get tic to build, and even with libncurses-dev installed on the target - https://bpa.st/QQCA which looks like a glibc issue Dec 17 08:48:14 damex: no docs unfortunately :) Dec 17 08:49:16 damex: I've got most of the info from https://github.com/openwrt/luci/pull/4307 Dec 17 08:49:56 I'm not a programmer, it might be easier to find someone on fiverr to do this.. the openwrt forum post is one year old with 1 response Dec 17 08:50:08 Strykar: looks like you have tried to copy tic compiled for host to your target. Dec 17 08:50:44 that was what I thought at first, but it's size was 1/10th of the other tic binaries Dec 17 08:50:57 Strykar: where did you copy it from exactly? Dec 17 08:52:09 PaulFertser: ~/openwrt-sdk/openwrt-sdk-19.07.4-x86-64_gcc-7.5.0_musl.Linux-x86_64/build_dir/target-x86_64_musl/ncurses-6.1/progs Dec 17 08:53:26 there's even an example (for the host) at https://github.com/openwrt/openwrt/blob/openwrt-19.07/package/libs/ncurses/Makefile#L170 but I can't seem to convert that for the target Dec 17 08:55:25 Strykar: my guess is that those programs are compiled for the host to help building the databases etc. So you need some trick to cross-compile them. Dec 17 09:12:02 * ldir urghs Dec 17 09:14:02 ynezz: a few days ago i became aware of this in the context of adding support for bullet-ac: https://github.com/true-systems/ubnt-openwrt-flashing ... did you give any thought to trying to disable the rsa key check in the ubiquiti u-boot? Dec 17 09:15:39 russell--: it should be doable, yes Dec 17 09:20:04 i don't know mips binary instructions, but i assume the sed is replacing an branch with a no op of some kind Dec 17 09:20:28 a* branch Dec 17 09:21:09 which sed? Dec 17 09:22:09 oh, sorry. i was referring to the flashing instructions where fwupgrade.real is hexdump'd through a sed and then reverse hexdump'd Dec 17 09:22:48 like described here: https://patchwork.ozlabs.org/project/openwrt/patch/874kkm3th8.fsf@husum.ptp/ Dec 17 09:23:32 hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | hexdump -R > /tmp/fwupdate.real Dec 17 09:23:33 yes, correct Dec 17 09:24:12 nice Dec 17 09:24:59 but doing this for u-boot is obviously more risky Dec 17 09:27:15 yeah, probably not worth it. Dec 17 09:27:27 it depends on the volume Dec 17 09:27:55 it would be nice if you could flash from urescue Dec 17 09:29:38 yeah, tell that to UBNT :p Dec 17 09:29:45 but seems like the steps to accomplish that would be far beyond the available methods Dec 17 09:29:50 yeah, totally. Dec 17 09:31:50 anyway, i appreciate the work you put into finding the magic instructions Dec 17 10:00:14 ynezz: I'm getting fallout from that specs cahngfe too, though I agree it looks right :| https://paste.jvnv.net/view/8ghmN was me trying to understand it the other day, but it's same now, a sunxi build fails, but ath79 works, for the same app, while other apps do build on sunxi, and the sunxi build is fixed when I revert the rules.mk change :| Dec 17 10:17:39 I everyone. I am struggeling with a custom kernel configuration. I can not enable NET_DROP_MONITOR. Does anyone have a hint for me? I also described my issue in the forum: https://forum.openwrt.org/t/enabling-net-drop-monitor/82259 Dec 17 14:56:59 https://www.friendlyarm.com/index.php?route=product/product&product_id=284 looks interesting :) Dec 17 16:37:37 If I create a package that only consists of local files, will I create Build/Prepare and Build/Configure as empty or leave them undefined? Dec 17 16:49:28 adrianschmutzler: i think empty Dec 17 16:50:16 Build/Compile and Build/Configure in my case Dec 17 16:50:18 nothing to compile either, just uci-defaults/scripts Dec 17 16:50:29 Build/Compile needs to be empty indeed Dec 17 16:50:46 but I'm not sure about the other two, have found different examples Dec 17 16:51:52 empiricism, ftw Dec 17 16:52:48 I have actually already tried to read the package*.mk files, but I'm still not really sure since I'm dealing to rarely with that stuff Dec 17 16:58:00 well, let's just remove them and see whether building explodes in my face ... Dec 17 16:59:07 that's exactly what i would do (did*, iirc) Dec 17 17:03:08 adrianschmutzler: https://stackoverflow.com/questions/3477292/what-do-and-do-as-prefixes-to-recipe-lines-in-make, check which commands in Build/* are prepended with +, these will fail the build if not redefined. Dec 17 17:05:22 tmn505: thanks. However, all of the relevant definitions are flagged as optional in the documentation, and I also found defaults in the package*.mk files already. The question is more whether these defaults are suitable Dec 17 17:05:35 (as I can only partially judge the latter) Dec 17 17:06:31 I suspect that it just won't matter without an external source pulled, but I'm not sure Dec 17 17:07:16 tmn505: btw, you are the one with the c-75 patches? Dec 17 17:11:21 adrianschmutzler: yes Dec 17 17:12:40 I'm not really satisfied with the partition labels, I'm still looking for something that both expressed your "reserved" but also the fact that these are part of the concatenated partition Dec 17 17:14:12 but I'm still searching for an idea there ... Dec 17 17:14:13 I'm fine with whatever You'll come up with. Dec 17 17:15:22 it's not so much about your patch, I will just merge it later. Dec 17 17:15:56 but eventually the points you made were valid, and we should label it to something preventing users from changing it on all devices Dec 17 18:05:19 tmn505: the buffalo wzr600dhp has two spi flash chips Dec 17 20:00:42 will there be another 19.07 release? I guess so right? Dec 17 20:48:27 given we only just did the last 18.06, I would _expect_ so, especially as we haven't even _branched_ for a new release... Dec 17 20:48:52 it tends to be regarded as bad form to EOL something before the replacement is even available :) Dec 17 20:50:06 yes there will be a next 19.07 release Dec 17 21:11:54 :P Dec 17 21:15:47 thanks Dec 17 21:16:41 aparcar[m]: why are you asking? Dec 17 21:17:01 Borromini: backporting Dec 17 21:17:31 :) Dec 17 21:17:54 even without releases it would be seeing security fixes Dec 17 21:18:11 https://lists.openwrt.org/pipermail/openwrt-adm/2020-December/001828.html < did you see Hauke's proposal? Dec 17 21:19:40 https://github.com/openwrt/openwrt/pull/3696 more relevant to the firmware selector Dec 17 21:19:50 why does /dev not show any spi when `ls /dev/*spi*` when i have `kmod-spi-dev [=y]` in menuconfig ? Dec 17 21:21:32 aparcar[m]: ok :) Dec 17 21:21:32 reboot :3? Dec 17 21:24:39 https://www.irccloud.com/pastebin/QaaDtcfe/ Dec 17 21:29:28 novski__: what are you running on? kernel 4.14 looks way to old Dec 17 21:29:44 im on 19.7 Dec 17 21:30:34 19.07.4, r11208-ce6496d796 exactly Dec 17 21:31:26 aparcar[m]: hehehe. all of 19.07 is on 4.14 :P Dec 17 21:31:41 awkward Dec 17 21:31:41 well, not even i think. there's some targets on 4.9 even Dec 17 21:31:47 sorry Dec 17 21:32:44 ah sorry Linux version 4.14.195 Dec 17 21:33:44 do i have to download the package again an just try another build? Dec 17 21:36:07 novski__: please compare the checksums Dec 17 21:36:22 maybe something went wrong with the download Dec 17 21:37:24 aparcar[m]: i will. Thanks Dec 17 21:47:47 adrianschmutzler: what do you think about not requiring a PKG_BUMP for base-files anymore and entirely use the number of commits? It's inconvenient to ping everyone to raise the PKG_RELEASE, especially if 5 people have patches in parallel, because then we have to fixup the release anyway. Dec 17 22:26:44 seems reasonable for base-files, where the content is in the repo, and the seq number is used elsewhere. Dec 17 22:26:58 could arguably be applied to all packages in core... Dec 17 22:42:55 the scheme breaks down if you factor in branches Dec 17 22:58:47 I thought this was just proposed for the pkg-release bit? so the pkg-version would still be relevant, but yeah, it could get confusing. Dec 17 23:16:31 aparcar[m]: 4.14 is LTS Dec 17 23:16:51 4.4 on the other hand is super LTS Dec 17 23:26:08 mangix: 4.4, 4.9, 4.14, 4.19, 5.4, 5.10 (this is the odd one out :P). Dec 17 23:26:24 (Or, shall I say, even. :P) Dec 17 23:31:43 whatever happens to be the last stable kernel published in a calendar year Dec 17 23:32:03 ..with a little wiggle room in either direction Dec 17 23:32:59 rsalvaterra: I forgot how it went. 4.4 is super LTS as well as 4.19 I think Dec 17 23:33:19 4.4 will be supported through 2038 I believe Dec 17 23:33:36 blame the japanese Dec 17 23:33:58 that's the one for trains and shit right? I remember they wewre planning some super long term maintennance Dec 17 23:34:16 yep. they call it "social infrastructure" Dec 17 23:34:27 based on kernel 4.4 Dec 17 23:35:27 i don't think 4.4 is even year 2038 safe Dec 17 23:36:03 well, 5.10 is going to be SLTS too: https://www.cip-project.org/blog/2020/12/02/cip-to-embark-on-kernel-5-10-development-for-slts Dec 17 23:36:41 so basically what red hat does but upstream Dec 17 23:37:01 pure madness Dec 17 23:38:37 found it: https://youtu.be/vyenmLqJQjs?t=685 Dec 18 00:03:16 jow I don't understand how it break the schema? Dec 18 00:03:26 karlp: can you explain? Dec 18 00:05:10 the numbers don't track neatly in forward directions when you start forking I think they mean, Dec 18 00:05:32 I think that should only matter if you're proposing to use the rev number as the _only_ version Dec 18 00:11:51 yea that what i'd propose Dec 18 00:12:08 so no more manual changes to that Dec 18 00:12:29 I don't see a problem when forking, the numbers should stay the same + commit hash Dec 18 00:45:19 * m4t running linux-cip-rt w/recent master using external tree Dec 18 00:45:40 the only oddity i saw was that the uImage is still labeled at 5.4.x or whatever Dec 18 00:59:28 aparcar: I'm actually not so keen on spending my life with "please do increase PKG_RELEASE" Dec 18 00:59:54 my last information was that you said roughly "we have to increase that with every change or somebody will die terribly" Dec 18 01:00:40 In a git world, I won't mind if we come back to a point where we only change it when it is actually relevant for opkg users Dec 18 01:00:57 i.e. like it was before ;-) Dec 18 01:01:33 however, I'm not sure how we should handle base-files in particular Dec 18 01:18:12 adrianschmutzler: how does it not always matter? Only on cosmetic changes it doesn't matter. Dec 18 01:19:12 well, it matters if it's a functional change and it's a package that the user might want to update Dec 18 01:19:42 e.g. nobody cares about PKG_RELEASE for uboot-envtools Dec 18 01:19:52 adrianschmutzler: yes. So why not make it automatic? We could even do it for other tools too Dec 18 01:20:23 depends obviously on _how_ you want to make it automatic Dec 18 01:23:37 Similar to Luci? Dec 18 01:24:01 Or even the same, so Luci can use that code fragment Dec 18 01:25:09 I have no idea how luci does that Dec 18 01:36:43 I'll create a pr **** ENDING LOGGING AT Fri Dec 18 02:59:56 2020