michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<JEEB>
there, finally was around at my main lair and got 2FA set up
<wbs>
kasper93: you're right that it does seem to have triggered gcc to produce a couple more warnings than before though, probably for array/size accesses where it didn't optimize far enough to care/notice before
<kasper93>
yes, it's known issue with gcc diagnostics, they do overflow diagnostic after vectorization, which causes false positives
<wbs>
yeah, I've seen many cases of them being false positives, super annoying
Guest28 has joined #ffmpeg-devel
Guest28 has quit [Client Quit]
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Read error: Connection reset by peer]
<Sean_McG>
BtbN: can I disable the 'pr_labeler' job in my repo? I suspect no but Forgejo is new to me
<BtbN>
you can just disable actions in your repo
<BtbN>
If you want to disable a job, remove it from master
<Sean_McG>
also, I got caching to work properly -- it was my firewall blocking communication to a port opened by the runner. It's _not documented anywhere_ for the runner so I'm pretty annoyed about it, especially because the port is ephemeral
<Sean_McG>
not sure why it doesn't just use a Unix socket since the connection is local
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20098 merged: avformat/mov: set primary extradata based on the first Sample only if it's not already in place (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20098) by jamrial
minimal has joined #ffmpeg-devel
Kimapr has quit [Remote host closed the connection]
Kimapr has joined #ffmpeg-devel
Kimapr_ has joined #ffmpeg-devel
Kimapr has quit [Remote host closed the connection]
<Sean_McG>
I'm seeing weird sporadic failures of fate-ffmpeg-fix_sub_duration_heartbeat on my runner -- doesn't seem to be the case in the official repo
<Sean_McG>
if I resubmit the job it usually succeeds
GewoonLeon has quit [Ping timeout: 248 seconds]
<kasper93>
known race condition apparently
<JEEB>
technically an input VS output latency thing. if we could set that to a specific value we could make it deterministic
<BtbN>
Again: Discuss those rules then, and don't just blindly revert the whole script
<kierank>
policing capital letters and punctuation is insane
<kierank>
literally rules you made up from the sky
<BtbN>
Again: Discuss those rules then, and don't just blindly revert the whole script
lemourin has joined #ffmpeg-devel
<kierank>
only one of them is a reasonable rule
<kierank>
two out of seven are reasonable
<kierank>
literally enforcing random rules on people
<BtbN>
Also, again for like the fifth time: It's not enforcing anything
<BtbN>
you are free to ignore the check
<BtbN>
This is just ridiculous behaviour
<kierank>
it's ridiculous to just make up rules
<michaelni>
BtbN, i expected the revert to be applied once its reviewed and approved, not immedeatly
<kierank>
I approved the MR
<kierank>
the rules are plucked from the sky
<BtbN>
michaelni: yeah, I don't mean you by that
<kierank>
wtf michael literally sent the revert
<BtbN>
To discuss it
<BtbN>
Things can be discussed
<kierank>
where does it say that??
<BtbN>
That's literally the point of submitting a PR vs. just pushing the change
<kierank>
omg this is insane
<kierank>
kafkaquesque stuff
<JEEB>
for the record, I've also been taught the "the topic is not a sentence, so it should not start with a capital letter". it could even be in the developer pages, but not sure.
<JEEB>
so the linter rule did not come out of nowhere
<BtbN>
It's a pretty common thing to do, and the vast majority of commits already do that
<kierank>
making up rules here
<kierank>
out of the sky
<JEEB>
I'm not feeling too hard about whether to keep that rule or not, but it pretty clearly was not made out of the sky randomly and suddenly
<kierank>
doesn't count but tons of other counterexamples
<kierank>
examples: Add av_freep to avoid potential memory leak
<JEEB>
https://ffmpeg.org/git-howto.html#Writing-a-commit-message has indeed starting with lowercase. and yes, there are most likely both in the history since it was never a hard rule but rather whatever the merging person was OK with
<Lynne>
BtbN: michaelni: why was the revert done immediately?
<jamrial>
michaelni: you merged that in 10 minutes...
<Lynne>
I think the rules were very reasonable
<BtbN>
Cause michael set it to auto-merge on approval, and kierank insta-approved it
<kierank>
jamrial: I pressed approve
<Lynne>
and I don't think this should be done by fate
<kierank>
Coming up with random rules reminds me of a former ffmpeg/libav developer who shall not be named
<jamrial>
kierank: that doesn't mean it should go in if there were concerns
<kierank>
how did it go in to begin with
<BtbN>
Lynne: imo the code linting should be done by fate. But commit message linting (and code to pull them from Forgejo) does not belong there
<jamrial>
with a mr that was not merged in 10 minutes at least, i'd assume
<BtbN>
kierank: we worked on it for days in its PR
<JEEB>
kierank: it clearly was not random if most commits followed the style and the developer docs used that style
<kierank>
rules via telepathy I guess
<JEEB>
but it also was not a forced thing, things got merged without it going through, too
<BtbN>
It's explicitly not a required check
lemourin has joined #ffmpeg-devel
<BtbN>
and only runs on PRs, not master
<Lynne>
BtbN: I think its better for code linting to be done before fate, since its much faster to inform users than waiting for 10 minutes