**** BEGIN LOGGING AT Fri May 21 02:59:56 2021 May 21 06:23:14 aparcar[m]: ping May 21 07:00:40 pong May 21 07:42:56 hopefully i wont be the only one playing May 21 08:30:10 https://blog.scaleway.com/scaleway-and-chia/ May 21 08:30:13 this is depressing May 21 08:34:17 yeah - all this computer power and energy efficiency compared to 90s&2000s and now rebound effects and strange economics w. blockchain "tech" May 21 08:38:14 zorun: I can't fathom how in hell someone (actually, not just "someone", Bram Cohen) could create a proof-of-space-based cryptocurrency without thinking of the consequences. May 21 08:39:16 "Oh, but it was supposed to run on the unused storage space of your device". Really?! May 21 08:40:34 this alt coin crazy is quite crazy May 21 08:40:39 that being said May 21 08:40:45 To the moon! May 21 08:41:49 craze* May 21 08:42:58 philipp64: pong May 21 08:47:09 i mean those "exabytes" of chia storage only contain "random" nonsense information dont they ? May 21 08:48:41 "blockchain" with "proof of internet connection speed" side effects might be more interesting May 21 08:50:06 ldir: The /etc/udhcpc.user.d and /etc/odhcp6c.user.d directories are a recent change. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=467c32600cc575fcb67c5f01ad32e02141220ceb May 21 08:54:19 proof of proof of work May 21 09:09:29 can someone tell me if we really need network aliases (option ifname @foo) now that we have "device" sections? May 21 09:14:33 maybe define some "use case" where it makes sense - and some writeup why / why not like https://www.kernel.org/doc/Documentation/networking/alias.txt May 21 09:15:34 naming , use-case, "correct" use case / legacy compatibility May 21 09:17:13 I understand the need for aliases back in times when we didn't have "config device" UCI sections May 21 09:17:39 some devices (e.g. bridges) were defined in "config interface" (e.g. option type bridge) May 21 09:17:57 so to reference such indirectly defined devices we needed aliases May 21 09:18:06 that case is gone May 21 09:18:16 i'm not aware of others May 21 09:18:21 nbd jow ? May 21 09:22:54 plntyk: I've pushed your grub2 liblzma tweak - let's see what falls out :-) May 21 09:24:20 plntyk: oh, it's interestig to see kernel had similar aliases and they got deprecated May 21 09:29:55 that alias think came up in ongoing search for testing / playing around with multiple ips / dhcp requests / fixed ip mixing and issues with "outgoing" ip addresses May 21 09:30:25 like when avahi or other daemons advertise global routable ips etc. May 21 09:30:45 or how "buggy" services bind to "wrong" ips May 21 09:41:23 rmilecki: when you want to define more complex device stacks on top of wireless interfaces May 21 09:42:43 nbd: what do you think about having actually two options then: "device" for specifying "config device" and "ifname" for referencing "config interface" using @foo May 21 09:43:09 nbd: "@foo" syntax will have to stay, as "foo" will be treated as device reference for backward compatibility May 21 09:43:30 we don't actually need the 'config alias' support anymore May 21 09:43:37 but users would be expected to migrate from "option ifname " to "option device " May 21 09:43:41 since @foo replaces it May 21 09:43:50 oh, there is "config alias"? May 21 09:44:00 yes, old legacy stuff May 21 09:44:04 not sure if anybody uses it anymore May 21 09:44:39 should I care to add uci-defaults migrating that "config alias" and drop it from netifd? May 21 09:44:51 i think using ifname to specify interfaces is a bad idea May 21 09:44:56 since we used it for something else before May 21 09:45:06 that's basically guaranteed to cause maximum user confusion May 21 09:45:40 i'm not going to change "option ifname @foo" May 21 09:46:07 this is what is already supported May 21 09:47:21 now we have: "option ifname foo" for referencing "foo" device" AND "option ifname @foo" for referencing "foo" interface May 21 09:47:23 i want to have: "option device foo" for referencing "foo" device" AND "option ifname @foo" for referencing "foo" interface May 21 09:47:48 (i'll also leave old syntax support for backward comp) May 21 09:49:21 splitting it up in this way doesn't really make much sense to me May 21 09:49:34 the @ syntax refers to the device of an interface May 21 09:49:38 it can be used even for vlans May 21 09:49:40 like @foo.1 May 21 09:49:47 for vlan 1 on the device of interface foo May 21 09:49:58 hm May 21 09:50:04 maybe you're right May 21 09:50:08 i got fixed on another view May 21 09:50:31 it still about referencing device after all, just with an interface on the way May 21 09:50:49 ok, there no need to make it overcomplicated like i planned to May 21 09:50:50 thanks May 21 10:29:09 * ldir has discovered ddns-scripts can cope with his desired config, you just can produce that config from the luci gui. May 21 10:29:21 can't produce May 21 10:38:32 ldir: I had trouble with UCI itself, let alone LuCIā€¦ May 21 10:39:51 rsalvaterra: I can't help it if you're just being weird/difficult :-P May 21 10:39:53 Also, wtf are the wiki instructions being changed to uci commands, instead of showing the configuration files themselves? It's 1000 times more obvious looking at a configuration than trying to extract it from uci commands! May 21 10:39:54 * ldir runs away May 21 12:15:52 I just sent an email to the dev mailing list with the topic, "SquashFS mixed errors (decompression failed and others)". I would appreciate any kind of insights into the issue. I think some of you will find the issue interesting and hopefully someone knows something about what is causing it. May 21 13:46:15 jow: fyi, i'm planning on replacing the 'hwmode' option in the wifi-device section with something new May 21 13:46:44 the 11a/11g/11ad/etc. notation doesn't fit well for things like 6ghz (which is a separate band) May 21 13:47:05 so i'm planning on replacing it with a 'band' option that takes 2g/5g/6g/60g as values May 21 13:47:34 what do you think? May 21 13:47:49 should be cleaner for the ui as well May 21 13:50:29 nbd: I like it May 21 13:55:18 nbd: Yes, please! I wager it's a major source of confusion, as it is. May 21 14:35:17 can we get some progress on PR #4041 ? May 21 16:58:10 Ansuel that PR has branch conflicts. Worth resolving? May 21 17:06:30 Nick_Lowe: sure i will fix that but i wanted to have some review or suggestion if we want to proceed with that change May 21 19:32:50 aparcar[m]: hey Paul, questions about the include/image.mk file and the Device/ steps... May 21 19:33:42 we name the image with $(CONFIG_TARGET_PROFILE) as part of the name, but there's no way inside the image to derive its name... which I need. May 21 19:34:26 How hard would it be to squirrel the name of the image into a file in the image itself, without breaking ImageBuilder? May 21 19:34:47 Ansuel: hi, I'm catching up with the ipq806x cpufreq thing: you think the crash in FS#3099 is unrelated to this? May 21 19:35:12 philipp64: just add the name manually under files/ May 21 19:36:01 Can we 'echo "OPENWRT_PROFILE=\"$CONFIG_TARGET_PROFILE\"" >> usr/lib/os-release' into the root-*/ just before we finalize the image? May 21 19:36:39 Trying to do this in a "clean", generically useful way. May 21 19:36:54 And hopefully one that will get adopted into master... May 21 19:37:15 I see May 21 19:46:10 nbd: do you have any thoughts on the subject? May 21 19:49:14 philipp64: in many builds there is no per-device rootfs May 21 19:49:27 well, it is for the snapshot build, but not always for self made builds May 21 19:51:37 philipp64: but the build system can generate a profiles.json, which contains lists of image files and their supported devices May 21 19:52:01 so the device name from the system info could be matched against data from that json May 21 19:53:25 aparcar[m]: did you see https://bugs.openwrt.org/index.php?do=details&task_id=3819 about the keyring change? May 21 20:12:08 zorun: i'm starting to think the problem are related to a bad charger... there are user with 60 days of uptime and they were using a bad cpufreq patch May 21 21:11:25 Ansuel: you mean a bad power supply? May 21 21:11:44 strange that it would not affect latest master May 22 01:08:24 what are the 01_leds scripts for and how does it work? May 22 01:20:13 wingsorc: looking up the function calls will help **** ENDING LOGGING AT Sat May 22 02:59:57 2021