2014-02-11 8:04 GMT+01:00 Guido Günther <a...@sigxcpu.org>: > Hi, > On Mon, Feb 10, 2014 at 11:36:46PM +0100, Marius B. Kotsbak wrote: > > On 07. feb. 2014 08:14, Guido Günther wrote: > > > blocks 737572 731851 > > > thanks > > > > > > Hi, > > > On Tue, Feb 04, 2014 at 10:21:43AM +0100, Marius Kotsbak wrote: > > >> Hi > > >> > > >> It is actually almost ready in the git repo I have pushed. > > >> > > >> The remaining thing is to find out how to handle the qmi-proxy binary, > > >> which is used by the lib. > > > > > > The binary is libexecdir so it ends up in /usr/lib/<arch> on Debian, > > > so which not just ship it in the libqmi-glib itself? It useless without > > > the lib anyway. > > dh > > Yes, that was my plan, but the problem is when libqmi-glib2 is released, > > the path will be the same, so in that case, it should be placed in the > > recommended path including the package name (/usr/share/...?). Anyway, > > Use share is for architecture _independent_ data. > > Japp, I mean /usr/lib/[triplet]/qmi-glib1/qmi-proxy
> as only one qmi-proxy can be run at the same time to work, I'm proposing > > the following: > > I still don't understand why you can't leave it in /usr/lib/<arcH>? > Done it like that and pushed now. Then it will be up to the user to avoid conflicts between different qmi-proxy running at the same time against the same port (but it is probably possible to run multiple for different modem devices). What do you think? -- Marius