**** BEGIN LOGGING AT Wed Jan 30 02:59:57 2019 Jan 30 03:47:23 gch981213: it breaks my auto-provisioner scripts ;-) Jan 30 07:13:45 morning Jan 30 07:32:25 morning jow Jan 30 08:17:57 are the kirkwood-linksys_audi-squashfs-factory.bin mages used for aynthing besides the EA3500 ? Jan 30 08:18:11 I'm consfused by these stupid Linksys code names Jan 30 09:18:39 ynezz, that works! I needed to create a new patch, compile fine. thank you for the link! Jan 30 09:21:13 jow: no, audi means ea3500 Jan 30 09:21:37 I also don't know why we need to use the codenames in the image filenames ... Jan 30 09:21:50 allright. any last remarks before tagging 18.06.1 ? Jan 30 09:22:36 I am going to drop these images after build from the download server due to known brokeness: https://pastebin.com/wuC1WQYe Jan 30 09:23:04 *18.06.2 obviously Jan 30 09:24:29 ldir: ping Jan 30 09:33:57 ping Strykar Jan 30 09:34:00 ops Jan 30 09:34:02 ping stintel Jan 30 09:43:20 jow: I have the latest kernel bumps staged. compile-testing as we speak. do you want this in? Jan 30 09:43:59 xback: anything critical in thme? Jan 30 09:44:15 if not lets defer them to the next point release, I expect it in 4-8 weeks Jan 30 09:45:10 jow: you read my mind :) I was checking the diff Jan 30 09:45:18 nothing critical Jan 30 09:45:36 i'll hold off until the tag occured Jan 30 09:47:03 anyone knows about the dnsmasq lease issue recently discussed here? Jan 30 09:47:15 has it been fixed? does it need patching? Jan 30 09:48:43 dedeckeh: do you know this? Jan 30 09:50:47 iirc, stintel had been testing some stuff for ldir and was happy, not sure if it had been merged or not? Jan 30 09:51:28 I see no relevant commits in 18.06 Jan 30 09:52:21 not sure it was ever reported as a problem on 18.06? Jan 30 09:53:25 jow: maybe also useful to cherry-pick the latest wireguard commits? Jan 30 09:53:54 it's seems pretty popular, and safe to pick them Jan 30 09:54:00 xback: yeah, going to pick the wg stuff and the hostapd ap-sta chanswitch fixes, after that I'll close the box Jan 30 09:56:02 actually the chan switch is too hot for my taste, not going to pick it Jan 30 09:56:59 jow xback:stintel stated he did not see the issue anymore with the dnsmasq trunk version Jan 30 09:58:02 ldir proposed to update dnsmasq to the latest version in 18.06 but this was not met with universal approval Jan 30 09:58:05 I took a cursory look at the dnsmasq git but couldn't see obvious things Jan 30 09:58:53 me neither; I cannot pinpoint which commit would solve this Jan 30 09:59:31 jow: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7541d30c9c2946fe112d7966f9d1e7456725c324 Jan 30 09:59:51 i recall this from ldir regarding that specific issue Jan 30 10:00:28 "the most relevant fix .." is regarding that issue Jan 30 10:00:45 ah - thanks! Jan 30 10:00:54 I'll just pick https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/dnsmasq/patches/0030-Fix-entries-in-etc-hosts-disabling-static-leases.patch;h=265bd3fc9efb70437114b63c2a2909bb4f323d78;hb=7541d30c9c2946fe112d7966f9d1e7456725c324 into 18.06 then Jan 30 10:01:12 (in case it applies at all) Jan 30 10:03:50 jow: looks reasonable to do so :) Jan 30 10:32:05 jow: i've all my fixes in the 18.06 branch Jan 30 10:32:22 ack for renaming images to don't use code names Jan 30 11:05:56 jow: pong Jan 30 11:06:42 printer still has correct IP from static lease Jan 30 11:06:47 13:06:43 up 13 days, 18:33, 0 users, load average: 0.11, 0.19, 0.21 Jan 30 11:07:03 but for the printer it took some time before the problem occured Jan 30 11:07:07 stintel: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=80ed6ebc56b4e982451dae7d40f14943a2f28a9c Jan 30 11:07:12 laptop was usually immediate, but currently not at home Jan 30 11:07:25 jow: great Jan 30 11:08:08 I'll be back in Sofia next Monday for 3 weeks, will be a bit more active then Jan 30 11:08:25 now installing the network in my client's new office, which opens tomorrow :D Jan 30 11:08:40 ah good. I'll be more or less completely offline from feb 18th to march 4th Jan 30 11:09:20 forgive me for asking, is there any date for branching 19.01 ? or did I miss it :P Jan 30 11:09:52 not from my side, but we can branch during the next few weeks Jan 30 11:10:12 I got the impression though that people just want to branch to jump to kernel 4.19, not to actually produce a release ;) Jan 30 11:18:28 bad reason :P Jan 30 11:29:06 * ldir wanders in Jan 30 11:30:00 jow: pong Jan 30 11:35:43 ldir: I was a bit confused wrt. the static lease bug situation with dnsmasq Jan 30 11:36:10 ldir: but I've been told that you had a commit prepared which address this - I cherry picked the single patch from there Jan 30 11:38:33 ah, ok. I saw a change go in to upstream dnsmasq and had a hunch it might fix stintel's static lease problem...which it appears to have done. Jan 30 11:38:50 ldir: you're still my hero for that ;-) Jan 30 11:39:56 Basically there's an issue caused by dnsmasq allocating leases for ipv4 vs external methods allocated ipv6 and putting entries into hosts files. Jan 30 11:40:58 I've never hit it 'cos I use dnsmasq for all my ipv4 * ipv6 needs. Jan 30 11:41:17 nbd: https://github.com/openwrt/openwrt/pull/1485 - opinions? ack/nak? Jan 30 11:41:55 there are 2 relevant patches - one fixes it, and the other fixes the fix (some missing braces) Jan 30 11:42:18 xback: https://github.com/openwrt/openwrt/pull/1484 - ack? Jan 30 11:42:21 without the second it'll segfault :-) Jan 30 11:42:41 ldir: ugh, I only picked one patch Jan 30 11:42:47 ldir: which one addresses the segfault? Jan 30 11:43:50 if you picked 0030-* then 0031-* is the fix for the fix. It's an absolute silly related to single vs multi-line if clauses. Jan 30 11:44:21 jow: fine with me Jan 30 11:44:40 jow: I tend to NACK that one. imho that should be taken upstream (as I've told him multiple times) Jan 30 11:45:53 xback: isn't that a side effect of the alignment hack used for ar71xx/ath79, so not an issue of upstream? Jan 30 11:46:44 jow: oops no, sorry it's not an if thing but rather a for loop thing.... but not immediately obvious because of some #ifdef nearby :-) Jan 30 11:47:36 hmmm, finally playing around with flent Jan 30 11:48:15 KanjiMonster: checking .. Jan 30 11:48:59 jow: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=d2d49907435433001ab00698a3e9ca2a7b5b3236 Jan 30 11:49:08 I mean the patch touched is the alignments hack patch ;) Jan 30 11:50:03 * xback is reading the alignment patch Jan 30 11:51:49 ldir: ugh, will take that one asap Jan 30 11:52:42 Hi all, I'm playing around with netifd wireless API Jan 30 11:52:58 just wondering how you're supposed to handle one daemon handling multiple radios? Jan 30 11:53:19 jow: I would point out that backporting those 2 patches alone would have received less testing than picking all the dnsmasq patches in master - though it's unlikely to go wrong. Jan 30 11:53:25 nbd: the api is not designed for that atm Jan 30 11:53:32 sorry, Neighbor11111114 ^ Jan 30 11:53:45 thnaks Jow, thought so Jan 30 11:53:52 so I should probably just hack it Jan 30 11:54:08 if you were going to do it how would you do it? Perhaps I could give you a patch if it works for me Jan 30 11:54:21 if you wanted it Jan 30 11:54:21 I'd probably start out with some kind of placeholder process Jan 30 11:54:48 start hostapd as normal system daemon and have the placeholder processes poke it using wpa_cli calls Jan 30 11:55:09 then refine from there Jan 30 11:55:56 KanjiMonster: true .. but I dont get it yet why the alignment patch is needed. meaning .. is this target the only one in the world affected by this? Jan 30 11:56:24 intersting, ok cool thanks! Jan 30 11:56:43 xback: that and ath79 Jan 30 11:57:21 xback: iirc the problem is that a vanilla upstream kernel causes a lot of misalignment traps on ar71xx due to not properly packed / aligned structures Jan 30 11:57:32 which causes performance impacts in certain hot paths Jan 30 11:57:37 xback: ar71xx/ath79 needs ethernet packets to start at a 4-byte boundary, causing the ip-header to be 2-byte aligned instead of the expected 4-byte alignment. all sane ethernet controllers support either 2-byte alignment (so ip header is 4-byte aligned), or the cpus support efficient unaligned accesses Jan 30 11:59:06 thanks for the details Jan 30 11:59:36 I just can't believe that structs like that are not aligned by default to a sane boundary upstream :s Jan 30 11:59:48 jow: in that case .. ack on the patch Jan 30 12:03:33 xback: it's a soup of some can, some can't, some prefer, some don't. Jan 30 12:03:42 been a problem "forever" Jan 30 12:07:36 * russell-- getting a bunch of complaints: tmp/.config-package.in:110847: symbol PACKAGE_lighttpd-mod-auth is selected by PACKAGE_lighttpd-mod-authn_file Jan 30 12:08:03 big (network) v little endian, vi v emacs :-) Jan 30 12:08:04 yeah, bugs introduced over in the packages feed Jan 30 12:08:19 iirc someone ocmmented on it already but no reaction so far Jan 30 12:10:16 russell--: libmicrohttpd-no-ssl too. Jan 30 12:20:03 xback: a "workaround" for the alignment issue would be to enable the proprietary atheros header on atheros/qca switches - it's inserted before the payload, and is 2 byte, thus shifting the payload again to the expected 4-byte alignment Jan 30 12:22:32 pretty classic workaround :) some old cisco stuff used to insert 2 bytes there and use it for internal things Jan 30 12:29:07 who's the resident umbim expert? Jan 30 13:00:40 jow: thank you for your answer about backporting. So, no issues if I backport youtube-dl (as I am Co-maintainer of this package) to 18.06.02 also would be good, if one fix to luci-app-lxc could be merged as well to OpenWrt 18.06.02 Jan 30 13:01:53 Pepe: sure Jan 30 13:02:00 Thank you! Jan 30 13:02:10 Pepe: in general the policy for packages not included in the default images is a bit more relaxed Jan 30 13:02:31 Pepe: what should be avoided is doing major, incompatible version updates or updates that break existing configurations Jan 30 13:02:55 like. e.g. switching from samba3 to samba4, or openssl 1.0.x to openssl 1.1 or 1.2 Jan 30 13:04:02 Agree, I'm aware of openssl. But I thought that it would be good to provide samba3/samba4 together. Jan 30 13:05:40 problem with samba4 in particular is that it more or less requires a switch from librpc to libtirpc Jan 30 13:05:51 which in turn requires updates to various packages Jan 30 13:28:28 jow: during clone I got this: Jan 30 13:28:30 WARNING: previous mirror push of repo 'openwrt/openwrt' to host 'git-02' failed, status is: Jan 30 13:29:28 is that important? Jan 30 13:41:39 Hi,do you know how is PKG_CPE_ID used ? Is there any tool which use that information ? Jan 30 14:11:52 18.02.2 got tagged? Jan 30 14:12:00 erm 18.06.02 Jan 30 14:13:33 jow: why is the clone() necessary in most of the json-rpc providers? uci uses the jsonrpcbind to do a ~clone too, with wrappers to load/commit sort of thing, but ipkg doesn't do a clone? Jan 30 14:13:44 just working out what's best to copy Jan 30 14:14:15 lach1012: yes Jan 30 14:14:34 looking at https://github.com/openwrt/luci/blob/master/modules/luci-mod-rpc/luasrc/controller/rpc.lua for reference Jan 30 14:15:13 karlp: the clone is needed when at least one function needs to be wrapped Jan 30 14:15:30 karlp: modifying the original module scope would alter the module for every one Jan 30 14:15:57 leading to unwanted side effects such indirect as recursion Jan 30 14:16:03 *such as indirect Jan 30 14:18:22 so in the fs case, it's because you're _replacing_ the readfile/writefile methods with ones that do the ltn pump stuff instead of the original ones? Jan 30 14:20:15 so I guess as long as I write a "plain" module like luci-module-ipkg, then I shooudn't need much trickery in the rpc registraiton. Jan 30 14:20:19 * karlp goes off to try things a bit. Jan 30 14:20:27 right Jan 30 14:20:42 I made a mess of this last time I tried and decided I should try looking at the existing rpc implementations first. Jan 30 14:21:05 readfile/writefile are replaced with variants that read/produce base64 data, hence the wrapping Jan 30 14:21:29 he kept his motor running but he never kept it clean Jan 30 14:21:56 and luci.sys.net was wrapped because getiwinfo() returns an opaque metatable object which cannot be json serialized, hence the need for a wrapper producing a proxy object Jan 30 14:22:18 and the uci wrapper is just a different style, in a separate file, to handle doing things atomically per rpc call, instead of via the series of calls that's normally required Jan 30 14:22:25 right Jan 30 14:22:54 trying to do a little sqlite db front end thingy. Jan 30 14:25:38 jow: pushed another mt76 update backport to 18.06, which fixes a regression from a while back. not sure if it's worth putting into 18.06.2 Jan 30 14:30:14 nbd: I already tagged two hoursor so ago Jan 30 14:30:31 nbd: if further worthwhile things turn up we can put out another dot release in 3-4 weeks Jan 30 14:31:52 fine with me Jan 30 14:32:02 just wanted to let you know Jan 30 14:32:06 thanks Jan 30 14:32:18 jow: well, I guess Hauke's "add missing config option for kernel 4.14" preemptively. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a5269ffa7a46f3318d35fbdb13d18580717c8498 since it will be a thing in 3-4 weeks Jan 30 14:32:31 *add Jan 30 14:33:04 (18.06.02 should be fine since it's on 4.14.95) Jan 30 14:46:54 lach1012: this is the reason I didn't push the kernel bump yet to 18.06 Jan 30 14:47:14 xback: could you defer the bump for one or two days? Jan 30 14:47:17 hauke's patch fixes it .. but there is nothing important in the bump to take the risk on such short notice Jan 30 14:47:28 jow: noted Jan 30 14:47:38 this will reduce the work for the builders, producing the binary images faster Jan 30 14:47:59 otheewise they'll need to jump back and forth between the kernel versions, rebuilding a lot of things in between Jan 30 14:48:10 ok Jan 30 14:48:54 will divert some resources on the fsf machines to speed up release building Jan 30 14:49:02 jow: before I go off on a wild goose chase, if I'm making json rpc calls from a logged in user, things should "just work" ? or will I still need to be calling auth manually? Jan 30 14:49:33 karlp: it should just work as long as you pass a valid sid Jan 30 14:49:45 either through cookie or via that http param Jan 30 14:49:59 I've got some notes that "<%=luci.dispatcher.context.authsession%>" will give me that? Jan 30 14:50:07 correct Jan 30 14:50:20 browsers should handle the cookie already though right, shouldn't even need that? Jan 30 14:50:38 or does that depend on how exactly I make the jsonrpc call from the client code I guess. Jan 30 14:50:59 iirc your xmlhttprequest call needs withCredentials = true Jan 30 14:51:27 and then it depends on whether the rpc endpoint url falls witihn the luci prefix, otherwise the sysauth cookie might not get sent Jan 30 14:51:51 I can't tell offhand whether thats the case, just check the browser debugger to see if sysauth cookie is sent by default Jan 30 14:52:09 ok, I can do that. Jan 30 15:03:15 qick question: Is the "procd_set_param respawn" parameter supposed to respawn a service even if it was manually stoped via luci/startup/stop? Jan 30 15:05:32 andy2244: no, that luci stop button should trigger an /etc/init.d/foo stop in background Jan 30 15:05:43 which in turn will completely deregister the service from procd Jan 30 15:07:22 mhh can you have a quick look than at my softethervpn5 init script, i just noticed that the service will respawn just after i hit stop...unless i remove the option from the init, script no clue why. Jan 30 15:07:23 https://git.openwrt.org/?p=feed/packages.git;a=blob;f=net/softethervpn5/files/vpnserver.init;h=e6f73da315248fa2f76fe188407d92ee8da292d0;hb=refs/heads/master Jan 30 15:11:28 andy2244: can you compare ubus call service list '{ "name": "softethervpnserver" }' before and after calling /etc/init.d/softethervpnserver stop ? Jan 30 15:11:44 andy2244: also is the stop taking a longer amount of time? Jan 30 15:12:39 mhh "vpnserver stop" takes like 1-3 seconds on my board, you think i need to set some higher timeout time? Jan 30 15:13:25 that should be okay, was thinking about the possibility that the luci action simply times out Jan 30 15:15:47 ok what should i look for in the service list, i only see different "running" entries, goes from true, after i hit stop its false and than after the restart true again Jan 30 15:16:26 so the service gets restarted by procd after i hit stop, like 3 seconds later Jan 30 15:16:48 i can see the process getting killed, than a new is spawned Jan 30 15:19:18 its still ok to call "/var/softethervpn/vpnserver stop" manually inside stop_service() for procd stuff? Jan 30 15:24:26 I think that might be the culprit Jan 30 15:24:47 does it work if you simply comment out the entire stop_service() procedure? Jan 30 15:29:15 yes works without it, mhh i used the explicit stop since i upped the config save intervall my 12 hours, so i wanted to ensure the server is closed correctly and writes its log files Jan 30 15:30:13 guess i have to verify if procd sigkill triggers correct closing behavior in the server than Jan 30 15:30:26 is the stop command you used doing more than just delivering a TERM signal? Jan 30 15:30:47 no clue, did not inspect the code of it Jan 30 15:30:57 I think you can keep using it if you tune the respawn values Jan 30 15:31:06 do the luci-json-rpc endpoints still use rpcd's acls? Jan 30 15:31:53 karlp: no Jan 30 15:32:29 so "3600 5 5" is default what values should i try? Jan 30 15:33:07 andy2244: ah hmm, then forget what I said. I though the holdoff is 0 by default Jan 30 15:36:57 ok, I added some trace, and it's because the ubus session lookup isn't returning a "secret" here: https://github.com/openwrt/luci/blob/master/modules/luci-mod-rpc/luasrc/controller/rpc.lua#L17 Jan 30 15:37:29 I just get a token+username from ubus call session get Jan 30 15:39:44 commenting out that line on secret makes it work. Jan 30 15:42:38 karlp: uhm... need to check Jan 30 15:43:06 np Jan 30 15:43:26 commenting out that line is wayyyyyy easier than the ubus rpcd hoops I was trying last time I did this, this is super easy and nice now :) Jan 30 15:45:37 yeah, that secret is only generated when logging in through the rpc controller, web sessions don't have it set Jan 30 15:46:00 from a cursory look it does not appear to be used at all, so we can likely drop it entirely from the code, to make rpc sessions compatible with web sessions Jan 30 15:46:24 works for me :) [tm] Jan 30 15:46:49 was using rpc because it was meant to be "like" the web sessions, and didn't need to do auth myself. Jan 30 15:47:06 people can auth externally if they want to still. Jan 30 15:49:16 do you want me to file a ticket on github for this? or have you got it? Jan 30 15:52:27 karlp: already pushed Jan 30 15:59:35 awesome thanks. Jan 30 16:00:19 so, anyone know why valgrind doesn't build on mips_24kc? lto-wrapper failures? http://downloads.openwrt.org/snapshots/faillogs/mips_24kc/base/valgrind/compile.txt Jan 30 16:07:10 reverting https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=0331770299b1587a96285fd1af33afe6de4ecbb9 fixes it.... Jan 30 16:29:21 jow: the cifs kernel server package i work on currently, will need CONFIG_KEYS=y, this must be changed directly in openwrt\target\linux\generic\config-xx ? So all targets have this kernel feature enabled? Jan 30 16:29:36 yep Jan 30 16:31:14 i just got it to work after i contacted the devs and we sorted out some problems, i still get a few segfaults so will need to test it a bit more, before i make the PR. They are two samsung kernel devs working on this atm. Jan 30 16:32:42 atm i need to build with full-nls, i will try to just add the missing stuff to the mini package, i think its only UTF16LE/BE thats missing. Jan 30 16:35:42 first test are promising, i get max network speeds via this smbv3 server at 110MB/s at lower cpu usage than samba4 and the package is tiny, i think just 200kb total Jan 30 16:36:36 we need to see how large the impact of CONFIG_KEYS is on the kernel image Jan 30 16:37:32 yeah i just quickly looked at the kernel docu and should be a rather minimal change, all the other options where already enabled for the module Jan 30 16:38:15 i think one crypto module was missing, but seemed to work without it on my system so far Jan 30 16:38:35 that sounds very promising indeed Jan 30 16:39:40 they also kinda use the same smb.conf syntax, but just supporting the basic needed parameters atm. I will try and symlink my samba4 cfg to there folder and see if the server can seamlessly be swapped. Jan 30 16:40:12 I'd prefer some "just give me smb from this mount point" option over samba4 any minute Jan 30 16:40:34 smaba4 is just too big and complicated to setup, people often just want some expose disk, share anything, no auth option Jan 30 16:41:16 yeah its madness what i had to do, just so i get a simple fileshare working ... Jan 30 16:41:50 btw you have a trick how can i kill a kernel module if i get this: Jan 30 16:41:50 rmmod cifsd Jan 30 16:41:50 unloading the module failed Jan 30 16:42:09 unfortunately not Jan 30 16:42:32 seems after i got a few segfaults in the userspace tools i cant kill/remove the module anymore and need to restart the router... Jan 30 16:43:27 ah btw how should i handle the actual module loading than? I have seen some auto startup stuff and some manual modprobe in init scripts? Jan 30 16:44:06 usually a define KernelModule/fooo definition contains some AUTOLOAD:=$(call AutoLoad...) definition Jan 30 16:44:23 that will, through various indirections, create an /etc/modules.d/foo file containing the name of the module Jan 30 16:44:34 yeah but than the module will always be loaded even if the userspace server is disabled? Jan 30 16:44:47 during boot, /sbin/kmodloader is invoked which will scan /etc/modules.d/ and load all mods from there Jan 30 16:44:53 yes, it'll always be loaded Jan 30 16:45:20 if this is a problem then don't AUTOLOAD:= and modprobe it from the init script instead Jan 30 16:45:33 mhh i think i rather load it via init than, the project is only 2 years old and under development Jan 30 16:45:34 I wouldn't bother about rmmod (unless its needed for to some reason) Jan 30 16:45:58 ok makes sense thanks Jan 30 17:47:34 Does netifd add wireless interfaces to the LAN bridge (assuming the interface is part of lan)? Or is that done somewhere else? Jan 30 17:50:45 I think wpad/hostapd's "bridge" config option does it. Jan 30 17:56:01 right, hostapd is responsible for that Jan 30 18:28:06 karlp: https://github.com/openwrt/openwrt/pull/1634 Jan 30 18:38:02 andy2244: does cifsd work similar to samba? Jan 30 18:38:20 define similar? Jan 30 18:38:44 "create shares, access them" Jan 30 18:39:05 yes, with some minor exceptions i noticed already Jan 30 18:40:16 locking is a bit simpler atm, compared to samba4. So as example some of my portable apps do not directly run from the share, which works with samba4. Yet as simple fileshare it seems to work ok so far. Still need to-do more testing. Jan 30 18:40:34 samba3 for me is unusable. sendfile is totally broken on several platforms (ramips, mvebu) Jan 30 18:41:14 even without sendfile it crashes after a while Jan 30 18:41:29 build #177 of layerscape/armv8_64b is complete: Failure [failed kmods] Build details are at http://release-builds.openwrt.org/18.06/images/builders/layerscape%2Farmv8_64b/builds/177 Jan 30 18:41:48 build #202 of apm821xx/nand is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/apm821xx%2Fnand/builds/202 Jan 30 18:42:06 build #201 of ramips/rt3883 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Frt3883/builds/201 Jan 30 18:42:23 andy2244: my usecase involves playing music from a samba share for hours. Jan 30 18:42:25 build #198 of ar71xx/mikrotik is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ar71xx%2Fmikrotik/builds/198 Jan 30 18:42:43 build #197 of mvebu/cortexa72 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mvebu%2Fcortexa72/builds/197 Jan 30 18:43:03 build #197 of armvirt/32 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/armvirt%2F32/builds/197 Jan 30 18:43:22 build #141 of mediatek/mt7622 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mediatek%2Fmt7622/builds/141 Jan 30 18:43:37 i also got some crashes already, but those seem to-be related to some untested configs and configurations. The devs seem to only test x86 atm on a full distro, not something like openwrt. I hope this package can be what the nfs4 kernel server is for nfs, a simple and fast way to get a fileshare, without the samba4 madness. Jan 30 18:43:41 build #194 of ixp4xx/harddisk is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ixp4xx%2Fharddisk/builds/194 Jan 30 18:43:59 build #194 of cns3xxx/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/cns3xxx%2Fgeneric/builds/194 Jan 30 18:44:17 build #193 of x86/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2Fgeneric/builds/193 Jan 30 18:44:35 build #194 of mvebu/cortexa9 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mvebu%2Fcortexa9/builds/194 Jan 30 18:44:53 build #192 of mvebu/cortexa53 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mvebu%2Fcortexa53/builds/192 Jan 30 18:45:11 build #185 of archs38/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/archs38%2Fgeneric/builds/185 Jan 30 18:45:18 andy2244: what's the filesize? Jan 30 18:45:20 Yet its to early, i just got the the package to work today and did some basic testing, need to-do more testing on the weekend and gobble together a simple PR, which than more can test. Jan 30 18:45:29 build #189 of layerscape/armv8_32b is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/layerscape%2Farmv8_32b/builds/189 Jan 30 18:45:48 build #172 of sunxi/cortexa8 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/sunxi%2Fcortexa8/builds/172 Jan 30 18:46:06 build #172 of x86/legacy is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2Flegacy/builds/172 Jan 30 18:46:16 the kernel module and userspace tools are like 200kb, but it uses glib2 so thats a extra 700-900kb i think. I asked about glib2, but atm the devs don't want to replace it. Jan 30 18:46:25 build #172 of bcm53xx/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/bcm53xx%2Fgeneric/builds/172 Jan 30 18:46:34 thanks lach1012 and jow Jan 30 18:46:43 build #170 of lantiq/xrx200 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/lantiq%2Fxrx200/builds/170 Jan 30 18:47:02 build #169 of brcm2708/bcm2709 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm2708%2Fbcm2709/builds/169 Jan 30 18:47:20 build #168 of brcm2708/bcm2708 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm2708%2Fbcm2708/builds/168 Jan 30 18:47:26 It also needs a full-nls package, but i think i can fix this by adding only the needed converts to the tiny nls package. Jan 30 18:47:38 build #168 of octeon/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/octeon%2Fgeneric/builds/168 Jan 30 18:47:56 build #166 of at91/sama5d4 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/at91%2Fsama5d4/builds/166 Jan 30 18:48:15 build #166 of at91/sama5d3 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/at91%2Fsama5d3/builds/166 Jan 30 18:48:33 build #165 of at91/sama5d2 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/at91%2Fsama5d2/builds/165 Jan 30 18:48:49 andy2244: sounds great then. No idea if CIFS versions can be compile time disabled. Should save some space. Jan 30 18:48:51 build #179 of brcm63xx/smp is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm63xx%2Fsmp/builds/179 Jan 30 18:49:10 build #179 of ramips/mt7620 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Fmt7620/builds/179 Jan 30 18:49:22 what you mean by "CIFS versions can be compile time disabled" ? Jan 30 18:49:28 build #176 of ramips/mt7621 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Fmt7621/builds/176 Jan 30 18:49:47 build #176 of lantiq/falcon is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/lantiq%2Ffalcon/builds/176 Jan 30 18:50:02 andy2244: #ifdef'd out. Jan 30 18:50:06 build #176 of sunxi/cortexa7 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/sunxi%2Fcortexa7/builds/176 Jan 30 18:50:24 build #189 of ar71xx/tiny is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ar71xx%2Ftiny/builds/189 Jan 30 18:50:42 build #184 of rb532/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/rb532%2Fgeneric/builds/184 Jan 30 18:51:00 build #184 of mpc85xx/p1020 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mpc85xx%2Fp1020/builds/184 Jan 30 18:51:15 CIFS 2+ supports encryption and whatnot AFAIK. Jan 30 18:51:27 I don't think that's useful on a router Jan 30 18:51:37 build #181 of imx6/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/imx6%2Fgeneric/builds/181 Jan 30 18:51:42 smbv1 is already not build for the kernel module, the code has support for it, but from what i have seen so far, the devs seem to concentrate mainly on smbv3 features. So by default i will enable only smbv2/3, also the main size comes from glib2 not cifsd Jan 30 18:51:55 build #170 of ipq40xx/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ipq40xx%2Fgeneric/builds/170 Jan 30 18:52:12 build #176 of lantiq/xway_legacy is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/lantiq%2Fxway_legacy/builds/176 Jan 30 18:52:29 build #213 of x86/geode is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2Fgeode/builds/213 Jan 30 18:52:44 Whoa, 995521 bytes locally Jan 30 18:52:47 build #213 of kirkwood/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/kirkwood%2Fgeneric/builds/213 Jan 30 18:53:02 * mangix investigates Jan 30 18:53:04 build #212 of ramips/rt288x is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Frt288x/builds/212 Jan 30 18:53:21 build #205 of brcm47xx/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm47xx%2Fgeneric/builds/205 Jan 30 18:53:38 build #212 of octeontx/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/octeontx%2Fgeneric/builds/212 Jan 30 18:53:55 build #212 of brcm63xx/generic is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm63xx%2Fgeneric/builds/212 Jan 30 18:54:09 build #178 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/layerscape%2Farmv8_64b/builds/178 Jan 30 18:54:11 build #207 of sunxi/cortexa53 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/sunxi%2Fcortexa53/builds/207 Jan 30 18:54:19 build #156 of oxnas/ox820 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/oxnas%2Fox820/builds/156 Jan 30 18:54:36 build #201 of lantiq/ase is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/lantiq%2Fase/builds/201 Jan 30 18:54:53 build #205 of x86/64 is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/x86%2F64/builds/205 Jan 30 18:55:09 build #203 of ar7/ac49x is complete: Failure [failed] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ar7%2Fac49x/builds/203 Jan 30 19:02:19 sorry for that Jan 30 19:06:43 here are some tunes for you http://cmg.streamguys1.com/hou1075/hou1075-sgplayer-aac Jan 30 19:09:29 build #208 of sunxi/cortexa53 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/sunxi%2Fcortexa53/builds/208 Jan 30 19:48:51 Hello :) Jan 30 19:53:32 hello! Jan 30 21:14:38 mangix: reverting works for me, I don't need valgrind with lto, just valgrind at all. Jan 30 21:15:01 (or at least, I thoughtt I did, but the app that was segfaulting on startup now... doesn't, I guess some musl updates or similar "fixed" it) Jan 30 21:17:08 andy2244: so, wrt nfs kernel server, have you had any luck actually serving nfs? it still can't share squashfs stuff can it? Jan 30 22:22:36 build #1236 of at91/legacy is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Flegacy/builds/1236 blamelist: Val Kulkov , Jeffery To , G?nther Kelleter , Sven Roederer , Mirko Parthey Jan 30 22:22:36 , Michal Hrusecky , Thorsten Glaser , David Santamar?a Rogado , Felix Fietkau , Jo-Philipp Wich Jan 31 01:20:44 build #469 of mvebu/cortexa9 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/mvebu%2Fcortexa9/builds/469 blamelist: Felix Fietkau Jan 31 01:20:47 build #1184 of ixp4xx/harddisk is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/ixp4xx%2Fharddisk/builds/1184 blamelist: Felix Fietkau Jan 31 01:20:50 build #352 of mediatek/mt7622 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/mediatek%2Fmt7622/builds/352 blamelist: Felix Fietkau Jan 31 01:20:52 build #1210 of cns3xxx/generic is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/cns3xxx%2Fgeneric/builds/1210 blamelist: Felix Fietkau **** ENDING LOGGING AT Thu Jan 31 02:59:57 2019