**** BEGIN LOGGING AT Wed Apr 15 02:59:57 2020 Apr 15 06:15:43 dengqf6: Thanks for sending me the patch. I am currently building a image to test it. Apr 15 06:40:37 aparcar[m]: how is this supposed to work? IMAGE/combined.img.gz := grub-config pc | combined | grub-install | gzip | append-metadata Apr 15 06:41:57 does gzip ignore the metadata? Apr 15 06:46:56 ynezz: it gives a notification of "trailing garbage" but works just fine Apr 15 06:49:18 ynezz: I talked with dangole about the staging tree builds and he liked the idea. He suggested to enable ccache, what do you think? Apr 15 06:49:46 Curently gitlab fails the artifact storage when it the bin dir is bigger than 1gb, however on a self hosted server this should be a problem Apr 15 06:49:54 https://gitlab.com/openwrt/staging/dangole/-/jobs/511104388 Apr 15 06:50:33 I looked a bit into buildbot and they would support staging trees as well. Not sure what to focus on Apr 15 06:53:10 why are you asking for an oppinion if you do it anyway as you want to do it Apr 15 06:54:01 IIRC we've talked about this gitlab.com just yesterday, I didn't recommended it for various reasons, yet you moved forward and did it anyway Apr 15 06:55:40 I find it quite interesting as well, that Daniel was strongly against gitlab.com usage, but it seems alright now Apr 15 06:56:51 IMHO voting by the team members made it clear, what is the preference and we should stick to it, even if we don't agree with it completely Apr 15 06:58:04 whats the difference between gitlab.com/aparcar/openwrt/staging/dangole and gitlab.com/openwrt/staging/dangole? Apr 15 06:59:39 no difference in functionality, but the latter one is _official_ and you cant simply decide about it Apr 15 07:05:12 thats my 5 cents Apr 15 07:13:29 clear Apr 15 07:14:46 rr123: yes, should be still a valid option Apr 15 07:33:40 ynezz: I ask because I value your opinion, I deploy it to see if it works. I added the staging subgroup as private but as dango has no gitlab.com account changed it to public afterwards. As it's a mirrored repository from git.openwrt.org I did not see it as polluting the _official_ repository. Most other repos from git.openwrt.org are mirrored to gitlab.com already. Apr 15 07:33:40 Dango did not changed his mind but kept his position that relying on gitlab.COM is not ideal, self hosted however is fine. Apr 15 07:36:56 I assumed that likely multiple developers would be interested in testing the CI once they have an idea how it works, so instead of putting it in my sub sub account I mirrored something following the official structure Apr 15 07:39:44 Gitlab offers a migration "off" gitlab.com to a private instance (https://docs.gitlab.com/ee/user/project/import/gitlab_com.html) so I didn't see it as a waste of time getting the _official_ gitlab in shape Apr 15 07:54:22 morning - I think - and 'ugh' Apr 15 07:55:14 Anyone here have any knowledge on creating luci-statistics graphs? Apr 15 07:55:39 I'm collecting some additional data that doesn't fit into any of the existing graphs, so need to create a new one. Apr 15 08:20:14 Good morning mother lovers! Apr 15 08:21:16 morning Apr 15 08:22:50 aparcar[m]: enabling ccache on cross-compiled code is usually a bad idea. It's been disabled on phase1 for a reason. My 2c. Apr 15 08:49:03 ldir Hi mate how are you? Apr 15 08:50:17 struggling. Not at my most positive. Apr 15 08:50:50 I know mate it's hard being locked down and board. Apr 15 08:51:40 My mind is allover the place. I find that I cant concentrate on things be fore it is off thinking about other things. Apr 15 08:52:40 Trying to make constructive use of time by 'fiddling with code' but that's not proving satisfying because as usual I'm running beyond the limits of my knowledge and stuff isn't working and bashing my head against a brick wall trying to work out why. Apr 15 08:53:43 What you working on? Apr 15 08:55:30 If you find your self getting to vexed then listen to one song on Spotify and then go back to it. That helps me. Apr 15 08:55:56 It's an idea that appeared in the forum. It should have said "Bash your head against a brickwall and try to enjoy it" but instead it said "Wouldn't it be good if we could graph some stats on the CAKE shaper" Apr 15 08:56:16 well that would be cool indeed! :D Apr 15 08:56:18 Lol forums! Apr 15 08:56:47 So this involves taking output from tc, parsing it, collecting it and the displaying it. Apr 15 08:57:36 It makes sense to take 'machine readable' output from tc instead of trying to parse a potentially changeable screen output... so use the '-j' option to output in JSON. Apr 15 08:57:42 I know nothing about JSON. Apr 15 08:58:56 Do any of the other luci graphs do it like you want to do it? Apr 15 09:00:08 Then, once you've parsed that you need to collect it in some form. collectd can parse and collect JSON formatted data BUT openwrt's collectd package doesn't have (yet another bloody) json library. Sooo that led to using collectd-exec and writing a script to take tc json output, parse it, and then output the parsed data into something that in theory collectd can accept. Apr 15 09:00:45 and would you believe, all of the is working. It's f*ugly but it does appear to be working. Apr 15 09:01:16 lol how does collectd clect it's other data from things? Apr 15 09:01:28 If it does not use json Apr 15 09:03:19 collectd has a number of plugins that do the collection, they're mostly written in 'c' - and no I didn't fancy writing 'c' code to interface with netlink to query the kernel in the same way tc does to go and collect some stats. Apr 15 09:05:31 The collection part is 'solved', well, solved sufficiently for testing purposes. Apr 15 09:06:33 isn't collectd a leaky nightmare? Apr 15 09:06:35 Nice glad you got it working mate. Apr 15 09:06:58 I can't get any graphs out of it. Apr 15 09:07:27 Damb Apr 15 09:08:00 f00b4r0: I don't know. But it's here and available and been working collecting various things for me, for years. Apr 15 09:08:33 ah ok. I remember - a long time ago - it would OOM my router after a few weeks. I vowed never to use it again ;) Apr 15 09:08:34 There's a luci_stats package based upon it, producing pretty graphs. Apr 15 09:09:15 ldir could of added it to the luci-app-sqm package or would of that bin to mutch work? Apr 15 09:09:40 It's the same work Apr 15 09:09:44 oh god. Please don't make app-sqm depend on collectd Apr 15 09:09:52 hahahah Apr 15 09:10:08 That is not what I was meening Apr 15 09:10:51 If the thing was aded to the luci-app-sqm package it could be on the home page of openwrt a graph to show how well sqm is working. Apr 15 09:14:58 I think that there should be a display thingy on the overview page of luci any for services to say what's active or disabled. Eg mine would say Addblock active BanIP active Https-dns-proxy active UPNP active SQM active. Apr 15 09:16:03 O good why are people Burning Down 5G Cell Phone Towers? Apr 15 09:16:08 god* Apr 15 09:16:39 WTF hahaha people think thatt covid19 is from 5G hahahahahah Apr 15 09:16:45 because they think they're witches? Burn the witch! Apr 15 09:17:07 https://www.vice.com/en_uk/article/m7qyy3/watch-people-are-burning-down-5g-cell-phone-towers-over-coronavirus-conspiracy-theories?utm_source=dlvr.it&utm_medium=twitter Apr 15 09:19:39 Some of the towers they set on fire were 4G ones. WTF is rong with people? Apr 15 09:20:44 Ahaaa! graphs! Useless graphs, but graphs nonetheless and they do contain sensible data. Apr 15 09:21:26 looks like I need to extend the collectd types database. This 'project' is escalating. Apr 15 09:21:36 Everything I bloody touch escalates. Apr 15 09:21:53 before long you will be rewriting collectd in a fancy new language :) Apr 15 09:22:07 no Apr 15 09:22:10 Tapper: but they do not burn people any more, this is an improvment over the middle ages Apr 15 09:22:18 lol Apr 15 09:22:33 fortunately we kept drowning as an option Apr 15 09:26:57 This https://forum.openwrt.org/t/sqm-reporting/59960 is why I shouldn't read forums. Apr 15 09:33:18 * ldir weighs a 5G cell tower and discovers it weighs the same as a duck. Aha! Apr 15 09:36:14 it's a witch! Apr 15 09:39:49 lol Apr 15 09:40:46 ldir why don't you rewrite collectd in rust lol Apr 15 09:41:01 Hauke inded. Apr 15 09:41:29 indeed* Apr 15 09:42:13 ldir that would be some escalation rite there! Apr 15 09:42:21 * f00b4r0 grumbles, can never get firewall.user to work as he wants Apr 15 09:42:45 f00b4r0 your holding it rong! Apr 15 09:48:58 f00b4r0: why is ccache on cross compiled code usally a bad idea? were you burnt by it some years ago or what? Apr 15 09:55:37 karlp: I can't seem to find it again but there used to be a statement from ccache dev saying that it wasn't designed for xcompile caching. I'm guessing there might be hashing problems if you ccache multiple blobs for multiple xcompiled archs. Apr 15 09:56:38 karlp: the other reason why it was disabled on phase1 for xcompiled steps is because it was simply trashing the cache one build after another (saturation) and so the hit ratio was close to 0 overall. Meaning that ccache essentially added overhead for no benefit Apr 15 09:57:16 now that it's only applied to native compiles the builders enjoy c 99% hit ratio Apr 15 09:57:25 and now it's really useful. Apr 15 09:58:24 yes, you'd need a very big cache to allow all combinations, that seems rather self evident :) Apr 15 09:58:47 not sure how not being designed for cross compilation at some poitn in the past really matters. Apr 15 10:00:16 it's also generally a bad idea to use ccache on buildbots that serve "distro" content Apr 15 10:01:05 because if a corrupt blob is cached, it will be silently added to all output content until the cache is expired. Apr 15 10:01:20 and ccache can crap out Apr 15 10:01:35 yes, on a builder that is always building new code, I don't imaging ccache would be pðarticuarly useful in general, but your blanket "ccache is useless for cross compiling" sounded like a rather large claim Apr 15 10:01:53 where are you getting corrupt blobs from? Apr 15 10:02:14 cache "expiry" ? is just based on commandline hashes, there's no magic stale cache there... Apr 15 10:02:39 cache expires when the source change (for instance). Is what I mean. Apr 15 10:03:13 this is quite documented btw: https://ccache.dev/manual/latest.html#_corrupt_object_files Apr 15 10:03:15 so, anyone know why brcmfmac-firmware-usb can't be disabled if you have kmod-brcmfmac? I only want the sdio firmware, not usb firmware Apr 15 10:03:18 meanwhile, am on the phone Apr 15 10:03:45 you know that if you have a storage problem and get a corrupt .o you get... the exact same behaviour with or without ccache right? Apr 15 10:05:10 no you don't. Apr 15 10:05:22 once the corrupt blob is cached it is reused. Apr 15 10:05:36 run two consecutive non ccache'd builds and you won't get that behavior. Apr 15 10:05:38 anyway Apr 15 10:10:18 * karlp corrupts an o file and runs make repeatedly and gets a build failure every time.... Apr 15 10:23:15 either you don't know how a build server works or you're trolling me. Apr 15 10:24:24 I know what you're tryign to say, but I don't udnerstand how your takeway is just a a blanket "ccache should not be used" Apr 15 10:25:39 that's not what I said. Apr 15 10:26:01 f00b4r0 | aparcar[m]: enabling ccache on cross-compiled code is usually a bad idea Apr 15 10:26:29 indeed. Apr 15 12:42:13 Hi all Apr 15 12:44:02 hi Apr 15 13:18:37 hello Apr 15 13:19:06 I am looking for a wifi chip or module that has good BT coexistence support in the linux kernel Apr 15 13:19:44 it seems Ralink chips have a TX enable pin, but the kernel driver does not support it Apr 15 13:19:59 does anybody have experience on this? Apr 15 13:47:10 xback: hi :) Apr 15 13:57:33 f00b4r0: Hi Apr 15 13:57:49 I'm just finishing up new kernel additions and would start on extensively testing your patches Apr 15 13:57:57 cool! Apr 15 13:58:06 dunno if you spotted the second set (8 patches) Apr 15 13:58:53 yes Apr 15 13:59:10 this is currently your final? Apr 15 13:59:28 or are more changes coming? Apr 15 14:00:49 only formatting changes until I get the first comments :) Apr 15 14:01:12 ok, I'll use these for testing Apr 15 14:01:13 for now the testing reports i got are all green Apr 15 14:18:06 How can I wait for a deamon that I can create a usock? Currently, with procd level set to 81 oder 95, I get an error "usock: Network unreachable". What can I do? Should I set some timer and retry, or can I do a respawn? I don't know the right solution. Apr 15 14:20:44 nick[m]1: retry loops are the only robust design choice (at least for OpenWrt) atm Apr 15 14:21:22 means repeatedly try binding or connecting until it works Apr 15 14:21:30 @jow: with utimer? or a real loop? Apr 15 14:21:54 depends on your application design. If you already use uloop as event loop then you could use uloop timeouts Apr 15 14:22:10 otherwise a naive while(1) { ... } loop with nanosleep() or similar Apr 15 14:22:11 jow: or a service trigger Apr 15 14:22:17 jow: like igmp proxy Apr 15 14:22:29 nick[m]1: should this daemon run only when lan/wan is up ? Apr 15 14:22:32 blogic: to restart/reload on every up? Yeah, thats the shotgun approach Apr 15 14:22:41 or can it start / stop with the network going up/down Apr 15 14:23:29 that sounds good Apr 15 14:23:56 look at the igmp proxy init.d file Apr 15 14:24:06 thanks. I will look at those different approaches and implement one! :) Apr 15 14:24:15 it add servie triggers to restart/load the service when wan/lan/... restarts Apr 15 14:28:48 f00b4r0: what's your final view on your 2 series? are both intended of only the last one? Apr 15 14:29:05 both. They're orthogonal Apr 15 14:29:24 one is a mtd parser, the other a sysfs driver Apr 15 14:29:30 ok, i'll use both simultaniously Apr 15 14:29:44 sure; that's how it's meant to be :) Apr 15 14:31:37 xback: note that the 5.4 kernel build bits/patches are missing, hopefully copy-pasta from 4.19 will work. Apr 15 14:32:26 xback: also, the partial-erase support in recent kernels appears to be broken, which means you shouldn't try to use rbcfg for now or else risk trashing your secondary bootloader Apr 15 14:32:46 i was unable to diagnose this latter bug alas. Apr 15 14:33:02 ok, thanks for the heads-up Apr 15 14:35:45 igmp proxy has a start level of 99, too ... ^^ Apr 15 14:36:41 nick[m]1: forgot about start levels Apr 15 14:36:57 nick[m]1: on a fast machine they may add or remove a few ms of startup delay Apr 15 14:37:27 but generally init scripts are launched partly in parallel so it gies no ordering guarantees Apr 15 14:38:08 a higher start index will guarantee that your init script runs after other init scripts have run, but it does not guarantee that the *services* launched by the other init scripts are actually ready Apr 15 14:42:43 Thanks for explaining. :) Apr 15 14:44:29 f00b4r0: purely fyi, patch 9/11 doesn't apply anymore. (file got renamed) Apr 15 14:44:59 ah right. Fast moving target ;P Apr 15 15:06:05 hmm, usocks won't be destroyed if the network restarts? Apr 15 15:06:30 * hmm, usocks won't be destroyed if the network restarts? (listening sockets) Apr 15 15:43:33 Neighbor11111112: stop this please Apr 15 15:50:12 ml Apr 15 15:50:14 oops Apr 15 16:08:31 f00b4r0: just tested Apr 15 16:08:37 5.4 goes into a bootloop Apr 15 16:08:41 on 4.19: Apr 15 16:08:44 root@OpenWrt:/sys/firmware/mikrotik/hard_config# cat /proc/mtd Apr 15 16:08:46 dev: size erasesize name Apr 15 16:08:47 mtd0: 00010000 00001000 "partitions" Apr 15 16:08:49 mtd1: 0000c000 00001000 "routerboot" Apr 15 16:08:50 mtd2: 00001000 00001000 "hard_config" Apr 15 16:08:52 mtd3: 00001000 00001000 "bios" Apr 15 16:08:53 mtd4: 00001000 00001000 "soft_config" Apr 15 16:08:55 mtd5: 00040000 00020000 "booter" Apr 15 16:08:56 mtd6: 003c0000 00020000 "kernel" Apr 15 16:08:58 mtd7: 07c00000 00020000 "ubi" Apr 15 16:09:14 looks ok Apr 15 16:09:43 yes. Except with 4K_LIMITS=4096 (the default iirc), mtd0 erasesize is wrong Apr 15 16:09:56 but more importantly, are the partitions correctly placed? Apr 15 16:10:28 sec. ill print it from another device here running 19.07 Apr 15 16:10:50 /proc/mtd isn't helpful for partition placement Apr 15 16:10:57 you want the dmesg mtd parsing Apr 15 16:11:06 I mean for both ;-) Apr 15 16:11:12 :) Apr 15 16:11:39 did you get valid data in /sys/firmware/mikrotik/hard_config/ ? Apr 15 16:11:57 at first glance yes Apr 15 16:12:07 MAC's match the interfaces also Apr 15 16:12:28 19.07: Apr 15 16:12:28 good ;) Apr 15 16:12:31 [ 0.663588] m25p80 spi0.0: found w25x05, expected m25p80 Apr 15 16:12:32 [ 0.680147] m25p80 spi0.0: w25x05 (64 Kbytes) Apr 15 16:12:34 [ 0.684986] Creating 4 MTD partitions on "spi0.0": Apr 15 16:12:36 [ 0.689861] 0x000000000000-0x00000000c000 : "routerboot" Apr 15 16:12:37 [ 0.696641] 0x00000000c000-0x00000000d000 : "hard_config" Apr 15 16:12:39 [ 0.703256] 0x00000000d000-0x00000000e000 : "bios" Apr 15 16:12:40 [ 0.709717] 0x00000000e000-0x00000000f000 : "soft_config" Apr 15 16:12:42 [ 0.717314] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1 Apr 15 16:12:43 [ 0.723802] nand: Samsung NAND 128MiB 3,3V 8-bit Apr 15 16:12:45 [ 0.728484] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 Apr 15 16:12:45 yay Apr 15 16:12:46 [ 0.736199] Scanning device for bad blocks Apr 15 16:12:48 [ 0.746621] random: fast init done Apr 15 16:12:49 [ 0.882027] Creating 3 MTD partitions on "ar934x-nfc": Apr 15 16:12:51 [ 0.887297] 0x000000000000-0x000000040000 : "booter" Apr 15 16:12:52 [ 0.893687] 0x000000040000-0x000000400000 : "kernel" Apr 15 16:12:54 [ 0.899816] 0x000000400000-0x000008000000 : "ubi" Apr 15 16:13:05 looks good indeed Apr 15 16:13:22 master: Apr 15 16:13:26 [ 0.705352] m25p80 spi0.0: w25x05 (64 Kbytes) Apr 15 16:13:27 [ 0.710013] 1 routerbootpart partitions found on MTD device spi0.0 Apr 15 16:13:29 [ 0.716293] Creating 1 MTD partitions on "spi0.0": Apr 15 16:13:30 [ 0.721178] 0x000000000000-0x000000010000 : "partitions" Apr 15 16:13:32 [ 0.727873] 4 routerbootpart partitions found on MTD device partitions Apr 15 16:13:33 [ 0.734545] Creating 4 MTD partitions on "partitions": Apr 15 16:13:35 [ 0.739775] 0x000000000000-0x00000000c000 : "routerboot" Apr 15 16:13:36 [ 0.745888] 0x00000000c000-0x00000000d000 : "hard_config" Apr 15 16:13:38 [ 0.752104] 0x00000000d000-0x00000000e000 : "bios" Apr 15 16:13:39 [ 0.757729] 0x00000000e000-0x00000000f000 : "soft_config" Apr 15 16:13:41 [ 0.767663] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1 Apr 15 16:13:42 [ 0.774147] nand: Samsung NAND 128MiB 3,3V 8-bit Apr 15 16:13:44 [ 0.778841] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 Apr 15 16:13:45 [ 0.786554] Scanning device for bad blocks Apr 15 16:13:47 [ 0.793851] random: fast init done Apr 15 16:13:48 [ 0.926925] 3 fixed-partitions partitions found on MTD device ar934x-nand Apr 15 16:13:50 [ 0.933827] Creating 3 MTD partitions on "ar934x-nand": Apr 15 16:13:51 [ 0.939146] 0x000000000000-0x000000040000 : "booter" Apr 15 16:13:53 [ 0.944910] 0x000000040000-0x000000400000 : "kernel" Apr 15 16:13:54 [ 0.950694] 0x000000400000-0x000008000000 : "ubi" Apr 15 16:14:14 looks all good Apr 15 16:14:42 is the bootloop related to the sysfs patch then? Apr 15 16:16:01 still need to check that. I quickly copied your patch for Kconfig from 4.19, altered it to match. and build using testing kernel first Apr 15 16:16:04 that one bootlooped Apr 15 16:16:14 then just switching to 4.19 and bootloop is gone Apr 15 16:16:19 i'll check that tomorrow Apr 15 16:16:22 odd. Apr 15 16:16:41 Maybe V=s will show hints? Apr 15 16:18:21 although I don't think I used any API that changed since 4.19, but I could be wrong about that Apr 15 17:15:46 jow: is there a way of having a logarithmic scale on the luci stats graph? I believe rrdtool is capable but I can't find a magic switch in the code Apr 15 17:36:27 ldir: no, there is no such facility yet Apr 15 17:36:44 ldir: and the used rrdtool is very old (1.0.x) so not sure if it has zthe capabilities Apr 15 17:39:27 ldir: ah, it does Apr 15 17:41:45 ldir: in the returned graph definition, add `rrdopts: [ "--logarithmic" ]` Apr 15 17:49:40 cheers - will try that :-) Apr 15 19:07:11 works :-) Apr 15 19:09:05 So I have another challenge. You've probably guessed I'm collecting stats from the cake qdisc. This divides some info into 'tins'. I've told collectd to store each bit of tin data in separate files eg: qdisct_drops-tin0.rrd Apr 15 19:10:10 tin1 for tin1 and so on. the default renderer is picking up all the related tin file and placing them into 1 graph. I'd like to graph by tin. Apr 15 19:11:25 This is what I've done so far https://paste.ubuntu.com/p/kCS2zpyG7Y/ Apr 15 19:19:49 maybe I have to extend the containing dir from ./cake-eth0 to ./cake-eth0t'n'. So ./cake-eth0 has the overall data, ./cake-eth0t'n' dirs have each tin. Apr 15 19:20:06 hm, you can try per_instance: true Apr 15 19:21:56 whats the current directory structure (find /tmp/rrd) ? Apr 15 19:24:40 https://paste.ubuntu.com/p/F8vWnZMWpt/ Apr 15 19:27:09 hm, then per_instance: true should do what you need Apr 15 19:33:05 I'll give that a go :-) Apr 15 19:54:22 hmm, sadly only appears to output the 1st instance ie tin 0 Apr 15 21:54:59 should we backport this linux kernel wireless commit https://git.kernel.org/linus/a0761a301746ec2d92d7fcb82af69c0a6a4339aa Apr 15 21:55:31 for me this looks security relevant Apr 15 22:03:26 jow: tmn505 are these two backports to 19.07 ok? Apr 15 22:03:28 https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commitdiff;h=2e84d4b4cfa2c7543b6d10e4c6e0ee81a69e3faf Apr 15 22:03:31 https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commitdiff;h=97f16d91bdf4af95ab23043fee68a55ce63414b1 Apr 15 22:03:48 this will generate a new toolchain, are the build bots fine with it? Apr 15 22:11:31 Hauke: sounds good Apr 15 22:13:04 speaking of toolchain, that reminds me of this patch: https://patchwork.ozlabs.org/project/openwrt/patch/20200112044559.633608-1-rosenp@gmail.com/ Apr 15 22:13:10 I should probably resend Apr 15 22:45:54 f00b4r0: do you know how I can reanable the ccache for phase1 to compare the results? Apr 15 23:40:36 I may have disaggreed on the scale of their claism, but ccache on continually changing code is going to be _huge_ disk space for marginal gains. Apr 15 23:40:56 it's wayyyy more suited to rebuilding things with minor change Apr 15 23:56:05 karlp: isn't that exactly what the buildbots are doing? rebuilding things with minor change Apr 16 00:02:03 correct Apr 16 00:02:52 I very much agree with f00b4r0 on it in this use, I was just objecting earlier today to the (in my interpretation of their words, but by all acounts overthought) claim that ccache was best avoided for cross compilation in general Apr 16 00:08:15 Hauke: this sounds similar to the kr00k vuln some weeks ago - so we should definitely backport this imho. Apr 16 01:06:41 karlp: i got ccache enabled in my local build environments accross several targets and haven't seen any problems so far Apr 16 01:14:33 I agree :) Apr 16 02:49:27 i used to call partpobe / losetup -P within my custom sysupgrade script in older releases and relied on respective block device nodes being created dynamically. Apparently the latter isn't the case anymore. What do I have to copy over to the ramdisk in order to re-activate this behaviour? Apr 16 02:49:49 Just adding hotplug-call to RAMFS_COPY_BIN doesn't seem enough Apr 16 02:57:30 hm, i assume since hotplugd got replaced by functionality inside procd and procd is not running within the ramdisk used by sysupgrade, there's no way anymore of automatic block device node creation? **** ENDING LOGGING AT Thu Apr 16 02:59:57 2020