02:06jcline: You can drop anchors with ".. anchor-name:" I think, I'd have to go check the docs. And then to reference a section within the docs you do ":ref:`anchor-name`" I believe
02:07jcline: https://www.sphinx-doc.org/en/3.x/usage/restructuredtext/index.html should cover the basics
12:38karolherbst: oh wow, google even tells me what users saerch for and what links they clicked
12:38karolherbst: interesting :)
14:53jcline: karolherbst, should I use the logo the nouveau twitter account is using for the sphinx project and if so do you know where the source lives? I didn't see it on the existing wiki anywhere.
14:53karolherbst: yeah.. I think the source is lost? dunno
14:54karolherbst: jcline: but I was thinking about if we should at least for the beginning try to patch the style of the existing wiki or not
14:54karolherbst: I have many opinions on that, but no conclusion on if it matters or not
14:56jcline: Aha, https://lists.freedesktop.org/archives/nouveau/2014-November/019164.html
14:57karolherbst: yeah.. but as source I was more thinking about a SVG file :p
14:58jcline: Yeah :(
14:58jcline: Maybe if I email them they still have it sitting around. Bit of a long shot, I suppose.
15:52mupuf: karolherbst: I should still have the name of the source
15:52mupuf: jcline: I should have it somewhere
15:56mupuf: i have at least one
15:58mupuf: jcline: https://fs.mupuf.org/logo-nouveau-solo.svg
15:59mupuf: You however need to attribute the work to Valeria Aguilera as the logo is under CC-By license
16:00karolherbst: finally the SVG! :D
16:05mupuf: I guess we should vectorize the "Nouveau" part
16:05mupuf: from the jpeg
16:06mupuf: nevermind, got it
16:06mupuf: will send it in a bit
16:58jcline: Cool, thanks!
17:09mupuf: jcline: http://fs.mupuf.org/nouveau_logo.svg
17:09mupuf:should add them both to a page in nouveau's wifi
17:10karolherbst: mupuf: question is, do you want to do that in gitlab or with the old cgi thing :p
17:11karolherbst: I am quite close to just tell daniels to flip the switch
17:11mupuf: flip the switch to what? kill ikiwiki?
17:11mupuf: or port the wiki?
17:11karolherbst: just to move to gitlab pages
17:12karolherbst: rewrite the subdomain to that
17:12karolherbst: it's the same thing, just on gitlab and with the gitlab CI
17:12karolherbst: just allows random users to file bugs and MRs
17:13mupuf: well, if you are waiting for acks, I agree about killing ikiwiki
17:13karolherbst: it still uses ikiwiki
17:13karolherbst: but I sent out emails on that to the ML
17:13mupuf: ok, let me read them
17:13karolherbst: jcline is working on writing some new stuff based on sphinx
17:13karolherbst: but that will take a while I guess
17:14mupuf: let's just say that I haven;t been following Nouveau development too much in recent years
17:14mupuf: too many things to address
17:28mupuf: Lyude: Yeepee, you sent patches to IGT for crc-based testing!
17:28mupuf: need a review on that?
17:40Lyude: mupuf: lol, surprised at the offers for review
17:40Lyude: mupuf: it's already been pushed upstream (it'd been waiting on the list for a while, I eventually got jcline to review it)
17:41Lyude: mupuf: if you're curious, on the igt front the next step I'm working on is getting nvidia's tiling formats supported in igt since that should hopefully get a bunch of the kms_plane tests going
17:48mupuf: Lyude: sounds good! Ask me for review for IGT tests for nouveau
17:48mupuf: that's something I can do now, at least!
17:48Lyude: awesome :D
17:48mupuf: I have more time now, as I left Intel yesterday to start my contracting company
17:49Lyude: ooh sweet
17:49mupuf: indeed :) I will be mostly working for Valve on improving Linux gaming.
18:01karolherbst: Lyude: I guess you are also okay with us moving the wiki to gitlab?
18:01Lyude: karolherbst: yes, as long as kdocs don't get ignored i'm fine with whatever works best :)
18:02karolherbst: well, this is just for moving stuff for now :p what we do with it after is completlely up to us
18:02Lyude: ideally too, it'd be really, really really really nice if we could get a more normal workflow with nouveau in terms of working with the kernel
18:02Lyude: just, putting that out there
18:02karolherbst: I think there is this "secret" plan to move skeggsb nouveau tree to gitlab as well
18:02karolherbst: under the nouveau team
18:02Lyude: for reference, nouveau is one of the drivers I work the most on, and it's also one of the only things I work on often that I don't have commit access...
18:02karolherbst: but.. yeah.. no clue
18:03karolherbst: I think having MRs would already help a lot :p
18:03karolherbst: just to better track things
18:03karolherbst: but no idea how that entire workflow would look like with an out of tree thing
18:03karolherbst: we probably would need to move to a proper kernel tree as the main thing then
18:03Lyude: karolherbst: yeah but i mean, I'm thinking mostly in the cases where I'm working on nouveau with DP, where there's a lot of overlap between drivers and helpers and nouveau
18:04jcline: karolherbst, so it looks like the sphinx folks don't maintain a "3" docker tag and afaik docker doesn't do clever semantic version processing so we can't just say "give me sphinx major version 3"
18:04karolherbst: anyway, I think there are a couple of things we should improve
18:04karolherbst: and if we stop posting patches on a Mailing list that would be a huge win already :p
18:04Lyude: having something that builds into drm-tip for instance would be _REALLY_ helpful
18:05Lyude: ...also, having responses for when i get my patches reviewed would be nice.
18:05jcline: We we can either pin it to a version like 3.2.1 and try to remember to update it, or use pip
18:05karolherbst: jcline: oh really? that's annoying..
18:05karolherbst: yeah.. I guess we could use pip then
18:06karolherbst: but I think it makes sense to move to python:slim in that case
18:06jcline: None of the options are completely "never think about updating things ever" so I suppose it's really just a matter of what we want to very occasionally think about
18:06karolherbst: should reduce the bandwidth need a little
18:06karolherbst: we just need to install pip I think
18:06Lyude: karolherbst: while I do really want to move away from MLs I do worry about how that's going to work with other parts of the kernel if we drop it before they do
18:06karolherbst: Lyude: well... sure :/
18:07karolherbst: I don't see the kernel moving over to something else any time soon as there is always this "dude" with the custom workflow everybdoy else hates
18:07jcline: Hm. I wrote a silly little project to turn mailing list posts to gitlab MRs and the reverse
18:07jcline: Not that I'd *really* recommend using it, but it's possible
18:07Lyude: well, sure, but that doesn't really change the fact it'd become even _more_ difficult then it already is to coordinate efforts that actually work on both nouveau and other drivers at the same time
18:07karolherbst: Lyude: for drm we might be able to do one thing
18:08karolherbst: just need to talk with the others
18:08Lyude: yeah, if other subsystems can get on the plan I'm fine with it
18:08karolherbst: for the kernel I am just not seeing it if subsystems don't do it first
18:08karolherbst: if all of drm moves over to MRs, that would be sufficient enough
18:08karolherbst: as it really doesn't change anything
18:08karolherbst: Linus still has to merge all together anyway
18:09Lyude: karolherbst: i mean, the way I see it as long as linux isn't using MRs we will always need -some- way of accepting patches, since if other folks in the kernel need to make changes that's how they're going to be sending them to us :P
18:09Lyude: but i'm sure the other drm folks are more then aware of this
18:11karolherbst: it would be interesting to know if something like gitlab even scales for a project like the kernel
18:11karolherbst: or if people would just constantly have to rebase/resolve conflicts
18:11karolherbst: anyway, this is already an issue today
18:12karolherbst: and using gitlab or MLs has 0 impact on this
18:12jcline: Well people have to rebase/resolve conflict whether it's in email form or left in a git branch
18:12karolherbst: normally linus does it when he merges stuff in his tree
18:13karolherbst: of course we also have several drm driver trees
18:13karolherbst: and maybe we could do something for that..
18:13karolherbst: well.. dunno
18:13karolherbst: I just don't see it affecting anything
18:13jcline: Right, in my brief tenure as a kernel maintainer for various red hat kernels I had to deal with that sort of stuff as well and the whole process made little sense to me, given how most projects handle it. But yeah, that's a whole different discussion
18:40jcline: mupuf, do you happen to know under which version of the cc-by the logo is available?
18:46mupuf: jcline: Attibution 4.0 International (CC BY 4.0)
18:47jcline: Perfect, thanks
18:47mupuf: these are the exact words from the author, including typos ;)
18:53karolherbst: mhh.. we could embeded that inside the SVG, but that looks like a bit of work figuring out the XML stuff
19:01jcline: I could possibly manage it with inkscape. Do you think the attribution at the bottom of the page isn't acceptable?
19:01mupuf: karolherbst: done
19:01mupuf: jcline: yeah, I used inkscape to add the metadata
19:18comradekingu: 3860x2140 monitor in 2140x3860 (vertically) stopped working after Linux 5.4. Just me?
19:29karolherbst: comradekingu: probably. Maybe it was fixed
19:29karolherbst: 5.4 is EOL
19:29karolherbst: ehh.. wait
19:30karolherbst: 5.4 is not EOL :D sorry, my bad
19:30karolherbst: but maybe it is indeed fixed on a newer kernel if you are able to try that out
19:33comradekingu: karolherbst: It is broken on anything beyond 5.4.02 for me on devuan 4.0. Tried up to 5.8
19:33karolherbst: ahh, okay
19:34karolherbst: I actually have a laptop here with a 4k display I could try it out
19:34karolherbst: what are you using to rotate the screen?
19:34karolherbst: just the normal display settings or something else?
19:35comradekingu: karolherbst: The control panel settings in MATE
19:35karolherbst: I guess that is still X, correct?
19:35karolherbst: I wrote a note and hopefully I don't forget to check later
19:37karolherbst: jcline: it would possible be enough, I just like to have the license inside the metadata if possible so we don't miss it later
19:37karolherbst: now it is there forever (hopefully) :)
19:45jcline: Makes sense, I initially thought you meant as visible text below the logo