<Ansuel>
hauke btw the mt7621 is not our fault... just a bug in how python3/host works... seems it's a long lasting bug from last year that still nobody manage to solve
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hanetzer3 has joined #openwrt-devel
hanetzer2 has quit [Ping timeout: 480 seconds]
cbeznea has joined #openwrt-devel
<rmilecki>
PaulFertser: Ansuel: extra MACs should be "generated" by NVMEM layer and we have design for that ready
<rmilecki>
it's already possible for custom NVMEM layouts like U-Boot env data
<rmilecki>
see .dts changes in my commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=9a62b3977f7c2aa3ff3e25013069dee07c5296d7 ("kernel: backport NVMEM patch for U-Boot env data "ethaddr" cell")
<rmilecki>
i've sent the same feature support for NVRAM and it has been accepted already
<rmilecki>
I'm waiting for few more NVMEM patches to be accepteda
<rmilecki>
and I'm going to work on a solution for fixed NVMEM cells thne
<rmilecki>
we should have something in few weeks optimistically
<PaulFertser>
rmilecki: that's a cool idea but what about the case where MAC address can only be fetched by the ethernet network driver itself?
<rmilecki>
PaulFertser: oh, that's a problem
goliath has joined #openwrt-devel
<PaulFertser>
rmilecki: essentially some PCIe network cards have like an additional *MII interface which connects directly to a BMC (separate SoC for managing a motherboard) and by sending special ethernet type frames over that connection (called NC-SI) the BMC can obtain MAC, get link parameters etc. So it's natural for a vendor to allocate two MACs per board, with one MAC "flashed into" the network card
<PaulFertser>
under the assumption that the BMC should automatically use the next MAC.
georgep56_ has joined #openwrt-devel
tidalf has joined #openwrt-devel
tidalf_ has quit [Ping timeout: 480 seconds]
xutaxkamay has quit [Ping timeout: 480 seconds]
xutaxkamay has joined #openwrt-devel
Tapper has joined #openwrt-devel
robimarko has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
georgep56_ has quit [Quit: Connection closed for inactivity]
<stintel>
Mangix: then it turns this into + .flags = {.mirror_x = true, .mirror_y = false, .swap_xy = LCD_SWAP_XY},
<stintel>
wtf
Lynx- has joined #openwrt-devel
<Mangix>
stintel: sounds about right. So there's some weird interaction with the max line len in clang-format 's config
<stintel>
pffft, and wrapping it in // clang-format off // clang-format on is also going to be meh
<stintel>
seriously fugly
<stintel>
I guess no clang-format then
<Mangix>
There's also GNU indent IIRC
george_p56 has quit [Ping timeout: 480 seconds]
<stintel>
yeah I looked at that too, even worse
JEnga has joined #openwrt-devel
<JEnga>
hello, Can someone help me automate my custom build process for a couple of architectures/devices
JEnga has quit [Remote host closed the connection]
<Slimey>
heh they dont hang around long. ever. in any channel.
<Lynx->
any of you familiar with procd?
<Lynx->
I am tyring to work out how to get procd service show up as 'inactive' when script terminates run by the command
Danct12 has quit [Quit: WeeChat 3.8]
JEnga has joined #openwrt-devel
<JEnga>
hello, Can someone help me automate my custom build process for a couple of architectures/devices I started compiling for a couple of models which is growing and I cannot keep up with the demand, it would be a real lifesaver if I can automate it using a buildbot or whatevevr. this is how I'm currently building manually https://pastebin.com/bTKFyXN6 my connection is too unstable atm I will keep up reading the irc log in case I get disconnecte
<Ansuel>
Jenga just abuse github ci and with the use of secrets push the final image to a local server
<JEnga>
Ansuel: Can you point me to a sample project or a document somewhere ?
<Ansuel>
ehhh you need to do some homework yourself but openwrt ci always have all the groundwork on compiling an image from source
<Ansuel>
as we need to test each commit
<stintel>
Mangix: leaving the ending comma and BreakBeforeBinaryOperators: All fixes it
<stintel>
quite confusing but good enough
<stintel>
now I just need an AlignConsecutiveAssignments only for struct initialization
<schmars[m]>
could we get sources.openwrt.org into the rsync mirror too? looking to have a complete local mirror for all things openwrt-dev-related that we can replicate in our community network
<f00b4r0>
stintel: xcode happily formats all the code I write exactly the way I want to ;D
* f00b4r0
hides
<ukleinek>
f00b4r0: same for vim on my side. And if it's wrong and indents by one tab too much, I just have to delete that tab ... :-)
<f00b4r0>
I was about to mention vim next xD
<Ansuel>
i just write good formatted code from the start
<Ansuel>
exploding brain meme
<f00b4r0>
^^
<f00b4r0>
:D
<stintel>
sure, that works for code without collaboration :)
<robimarko>
Ansuel: Just ignore those downstream ones
<Ansuel>
can't wait to have more issue like that
goliath has quit [Quit: SIGSEGV]
tidalf_ has quit [Ping timeout: 480 seconds]
JEnga has quit [Remote host closed the connection]
<rmilecki>
Ansuel: yes, I'm going to work on ASCII formats too
<rmilecki>
I'll just need to figure out solution that will make DT guys happy
<rmilecki>
I've some plan ;)
<Ansuel>
PITA incoming
<Ansuel>
rmilecki btw the porblem Paul pointed out can be resolved by creating virtual nvmem
<Ansuel>
just like we do with mtd
<rmilecki>
Ansuel: i don't know if upstream will accept it
<rmilecki>
but sounds like a possible solution
<Ansuel>
funny discussion about security and military about openwrt
<Ansuel>
rmilecki well the limitation is real and your work on nvmem seems correct... so it seems correct to attach and virtualize these kind of device that provide ma cthat way
<Ansuel>
provide mac that way*
<rmilecki>
hopefully
<Ansuel>
but i would first focus on asciii
<Ansuel>
that and increment would remove 3/4 of the board.d scripts
<rmilecki>
i'd love that to happen
<rmilecki>
and I hope it will :)
<Ansuel>
reverse would be the last thing but i think that is impossible
<rmilecki>
just give Siri 1 or 2 weeks to pick up pending nvmem patches
<rmilecki>
Ansuel: i think it's possble
<rmilecki>
Ansuel: is that about 00:11:22:33:44:55 vs. 55:44:33:22:11:00?
<Ansuel>
yes we have some case where OEM saved the mac reversed
<rmilecki>
Ansuel: can you point me to downstream code supporting that?
<Ansuel>
let me grep
<rmilecki>
hauke: i'd like to relicense your code to dual-licensing, would you accept that?
<ynezz>
I'm not sure whether its a good idea to do it at this point of time
<Ansuel>
should affect only host tool
<ynezz>
which in turn produce firmware images
<ynezz>
so there might be some theoretical potential for regression on some exotic targets
<Ansuel>
but even if we branch buildbot will use the same container
<Ansuel>
right?
<Ansuel>
or by nranching we would use old container version ?
minimal has joined #openwrt-devel
<ynezz>
yes, the idea is to use it for 23.05 as well
<ynezz>
for 22.03 we probably shouldn't do that switch
<ynezz>
handling that with monomaster is going to be fun
<Ansuel>
don't know if the risk are that high honestly... for real crucial stuff we use self compiled host tools so it would be a bug in the gcc present in debian 11 that result in broken host tools
grid has quit [Ping timeout: 480 seconds]
<Ansuel>
ynezz btw the idea was to branch in the next 2 days if the gnutls problem are fixed
<Ansuel>
does the buildbot change would delay it ?
<ynezz>
lets see how it goes, I'll do my best to get it working on time
<f00b4r0>
handling different build containers for different branches is currently not an option, and I'm not sure it's even feasible without losing all the benefits of the single master
<ynezz>
f00b4r0: it could be an option with dedicated build workers for 22.03 releases
<f00b4r0>
since we build nearly all "important" host tools anyway, I don't think there's a major risk in bumping everyone. I've been building images for 19.07 to 21.03 on debian 11 for a while now and I suspect I'm not alone
<f00b4r0>
ynezz: buildbot doesn't deploy its own container; it uses what's set on the slave
<f00b4r0>
furthermore if we manage to do this (deploy container before build), then the overhead of switching will be insane. Better not move to monomaster at all then.
<f00b4r0>
i'm not sure we take a special risk trying to bump everything and see how snapshots fare
<ynezz>
thats in progress now
<f00b4r0>
good. Let's wait and see then
<Ansuel>
i mean... if we want to be paranoid we can test building some image from the new system
<Ansuel>
compare sha
<Ansuel>
and see if it's different
<Ansuel>
image are reproducible so they should be the same
<f00b4r0>
indeed. Will be a good way to check if we still catch some host deps when we really shouldn't
<Ansuel>
honestly what scares me the most is just python getting bumped
<f00b4r0>
that... ;P
<Ansuel>
on debian 10 it's 3.7
<f00b4r0>
can't wait till all our build infra is built on meson ;D
* f00b4r0
hides
<Ansuel>
debian 11 is 3.9
<Ansuel>
mh ggc 8 to gcc 10
<Ansuel>
no idea debian10 used that old gcc
<f00b4r0>
if it ain't broke... :)
<Ansuel>
but still even gcc 10 is not pretty old so i assume they had plenty of time to fix regression with it
<Ansuel>
*is pretty old
<ynezz>
we live only once :P
<Ansuel>
can't wait for us having fun with buildbot exploding ahahahha
<robimarko>
Ansuel: Well, it would be rather great if we can just disable caching
<Ansuel>
it's a PITA to do research on google about make
<Ansuel>
make disable directory cache
<robimarko>
Yes, its all nicely not documented
<Ansuel>
anyway commenting that function results in the same error...
<Ansuel>
ynezz very useful error i see
<Ansuel>
but some are building correctly it seems
<f00b4r0>
ynezz: did you start clean (as in, wiped the container)?
<f00b4r0>
ynezz: oh, i see
<f00b4r0>
ynezz: it's building detached head: it's building a commit that is no longer the current branch head
<f00b4r0>
so the failure is "expected"
cbeznea1 has quit [Quit: Leaving.]
<f00b4r0>
ynezz: that's why the next build didn't die on this step
<f00b4r0>
my understanding is that this is working as intended
<f00b4r0>
i would argue for not building master as frequently (either by increasing the idle timer, and/or by using a scheduler that builds at fixed intervals)
<f00b4r0>
meanwhile, food time
<Ansuel>
f00b4r0 think he is testing with a single commit
<Ansuel>
ynezz also signfiles fail but probably it's expected ?
Borromini has joined #openwrt-devel
hanetzer4 has joined #openwrt-devel
hanetzer3 has quit [Ping timeout: 480 seconds]
robimarko has quit [Quit: Leaving]
Guest24 has quit []
Danct12 has joined #openwrt-devel
<f00b4r0>
Ansuel: what do you mean?
<f00b4r0>
also the signfiles is most certainly expected, since "gpg: invalid armor header: placeholder_for_demo_purposes\n" :)
<f00b4r0>
pkg_hash_fetch_best_installation_candidate: Packages for ath10k-firmware-qca9888-ct-htt found, but incompatible with the architectures configured
<Ansuel>
that is a problem with opkg probably
<Ansuel>
or not
<f00b4r0>
affects the mikrotik and nand ath79 subtargets, but not the main target
<f00b4r0>
s/main/generic/
<f00b4r0>
ok, it's past 10PM, and I had a long day, so further buildbot bugs shall be temporarily redirected to /dev/null until tomorrow ;P
<Ansuel>
same timezone i see
<f00b4r0>
I'm not sure the above two images failures are related to my changes anyway, so I'll sleep soundly until proven otherwise ;D
shibboleth has joined #openwrt-devel
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
<f00b4r0>
the kmodupload step failing is the lambda in doStepIf returning true when it should not. Can't figure why now and I shouldn't be here, will look tomorrow.
<f00b4r0>
(might want to stop wasting cpu cycles meanwhile)
goliath has quit [Quit: SIGSEGV]
shibboleth has quit [Quit: shibboleth]
djfe_ has joined #openwrt-devel
djfe__ has joined #openwrt-devel
djfe has quit [Ping timeout: 480 seconds]
djfe_ has quit [Ping timeout: 480 seconds]
MatMaul[m]1 has quit [Ping timeout: 480 seconds]
John[m]12345 has quit [Ping timeout: 480 seconds]
olmari has quit [Ping timeout: 488 seconds]
mkg20001 has quit [Ping timeout: 488 seconds]
Christophe[m]1 has quit [Ping timeout: 480 seconds]
nick[m]1234 has quit [Ping timeout: 480 seconds]
znullptr[m] has quit [Ping timeout: 480 seconds]
JuniorJPDJ has quit [Ping timeout: 480 seconds]
ctdvqgg445[m] has quit [Ping timeout: 480 seconds]
tohojo has quit [Ping timeout: 480 seconds]
will[m] has quit [Ping timeout: 480 seconds]
PJin[m] has quit [Ping timeout: 480 seconds]
pavlix has quit [Ping timeout: 480 seconds]
JulianGro[m] has quit [Ping timeout: 483 seconds]
bluse-blue[m] has quit [Ping timeout: 480 seconds]
fpsusername[m] has quit [Ping timeout: 480 seconds]
skorpy[m] has quit [Ping timeout: 480 seconds]
hauke[m] has quit [Ping timeout: 480 seconds]
aparcar[m] has quit [Ping timeout: 480 seconds]
schmars[m] has quit [Ping timeout: 480 seconds]
fieryeagle954[m] has quit [Ping timeout: 480 seconds]
vulpes2[m] has quit [Ping timeout: 480 seconds]
whatevs111[m] has quit [Ping timeout: 480 seconds]
barhom has quit [Ping timeout: 480 seconds]
gnustomp[m] has quit [Ping timeout: 480 seconds]
hexagonwin[m] has quit [Ping timeout: 480 seconds]
lipnitsk has quit [Ping timeout: 483 seconds]
decke[m] has quit [Ping timeout: 483 seconds]
domon has quit [Ping timeout: 483 seconds]
evils[m] has quit [Ping timeout: 483 seconds]
oliv3r[m] has quit [Ping timeout: 483 seconds]
djfe has joined #openwrt-devel
wvdakker has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
zatwai_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
zatwai has joined #openwrt-devel
wvdakker has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]