**** BEGIN LOGGING AT Thu Apr 04 02:59:57 2019 Apr 04 04:30:02 jow: i was (at least partially) right about that rtcache compilation problem Apr 04 04:30:34 jow: Hauke: "*rt6i_node;" was renamed to the "fib6_node" in upstream commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93c2fb253d177a0b8f4f93592441f88c9b7d6245 ("net/ipv6: Rename fib6_info struct elements") Apr 04 04:31:43 jow: Hauke: OpenWrt's target/linux/generic/backport-4.19/020-backport_netfilter_rtcache.patch still uses "rt6i_node", see https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/backport-4.19/020-backport_netfilter_rtcache.patch;hb=HEAD Apr 04 04:32:26 jow: Hauke: it means 4.19 won't compile in OpenWrt if using CONFIG_NF_CONNTRACK_RTCACHE and CONFIG_NF_CONNTRACK_IPV6 Apr 04 04:33:11 so the question is why noone noticed it so far... is there a problem with CONFIG_NF_CONNTRACK_RTCACHE or CONFIG_NF_CONNTRACK_IPV6 when using 4.19 kernel? Apr 04 04:44:53 jow: Hauke: oh, there is also https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77634cc67dc1ffc8ae6d869af6dee4b2ea6025ee ("net/ipv6: Remove unused code and variables for rt6_info") Apr 04 04:48:05 1. commit a64efe142f5e ("net/ipv6: introduce fib6_info struct and helpers") added a NEW "struct fib6_info" with "rt6i_node" Apr 04 04:48:07 2. commit 77634cc67dc1 ("net/ipv6: Remove unused code and variables for rt6_info") removed "rt6i_node" from the OLD "struct rt6_info" Apr 04 04:48:08 3. commit 93c2fb253d17 ("net/ipv6: Rename fib6_info struct elements") renamed "rt6i_node" to "fib6_node" in the NEW struct "struct fib6_info" Apr 04 04:48:48 020-backport_netfilter_rtcache.patch has to be updated to: 1. use NEW struct "struct fib6_info" 2. use new name "fib6_node" Apr 04 04:53:10 i think we need: if (rt->from && rt->from->fib6_node) return (u32)rt->from->fib6_node->fn_sernum; Apr 04 06:55:39 jow: if you have a moment to look at that... with kernel 4.14 I get: Apr 04 06:55:41 egrep "CONFIG_NF_CONNTRACK_RTCACHE|CONFIG_NF_CONNTRACK_IPV6" build_dir/target-*/linux-*/linux-*/.config Apr 04 06:55:43 CONFIG_NF_CONNTRACK_RTCACHE=m Apr 04 06:55:44 CONFIG_NF_CONNTRACK_IPV6=m Apr 04 06:55:52 so perfectly fine, just as expected Apr 04 06:56:06 the problem appers after switching to a kernel 4.19 Apr 04 06:56:08 egrep "CONFIG_NF_CONNTRACK_RTCACHE|CONFIG_NF_CONNTRACK_IPV6" build_dir/target-*/linux-*/linux-*/.config Apr 04 06:56:09 CONFIG_NF_CONNTRACK_RTCACHE=m Apr 04 07:34:26 rmilecki: hmm, iirc conntrack-ipv6 moved around a bit, maybe it is improperly packaged for 4.19 Apr 04 07:34:44 it could be Apr 04 07:35:07 jow: i probably won't have time to look at that for the next weeks :( Apr 04 07:35:20 i sent a patch for rtcache though Apr 04 07:35:30 rmilecki: thats fine. 4.19 isn't exactly a priority for me Apr 04 07:35:41 maybe someone else will look into it Apr 04 07:37:29 rmilecki: but you did update your openwrt .config accordingly (defconfig etc.), did you? Apr 04 07:37:48 I did "make oldconfig" and kept pressing ENTERs Apr 04 07:37:54 should be ok Apr 04 07:38:08 is kmod-nf-conntrack6 selected? Apr 04 07:38:21 CONFIG_PACKAGE_kmod-nf-conntrack6=y Apr 04 07:38:38 ok Apr 04 07:40:53 then maybe there's new dependencies for CONFIG_NF_CONNTRACK_IPV6 in upstream kconfig Apr 04 07:41:37 i thought of that, but didn't notice any Apr 04 07:41:48 oh, wait, I was checking kernel 4.18 Apr 04 07:41:51 maybe there is some in 4.19 Apr 04 07:44:50 well actually it got dropped in 4.19 Apr 04 07:45:12 there is no dedicated CONFIG_NF_CONNTRACK_IPV6 anymore as the code was merged with the common ipv6 conntrack Apr 04 07:45:21 *common ipv4 conntrack Apr 04 07:46:05 so the offending rtcache code likely never gets compiled with K4.19+ because the guards used by it do not exist anymore Apr 04 07:48:50 i see Apr 04 07:50:01 what the helll... does compiling Linux require openssl now?! starting with the 4.19? Apr 04 07:50:03 extract-cert.c:(.text.startup+0xe): undefined reference to `OPENSSL_add_all_algorithms_noconf' Apr 04 07:50:22 yes, its that secure keyringh thing we debugged a while back Apr 04 07:50:26 it seems that with 4.19 extract-cert requires openssl specific symbol Apr 04 07:50:41 you added an explicit linkage to -lcrypto to fix it Apr 04 07:50:53 jow: right but now -lcrypto is not enough Apr 04 07:50:54 a leftover from that? Apr 04 07:51:12 ah yes, because you're likely linking against a dynamic openssl Apr 04 07:51:17 i still use -lcrypto but it doesn't work with 4.19 (it used to work with 4.18 and earlier) Apr 04 07:51:23 not the static openwrt libressl Apr 04 07:51:33 well then -lcrypto -lssl :D Apr 04 07:51:33 oh crap Apr 04 07:52:13 wait until they start to depend one nodejs and go to transpile some scripts :P Apr 04 07:53:00 well anyhow, the way it looks, the rtcache for ipv6 is simply completely broken with kernel 4.19 and onwards at the moment Apr 04 07:53:23 oh ;) Apr 04 07:53:25 broken as in not used, so I'd expect more or less significant ipv6 throughput regressions Apr 04 07:55:38 4.19 will need more work it seems Apr 04 07:55:48 there is also a problem with STACKPROTECTOR I think Apr 04 07:55:57 OpenWrt's config doesn't control it correctly anymore I'm afraid Apr 04 07:56:04 i have to verify that yet Apr 04 07:57:26 I guess the guards need to be changed to something like #if IS_ENABLED(CONFIG_IPV6) Apr 04 07:58:58 conntrack_core.c does the same now on 4.19: https://elixir.bootlin.com/linux/v4.19.33/source/net/netfilter/nf_conntrack_core.c#L319 Apr 04 07:59:11 sounds OK then I think? Apr 04 08:00:28 your patch is fine but not broad enough in scope Apr 04 08:00:51 it also needs s/#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)/#if IS_ENABLED(CONFIG_IPV6)/ Apr 04 08:01:40 which might or might not reveal further broken code Apr 04 08:01:45 got it :) Apr 04 08:43:37 oh my, now we have some fancy API for setting PHY dev capabilities... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c1bcc8614db10803f1f57ef0295363917448cb2 ("net: ethernet: Convert phydev advertize and supported from u32 to link mode") Apr 04 08:51:42 ah, there a new NAT performance regression between 4.19 and 5.0, GREAT Apr 04 08:52:17 Aren't we glad it isn't same old regression? ;) Apr 04 08:53:35 olmari: oh, don't worry, I have some old regressions too ;) Apr 04 08:59:13 who cares about regressions, its Linux 5! Thats like five times better. We must immediately switch to it because it works great on that one ARM board Apr 04 08:59:37 the rest should just buy new hardware Apr 04 08:59:44 ... Apr 04 09:00:17 ;D Apr 04 09:04:21 philipp64: you might want to start testing https://github.com/openwrt/openwrt/pull/1968/files Apr 04 09:04:32 philipp64: its a way more polished approach then what I have in my tree Apr 04 09:04:46 lets switch to 5 quickly before the branch-off? Looks good on paper .. ;-) Apr 04 09:04:58 I also like that the guy opted to extend ptgen instead of bringing in some rather heavy new host tool deps Apr 04 09:05:26 I am still not 100% positive about the grub / grub-efi split, in my tests it led to random build errors when jumping back and forth Apr 04 09:09:08 I don't know what the general thing is with "grub-mbr" anf "grub-efi", but withmost desktopsystems they can't be installed at the same time either.. I mean I know the diffirence in bios and efi, but it doesn't need to relate to grub... Apr 04 09:11:09 olmari: no I mean the split of grub into two build variants the way it is done in the proposed PR. Iirc it is not 100% clean and the two variants tend to randomly clobber each others build stemps Apr 04 09:11:18 leading to spruious rebuilds, missing artifacts etc. Apr 04 09:11:34 mm... I see Apr 04 09:12:07 xback: hi! can you please check https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=dafbbf8eff947a81ccfd531cf0dab433b9c39c35 Apr 04 09:14:58 xback: BTW did this caused any harms during testing https://patchwork.ozlabs.org/patch/1020748/ ("ath79: ag71xx: Enable tx hang workaround for the rest of ar724x SoCs") ? Apr 04 09:15:27 jow, nbd: can we come with some conclusion on this http://lists.infradead.org/pipermail/openwrt-devel/2019-April/016552.html ? I would like to get x86/armvirt/malta fixed before 19.03 Apr 04 09:19:17 this https://patchwork.ozlabs.org/patch/1056981/ ("openssl: Fix longer booting times by unblocking getrandom") would be nice to solve before 19.03 as well, got bitten again just few moments ago, while trying to confirm FS#2222 Apr 04 09:23:56 seems like I'm still having that memleak on x86 with master. anyone good at hunting those? Apr 04 09:25:53 yeah, Mr. valgrind or Ms. kmemleak :) Apr 04 09:27:46 meh. seems I don't have kmemleak enabled anymore in that build Apr 04 09:28:31 pretty sure it's in the kernel, previous attempts pointed to conntrack, but I'm too dumb too understand the output let alone fix it Apr 04 09:41:04 strongSwan 5.8.0 will support virtual XFRM interfaces. when that's released I'll have a reason to try 4.19 :) Apr 04 09:41:11 no more messing with VTI Apr 04 09:43:20 stintel: ah so there will finally be netdevs to work with? Apr 04 09:44:09 jow: indeed Apr 04 09:44:57 just read https://lwn.net/Articles/757391/ Apr 04 09:45:13 the problem is I'll need to rework strongSwan - ipsec.conf will not support it iiuc Apr 04 09:45:19 make me wonder why that took decades Apr 04 09:45:34 I just updated my Netgear DM200 to the latest git source code, but is still not delivering packets on LAN after 300 seconds, as i explained here https://bugs.openwrt.org/index.php?do=details&task_id=1944&pagenum=4 Apr 04 09:45:56 ynezz: Good morning Apr 04 09:46:00 any idea? Apr 04 09:46:07 good morning everyone! :) Apr 04 09:46:16 going to rebuild that thing witk kmemleak enabled again Apr 04 09:46:23 srry for being late .. (i've spend lots of time in the hospital again with my kid) Apr 04 09:46:47 regarding the revert: if required, feel free to do so Apr 04 09:46:54 oh sorry to hear that. how's he (she) doing? Apr 04 09:47:00 xback: kid in hospital is way more important than being on-time in irc. hope all is well Apr 04 09:47:14 xback: ah, sorry to hear that about the kido, hope it's going better now Apr 04 09:47:31 jow: fully agree Apr 04 09:48:05 ynezz: I didn't had the time yet to actually test your patch. most of my devices here are native ar71xx Apr 04 09:51:37 xback: I don't want to revert it, as it would mean more work to fix that compile error again, so I would rather prefer to fix it if you don't mind. Regarding that ath79 patch, no worries Apr 04 09:59:33 ynezz: i'll check it later on. noted. thanks for the heads-up Apr 04 10:21:36 bcrmnand question here: if /proc/iomem on OEM shows "10000200-10000383 : brcmnand", does this mean i can get the nand detected using an entry in the dts like "nand@10000200 { ..."? Apr 04 10:26:53 i'm getting "unsupported NAND flash detected" Apr 04 10:41:08 donn_: maybe... root@OpenWrt:/# cat /proc/iomem | grep nand Apr 04 10:41:10 18028000-180285ff : 18028000.nand Apr 04 10:41:12 18028f00-18028f1f : 18028000.nand Apr 04 10:41:13 1811a408-1811aa07 : 18028000.nand Apr 04 10:41:33 donn_: it's from my BCM47094 SoC which has nand@18028000 with reg = <0x18028000 0x600>, <0x1811a408 0x600>, <0x18028f00 0x20>; Apr 04 10:43:56 donn_: are you sure you use brcmnand? that "unsupported NAND flash detected" seems to be coming from OpenWrt's downstream patch 411-MIPS-BCM63XX-Register-SPI-flash-if-present.patch Apr 04 10:44:05 i'm not sure if that patch is related to the upstream brcmnand driver Apr 04 10:44:16 KanjiMonster may have some idea Apr 04 10:44:48 oh, wait, i"m wrong, "unsupported NAND flash detected" is part of upstream arch code Apr 04 10:45:04 arch/mips/bcm63xx/dev-flash.c Apr 04 10:45:42 donn_: so that message is not from brcmnand at all Apr 04 10:45:58 donn_: make sure you use brcmnand, add some pr_info to its probe function Apr 04 10:45:59 KanjiMonster was helping me before, but with the mtd partitions, but i need to figure out how to get the flash detected first Apr 04 10:47:06 donn_: pr_warn("unsupported NAND flash detected\n") that means arch code has detected NAND flash, but it doesn't load any driver for the NAND controller Apr 04 10:48:18 ok Apr 04 10:48:29 that's what the message seems to imply Apr 04 10:51:18 the message means that pinstrapping indicates we booted from NAND, but (at that time) no nand driver is available to to attach partitions to - at *this* point it will also never change, as the now existing one only works when probed from of, not from platform Apr 04 10:54:31 so this means my hacking in the dts is in vain Apr 04 10:56:42 no, it means you need to hack the dts, and can't do anything at the place the message is printed Apr 04 10:57:07 donn_: don't worry about arch code warning, just play with DTS Apr 04 10:57:33 donn_: add DTS entry for nand controller & brcmnand driver, you don't even need pinctrl hacking it seems Apr 04 10:57:41 donn_: load kernel & see what happens Apr 04 10:57:57 ok Apr 04 10:58:43 rmilecki: meaning 'compatible = "nand,brcmnand"' or some such?= Apr 04 10:58:55 yes Apr 04 11:02:44 donn_: add some pr_info("Hello world\n"); at the beginning of brcmnand_probe() so you know it worked Apr 04 11:03:04 ok, compiling now :) Apr 04 12:51:21 jow:ping Apr 04 12:52:29 dedeckeh_: pong Apr 04 12:52:50 jow:does http://patchwork.ozlabs.org/patch/1074898/ look sane to you ? Apr 04 12:53:15 dedeckeh_: Acked-by Apr 04 12:53:27 thx Apr 04 12:57:34 " but again, while possible, it's one of the worst ways for installing stuff and basically never an acceptable approach (hint, you don't always have network access when installing a package - and you need corresponding postrm cleanup, etc.)" Apr 04 12:58:25 pkadd: I'm creating a package for tesseract, which consist of two parts: the software itself and the trained language models Apr 04 12:59:18 The whole languages consume nearly to 1GB of space. However, I was thinking about download the selected language in time-run Apr 04 12:59:38 should I discard this idea and do it by the classic way? Apr 04 12:59:58 brucethompson: ping Apr 04 13:00:08 whoever pinged me, ran out of my backlog buffer, but I'm here now Apr 04 13:00:10 hello Apr 04 13:00:27 Right now I managed to make it work calling directly to download.pl Apr 04 13:00:41 But is true that it depends of Internet connection Apr 04 13:00:51 vk496: I think shipping some "tesseract-download-language" helper command with the base package would be acceptable Apr 04 13:01:16 You left for lunch yesterday, and a message of mine didn't reach you: Apr 04 13:01:22 you can then echo something like "Please run tesseract-download-language to install language files" during postinstall Apr 04 13:01:25 you may simplify that URL. Use https://files.pythonhosted.org/packages/source/P/PyNaCl, and then you won't have to change that URL hash for every version bump. Apr 04 13:02:12 As jow pointed out, it's the hash in the url (.../61/ab/2ac6dea8489fa713e2b4c6c5b549cc962dd4a842b5998d9e80cf8440b7cd/...) Apr 04 13:04:43 jow: Currently I have subpackages for each language available, following the remarks of jeff: https://forum.openwrt.org/t/how-to-define-dynamic-list-of-packages/34596 Apr 04 13:05:29 Something like this: https://forum.openwrt.org/t/how-to-define-dynamic-list-of-packages/34596 (is not updated yet with the last modifications) Apr 04 13:05:41 Sorry, this one: https://github.com/vk496/packages/blob/2639aaedfa44cbba905b8328ff9b7d8d3ec0b1ad/utils/tesseract/Makefile Apr 04 13:09:15 that looks sane so far to me Apr 04 13:14:23 Ok, updated the file with what I currently have: https://github.com/vk496/packages/blob/d05ea7dffbf1957ac50178c93306908247bc218f/utils/tesseract/Makefile Apr 04 13:15:11 In line 75 is what I use to download what the user selected from menuconfig during the compilation time Apr 04 13:16:41 Using the classical way of download, the user should download 600M of languages (the .gz from the repo ) to copy a 5M language that he selected Apr 04 13:17:12 coteqeiroz: I will try that Apr 04 13:18:33 vk496: hm, yeah I understand the dilemma Apr 04 13:19:03 vk496: but if you really want to go that route you somehow need to include a list of checksums to ensure integrity Apr 04 13:19:33 Hi all, Apr 04 13:20:30 does anyone know where or how the libc package is made? I know the kernel and libc are virtual packages but I'm intrigued how they are made? I can't see a package Makefile in the package directory for example Apr 04 13:21:50 Neighbor11111118: the compilation business happens in toolchain/libc/, the "libc" opkg package is defined in the same Makefile as base-files Apr 04 13:22:23 Neighbor11111118: erm sorry, not base-files, it is in package/libs/toolchain/Makefile Apr 04 13:22:43 jow: hmmm, I understand. If I go throught the classic way (defining Download with URL and bla bla bla), do you know if I invoke the call method multiple times (put it inside the dynamic subpackages definition), will it be downloaded multiple times? Apr 04 13:22:44 the "toolchain" source package takes care of bundling the various components (libgcc, libc, librt etc.) Apr 04 13:23:09 Or the openwrt ecosystem takes care about the existence of already downloaded package? Apr 04 13:23:47 If checksums staff are mandatory, probably downloading the whole file would be better Apr 04 13:24:26 vk496: I think so as well, yes. In the end it is opt-in, someone who does not want to use or download the data simply has to not enable the package Apr 04 13:25:20 it could be an impact on the buildbot infrastructure but in the worst case we could simply blacklist the package there Apr 04 13:27:29 ack Apr 04 13:27:31 thnks Apr 04 13:31:42 Thanks Jow much appreciated! Apr 04 13:35:47 is there a faster way to update a dts in an image than just plain old make? Apr 04 13:46:30 joy .. Apr 04 13:46:34 Package libnetsnmp is missing dependencies for the following libraries: Apr 04 13:46:35 libpci.so.3 Apr 04 13:46:37 Makefile:285: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/bin/packages/arm_mpcore_vfp/packages/libnetsnmp_5.8-1_arm_mpcore_vfp.ipk' failed Apr 04 14:00:39 Hi, could my problem (https://bugs.openwrt.org/index.php?do=details&task_id=1944&pagenum=4) be caused by gphyfirmware? Apr 04 14:13:51 BigNerd95: i do know that the gphy fw supplied by openwrt is older than what netgear uses. you can try substituting from https://pastebin.com/9qAp0NcG and report back Apr 04 14:21:14 Ok thanks you, where do i have to put the binary file then? Apr 04 14:21:25 I don't understand this commit, https://github.com/openwrt/openwrt/commit/6eaf8b3d89571992a0aa7142cfab3f1dcef3c802#diff-619398f103a0ed980f8410aaee726aba Apr 04 14:21:36 it looks linke now openwrt uses the upstream driver? Apr 04 14:24:47 upstream meaning in the upstream kernel Apr 04 14:25:17 did you un-base64 and un-7z the pastebin? Apr 04 14:25:55 yesss Apr 04 14:26:38 now i have 6 xrx...bin files Apr 04 14:28:53 and the drivers used by netgear are more recent than drivers present in the upstream kernel? Apr 04 14:29:39 no, i was referring to the gphy fw files being newer Apr 04 14:30:25 you can drop them in target/linux/lantiq/files/firmware/lantiq/ Apr 04 14:36:37 ok, now recompile? Apr 04 14:38:39 just recompiled, but the md5 of the image i made this morning is the same of the new image Apr 04 14:44:40 hmm, idk Apr 04 14:45:04 search through build_dir/target-mips_24kc_musl/root-lantiq/ Apr 04 14:49:00 I can only find ./lib/firmware/xcpe_581816_580B11.bin and ./lib/firmware/lantiq-vrx200-a.bin Apr 04 14:49:15 are them compiled with the kernel? Apr 04 14:49:20 i can try with make clean Apr 04 14:55:22 ok now the md5 is different Apr 04 14:55:33 i try to flash and test it Apr 04 15:04:22 problem still present... Apr 04 15:04:48 then it's probably not that Apr 04 15:04:57 ping a device, then wait 300 seconds, try to ping again and the arp are not being sent for 15 seconds... Apr 04 15:05:20 i already tryed to modify all net.ipv4.neigh parameters Apr 04 15:05:27 but nothing change Apr 04 15:06:40 tcpdump show arp being sent, but the "pinged" device receive nothing, until the kernel send a broadcast arp Apr 04 15:06:53 after 15 seconds Apr 04 15:11:09 * ldir has been beaten into submission by the compiler into producing syntactically correct code - functionality remains to be tested Apr 04 15:13:56 at the moment i solved the problem with: sysctl -w net.ipv4.neigh.br-lan.ucast_solicit=0 Apr 04 15:15:01 now after 300 seconds, the kernel immediately send a broadcast arp (instead of a unicast arp) and it is delivered correctly Apr 04 15:50:08 i made other test, the problem is still present...so i'll flush the arp table each 300 seconds Apr 04 15:50:20 it is the only working solution for now Apr 04 15:54:44 It's Bruce Thompson again. I have gotten further in the build of pynacl for OpenWrt but now I am getting some type of build error. Apr 04 16:01:50 brucethompson:do you have logging or did you just join? Apr 04 16:02:06 cotequeiroz had some messages for you.. Apr 04 16:02:15 I know about those messages Apr 04 16:02:37 Not sure what you mean by "did you just join?" Apr 04 16:02:58 I have log files on the computer where I am trying to do the build. Apr 04 16:03:24 I am porting a new Python package PyNaCL to OpenWrt Apr 04 16:03:58 Had to create a new Makefile for it. Apr 04 16:04:31 Getting pretty far now but the package make is failing during the build process Apr 04 16:07:58 Here is the error I am getting (from config.log) Apr 04 16:08:28 The message is too long to post here. Apr 04 16:08:51 Would you like to see the error log? Apr 04 16:10:45 did you see cotequeiroz messages to you here? I meant irc logs Apr 04 16:11:34 nvm, I see now you actually replied later to them. Apr 04 16:11:34 and yes, you may want to share the build failure to a pastethingy Apr 04 16:15:02 OK. I am a newbie. I looked up pastethingy. Looks like a tool I need to download. Apr 04 16:16:10 But I am not exactly sure what I a supposed to do. Apr 04 16:16:33 Got any instructions? Apr 04 16:27:16 Now I got it. Apr 04 16:27:20 https://paste2.org/1pBC6BeD Apr 04 16:29:40 https://paste2.org/OYVcPD7f Apr 04 16:32:24 https://paste2.org/bt5XX61F Apr 04 16:41:16 Can you see the files I pasted? Apr 04 16:55:33 brucethompson: I will try to help you as well. I have a few questions first. Do you need to build a python2 variant of it? There is a discussion going on about deprecating python2 https://github.com/openwrt/packages/issues/8520 Apr 04 16:56:00 I know about that. Apr 04 16:56:20 Yes I have to build a python2 variant. Apr 04 16:56:52 The overall project is that I am getting Tahoe-LAFS to run on OpenWrt Apr 04 16:57:06 Tahoe-LAFS is Python 2.7 right now. Apr 04 16:57:27 Thanks Apr 04 17:00:48 OK. I'm building it here, and will report back when finished. Apr 04 17:03:48 OK. You are using my makefile? Apr 04 17:05:05 FYI. Tahoe-LAFS is going to Python3 but not there yet. Apr 04 17:07:21 I got your Makefile, yes. Apr 04 17:08:45 OK. Thx Apr 04 17:13:26 Why do you have these HOST_PYTHON{,3}_PACKAGE_BUILD_DEPENDS:="pynacl==$(PKG_VERSION)" lines? Apr 04 17:15:40 I used the makefile for python-cffi as a template Apr 04 17:15:41 I think I just copied it from there Apr 04 17:21:06 They are used to build the packages for the host. Unless you need a host build, you may ommit them. They are not causing your failure, apparently. Apr 04 17:21:50 Instruction for creating a python makefile for OpenWrt are here: Apr 04 17:21:55 https://github.com/openwrt/packages/tree/master/lang/python Apr 04 17:22:25 README.mk Apr 04 17:23:07 From that file: Apr 04 17:23:42 PKG_BUILD_DIR It's important when packaging for both Python & Python3 to override this variable, so that the build directory differs for each variant. Apr 04 17:23:42 Typically it's just something like: Apr 04 17:23:43 PKG_BUILD_DIR:=$(BUILD_DIR)/$(BUILD_VARIANT)-pyasn1-$(PKG_VERSION) Apr 04 17:26:32 Sorry I was wrong. The python makefile instructions say nothing about PACKAGE_BUILD_DEPENDS Apr 04 17:27:14 Are you getting the same failure? Apr 04 17:38:31 I got the failure OK. Apr 04 17:38:57 I see that the host package installed python-six. Don't we need that for the target as well? Apr 04 17:39:47 I don't know Apr 04 17:42:32 I'm building it now, then I'll try again to see if it works. Same with python-cffi. See line 26 and followin of https://paste2.org/1pBC6BeD where the host installs six and cffi. Apr 04 17:46:41 I see it Apr 04 17:47:54 rmilecki: I haven't noticed that CONFIG_NF_CONNTRACK_RTCACHE is not seletced and that we have a compile problem if it is selected Apr 04 17:48:27 You see that the build is failing in setup.py? Apr 04 17:49:47 rmilecki: jow: some dependencies in Kconfig changed for netfiter stuff, I think the defrag part was moved and now we have a lot of stuff with dependecies on IPv6 or something like this for kernel 4.19 Apr 04 17:51:46 rmilecki: I looked into STACKPROTECTOR and I think I fixed that in OpenWrt Apr 04 17:51:59 I think it is trying to install libsodium instead of using the system. Apr 04 17:52:46 I have a dependency on libsodium in the makefile Apr 04 17:53:07 But I remember it did the same thing (I think) when I removed that dependency Apr 04 17:56:35 You may need to add PYTHON3_PKG_SETUP_VARS:= SODIUM_INSTALL=system (and PYTHON_PKG...). I'm trying it now. Apr 04 18:01:54 That's it. So, you may remove the HOST build (need to make sure, cause now my staging_dir has it), remove pycparser (a dependency of cffi, not nacl) from DEPENDS, and add python-six and python-cffi instead. Apr 04 18:02:18 You got it??? Apr 04 18:02:26 Then add the PYTHON_PKG_SETUP_VARS:= SODIUM_INSTALL=system and PYTHON3_PKG_SETUP_VARS:= SODIUM_INSTALL=system Apr 04 18:02:50 Yes I did. I just haven't run-tested it. Apr 04 18:03:01 I can do that Apr 04 18:03:29 Could you paste the updated makefile? Apr 04 18:04:26 Also, remove that copyright line from the top of the Makefile. You may assign it to yourself, if you want. Apr 04 18:11:03 The package license is not right either. It is an Apache-2.0 license. Apr 04 18:12:37 You want me to remove HOST_PYTHON_PACKAGE_BUILD_DEPENDS and HOST_PYTHON3_PACKAGE_BUILD_DEPENDS? Apr 04 18:13:08 Here's the Makefile. I have left the host build lines commented, as you have to make sure they're indeed not needed. https://paste2.org/E1gWPtj7 Apr 04 18:13:42 After you're certain that they are not needed. Apr 04 18:14:06 Better, I'm going to test them for you right now. Apr 04 18:18:04 I just hand edited the makefile based on your instructions. Looks like it works!!!! Apr 04 18:18:15 I have a lot to learn.... Apr 04 18:18:49 Me too. Apr 04 18:19:20 Looks like you fixed the source URL too. Apr 04 18:19:32 Of course. Apr 04 18:22:01 To ensure we haven't missed any build dependencies, you may need to run 'make dirclean', and then 'make' to see if the package builds from a clean build environment. Apr 04 18:22:58 Apparently, those HOST_PYTHON... lines are not needed. Apr 04 18:28:00 OK. I just did a make clean Apr 04 18:28:12 But I will do a make dirclean Apr 04 18:28:24 And I have an ipk file now!!!! Apr 04 18:31:50 I tried make package/python-nacl/dirclean Apr 04 18:31:55 That does not work Apr 04 18:33:00 make dirclean by itself. It will remove your toolchain and everything else, but not your config. Apr 04 18:33:11 OK. So that's a long build then Apr 04 18:33:16 Got it Apr 04 18:34:50 I forgot to thank that masked man... Apr 04 19:46:45 Goodevening Apr 04 19:49:29 Trying to get linux/openwrt on my bcm3380 i built a kernel, however it panics quite fast with a failing to allocate memory Apr 04 19:49:53 When i check, memblock_alloc() always returns zero Apr 04 19:50:23 Hauke: do you know anything about different versions of the lantiq GPHY firmware files? Apr 04 19:51:18 But i defined memory in the devicetree (0x80000000-84000000) and it shows up during boot as identied memory Apr 04 19:51:39 Do i miss something (bcm3380 is bmips4350) Apr 04 19:54:09 Hauke: wow, thanks for looking at STACKPROTECTOR Apr 04 20:07:10 DonkeyHotei: the more recent versions of the gphy FW fix some bugs, I do not know the changelog Apr 04 20:07:55 this is probably related to layer 1 etherent problems Apr 04 20:27:56 Hauke: i've put the gphy files from the most recent dm200 gpl tarball, renamed for the mainline kernel, on pastebin for now: https://pastebin.com/9qAp0NcG Apr 04 20:29:32 Hauke: if they fix bugs, it would be good to replace the ones in openwrt Apr 04 20:31:51 mamarley, did you get a chance to try the latest ath10k-ct stuff? Apr 04 20:32:27 greearb_: I did, the 4.19 build with the latest FW now works fine, thanks! Did you look at the stacktrace I sent you from 4.20 yesterday? Apr 04 20:32:51 mamarley, please re-send Apr 04 20:33:21 greearb_: https://paste.ubuntu.com/p/bh5GCqxmtW/ Apr 04 20:33:46 (For reference, it behaves the same way with and without the patches OpenWRT applies, so I don't think that is the problem.) Apr 04 20:34:22 (And it says 4.19 in the log, but that's because the code still says 4.19, it really is the 4.20 driver.) Apr 04 20:34:51 mamarley, please email me a snippet of around that wirless/core.c:627 splat from your backports Apr 04 20:35:29 OK, just a sec. Apr 04 20:36:22 greearb_: Do you mean the mac80211 code? Apr 04 20:36:51 yes, that is where the splat comes from Apr 04 20:37:26 something must have changed in 5.x that is not compatible with (my) 4.20 code Apr 04 20:39:07 greearb_: Emailed. Apr 04 20:42:49 mamarley, comment out this code, I think it is broken: if (WARN_ON(types & BIT(NL80211_IFTYPE_ADHOC) && Apr 04 20:42:50 c->beacon_int_min_gcd)) { Apr 04 20:42:50 return -EINVAL; Apr 04 20:42:50 } Apr 04 20:43:57 greearb_: OK, I will try that. Apr 04 20:45:47 I just re-sent email to linux-wireless about that...I had hit it earlier when I started using 4.20 Apr 04 20:54:28 greearb_: That seems to have worked, thanks! Apr 04 20:58:23 One of these days I'm going to wear out the poor flash chip on my router by flashing it so much… Apr 04 21:09:35 ping KanjiMonster Apr 04 21:10:36 cotequeiroz: pong Apr 04 21:11:21 I'm looking at some linking problems in znc, with the i386-pentium. It is related to -nodefaultlibs option to gcc. Apr 04 21:13:35 I'm not sure what other platforms it affects, but removing -nodefaultlibs fixes the problem for i386, while increasing package size for everyone else. Apr 04 21:14:58 What do you think would be the best way to deal with it? Remove the flag for everyone, or hunt down the platforms and make an exception for them? Apr 04 21:16:46 * karlp cant' tthink of a world where "increasing package size for everyone" is even considered a solution :) Apr 04 21:17:41 depends on the size increase. can you give any numbers? Apr 04 21:18:48 karlp: znc isn't exactly lightweight, anyone running it will likely have enough space ;) Apr 04 21:20:29 Let me rebuild it. I had them saved, but I guess I overwrote them while testing. The size is what made me ask. Exceptions are not always good to maintain. Apr 04 21:21:58 KanjiMonster: "everyone else" meaning all other platforms because it's a gcc option? Apr 04 21:22:14 and everyone who's not running znc? unless cotequeiroz meant somethign altogether not what they said :) Apr 04 21:22:44 I mean all other platforms where this is not failing. This package only, not a global gcc option. Apr 04 21:23:09 32bit x86 is the only platform where it fails Apr 04 21:23:58 that's how I understood it Apr 04 21:26:06 ppc also fails. I haven't look at every one of them. Apr 04 21:27:52 And anything using glibc, I imagine from previous experiences with linking without defaultlibs. Apr 04 21:37:08 cotequeiroz: might be a remnant from when it still linked against uclibc++, so probably can be just removed - other users of this flag only set it conditionally when compiling against uclibc++ (probably to prevent stdlibc++ to be picked up/preferred) Apr 04 21:40:50 Got the sizes on ramips (mipsel_74kc). All ipks combined, using du -sc: with -nostdlibs: 2352; without -nostdlibs: 2368 Apr 04 21:41:14 And it links with -lstdc++, btw Apr 04 21:45:08 Something's come up. I got to go, but unless you tell me otherwise, I'll make this simple and remove the linking hacks. Apr 04 22:02:52 cotequeiroz: that's not even a percent in in size increase, so go ahead Apr 04 23:25:24 KanjiMonster: i finally got a dts working for brcmnand, based on the example from linux-4.14.107/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt. would you mind sanity checking my dts to see if anything looks weird? https://pastebin.com/vsd1U08b Apr 04 23:27:23 jow: was just looking at that PR. Not sure about some of the dependencies, GRUB_BAUDRATE depending on EFI_IMAGES. Apr 05 00:23:29 what will the next release be called? Apr 05 00:25:26 cotequeiroz: -nodefaultlibs is indeed a uclibc++ thing. see: https://github.com/openwrt/packages/blob/master/utils/smartmontools/Makefile#L71 Apr 05 00:25:47 it allows a slightly smaller size. Apr 05 00:27:00 znc cannot be build with uclibc++. Maybe it used to be/ Apr 05 00:41:49 it's safe to assume 19..0, no codename Apr 05 00:44:42 email archive says 19.03 Apr 05 00:46:20 yes, given that it hasn't branched off master yet, it would be more likely to become 19.04.0 (or 19.05.0) though **** ENDING LOGGING AT Fri Apr 05 02:59:57 2019