On Tue, Jun 2, 2015 at 7:24 AM, Daniel Mack wrote:
>> I could create a PR in systemd-devs GitHub if you'd like, otherwise
>> feel free to just push it straight upstream if you prefer.
>
> Nope, let's try to get used to the new workflow. Just create the PR :)
Good call... we were actually missing
On 06/02/2015 03:50 PM, Filipe Brandenburger wrote:
> Hi Daniel,
>
> On Tue, Jun 2, 2015 at 3:04 AM, Daniel Mack wrote:
>> On 06/02/2015 11:25 AM, Martin Pitt wrote:
>>> FTR, this works fine here, using --with-rootprefix= (to avoid the
>>> extra slashes). This spawned a long thread and multiple f
Hi Daniel,
On Tue, Jun 2, 2015 at 3:04 AM, Daniel Mack wrote:
> On 06/02/2015 11:25 AM, Martin Pitt wrote:
>> FTR, this works fine here, using --with-rootprefix= (to avoid the
>> extra slashes). This spawned a long thread and multiple followup
>> patches, and TBH I lost track which patches got pr
On 06/02/2015 11:25 AM, Martin Pitt wrote:
> Daniel Mack [2015-05-29 11:05 +0200]:
>> Could you try the attached patch?
>>
>> I had to introduce a new entity in custom-entites.ent, because with
>> "--with-rootprefix=/", "&rootprefix;/lib" resolves to "//lib", and with
>> the default behaviour of co
Hello Daniel,
Daniel Mack [2015-05-29 11:05 +0200]:
> Could you try the attached patch?
>
> I had to introduce a new entity in custom-entites.ent, because with
> "--with-rootprefix=/", "&rootprefix;/lib" resolves to "//lib", and with
> the default behaviour of configure, "&rootprefix;lib" becomes
On 05/29/2015 07:37 PM, Filipe Brandenburger wrote:
> I haven't tested it, but I do have a few comments.
>
> First, why not use "rootlibdir" instead of "rootprefixlibdir"?
Because $(rootlibdir) resolves to /usr/lib64 on my system.
[...]
> On Fri, May 29, 2015 at 2:05 AM, Daniel Mack wrote:
>>
Hi Daniel,
I haven't tested it, but I do have a few comments.
First, why not use "rootlibdir" instead of "rootprefixlibdir"? There's
already similar "rootbindir" and "rootlibexecdir" defined there, so I
think we could stick to the same convention.
From a few lines down in Makefile.am:
# And t
On Fri, 29.05.15 11:05, Daniel Mack (dan...@zonque.org) wrote:
> On 05/29/2015 05:18 AM, Michael Biebl wrote:
> > 2015-05-28 19:47 GMT+02:00 Filipe Brandenburger :
> >> We're actually still missing a small part of it (A sentence like
> >> "Files in /etc have the highest priority, files in /run tak
On Thu, 28.05.15 10:47, Filipe Brandenburger (filbran...@google.com) wrote:
> On Thu, May 28, 2015 at 10:44 AM, Michael Biebl wrote:
> > 2015-05-28 19:41 GMT+02:00 Martin Pitt :
> >> \o/ Many thanks Filipe, that's great! Biggest patch gone :)
> >
> > A huge thanks from me as well to everyone invo
On 05/29/2015 05:18 AM, Michael Biebl wrote:
> 2015-05-28 19:47 GMT+02:00 Filipe Brandenburger :
>> We're actually still missing a small part of it (A sentence like
>> "Files in /etc have the highest priority, files in /run take
>> precedence over files with the same name in */usr/lib*." in files l
2015-05-28 19:47 GMT+02:00 Filipe Brandenburger :
> We're actually still missing a small part of it (A sentence like
> "Files in /etc have the highest priority, files in /run take
> precedence over files with the same name in */usr/lib*." in files like
> hwdb.xml, the last /usr/lib won't get fixed)
On Thu, May 28, 2015 at 10:44 AM, Michael Biebl wrote:
> 2015-05-28 19:41 GMT+02:00 Martin Pitt :
>> \o/ Many thanks Filipe, that's great! Biggest patch gone :)
>
> A huge thanks from me as well to everyone involved!
Lennart: Thanks for applying it.
Martin and Michael: You're welcome, glad to he
2015-05-28 19:41 GMT+02:00 Martin Pitt :
>> > I hope that's helpful!
>>
>> Applied both!
>
> \o/ Many thanks Filipe, that's great! Biggest patch gone :)
A huge thanks from me as well to everyone involved!
--
Why is it that all of the instruments seeking intelligent life in the
universe are poin
Hey Filipe,
Lennart Poettering [2015-05-28 19:35 +0200]:
> On Wed, 27.05.15 02:38, Filipe Brandenburger (filbran...@google.com) wrote:
>
> > As suggested by Martin Pitt, for better support of distros with non-merged
> > /usr.
> >
> > This doesn't get us 100% there but I'd say it gets us much cl
On Wed, 27.05.15 02:38, Filipe Brandenburger (filbran...@google.com) wrote:
> As suggested by Martin Pitt, for better support of distros with non-merged
> /usr.
>
> This doesn't get us 100% there but I'd say it gets us much closer.
>
> I think we still need a new variable for /etc/udev (similar
Hi,
On Wed, May 27, 2015 at 6:04 AM, Lennart Poettering
wrote:
> Hmm, any chance we can somehow define those entities without having to
> add
>
>
> %entities;
> ]>
>
> To each file? Can't we tell xsltproc about this via some command line
> switch or so?
I don't think that's possible, in part
On 05/27/2015 03:04 PM, Lennart Poettering wrote:
> Hmm, any chance we can somehow define those entities without having to
> add
>
>
> %entities;
> ]>
>
> To each file? Can't we tell xsltproc about this via some command line
> switch or so?
>
> This is in a way similar to how we use gcc's "
On Wed, 27.05.15 02:38, Filipe Brandenburger (filbran...@google.com) wrote:
> As suggested by Martin Pitt, for better support of distros with non-merged
> /usr.
>
> This doesn't get us 100% there but I'd say it gets us much closer.
Hmm, any chance we can somehow define those entities without ha
As suggested by Martin Pitt, for better support of distros with non-merged /usr.
This doesn't get us 100% there but I'd say it gets us much closer.
I think we still need a new variable for /etc/udev (similar to &pkgsysconfdir;
which is /etc/systemd) though that is not really critical for non-merg
19 matches
Mail list logo
