<nbd>
nick[m]12: stintel added a fix on the git server side. after the next commit it should sync again
<nick[m]12>
nbd: thanks!
ktifhfl has joined #openwrt-devel
<stintel>
if not, yell
<karlp>
I'm just getting "lto1: internal compiler error: original not compressed with zstd" on glib after dong a dirclean and removing my dl/*glib*
<karlp>
I wish I could have simple problems like updating github host keys :|
torv has quit [Remote host closed the connection]
<Ansuel>
karlp wipe ccache
torv has joined #openwrt-devel
<Ansuel>
ccache bug that doesn't detect config change and doesn't wipe itself
<karlp>
might I suggest taht "make dirclean" should remove .ccache?!
<stintel>
${HOME}/.ccache ?
<karlp>
no, this is in the openwrt build dir, I don't even ahve a ssystem ccache right now
<Ansuel>
.cache in openwrt
<stintel>
in that case, makes sense
<nick[m]12>
nbd: I saw you send additional to the station fix, some mesh fixes to linux-wireless. You did not put them to OpenWrt? I looks like this is maybe fixing some issue for me in my mesh setup
<karlp>
I certainly wouldn't expect it to remove my system home ccache dir, no.
<Ansuel>
karlp eh these are workaround tho... imho the current way is fragile but yes wiping .ccache on clean call is not a bad idea
<stintel>
we don't really CI how the average dev / user who builds their own images build
<karlp>
especially dirclean, dirclean is meant to be the "yes, I'm prepared to rebuild even toolcahins because things are screwed up and I just want to rebuild clean"
<stintel>
i.e. with leftover {build,staging}_dir and tmp/
<stintel>
there is breakage all the time in this regard, rather frustrating
<nick[m]12>
nbd: whups. they are not new and already included into openwrt.
maciekb has quit [Ping timeout: 480 seconds]
maciekb has joined #openwrt-devel
minimal has quit [Quit: Leaving]
<oliv3r[m]>
Ansuel: now that you are here, any thoughts on that 7z MR?
<stintel>
shibboleth: you need to be married before you can get a divorce :P
<shibboleth>
true. and fortunately :P
* enyc
meeps
<enyc>
If I'm seeing things rightly, lots of changes being submitted to master which may go into a new 23.xx release cycle, or so, at this stage, and no real need for 22.03.x new point release now, or so?
schwicht has joined #openwrt-devel
<stintel>
since we didn't branch 23.xx yet, everything that's in master now will most likely end up in 23.xx unless something gets reverted
<enyc>
stintel: sure thintg, but I'm just wonedring whats going on dev-wise, maybe this isn't unusual but it seems anomalous to me no new point release in some time, seems odd, could just be "watched kettle" syndrome ;o
<stintel>
we usually do a new point release shortly after some bad bugs are found
<olmari>
...but took me apparently this long to know git doesn't care about permissions more than x
<Habbie>
Ansuel, wow
ptudor has joined #openwrt-devel
<olmari>
Well... paid company is... paid company :D
<olmari>
I mean.. that fact doesn't itself mean much, but incentives are always something else ;)
schwicht has joined #openwrt-devel
<pekster>
olmari: If you're using custom files (via the build system or image builder: there's support for both [1]) it's up to you to set permissions correctly before invoking `make`. An alternative is to use uci-defaults and script the key (or other material) to place.
<pekster>
Do beware if including private keys like that you should protect the resulting firmware image as you would key material since anyone with access to it could trivially extract your host keys.
<olmari>
pekster: well... quite the funsies for git deficiensy... (yeah not openwrt failure on that particularity )
<olmari>
rest of the facts are known :)
<pekster>
Deployment isn't really git's responsibility; tools like scripts or Ansible/Puppet/Chef/… are better at that anyway.
<olmari>
true... but also I am not deploying anything myself in the strictest meaning... only wanna throw keyfiles :D
<olmari>
without env it even works :P
<olmari>
so yeah...
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<olmari>
I suppose the "env" should take care, while I have no direct ideas how, but yeah.. Also I can manage without this, just.. meh :D
<olmari>
Okay, then totally another question... tplink WDR4900 still supposed to work wuth latest master?
<olmari>
I know the past things happened with it and some kernel size and bootloader issues
<olmari>
something similar issue again? :)
<slh>
there's only ome way to find out ;)
<olmari>
well... kind og
<olmari>
of
<olmari>
I know I can eventually take the device from wall and use TTL-serial, but first I need to get there :D
<olmari>
ac7v2 went just fine ;)
<slh>
it's not exactly a popular device (yes, I know, it's still rather fast), so I wouldn't expect too many others to have tried it - you may be the first in weeks/ months
<olmari>
wdr4900 seems not to be tehre after update
<olmari>
While I know and/or knew this is always option (to brick), at the moment was more beneficial to try update it rather than let it sit doing nothing