On 9/9/22 12:52 PM, mm wrote: > Hey Andrew, > > > thank you for your work!! >
Thank *you*! :) > So one by one: > > https://github.com/maiska/qubes-doc.rtd/commit/0b8529a026da0523355eec55c57c1da2aa110d07 > >> By the way, with this one, the link is not actually broken. It still works, >> because your browser adds the missing forward slash automatically. >> Nonetheless, I've committed a fix to make it technically syntactically >> correct. > > With the above commit there several links. I suppose you mean the internal > one: Ah yes, I meant the first one. > it is so, yes, but for the convenience of my stupid script..., but let me > explain: > > Some people, when confronted with a problem, think > “I know, I'll use regular expressions.” > Now they have two problems. > > Well.... :) > Oh, no worries. It ought to be syntactically correct anyway. :) >>> [...] >>> other people's articles linking to the official Qubes OS documentation >>> would be broken, since I do not think that there is a proxy >>> >>> to handle such requests and redirects? Or there is a simpler way? >>> >> I don't understand why links would get broken. Let's use a concrete example >> to help me understand. Take this page, for example: >> >> https://www.qubes-os.org/doc/how-to-update/ >> >> After the migration to RtD, wouldn't this still be the same URL for that >> page? Why would it be any different? >> >> If you're saying it has to be a different URL for some reason, what would >> the new URL look like? > > The new url when generated will look like: > foo.bar/user/how-to-guides/how-to-update.html from rst will look like :doc:` > foo </user/how-to-guides/how-to-update>` > > Domain dependent or whatever... > Oh, so it will mirror the directory structure. I seem to recall that I/we once tried this and decided against it for some reason, but I can no longer remember the details. I also can't recall whether we already discussed mirroring the directory structure for the purpose of this RST conversion and decided to go ahead with it. I suppose that if it's already implemented that way, we can proceed with it and deal with any problems that might arise. (Worst case scenario, we may have to go back and re-implement this part, but hopefully we can just work around it.) >> >>>> Wouldn't converting all Markdown files to RST result in still using the >>>> _doc submodule, just with all the files converted? Maybe I'm not >>>> understanding something here. >>> This could be a possibility yes, perhaps with a sphinx plugin for >>> redirects. It exists, haven't tried it yet. >>> >> Why only "a possibility"? I figured that would be the obvious thing to do, >> but clearly I am missing something. If there is a good reason to do >> otherwise, then that's totally fine! It's just not clear to me what that >> reason might be. > > Nope, you are abs right! > > My motivation behind this solution (meaning leave the docs as they are but > empty etc.) was take it one step at a time w/o necessarily drain time in > fixing possible broken links. Till the documentation is on RTD > > and afterwards the website can be dealt with and properly cleared of any > redundant information (such as in _includes research.html, cause i blank out > translated it > > into flat markdown or rst), > > also than use the sphinx redirect extension, these all are nice to have and > can be done afterwards. > > The possibility was not the right word in this context... > > The HCL and Downloads thus can be addressed later :) > Ok, one step at a time makes sense. > About the pull requests I will look into it latest tomorrow, render and say > if smth is 'missing' > > > One thing though which I did not think about: > > The privacy policy should be 2x - one for the Qubes OS website, and one for > RTD. The one for RTD should be adjusted and perhaps refer to also their > privacy policy: > > https://docs.readthedocs.io/en/stable/privacy-policy.html > I guess it's not obvious to me why that would be the case since we're self-hosting (aren't we?), but if you say we need it, then I don't see why we can't have two. > > But maybe that's okay, since once we migrate to RtD, we'll no longer be > relying on custom scripts like this to populate the table of contents. > > Yes!! Hopefully there will be a lot less clutter :)) > > > git clone -b new-master > --recursivehttps://github.com/maiska/qubesos.github.io.rtd.git > > So, how do I serve the site locally after doing this? Can you provide > step-by-step instructions? > > > On a fedora VM: > > sudo dnf install ruby ruby-devel openssl-devel redhat-rpm-config > @development-tools; > gem install jekyll bundler; > find . -name gem; #(in my case it was /home/user/.local/share/gem/) > git clone -b new-master --recursive > https://github.com/maiska/qubesos.github.io.rtd.git; cd qubesos.github.io.rtd/ > bundle config set --local path '/home/user/.local/share/gem/' > bundle exec jekyll serve > Ah, ok, it looks similar to the standard old method of serving a Jekyll site. Thanks, I'll give it a try when I find some time. Any chance you've gotten this to work in a Debian minimal VM (plus whatever packages are required, of course)? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/032320d2-9081-e79a-0a29-f6980d59164e%40qubes-os.org.
