On Sun, 24 Dec 2017 at 12:39:03 +, Simon McVittie wrote:
> As I said, I suspect we don't actually need the triplet-location after
> the .pc file has been updated, although I'd have to check in codesearch
> to be sure.
Here are the mentions of glib-compile-resources in packages.
All of them:
On Sat, 23 Dec 2017 at 14:11:38 +0100, Helmut Grohne wrote:
> On Fri, Dec 22, 2017 at 11:08:58PM +, Simon McVittie wrote:
> > As far as I can tell from skim-reading its source code, this tool has
> > non-architecture-dependent output, so it should live in libglib2.0-bin or
> >
Hi Simon,
thank you for taking the time.
On Fri, Dec 22, 2017 at 11:08:58PM +, Simon McVittie wrote:
> As far as I can tell from skim-reading its source code, this tool has
> non-architecture-dependent output, so it should live in libglib2.0-bin or
> libglib2.0-dev-bin (optionally with
On Fri, 22 Dec 2017 at 23:03:35 +0100, Helmut Grohne wrote:
> Having this tool both on an
> architecture-dependent path and in an m-a:foreign package seems wrong to
> me: Either the tool has architecture-dependent behaviour, then
> libglib2.0-bin shouldn't symlink it, or it doesn't and then it
Package: libglib2.0-0
Version: 2.54.2-1
File: /usr/lib//glib-2.0/glib-compile-resources
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:empathy src:gupnp-tools
The packages listed under affects fail to cross build from source,
because they fail running
5 matches
Mail list logo
