08:52 mlankhorst: pixelcluster: thanks for testing
08:53 mlankhorst: also 404, on that commit id
10:05 sima: mripard, I guess go ahead with tejun's ack
10:07 mripard: sima: it's pushed already :)
10:08 sima: I'm slow ...
10:08 sima: otoh distracted shouting about a decade old stable entertainment is distracting
10:14 mlankhorst: someone with 2 last names?
10:26 javierm: sima: if reverts are part of the problem, would a `dim revert` that looks up the cherry-pick (and threat them as aliases as you suggest) would help ?
10:27 javierm: and maybe add the same lookup as a check for `dim push`
10:28 sima: javierm, it's all the sha1 references we have, and the only way to get rid of them is to rebase -next
10:29 javierm: sima: right
10:29 sima: we could try to replace them when you do a git revert or git cherry-pick, but that doesn't catch all, and ime it's really hard to make sure it happens consistently
10:29 sima: s/git/dim/ which is part of the issue why they don't happen consistently, because people just use git tools directly
10:30 sima: agd5f has been rebasing amd-next for the longest, and there's been lots of sha1 references pointing to nowhere as a result
10:30 sima: and your average committer has a few decades less experience than agd5f
10:32 javierm: in an ideal world, every subsystem would have a -stable-fixes branch that contains fixes for stable, and the subsystem maintainers (or committers) would cherry-picks from Linus' main branch
10:32 javierm: then stable folks could just pull from those branches
10:33 javierm: that would also make sure that the fixes are not semi-randomly picked and done by people who have enough context to know whether makes sense or not to pick for stable
10:35 lumag: mripard, it seems I can't push to drm-misc-next-fixes, so one of drm-misc maintainers will have to pick up that patch
10:40 MrCooper: isn't it ironic, the same person yelling at people for adding "Cherry picked from" references, then complaining about the resulting lack of information
11:35 jani: drm buddy tests started complaining about unused vars all of a sudden: http://paste.debian.net/1345265/
11:39 jani: https://lore.kernel.org/r/875xmggvcs.fsf@intel.com
12:07 tomba: Can 96b5d2e807f667320c66f41ddc1c473023a73ab2 from drm-misc-next be picked to a -fixes branch? It fixes 3ec5c1579305, which is in drm-misc-next and in drm-next.
12:08 mlankhorst: pixelcluster: you created a fix for dmem, what is the sequence needed to reproduce it in a testcase somehow?
13:18 lumag: mripard, mlankhorst, tzimmermann, daniels: is there a special handling or special set of access restrictions for drm-misc-next-fixes? I'm trying to push a fix to that branch, but i'm getting an error:
13:18 lumag: remote: GitLab: You are not allowed to push code to protected branches on this project.
13:18 lumag: To ssh://gitlab.freedesktop.org/drm/misc/kernel.git
13:18 lumag: ! [remote rejected] drm-misc-next-fixes -> drm-misc-next-fixes (pre-receive hook declined)
13:23 mripard: lumag: yeah, we've been disabling pushing to drm-misc-next-fixes to avoid screwups, but forgot to enable it again
13:24 lumag: :-)
13:26 mripard: lumag: should be good now?
13:27 lumag: mripard, yes, seems to work. Thank you!
13:38 mlankhorst: Ah right, good to remember
22:06 alyssa: jenatali: I implemented the hash-table based printf approach + magic constructors, works like a charm
22:06 alyssa: I'm compiling as C++ already but will need your help making it MSVC safe *sweat*
22:08 alyssa: my wip branch is generating https://rosenzweig.io/libagx.cpp
22:08 alyssa: scroll to the bottom for the printf part
22:09 alyssa: i expect init/deinit can turn it into C++ constructors/destructors with a static object or something? but I don't know the syntax magic off hand and it's 5pm now
22:37 jenatali: alyssa: class <somename> { <somename>() { constructor logic here; } }; static <somename> <somename>_instance;
22:38 jenatali: And then if you need destructors throw ~<somename>() { destructor logic here; } into the mix too
22:39 jenatali: Er, I guess change 'class' to 'struct' so the constructor is public instead of private. But yeah should be straightforward. Maybe even less code than attribute((constructor)) ;)