**** BEGIN LOGGING AT Tue Nov 12 02:59:57 2019 Nov 12 04:16:53 ynezz: thank you for the docker fixup earlier. do you think we shouldn't use latest in the future? Nov 12 04:26:46 zorun: ping Nov 12 04:56:39 yanosz: and how does one extract it from that image? Nov 12 07:04:00 well, that was weird. build for rb493g was not getting updated with a changed files overlay. /me looks at files overlay. /me looks at flashed image. *squints* looks at files overlay again. blew away build_dir/target-$foo and building again. Nov 12 07:32:30 DonkeyHotel: https://forum.openwrt.org/t/howto-updating-the-lantiq-xrx200-devices-with-latest-dsl-vectoring-firmware/18853 Nov 12 07:33:03 mind, that there' different models (ADSL, VDSL). The 7312 is VDSL, only. I'm not an expert in different lantiq-chips, though Nov 12 07:33:10 sorry, ADSL only Nov 12 07:42:24 morning Nov 12 08:08:38 blogic: hello Nov 12 09:45:26 aparcar[m]: pong Nov 12 10:29:04 is https://github.com/openwrt/luci/wiki/DevelopmentEnvironmentHowTo up-to-date and the best way to develop on LuCI? Nov 12 10:35:42 personally I prefer to nfs mount my laptop and then symlink things, so I don't have to do the whole "copy things back" Nov 12 10:35:45 https://zerobin.net/?b250ccd2eb32bd8a#pnU0m+NMxFb22qY9i6nw3V4FZZliIPXcfpwn5GxwyZE= Nov 12 10:36:26 unfortauntely because of the structures of the inside pieces, you can't just symlink whole directories.... Nov 12 10:36:46 karlp: ok, thanks Nov 12 10:37:07 do you run a NFS server on the openwrt dev box, or the reverse? (NFS client on the openwrt box) Nov 12 10:37:19 nfs client on the openwrt box Nov 12 10:37:31 ok Nov 12 10:37:48 so that I can use my "nice" editors locally, and have that in my git repos locally automatically Nov 12 10:38:19 the openwrt just mounts my laptop and links crap. Nov 12 10:38:31 the notes on that wiki page about turning off caching are useufl though :) Nov 12 10:44:04 I usually use sshfs to mount the openwrt rootfs Nov 12 10:44:19 that does require copying things back and forth though Nov 12 10:44:49 I usually copy changed files to target over ssh after vim save Nov 12 10:47:00 but using NFS as well sometimes, heading towards Docker with volume mounted sources one day Nov 12 10:51:42 that sshfs is interesting, never thought about this option Nov 12 10:56:27 ynezz: way simpler than nfs Nov 12 10:56:50 you just need openssh-sftp-server which is tiny Nov 12 10:56:58 and has no kernel deps Nov 12 11:13:16 the "requires copying files back and forth" is a fiarly major downside IMO :) Nov 12 11:19:49 * karlp just ran into this again: https://github.com/openwrt/odhcpd/issues/60 Nov 12 11:25:55 wouldn't it be possible to have a "make" target that copies files to the right place? Nov 12 11:26:27 using an existing mountpoint (NFS, SSHFS, docker volume) Nov 12 11:29:16 zorun: I've following http://paste.ubuntu.com/p/yRqM86Y6GD/ Nov 12 11:30:39 for "copy all changed files" after pressing CTRL+A in vim Nov 12 11:31:38 ynezz: that's ok if you are working on a files/ type overlay directory Nov 12 11:31:56 but for luci apps with each app having their own luasrc/lualib/www directories that's not going to work too nicely... Nov 12 11:32:53 kinda cute doing it on a vim save hook though :) Nov 12 11:33:36 right, I don't hack on LuCI that much, but I think, that it's going to be another path substition Nov 12 11:34:05 yes, it ends up looking much like the one I pasted, just with scp one way instead of nfs and symlinks. Nov 12 11:37:44 zorun: indeed, something generic enough using QEMU/Docker would be nice and welcome I would guess Nov 12 11:41:37 one "problem" with doing it in qemu/etal is that it's too fast :) Nov 12 11:41:58 you don't see how things really behave on the slow router platforms. Nov 12 11:43:43 use QEMU without KVM on mips Nov 12 11:44:55 cgroups should apply to KVM as well, right? Nov 12 11:47:52 BTW there's ongoing work on making Docker containers accessible in the same way as QEMU VMs are now https://github.com/openwrt/openwrt/pull/2367 Nov 12 11:47:59 (or similar way) Nov 12 11:51:36 now you've just got to rebuild your rootfs.... Nov 12 11:51:42 which is way longer... Nov 12 11:51:59 I mena, that's nice too, sure, but not really for the same purpose as far as I can tell Nov 12 11:54:58 docker has quite usable volumes Nov 12 11:55:34 9p might work for qemu Nov 12 12:07:06 interesting. sysupgrade seems to be broken on mikrotik rb493g (ar71xx-mikrotik nand-large) Nov 12 12:07:39 11479-gb5791118cc Nov 12 12:10:38 http://paste.debian.net/1115880/ Nov 12 12:11:03 kernel and rootfs are unmolested afaict Nov 12 12:15:01 what was last working version? Nov 12 12:16:11 where can I download that sysupgrade image Nov 12 12:16:42 ath79 is missing a factory.bin for unifiac-pro on master. did i break something or is this intentional? Nov 12 12:20:05 apparantly missing since 19 from ar71xx too. its there in 18 Nov 12 12:22:08 ynezz: you talking to me or someone else? Nov 12 12:22:32 russell--: yes Nov 12 12:23:01 seems sysupgrade is writing the kernel to a ubi vol named "none" instead of "kernel" Nov 12 12:23:14 from an initramfs boot Nov 12 12:23:19 missing from the official downloads as well. http://downloads.openwrt.org/releases/19.07.0-rc1/targets/ar71xx/generic/ Nov 12 12:23:24 what happened to ubnt? Nov 12 12:23:27 russell--: ok, so probably unrelated to fwtool changes Nov 12 12:23:31 * russell-- just triangulatng at the moment Nov 12 12:24:46 russell--: I'm just interested to find out, if that image has json metadata, as fwtool reports "no metadata" which might be a possible regression of my last fwtool changes Nov 12 12:26:36 "Image metadata not found" Nov 12 12:29:07 ynezz: how do i tell whether the image has json metadata? Nov 12 12:31:49 strings image.bin | grep metadata_version Nov 12 12:32:14 or tail --bytes 2048 image.bin | strings Nov 12 12:32:47 http://paste.debian.net/1115883/ the sysupgrade.bin is a tarball Nov 12 12:42:10 somehow sysupgrading from an initramfs boot (same openwrt version), kernel gets written to ubi volume "none", but the flashed image looks for a ubi volume with "kernel" during its sysupgrade (in /lib/upgrade/nand.sh) Nov 12 13:20:20 breakage seems to have appeared in the last month Nov 12 13:22:08 an image i built on oct 17 can sysupgrade, and i get a new kernel and rootfs Nov 12 13:22:45 image i built today can't sysupgrade to a different kernel/rootfs except via an initramfs boot Nov 12 13:38:43 as of 11167-g273a6cb562, rb493g was booting the kernel from /dev/mtd5, not one in a volume found in /dev/ubi0 Nov 12 14:10:04 Chaps! I've just been through a horrible lesson in apu2 booting after sysupgrade to latest master. Nov 12 14:11:00 I suspect related to e97113d5e1 & 98d1c7d834 Nov 12 14:11:56 basically after sysupgrade my APU2 couldn't find the squashfs filesystem 'cos grub was looking for a partition UUID of "-2" Nov 12 14:12:15 uh Nov 12 14:12:53 -02? Nov 12 14:12:53 I've bastardised a boot with grub command line "linux /boot/vmlinuz root=/dev/sda2 rootfstype=squashfs rootwait console=tty0 console=ttyS0,115200n8 noinitrd" Nov 12 14:15:00 I flash an image to a usb stick & booted off that... it too couldn't find the root partition. Nov 12 14:15:31 so I reverted the above mentioned commits, rebuilt an image, flashed...and it booted off the stick. Nov 12 14:16:46 sumthing going wrong with the partition UUID signature generation which should be 8(?) hex digits followed by -2 if I read the code right. Nov 12 14:18:24 how/where do you build your images? Nov 12 14:18:32 do you have "mkhash" ? Nov 12 14:18:35 Can anyone else (ahem) reproduce this behaviour or is it me being 'special'? Nov 12 14:19:07 hmm, no mkhash. Mac OS X Nov 12 14:19:11 * mamarley looks sideways at ldir's mac. Nov 12 14:19:19 mkhash is in staging_dir/host/bin Nov 12 14:19:22 I don't have mkhash either, I'm hoping it's a magic builtin somewhere Nov 12 14:19:43 was just about to type 'but don't we build that anyway?' Nov 12 14:19:45 I've just downloaded latest x86 snapshot image Nov 12 14:19:56 and it boots here in QEMU Nov 12 14:20:05 does osx's "head" have the --bytes option? Nov 12 14:20:07 OpenWrt SNAPSHOT, r11477-4ba8f7b1ef Nov 12 14:20:13 head --bytes 8 -> head -c 8 ? Nov 12 14:20:16 mamarley: don't even thing about starting that ;-/ Nov 12 14:20:42 aha - no head --bytes Nov 12 14:20:46 *-> == Nov 12 14:21:05 d'oh :) Nov 12 14:21:09 'head -c' does bytes Nov 12 14:22:02 posix head only has -n. everything else is "custom" Nov 12 14:22:13 cut however... Nov 12 14:22:58 so whoever fixes it, add a comment that states "X is not supported on Y" Nov 12 14:23:00 "cut -b1-8" is posix specced. Nov 12 14:23:17 karlp: and appears in the Apple man page Nov 12 14:24:59 ldir: are you going to fix it? Nov 12 14:25:44 ynezz: yes, sure - I'll try a fix locally and prove it doesn't blow up... again :-) Nov 12 14:25:55 seems an easy fix Nov 12 14:26:12 thanks! Nov 12 14:27:09 i had to change python and python3 symlink the other day, dunno why Nov 12 14:28:01 is the topic about next kernel version dead? should we make some voting about it? Nov 12 14:29:17 it seems like next version is not an issue, I've registered few objections regarding when/which release Nov 12 14:34:44 as the 19.07 is getting out, it would be nice to make some decisions, especially if we want to follow our Hamburg ideas regarding release schedule Nov 12 14:40:20 20.01 with 4.19, 20.07 with 5.4? Nov 12 14:41:17 I don't think we can make it for 20.01 Nov 12 14:42:03 well, then what's the problem? why we need to vote? :) Nov 12 14:42:57 because it's good to have a plan, not just for us but also for downstream project/users Nov 12 14:53:07 * ldir is an idiot - there are TWO head --bytes to be fixed - ldir has another attempt - it's good to test :-) Nov 12 14:54:39 ynezz: thanks Nov 12 14:56:40 ldir: hmm, I only found one Nov 12 14:57:10 ah, one head --bytes and one head -c Nov 12 14:57:18 what does it mean: "Failed to parse JSON: 4" a bunch of times (~18 or 20) during sysupgrade? Nov 12 14:58:54 only head -c I can see is back in 2018 in 802.11r. Nov 12 14:59:07 and that's something that runs on the target... Nov 12 14:59:12 include/image.mk:mkfs_packages_id = $(shell echo $(sort $(1)) | mkhash md5 | head -c 8) Nov 12 14:59:16 include/image.mk:mkfs_packages_id = $(shell echo $(sort $(1)) | mkhash md5 | head -c 8) Nov 12 14:59:17 include/image.mk:IMG_PART_SIGNATURE:=$(shell echo $(SOURCE_DATE_EPOCH)$(LINUX_VERMAGIC) | mkhash md5 | head --bytes 8) Nov 12 14:59:25 ynezz: :) Nov 12 14:59:29 * ynezz wins Nov 12 14:59:42 congratz :P Nov 12 14:59:42 * karlp uses git grep instead of git log -p and sees the right things Nov 12 14:59:49 karlp: this is from git grep ;) Nov 12 15:00:01 ah, you were using `git log -p` earlier? Nov 12 15:00:04 yeah Nov 12 15:00:07 gotcha Nov 12 15:00:28 that head -c has been there since 2016 though... Nov 12 15:00:35 so shouldn't have been bothering ldir... Nov 12 15:01:16 and actually longer, 2016 was just when md5sum => mkhash md5. Nov 12 15:01:26 no it turns out it wasn't - but I was being stupid and changed the wrong thing...that isn't actually b0rken. Nov 12 15:01:52 well. it _is_ it's just not biting you _yet_ :) Nov 12 15:02:03 yeah but since we're moving it to posix I would change them both ? Nov 12 15:02:14 so now I'm in 2 minds.... cut -b1-8 (posix) or head -c 8 (not posix). - I think posix wins Nov 12 15:02:15 consistency, future-proof, etc Nov 12 15:02:18 i'm getting as far as include /lib/upgrade in /lib/upgrade/do_stage2, but don't see an echo i sprinkled immediately after. Nov 12 15:02:54 anyway - is testing both heads changed to cut -b1-8 Nov 12 15:03:53 i wonder if i'm hitting a watchdog timeout Nov 12 15:04:01 * Slimey gives hugs Nov 12 15:08:52 it's interesting, that shellcheck doesn't care about this `head -c --bytes` even with #!/bin/sh shebang Nov 12 15:09:19 is shellcheck meant to check for posix compliance of invoked binaries? Nov 12 15:09:29 I would have htought it was just a shell checking thing.... Nov 12 15:11:19 hi all, how to add package build dir to PATH as cmakelists.txt uses in the middle binary just compiled for preparing tests? Nov 12 15:12:36 karlp: I've experienced some of this warnings https://github.com/koalaman/shellcheck#portability with /bin/sh so I've thought, that there's some strict mode Nov 12 15:14:09 why didn't make blow up if "IMG_PART_SIGNATURE:=$(shell echo $(SOURCE_DATE_EPOCH)$(LINUX_VERMAGIC) | mkhash md5 | head --bytes 8)" causes head to report illegal option Nov 12 15:14:44 probably just got printed to stderr, and the $(shell blah) captured just the stdout part. Nov 12 15:14:50 It shouldn't have produced an image (in an ideal world?) Nov 12 15:15:06 it's just an assignment to a variable Nov 12 15:15:13 not a command being run, so there's no "failure" Nov 12 15:15:24 you just don't have the value assigned that you hoped you were getting. Nov 12 15:15:30 :-) Nov 12 15:16:18 so more defensive programming would have checked the returned value and barfed if null Nov 12 15:16:40 I'm not sure BLAH=$(shell wop) _has_ a return code... Nov 12 15:17:03 or there's 'don't check for a condition you don't know how to handle' :-) Nov 12 15:17:26 I have enough trouble with shell, let alone make Nov 12 15:19:53 ynezz: all of those look like shell builtins. Nov 12 15:22:42 * ldir goes for an upgrade - if I'm back in 60 seconds then it went well. If not.... Nov 12 15:23:50 good, so I'm not alone testing snapshots on my main gateway :p Nov 12 15:24:33 Ohhh yes!!! Nov 12 15:26:34 * ldir goes for another reboot to check summit Nov 12 15:40:02 yanosz: those instructions, when applied to the file you linked, yield a zero-byte file Nov 12 15:40:47 I've to admin,that I was running freetz on a real box Nov 12 15:46:28 seems to be something to do with the switching to ramdisk Nov 12 16:01:58 erk - new luci fun-ness https://pastebin.com/aYS4qR7A Nov 12 16:09:55 can't open /usr/share/libubox/jshn.sh Nov 12 16:14:17 i am thinking about moving from using libpcre to libpcre2. Which one is the preferred one for openwrt? Is one of them automatically installed because it is a hard dependency in a base-package of openwrt? Nov 12 16:17:30 yeah, we aren't copying the file into the tmpfs in stage2's switch_to_ramfs() Nov 12 16:18:07 oh and i saw neither pcre nor pcre2 has jit enabled. at least the arm-targets should have jit-support according to https://pcre.org/current/doc/html/pcre2jit.html#SEC2 Nov 12 16:22:18 ldir: do you have luci-compat installed? Nov 12 16:33:01 this seems to fix my flash failure: http://paste.debian.net/1115935/ Nov 12 16:37:28 i assume this is related the recently libubox changes? Nov 12 16:43:26 karlp: yep Nov 12 16:50:27 maybe this: 940844e077d7d41bc94728f42b39a65854d38b87 ? Nov 12 16:54:50 zorun: i am also spending some time on the new luci, the document is not updated to reflect the js-cbi yet as far as i can tell. Nov 12 16:57:09 the es6 class sugar syntax was not used and it's a little challening for me to understand those js code as I did not program js in the past :( Nov 12 16:58:50 jow: what's the purpose of the v in each url? e.g. fs.js?v=git-19.310.44720-c2be304 why do we need put git-info in each url request Nov 12 17:02:20 means they don't get cached across updates Nov 12 17:03:13 i see Nov 12 17:08:40 will urngd make /dev/random unblocking Nov 12 17:32:04 rr123: it should, but it depends... Nov 12 19:29:02 build #40 of sunxi/cortexa7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa7/builds/40 Nov 12 20:32:39 blogic: ping Nov 12 20:32:58 blogic: are these intel-mips targets to compatible with current master brancu? Nov 12 20:40:32 no Nov 12 20:40:46 intel mips prpl target feed is not upstream yet Nov 12 20:48:28 blogic: damn Nov 12 20:48:36 https://buildmaster.aparcar.org/#/builders Nov 12 20:48:46 Okay than I have to figure out how to do multi branch wilds Nov 12 20:48:48 *builds Nov 12 22:53:00 aparcar[m]: ŵhat is your plan with the Intel mips target feeds? Nov 12 23:13:51 Hauke: I'm upgrading the buildbot to teach it some new tricks. External feeds are the latest one Nov 12 23:14:03 ah nice Nov 12 23:14:12 I used the Intel MIPS for testing. Will it be upgraded? Nov 12 23:15:56 aparcar[m]: I think it should be upgraded to a new version based on UGW 8.4.1 soon, but this is still using 19.07 or an older master snapshot Nov 12 23:16:09 what problems do you have against master? Nov 12 23:17:42 Hauke: can you please see the buildbots for yourself? Nov 12 23:17:53 I'm on mobile right now Nov 12 23:18:29 Hauke: actually the new buildbot interface is quite mobile friendly https://buildmaster.aparcar.org/#/builders/118/builds/5/steps/43/logs/stdio Nov 12 23:18:43 aparcar[m]: thanks, I didin't saw the logs before Nov 12 23:19:13 ATM_BR2684_MINI_JUMBO_FRAME_SUPPORT Nov 12 23:21:56 aparcar[m]: I will try to have a look at this tomorrow Nov 12 23:22:13 Thank you! **** ENDING LOGGING AT Wed Nov 13 02:59:58 2019