**** BEGIN LOGGING AT Fri Feb 19 02:59:57 2021 Feb 19 02:59:58 so that's what we wanted right? Feb 19 03:00:29 I think that's code 1 from make though, not the diff logic below Feb 19 03:00:40 I would have liked to see "Dirty patches detected, please refresh and review the diff" Feb 19 03:02:16 I see Feb 19 03:02:17 it's not too clear why make failed though.... Maybe the error just didn't get echoed for some reason? Feb 19 03:02:22 does it need to go to stderr? Feb 19 03:02:41 please create a PR on packages.git so you can test it without me refreshing okay? Feb 19 03:02:59 okay, just point it to my repo? Feb 19 03:03:03 like you did? Feb 19 03:03:05 yes Feb 19 03:03:20 okay I'll play with it Feb 19 03:03:25 thank you Feb 19 03:04:56 lipnitsk: if you feel fancy please look into https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#grouping-log-lines to separate the different check outputs Feb 19 03:12:16 aparcar[m]: what issues? Feb 19 03:18:39 mangix: you said there are issues :) Feb 19 03:19:22 https://downloads.openwrt.org/snapshots/faillogs/mips64_octeonplus/packages/gnunet/compile.txt https://downloads.openwrt.org/snapshots/faillogs/mips64_octeonplus/packages/mc/compile.txt as examples Feb 19 03:19:29 my patch fixes those Feb 19 03:20:20 git grep FIXUP | grep gett in the packages feed to see more Feb 19 03:24:42 build #761 of malta/be is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/malta%2Fbe/builds/761 blamelist: ?lvaro Fern?ndez Rojas , Felix Fietkau , Daniel Golle , John Audia Feb 19 04:06:30 aparcar[m]: I think the fail is because of -e bash option in entrypoint.sh: Feb 19 04:06:31 -e Exit immediately if a command exits with a non-zero status. Feb 19 04:06:53 so when the git check fails it exits right away without going inside the if $? Feb 19 04:07:46 so really the "|| exit $?" clauses in the script are also redundant Feb 19 04:34:08 aparcar[m]: https://github.com/openwrt/gh-action-sdk/pull/3 Feb 19 04:34:22 figured it out. mostly cosmetic, but it would be nice to print out that error. Feb 19 04:34:49 some bash voodoo. Feb 19 04:52:11 lipnitsk: funny. shellcheck warns on this Feb 19 04:52:21 haha Feb 19 04:52:32 well I can come up with some other way Feb 19 04:52:52 no i mean it warns on if [ $? -ne 0 ]; then Feb 19 04:53:05 oh, so the new thing is good? Feb 19 04:53:14 yeah Feb 19 04:53:53 what is this shellcheck? standard tool or openwrt homebrew? Feb 19 04:54:09 sudo apt install shellcheck Feb 19 04:54:27 yeah, SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?. Feb 19 04:54:47 https://github.com/koalaman/shellcheck/wiki/SC2181 Feb 19 04:55:09 cool Feb 19 04:55:15 i should use the if ! make mytarget; form though Feb 19 04:56:02 haha it even mentions what you said in your PR Feb 19 04:56:03 Scripts that run or are called with set -e aka errexit will exit immediately if the command fails, even though they're followed by a clause that handles failure. Feb 19 04:59:49 yeah too bad google didn't lead me straight to that page... Feb 19 05:00:31 third result on duckduckgo Feb 19 05:01:20 query? Feb 19 05:01:26 SC2181 Feb 19 05:01:27 maybe I just suck at searching Feb 19 05:01:39 well yeah, I didn't just know to search for SC2181 :) Feb 19 05:01:48 I'll just have to get in a habit of running shellcheck Feb 19 05:02:47 notice how there's a disable directive in that file :) Feb 19 05:03:28 there used to be a shellcheck thing for the CI, but it was removed because of it being too noisy Feb 19 05:06:27 I see.. Yeah that's the issue with static analysis - false positives. But still I should use it more often, if only manually Feb 19 05:09:44 basically, the issue is that busybox ash has capabilities in between debian ash and bash. The solution IIRC would be to check against ash and selectively disable warnings Feb 19 05:10:01 the last part is a problem, except in shellcheck master Feb 19 05:10:17 been a while since i looked into it Feb 19 05:11:11 oh this is even better: https://github.com/koalaman/shellcheck/pull/2139 Feb 19 05:12:21 actually nvm... that's just a detection commit Feb 19 06:23:49 build #793 of apm821xx/sata is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fsata/builds/793 Feb 19 07:21:18 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 98.1% packages reproducible in our current test framework.) Feb 19 07:42:57 build #652 of layerscape/armv7 is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/652 blamelist: ?lvaro Fern?ndez Rojas , Felix Fietkau , Daniel Golle , John Audia Feb 19 07:56:04 build #4 of apm821xx/sata is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/apm821xx%2Fsata/builds/4 Feb 19 08:47:54 build #769 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mvebu%2Fcortexa53/builds/769 Feb 19 09:20:48 is there a 21.02 imagebuilder available for quick generation of images or should one still use snapshots for that ? Feb 19 09:23:17 ugh Feb 19 09:23:25 finally rebuilt my NAS Feb 19 09:23:42 surprisingly easier than i though Feb 19 09:23:43 t Feb 19 09:24:27 <_uwu_> https://bugs.openwrt.org/index.php?do=details&task_id=3034&string=openssl Feb 19 09:24:42 <_uwu_> well this is really broken Feb 19 09:26:00 plntyk: i see imagebuilder tarballs in the 21.02 snapshot subdirs? Feb 19 09:26:39 protip: keep /var/lib/docker separate to OS storage Feb 19 09:30:29 can u post the link ? i cannot seem to find it - someone mentioned its not "public" Feb 19 09:30:51 plntyk: oh. it's not published on the downloads page, no. sec. Feb 19 09:30:59 https://downloads.openwrt.org/releases/21.02-SNAPSHOT/ Feb 19 09:31:15 thank u Feb 19 09:31:18 yw Feb 19 09:31:57 wanting to test wpa3 issue with snapshot in case its a "real" problem before release Feb 19 09:34:41 :) Feb 19 09:42:33 hm... seems I have to wait a little bit since packages for ath79/mips_24kc arent done yet Feb 19 09:43:18 ah still broken ABI changes on buildbot Feb 19 09:43:21 "Packages for kmod-cfg80211 found, but incompatible with the architectures configured" Feb 19 10:13:07 build #4 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mvebu%2Fcortexa53/builds/4 Feb 19 10:15:07 build #834 of oxnas/ox820 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/834 Feb 19 10:47:55 Hauke: ping Feb 19 11:19:56 build #4 of gemini/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/gemini%2Fgeneric/builds/4 Feb 19 13:06:38 if you didn't back Solo V2 already, now's the time: https://www.kickstarter.com/projects/conorpatrick/solo-v2-safety-net-against-phishing/posts/3098893 Feb 19 13:16:00 guys i'm trying to migrate a device from ar71xx to ath79, is this the correct approach? https://paste.debian.net/plain/1186093 Feb 19 13:16:13 ar71xx mach file has 1 and 0, i suppose eeprom matches what's defined as art Feb 19 13:17:02 Borromini: no, the number in DTS should be offset (number of bytes) from the start of partition Feb 19 13:17:19 Borromini: I suggest you take a look at hexdump -C of the art partition to see those MACs. Feb 19 13:17:30 PaulFertser: ah ok (i don't have that device myself) Feb 19 13:17:48 Borromini: probably you just need 6 instead of 1 there. Worth checking hexdump. Feb 19 13:18:14 PaulFertser: will ask the owner if he can get me a dump Feb 19 13:18:47 thanks for the advice Feb 19 13:24:30 rsalvaterra: pong Feb 19 13:27:46 Hauke: I'm taking a stab at porting 5.10 to mvebu, will also backport the buffer management patch, while it doesn't hit linux-stable. Feb 19 13:30:00 I don't have arm64 hardware to test, though, only my Omnia. Feb 19 13:30:49 Hauke: my R6800 needs a driver that got added to the mt7621 kernel config when device support got committed, but got lost with the move to 5.4 it seems Feb 19 13:31:24 ipk is 60k. can i re-enable that driver in the kernel config for mt7621 or do i need to make a separate package and have the device profile depend on that? Feb 19 13:31:26 rsalvaterra: I have a mvebu a53 board here Feb 19 13:32:00 rsalvaterra: I was just asking about the stability becasue I think hw buffer managers are compliacted Feb 19 13:32:11 at least I have experience with it from a different SoC Feb 19 13:32:14 device commit was this one: https://github.com/openwrt/openwrt/commit/4e9317201d3fb47800b387d69d79c00f38d2dbfd Feb 19 13:32:47 (last file changed, config-4.14) Feb 19 13:32:50 Borromini: what driver is missing? Feb 19 13:33:29 Hauke: CONFIG_PINCTRL_SX150X is the symbol Feb 19 13:33:40 Borromini: if you do not need that driver to boot up, I would prefer to have it as a ipkg Feb 19 13:33:46 generic kconfig has it unset, kirkwood has it enabled e.g. Feb 19 13:33:49 Hauke: ok, thanks Feb 19 13:33:54 Hauke: Sure, but it's rock-solid here. Like I said, they've been working since forever on other Armada 38x/XP devices, only the Omnia got snubbed due to the device tree bug. :) Feb 19 13:34:08 we have many mt7621 devices with small memory Feb 19 13:34:34 Borromini: and if it is only needed on one of them an ipkg would be better Feb 19 13:34:56 rsalvaterra: ok then I am fine with adding it also to 21.02 Feb 19 13:35:03 Hauke: yeah, understand. Feb 19 13:35:09 Hauke: Just to make sure, I'm not stepping on nitroshift's toes, he told me he doesn't have a lot of time to make the the changes adrianschmutzler asked, so I'm taking the liberty to try and do them myself (also as a learning exercise). Feb 19 13:35:39 adrianschmutzler: hi :) can I ask you about okli loader and initramfs images? I have an impression this combination is broken, unbootable images are produced. Feb 19 13:36:48 PaulFertser: you may ask, but I probably won't be able to answer anything helpful ;-) Feb 19 13:37:06 Hauke: when do you plan to commit rt3200? :P Feb 19 13:37:14 I just got the package from amazon Feb 19 13:37:44 ynezz: I haven#t booted it yet, plan to have a look at it at the weekend Feb 19 13:38:05 I have some other mt7622 device here for over a year, that should also be added Feb 19 13:38:14 :) Feb 19 13:38:39 I just probably wont have time to tackle it myself in next 2-3 weeks, but would like to include it into testbed Feb 19 13:38:40 adrianschmutzler: okli loader's idea is that it's a small ELF and then it finds the kernel somewhere on its own, do I get it right? Feb 19 13:39:12 rsalvaterra: I will have a look at this in the next days Feb 19 13:39:13 adrianschmutzler: when using initramfs images okli loader is loaded to the desired location but the kernel itself stays where it was loaded, so I can't see how it can work. Feb 19 13:40:24 Hauke: Wait, mvebu? Feb 19 13:43:17 Hauke: I'm now going through the patches, deleting the already upstreamed ones. Feb 19 13:44:38 PaulFertser: okli is not intended to be used with the initramfs images Feb 19 13:44:57 blocktrron: but currently they end up like that afaict. Feb 19 13:45:21 blocktrron: so either the generation should be disabled or fixed Feb 19 13:45:33 Do they? Feb 19 13:45:50 The Siemens WS-AP3610 for example utilizes okli only for the regular kernel Feb 19 13:46:15 When you simply reuse the kernel build-receipt and not provide a seperate one for the initramfs, they might Feb 19 13:46:26 blocktrron: I looked at https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_cpe220-v2-initramfs-kernel.bin as one of the users had issues with that Feb 19 13:46:35 Eww, that CPE mess Feb 19 13:47:34 afair, we could skip that whole OKLI for initramfs and provide an ELF kernel, as okli is used there for backwards compatibility Feb 19 13:48:30 blocktrron: I do not have a compatible device for proper testing so I'm reluctant to try to offer a patch. Feb 19 13:49:33 We have a shitpile of CPE somewhere. Their only purpose is to threaten people to gift them multiple ones. Feb 19 13:49:54 and normally initramfs is not used for these anyway? Feb 19 13:50:14 so I never actually cared whether it does something useful there ... Feb 19 13:50:32 you can use them from the bootloader CLI apperently Feb 19 13:51:04 adrianschmutzler: normally initramfs is not used at all. But comes rather handy for recovery and experimentation. Feb 19 13:51:27 Then wait until somebody cares enough to fix it. Case closed? Feb 19 13:51:51 PaulFertser: so, you essentially stumbled over the fact that initramfs can only be enabled per target Feb 19 13:52:04 so, most ath79 devices have one, although it's only needed for a few Feb 19 13:52:09 most->all Feb 19 13:52:29 and from all those not needing it, quite a few are probably broken Feb 19 13:52:34 adrianschmutzler: I'd say it's needed for most of the targets, as it's rather handy for flashing from bootloader. Feb 19 13:52:37 as blocktrron says Feb 19 13:53:33 I don't doubt that, but still probably nobody cared to have it working properly on many ath79 devices Feb 19 13:54:04 BTW that whole initramfs part need more love anyway Feb 19 13:54:26 aparcar[m]: is there anything new about this patch https://patchwork.ozlabs.org/project/openwrt/patch/20210110202539.1047929-2-mail@aparcar.org/ ? :) Feb 19 13:54:37 I think a generic clean-up where all okli image generation is inspected and initramfs handled specifically might be worth a shot. It's just that I do not have a single device for testing. Feb 19 13:54:37 one could only enable it per target, so issues like this don't happen Feb 19 13:55:02 one could make the packages it uses configurable, so we don't have to stuff everything into DEFAULT_PACKAGES ... Feb 19 13:55:24 so we would have different content in different images? Feb 19 13:55:38 regarding okli, the problem is that there are not so many people really understanding it Feb 19 13:56:06 ynezz: ideally, so we do not have to stuff all packages from individual devices into default packages Feb 19 13:56:19 that's only a stupid idea without having looked to much, though Feb 19 13:56:41 so why it's being now done for squashfs images? Feb 19 13:56:57 why are you trying to treat it differently? Feb 19 13:57:08 I want to treat it like squashfs images Feb 19 13:57:19 so, every device only gets the packages it needs Feb 19 13:57:38 initramfs images and their cpio are built by the kernel Feb 19 13:58:10 I know Feb 19 13:58:19 so you have to go through that process for each device Feb 19 13:58:39 I just don't get it, that we now have initramfs images which are working differently then other images Feb 19 13:59:12 alternatively you could hack something to append a device-specific ramdisk. Or simply provide the ramdisk to the kernel using FIT / bootm parameters. Feb 19 13:59:24 not every bootloader supports fit Feb 19 13:59:45 i'm aware of that Feb 19 14:01:05 so, either we drop device-specific packages, or we do a lot of additional build steps for each device? Feb 19 14:01:22 (if we want to have squashfs and initramfs the same) Feb 19 14:01:32 great Feb 19 14:01:39 this is no go for backports Feb 19 14:02:05 we might come with something better for next release, but it would be nice to have something for 21.02 and 19.07 Feb 19 14:02:30 at least for devices/targets where people care and actually use/test the initramfs images Feb 19 14:03:51 the alternative would be to have two categories for device packages: Feb 19 14:03:55 https://git.openwrt.org/7a629ef6b502038c9ffd6da2c90d3e9a3a609d93 Feb 19 14:03:58 1. needed and 2. "really needed" Feb 19 14:04:19 "needed" would go into DEVICE_PACKAGES and "really needed" would go into "DEFAULT_PACKAGES" Feb 19 14:04:28 this is my current WIP initramfs fix for mvebu Feb 19 14:05:07 hell I don't probably care about 19.07 anymore, but I would come up with something which would be accepted in 21.02 Feb 19 14:06:20 Additionally, removing packages in DEVICE_PACKAGES makes "make menuconfig" more ugly to use Feb 19 14:06:58 well, that's how it works currently and it's being (ab)used Feb 19 14:07:22 PaulFertser: would you mind taking a peek? Feb 19 14:07:24 ynezz: But apart from this academic discussion, your patch is probably the only way for 21.02 that would actually solve the problem Feb 19 14:07:30 i think this is the line: 00001000 00 22 3f 0d 06 12 00 22 3f 0d 06 13 35 31 33 36 Feb 19 14:07:42 https://paste.debian.net/plain/1186098 Feb 19 14:08:32 Borromini: netgear? Feb 19 14:08:35 PaulFertser: yeah Feb 19 14:08:39 wnr2000 v1 Feb 19 14:08:58 ynezz: though I don't really see why we need wifi packages in initramfs Feb 19 14:09:00 Borromini: so 0x1000 and 0x1006 looks correct Feb 19 14:09:05 0-1-2-3-4-5 are mac 1 so offset 6 like you said for mac 2 probably? Feb 19 14:09:06 ok Feb 19 14:09:09 thanks Feb 19 14:09:14 adrianschmutzler: why you need them in squashfs? for wifi? Feb 19 14:09:57 yes, but isn't the initramfs just an intermediate step until I get the "proper" image? Feb 19 14:10:05 so no need to set up wifi there? Feb 19 14:10:08 that's your understanding Feb 19 14:10:58 maybe it should be renamed to initramfs-install-only Feb 19 14:11:21 if not, why do you pick only wifi packages here and not all the others? Feb 19 14:11:47 for example? Feb 19 14:12:01 who can point me to the flashing instructions for realtek devices? Feb 19 14:12:24 stintel: usually commit message for that device Feb 19 14:12:25 so you really aim at eventually have all packages in initramfs? Feb 19 14:13:12 adrianschmutzler: just want to have similar functionality as provided by the squashfs image Feb 19 14:13:18 ynezz: indeed, I just found it, sorry for being lazy =) Feb 19 14:13:52 funny how everybody hates realtek but now we all want it because we can run OpenWrt on a switch :D Feb 19 14:13:56 cause we have size constraints on many initramfs images already, and making them much larger won't really be a help here Feb 19 14:14:31 (don't know whether that applies to mvebu/cortexa9 in particular, though) Feb 19 14:14:47 stintel: Running OpenWrt on a switch qualifies as "awesome" in my book. :P Feb 19 14:14:58 aye Feb 19 14:15:09 I had a go at the Unifi Switch 8 at some point Feb 19 14:15:26 but I think I broke the device by shorting one of the TTL pins with the chassis Feb 19 14:15:35 * rsalvaterra still hasn't given up on his TL-SG2008 v1.0… Feb 19 14:15:56 adrianschmutzler: yeah, then there is luci... Feb 19 14:16:40 stintel: an unintended irony on their part I think :P Feb 19 14:17:04 also at some point I think I read that some cisco switches are mvebu based Feb 19 14:17:20 adrianschmutzler: anyway, I won't be touching those corner cases where you actually need smallest initramfs image in order to flash openwrt Feb 19 14:17:21 SG250-08-K9-EU IIRC Feb 19 14:17:40 but I bought way too much hardware recently that I still have to get working with OpenWrt Feb 19 14:18:06 + commit upstream :P Feb 19 14:18:13 stintel: But Cisco stuff is usually filled up with custom undocumented accelerator ASICs, no? Feb 19 14:18:31 I have an Odroid C2 running OpenWrt for years but never got to finishing that target properly :( Feb 19 14:19:22 adrianschmutzler: maybe I'll just as well leave that initramfs hell and simply lower the number of tests from daily to weekly and use squashfs images and flash them Feb 19 14:19:27 and now I have a TP-Link OC200 that is a bitch because it requires TTL header + level shifter + 4 bridges to be soldered on the PCB to get serial, the SPI NOR chip is 1.8v, this is how I killed my first OC200 by reading it with a 3.3v programmer :P Feb 19 14:19:51 (it requires either serial or overwriting the RSA pubkey in the SPI NOR flash to be able to flash OpenWrt) Feb 19 14:20:34 adrianschmutzler: I wanted to use imagebuilder first to build proper initramfs images (don't know if that's even possible), but then rejected the idea as it won't be pristine image from downloads.openwrt.org Feb 19 14:20:40 well, with the current constraints I must say that having initramfs-install-only as you said seems the least-painful to me Feb 19 14:21:03 and then there's the WatchGuard Firebox M200 and M300 that I managed to boot after hacking asm vector instructions out of musl, but unable to get the network interfaces to work :( Feb 19 14:21:32 and the Huawei AP7060DN Feb 19 14:21:32 if it is any help, I'm really unsatisfied with the current situation as well Feb 19 14:21:43 for now I'm done buying unsupported hardware and trying to get it to work :P Feb 19 14:21:50 I'm clearly too dumb for this Feb 19 14:22:17 have you asked for SDK/sources? this might help a lot Feb 19 14:22:36 without this info it's quite tedious task I would say Feb 19 14:23:47 PaulFertser: is there a way to say if that ART dump contains caldata and where it starts? I'm looking at other AR9132 DTSes and they all refer to caldata in the ART partition at 0x1000 Feb 19 14:32:55 Borromini: I think https://github.com/pepe2k/ar9300_eeprom/tree/master/art (and the tool itself) can help, but I do not know direct answer. Feb 19 14:34:01 Borromini: I'd try giving the same art offset as the other similar devices do Feb 19 14:35:30 Borromini: I'd just give it a try booting with caldata supposed to be at 0x1000 from art start Feb 19 14:35:48 PaulFertser: okay, thank you Feb 19 14:42:09 Borromini: from wnr2000.c machine file in ar71xx: u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff1000); It means the last sector of flash, 0x1000 offset. Feb 19 14:43:49 build #241 of lantiq/xway is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxway/builds/241 Feb 19 14:44:10 PaulFertser: ok, so your hunch was right, thanks. Feb 19 14:44:42 saw that in other ar9132 mach files as well but wasn't sure that matched Feb 19 15:48:35 build #238 of armvirt/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F64/builds/238 Feb 19 16:11:01 oh, I need serial to flash the GS108Tv3 Feb 19 16:12:56 I lost the count of the number of times I've been staring at a make failure, only to realise I wrote "make donwload"… Feb 19 16:18:19 adrianschmutzler: Building an image with 5.10 for my Omnia, hopefully I haven't screwed up anything (my patch refresh ended up a bit different from nitroshift's). Feb 19 16:18:47 stintel: you shouldn't need serial to flash that switch Feb 19 16:19:21 stintel: from OEM GUI you need to flash the initramfs, then re-flash a sysupgrade from OpenWrt Feb 19 16:19:37 svanheule: but OEM GUI requires a cloud account Feb 19 16:19:39 ain't going to happen Feb 19 16:19:59 you can disable that, by preventing the switch from pinging 8.8.8.8 Feb 19 16:20:06 aha Feb 19 16:20:31 if the switch thinks it doesn't have internet, you can log in with the local account :-) Feb 19 16:21:03 rsalvaterra: and that's why separate patches help a lot, because then you can actually see the different refresh directly Feb 19 16:21:25 svanheule: good to know, tyvm Feb 19 16:21:33 stintel: yw Feb 19 16:21:34 * Borromini makes mental note as well Feb 19 16:21:40 too bad it's not in the commit message :P Feb 19 16:21:42 but the thing is opened up already anyway and the soldering iron is hot :P Feb 19 16:22:21 and good to have masks at hand these days, those fumes are nasty :P Feb 19 16:22:35 my air purifier and pm sensors go mad whenever I'm soldering Feb 19 16:22:44 :P Feb 19 16:23:23 adrianschmutzler: I basically followed your process for bcm63xx. :) Feb 19 16:24:50 Kernel config -> patch copy -> patch refresh -> patch backport (just a single one) -> kernel testing version. This is basically the patch series. Feb 19 16:25:13 I'll remember that 8.8.8.8 trick for my next one :P Feb 19 16:25:23 I should actually just have ordered 2 at once Feb 19 16:25:33 so I don't need to yolo sysupgrade on production switch :P Feb 19 16:26:42 :P :P Feb 19 16:34:45 hmmm maybe I should build an image first :P Feb 19 16:35:57 ynezz: ping Feb 19 16:37:25 ynezz: stintel and I are looking into some issues with bcm2708 and urngd, and we could definitely use some help... Feb 19 16:39:01 mangix: ping Feb 19 16:39:08 we don't know why, but it takes a very long time for bcm2708 (bcm2835) devices to get to "random: crng init done", which doesn't make any sense, since there's a hw random generator Feb 19 16:40:58 as you can see in: https://gist.github.com/Noltari/226e5604bc0916138330e1faa16ef53f if both "return JENT_ECOARSETIME" are removed from jitterentropy-basec.c in urngd, this speeds up the process from 102s to 12s Feb 19 16:41:11 stintel: priorities huh :P Feb 19 16:41:44 it's weird that it's returning "urngd: jent-rng init failed, err: 2" only on bcm2835 devices... Feb 19 16:46:02 Hm, wireguard failed to build… Feb 19 16:46:15 * rsalvaterra goes digging… Feb 19 16:46:36 rsalvaterra: https://github.com/openwrt/openwrt/pull/3885 Feb 19 16:47:21 Thanks, I was already there. :) Feb 19 16:47:54 128 files changed…? o_O Feb 19 16:51:43 haha, it's the wireguard patches Feb 19 16:52:03 it failed for you? Feb 19 16:52:21 build #239 of brcm47xx/legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm47xx%2Flegacy/builds/239 Feb 19 16:52:49 lipnitsk: I haven't merged them here. I'm porting 5.10 to mvebu, and just noticed wireguard failed to build. :P Feb 19 16:52:59 oh yeah, welcome to the show :) Feb 19 16:53:14 I'll just disable WireGuard for the time being… :P Feb 19 16:53:23 it's actually really easy on 5.10, 5.4 is hairy Feb 19 16:53:34 but yes, probably smart to wait and see how it plays out Feb 19 16:54:10 I see zx2c4 himself is on the case too, so I'm not too worried. :) Feb 19 17:00:31 Borromini: yeah and at the same time I'm posting a feature request for home-assistant :P Feb 19 17:06:31 :P Feb 19 17:07:36 ow Feb 19 17:08:05 having a switch with OpenWrt could solve my multicast between different VLANs problem Feb 19 17:08:14 * stintel gets even more excited Feb 19 17:08:20 :) Feb 19 17:08:41 * stintel puts on a bib 😂 Feb 19 17:12:07 Speaking of which, I think I found out my multicast problem… Feb 19 17:12:18 … it's being routed through the default gateway. *facepalm* Feb 19 17:15:34 damn that's actually epic. no need to have TV or AVR in the same VLAN as my phone e.g. Feb 19 17:20:22 Oh, netsplits are still a thing, I see. :P Feb 19 17:21:07 rsalvaterra: Like that would ever go away with multi-server statefull IM protocol Feb 19 17:21:10 (: Feb 19 17:24:52 <32NAANUI0> Aww, yiss! Feb 19 17:24:55 <32NAANUI0> Linux rocket.lan 5.10.16 #0 SMP Fri Feb 19 15:59:18 2021 armv7l GNU/Linux Feb 19 17:25:27 congratz :P Feb 19 17:26:04 I don't know what the hell happed with my nick. Fixed. :P Feb 19 17:26:35 No kernel stack traces. Sweet! Feb 19 17:27:57 What will it be, ladies and gentlemen? Patch series or pull request? :P Feb 19 17:28:21 patch series Feb 19 17:28:30 build #4 of ath79/mikrotik is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ath79%2Fmikrotik/builds/4 blamelist: ?lvaro Fern?ndez Rojas , John Audia Feb 19 17:29:44 grift: That would be my preference too. Feb 19 17:31:11 speaking of mailing list, the log of the last meeting was promised to be published on ml , but i havent seen it yet? Feb 19 17:32:01 theres some people who werent able to attend but still would like a taste of what waas discussed Feb 19 17:49:30 build #890 of ipq806x/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq806x%2Fgeneric/builds/890 Feb 19 17:53:11 * stintel thanks everyone involved with the realtek target Feb 19 17:55:23 build #244 of zynq/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/zynq%2Fgeneric/builds/244 Feb 19 17:55:51 grift: https://openwrt.org/meetings/20210212 Feb 19 17:56:37 o it has a dedicated place? nice Feb 19 17:56:42 stintel: i just fired up a gs108t-v3 after seeing the recent support commits Feb 19 17:56:46 i was waiting for it on the ml Feb 19 17:56:54 grift: btw I tried selinux the other day and this looked problematic: [ 30.014461] audit: type=1400 audit(1613448535.993:5): avc: denied { search } for pid=3137 comm="sh" name="libubox" dev="overlay" ino=1552 scontext=u:r:ntpdhotplug.subj tcontext=u:r:libubox.datafile tclass=dir permissive=0 Feb 19 17:56:54 [ 31.128242] audit: type=1400 audit(1613448537.103:6): avc: denied { search } for pid=3138 comm="sh" name="libubox" dev="overlay" ino=1552 scontext=u:r:ntpdhotplug.subj tcontext=u:r:libubox.datafile tclass=dir permissive=0 Feb 19 17:57:21 grift: I'll announce it on the ML lter today Feb 19 17:58:46 aparcar[m]: yes i will add that, but it would help if you could somehow produce that in permissive mode `setenforce 0 ; reporduce issue` Feb 19 17:59:13 because basically selinux blocked the first or a bunch of syscalls, so we only see the first syscall now Feb 19 17:59:32 so it gives a hint but not the full picture Feb 19 17:59:53 build #870 of arc770/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/870 Feb 19 17:59:53 of course i can rely on experience and just recognise patterns but i might be wrong Feb 19 18:00:17 build #868 of pistachio/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/868 Feb 19 18:00:33 ill just add what i think is going on but yes this is why i suggested setting the default mode to permissive for now Feb 19 18:01:21 beause not everyone is confident with selinux and if the default mode is enforcing then i kind of feel bad to ask "can you reproduce the event in permissive mode?" Feb 19 18:01:35 anyhow thanks Feb 19 18:01:41 was that all though? Feb 19 18:02:05 hmmm realtek is pretty verbose on console Feb 19 18:05:36 aparcar[m]: addressed: https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=261012d033921beb9d45fe60d38831f9c5e70c33 Feb 19 18:06:26 build #808 of tegra/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/808 Feb 19 18:09:12 And I'm still being shafted by that damn GPIO IRQ storm on 5.10…! FFS… Feb 19 18:12:14 aparcar[m]: for next time, a way to reproduce something like this is probably: `setenforce 0 && service network restart && setenforce 1 && dmesg | grep -i denied | nc termbin.com 9999` Feb 19 18:14:16 thanks for the log aparcar[m] Feb 19 18:16:03 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 98.2% packages reproducible in our current test framework.) Feb 19 18:35:43 grift: good info thank you Feb 19 18:35:53 Borromini: you're welcome Feb 19 18:36:56 aparcar[m]: is it a summary or is there gonna be an expansion later on? Feb 19 18:36:59 (just curious) Feb 19 18:37:39 it looks very compact and to the point :) Feb 19 18:39:50 grift: i recall you asking for people to test your selinux policy Feb 19 18:40:09 jacekowski: yes pretty please Feb 19 18:40:26 grift: would forkbomb work? Feb 19 18:40:35 no but not because of selinux Feb 19 18:40:45 to prevent forkboms use cgroup Feb 19 18:40:52 maxpids Feb 19 18:41:27 try it out: http://openwrt.defensec.nl:7681 Feb 19 18:41:48 its been open since day one; open root access on my main router Feb 19 18:41:56 affect it and bump me off the internet Feb 19 18:42:05 youll see me timeout on irc if you succeed Feb 19 18:42:18 then you can point and laugh Feb 19 18:44:25 You're not concerned someone would use it to connect to some internal device? Feb 19 18:45:39 Q_ no Feb 19 18:46:49 Q_ theres no network access Feb 19 18:47:05 anyway try it out: http://openwrt.defensec.nl:7681 Feb 19 18:49:34 the only way i know of where you might be able to dos is to saturate the storage/ram Feb 19 18:49:40 and that would be lame Feb 19 18:49:55 need someone with deep internal skills to escape the sandbox Feb 19 18:51:29 could even limit the storage and ram with cgroups too to avoid that? Feb 19 18:51:57 linux 5.4 seems to not support cgroup mem on this device Feb 19 18:52:04 o_O Feb 19 18:52:16 "seems" Feb 19 18:53:27 it prints some "error" but the memory container is still there Feb 19 18:54:03 so not sure whats going on there but i suspect its just some linux 5.4 cgroup loose end Feb 19 18:55:08 s/container/controller/ Feb 19 18:56:07 anyone else seeing CI/CD failures for x86_64 *only*? Feb 19 18:56:17 point is that selinux is access control and cgroup is resource control Feb 19 18:58:32 build #248 of bcm53xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/bcm53xx%2Fgeneric/builds/248 Feb 19 18:58:56 build #762 of malta/be is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/malta%2Fbe/builds/762 Feb 19 19:01:25 anyways friday's night is a great time to play Feb 19 19:02:17 crack it, i promise i will appeciative Feb 19 19:02:44 I can't figure out what the failure was here: https://github.com/openwrt/packages/pull/14711/checks?check_run_id=1933481177 Feb 19 19:12:27 guys i have added a kernel module package, it's showing in openwrt's menuconfig but the package is empty... Do i need to do anything extra (sometimes touching Makefiles helps) before it works? Feb 19 19:12:31 https://paste.debian.net/plain/1186147 Feb 19 19:12:47 it's basically replicating other entries and paths are correct Feb 19 19:18:24 Borromini: rm -rf tmp/ Feb 19 19:18:58 stintel: ok thanks Feb 19 19:19:05 what's the correct way to call a kmod build? Feb 19 19:19:27 make package/mt76 e.g. works for mt76 but make/gpio-sx150x doesn't Feb 19 19:19:30 good question, can't answer that Feb 19 19:19:35 ok Feb 19 19:19:58 not on the wiki page either (which is pretty complete) Feb 19 19:21:37 package/kernel/<> i think Feb 19 19:22:03 philipp64: 2021-02-19T08:19:37.4123107Z /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.4.0/../../../../x86_64-openwrt-linux-musl/bin/ld: /home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libgmp.a(bdiv_q_1.o): relocation R_X86_64_PC32 against symbol `__gmp_binvert_limb_table' can not be used when making a shared object; recompile Feb 19 19:22:09 with -fPIC Feb 19 19:22:10 https://pipelines.actions.githubusercontent.com/5yKFRfuu84LeYF9JWXeroTFD7H8ygjTZsUcmjLvv85kJt4ah0c/_apis/pipelines/1/runs/3346/signedlogcontent/11?urlExpires=2021-02-19T19%3A22%3A31.4483779Z&urlSigningMethod=HMACV1&urlSignature=g2scibRBYgNdfcs4l8462z8g0fOo90HKRnmBSnfs2dU%3D Feb 19 19:23:15 plntyk: i'll give that another shot but didn't seem to work Feb 19 19:23:40 ah looks like that thing can't be compiled as a module. Feb 19 19:23:47 either y or N Feb 19 19:24:21 that explains it since per_device_rootfs sets it to m Feb 19 19:30:14 grift: it was me, couldn't resist temptation to see it ,while I know I prolly couldn't do anything, and it's friday evening... alt-f4 obviously made it go away, with the makeshift matrix-IM fullscreen browser I'm using this chat xD Feb 19 19:30:34 no problem Feb 19 19:30:42 dont let me intimidate you Feb 19 19:30:49