[Pokey] has quit [Quit: Hecc! My server must have died!]
rsalvaterra has joined #openwrt-devel
philipp64 has quit [Ping timeout: 480 seconds]
f0ghua1 has joined #openwrt-devel
<f0ghua1>
Hi all. I am confused with script 'reload_config'. If I changed a config file like '/etc/config/network', and then do '/etc/init.d/network reload', service reloaded successfully. But then if I run 'reload_config', the service reloaded again. So, what's the proper way to use 'reload_config' to prevent from reload the service again?
torv has quit [Remote host closed the connection]
<schmars[m]>
only call reload_config
<schmars[m]>
it keeps track of changes and reloads if neccessary, but it doesn't know that you've already manually reloaded
<schmars[m]>
yeah it's not needed if you do reload_config
<f0ghua1>
but reload_config will reload all the changed services, right?
torv has joined #openwrt-devel
<f0ghua1>
schmars[m], can I just reload a specific service?
<schmars[m]>
it's based on the config files, not on the services. a service can be notified if a specific config file changes
<schmars[m]>
check /sbin/reload_config, it's short and simple
<schmars[m]>
you could notify only services that rely on /etc/config/network, see the ubus call service event invocation in /sbin/reload_config
<schmars[m]>
but the thing that makes it reload twice in your case, is the md5 check on the config content
<f0ghua1>
schmars[m], I see. I read the luci code and found that if there are anything changed, it send a config.change event to ubus, then execute specific service reload. e.g. I changed something on firewall page, then apply, /etc/init.d/firewall reload will execute
<schmars[m]>
yeah that's from service_triggers() in the init script
<schmars[m]>
some service are more complex and listen to multiple config files changes
<f0ghua1>
so, will reload_config reload firewall again?
<f0ghua1>
because it just run /etc/init.d/firewall reload and didn't update the md5 of the config file
<schmars[m]>
i'm not 100% sure if luci also does the md5 content check, which reload_config does
<schmars[m]>
if it does, then reload_config will recognize that the changes have already applied
<schmars[m]>
you can check /var/run/config.md5 and /var/run/config.check/* to see if changing stuff via luci does anything to the md5 cache
<f0ghua1>
schmars[m], Ok, thanks. Let me check. So from your point of view, all service reload actions should be called from 'reload_config', but not call '/etc/init.d/service reload' directly, right?
<schmars[m]>
it's definitely the easiest
<schmars[m]>
but manual reloads are also not wrong
<f0ghua1>
I see, but it may cause reload the service twice
<schmars[m]>
yes if you want to avoid double reload then reload_config is the easiest path
Danct12 has quit [Remote host closed the connection]
Daanct12 has joined #openwrt-devel
<f00b4r0>
in ubus calls, must all keywords parameters always be specified, even if empty?
<schmars[m]>
let me know when you try out ucode-rtnl or ucode-ctypes :) ucode-ubus i haven't dipped my toes into yet
<schmars[m]>
have high hopes for the ucode + ctypes/ffi combo
bluew has quit [Ping timeout: 480 seconds]
<f0ghua1>
schmars[m], I have tried with luci. It looks like that the luci doesn't update md5 of the config file, because after applying the page, service reloaded; then 'reload_config' make the service reload again.
<f0ghua1>
so, I am wondering why luci doesn't call reload_config?
<schmars[m]>
good question
Ansuel has joined #openwrt-devel
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #openwrt-devel
Daaanct12 has joined #openwrt-devel
CrazyLemon has joined #openwrt-devel
CrazyLemon has left #openwrt-devel [Leaving]
Daanct12 has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
hexa- has quit [Quit: WeeChat 3.7.1]
<robimarko>
nbd: You around?
dangole_ has quit [Ping timeout: 480 seconds]
<nbd>
robimarko: yep
<robimarko>
nbd: With 6.1 now having fortify_memcpy_chk we are hitting this in ieee80211_strip_8023_mesh_hdr
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
dangole_ has joined #openwrt-devel
<guidosarducci>
robimarko: heh heh, I have the same ones porting malta and armvirt to 6.1 too. Lots of rebasing coming up I expect.. :-)
<robimarko>
guidosarducci: Yeah, everybody is going to hit those, that is why I sent them now
<robimarko>
Dont want them getting into target configs
<f00b4r0>
do i hate weakly typed languages that have operator overload for addition and comparison. Never really know what's going on when reading code.
<aparcar[m]>
Ansuel: looks like the tools-openwrt-23.05 container is missing, I'd guess we need a way to create it manually or create the container on tagging
<Ansuel>
should also be changed in push-container.yml
<ynezz>
ah, ok, I've missed that part
<Ansuel>
and still i don't think push-container will be triggered on situation like branch
<ynezz>
you changed files in include
<Ansuel>
you are right!
<Ansuel>
nice trick
<ynezz>
lets call it another workaround
<ynezz>
the CI is still misleading, you see a green check mark, but the world then burns down when the changes hit master
<Ansuel>
eh main problem is that 20 runner shared across the entire org makes impossible to do correct testing :(
<ynezz>
well, IMO 20 runners is plenty, our CI is just greedy
<ynezz>
first interim solution would be to simply run CI on approval/label
<Ansuel>
https://github.com/openwrt/openwrt/pull/11652 i'm implementing to squeeze another 2 min from all the job but still... what i really can't sort out is why ccache doesn't work for kernel compile
<ynezz>
really, we shouldn't be building every (cosmetic) force push in PRs
<Ansuel>
that is almost already handled by concurrent rules
<ynezz>
its not
<ynezz>
you're still going to run complete pipeline if I change some typo in commit description for example
<Ansuel>
so your idea is to disable tests on pr and make them all manual on reviewers approval
<ynezz>
and we should remember that those runners are shared accross whole org, so one project shouldn't consume all the resources
<ynezz>
otherwise others wait ages for their changes
<ynezz>
like for example buildbot container for deployment :) so I was even considering to BYOR (Bring Your Own Runner) to have the changes faster
<ynezz>
Ansuel: for the start it could be worth trying
<Ansuel>
yep and link it to something like ready for merge tag
<ynezz>
there is approval event we can bind to
<Ansuel>
can that button be enabled to every pr?
<Ansuel>
let me check that
<Ansuel>
yes
<ynezz>
but it seems, that anyone can approve anything?
<Ansuel>
we can set to require approval for all outside collaborators
<Ansuel>
currently it's set to approval for first-time contributors
<Ansuel>
(and that stops any action test from running)
<ynezz>
I mean review approval, sorry
<Ansuel>
that is a different thing from approval to run tests on pr
<Ansuel>
think pull_request_review can't be used since everyone can review for some reason...
<ynezz>
maybe we need to tweak the permissions little bit?
<Ansuel>
just googling that
<Ansuel>
never liked the fact that pr gets flagged as reviewed by outsiders
<robimarko>
That can be limited per permissions
<ynezz>
and IMO its nice, but usually folks just approve those without actually reviewing them :D
<Ansuel>
maybe review but deny approval ?
<robimarko>
You can just leave comments enabled
<robimarko>
That is like the most usefull part of GH reviews
<robimarko>
As they point at the exact lines
<Ansuel>
mhhh enabling the option i think disables the feature of proposing changed lines
<Ansuel>
can you check that robimarko ? (i just enabled the option)
<robimarko>
Ansuel: You can still add a comment on individual lines
<Ansuel>
yes
<robimarko>
But request changes option is gone
<Ansuel>
you can suggest code changes tho (from what i can read)
<Ansuel>
yep... that is the limiting part github doesn't provide option to also permit that and disable approval
<robimarko>
I mean, comments should be enough
<Ansuel>
was a nice feature... not that used but was nice for outsiders but anyway
<Ansuel>
ynezz so in theory now we can react an approval events
<robimarko>
Though that is going to add more stress on reviewers
<ynezz>
why?
<Ansuel>
we have to approve every pr :( it's nice sometimes to just check the changes, see CI passed and just merge
<robimarko>
Yeah
<robimarko>
Though I agree that CI is choking currently
<Ansuel>
but the beneficial part is permit more tests
<ynezz>
its a problem of the workflow
<ynezz>
it should be approve and forget
<f00b4r0>
robimarko: comment only means the actual committer will have to pore through to check if changes were requested though?
<Ansuel>
a man can dream... approve, ci pass, automerged to git server, pr gets flagged as merged!
<robimarko>
f00b4r0: Well yeah, you gotta read through
<f00b4r0>
which i think is going to be too much to ask given the load
<f00b4r0>
having change requests duly flagged saves a lot of time
<robimarko>
I dont disagree
<ynezz>
Ansuel: bors-ng to the rescue?
<ynezz>
in theory it could be merged from that pipeline itself
<f00b4r0>
Ansuel: imho it's visually quicker to mentally filter out the "approved by" list than going through every comment to check whether one of the reviewers (e.g. robimarko who isn't a GH member) actually asked for changes
<f00b4r0>
my 2c
<Ansuel>
ynezz the hard part is the rebase and force push witch will result in a loop i think (pr gets force pushed... has to be tested again.... things gets merged in the meantime... also people disabling org from force pushing)
<f00b4r0>
especially when GH already filters out non-member "approved by" in checks
<robimarko>
Hm, well it seems that add a suggestion is still here
<robimarko>
Though that is not the same as request changes in terms of feedback
<Lynx->
Why is OpenWrt changing 'master' to 'main'? I thought OpenWrt was apolitical.
<Lynx->
this cancer is even affecting software projects :(?
<Lynx->
master just means original like a master copy, or head, like headmaster, are we worried about offending people who think it might relate to master/slave and hence conjure up images of white supremacy?
<schmars[m]>
You can find the discussion and vote on the openwrt-adm mailing list
<Lynx->
so that's hardly a case of democracy prevailed
<Lynx->
Just like our political leaders imposing stuff on society it doesn't actually want.
<robimarko>
It did prevail, majority of those with commit rights voted to change it
<robimarko>
To me the name of a branch doesnt really matter
<Lynx->
matters enough for those who voted to go to the trouble of changing it and pander to this crap
<Lynx->
look I don't want to annoy people here or create a fight, sorry. I'm just so frustrated to see this shit in OpenWrt even.
<robimarko>
Well, anybody with commit rights can propose a change and put it to a vote
<robimarko>
dangole_: We are starting to use BPI R3 at work but we use Gentoo, do you have any docs on what the SD card image must look like
<ynezz>
aparcar[m]: so whats your plan now? I would suggest to revert that breaking change on github.com, as apparently "Projects hosted on GitHub (packages, luci, …) allow branch renaming with automatic forwarding from master to main including re-targeting open pull requests." in that vote wasn't completely correct
<ynezz>
I assume that folks voting in favor wanted a seamless transition without such breakages
<ynezz>
so you've more time to try out different approach etc.
<dangole_>
robimarko: i guess the image generation code in openwrt is the best documentation at this point. the SoC expects to load something from a fixed offset (typically: arm trusted firmware-a bl2), from there you are pretty free to do what ever you like to do. U-Boot is the most popular next stage, but you can also directly jump into Linux, or extend tf-a with some filesystem support...
<gch981213>
robimarko: Mediatek is on mainline u-boot now, I think you can enable U-boot EFI stub and start GRUB from it.
<Lynx->
Very last point from me. Since the whole point was to make the developer 'community' more inclusive, wouldn't it have made sense to put the vote to users before holding a vote and relying on a tiny margin of five with 9 absentees. The suggestion in the mailing list that if this puts off people from joining the developers community then this is a good thing is troublesome to me.
<Lynx->
I'm a patent attorney not a coder, but it would definitely have put me off. Because there's no technical reason for it, it's entirely political in nature.
<f00b4r0>
Lynx-: this bird has flown. Your arguments were already voiced and dismissed in the vote. As long as the people who suggested this change take responsibility for the (inevitable) breakage this will cause, I'd say let it rest ;P
<f00b4r0>
s/take responsibilty/fix/
<Lynx->
Understood - I'll shutup now. Thanks for not kicking me already.
<aparcar[m]>
ynezz: re. let me pick up on the fallout for a second
<ynezz>
seems like my latest push recreated the master branch
<ynezz>
so that mirroring script needs to be adjusted as well
<ynezz>
and CI is running happily on both branches
<aparcar[m]>
the github rename worked as expected (i.e. https://github.com/openwrt/openwrt/pull/12708 points towards "main"), I assume that the push script re-created the master branch and thereby broke the forwarding
<ynezz>
no, it was missing completely
<ynezz>
just try it in some test repo
<ynezz>
there is no forwarding on github
<aparcar[m]>
okay then something caused an issue on githubs side. I tested this before and github creates a hidden alias that automatically forwards master (or whatever a branch is called before the rename) to the new name
<ynezz>
yes, that works
<ynezz>
but folks cant use master for cloning anymore
<ynezz>
as you can see on blocktrron failure in gluon, just 11 minutes after the change
<aparcar[m]>
so they say git pull actions are not redirected, however I previously tested it without issues and even remember github stating that they do such forwarding. let me check if they recently changed this
<ynezz>
you can check the git history of that document
<aparcar[m]>
Yea seems like I misread "Redirect web requests for the old branch name to the new branch name" and maybe had a timing problem after a rename.
<f00b4r0>
the git pull sentence has been there for 2 years.
<aparcar[m]>
well looks like the planet is still spinning (or at least again)
<ynezz>
because that git mirror script has created the master branch again
<f00b4r0>
^
<aparcar[m]>
ynezz: due to missing access I can't make `main` the default branch for git.o.o
<aparcar[m]>
so people will still pull master
<f00b4r0>
are you sure you want to break git.o.o *before* you get a working situation on github? :P
<ynezz>
I would suggest to take a step back and better test/plan this changes
<f00b4r0>
^
<ynezz>
you probably want to make everyone aware about this switch, then make master read-only etc.
<aparcar[m]>
symbolic-ref will keep both things up to date. people cloning from github (and creating PRs) will end up using main, people cloning from g.o.o will have master. Felix requested a script that blocks (or warns) against pushing to master on git.o.o. I'd implement that, however it likely create more frustration in the direct future.
<robimarko>
dangole: Thanks, I was just concerned about where BL2 needs to be
<robimarko>
And will just use mainline U-boot to boot, I have the binaries built just need to make the image
<f00b4r0>
aparcar[m]: the change needs to be transparent for pulls. We can fix our own automation (buildbot) but breaking downstream one is not a good idea. Esp when AIUI the vote said we wouldn't;
<robimarko>
gch981213: I will use mainline U-boot but no need for EFI
<aparcar[m]>
f00b4r0: how is that comment helpful?
<f00b4r0>
aparcar[m]: I don't know, it seems to me you're willing to forge ahead regardless. Maybe I'm misunderstanding.
<aparcar[m]>
ynezz: yes, same for the buildbots. However with the symbolic-ref it should not matter
<ynezz>
as you can see it does, that mirror script is going to push to both for the start
<aparcar[m]>
ynezz: one sec, I'm looking at the command to run
<ynezz>
I'm not going to run it, so don't bother
<dangole_>
robimarko: on sd card bl2 should be at 17k offset, if you use emmc it should be at offset 0 but in boot0 hardware partition.
<aparcar[m]>
ynezz: now both branches live in parallel however people still checkout `master` branch when cloning first time from git.o.o. To change that the following three commands would be necessary: git branch -d main; git -m master main; git symbolic-ref refs/heads/master refs/heads/main
<aparcar[m]>
after that new pulls end up having main per default but you can still use -b master if desired
<ynezz>
not from github.com
<aparcar[m]>
If I'm not mistaken the current push script just uses git push --mirror git@github.com:openwrt/openwrt.git
<aparcar[m]>
so everything gets pushed to github, including both master and main (since master exists as a ref)
<ynezz>
ok, so lets see how it goes
<ynezz>
and once I've more time to fix the possible fallout we can do that switch on g.g.o
<ynezz>
we should first switch buildbots as well to the main branch
<f00b4r0>
ynezz: fwiw i'm looking at the strange version numbering on 23.05-SNAPSHOT (pointed by Ansuel), and trying to figure out why getver.sh parsed the built commit as being -3 past some older one. Puzzled.
<f00b4r0>
have to admit getver.sh is a bit of black magic to me
<aparcar[m]>
dangole_: do you have an idea regarding the getver.sh thing? I'm looking at it, too (pinged by Ansuel ) but don't see the issue
<Mangix>
Wow. Two big changes. main branch and 23.05. Didn't notice.
<dangole_>
Mangix: it also caught me more or less by surprise, I was out this weekend... but some people were busy with OpenWrt infra work :)
<aparcar[m]>
ynezz: since systems are running right now I'd hop to another meeting and will be back in some 2 hours. Should we try to find some time tomorrow to finish the process?
<Mangix>
dangole_: I'm in Europe currently, away from my dev machine.
<Mangix>
Hence I barely noticed
<Mangix>
I assume someone got fed up with master branch warnings from git :)
<Znevna>
Borromini: I've found that github PRs are easier to make :P
<Borromini>
Znevna: once you set up your git config right, git send-email is *way* easier, trust me.
<Znevna>
probably
<Znevna>
not that I've used git that much :P
<oliv3r[m]>
i was a big fan and user of git send-email; but I find managing MR's on gitlab (and even GH) far more convenient
<oliv3r[m]>
yes, there's patchwork etc
<Znevna>
I don't want to learn different flavors of git/web-git-thingies
<Borromini>
you don't do programming day to day I suppose (nor do I)
<Znevna>
and github desktop is decent too
<Znevna>
I don't :P
<Znevna>
It's just my luck to find bugs and I tend to bug people about them :P
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
fakuivan has quit [Remote host closed the connection]
<Znevna>
you remember I had that C6U with flaky SPI that caused the wifi to not be detected?
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
<Borromini>
yeah
<Borromini>
and down the rbbithole you went xD
<Znevna>
something in master fixed it but I don't know what :P
owrt-images-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-images-builds has joined #openwrt-devel
<f00b4r0>
ynezz: btw if you restart the buildmaster I'd suggest (again :-) enabling 22.03 without rsync urls, so that the monomaster database registers the successful builds and doesn't clobber the existing binaries when you turn on upload later. As an added bonus it will enable us to confirm that 22.03 builds on debian 11 bots.
<Borromini>
Znevna: not a lower read speed or sth?
<f00b4r0>
ynezz: ok, let's wait until the next pull/switch to confirm this doesn't throw Git() off though :)
danitool has joined #openwrt-devel
<oliv3r[m]>
me? I do :) well not so much as I used to; but using git + cli is no issue; sending mail with git send-email is ok (but tedious to get all to's and cc's right). I think gitlab even has an address where you can send-email too, and it creates an MR. But handling of the MR, changing things etc, discussing things, so much nicer in a web env, where everything stays together.
<f00b4r0>
ynezz: good. For some reason these builds have the old rm steps in there too
<robimarko>
oliv3r[m]: Yeah, Ansuel merged it yesterday
<oliv3r[m]>
fuck yeah; alright then, time to get busy :)
<oliv3r[m]>
any big things to watch out for?
<ynezz>
f00b4r0: I limit the deploys as it cancels ongoing builds, so wanted to do it now, but the build queue is quite long and the container is not available yet
<ynezz>
so applied the changes manually
<robimarko>
oliv3r[m]: Shouldnt be, but like always something is bound to break
<oliv3r[m]>
of course :(
<f00b4r0>
ynezz: I'm confused but okay :D
<ynezz>
f00b4r0: if you restart buildbot (deploy new container) then the ongoing builds are lost as buildbot is unable to recover from this state for some reason
<f00b4r0>
ah that, yes
<f00b4r0>
you'll want to stop builds after current one and then restart. IIRC it can be done
<ynezz>
yes, a lot of clicks :P
<f00b4r0>
lol
<f00b4r0>
i'll see if a script can be cooked
<f00b4r0>
but later ;)
<ynezz>
yes, there is api for that
<f00b4r0>
f00d time here, bbl
<ynezz>
I wish github prioritized builds for defaults branches/tags
<robimarko>
That would be awesome for sure
<Ansuel>
afaik it's a feature for enterprise with self hosted runner
<oliv3r[m]>
i think github is building too much atm anyway; :)
<ynezz>
seeing whole build backlog for org is enterprise feature as well?
<oliv3r[m]>
but if you host your own runner (you can even with GH) you could have two, where you dedicate one to branches/tags
<oliv3r[m]>
i hate we loose history of 'new' files when doing the kernel migration bit; I suppose one could first do a git mv commit; but that would break atomicity of our commits
<Ansuel>
for kernel the copy is really to track if some patch are missed compared to an old version
<Ansuel>
they will be refreshed manually anyway
<oliv3r[m]>
well while hacking, I often rely on git log :)
<oliv3r[m]>
i suppose it's nice to know you don't have to look 'further back' because that was the moment of the switchero
<oliv3r[m]>
but other then that, I sometimes just want to go back further; and git has no idea
<oliv3r[m]>
e.g. it's almost impossible to do git log -p config-4.14 :) as git just says 'no such file or directory' fu
djfe has joined #openwrt-devel
<robimarko>
Ugh, I just love debugging a call to magic TZ FW without any docs that suddenly doesnt work
floof58 has quit [Read error: Connection reset by peer]
floof58 has joined #openwrt-devel
<aparcar[m]>
ynezz: what's broken with the buildbot mirroring script? it worked for the projects which I mirrored some time ago
<Ansuel>
oh i have to update the maintainer-tools script
<f00b4r0>
aparcar[m]: I did not because they will almost certainly say -ENOTABUG
<aparcar[m]>
f00b4r0: I though a "clean" checkout would be desired. I remember them being quite open when I supplied patches some time ago, maybe try it
<aparcar[m]>
Ansuel: regarding master/main?
<f00b4r0>
ynezz: curiously I received a GH email about "[openwrt/buildbot] Build and push containers workflow run": "Build and push containers: All jobs were cancelled". Dunno if that's expected
<f00b4r0>
aparcar[m]: remote tracking is not needed to build anything. Its our (rather unusual) way of computing the version string that requires it. I doubt they're going to accommodate such an arcane situation. I'd rather focus on #5 (which maybe something similar)
<Ansuel>
aparcar no my bad just have to update repo anyway should we push to main or master?
<aparcar[m]>
ack
<Ansuel>
or it's the same?
<f00b4r0>
btw it seems the script/makebranch.sh from buildbot is not used anywhere. I should probably look to clean that folder eventually
<aparcar[m]>
Ansuel: for openwrt.git main == master, it got an alias. anywhere else you stick to what was there before
<Ansuel>
ok
<aparcar[m]>
f00b4r0: yea ideally it'd move/merge to maintainer-tools