Thanks all,
On Tue, 13 Nov 2018 11:03:36 -0800, Brian Norris
wrote:
> [ ... ]
>
> Cc: Genki Sky
> Cc: Christian Kujau
> Cc: Guenter Roeck
> Suggested-by: Alexander Kapshuk
> Signed-off-by: Brian Norris
Tested-by: Genki Sky
Thanks all,
On Tue, 13 Nov 2018 11:03:36 -0800, Brian Norris
wrote:
> [ ... ]
>
> Cc: Genki Sky
> Cc: Christian Kujau
> Cc: Guenter Roeck
> Suggested-by: Alexander Kapshuk
> Signed-off-by: Brian Norris
Tested-by: Genki Sky
Hi Alexander,
On Sun, 11 Nov 2018 16:48:38 +0200, Alexander Kapshuk
wrote:
> Piping the output of the git command to grep and using the return status
> of grep as the test condition within the if block, would be sufficient
> to determine whether or not '-dirty' should be printed.
>
> Sample
Hi Alexander,
On Sun, 11 Nov 2018 16:48:38 +0200, Alexander Kapshuk
wrote:
> Piping the output of the git command to grep and using the return status
> of grep as the test condition within the if block, would be sufficient
> to determine whether or not '-dirty' should be printed.
>
> Sample
Hi Andreas,
On Sat, 10 Nov 2018 11:42:11 +0100, Andreas Schwab
wrote:
> On Nov 10 2018, Genki Sky wrote:
> > On Fri, 9 Nov 2018 10:34:37 -0800, Brian Norris
> > wrote:
> >> + git_status="$(git --no-optional-locks status -uno
Hi Andreas,
On Sat, 10 Nov 2018 11:42:11 +0100, Andreas Schwab
wrote:
> On Nov 10 2018, Genki Sky wrote:
> > On Fri, 9 Nov 2018 10:34:37 -0800, Brian Norris
> > wrote:
> >> + git_status="$(git --no-optional-locks status -uno
Hi, thanks very much for doing this. But, this patch always prints
-dirty for me, even with no untracked changes in git. I think this is
because:
On Fri, 9 Nov 2018 10:34:37 -0800, Brian Norris
wrote:
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index
Hi, thanks very much for doing this. But, this patch always prints
-dirty for me, even with no untracked changes in git. I think this is
because:
On Fri, 9 Nov 2018 10:34:37 -0800, Brian Norris
wrote:
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index
On Wed, 7 Nov 2018 13:18:19 -0800, Doug Anderson wrote:
> From reading the thread it sounds like Guenter was not even super
> happy with that based on the principal that you wouldn't expect a
> kernel build to be doing write operations in your .git directory even
> if $objtree == $srctree
I see,
On Wed, 7 Nov 2018 13:18:19 -0800, Doug Anderson wrote:
> From reading the thread it sounds like Guenter was not even super
> happy with that based on the principal that you wouldn't expect a
> kernel build to be doing write operations in your .git directory even
> if $objtree == $srctree
I see,
On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> I do not think it is a good idea to create a random file in the .git directory
> under any circumstance, and much less so if an output directory was specified,
> no matter if the path is read-only or not. I also still think that it is a
>
On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> I do not think it is a good idea to create a random file in the .git directory
> under any circumstance, and much less so if an output directory was specified,
> no matter if the path is read-only or not. I also still think that it is a
>
On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
wrote:
> On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > On a different tangent: how about the --no-optional-locks (see
> > git(1))? Will this get you your "up-to-date" result without writing to
> > the .git directory? I've only
On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
wrote:
> On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > On a different tangent: how about the --no-optional-locks (see
> > git(1))? Will this get you your "up-to-date" result without writing to
> > the .git directory? I've only
Hi Guenter,
On Tue, 6 Nov 2018 10:10:38 -0800, Guenter Roeck wrote:
> This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
>
> The reverted patch results in attempted write access to the source
> repository, even if that repository is mounted read-only.
>
> Output from "strace git
Hi Guenter,
On Tue, 6 Nov 2018 10:10:38 -0800, Guenter Roeck wrote:
> This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
>
> The reverted patch results in attempted write access to the source
> repository, even if that repository is mounted read-only.
>
> Output from "strace git
Sorry to have been the bearer of bad news :(. Again, I just have my
user hat on here. It does seem like this unifying would have been nice
to have. And even, more compliant with the POSIX definition of
MONOTONIC...
On that note, maybe it is still worth introducing MONOTONIC_ACTIVE,
but just as an
Sorry to have been the bearer of bad news :(. Again, I just have my
user hat on here. It does seem like this unifying would have been nice
to have. And even, more compliant with the POSIX definition of
MONOTONIC...
On that note, maybe it is still worth introducing MONOTONIC_ACTIVE,
but just as an
Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> I came across this thread for same reason as [0]: Daemons getting
> killed by systemd on resume (after >WatchdogSec seconds of
> suspending). I'm using master branch of systemd and the kernel. As
> mentioned, systemd uses CLOCK_MONOTO
Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> I came across this thread for same reason as [0]: Daemons getting
> killed by systemd on resume (after >WatchdogSec seconds of
> suspending). I'm using master branch of systemd and the kernel. As
> mentioned, systemd uses CLOCK_MONOTO
Hello,
I came across this thread for same reason as [0]: Daemons getting
killed by systemd on resume (after >WatchdogSec seconds of
suspending). I'm using master branch of systemd and the kernel. As
mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
not include suspend time.
Hello,
I came across this thread for same reason as [0]: Daemons getting
killed by systemd on resume (after >WatchdogSec seconds of
suspending). I'm using master branch of systemd and the kernel. As
mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
not include suspend time.
22 matches
Mail list logo
