**** BEGIN LOGGING AT Mon Nov 23 02:59:57 2020 Nov 23 03:16:24 goliath: Oh hi, my plan is still to migrate over to your implementation Nov 23 07:43:53 aparcar[m]: AFAIK it was disabled by jow on the old server, but it seems to be running on the new server as https://firmware-selector.openwrt.org/?version=SNAPSHOT&id=tplink_archer-c7-v5 says 22.11.2020 Nov 23 07:46:20 aparcar[m]: ideally it should be moved to CI, or at least some locking implemented (this probably might as well go in to the cron job) Nov 23 08:07:12 aparcar[m]: that script is now running every 8 hours, which is probably bearable Nov 23 08:08:18 aparcar[m]: that CI approach would mean scraping of the json files over HTTPS which would probably cause more load on the server then the local file scraping Nov 23 08:23:02 aparcar[m]: http://sprunge.us/focA4Q doesn't looks that bad to me Nov 23 08:23:16 the new server simply rocks :) Nov 23 08:24:13 /home/mirror/downloads is 912G currently Nov 23 08:27:13 'morning! Nov 23 08:27:41 good midnight Nov 23 08:27:53 :) Nov 23 08:37:20 meurning Nov 23 08:38:10 jow: aparcar[m]: I assume, that it should be fine for some time with this command: flock -n /var/run/collect-py.flock ionice -c 3 nice -n 19 /usr/local/bin/collect.py /home/mirror/downloads 'https://downloads.openwrt.org/{base}/{target}' /opt/firmware-selector/www Nov 23 08:57:31 very polite collector script Nov 23 08:57:43 Tha ks ynezz for checking and the update Nov 23 09:28:58 rsalvaterra: (annnd dangole, we should certainly deal with jffs2 created by _older_ kernels of ours too! not just the kernel we are running! Nov 23 09:30:13 karlp: Rats. ¬_¬ Nov 23 09:30:35 I mean, how else is upgrade from older owrt versions meant to work? :) Nov 23 09:31:28 I thought files were backed-up at sysupgrade, the jffs2 partition was initialised, and the files were restored afterwards. Nov 23 09:32:06 But… yeah. If it's done this way, we're still using the old kernel. Nov 23 09:32:12 hrm, I didn't think so, because I thought I only saw the long init time delays at first install, not upgrades Nov 23 09:32:32 but I could very easily be wrong on that. Nov 23 09:33:20 karlp: on upgrade the tar file with configs is written as a new and only file of a new jffs2 system. Nov 23 09:33:56 However, that patch is a monstrosity. I'd love to put it out of its misery. Nov 23 09:33:58 It's put on the erase marker embedded last in squashfs sysupgrade image. Nov 23 09:39:24 ok, don't me then, dangole was right, only current kernel matters :) sorry for the noise rsalvaterra Nov 23 09:39:54 And (this is mostly to aparcar[m]) after sleeping on it, I think the squashfs zstd compression should be optional, since zstd's compression ratio is lower than xz's. People with small flash will most likely still prefer xz. Nov 23 09:42:36 Fast boot times are nice, but I wager normal users aren't rebooting their routers so often it makes a difference. Nov 23 09:44:48 rsalvaterra: ack Nov 23 09:52:45 My router just rebooted (short power outage) and it took about 7 minutes to get connected to it. That kinda sucks. Nov 23 09:54:14 PaulFertser: 7 minutes?! O_o Nov 23 09:54:44 My AirGrid M2 boots in around two minutes. With a 390 MHz 24Kc CPU. Nov 23 09:58:05 rsalvaterra: yes. It seems like netifd , jsonsh etc scripts are very slow. So ifup events for wan and br-lan take plenty of time. Nov 23 09:59:04 has anyone played with the ubiquiti bullet ac? or know anything about them? Nov 23 09:59:08 What hardware is that? Nov 23 09:59:28 rsalvaterra: dir-615-e4 , same thing I was trying zram on Nov 23 09:59:42 Oh…! Right. Nov 23 10:01:52 You have 4 MiB flash, so you're definitely compiling everything with -Os. That makes *a lot* of difference on MIPS, especially 24Kc. Nov 23 10:03:34 rsalvaterra: I have 16 MiB flash now. Nov 23 11:19:32 anyone can tell me how i can set the board config to 1.1? (swconfig -> dsa) Nov 23 11:19:49 somehow it didn't get updated although i'm using dsa Nov 23 11:27:29 nitroshift: just an -F would be sufficient afaik Nov 23 11:27:32 with sysupgrade Nov 23 11:27:54 Borromini, did that, seems it didn't have any effect Nov 23 11:35:08 oh :-/ Nov 23 11:37:55 nitroshift: what effect it should have? Nov 23 11:38:15 you need to setup DSA manually Nov 23 11:38:31 ynezz, when sysupgrading through luci, it doesn't perform the sysupgrade Nov 23 11:38:58 i'm actually running 5.9.10 atm Nov 23 11:39:19 switched to dsa since target got 5.4 support Nov 23 11:39:56 ynezz: it's a check to make sure people wipe configs from swconfig to dsa Nov 23 11:40:12 I still don't follow, what is wrong then? Nov 23 11:40:30 spolier: multiple lines Nov 23 11:40:32 sysupgrade -k -F openwrt-mvebu-cortexa9-linksys_wrt3200acm-squashfs-s Nov 23 11:40:33 ysupgrade.bin Nov 23 11:40:33 The device is supported, but the config is incompatible to the new image (1.0->1.1). Please upgrade without keeping config (sysupgrade -n). Nov 23 11:40:33 Config cannot be migrated from swconfig to DSA Nov 23 11:40:48 nitroshift: did you tick 'wipe config'? Nov 23 11:40:56 if you're using luci Nov 23 11:40:59 oh Nov 23 11:41:02 you need to use -n Nov 23 11:41:09 that's what that warning tells you. Nov 23 11:41:28 Borromini, when first moved to dsa i sysupgraded without keeping settings Nov 23 11:41:38 the check was implemented later. Nov 23 11:41:45 hence why you're bumping into it. Nov 23 11:41:46 i redid all configs after Nov 23 11:42:04 then you need to update the compat version manually Nov 23 11:42:14 wait a sec, I once wrote a manual somewhere Nov 23 11:42:32 adrianschmutzler, that's what i was looking for Nov 23 11:42:35 adrianschmutzler: /etc/board.json? Nov 23 11:42:46 nitroshift: it's in there ^^ Nov 23 11:42:51 and i think you can just edit it Nov 23 11:43:02 compat_version Nov 23 11:43:05 no, you need to change the uci setting in /etc/config/system Nov 23 11:43:08 Hmm… I'm having the exact same problem, so I'm interested in this. All my master builds since a few days ago complain about DSA on sysupgrade. Nov 23 11:43:10 Borromini, i have 2 identical devices, the other one doesn't complain Nov 23 11:43:25 https://openwrt.org/docs/guide-user/installation/generic.sysupgrade#forcing_upgrade Nov 23 11:43:55 the uci config is generated from the board.json. But once you have the uci config, the board.json is not looked at anymore Nov 23 11:44:30 so uci set system.@system[0].compat_version="1.1" Nov 23 11:44:58 heh... compat_version in board.json *is* 1.1 Nov 23 11:45:09 * nitroshift scratches hos head Nov 23 11:45:12 *his Nov 23 11:45:33 but in /etc/config/system as well? Nov 23 11:46:32 * Borromini has no compat_version in /etc/config/system Nov 23 11:46:40 adrianschmutzler, there's nothing there about compat_version Nov 23 11:46:46 oh nevermind me, i do. Nov 23 11:47:03 was grepping for the wrong keys Nov 23 11:47:13 nitroshift: obviously not, because /etc/config/system has been created before the update. Nov 23 11:47:23 and once you add it there, it will work. Nov 23 11:47:32 right, then there's the fault Nov 23 11:47:43 shoud i add it under system paragraph? Nov 23 11:47:56 Yes, or just run the command as stated Nov 23 11:49:05 ran the command, still nothing in /etc/config/system Nov 23 11:49:17 you also need uci commit system after that Nov 23 11:49:26 as in the article I linked Nov 23 11:50:03 adrianschmutzler, thanks, skipped that part, obviously not enough coffee :| Nov 23 11:50:31 it's there now Nov 23 11:50:33 thanks! Nov 23 11:50:51 And from now on it should just work Nov 23 11:50:57 yep Nov 23 11:51:54 thanks again Nov 23 12:09:27 * russell-- cracked case on a ubnt unifi ac mesh, aka uap-ac-pico Nov 23 15:22:35 The more I read about jffs2, the more perplexed I get. Now I was wondering why it doesn't just use the crypto API for compression, like all good citizens… Nov 23 15:22:58 … turns out, someone actually started implementing it: http://www.inf.u-szeged.hu/projectdirs/jffs2/compression.php Nov 23 15:23:10 *15 years ago*. Nov 23 15:23:59 Nobody cared, I guess. Nov 23 15:30:14 rsalvaterra: did that api exist then? Nov 23 15:31:06 karlp: If the patch exists, I assume the answer is "yes". Nov 23 15:31:55 https://lwn.net/Articles/13587/ Nov 23 15:32:06 We're talking Linux *2.5*. Nov 23 15:33:41 30th October 2002. It's old enough to drive a car. Nov 23 15:41:13 pretty sure crypto of jffs partitions wasn't exactly a roadmap item for jffs implementors, at all, let alone using brand new kernel features... Nov 23 15:41:25 jow: I've got some luci controller actions() like https://paste.jvnv.net/view/nWNOs that return json blobs directly, what's the right way of putting them into a menu.d json file? Nov 23 15:42:20 I've made as a "view" and it gets called, but just returing the raw json doesn't make things happy, it just renders a blank inside the normal luci page: https://paste.jvnv.net/view/FlVEG Nov 23 15:43:07 is there some other "type" I can put in the action, or some overrides I can call or some other trick? Nov 23 15:44:07 the view wrapper always does this ui.instantiateView(path) thing Nov 23 15:46:51 template requires it to be a .htm file as well. Nov 23 15:51:06 karlp: I'm not talking about data encryption. The Linux crypto API is used for all kinds of data transformation, encryption and compression being two examples. Nov 23 15:51:23 was it used for compression _then_ ? or just reused for that later? Nov 23 15:51:43 it doesn't surprise me _at all_ that someone making a novel out of tree filesystem wasn't using brand new crypto api :) Nov 23 15:55:33 karlp: Yes, it was. In 2005, deflate was already implemented as a crypto API algorithm. Nov 23 15:59:04 wellll, if jffs2 was added to the kernel in 2.4.10, wasn't it the failing of the crypto api to not update the jffs2 compression layer? :) Nov 23 16:04:15 karlp: In my opinion, I don't think so. Nothing was removed, just added, so all previous users still work, albeit with lots of (nowadays) unnecessary boilerplate. Nov 23 16:10:27 (And without the benefit of getting new algorithms "for free", when they're added to the crypto API.) Nov 23 16:51:04 jow: just dropping the menu.d for now, I've converted my cbi to js view, but leaving the controller for dispatching for now, if there's a new path intended for the future, I'll try and move to it. Nov 23 16:51:49 do I still need an rcp.d/acl.d file if I'm not using menu.d files? Nov 23 17:05:45 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.1% images and 98.5% packages reproducible in our current test framework.) Nov 23 22:08:51 adrianschmutzler: you have previously reviewed https://github.com/openwrt/openwrt/pull/3380 - your comments have been addressed so it would be great if you could put this on your TODO-list and merge this PR if you agree that everything is fine now. thank you! Nov 24 00:55:55 downloads.openwrt.org down Nov 24 00:55:57 ?! Nov 24 00:58:06 yes Nov 24 01:18:17 build #216 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsam9x/builds/216 **** ENDING LOGGING AT Tue Nov 24 02:59:57 2020