02:00 <philipp64> seems like CI/CD is backed up again...

06:22 <owrt-snap-builds> Build [#852](https://buildbot.openwrt.org/master/images/#builders/49/builds/852) of `mvebu/cortexa53` completed successfully.

09:22 <owrt-snap-builds> Build [#850](https://buildbot.openwrt.org/master/images/#builders/52/builds/850) of `x86/legacy` completed successfully.

10:30 <Znevna> zomg disaster https://forum.openwrt.org/t/ubiquiti-er-x-and-22-03-4-disaster-help/158295

10:30 <Znevna> >.>

13:17 <enyc> ** https://downloads.openwrt.org/ should have "adviced" corrected to "advised" please =).

15:31 <owrt-snap-builds> Build [#858](https://buildbot.openwrt.org/master/images/#builders/54/builds/858) of `ramips/mt7620` completed successfully.

17:03 <philipp64> anyone around who can help me figure out this dependency issue? https://github.com/openwrt/packages/actions/runs/4775446114/jobs/8489737850?pr=20857 what's odd is that it only fails on two platforms... I'm wondering if it's limited to the 5.15 kernels or what's going on...

17:38 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html

17:39 <schmars[m]> philipp64: the kmods feed is for 5.15.107 (see line 22) but something is expecting 5.15.108 kmods

17:40 <philipp64> schmars[m]: okay... and where is that going on?

17:40 <philipp64> I've not dived into the CI/CD.

17:41 <schmars[m]> dunno, but i guess something got missed when kernel was bumped from 5.15.107 to 5.15.108

17:42 <philipp64> swalker: I need to figure out what to do with Perl updates... it's just too painful. They keep adding more build-time discovery of options that doesn't like cross-compilation... it's more and more of a pain to maintain.

17:42 <Ansuel> or the container still needs to be pushed probably

17:44 <philipp64> it's been broken a while... I tried to fix the issue with https://github.com/openwrt/packages/commit/d1b2bb9dcde39be60266fa0aeef8b52abe1ef34e and that was a while ago...

17:44 <schmars[m]> ah yeah the .108 bump was only yesterday. no update in openwrt's large architecture of targets, feeds, packages, and buildbots is atomic, so transient errors like this happen

17:45 <schmars[m]> i see, ok, then probably there's something wrong for real :-)

17:45 <philipp64> Ansuel: what's the potential problem with PR #12457? I'm trying to understand what I may be missing here...

17:47 <Ansuel> probably me writing at late night

17:47 <Ansuel> my concern was that some package installing files there resulting in default file from package being wrongly preserved

17:48 <Ansuel> but that should be the case at all

17:50 <philipp64> I think files only get backed up when they're changed, if you do "sysupgrade -b -u"

17:50 <Ansuel> yep that is the case so i was just confused

17:50 <philipp64> -u skip from backup files that are equal to those in /rom

17:50 <philipp64> Ansuel: I don't blame you... a lot of this stuff could be better documented.

17:51 <Ansuel> so my concern was pkg A installing special stuff in that dir... you do a config backup and you have files of pkg A.... then pkg A is updated making changes there and you overwriting the new version of pkg A... but in theory opkg should take care of that

17:52 <Ansuel> (aka warning you that conf file are already present and giving to you the new version with -opkg appended)

17:54 <philipp64> Yeah, it won't overwrite it if it doesn't match the SHA in the package's meta-information... If it's correctly flagged as a configuration file.

17:55 <philipp64> Ansuel: Any thoughts on PR #12354? Trying to get traction on a whole host of sysupgrade stuff, but it's not clear to me who officially owns that. Unlike packages/ which has recorded maintainers... sigh.

17:57 <Ansuel> the owner is anyone on the openwrt team that wants to take the risk of causing a major brick on every device supported ahahahahaha

17:57 <Ansuel> similar to opkg

17:59 <philipp64> ironically, there's a risk to bricking devices when you sysupgrade and it restores a bunch of crap that's either wrong or fills up the filesystem...

17:59 <philipp64> inaction isn't a perfect solution either