On 9/1/19 12:14 am, Sebastian Huber wrote:
> What should I use to execute the git command and get the output in
> "common/conf.py"? The subprocess command is only available in Python 3.5 and
> later.
Try 'ctx.cmd_and_log()', an example is ...
https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems
On 08/01/2019 07:53, Chris Johns wrote:
On 8 Jan 2019, at 5:19 pm, Sebastian Huber
wrote:
On 08/01/2019 02:59, Chris Johns wrote:
On 7/1/19 11:30 pm, Sebastian Huber wrote:
On 07/01/2019 12:49, Sebastian Huber wrote:
On 07/01/2019 12:39, Chris Johns wrote:
On 7 Jan 2019, at 10:03 pm, Sebas
> On 8 Jan 2019, at 5:19 pm, Sebastian Huber
> wrote:
>
>> On 08/01/2019 02:59, Chris Johns wrote:
>>> On 7/1/19 11:30 pm, Sebastian Huber wrote:
On 07/01/2019 12:49, Sebastian Huber wrote:
On 07/01/2019 12:39, Chris Johns wrote:
>> On 7 Jan 2019, at 10:03 pm, Sebastian Huber
On 08/01/2019 02:59, Chris Johns wrote:
On 7/1/19 11:30 pm, Sebastian Huber wrote:
On 07/01/2019 12:49, Sebastian Huber wrote:
On 07/01/2019 12:39, Chris Johns wrote:
On 7 Jan 2019, at 10:03 pm, Sebastian Huber
wrote:
The usage of a build date prevents reproducible builds.
-1
I prefer a bu
On 7/1/19 11:30 pm, Sebastian Huber wrote:
> On 07/01/2019 12:49, Sebastian Huber wrote:
>> On 07/01/2019 12:39, Chris Johns wrote:
On 7 Jan 2019, at 10:03 pm, Sebastian Huber
wrote:
The usage of a build date prevents reproducible builds.
>>> -1
>>>
>>> I prefer a build date be
On 07/01/2019 14:43, Joel Sherrill wrote:
We need some indication for automated builds on RTEMS.org that the
server actually did build something. The script that builds the docs
on the server should create a file and put the build time in it.
Built something is good, but built the right thing
We need some indication for automated builds on RTEMS.org that the server
actually did build something. The script that builds the docs on the server
should create a file and put the build time in it.
On Mon, Jan 7, 2019, 5:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de wrote:
> The u
On 07/01/2019 12:49, Sebastian Huber wrote:
On 07/01/2019 12:39, Chris Johns wrote:
On 7 Jan 2019, at 10:03 pm, Sebastian Huber
wrote:
The usage of a build date prevents reproducible builds.
-1
I prefer a build date being present. For unreleased it marks the
online builds and for release
On 07/01/2019 12:39, Chris Johns wrote:
On 7 Jan 2019, at 10:03 pm, Sebastian Huber
wrote:
The usage of a build date prevents reproducible builds.
-1
I prefer a build date being present. For unreleased it marks the online builds
and for releases it tags the day built.
Adding the Git commi
> On 7 Jan 2019, at 10:03 pm, Sebastian Huber
> wrote:
>
> The usage of a build date prevents reproducible builds.
-1
I prefer a build date being present. For unreleased it marks the online builds
and for releases it tags the day built.
I have never seen this being a requirement for docs
The usage of a build date prevents reproducible builds.
---
common/conf.py | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/common/conf.py b/common/conf.py
index 60db066..8d5e6b8 100644
--- a/common/conf.py
+++ b/common/conf.py
@@ -1,26 +1,3 @@
-import
11 matches
Mail list logo