Page MenuHomePhabricator

Install librsvg 2.40.20 on Jessie for K8s webservice
Open, NormalPublic

Description

In T170810, production (on Jessie) upgraded to a backport of librsvg 2.40.18. Tool Labs (on Trusty) is stuck on 2.40.2, which creates problems for tools, like mine, that attempt to preview the result of uploads in production. Using K8s, one can get one's webservice running on a version of Jessie, but no version of librsvg seems to be installed(?). Rather than install librsvg 2.40.5 (which I think is what is the Jessie default), ideally we would have the same 2.40.18 backport as described on T170810 on the Tool Labs version of Jessie.

Event Timeline

Restricted Application added a project: Cloud-Services. · View Herald TranscriptNov 25 2016, 11:18 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
scfc triaged this task as Normal priority.Feb 16 2017, 10:41 PM
scfc moved this task from Triage to Backlog on the Toolforge board.

What language flavor do you want librsvg on? I'm guessing PHP?

root@2a3ac38373b3:/# dpkg -l | grep librsvg
ii  librsvg2-2:amd64              2.40.18-1~wmf1                   amd64        SAX-based renderer library for SVG files (runtime)
ii  librsvg2-common:amd64         2.40.18-1~wmf1                   amd64        SAX-based renderer library for SVG files (extra runtime)

So librsvg is already installed, though I'm again assuming what you really want is the rsvg-* commands.

Yes, as you say it's the rsvg-* that are of interest to me. This is what I do (very happily) not on k8s (with both paths sanitised, naturally):

exec( "/usr/bin/rsvg-convert '" . $svgPath . "' -o '" . $pngPath . "'" );
exec( '/usr/bin/rsvg-convert -v' )

Neither works so I assume they either don't exist or are not available on those paths. I thought they always came packaged with librsvg but evidently not...

Jarry1250 renamed this task from Install librsvg 2.40.16 on Jessie for K8s webservice to Install librsvg 2.40.18 on Jessie for K8s webservice.Aug 19 2018, 1:54 PM
Jarry1250 updated the task description. (Show Details)

rsvg-convert is also a requirement for T211637: Render image previews via RSVG.

Does this ticket also involve installing rsvg for the php7.2 container?

Change 480159 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[operations/docker-images/toollabs-images@master] php72: add RSVG

https://gerrit.wikimedia.org/r/480159

From Gerrit: We need a better strategy for custom container images. We can't fall into the same hole we did with Grid Engine hosts where we just install everything people may ever need. This is not going to work with containers. @MaxSem I'm afraid we're not there yet and I'd like to push hard against even starting to pile up packages inside container images. I'm afraid there is no quick solution here.

zhuyifei1999 added a comment.EditedDec 19 2018, 8:06 PM

@MaxSem May I suggest doing the compilation of RSVG locally in the tool?

@MaxSem May I suggest doing the compilation of RSVG locally in the tool?

We've had a cursory attempt at that, and got the following error on ./configure:

configure: error: cargo is required. Please install the Rust toolchain from https://www.rust-lang.org/

I'm not sure if cargo can be installed locally.

You're trying the latest RSVG which is not what WMF is running and not what is being requested here. The requested version is in C, and requires you compile GTK first, among other things.

Oh great. Dependency fun.... (Looking at the dependency for compilation in Gentoo)

 * dependency graph for gnome-base/librsvg-2.40.20
 `--  gnome-base/librsvg-2.40.20  ~amd64 
   `--  dev-libs/glib-2.58.2  (>=dev-libs/glib-2.34.3) ~amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  x11-libs/cairo-1.16.0-r2  (>=x11-libs/cairo-1.12.14-r4) ~amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  x11-libs/pango-1.42.4  (>=x11-libs/pango-1.38.0) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-libs/libxml2-2.9.8  (>=dev-libs/libxml2-2.9.1-r4) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-libs/libcroco-0.6.12-r1  (>=dev-libs/libcroco-0.6.8-r1) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  x11-libs/gdk-pixbuf-2.36.12  (>=x11-libs/gdk-pixbuf-2.30.7) amd64  [introspection? abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-libs/gobject-introspection-1.56.1  (>=dev-libs/gobject-introspection-0.10.8) ~amd64 
   `--  x11-libs/gtk+-3.24.1  (>=x11-libs/gtk+-3.10.0) ~amd64 
   `--  dev-libs/gobject-introspection-common-1.56.1  (dev-libs/gobject-introspection-common) ~amd64 
   `--  dev-libs/vala-common-0.36.15  (dev-libs/vala-common) ~amd64 
   `--  dev-util/glib-utils-2.58.2  (dev-util/glib-utils) ~amd64 
   `--  dev-util/gtk-doc-am-1.25-r1  (>=dev-util/gtk-doc-am-1.13) amd64 
   `--  virtual/pkgconfig-0-r1  (>=virtual/pkgconfig-0-r1) amd64  [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_ppc_32(-)? abi_ppc_64(-)? abi_s390_32(-)? abi_s390_64(-)?]
   `--  dev-lang/vala-0.36.15  (dev-lang/vala) ~amd64  [vapigen(+)]
   `--  dev-lang/vala-0.34.16  (dev-lang/vala) amd64  [vapigen(+)]
   `--  dev-lang/vala-0.32.1  (dev-lang/vala) amd64  [vapigen(+)]
   `--  app-portage/elt-patches-20170826.1  (>=app-portage/elt-patches-20170815) ~amd64 
   `--  sys-devel/automake-1.16.1-r1  (>=sys-devel/automake-1.16.1) ~amd64 
   `--  sys-devel/automake-1.15.1-r2  (>=sys-devel/automake-1.15.1) amd64 
   `--  sys-devel/autoconf-2.69-r4  (>=sys-devel/autoconf-2.69) amd64 
   `--  sys-devel/libtool-2.4.6-r5  (>=sys-devel/libtool-2.4) ~amd64 
   `--  app-arch/xz-utils-5.2.4-r2  (app-arch/xz-utils) ~amd64 
   `--  sys-apps/sed-4.5  (>=sys-apps/sed-4) amd64 
   `--  dev-util/desktop-file-utils-0.23  (dev-util/desktop-file-utils) amd64 
   `--  x11-misc/shared-mime-info-1.10  (x11-misc/shared-mime-info) amd64 
[ gnome-base/librsvg-2.40.20 stats: packages (26), max depth (1) ]

I had suggested to get a Gentoo prefix for Toolforge, but since it's gotta put all the binaries (including compilers on NFS), it's not a 'loved' idea.

The dependency game might be too painful :(

At some point, I think we will have to embrace custom Docker images but we're not there yet and it will take a while (probably not before we adopt a PaaS solution).

In the meantime and, with the goal of containing any future technical debt, I would like to propose we create a "php72-commtech" image that has all these extras. The advantage would be this is clearly tied to Community Tech and when the time comes to adopt an image build pipeline, we know for sure who is using it (as opposed to adding it to the standard "php72" image today and never being able to remove it because it could be used by who knows how many users). I think this would be a good compromise.

My main goal with this proposal is to give our end users the flexibility they need today with the platform we have today while minimizing future headaches. If that would be acceptable I can work on creating this team-specific image. We should not encourage others to request more specific images if possible though. It should be clear this is an exception for CommTech until we have a proper image build pipeline in place, because creating team-specific image won't scale with our current processes.

Change 480159 merged by jenkins-bot:
[operations/docker-images/toollabs-images@master] php72: add RSVG

https://gerrit.wikimedia.org/r/480159

Leaving ideology aside until we have a proper solution for this and then we can review these images and remove anything we desire.

Image built and pushed to the repository.

# docker run --rm -ti docker-registry.tools.wmflabs.org/toollabs-php72-web rsvg-convert --version
rsvg-convert version 2.40.16
GTirloni closed this task as Resolved.Dec 21 2018, 11:18 AM
GTirloni claimed this task.

In the meantime and, with the goal of containing any future technical debt, I would like to propose we create a "php72-commtech" image that has all these extras. The advantage would be this is clearly tied to Community Tech and when the time comes to adopt an image build pipeline, we know for sure who is using it (as opposed to adding it to the standard "php72" image today and never being able to remove it because it could be used by who knows how many users). I think this would be a good compromise.
My main goal with this proposal is to give our end users the flexibility they need today with the platform we have today while minimizing future headaches. If that would be acceptable I can work on creating this team-specific image. We should not encourage others to request more specific images if possible though. It should be clear this is an exception for CommTech until we have a proper image build pipeline in place, because creating team-specific image won't scale with our current processes.

I think this is a bad route to go down - tools are about well, the tools, not the people behind them (related: cloud VPS projects being about projects, not teams).

Adding rsvg to the main php72 image seems very reasonable to me (I was going to do it in August but didn't because time...) because it's a dependency of MediaWiki, and very highly used in our projects.

@Legoktm I'm sorry, I didn't know it was a dependency and a highly used one. I only saw a request from CommTech to add a package and no other justification other than "we need it".

In any case, where do we draw the line? Say a volunteer wants to add LaTeX to the stretch image.

This ticket is probably the wrong place to have this discussion, but I'd also like to know what the protocol should be — I don't know about latex (although actually that'd be cool to have available to a tool!) but the other day I wanted GraphViz in the php7.2 container and I didn't want to request it because it seemed from this ticket that that's not the way things are going. But maybe it is? I totally understand that the line has to be drawn somewhere, and perhaps it's going to be a matter of waiting for the future point at which custom containers will be supported.

Jarry1250 reopened this task as Open.Mar 29 2019, 9:25 AM

Hi all. Sorry to be a pain but -- while I am very grateful to have 2.40.16 on Kubernetes, for which many thanks -- it would be much more helpful to have 2.40.18 installed as that is the version that is running in production. See also T218828 (which relates I think to CVE-2017-11464 which was fixed in 2.40.18). Alternatively, if I would be better off asking for 2.40.18 to be backported to Stretch, let me know. Best, Jarry1250 (volunteer)

GTirloni removed GTirloni as the assignee of this task.Apr 1 2019, 10:02 AM
GTirloni removed a subscriber: GTirloni.Apr 3 2019, 10:19 AM

@Jarry1250 : Actually since last week librsvg 2.40.20 is installed on servers, therfore we might should change the title. (Update librsvg to 2.40.20 on toolforge)

Since last week all servers are using librsvg 2.40.20-3 which fixes some svg rendering issues (and possibly introduces others).

Aklapper renamed this task from Install librsvg 2.40.18 on Jessie for K8s webservice to Install librsvg 2.40.20 on Jessie for K8s webservice.May 4 2019, 10:12 PM
JoKalliauer closed this task as Resolved.May 5 2019, 8:49 AM
JoKalliauer reopened this task as Open.