**** BEGIN LOGGING AT Tue Jun 11 03:00:01 2019 Jun 11 04:06:45 ;) Jun 11 04:46:21 morning Jun 11 04:46:41 jow: what do you think about updating lua? it seems some people want it for non-luci projects Jun 11 04:46:45 https://stackoverflow.com/questions/20988178/has-anyone-built-lua-5-2-for-openwrt or https://forum.openwrt.org/t/upgrade-lua-to-5-3/14385/1 Jun 11 05:03:47 * ldir Urgh, up 0415 urgh, 0600, airport lounge, urgh Jun 11 05:05:50 Wow 19.xx branch! nice. Jun 11 05:06:02 OO baby show me your gits! Jun 11 06:29:23 rmilecki: unfortunately these are incompatible to 5.1 so luci will need some serious forward-porting work Jun 11 06:31:35 rmilecki: but I think we can start offering newer version which are installable in parallel to 5.1 Jun 11 06:34:57 jow: under new package name? Jun 11 06:35:06 should we rename current lua to sth like lua-old? Jun 11 06:36:24 we rename lua to lua5.1, adjust the default library search paths to /usr/lib/lua/5.1 etc. Jun 11 06:36:31 then we package 5.2 or 5.3 as lua 5.3 Jun 11 06:36:45 erm as lua5.2 or lua5.3 respectivel basically mimick what other distros do Jun 11 06:39:08 another option would be to deprecate luci standalone and only support uhttpd-mod-lua with a 5.1 .so builtin Jun 11 06:39:24 then we can drop lua 5.1 entirely or update it without affecting luci Jun 11 06:45:50 jow: which option do you prefer? Jun 11 06:46:50 rmilecki: parallel packaging Jun 11 06:47:05 how do we "adjust the default library search paths" ? Jun 11 06:47:14 its a luaconf option irrc Jun 11 06:47:26 basically there's a central header file which can be customized Jun 11 06:47:38 this contains the default paths, compile time options etc. Jun 11 06:48:10 ok, thanks, I'll check that if I find time for it Jun 11 08:28:21 I wonder how https://git.openwrt.org/ae3e232 doesn't break ar7, ixp4xx and orion as they are still on kernel 4.9 Jun 11 08:30:45 stintel: @!LINUX_4_14 includes 4.9 as well Jun 11 08:30:58 should be @!LINUX_4_9 @!LINUX_4_14 Jun 11 08:31:15 indeed that's what I thought Jun 11 08:31:21 but the builders don't fail those targets Jun 11 08:31:56 I can push it during lunch break :) Jun 11 08:32:05 how's the meeting going btw ? Jun 11 08:40:19 we are just writeing a summary of yesterday's results Jun 11 08:51:55 cool! looking forward to read it. some mixed feelings here about not attending, but I'm travelling a lot already and am finally getting my finances in order, should be better the next meeting or summit Jun 11 09:25:44 my avm fritzbox 7360 lacks DSL - there is a hole in the dsl chip. Is there a easy way to build the openwrt for this box completely without dsl support? Jun 11 09:25:46 https://sky.webnmail.de/privatebin/?aa301fffb048d817#M+GNcr10fk803mFhO8X5zlz8xk60HAW1PAG6OvoIBXo= Jun 11 10:08:43 rubberduck: not completely. you can use the imagebuilder to easily assemble an image without the dsl drivers, but the generated default network config will still reference it, so you will need to adapt that Jun 11 10:19:02 okay - so better throw away because a openwrt-nearly-identical fritzbox 3370 is round about €15,- Jun 11 10:31:25 i've added a cronjob that does a reboot at the end. now it hangs in a reboot loop. do all cronjobs get reevaluated when the time is set at boot? Jun 11 11:12:07 i've found the documentation about that behaviour because of sysfixtime but that's not what's happening. the last timestamp in /etc is on 13:03. cronjob with reboot was issued for 13:05. system reboots after 60 seconds even though ntpd set the correct time and therefor the cronjob is in the past Jun 11 12:06:32 oh hi Jun 11 12:07:06 https://www.youtube.com/watch?v=PSxm2DbDHG8 - german language video about reproducible builds Jun 11 12:08:09 i'd be happy to talk about openwrt and reproducible builds either today or tomorrow Jun 11 12:08:30 today probably soon, say at 1500, so i can eat first, or tomorrow anytime after 1100 Jun 11 12:08:35 lynxis: ^ Jun 11 12:09:05 \o/ Jun 11 12:09:14 hmm, I might have been too fast to deny the DCO enable request on gh/openwrt/openwrt Jun 11 12:09:15 we have a break till 14:30 Jun 11 12:09:22 * lynxis waves towards stintel Jun 11 12:09:27 lynxis: o/ Jun 11 12:09:42 I remembered that DCO was junk: http://lists.infradead.org/pipermail/openwrt-devel/2018-May/012331.html Jun 11 12:10:45 stintel: maybe they fixed it already. let's try Jun 11 12:12:57 rubberduck: funny problem ;-) Jun 11 12:13:16 stintel should I request it again? Jun 11 12:13:46 aparcar[m]: nah, we can enable it. lynxis will you handle it and revert again if it causes issues? Jun 11 12:14:08 stintel: yes. I'm sitting right beneith stintel Jun 11 12:14:18 no you're not :D Jun 11 12:14:32 next to you. arghh Jun 11 12:14:37 english, spoken languages are crap Jun 11 12:14:38 ;D Jun 11 12:14:38 * h01ger goes to have food. will be back at ~1430ish Jun 11 12:15:40 Hauke: funny in which direction? Jun 11 12:17:04 the DSL Interface was destroyes by a Flash... Jun 11 12:17:08 -s+d Jun 11 12:17:14 Flashlight Jun 11 12:20:40 thunderstorm Jun 11 12:21:02 high voltage by nature Jun 11 12:32:06 aparcar[m]: stintel: lynxis: can we do something about those requests landing here without any context that (I assume) come from the meeting? PRs without any commit messages etc Jun 11 12:32:25 KanjiMonster: which ones? Jun 11 12:32:29 where did it landed? Jun 11 12:32:55 at least I assume those by aparcar[m] are based on discussions on the meeting Jun 11 12:33:58 KanjiMonster: sure. there should be a detailed commit message if you mean PR#2109 Jun 11 12:34:33 KanjiMonster: btw: we've written down notes and will publish them Jun 11 12:34:37 lynxis: also #2107 Jun 11 12:35:47 the notes relevant to the PRs should be in the PR, not separate Jun 11 12:36:05 KanjiMonster: sure! Jun 11 12:38:38 it is just funny to have a broken chip Jun 11 12:41:47 KanjiMonster: there won't be any decision made at the hamburg meeting. everybody has only the power as they can do as individual. for everything what happens here, we will write a note. if there are things which change the projects. The project as all people (and of corse, the people who are in Hamburg and not in Hamburg) counts here will have a vote on that. Jun 11 12:42:06 sorry, this should not be directly towards you KanjiMonster. That should be a general annoucement Jun 11 12:42:46 There won't be any decision made at the hamburg meeting. Everybody has only the power as they can do as individual. For everything what happens here, we will write a note.If there are things which change the projects. The project as all people (and of corse, the people who are in Hamburg and not in Hamburg) counts here will have a vote on that. So meaning who is allowed to vote. Jun 11 12:57:46 lynxis: i'll be around in 7-10min Jun 11 12:58:02 h01ger: time is bendable Jun 11 13:42:40 https://tests.reproducible-builds.org/openwrt/ and then eg https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html Jun 11 13:42:50 also https://try.diffoscope.org Jun 11 13:43:33 is builT twice Jun 11 13:43:43 what about testing with 42.zip? Jun 11 14:26:55 urng will not be part of 19.07? Jun 11 14:27:04 aparcar[m]: https://meetings-archive.debian.net/pub/debian-meetings/2019/miniconf-hamburg/hacking.webm is the 'hacking (the) work(place)' talk from sipgate Jun 11 16:10:43 h01ger nice thank you Jun 11 16:15:27 aparcar[m]: np :) Jun 11 17:53:43 ping mangx Jun 11 17:53:48 ping mangix Jun 11 18:58:41 cotequeiroz: pong Jun 11 19:00:41 ping cotequeiroz Jun 11 19:05:43 mangix: I'm starting to look at #9218. You said you were listing two commits, but you listed the same one twice. Do you have a second one? Also, does the issue appear in a local build, or just the bots? Jun 11 19:05:54 rubberduck: pong Jun 11 19:06:53 cotequeiroz: one is libfolly, the other libfizz Jun 11 19:07:57 i have no idea why it's failing. it was successful here: https://github.com/openwrt/packages/pull/9111 Jun 11 19:08:32 The buildbots currently fail the same way with the CXX_ABI errors Jun 11 19:09:36 only thing i can think of is some change in the main openwrt repo but i can't see anything Jun 11 19:12:06 I'll check the tmp files with the commit you mentioned removed, to see what differs. Main question is does it happen in your local build, or is restricted to circleci/buildbots. Jun 11 19:13:20 on arc700, I'm getting a different failure (possibly because of libatomic). I'll try to test a different platform. Jun 11 19:14:17 note that the pull request allows compilation with more targets Jun 11 19:36:34 I've cheked tmp/.packagedeps, and it apparently does what it is supposed to: Jun 11 19:38:36 Changes $(if $(CONFIG_(mips||mipsel||powerpc||i386||x86_64||arm||aarch64)),$(curdir)/libs/libunwind/compile) (note that this is in devel/perf/compile), to: Jun 11 19:39:16 $(if $(CONFIG_mips)$(CONFIG_mipsel)$(CONFIG_powerpc)$(CONFIG_i386)$(CONFIG_x86_64)$(CONFIG_arm)$(CONFIG_aarch64),$(curdir)/libs/libunwind/compile) Jun 11 19:41:13 I'm mentioning libunwind, as it is the only dependency of libfolly/libfizz that's being affected in any way. It looks correct to me. Jun 11 19:43:41 I should probably get rid of the libunwind dependency, given how much of a mess it is Jun 11 19:48:42 just tried compiling on powerppc. it's failing on rsocket-cpp. Jun 11 19:48:48 * mangix looks Jun 11 19:53:07 The full diff of .packagedeps can be seen with 'curl https://pastebin.com/raw/1TeAVSeP | less'. Note that I used color output, so it won't look pretty in a browser Jun 11 20:08:42 c++ error. lovely. Jun 11 20:08:53 * mangix hates c++ Jun 11 20:17:54 thrift1: error while loading shared libraries: libboost_filesystem.so.1.70.0: cannot open shared object file: No such file or directory Jun 11 20:18:05 same error Jun 11 20:32:37 ahh bugger I wanted to migrate my IPsec tunnels to xfrm interfaces but didn't realise I'm not running 4.19 Jun 11 20:34:39 stintel:it seems not be working as expected as reported by the author but I don't fully understand what the issue is Jun 11 20:35:22 I've asked him for more details Jun 11 20:40:39 about kernel version .. since 19.07 branch was created, can we switch default kernel version of targets in master to 4.19 or preferably not yet ? Jun 11 20:41:56 if not I'm going to wait with trying the xfrm interfaces thing. it would suck to forget to use 4.19 during a build in the future and ending up with broken VPN Jun 11 21:05:49 stintel: I would be fine with it. Maybe send a short email about to -devel to collect a few acks? Jun 11 21:06:24 always nice to have a (e-)paper trail for these things ;) Jun 11 21:08:21 KanjiMonster: done! Jun 11 21:12:47 stintel: replied! Jun 11 21:13:25 KanjiMonster: thanks! Jun 11 21:18:11 ah but there's also this KERNEL_TESTING_PATCHVER now. what is this sorcery Jun 11 21:18:42 aha. CONFIG_TESTING_KERNEL could work for me too Jun 11 21:35:22 thanks for the 19.07 branch guys <3 Jun 11 21:35:53 Borromini: o/ Jun 11 21:51:44 * stintel stabs perf Jun 11 21:52:24 * Hellsenberg runs away Jun 11 22:30:17 meh, need to migrate from ipsec.conf to swanctl.conf too for xfrm interface in strongswan :/ Jun 11 22:37:09 Are there any NAND-based devices that do NOT use UBIFS for the overlay, but something like JFFS2 on a UBI block-device? Jun 11 22:53:51 I would expect that to be the normal situation, the r7800 at least is using ubi, but I don't know which fs on top for the overlay (and can't seems to find information about that at the moment) Jun 11 22:59:22 ah, no, ubifs on ubi is probably more likely (BT Home Hub 5 Type A, /dev/ubi0_2 on /overlay type ubifs (rw,noatime,ubi=0,vol=2)) Jun 11 23:02:12 jeffsf: no; if it has NAND, it uses ubifs overlay Jun 11 23:02:32 perfect timing ... Jun 11 23:02:34 jeffsf: no; if it has NAND, it uses ubifs overlay Jun 11 23:52:22 looks like xfrm interface don't play along with multicast, as my OSPF config completely broke Jun 11 23:52:39 changed it to nonbroadcast and specified neighbor IPs and now it's working Jun 11 23:53:12 also, strongswan swanctl, wtf. not impressed Jun 12 00:28:10 Thanks KanjiMonster -- `firstboot` fails on NAND devices because `jffs2reset` assumes there is a JFFS2 file system there and writes a "magic mark" Jun 12 00:28:16 https://bugs.openwrt.org/index.php?do=details&task_id=468 Jun 12 00:29:53 past the problems of trying to write(fd, &deadc0de, sizeof(deadc0de)) to a NAND MTD device Jun 12 00:33:44 (4 bytes) **** ENDING LOGGING AT Wed Jun 12 03:00:27 2019