On Thu, Aug 13, 2015 at 11:40 AM, Laurent Bercot
wrote:
> You like to play with fire. :)
> Until it's released, it's not production-ready by any means.
> Just making sure you're very much aware of that.
>
It's how I roll. Plus the backout path to a functional system takes a
few minutes in a gett
On 13/08/2015 19:44, Colin Booth wrote:
I run s6-rc on my laptop, which is about as half-serious an
environment as you get.
You like to play with fire. :)
Until it's released, it's not production-ready by any means.
Just making sure you're very much aware of that.
I may be missing somethin
On 13/08/2015 19:55, Colin Booth wrote:
Makes sense. In this case can we get a --livedir=DIR buildtime option
so us suckers using a noexec-mounted /run can relocate things easily
without having to type -l every time we want to interact
with s6-rc?
Unless I encounter a strong reason not to, su
On Thu, Aug 13, 2015 at 9:46 AM, Laurent Bercot wrote:
>
> Oh, and btw, I'll have to change s6-rc-init and go back to the
> "the directory must not exist" model, and you won't be able to
> use a tmpfs as live directory - you'll have to use a subdirectory
> of your tmpfs.
>
Ah bummer. It was fun w
On Thu, Aug 13, 2015 at 9:37 AM, Laurent Bercot wrote:
>
> Eh... keep a backup of your current source, if you're using it in
> a half-serious environment. The current version uses automatically
> generated services, and the scripts haven't been tested yet, it's
> the first draft.
>
I run s6-rc on
Oh, and btw, I'll have to change s6-rc-init and go back to the
"the directory must not exist" model, and you won't be able to
use a tmpfs as live directory - you'll have to use a subdirectory
of your tmpfs.
The reason: as it is now, it's too hard to handle all the failure
cases when updating l
On 13/08/2015 18:21, Colin Booth wrote:
nice to get rid of that pile of explicit bundle definitions that I
currently have for service-logger pairs.
Eh... keep a backup of your current source, if you're using it in
a half-serious environment. The current version uses automatically
generated ser
On Aug 13, 2015 9:12 AM, "Laurent Bercot" wrote:
>
> On 13/08/2015 18:05, Laurent Bercot wrote:
>>
>> If you're going to pull from git head, then you should pull from
>> the git head of *every* project, including dependencies. Which you
>> didn't for execline. :)
>
>
> I'm not lying! I'm just c
On 13/08/2015 18:05, Laurent Bercot wrote:
If you're going to pull from git head, then you should pull from
the git head of *every* project, including dependencies. Which you
didn't for execline. :)
I'm not lying! I'm just chronologically challenged sometimes. See,
if you had pulled from the
On 13/08/2015 17:30, Colin Booth wrote:
Your commit 979046fdee76d70792750f5a1a9afd2bba5f127f introduced a
build failure in
src/s6-rc/s6-rc-compile.c.
No, it didn't.
If you're going to pull from git head, then you should pull from
the git head of *every* project, including dependencies. Which
Hi Laurent,
Your commit 979046fdee76d70792750f5a1a9afd2bba5f127f introduced a
build failure in
src/s6-rc/s6-rc-compile.c.
It'll probably get fixed today, but since the git repo is advertised
as a reasonable alternative to downloading tarballs you might want to
start doing work on side branches an
Hello,
A release to fix a few building bugs that could impact some systems.
Notably:
- rebuilding and reinstalling shared libraries in the same place
without using a DESTDIR should now work
- linking against shared objects on non-musl systems without a vDSO
should now work all the time.
It
12 matches
Mail list logo
