00:44Lyude: hm. so, NOUVEAU_GETPARAM/NOUVEAU_SETPARAM are deprecated, but we also use them libdrm in nouveau_device_new() which is not deprecated
00:44Lyude: *them in libdrm
01:40Lyude: oh-hold on, i'm misreading, that's compatibility code
07:05pmoreau: karolherbst: Thank you for starting the transition for the wiki. I have absolutely nothing against it (and even pretty happy that this is happening).
07:05pmoreau: I opened a first MR with some small fixes. Running the wiki locally works fine, though I don’t understand why it tries to automatically pull first.
10:49karolherbst: pmoreau: ikiwiki has a git plugin doing... weird shit
10:50karolherbst: it's kind of build in a way that it thinks it's the one managing the git repo
10:50karolherbst: there are also some issues once you have branches and remove them and stuff
10:50karolherbst: but I would just mark the master branch as protected (to prevent force pushes) once migrationg is complete and disallow creating any branch
10:51pmoreau: The protection sounds good
10:57karolherbst: pmoreau: also, your MR doens't change anything :p
10:57karolherbst: with HTML5 anchoring on name _and_ id works
10:57karolherbst: and name is obsolete anyway
10:58karolherbst: so using the id is the proper way of doing it now
10:58karolherbst: and those a name= tags should go away
10:58pmoreau: It didn’t work locally for me, for some reason.
10:59karolherbst: both works online
10:59pmoreau: Yeah, I just tried the online version and it works.
11:00karolherbst: yeah.. let me test locally as well
11:01karolherbst: but it also looks different locally anyway.. I think there is some stuff going wrong when opening the files directly..
11:01karolherbst: can't find the index.css file
11:01karolherbst: but the link works
11:02karolherbst: "/wiki/index.css" yeah... well that won't work
11:03pmoreau: I switched back to the master branch, and the links do not work locally: it does switch to the document but does not go the anchor.
11:04karolherbst: what browser are you using?
11:05karolherbst: it works here with both chromium and firefox
11:06pmoreau: Using Firefox 81.0
11:06pmoreau: Getting the same behaviour in Chromium as well
11:07karolherbst: can you check what id tags you have?
11:07karolherbst: those seem to be generated actually
11:07karolherbst: markdown subtitle -> id or something
11:08pmoreau: No ID whatsoever in the generated code.
11:09pmoreau: I have IDs for pagebody, searchform, searchbox, content, footer, pageinfo and backlinks
11:09pmoreau: But that’s it
11:10karolherbst: did you install this multimarkdown perl module?
11:10karolherbst: anyway, fixed the css file loading issue for local builds: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/9
11:11pmoreau: I have perl-template-plugin-multimarkdown, perl-text-multimarkdown, and perl-text-multimarkdown-xs installed, so I think so?
11:11karolherbst: let's see...
11:14pmoreau: I’ll need to find a way to disable the git plugin part, cause it is annoying to need to commit before being able to generate the local version.
11:15karolherbst: ehh.. I don't think you need to commit actually
11:15karolherbst: but.. the issue is, without the git plugin we don't get those fancy links...
11:15karolherbst: you can just disable it and see what happens ;p
11:18pmoreau: Ah yeah, still seems to be working without commiting.
11:18karolherbst: pmoreau: do you have Text::Markdown::Discount
11:20karolherbst: seems like it's just the discount command line tool actually
11:20karolherbst: or uhm.. something
11:24pmoreau: I do have discount installed
11:24karolherbst: no idea if that's the difference or not
11:24pmoreau: I can try disabling it
11:24karolherbst: but I doubt we want to depend on generated ids
11:29pmoreau: Probably not; and I agree with replacing the name with IDs.
13:11rowbee: i think resuming from hibernation is executing my VBIOS twice, and my laptop's VBIOS is not idempotent
13:11rowbee: is there anyway i can test this?
13:11rowbee: when i resumed from hibernation i get blank screen
14:44RSpliet: rowbee: I like how you go beyond observing the problem and try and get to the root cause! However, I do wonder what makes you suspect that your problem (blank screen after resume-from-suspend-to-disk) is caused by double VBIOS execution
14:44RSpliet: Or rather, double-execution of just the resume script :-)
14:45rowbee: NvForcePost also caused black screen in the past
14:45rowbee: and someone in this channel said it's because some OEMs have broken VBIOSes which fail when executed twice
14:45rowbee: so i guessed
14:46rowbee: correction: blank screen
14:46rowbee: the panel doesn't turn on
14:46RSpliet: Haha well you're not wrong about OEMs shipping broken VBIOSes.
14:47rowbee: i can upload my VBIOS if you want. i'm on the windows partition right now but i can switch over
14:47RSpliet: Do you have access to the machine after resume through other means (SSH, serial console.. pick your poison)?
14:47rowbee: oh yeah i could certainly try that
14:47RSpliet: Perhaps it'd be good to first try and extract some logs from a resume
14:47rowbee: just need to give it a static ip and start sshd
14:48rowbee: gotchu, will try that
14:48rowbee: ty for the help
14:48RSpliet: no worries
14:48rowbee: btw i emailed mr. skeggs about the devel-clk tree and whether some of the patches there are needed but i got no response... i suppose he is busy
14:49RSpliet: Yeah he's a very busy bee
14:49rowbee: i see.
14:49rowbee: i was just wondering whether the memx patches there are still needed
14:49rowbee: i merged in about 10 of the bigger patches into 5.8.10 but didn't continue
14:50RSpliet: Nouveau is currently being carried by three people. And NVIDIA just released ampère. And Vulkan is a thing these days that nouveau should support. Oh and general maintenance too. I can guess how much time they got spare :-P
14:50rowbee: ahh yeah nobody wants to deal with fermi when fermi 2.0 is out
14:50rowbee: with all the associated housefires
14:51rowbee: 500W power draw yeesh
14:51RSpliet: Winter is coming
14:51RSpliet: With a bit of luck people can turn off their gas-powered heating now
14:51RSpliet: this year
14:53rowbee: make sure your wood screws are tightly screwed
14:53rowbee: wouldn't want exploding cards
17:31karolherbst: pmoreau: mhh.. actually.. we could get rid of the git plugin, it would just mean we have to put more stuff into our own ikiwiki plugin
17:31karolherbst: and maybe that wouldn't be all that bad..
17:32karolherbst: but I actually wanted to have less ikiwiki specific things :D
17:38jcline: I'm happy to convert it to Sphinx Restructured Text
17:39jcline: as long as folks don't care about the custom html stuff it shouldn't be terribly difficult
17:40jcline: Plus that way you only have to know one markup language/doc builder for the kernel docs, the nouveau docs, and envytools docs
18:52Lyude: hey - do we still use that old trello board for nouveau?
18:58karolherbst: more or less
18:59karolherbst: jcline: mhh.. but that means moving away from markdown
19:00jcline: Well, you're still going to have to know rst if you want to document stuff in the kernel or envytools, right?
19:00karolherbst: anyway.. we wanted to remove this google translate html stuff anyway
19:01Lyude: +1 for rst imho
19:01karolherbst: jcline: so? the wiki isn't the kernel doc
19:01jcline: I think markdown is fine, but basic rst is pretty similar
19:01jcline: Sure, but presumably the same people will be contributing to documentation
19:01karolherbst: yeah.. I am just not too fond of just converting it before we did some basic cleanup and fixed issues we still had from the last conversion :p
19:02karolherbst: jcline: why would it be the same persons?
19:02karolherbst: the wiki is there for everybody, not just us developers
19:02Lyude: tbh though I don't mind markdown or rst on the wiki, as long as we don't entirely neglect nouveau's kernel docs
19:02karolherbst: right, but those are two different things, and both need their own attention
19:03karolherbst: having the same syntax in both doens't help with people not updating stuff
19:03jcline: Well... I guess. I mean, historically it's not been editable by everyone
19:03karolherbst: hence the move to gitlab
19:04karolherbst: converting the syntax won't help with anything and just leave more issues caused by converting
19:04RSpliet: Yeah, curated edits can be helpful to increase visibility with a low risk of spam or defacement
19:04karolherbst: this already happened the last time
19:04karolherbst: and it was never fixed
19:05jcline: I'd advocate for a complete reorganization in any case
19:06karolherbst: yeah, and I think we need to do that. Also just throw out stuff we don't need anymore, etc...
19:06karolherbst: I just didn't want to do everything at the same time, because then it will never happen
19:06jcline: Which means going through everything there is currently anyway, and running each doc through pandoc isn't really the hard part of that task
19:08karolherbst: well, you need to verify the result
19:08jcline: And again, I'm happy to do it, and I will do it, assuming people are on-board with moving to sphinx.
19:08Lyude: i'm happy to help too even though i get distracted easily
19:08karolherbst: well, I have no technical comments at this point as I have no idea what advantages or disadvantages it will give us
19:09karolherbst: my biggest worry is just, that it will be never finished, like the last time ;)
19:09karolherbst: so doing it without any benefits is not a good starting point to justify something which will haunt us in 5 years still
19:10karolherbst: or it is a ton of work and still doesn't give us any benefits
19:10karolherbst: switching to a different tool, but keeping the syntax etc.. _is_ something I would be on board with as I suspect there are advantages
19:10karolherbst: just not a friend of changing the file format
19:11jcline: Are you saying selecting sphinx will haunt us in 5 years time, or that the conversion will take 5 years?
19:11karolherbst: jcline: well... there are still remaining issues from the time the wiki got ported to ikiwiki
19:11karolherbst: and that was more than 5 years ago
19:11jcline: Are those issues tracked somewhere?
19:12karolherbst: some is here: https://nouveau.pages.freedesktop.org/wiki/conversion.html
19:13karolherbst: but there are also tons of broken [[!img]] declarations
19:13Lyude: also reminder that ikiwiki might not be around forever ;P
19:13karolherbst: sure, but I already said I am fine with changing the tool as this is way easier than changing they file format
19:14karolherbst: and I kind prefer files not being tool specific anyway
19:14karolherbst: and for that we already have tons of stuff to do
19:14karolherbst: jcline: the issue is, that pandoc won't be able to convert the files
19:14karolherbst: so you have to fix it all by hand
19:14jcline: I think the fact that I can't find that conversion page from the wiki homepage speaks to the usability of the wiki as-is
19:15karolherbst: it is there though.. somewhere :D
19:15jcline: I did not have a positive experience reading through the wiki when I was getting started a few weeks ago
19:15karolherbst: I mean.. we can also start from scratch, but that won't work either
19:16karolherbst: but, I prefer simple changes over "change the world" thing, because the latter won't ever be finished
19:16karolherbst: also, I have nothing against just removing pages we think are useless
19:17karolherbst: I am just convinced that "starting from scratch" will cause more issues than benefits (tons of links break from other wikis, users don't find anything anymore, etc...)
19:18karolherbst: and I am already worried that I broke links by flattening the hierachy
19:19jcline: Well, we could leave what there is now with a big banner at the top pointing to a new location if breaking links is a concern
19:20karolherbst: it's not about the location
19:20karolherbst: it's about the structure of pages
19:20karolherbst: the wiki is actual user facing documentation and tons of other pages are linking directly into sub pages
19:21karolherbst: and before we break all of that and teal everybody to suck it up and just fix it, we need a _strong_ reason to annoy users and wiki maintainers with it
19:21jcline: Yeah, I understand, what I mean is just leave the old pre-pages thing (that's when you flattened things, right?) and start "fresh"
19:22karolherbst: then we have two wikis
19:22jcline: Add a big banner at the top saying the old one is just there to avoid breaking links and give them a URL to the new one.
19:23karolherbst: we could also be good and place redirects
19:23jcline: I mean, if you can't re-organize the existing wiki because it'll break links and we can't have two locations there's not much we can do
19:24karolherbst: I will probably add a html file we can just copy to the old locations to do the redirection and stuff
19:24karolherbst: the index.html were also just causing problems for the MR previews
19:24karolherbst: but there is no other benefit
19:24karolherbst: or.. I think the MR preview was fine
19:24karolherbst: local generation was broken
19:27karolherbst: anyway, I am not against switching the format or switching to a different tool or even just starting from scratch. We just should avoid "having two systems", "breaking links" and have a good reason to spend time on conversions
19:28karolherbst: just converting for the sake of it isn't something we should do at this point as focusing on the content is imho more important
19:28karolherbst: and anything talked about here wouldn't have helped with that actually
19:29karolherbst: and I am convinced it would actually prevent us from working on the actual content as we are busy with all the other things instead
19:33jcline: Well I'm new and I don't think I have a particularly good chance of convincing you otherwise
19:34karolherbst: it has nothing to do with you being new, just I don't see what benefits the conversion would give us, or what problem it will solve we have with the wiki currently
19:35karolherbst: I just see a dozen of potential problems, but no benefits
19:37jcline: What I mean is, you have no particular reason to take my word for it and I don't know what benefits exactly you're looking for
19:38karolherbst: well, the benefit we get from migrating to gitlab is, that users can submit changes. In the past people were asking randomly if the wiki could be updated, or poked us at stuff we should update.
19:38karolherbst: stuff like that
19:38karolherbst: another issue is, that content is just outdated, but converting to a different tool won't help with that, so we should focus on the actual issue: improve the pages, remove old stuff.
19:39karolherbst: If we have the long term goal of moving away from ikiwiki, removing all ikiwiki specific things in the markdown files is also a good way to start
19:39karolherbst: and would have to be done before converting anyway
19:39karolherbst: it's just a way smaller task and has the benefit of us being less dependent of ikiwiki
19:41karolherbst: and I assume sphinx can also just eat markdown files, no?
19:44karolherbst: so what I would rather see is, that as one task we just remove all ikiwikiism from the markdown files. Then we can see how we can make sphinx work and just move over. And in none of those steps we would end up with "two wikis being incompatible"
19:44karolherbst: I just dislike those big steps doing everything at once
19:44karolherbst: as that will bite us for sure
19:49jcline: To me it just seems that, if you know you want to end up on Sphinx, it's such a tiny part of the cleanup work it makes sense to batch together. If you don't agree that's fine, we'll clean it up and then reorganize it again as it gets moved to sphinx.
19:50karolherbst: why would we need to reorganize when we move to sphinx?
19:50jcline: I think a wiki isn't exactly what this should be anyway, it should be a structure doc project
19:52karolherbst: I just don't understand why we have to do everything in one step
19:52jcline: Wikis seem fine when it's a grab-back of maybe-not-related pages and you're fine with eventual consensus, but for a single software project I don't see the point
19:53karolherbst: right.. the term wiki might be wrong, but we still need to call it something
19:53karolherbst: and it's fine if everybody can suggest edits
19:53karolherbst: we are not a closed source software company which has to provide 500 pages of docs, all written by us :p
19:54karolherbst: and if uses want to add new pages because they show something, that's also fine
19:54karolherbst: this discussion is entireley unrelated to moving over to sphinx ;)
19:55karolherbst: sure, we could start something entirely new to document something
19:55jcline: I'm not suggesting that, I'm just saying the structure now is there isn't much structure
19:55karolherbst: but then we shouldn't talk about migrating things, but starting something new
19:55karolherbst: ohh, right
19:55karolherbst: but we can fix that, without having to change the tool
19:55karolherbst: or we can change the tool without having to fix the structure
19:55karolherbst: that's all what I am trying to say
19:56karolherbst: sure, we might want to do all of those things
19:56jcline: And I understand that, and what I'm saying is the documentation worth saving is small enough that I don't see the point of making a bunch of passes at fixing it
19:56karolherbst: we can also have the first pass removing everything we don't need
19:56jcline: but if that's what has to be done, that's what has to be done
19:58karolherbst: _but_ I just would like to have a state where we have everything in we agree is worth saving and everythign else was removed
19:59karolherbst: eg we could just remove those VDPAU and XvMC pages and just link to somewhere else
20:33Lyude: imo - my five cents is that we really do need a redo of our docs, even if it's some effort
20:35Lyude: personally i got pretty confused by a lot of the basic concepts in nouveau and most of them aren't even that complicated, it's just the only documentation is the code which also has abbreviations all over the place that aren't obvious, and is just generally a bit exotic compared to most GPUs out there. and as it is our docs are pretty incomplete/broken as it is right now
20:37Lyude: and i think too jcline, at least from what i've gathered from our discussions, needs to learn a lot of the basic concepts anyway so they seem like the perfect person to do it right now in terms of time commitments. it would be a bit different if it was me asking for this change for instance, i don't have the time to fix all of those docs
20:38Lyude: and eventually jcline won't either, but they do now, so I think we should just roll with it and go from there.
20:38Lyude: lowering the bar of entry to nouveau development will be the gift that keeps giving anyway
20:41dcomp: For what it's worth. I'm trying to read the code in the little spare time I have, a high level architecture document would be nice. And then maybe I'll be able to write a patch that fixes my card.
20:46jcline: Thanks Lyude, that's basically what I was trying to get across, but much less concisely and clearly.
20:49jcline: I've got many years of programming experience at this point, but nouveau has been extremely difficult to get into because of the abbreviations, lack of documentation, etc. As I learn pieces it turns out it's not complicated and it's extremely frustrating to spend a bunch of time trying to divine everyone's intent with code you're not sure even works sometimes.
20:52jcline: I've accepted it's going to be a painful process for me, but I'm being employed to do this and if I can at least document everything that will make the pain less irritating
20:52karolherbst: jcline: but those are things we want to document inside the nouveau source code tree, no?
20:53jcline: And no one has any expectations about me being productive right now anyway, so you can really view this as an opportunity to get me to do a lot of work I assume you'd rather not have to deal with
20:54jcline: Well sure, you need API documentation, but you also need user guides and developer guides, and it needs to be organized in such a way that every user can find their respective documentation
20:54jcline: and to be blunt, as it stands, that is not the case
20:54karolherbst: right, but I would focus on user guides inside the wiki, I think... not sure how to split up devleopers guides between in tree and external documentation
20:57jcline: Yeah, my impression from the discussion on the kernel-side docs was that the "wiki" would be end user documentation and anything not specific to the kernel and envytools would be hardware specific documentation
20:58jcline: Obviously all three of these places need to stand on their own, but also cross reference each other. It's less than ideal for a project to have three separate documentation locations, but that's apparently the situation. And because of that I think each location needs to be super clear about its focus
21:00jcline: And that's one reason having a wiki is confusing, because it implies a sort of "whatever people want to add wherever they want" situation. So moving to a reviewing docs before inclusion is good, obviously, but it also needs sorting and shuffling around to the correct sub-project and so on
21:00karolherbst: yeah, and that's fair
21:01jcline: And yes, I'm an anecdote, but if the docs fail someone with a decade of programming experience who's being paid to work on the project, that's a problem.
21:21Lyude: karolherbst: we want to document them in the kernel tree yes
21:21Lyude: but, they're not documented in the kernel tree
21:21Lyude: but i mean the kernel aren't the only bits here that need docs I'd imagine, or if they are then we should just be using kdocs
21:38Lyude: jcline: also on your last comment, i honestly completely agree with you lol
22:04karolherbst: jcline: yeah, the docs need to be improved and I doubt there is really anything useful for actual developers on the wiki, except maybe some background information which doesn't really help all that much either anyway
22:05karolherbst: and I think it might make sense to have _some_ developer focused stuff there, like background information, link list of nvidia whitepapers, interesting technical things we link to, but I don't think it makes much sense to add proper technical documentation in there.. dunno
22:05karolherbst: maybe it does
22:05karolherbst: maybe it does not
22:05karolherbst: I just think having that in the wiki will fall victim to become outdated sooner or later, and if you put that technical stuff in the source tree, you force people to update it :p
22:06karolherbst: and I think everything saying anything about the actual source code, should be where the source code is
22:06karolherbst: but besides that? no idea what makes sense at this point
22:08jcline: I definitely agree with stuffing as much developer-focused documentation in the source tree (and, in fact, in the source files as close as you can get them to whatever they're talking about)
22:08karolherbst: jcline, Lyude: uff.. btw "20,172 links from 991 websites point to nouveau.freedesktop.org"
22:09karolherbst: there are some nice web tools analying this stuff for us :)
22:09karolherbst: but it's worse than I thought it is :D
22:09jcline: To be honest, I think it's probably best to start with just leaving the old site as-is while sorting out the organization of a new one
22:09karolherbst: yeah.. I doubt
22:09karolherbst: I really don't think we want to have two systems at any point. This never works
22:10karolherbst: as long as we only think about how it should be.. maybe that's fine
22:10karolherbst: but then we could also just already improve things already
22:10jcline: Well, it's not like the old wiki was updated particularly often, based on the logs
22:10karolherbst: but I think removing pages is something we can do anyway
22:10karolherbst: and it will help with the new thing as well
22:10karolherbst: as it reduces the content we need to focus on
22:11karolherbst: I have an idea
22:11karolherbst: maybe I check what pages are never linked to, and we just remove those first
22:11jcline: I'm going to start on a sphinx site and as I sort through things I'll run it by you
22:11karolherbst: as... obviously, those are quite useless :p
22:12jcline: I think the amount of content worth moving over is quite manageable for one person, unfortunately
22:12karolherbst: I would just keep the links intact
22:12jcline: If you hate it, the only person who wasted any time was me, and I probably learned stuff along the way
22:12karolherbst: but I also don't think it's actually needed to move things :p
22:12karolherbst: jcline: but.. couldn't you just use markdown with sphinx?
22:12karolherbst: then you could just reuse the same files
22:12karolherbst: and actually focus on the content
22:13jcline: Yeah, but the raw html (which seems to be quite pervasive) is the only difficult part
22:13karolherbst: then sphinx migration is like a few minutes and the other time you spend on the actual content
22:13karolherbst: jcline: it's all google translate
22:13karolherbst: we just remove it :p
22:13karolherbst: I think...
22:13karolherbst: maybe there is more?
22:13jcline: There's more than just that based on my skimming
22:13karolherbst: might be worth checking those.. but I don't think it's that much actually
22:14karolherbst: let's just remove the google translate stuff first and see how much is left
22:14jcline: anyway, I can't stress how easy it is to turn markdown into rst and back with pandoc
22:14karolherbst: but we don't have strict markdown :p
22:14karolherbst: so a markdown to rst converter will fail
22:14jcline: Right, which is a whole separate problem with the wiki
22:14jcline: which is why I think using rst is better and clearer
22:15karolherbst: might be
22:15jcline: Or picking a widely supported flavor of markdown
22:15Lyude: that, and rst is what the kernel docs use
22:15jcline: But rst is more flexible than markdown typically
22:15karolherbst: yeah. I agree that rst is more flexible I think
22:15jcline: And what envytools uses. I see value in unifying behind a single format and tool to build the docs.
22:15karolherbst: and maybe all the ikiwiki specific things we have can be expressed in rst
22:15karolherbst: but not in markdown
22:16karolherbst: jcline: I have an idea actually...
22:16karolherbst: or maybe I don't... mhh
22:16karolherbst: no, I have
22:16karolherbst: jcline: so we have a couple of pages being pure markdown, hopefully
22:16jcline: Anyway, I'll run a sphinx version by you once I flesh one out a bit
22:16Lyude: also imho, might be a good idea to start focusing on the kernel docs first since that's what most kernel devs are going to default to
22:16karolherbst: and maybe a handful of pages which would require being rst
22:17karolherbst: jcline: maybe, we could leave the pure markdown pages _as_is_ and only convert the ones requiring being rst
22:17Lyude: but i'll leave that up to you
22:17karolherbst: and this way it's less work overall?
22:17karolherbst: but the pure ones can be converted automatically anyway.. mhh
22:17jcline: I'm definitely going to continue poking the kernel docs along, my interest in the wiki largely stemmed from the question of what goes where
22:17jcline: Really, seriously, markdown to rst is not the part that will be work
22:17karolherbst: maybe you can focus on the kernel docs bits first, and I try to clean up the wiki
22:17karolherbst: without changing too much around
22:18karolherbst: and then we can see what we do we the cleaned up stuff
22:18jcline: Making sure the content is actually correct will take far, far more time
22:18karolherbst: and I am convinced that removing useless things helps here to reduce the stuff we want to rework
22:18karolherbst: I just want to know what other websites are linking to first
22:19karolherbst: and at least keep those used pages existing even with sphinx+rst or something
22:19Lyude: tbh i don't even think reworking is a priority, like you said there aren't really a whole ton of useful docs as it is even for developers
22:19karolherbst: there are some useful end user bits though
22:19karolherbst: users like our feature table for whatever reason :p
22:19Lyude: sure - but those are few and far between
22:20jcline: I have to go deal with dinner, have a good one folks
22:20Lyude: and tbh - those are usually the only parts i've found useful :)
22:20Lyude: jcline: see ya
22:20karolherbst: anyway, brings us back to know what other websites link to :p
22:20karolherbst: jcline: have fun
22:20karolherbst: Lyude: anyway.. first step is to keep the URLs the same and move from the old infra over to gitlab
22:20jcline: I'll whip up something tomorrow, I think seeing what things could look like will be good
22:20karolherbst: and then we can just clean the heck up in that
22:20karolherbst: ohh sure
22:21karolherbst: I just want to know what we have to keep and what not
22:21karolherbst: and I assume even with sphinx we can make sure that links won't break, can't we?
22:34RSpliet: jcline: thanks for stepping in by the way!
22:57karolherbst: ehhh.. what a terrible hack: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/11