**** BEGIN LOGGING AT Fri Jan 15 02:59:57 2021 Jan 15 04:51:23 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.) Jan 15 08:11:09 any opkg wizzard around? Jan 15 08:11:35 I would like to provide simple command for dnsmasq upgrade Jan 15 08:12:08 it should be copy&paste stuff, something like `opkg update; opkg upgrade dnsmasq` Jan 15 08:12:40 but dnsmasq has 3 variants: dnsmasq, dnsmasq-full and dnsmasq-dhcpv6 Jan 15 08:12:47 how to handle this case? Jan 15 08:15:38 I wanted to use `opkg list-upgradable` with some grep/sed foo, but it OOMs here :p Jan 15 08:17:36 aparcar[m]: pong Jan 15 08:23:27 ynezz: you probably want to do an opkg list-installed to determine which dnsmaq package is installed first, no? Jan 15 08:24:16 that said, list-upgradable should show you what you have installed. Jan 15 08:24:34 if it ain't installed, it ain't upgradeable :) Jan 15 08:27:36 yeah, but this is quite long: opkg update; opkg upgrade $(opkg list-installed | sed -n '/dnsmasq/ s/\([a-z]*\) - .*/\1/p') Jan 15 08:27:52 rsalvaterra: are you sure the kernel things adds 24kb alone? I though in combination with ip-full Jan 15 08:28:23 d'oh, I can't even run that upgrade Jan 15 08:28:43 `opkg upgrade dnsmasq` OOMs Jan 15 08:29:03 Out of memory: Killed process 3468 (opkg) total-vm:53736kB, anon-rss:52688kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:136kB oom_score_adj:0 Jan 15 08:29:16 opkg still produces ooms? Jan 15 08:29:21 this is x86/64 under qemu with 128MB RAM Jan 15 08:30:05 aparcar[m]: It's the total image, no the kernel, sorry. It's written in the commit it fixes, though "Increases imagesize by 24.125 KiB.". Jan 15 08:30:55 Anyway, it's quite perplexing to enable a feature like that, without even giving the chance to disable it. Jan 15 08:35:22 I know it's only enabled by default for the targets which specify the small_flash feature, but that means anything with > 4 MiB of flash. 24 kiB on an 8 MiB device is a non-negligible amount of space, imho. Jan 15 08:37:04 *which don't specify Jan 15 08:38:59 rsalvaterra: okay I added your patch thank you Jan 15 08:39:17 aparcar[m]: No, I thank you! :) Jan 15 10:06:55 ynezz: not ooming for me on ath79 Jan 15 11:28:16 have anyone thought of using json for UCI to store config files? Jan 15 11:29:51 uhhh plz no Jan 15 11:31:05 :P Jan 15 11:31:09 Arrrrgh Jan 15 11:37:57 :) why not? what are the cons? Jan 15 11:39:02 xml! Jan 15 11:39:16 * ynezz hides Jan 15 11:40:07 cmon, xml is not for humans :) Jan 15 11:41:18 but uci is Jan 15 11:42:27 you mean basically ini format which uci currently uses Jan 15 11:44:09 it has 2 level limitation which is preventing it to be used with more complex things requiring more levels Jan 15 11:44:30 and json is human readable too Jan 15 11:44:38 so, why not? Jan 15 11:44:58 it's human readable but hardly writeable Jan 15 11:45:27 it's very error prone. there are people who edit those files manually instead of using uci set foo or luci Jan 15 11:46:43 now if there would be a cisco/huawei/... style cli with full command tab-completion, I wouldn't care Jan 15 11:47:51 if its not broken then dont fix it? besides no matter what format, its internal and you should use uci to edit config. also if you add support for more complexity to the format then uci needs to support that and that makes uci more complex, is there a need for more levels on complexity? Jan 15 11:48:34 using uci to edit config is simply not user friendly enough Jan 15 11:48:38 hence I edit my config files manually Jan 15 11:48:41 I'm sure I'm not the only one Jan 15 11:48:57 indeed not :) Jan 15 11:49:08 changing the config format is hardly a solution to that challenge Jan 15 11:50:08 anyway i guess for the audience that doesnt like uci theres luci Jan 15 11:50:25 I'm not the one suggesting it. I'm *against* it, as it would make manually editing config files even harder Jan 15 11:51:10 yes but youre assuming that you would still be manually editting it. gives me the impression that you just like manually editing configs Jan 15 11:51:40 editing config files is easier than uci set blah or using luci Jan 15 11:51:45 maybe in that case an idea to by-pass to unified config interface all together Jan 15 11:51:53 or do you know all uci keys by heart ? Jan 15 11:51:56 I for sure don't Jan 15 11:52:13 uci --help? Jan 15 11:54:17 I was talking about the things returned from "uci show" Jan 15 11:55:42 just simple key value pairs, but i rest my case. we have different view but they lead to the same conclusion Jan 15 11:59:29 yeah, very simple. with sometimes @, sometimes not, foo[n], etc. totally not user friendly. editing files is much easier. it's also the file format that is usually documented, not the uci keys Jan 15 12:00:48 uci commands can be a b*tch to figure out Jan 15 12:00:56 named, unnamed sections, ... Jan 15 12:01:11 i admit that Jan 15 12:01:25 but the config format is not at issue here Jan 15 12:02:54 IMO uci as such is very good and needed abstraction but it's current limitations are preventing OpenWrt to become a more serious product, which it has a potential for Jan 15 12:03:39 like a modern NOS would require FRR, which has pretty complex configuration but can be represented in json Jan 15 12:03:49 it might help of you give us a tangible problem statement and a solution to your multi level idea Jan 15 12:03:59 not just "it doesnt support multi-level" Jan 15 12:04:18 converting FRR config into current uci format is a nightmare and clurrer Jan 15 12:04:32 ie where do you need multi level and how would using json solve it in a proof of concept Jan 15 12:05:36 if youre convinced of your case then i guess send a [RFC PATCH] Jan 15 12:09:21 would be a huge undertaking to change this tree-wide Jan 15 12:10:16 might need compatibility for a transition Jan 15 12:10:45 if this is something we even want to consider, I think it should be something new, keep uci as is, let the user decide what he uses Jan 15 12:10:53 and if ever good enough, switch default Jan 15 12:11:14 yeah, for transition I was thinking that it could read old uci and save to json and if json exists it prefers json Jan 15 12:38:42 is somebody working on "lantiq/Easybox 904 xDSL" ? i saw this in some commit messages as "run tested" however this box isnt supported in mainline openwrt and the pull requests for that box are old & closed Jan 15 12:40:12 last commit w. that box in build & run tested was 667f6c7f49c94213ca43a42ad5a9e23abfd81861 (Kernel 5.4.77 bump) Jan 15 15:34:44 what's preventing multiple tabs from being used to make further levels in uci? Jan 15 15:35:01 other than that tabs/spaces differentiation is a horrifying abomination? Jan 15 15:35:20 err s/uci/file-based config storage/ Jan 15 16:03:37 hurricos, what are you talking about? uci is section.option style config, tabs/spaces don't mean anything Jan 15 19:07:16 20 more commits untils 50k Jan 15 19:15:04 adrianschmutzler: ping Jan 15 19:26:01 rsalvaterra: pong Jan 15 19:26:58 Anything blocking my x86 dead code and data elimination patch? Jan 15 19:27:08 I don't do x86 ... Jan 15 19:27:15 It's 200 kB For Free™… Jan 15 19:27:19 It's too different from the rest Jan 15 19:27:25 Unless it's really trivial Jan 15 19:27:33 Ah, right. Jan 15 19:27:49 Who's the x86 boss, then? :) Jan 15 19:28:49 well, I don't think anybody cares about size on x86 Jan 15 19:28:58 so, probably they have better things to do ..... Jan 15 19:29:24 That's something that strikes me as really odd. I care about size *everywhere*… :/ Jan 15 19:29:30 It's a matter of efficiency, to me. Jan 15 19:29:45 But whatever… Jan 15 19:30:02 well, it's also a matter of efficiency where a reviewer will invest time in when there is more to review than time Jan 15 19:30:14 but I'm just guessing ... Jan 15 19:30:26 I won't review/merge it because it's x86 ... Jan 15 19:31:11 Sure, I just wanted to know if I needed to fix anything more. Thanks, anyway. :) Jan 15 19:35:52 rsalvaterra: which patch? also x86 has various container-foo options enabled which requires size, it doesn't make sense to me hunting down single kBs Jan 15 19:36:56 aparcar[m]: this isn't "single kB"… https://patchwork.ozlabs.org/project/openwrt/patch/20210105000926.1729424-1-rsalvaterra@gmail.com/ Jan 15 19:42:02 rsalvaterra: does that patch work for other targets too? Jan 15 19:43:13 ARM (not 64, mind you) POWER and MIPS already have similar patches. Mine applies to x86 and x86-64. Jan 15 19:43:54 ¯\_(ツ)_/¯ Jan 15 19:44:12 I can compile and run check it, not that I actually understand what it does... not sure if that's of much help Jan 15 19:45:27 Well, I just mark the unreferenced sections which mustn't be garbage-collected and specify the architecture supports dead code and data elimination. The kernel build system does the rest. :) Jan 15 19:46:30 Anyway, don't worry about it, I'll just wait for a x86 specialist to curse at me. :P Jan 15 19:49:00 fair enough Jan 15 19:49:43 rsalvaterra: you could look at https://github.com/openwrt/openwrt/pull/2916 and see if the compression works better than our squashfs fork Jan 15 19:51:01 aparcar[m]: Oh, that looks nice! Jan 15 19:51:32 try it in a vm currently it bricks the book Jan 15 19:51:34 *boot Jan 15 19:53:38 Hmm… The image.mk options changed quite a bit. Jan 15 20:16:24 rsalvaterra: keep me posted Jan 15 21:38:36 hmm Jan 15 21:38:44 so what's the advantage of squashtools-ng? Jan 15 21:43:45 mangix: probably it's maintained, whereas squashfskit isn't…? Jan 15 22:18:43 mangix: squashfs-tools wasn't maintained for a while, patches piled up on upstream so lynxis forked it at some point, e.g. to have reproducible images. Eventually the maintainer did things but OpenWrt is still on the (now outdated) fork Jan 15 22:19:45 squashfs-tools is the initial implentation, squashfskit is lynxis fork and squashfs-tools-ng is the proposed reimplementation Jan 15 22:20:41 aparcar[m]: what's the advantage? Jan 15 22:21:23 can lynxis fork be backported to upstream? Jan 15 22:21:57 mangix: we could try to change just back to the upstream Jan 15 22:22:10 or use squashfs-kit Jan 15 22:30:23 a switch to upstream is fine for me too, however it lacks still multiple patches which are used in tree Jan 15 22:31:02 the dev of -ng was very helpful in reacting and fixing things, so that'd be a plus Jan 15 22:32:00 seems like upstream got some traction lately, I'm open to any of the three solutions Jan 15 22:33:32 mangix: can you give me an example on how to test your libusb patch? I guess I should try something with usbmode? **** BEGIN LOGGING AT Fri Jan 15 23:21:53 2021 Jan 16 00:51:00 aparcar[m]: usbutils is better Jan 16 00:51:04 just run lsusb **** ENDING LOGGING AT Sat Jan 16 03:00:36 2021