Thread: theme to use while building docs
Hi, While building docs on EL7 and F-23, I got this error: "no theme named 'classic' found (missing theme.conf?)" The reason is that sphinx in these distros don't have the classic theme. So, I can patch docs/en_US/conf.py , and change html_theme = 'default' in these distros. However, that will be a hack. Is this something we can fix upstream, or should I really patch it myself? Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
Hi, Any comments on this? I put 1.1 RPM package announcement on hold until we have a fix for this. Thanks! Regards, Devrim On Sat, 2016-11-12 at 22:54 +0300, Devrim Gündüz wrote: > Hi, > > While building docs on EL7 and F-23, I got this error: > > "no theme named 'classic' found (missing theme.conf?)" > > The reason is that sphinx in these distros don't have the classic theme. So, > I > can patch docs/en_US/conf.py , and change > > html_theme = 'default' > > in these distros. However, that will be a hack. Is this something we can fix > upstream, or should I really patch it myself? > > Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
On Sat, Nov 12, 2016 at 7:54 PM, Devrim Gündüz <devrim@gunduz.org> wrote: > > Hi, > > While building docs on EL7 and F-23, I got this error: > > "no theme named 'classic' found (missing theme.conf?)" > > The reason is that sphinx in these distros don't have the classic theme. So, I > can patch docs/en_US/conf.py , and change > > html_theme = 'default' > > in these distros. However, that will be a hack. Is this something we can fix > upstream, or should I really patch it myself? Hmmm. It's because the version of Sphinx for EL7 and friends is really quite old. We could probably add some Makefile magic to detect and change it, but frankly it's probably easier (and will certainly be much quicker) for you to just patch conf.py. Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi, On Mon, 2016-11-14 at 09:41 +0000, Dave Page wrote: > It's because the version of Sphinx for EL7 and friends is really > quite old. Right. > We could probably add some Makefile magic to detect and > change it, but frankly it's probably easier (and will certainly be > much quicker) for you to just patch conf.py. Ok, I can patch for now, but given that EL7 will be out for a long time, if there is a Makefile hack for next versions, that would be awesome. Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
Hi Dave, On Mon, 2016-11-14 at 09:41 +0000, Dave Page wrote: > Hmmm. It's because the version of Sphinx for EL7 and friends is really > quite old. We could probably add some Makefile magic to detect and > change it, but frankly it's probably easier (and will certainly be > much quicker) for you to just patch conf.py. Ok, patched conf.py. That said, Sphinx in EL6 is 0.something, and even does not accept the default parameters. We may want to disable docs builds on EL 6. Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
On Wed, Nov 16, 2016 at 9:16 AM, Devrim Gündüz <devrim@gunduz.org> wrote: > > Hi Dave, > > On Mon, 2016-11-14 at 09:41 +0000, Dave Page wrote: >> Hmmm. It's because the version of Sphinx for EL7 and friends is really >> quite old. We could probably add some Makefile magic to detect and >> change it, but frankly it's probably easier (and will certainly be >> much quicker) for you to just patch conf.py. > > Ok, patched conf.py. That said, Sphinx in EL6 is 0.something, and even does not > accept the default parameters. We may want to disable docs builds on EL 6. We can't not ship the docs. Or are you suggesting we pull the RPM from another build and use that? It is just HTML files and images after all. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Nov 16, 2016 at 9:16 AM, Devrim Gündüz <devrim@gunduz.org> wrote:
>
> Hi Dave,
>
> On Mon, 2016-11-14 at 09:41 +0000, Dave Page wrote:
>> Hmmm. It's because the version of Sphinx for EL7 and friends is really
>> quite old. We could probably add some Makefile magic to detect and
>> change it, but frankly it's probably easier (and will certainly be
>> much quicker) for you to just patch conf.py.
>
> Ok, patched conf.py. That said, Sphinx in EL6 is 0.something, and even does not
> accept the default parameters. We may want to disable docs builds on EL 6.
We can't not ship the docs. Or are you suggesting we pull the RPM from
another build and use that? It is just HTML files and images after
all.
On Wed, Nov 16, 2016 at 9:41 AM, Magnus Hagander <magnus@hagander.net> wrote: > > > On Wed, Nov 16, 2016 at 10:22 AM, Dave Page <dpage@pgadmin.org> wrote: >> >> On Wed, Nov 16, 2016 at 9:16 AM, Devrim Gündüz <devrim@gunduz.org> wrote: >> > >> > Hi Dave, >> > >> > On Mon, 2016-11-14 at 09:41 +0000, Dave Page wrote: >> >> Hmmm. It's because the version of Sphinx for EL7 and friends is really >> >> quite old. We could probably add some Makefile magic to detect and >> >> change it, but frankly it's probably easier (and will certainly be >> >> much quicker) for you to just patch conf.py. >> > >> > Ok, patched conf.py. That said, Sphinx in EL6 is 0.something, and even >> > does not >> > accept the default parameters. We may want to disable docs builds on EL >> > 6. >> >> We can't not ship the docs. Or are you suggesting we pull the RPM from >> another build and use that? It is just HTML files and images after >> all. >> > > Not at all knowing what Devrim was thinking, but perhaps you need something > like what postgresql.org does for "difficult build dependencies". Which is > build a snapshot tarfile that includes the *prebuilt* documentation, and the > same for releases of course. They don't go in git, but they go in the > tarballs (we do that both for the docs and for things like the bison output > in pg.org). And the tarballs contain nothing platform-specific (I assume), > so they can be built on a platform that has easy access to those tools. Yeah, that could work. Though "difficult dependencies" is a stretch here - it's really just that sphinx hasn't been updated in EPEL in ages. It might be easiest to just get that RPM refreshed and be done with it. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi, On Wed, 2016-11-16 at 09:22 +0000, Dave Page wrote: > We can't not ship the docs. Or are you suggesting we pull the RPM from > another build and use that? It is just HTML files and images after > all. Hmm, that should work in theory, but RPM headers will be different in distros, so it may not work. What we can do is creating a tarball of .html files somewhere else, make them available in pgadmin.org, and then create -docs RPM using that tarball. Easy, one click. What do you think? Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
Hi, On Wed, 2016-11-16 at 09:54 +0000, Dave Page wrote: > > Not at all knowing what Devrim was thinking, but perhaps you need something > > like what postgresql.org does for "difficult build dependencies". Which is > > build a snapshot tarfile that includes the *prebuilt* documentation, and > the > > same for releases of course. They don't go in git, but they go in the > > tarballs (we do that both for the docs and for things like the bison output > > in pg.org). And the tarballs contain nothing platform-specific (I assume), > > so they can be built on a platform that has easy access to those tools. > > Yeah, that could work. Though "difficult dependencies" is a stretch > here - it's really just that sphinx hasn't been updated in EPEL in > ages. It might be easiest to just get that RPM refreshed and be done > with it. I can do it in the community repo, but not sure if EPEL update will be accepted (I have the power to do so, but EPEL policy may be boring sometimes) I'll take a look. I already added 20+ more packages to community repo for pgadmin4. Adding another may not hurt, hopefully, at least for the build servers. Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
Hi, On Wed, 2016-11-16 at 13:10 +0300, Devrim Gündüz wrote: > I can do it in the community repo, but not sure if EPEL update will be > accepted > (I have the power to do so, but EPEL policy may be boring sometimes) > > I'll take a look. I already added 20+ more packages to community repo for > pgadmin4. Adding another may not hurt, hopefully, at least for the build > servers. Oh, just saw python-sphinx10 package in EPEL 6. That brings 1.0.8 to EL6. However, I will need to apply this patch on EL 6: --- docs/en_US/Makefile.sphinx.old 2016-11-16 13:16:31.885343501 +0300 +++ docs/en_US/Makefile.sphinx 2016-11-16 13:16:58.297102473 +0300 @@ -3,7 +3,7 @@ # You can set these variables from the command line. SPHINXOPTS = -SPHINXBUILD = sphinx-build +SPHINXBUILD = sphinx-1.0-build PAPER = BUILDDIR = _build So that it will use that sphinx version. Ok, I think we have a easier solution now, though -docs is not the only blocker in EL6. Let me work on the rest. Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachment
On Wed, Nov 16, 2016 at 10:10 AM, Devrim Gündüz <devrim@gunduz.org> wrote: > > Hi, > > On Wed, 2016-11-16 at 09:54 +0000, Dave Page wrote: >> > Not at all knowing what Devrim was thinking, but perhaps you need something >> > like what postgresql.org does for "difficult build dependencies". Which is >> > build a snapshot tarfile that includes the *prebuilt* documentation, and >> the >> > same for releases of course. They don't go in git, but they go in the >> > tarballs (we do that both for the docs and for things like the bison output >> > in pg.org). And the tarballs contain nothing platform-specific (I assume), >> > so they can be built on a platform that has easy access to those tools. >> >> Yeah, that could work. Though "difficult dependencies" is a stretch >> here - it's really just that sphinx hasn't been updated in EPEL in >> ages. It might be easiest to just get that RPM refreshed and be done >> with it. > > I can do it in the community repo, but not sure if EPEL update will be accepted > (I have the power to do so, but EPEL policy may be boring sometimes) Oh, urgh. > I'll take a look. I already added 20+ more packages to community repo for > pgadmin4. Adding another may not hurt, hopefully, at least for the build > servers. OK. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Nov 16, 2016 at 10:05 AM, Devrim Gündüz <devrim@gunduz.org> wrote: > > Hi, > > On Wed, 2016-11-16 at 09:22 +0000, Dave Page wrote: >> We can't not ship the docs. Or are you suggesting we pull the RPM from >> another build and use that? It is just HTML files and images after >> all. > > Hmm, that should work in theory, but RPM headers will be different in distros, > so it may not work. What we can do is creating a tarball of .html files > somewhere else, make them available in pgadmin.org, and then create -docs RPM > using that tarball. Easy, one click. What do you think? That's probably pretty easy. Let me take a look... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Nov 16, 2016 at 10:19 AM, Devrim Gündüz <devrim@gunduz.org> wrote: > > Hi, > > On Wed, 2016-11-16 at 13:10 +0300, Devrim Gündüz wrote: >> I can do it in the community repo, but not sure if EPEL update will be >> accepted >> (I have the power to do so, but EPEL policy may be boring sometimes) >> >> I'll take a look. I already added 20+ more packages to community repo for >> pgadmin4. Adding another may not hurt, hopefully, at least for the build >> servers. > > Oh, just saw python-sphinx10 package in EPEL 6. That brings 1.0.8 to EL6. > However, I will need to apply this patch on EL 6: > > --- docs/en_US/Makefile.sphinx.old 2016-11-16 13:16:31.885343501 +0300 > +++ docs/en_US/Makefile.sphinx 2016-11-16 13:16:58.297102473 +0300 > @@ -3,7 +3,7 @@ > > # You can set these variables from the command line. > SPHINXOPTS = > -SPHINXBUILD = sphinx-build > +SPHINXBUILD = sphinx-1.0-build > PAPER = > BUILDDIR = _build > > > So that it will use that sphinx version. Ok, I think we have a easier solution > now, though -docs is not the only blocker in EL6. Let me work on the rest. Did you notice the comment at the top of that section? You should be able to do: SPHINXBUILD=sphinx-1.0-build make -f Makefile.sphinx html or something similar. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Nov 16, 2016 at 10:26 AM, Dave Page <dpage@pgadmin.org> wrote: > On Wed, Nov 16, 2016 at 10:05 AM, Devrim Gündüz <devrim@gunduz.org> wrote: >> >> Hi, >> >> On Wed, 2016-11-16 at 09:22 +0000, Dave Page wrote: >>> We can't not ship the docs. Or are you suggesting we pull the RPM from >>> another build and use that? It is just HTML files and images after >>> all. >> >> Hmm, that should work in theory, but RPM headers will be different in distros, >> so it may not work. What we can do is creating a tarball of .html files >> somewhere else, make them available in pgadmin.org, and then create -docs RPM >> using that tarball. Easy, one click. What do you think? > > That's probably pretty easy. Let me take a look... https://www.postgresql.org/ftp/pgadmin3/pgadmin4/v1.1/docs/ :-) I really need to fix the ftp sites handling of symlinks... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Nov 16, 2016 11:10, "Devrim Gündüz" <devrim@gunduz.org> wrote:
>
>
> Hi,
>
> On Wed, 2016-11-16 at 09:54 +0000, Dave Page wrote:
> > > Not at all knowing what Devrim was thinking, but perhaps you need something
> > > like what postgresql.org does for "difficult build dependencies". Which is
> > > build a snapshot tarfile that includes the *prebuilt* documentation, and
> > the
> > > same for releases of course. They don't go in git, but they go in the
> > > tarballs (we do that both for the docs and for things like the bison output
> > > in pg.org). And the tarballs contain nothing platform-specific (I assume),
> > > so they can be built on a platform that has easy access to those tools.
> >
> > Yeah, that could work. Though "difficult dependencies" is a stretch
> > here - it's really just that sphinx hasn't been updated in EPEL in
> > ages. It might be easiest to just get that RPM refreshed and be done
> > with it.
>
> I can do it in the community repo, but not sure if EPEL update will be accepted
> (I have the power to do so, but EPEL policy may be boring sometimes)
>
> I'll take a look. I already added 20+ more packages to community repo for
> pgadmin4. Adding another may not hurt, hopefully, at least for the build
> servers.
Uh, are you suggesting to put sphinx in the pgdg repo? If so, strong -1 from me for doing that. It seems like a horrible idea. It's a *build* dependency, not a runtime one.
20 runtime dependencies is already pretty bad. Isn't there a risk of a potential conflict if somebody has both say pgdg and epel enabled if they carry incompatible versions?
/Magnus