**** BEGIN LOGGING AT Mon Sep 21 08:50:38 2020 Sep 21 08:55:07 Borromini: PRs welcome *duck* Sep 21 08:55:24 mangix: do you mind I create a few PRs? http://sprunge.us/ahWSkU Sep 21 08:55:50 go ahead Sep 21 08:56:30 please do bear in mind that for sane projects, major version changes might not be compatible with people, so if you don't use or know a project, be cautious making major version bumps... Sep 21 08:56:59 for less sane projects, even minor versions might be ground breaking changes, so they mgiht compile, but that might be all Sep 21 09:00:34 karlp: I don't intent do force push all this stuff, I'd create a script that generate pull requests and checks them via a CI, if they pass the maintainer can check them Sep 21 09:00:49 aparcar[m]: :D. It definitely was in there, afaik. Sep 21 09:02:35 it's exhausing sometimes convincing people that latest versions aren't always improvements. Sep 21 09:03:15 karlp: some of these versions have CVEs, should these be updated? Sep 21 09:04:10 we could add a makefile option like "PKG_AUTOBUMPS" which let's the bot know the maintainer wants them to be created. However that might be the wrong place Sep 21 09:08:18 looks like plenty of the stuff in packages is not using a numbering prefix for their uci defaults files... Sep 21 09:10:46 Borromini: yeah, numbering came up after there were conflicts and ordering problems once, a while ago Sep 21 09:10:57 anything that predated that never got changed, and for many packages, they don't care. Sep 21 09:11:03 karlp: yeah i found out the hard way the past week. Sep 21 09:11:35 aparcar[m]: cve's IMO shouldn't be blindly treated as important and automatically patched either :) Sep 21 09:11:49 my uci script was getting run, i could see that through the markers it set, but odhcpd's isn't numbered so it just overwrote my custom settings. i sent in a patch :) Sep 21 09:12:06 yeah, odhcpd is fabulous in many things. Sep 21 09:12:17 karlp: again, nothing is about auto bumping. it's just a convenience for maintainer Sep 21 09:12:20 karlp: how so? Sep 21 09:12:39 i just switched to it for DHCP v4 and v6. Sep 21 09:13:18 aparcar[m]: well, you might not consider it autobumping, but there's a bunch of autobumping by hand that gets done... Sep 21 09:16:42 most casual maintainers will simply accept auto-bump prs without testing Sep 21 09:17:00 if they'd have the time to test they would have updates themselves already Sep 21 09:17:07 *updated Sep 21 09:17:29 I'd be surprised by any different outcome Sep 21 09:18:07 so I fear it will result in a lot of churn Sep 21 09:21:04 jow: okay I just enable the bot for the two packages I maintain Sep 21 09:22:57 I guess with more automated runtests it could be quite safe. but not really sure Sep 21 09:23:27 automated tests tend to cover regressions retroactively Sep 21 09:23:51 the next regression will be a yet unknown with a high probability Sep 21 09:27:56 is that normal / expected that for a simple GET request browsers ignore Access-Control-Allow-Methods ? Sep 21 09:27:59 so we rely on maintainers that update and fully test their stuff Sep 21 09:28:00 uhttpd ubus sends Access-Control-Allow-Methods: POST, OPTIONS **** BEGIN LOGGING AT Mon Sep 21 09:30:01 2020 Sep 21 09:30:05 rmilecki: apparently it is by design Sep 21 09:30:18 the entire CORS spec is a freakzoo **** BEGIN LOGGING AT Mon Sep 21 09:32:16 2020 Sep 21 09:32:17 yes, because the api is misdesigned Sep 21 09:32:27 BuT ApPs OnlY UsEW CoRrEcT HtTp MetHoD VeRbs?!! Sep 21 09:32:27 GET / HEAD etc. requests should not modify state Sep 21 09:32:41 it's stupid.... i know RESTful is so cool, but so many pages use GET for actions Sep 21 09:32:51 all those pages are wrong!!!!11 Sep 21 09:32:51 rmilecki: well, yeah... Sep 21 09:33:07 not all webs ervers support all the verbs anyway... Sep 21 09:33:23 there's other webservers than nginx? Sep 21 09:33:23 so it was never going to be a happy logical world. Sep 21 09:33:26 do we even have anything like ??? Sep 21 09:33:47 jow: well, I had to patch DELETE or something in uhttpd a few years ago I think :) Sep 21 09:34:11 rmilecki: no, but we have a Sep 21 09:35:16 actually, no, it was adding headers to allow indicating that DELETE/PATCH/PUT were requested, even though not supported. https://git.openwrt.org/?p=project/uhttpd.git;a=commit;h=f91788b809d9726126e9cf4384fedbbb0c5b8a73 Sep 21 09:35:24 does uhttpd support put/patch/delete now? Sep 21 09:35:42 ah yes: https://git.openwrt.org/?p=project/uhttpd.git;a=commit;h=30a18cb4bfd8c9997e40d9cd9c8562a751d61ecf Sep 21 09:36:21 committteesss hey. Sep 21 09:36:29 ? Sep 21 09:36:32 or should I say "workign groups" Sep 21 09:36:46 I'm out, thanks for the thoughts on autobumps Sep 21 09:36:47 making up these complicated specs with different world views and expectations Sep 21 09:41:06 indeed Sep 21 09:55:08 Any chance somebody could review https://github.com/openwrt/openwrt/pull/3434/commits/c81f0f097b57c9d5f4c6da6a6d1e9fcdafac82e1 adds a density_level configuration option to set data rates for hostapd **** BEGIN LOGGING AT Mon Sep 21 10:03:23 2020 **** BEGIN LOGGING AT Mon Sep 21 10:18:10 2020 **** BEGIN LOGGING AT Mon Sep 21 10:30:36 2020 **** BEGIN LOGGING AT Mon Sep 21 11:13:41 2020 Sep 21 11:25:39 Hello, yesterday I played with a Mikrotik RB750Gr3, and long story short adding "earlyprintk" to the cmdline make the boot successfull Sep 21 11:25:43 => https://bugs.openwrt.org/index.php?do=details&task_id=3354 Sep 21 11:26:11 Anybody has more ideas what I could test ? Sep 21 11:44:21 champtar: probably timing-related problem? earlyprintk would add some delays to kernel bootup. You can probably experiment with additional "debuglevel=1" or something like that to see if that affects the boot. Sep 21 11:50:17 debuglevel=1 on the cmdline ? Sep 21 11:53:08 champtar: yeah, my idea is to change the quantity of messages going to serial via earlyprintk. Sep 21 11:53:55 loglevel=1 then ? Sep 21 11:53:58 https://www.kernel.org/doc/html/v5.4/admin-guide/kernel-parameters.html Sep 21 11:54:34 or loglevel=7 to have lots of logs Sep 21 11:54:56 champtar: yes, that's what I meant, I was reading that document right atm to tell the exact parameter name. Sep 21 11:55:14 But you were faster Sep 21 11:56:12 My idea is that it might probably confirm or falsify the idea that boot problem is timing-dependent. Sep 21 11:57:05 I understand. I'll will start with loglevel=7, then loglevel=1 Sep 21 12:02:46 CORS is so stupid! Sep 21 12:02:52 fetch('http://192.168.0.1:8008/ubus/list', { headers: new Headers({ 'Foo': 'Bar' }) }) results in preflight - browser sends OPTIONS with Access-Control-Request-Method: GET Sep 21 12:02:53 my uhttpd server replies with Access-Control-Allow-Methods: POST, OPTIONS but browser does not care - it proceeds with sending GET request Sep 21 12:03:24 it seems all the browser cares about is Access-Control-Allow-Origin in the OPTIONS reply Sep 21 12:04:44 is that also by design?! Sep 21 12:05:15 Maybe GET is always allowed because "legacy" Sep 21 12:05:43 so what's the point of sending OPTIONS in the first place? Sep 21 12:06:29 to have the Access-Control-Allow-Origin ? Sep 21 12:17:43 hm, I had an email about mt7623n_preloader licence Sep 21 12:17:45 can't find it **** BEGIN LOGGING AT Mon Sep 21 12:56:36 2020 Sep 21 13:13:34 interesting, datasheet for gd25lq80 says 4k sector size, but I'm not seeing any chip definitions in drivers/mtd/spi-nor/ with 4k sector size Sep 21 13:14:16 could it be sector_size is actually block size? **** BEGIN LOGGING AT Mon Sep 21 13:41:48 2020 Sep 21 13:56:34 https://fetch.spec.whatwg.org/ "If request’s method is not in methods, request’s method is not a CORS-safelisted method, and request’s credentials mode is "include" or methods does not contain `*`, then return a network error." Sep 21 13:56:36 so browser has to check if fetch() requested method is in Access-Control-Allow-Methods BUT it doesn't care after all for GET, HEAD and POST Sep 21 13:59:02 even POST ?? Sep 21 14:00:04 Is the JS loaded from the same host you are trying to query ? Sep 21 14:07:35 PaulFertser: maybe more a padding/alignment issue, adding loglevel=1 or loglevel=7 or testtestte make the images work Sep 21 14:11:07 champtar: loglevel without earlyprintk? Sep 21 14:13:16 i have a theory Sep 21 14:13:45 it's possible lzma-loader's current handling (read: hack) of kernel cmdline may be the cause of this problem Sep 21 14:14:11 as far as mikrotik devices are concerned I wish we'd get rid of lzma-loader already Sep 21 14:16:44 f00b4r0: so do you suggest to just pad the kernel command line with spaces for test? Sep 21 14:17:16 What would be the alternative to using lzma-loader? Is mikrotik's bootloader sane enough? Sep 21 14:17:38 PaulFertser: the booloader can load ELF binaries. The problem is that it doesn't deal with DTS Sep 21 14:17:58 champtar: yeah, it seems it happens even for POST Sep 21 14:18:26 champtar: i use http://192.168.0.1:80/ vs. http://192.168.0.1:8008/ which are considered two different domains Sep 21 14:19:07 I've been meaning to tackle this problem but real-life events have gotten in the way of my getting enough time to do this ;P **** BEGIN LOGGING AT Mon Sep 21 14:22:31 2020 Sep 21 15:08:55 PaulFertser: yes loglevel=X without earlyprintk **** BEGIN LOGGING AT Mon Sep 21 16:04:39 2020 **** BEGIN LOGGING AT Mon Sep 21 16:52:29 2020 Sep 21 18:13:02 if after booting, I do not get "Please press Enter to activate this console." what could cause this? Sep 21 18:13:41 I can enter failsafe and get a working console, but if I skip failsafe I never get that prompt Sep 21 18:21:16 its stuck installing a kmod Sep 21 18:21:29 try entering failsafe, rm /lib/modules and reboot Sep 21 18:21:36 or /etc/modules.d Sep 21 18:22:07 blogic: thanks Sep 21 18:22:16 problem is this is initramfs Sep 21 18:22:30 then build an initramfs without kmods Sep 21 18:22:38 or dont install kmodloader Sep 21 18:22:43 see if is the cause Sep 21 18:22:47 I will try that, thanks Sep 21 18:23:32 I could disable kmodloader in package/base-files/files/etc/init.d/boot maybe ? Sep 21 18:23:36 * stintel tries Sep 21 18:23:47 its also called in preinit Sep 21 18:23:57 it gets called twice Sep 21 18:24:09 for early boot insmod and then later post pre-init Sep 21 18:24:31 ok I remove it from ubox Sep 21 18:26:00 this device is terrible to hack :P requires level shifter to be soldered on the board, 4 pads to be bridged, uses EFI stub kernel on mvebu, rsa signed factory images, u-boot without saveenv, what else am I forgetting Sep 21 18:27:35 blogic: since ipq807x uses efi stub kernel, maybe you can answer this: if I would enable efi stub for mvebu, will this break existing images? or is there some magic that the efi stub stuff will be ignored Sep 21 18:27:51 no idea Sep 21 18:28:07 the efi stubs dont get installed by owrt Sep 21 18:28:26 the problem is that there is only 1 kernel image generated Sep 21 18:28:29 they are already there in the highky insane board/part setup that the master crafted Sep 21 18:28:54 so if you enable efistub/efi_armstub, that stuff *is* added to the kernel image Sep 21 18:29:12 right, off to bed, good luck with the mvebu unit Sep 21 18:29:22 blogic: thanks and good night :) Sep 21 18:38:17 hah looks like it's just missing ttyMV0 in /etc/inittab Sep 21 18:38:29 then I wonder if this actually works on any of the mvebu boarsd Sep 21 18:57:38 should have askconsole Sep 21 18:57:54 and that will only work if console= is passed in kcmdline Sep 21 18:58:03 cat /proc/cmdline Sep 21 18:58:19 inittab should always use askconsole Sep 21 18:58:29 ::askconsole: Sep 21 19:00:15 aha, and there is no cmdline Sep 21 19:00:28 then patch your dts to have one Sep 21 19:04:09 interesting though that most dts in mvebu target don't have this Sep 21 19:06:33 ah maybe there it is set in the u-boot env Sep 21 19:29:25 f00b4r0: this make the image work 'CONFIG_CMDLINE="rootfstype=squashfs,jffs2 "' Sep 21 19:30:32 champtar: thanks. When I have a bit more time on my hand i'll take another look at lzma-loader's code. I'm now convinced it's the cmdline/stack setup there that's causing this bug. Sep 21 19:31:38 ready to test ;) Sep 21 19:33:06 if I'm not on IRC (I'm not often here) don't hesitate to email me, I also watch the dev ML Sep 21 19:33:15 ok thx Sep 21 20:48:10 ynezz: ping **** BEGIN LOGGING AT Mon Sep 21 20:55:53 2020 Sep 21 21:10:50 this new rtl838x is missing on the snapshots but appears in dump-target-info.pl, is it broken? Sep 21 21:12:55 it's source-only IIRC Sep 21 21:13:35 but I'm probably not knowledgable about the build system to understand your statement :P Sep 21 21:14:05 svanheule: looking at the code I don't find it as source-only Sep 21 21:14:50 FEATURES:=ramdisk squashfs Sep 21 21:15:28 I think I remember blogic saying it would be added as source-only, in order not to break the builds Sep 21 21:16:59 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Sep 21 21:36:05 just guessing, but to my knowledge the buildbots have to be restarted to notice new targets (or forget about dropped ones), this might not have happened yet **** BEGIN LOGGING AT Mon Sep 21 21:44:19 2020 Sep 21 21:48:48 pkgadd: very good point Sep 21 21:49:07 ynezz: jow please restart the buildbots to spin up rtl838x target **** BEGIN LOGGING AT Mon Sep 21 22:55:00 2020 **** BEGIN LOGGING AT Mon Sep 21 22:59:08 2020 Sep 21 23:16:40 hmm... I wonder why with latest master dnssec does not seem to work, with wull dnsmasq compiled.. and enabled.. tried all sorts of things but no ad flag Sep 21 23:23:09 also tcpudp allowed on wan to port 53, if bears any meaning Sep 21 23:42:03 aparcar[m]: no json version of the uscan page Sep 21 23:42:22 swalker: mind adding what :)? Sep 21 23:43:02 I used BeautifulSoup4 to parse the website which works fine, but that's ugly for both ends Sep 21 23:47:27 no ad bit with computers on lan, nor directly within openwrt when pointed to local openwrt resolver, but does so when pointed directly to say 1.1.1.1 **** BEGIN LOGGING AT Tue Sep 22 00:01:28 2020 **** BEGIN LOGGING AT Tue Sep 22 00:20:48 2020 **** BEGIN LOGGING AT Tue Sep 22 00:37:19 2020 **** BEGIN LOGGING AT Tue Sep 22 00:55:52 2020 **** BEGIN LOGGING AT Tue Sep 22 00:59:03 2020 **** BEGIN LOGGING AT Tue Sep 22 02:54:17 2020 **** ENDING LOGGING AT Tue Sep 22 02:59:57 2020