* DTC 1.0.0 Release Coming?
@ 2007-07-25 16:12 Jon Loeliger
2007-07-26 3:05 ` David Gibson
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Jon Loeliger @ 2007-07-25 16:12 UTC (permalink / raw)
To: linuxppc-dev
Folks,
I'd like to make an official DTC Version 1.0.0 release soon!
To that end, I've published a repo on jdl.com with a v1.0.0-rc1
tag on it. I anticipate some updates to the Documentation before
a final 1.0.0 release still. However, if you have something
you would like to have be in The Real 1.0.0 release, please
let me know soon!
Thanks,
jdl
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: DTC 1.0.0 Release Coming? 2007-07-25 16:12 DTC 1.0.0 Release Coming? Jon Loeliger @ 2007-07-26 3:05 ` David Gibson 2007-07-26 7:25 ` David Gibson 2007-07-26 13:04 ` Jon Loeliger 2007-07-31 21:09 ` Segher Boessenkool 2007-08-01 23:35 ` Arnd Bergmann 2 siblings, 2 replies; 27+ messages in thread From: David Gibson @ 2007-07-26 3:05 UTC (permalink / raw) To: Jon Loeliger; +Cc: linuxppc-dev On Wed, Jul 25, 2007 at 11:12:00AM -0500, Jon Loeliger wrote: > Folks, > > I'd like to make an official DTC Version 1.0.0 release soon! > To that end, I've published a repo on jdl.com with a v1.0.0-rc1 > tag on it. I anticipate some updates to the Documentation before > a final 1.0.0 release still. However, if you have something > you would like to have be in The Real 1.0.0 release, please > let me know soon! It would certainly be great to have a release, since dtc is becoming necessary for more and more kernel builds. Only thing I'm not really happy with in the current release is the versioning stuff. For starters, it always reports my builds as -dirty, even when they're not. It also seems a bit hideously complicated for what it does. I'd prefer to see something simpler using git-describe to derive the version strings directly from the git tags themselves. Obviously we need some sort of cacheing mechanism to make the versioning work for tarball releases without the git history, but I think we can handle that with a suitable "make dist" target. I'll see if I can make a patch or two in the next few days. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-26 3:05 ` David Gibson @ 2007-07-26 7:25 ` David Gibson 2007-07-26 13:04 ` Jon Loeliger 1 sibling, 0 replies; 27+ messages in thread From: David Gibson @ 2007-07-26 7:25 UTC (permalink / raw) To: Jon Loeliger, linuxppc-dev On Thu, Jul 26, 2007 at 01:05:50PM +1000, David Gibson wrote: > On Wed, Jul 25, 2007 at 11:12:00AM -0500, Jon Loeliger wrote: > > Folks, > > > > I'd like to make an official DTC Version 1.0.0 release soon! > > To that end, I've published a repo on jdl.com with a v1.0.0-rc1 > > tag on it. I anticipate some updates to the Documentation before > > a final 1.0.0 release still. However, if you have something > > you would like to have be in The Real 1.0.0 release, please > > let me know soon! > > It would certainly be great to have a release, since dtc is becoming > necessary for more and more kernel builds. > > Only thing I'm not really happy with in the current release is the > versioning stuff. For starters, it always reports my builds as > -dirty, even when they're not. It also seems a bit hideously > complicated for what it does. I'd prefer to see something simpler > using git-describe to derive the version strings directly from the git > tags themselves. Obviously we need some sort of cacheing mechanism to > make the versioning work for tarball releases without the git history, > but I think we can handle that with a suitable "make dist" target. > > I'll see if I can make a patch or two in the next few days. Well, here's a first cut at my proposed simpler versioning scheme. This is *not* ready to merge. It needs more testing and some more thought on how to integrate it with a "make dist" target. Still, provided for comment. dtc: Simpler versioning Index: dtc/Makefile =================================================================== --- dtc.orig/Makefile 2007-07-26 16:56:12.000000000 +1000 +++ dtc/Makefile 2007-07-26 17:13:30.000000000 +1000 @@ -1,54 +1,12 @@ # # Device Tree Compiler # - -# -# Version information will be constructed in this order: -# EXTRAVERSION might be "-rc", for example. -# LOCAL_VERSION is likely from command line. -# CONFIG_LOCALVERSION from some future config system. -# -VERSION = 1 -PATCHLEVEL = 0 -SUBLEVEL = 0 -EXTRAVERSION =-rc1 -LOCAL_VERSION = -CONFIG_LOCALVERSION = - -DTC_VERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) -VERSION_FILE = version_gen.h - -CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ - else if [ -x /bin/bash ]; then echo /bin/bash; \ - else echo sh; fi ; fi) - -nullstring := -space := $(nullstring) # end of line - -localver_config = $(subst $(space),, $(string) \ - $(patsubst "%",%,$(CONFIG_LOCALVERSION))) - -localver_cmd = $(subst $(space),, $(string) \ - $(patsubst "%",%,$(LOCALVERSION))) - -localver_scm = $(shell $(CONFIG_SHELL) ./scripts/setlocalversion) -localver_full = $(localver_config)$(localver_cmd)$(localver_scm) - -dtc_version = $(DTC_VERSION)$(localver_full) - -# -# Contents of the generated version file. -# -define filechk_version - (echo "#define DTC_VERSION \"DTC $(dtc_version)\""; ) -endef - - CPPFLAGS = -I libfdt CFLAGS = -Wall -g LDFLAGS = -Llibfdt BISON = bison +GIT = git INSTALL = /usr/bin/install DESTDIR = @@ -57,9 +15,6 @@ BINDIR = $(PREFIX)/bin LIBDIR = $(PREFIX)/lib INCLUDEDIR = $(PREFIX)/include -# -# Overall rules -# ifdef V VECHO = : else @@ -68,7 +23,7 @@ ARFLAGS = rc .SILENT: endif -NODEPTARGETS = clean +NODEPTARGETS = clean .git-manifest version.h ifeq ($(MAKECMDGOALS),) DEPTARGETS = all else @@ -93,9 +48,6 @@ dtc-parser.tab.c dtc-parser.tab.h dtc-pa @$(VECHO) ---- Expect 2 s/r and 2 r/r. ---- $(BISON) -d $< -$(VERSION_FILE): Makefile FORCE - $(call filechk,version) - lex.yy.c: dtc-lexer.l @$(VECHO) LEX $@ $(LEX) $< @@ -133,13 +85,28 @@ endif TESTS_PREFIX=tests/ include tests/Makefile.tests +# +# Versioning rules +# +.git-manifest: gengitmanifest FORCE .git + @$(VECHO) GENGITMANIFEST + ./gengitmanifest $@ + +-include .git-manifest + +version.h: .git-manifest + @$(VECHO) GENLOCALVERSION $@ + ./genlocalversion $(GIT_COMMITTISH) $(GIT_DESCRIBE) $(GIT_MANIFEST_HASH) $(MANIFEST_FILES) > $@ + +# +# Overall rules +# STD_CLEANFILES = *~ *.o *.d *.a *.i *.s core a.out -GEN_CLEANFILES = $(VERSION_FILE) clean: libfdt_clean tests_clean @$(VECHO) CLEAN rm -f $(STD_CLEANFILES) - rm -f $(GEN_CLEANFILES) + rm -f version.h rm -f *.tab.[ch] lex.yy.c *.output vgcore.* rm -f $(BIN) @@ -152,19 +119,6 @@ install: all $(INSTALL) -d $(DESTDIR)$(INCLUDEDIR) $(INSTALL) -m 644 $(LIBFDT_INCLUDES) $(DESTDIR)$(INCLUDEDIR) -define filechk - set -e; \ - echo ' CHK $@'; \ - mkdir -p $(dir $@); \ - $(filechk_$(1)) < $< > $@.tmp; \ - if [ -r $@ ] && cmp -s $@ $@.tmp; then \ - rm -f $@.tmp; \ - else \ - echo ' UPD $@'; \ - mv -f $@.tmp $@; \ - fi; -endef - # # Generic compile rules # Index: dtc/genlocalversion =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ dtc/genlocalversion 2007-07-26 16:56:18.000000000 +1000 @@ -0,0 +1,20 @@ +#! /bin/sh + +GIT_COMMITTISH="$1" +GIT_DESCRIBE="$2" +GIT_MANIFEST_HASH="$3" +shift 3 + +MANIFEST_HASH=$(cat "$@" | sha1sum | cut -f1 -d' ') + +if [ "$GIT_MANIFEST_HASH" = "$MANIFEST_HASH" ]; then + # Identical to a git committed version + DTC_VERSION="$GIT_DESCRIBE" +else + # Locallly modified + DTC_VERSION="locally-modified-$MANIFEST_HASH" +fi + +echo "#define DTC_VERSION \"$DTC_VERSION\"" +echo "#define DTC_GIT_COMMITTISH \"$GIT_COMMITTISH\"" +echo "#define DTC_MANIFEST_HASH \"$MANIFEST_HASH\"" Index: dtc/gengitmanifest =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ dtc/gengitmanifest 2007-07-26 16:56:18.000000000 +1000 @@ -0,0 +1,21 @@ +#! /bin/sh + +set -e + +catgitblobs () { + for f; do + git-cat-file blob HEAD:$f + done +} + +exec > "$1" + +echo "GIT_COMMITTISH = $(git-rev-parse HEAD)" +echo "GIT_DESCRIBE = $(git-describe)" + +FILES=$(git-ls-files) + +echo "MANIFEST_FILES = " $FILES +echo "version.h: \$(MANIFEST_FILES)" + +echo "GIT_MANIFEST_HASH = $(catgitblobs $FILES | sha1sum | cut -f1 -d' ')" Index: dtc/dtc.c =================================================================== --- dtc.orig/dtc.c 2007-07-26 16:56:12.000000000 +1000 +++ dtc/dtc.c 2007-07-26 16:56:18.000000000 +1000 @@ -21,7 +21,7 @@ #include "dtc.h" #include "srcpos.h" -#include "version_gen.h" +#include "version.h" /* * Command line options Index: dtc/scripts/setlocalversion =================================================================== --- dtc.orig/scripts/setlocalversion 2007-07-26 16:56:12.000000000 +1000 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,22 +0,0 @@ -#!/bin/sh -# Print additional version information for non-release trees. - -usage() { - echo "Usage: $0 [srctree]" >&2 - exit 1 -} - -cd "${1:-.}" || usage - -# Check for git and a git repo. -if head=`git rev-parse --verify HEAD 2>/dev/null`; then - # Do we have an untagged version? - if git name-rev --tags HEAD | grep -E '^HEAD[[:space:]]+(.*~[0-9]*|undefined)$' > /dev/null; then - printf '%s%s' -g `echo "$head" | cut -c1-8` - fi - - # Are there uncommitted changes? - if git diff-index HEAD | read dummy; then - printf '%s' -dirty - fi -fi -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-26 3:05 ` David Gibson 2007-07-26 7:25 ` David Gibson @ 2007-07-26 13:04 ` Jon Loeliger 2007-07-26 14:27 ` David Gibson 1 sibling, 1 reply; 27+ messages in thread From: Jon Loeliger @ 2007-07-26 13:04 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev So, like, the other day David Gibson mumbled: > On Wed, Jul 25, 2007 at 11:12:00AM -0500, Jon Loeliger wrote: > > Folks, > > > > I'd like to make an official DTC Version 1.0.0 release soon! > > It would certainly be great to have a release, since dtc is becoming > necessary for more and more kernel builds. > > Only thing I'm not really happy with in the current release is the > versioning stuff. For starters, it always reports my builds as > -dirty, even when they're not. I think it won't do that once there is a tag available. > It also seems a bit hideously > complicated for what it does. I'd prefer to see something simpler > using git-describe to derive the version strings directly from the git > tags themselves. That is essentially what is there now. We just need a tag! > Obviously we need some sort of cacheing mechanism to > make the versioning work for tarball releases without the git history, > but I think we can handle that with a suitable "make dist" target. Sure. > I'll see if I can make a patch or two in the next few days. I would like to keep the current version mechanism as it is really quite similar to what is in the Kernel now. Thanks, jdl ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-26 13:04 ` Jon Loeliger @ 2007-07-26 14:27 ` David Gibson 2007-07-26 15:21 ` Jon Loeliger 0 siblings, 1 reply; 27+ messages in thread From: David Gibson @ 2007-07-26 14:27 UTC (permalink / raw) To: Jon Loeliger; +Cc: linuxppc-dev On Thu, Jul 26, 2007 at 08:04:30AM -0500, Jon Loeliger wrote: > So, like, the other day David Gibson mumbled: > > On Wed, Jul 25, 2007 at 11:12:00AM -0500, Jon Loeliger wrote: > > > Folks, > > > > > > I'd like to make an official DTC Version 1.0.0 release soon! > > > > It would certainly be great to have a release, since dtc is becoming > > necessary for more and more kernel builds. > > > > Only thing I'm not really happy with in the current release is the > > versioning stuff. For starters, it always reports my builds as > > -dirty, even when they're not. > > I think it won't do that once there is a tag available. Your 1.0.0-rc1 tag is there, still showing as dirty. > > It also seems a bit hideously > > complicated for what it does. I'd prefer to see something simpler > > using git-describe to derive the version strings directly from the git > > tags themselves. > > That is essentially what is there now. We just need a tag! Um... no. The base version comes from the numbers specified in the Makefile, not from the git tag. > > Obviously we need some sort of cacheing mechanism to > > make the versioning work for tarball releases without the git history, > > but I think we can handle that with a suitable "make dist" target. > > Sure. > > > I'll see if I can make a patch or two in the next few days. > > I would like to keep the current version mechanism as it > is really quite similar to what is in the Kernel now. First, I don't think it really is - except in superficial aspect of how the version number is partitioned - the kernel has no auto version generating thing of this type. Second, I don't see that being similar to the kernel's approach has any particular usefulness here, anyway. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-26 14:27 ` David Gibson @ 2007-07-26 15:21 ` Jon Loeliger 2007-07-27 1:33 ` David Gibson 0 siblings, 1 reply; 27+ messages in thread From: Jon Loeliger @ 2007-07-26 15:21 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev So, like, the other day David Gibson mumbled: > > > Only thing I'm not really happy with in the current release is the > > > versioning stuff. For starters, it always reports my builds as > > > -dirty, even when they're not. > > > > I think it won't do that once there is a tag available. > > Your 1.0.0-rc1 tag is there, still showing as dirty. Hmmm.. Seems to work here. Is your working directory really clean? jdl.com 872 % make clean CLEAN (libfdt) CLEAN (tests) CLEAN jdl.com 873 % make LEX lex.yy.c BISON dtc-parser.tab.c ---- Expect 2 s/r and 2 r/r. ---- dtc-parser.y: conflicts: 2 shift/reduce, 2 reduce/reduce CHK version_gen.h UPD version_gen.h CC dtc.o CC flattree.o [ snip ] CC tests/del_node.o CC tests/truncated_property.o AS tests/trees.o DUMPTREES jdl.com 874 % ./dtc -v Version: DTC 1.0.0-rc1 I hve also verified that at least one other independent build using this approach produces a correct version string for them as well. > > That is essentially what is there now. We just need a tag! > > Um... no. The base version comes from the numbers specified in the > Makefile, not from the git tag. Ah, ok. I understand what you mean now. That part. So run it the other way instead. So perhaps have the Makefile generate the tag using those versioning parts instead using some "make tagged_release" target? > > I would like to keep the current version mechanism as it > > is really quite similar to what is in the Kernel now. > > First, I don't think it really is - except in superficial aspect of > how the version number is partitioned I lifted the code from the Kernel's Makefile directly, and tweaked it slightly for lack of Kconfig aspects. I don't want to tie the code and build mechanism to git too much. Specifically, we need to be able to support stand-alone tarball based builds. For example, I've spoken to the Debian package maintainer on this issue, and he likes this approach as well as he says it will make packaging it much easier. *sigh* jdl ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-26 15:21 ` Jon Loeliger @ 2007-07-27 1:33 ` David Gibson 2007-07-27 2:00 ` David Gibson 2007-08-06 13:48 ` Josh Boyer 0 siblings, 2 replies; 27+ messages in thread From: David Gibson @ 2007-07-27 1:33 UTC (permalink / raw) To: Jon Loeliger; +Cc: linuxppc-dev On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote: > So, like, the other day David Gibson mumbled: > > > > > Only thing I'm not really happy with in the current release is the > > > > versioning stuff. For starters, it always reports my builds as > > > > -dirty, even when they're not. > > > > > > I think it won't do that once there is a tag available. > > > > Your 1.0.0-rc1 tag is there, still showing as dirty. > > Hmmm.. Seems to work here. Is your working directory really clean? Yes, it really is. I have quilt control directories, but it still shows as dirty with no patches applied. Exttra files which don't affect the build shouldn't count as being dirty. > jdl.com 872 % make clean > CLEAN (libfdt) > CLEAN (tests) > CLEAN > jdl.com 873 % make > LEX lex.yy.c > BISON dtc-parser.tab.c > ---- Expect 2 s/r and 2 r/r. ---- > dtc-parser.y: conflicts: 2 shift/reduce, 2 reduce/reduce > CHK version_gen.h > UPD version_gen.h > CC dtc.o > CC flattree.o > [ snip ] > CC tests/del_node.o > CC tests/truncated_property.o > AS tests/trees.o > DUMPTREES > jdl.com 874 % ./dtc -v > Version: DTC 1.0.0-rc1 sneetch:~/ibm/dtc$ git-ls-files -m sneetch:~/ibm/dtc$ make clean CLEAN (libfdt) CLEAN (tests) CLEAN sneetch:~/ibm/dtc$ make BISON dtc-parser.tab.c LEX lex.yy.c ---- Expect 2 s/r and 2 r/r. ---- dtc-parser.y: conflicts: 2 shift/reduce, 2 reduce/reduce [snip] DUMPTREES sneetch:~/ibm/dtc$ ./dtc -v Version: DTC 1.0.0-rc1-dirty > I hve also verified that at least one other independent build > using this approach produces a correct version string for them > as well. Yes, well, this is the other trouble - the current system is so complex it's very hard to debug and figure out why it's claiming my build is dirty but not yours. > > > That is essentially what is there now. We just need a tag! > > > > Um... no. The base version comes from the numbers specified in the > > Makefile, not from the git tag. > > Ah, ok. I understand what you mean now. That part. > So run it the other way instead. So perhaps have the > Makefile generate the tag using those versioning parts > instead using some "make tagged_release" target? Hrm... I really think the other way is both easier and less fragile. > > > I would like to keep the current version mechanism as it > > > is really quite similar to what is in the Kernel now. > > > > First, I don't think it really is - except in superficial aspect of > > how the version number is partitioned > > I lifted the code from the Kernel's Makefile directly, and tweaked > it slightly for lack of Kconfig aspects. Ah, yes, ok, I see. Frankly I really don't think a lot of that stuff makes much sense outside the context of Kbuild. The whole complex filechk macro, for example - for which there's only one used parameter in dtc's case. > I don't want to tie the code and build mechanism to git too much. > Specifically, we need to be able to support stand-alone tarball > based builds. For example, I've spoken to the Debian package > maintainer on this issue, and he likes this approach as well as > he says it will make packaging it much easier. Have a look at the patch I posted. I haven't sufficiently tested it yet, but it should be able to generated version info for a tarball too (provided the .git-manifest file is included, and I'm intending that will be build by a make dist target). It will give both the git-derived based version, and a file content derived hash so we can robustly tell different builds apart, all with less code than the current system. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-27 1:33 ` David Gibson @ 2007-07-27 2:00 ` David Gibson 2007-07-31 21:11 ` Segher Boessenkool 2007-08-06 13:48 ` Josh Boyer 1 sibling, 1 reply; 27+ messages in thread From: David Gibson @ 2007-07-27 2:00 UTC (permalink / raw) To: Jon Loeliger, linuxppc-dev On Fri, Jul 27, 2007 at 11:33:31AM +1000, David Gibson wrote: > On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote: [snip] > > I hve also verified that at least one other independent build > > using this approach produces a correct version string for them > > as well. > > Yes, well, this is the other trouble - the current system is so > complex it's very hard to debug and figure out why it's claiming my > build is dirty but not yours. Ok, figured out why. When I push, then pop a quilt patch some of the files end up with their original contents, but changed timestamps. That altered stat information causes git-diff-index to give false indications of changed files, so setlocalversion adds the -dirty. Running git status, or gitool or various other things causes git to notice that the files aren't really changed, updates the index and then the version is generated correctly again. Not very robust though. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-27 2:00 ` David Gibson @ 2007-07-31 21:11 ` Segher Boessenkool 2007-08-01 1:19 ` David Gibson 0 siblings, 1 reply; 27+ messages in thread From: Segher Boessenkool @ 2007-07-31 21:11 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger > Ok, figured out why. When I push, then pop a quilt patch some of the > files end up with their original contents, but changed timestamps. > That altered stat information causes git-diff-index to give false > indications of changed files, so setlocalversion adds the -dirty. > Running git status, or gitool or various other things causes git to > notice that the files aren't really changed, updates the index and > then the version is generated correctly again. > > Not very robust though. Well you can't blame that on DTC's build system, nor on the setlocalversion script, and not on Git either; it's a Quilt problem... Segher ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-31 21:11 ` Segher Boessenkool @ 2007-08-01 1:19 ` David Gibson 2007-08-06 19:33 ` Segher Boessenkool 0 siblings, 1 reply; 27+ messages in thread From: David Gibson @ 2007-08-01 1:19 UTC (permalink / raw) To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger On Tue, Jul 31, 2007 at 11:11:57PM +0200, Segher Boessenkool wrote: > > Ok, figured out why. When I push, then pop a quilt patch some of the > > files end up with their original contents, but changed timestamps. > > That altered stat information causes git-diff-index to give false > > indications of changed files, so setlocalversion adds the -dirty. > > Running git status, or gitool or various other things causes git to > > notice that the files aren't really changed, updates the index and > > then the version is generated correctly again. > > > > Not very robust though. > > Well you can't blame that on DTC's build system, nor on the > setlocalversion script, and not on Git either; it's a Quilt > problem... No, it's really not - touching the files on a pop is correct behaviour for quilt (that way it will correctly trigger a rebuild on make systems that aren't as flashy as Kbuild). setlocalversion should be ensuring that the verison information is based on content, not stat info, which means it needs to do a git status or something that will remove the false positives before using git-diff-index to determine whether the tree is clean or not. But I still think my approach of basing the version info directly off a hash or the source is nicer still. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-01 1:19 ` David Gibson @ 2007-08-06 19:33 ` Segher Boessenkool 0 siblings, 0 replies; 27+ messages in thread From: Segher Boessenkool @ 2007-08-06 19:33 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger >>> Ok, figured out why. When I push, then pop a quilt patch some of the >>> files end up with their original contents, but changed timestamps. >>> That altered stat information causes git-diff-index to give false >>> indications of changed files, so setlocalversion adds the -dirty. >>> Running git status, or gitool or various other things causes git to >>> notice that the files aren't really changed, updates the index and >>> then the version is generated correctly again. >>> >>> Not very robust though. >> >> Well you can't blame that on DTC's build system, nor on the >> setlocalversion script, and not on Git either; it's a Quilt >> problem... > > No, it's really not - touching the files on a pop is correct behaviour > for quilt (that way it will correctly trigger a rebuild on make > systems that aren't as flashy as Kbuild). Yeah okay -- "it's a problem with how all these tools are used together" :-) > setlocalversion should be ensuring that the verison information is > based on content, not stat info, which means it needs to do a git > status or something that will remove the false positives before using > git-diff-index to determine whether the tree is clean or not. Yeah, that seems best. Please fix this for the kernel version of setlocalversion as well :-) Segher ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-27 1:33 ` David Gibson 2007-07-27 2:00 ` David Gibson @ 2007-08-06 13:48 ` Josh Boyer 2007-08-10 1:30 ` David Gibson 1 sibling, 1 reply; 27+ messages in thread From: Josh Boyer @ 2007-08-06 13:48 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger On Fri, 27 Jul 2007 11:33:31 +1000 David Gibson <david@gibson.dropbear.id.au> wrote: > On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote: > > So, like, the other day David Gibson mumbled: > > > > > > > Only thing I'm not really happy with in the current release is the > > > > > versioning stuff. For starters, it always reports my builds as > > > > > -dirty, even when they're not. > > > > > > > > I think it won't do that once there is a tag available. > > > > > > Your 1.0.0-rc1 tag is there, still showing as dirty. git vs quilt issue, as you have already discovered. I've always seen that with kernel builds. > > > > I would like to keep the current version mechanism as it > > > > is really quite similar to what is in the Kernel now. > > > > > > First, I don't think it really is - except in superficial aspect of > > > how the version number is partitioned > > > > I lifted the code from the Kernel's Makefile directly, and tweaked > > it slightly for lack of Kconfig aspects. > > Ah, yes, ok, I see. Frankly I really don't think a lot of that stuff > makes much sense outside the context of Kbuild. The whole complex > filechk macro, for example - for which there's only one used parameter > in dtc's case. Except didn't you say you were going to work with Stephen to get DTC into the kernel source itself? Keeping things similar to Kbuild might help in that effort. > > I don't want to tie the code and build mechanism to git too much. > > Specifically, we need to be able to support stand-alone tarball > > based builds. For example, I've spoken to the Debian package > > maintainer on this issue, and he likes this approach as well as > > he says it will make packaging it much easier. > > Have a look at the patch I posted. I haven't sufficiently tested it > yet, but it should be able to generated version info for a tarball too > (provided the .git-manifest file is included, and I'm intending that > will be build by a make dist target). It will give both the > git-derived based version, and a file content derived hash so we can > robustly tell different builds apart, all with less code than the > current system. That may be. But I don't see the current approach being too much of a problem either. Especially given that it's already there and it works. Oh, and you sent out your patch saying it wasn't ready for merge and with no sign off. Small but important issues to fix I'd think. This seems to be the last issue holding up a dtc 1.0 release. Perhaps we could go with what exists and see if there really are problems. It can always be fixed later. josh ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-06 13:48 ` Josh Boyer @ 2007-08-10 1:30 ` David Gibson 2007-08-10 1:37 ` Josh Boyer 2007-08-10 2:13 ` Geoff Levand 0 siblings, 2 replies; 27+ messages in thread From: David Gibson @ 2007-08-10 1:30 UTC (permalink / raw) To: Josh Boyer; +Cc: linuxppc-dev, Jon Loeliger On Mon, Aug 06, 2007 at 08:48:13AM -0500, Josh Boyer wrote: > On Fri, 27 Jul 2007 11:33:31 +1000 > David Gibson <david@gibson.dropbear.id.au> wrote: > > > On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote: > > > So, like, the other day David Gibson mumbled: > > > > > > > > > Only thing I'm not really happy with in the current release is the > > > > > > versioning stuff. For starters, it always reports my builds as > > > > > > -dirty, even when they're not. > > > > > > > > > > I think it won't do that once there is a tag available. > > > > > > > > Your 1.0.0-rc1 tag is there, still showing as dirty. > > git vs quilt issue, as you have already discovered. I've always seen > that with kernel builds. Yeah, ick. > > > > > I would like to keep the current version mechanism as it > > > > > is really quite similar to what is in the Kernel now. > > > > > > > > First, I don't think it really is - except in superficial aspect of > > > > how the version number is partitioned > > > > > > I lifted the code from the Kernel's Makefile directly, and tweaked > > > it slightly for lack of Kconfig aspects. > > > > Ah, yes, ok, I see. Frankly I really don't think a lot of that stuff > > makes much sense outside the context of Kbuild. The whole complex > > filechk macro, for example - for which there's only one used parameter > > in dtc's case. > > Except didn't you say you were going to work with Stephen to get DTC > into the kernel source itself? Keeping things similar to Kbuild might > help in that effort. Actually, after discussions with Stephen and Paulus, we decided not to take this route. In any case having Kbuild like versioning wouldn't actually help us any in integrating into a full Kbuild system. > > > I don't want to tie the code and build mechanism to git too much. > > > Specifically, we need to be able to support stand-alone tarball > > > based builds. For example, I've spoken to the Debian package > > > maintainer on this issue, and he likes this approach as well as > > > he says it will make packaging it much easier. > > > > Have a look at the patch I posted. I haven't sufficiently tested it > > yet, but it should be able to generated version info for a tarball too > > (provided the .git-manifest file is included, and I'm intending that > > will be build by a make dist target). It will give both the > > git-derived based version, and a file content derived hash so we can > > robustly tell different builds apart, all with less code than the > > current system. > > That may be. But I don't see the current approach being too much of a > problem either. Especially given that it's already there and it > works. Oh, and you sent out your patch saying it wasn't ready for > merge and with no sign off. Small but important issues to fix I'd > think. Yeah, it lacks a make dist target, and needs a bit more work to support that properly. Never mind, I'll revisit this post the 1.0 release. > This seems to be the last issue holding up a dtc 1.0 release. Perhaps > we could go with what exists and see if there really are problems. It > can always be fixed later. > > josh > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-10 1:30 ` David Gibson @ 2007-08-10 1:37 ` Josh Boyer 2007-08-10 2:59 ` David Gibson 2007-08-10 2:13 ` Geoff Levand 1 sibling, 1 reply; 27+ messages in thread From: Josh Boyer @ 2007-08-10 1:37 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger On Fri, 10 Aug 2007 11:30:01 +1000 David Gibson <dwg@au1.ibm.com> wrote: > > Except didn't you say you were going to work with Stephen to get DTC > > into the kernel source itself? Keeping things similar to Kbuild might > > help in that effort. > > Actually, after discussions with Stephen and Paulus, we decided not to > take this route. In any case having Kbuild like versioning wouldn't > actually help us any in integrating into a full Kbuild system. Can you elaborate why you decided not to? I'm just curious. > > > Have a look at the patch I posted. I haven't sufficiently tested it > > > yet, but it should be able to generated version info for a tarball too > > > (provided the .git-manifest file is included, and I'm intending that > > > will be build by a make dist target). It will give both the > > > git-derived based version, and a file content derived hash so we can > > > robustly tell different builds apart, all with less code than the > > > current system. > > > > That may be. But I don't see the current approach being too much of a > > problem either. Especially given that it's already there and it > > works. Oh, and you sent out your patch saying it wasn't ready for > > merge and with no sign off. Small but important issues to fix I'd > > think. > > Yeah, it lacks a make dist target, and needs a bit more work to > support that properly. Never mind, I'll revisit this post the 1.0 > release. Ok. josh ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-10 1:37 ` Josh Boyer @ 2007-08-10 2:59 ` David Gibson 2007-08-10 20:59 ` Segher Boessenkool 2007-08-11 0:52 ` Paul Mackerras 0 siblings, 2 replies; 27+ messages in thread From: David Gibson @ 2007-08-10 2:59 UTC (permalink / raw) To: Josh Boyer; +Cc: linuxppc-dev, Jon Loeliger On Thu, Aug 09, 2007 at 08:37:54PM -0500, Josh Boyer wrote: > On Fri, 10 Aug 2007 11:30:01 +1000 > David Gibson <dwg@au1.ibm.com> wrote: > > > > Except didn't you say you were going to work with Stephen to get DTC > > > into the kernel source itself? Keeping things similar to Kbuild might > > > help in that effort. > > > > Actually, after discussions with Stephen and Paulus, we decided not to > > take this route. In any case having Kbuild like versioning wouldn't > > actually help us any in integrating into a full Kbuild system. > > Can you elaborate why you decided not to? I'm just curious. We decided that since a formal dtc release was imminent, it would be simpler to make dtc a new kernel build requirement, rather than integrate the substantial blob of dtc code into the kernel tree and then have to deal with the maintenance / synchronization issues between the in-kernel and upstream versions. > > > > Have a look at the patch I posted. I haven't sufficiently tested it > > > > yet, but it should be able to generated version info for a tarball too > > > > (provided the .git-manifest file is included, and I'm intending that > > > > will be build by a make dist target). It will give both the > > > > git-derived based version, and a file content derived hash so we can > > > > robustly tell different builds apart, all with less code than the > > > > current system. > > > > > > That may be. But I don't see the current approach being too much of a > > > problem either. Especially given that it's already there and it > > > works. Oh, and you sent out your patch saying it wasn't ready for > > > merge and with no sign off. Small but important issues to fix I'd > > > think. > > > > Yeah, it lacks a make dist target, and needs a bit more work to > > support that properly. Never mind, I'll revisit this post the 1.0 > > release. > > Ok. > > josh > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-10 2:59 ` David Gibson @ 2007-08-10 20:59 ` Segher Boessenkool 2007-08-10 22:24 ` Geoff Levand 2007-08-11 0:52 ` Paul Mackerras 1 sibling, 1 reply; 27+ messages in thread From: Segher Boessenkool @ 2007-08-10 20:59 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger >>> Actually, after discussions with Stephen and Paulus, we decided not >>> to >>> take this route. In any case having Kbuild like versioning wouldn't >>> actually help us any in integrating into a full Kbuild system. >> >> Can you elaborate why you decided not to? I'm just curious. > > We decided that since a formal dtc release was imminent, it would be > simpler to make dtc a new kernel build requirement, For _all_ kernel builds? Most people building a powerpc kernel don't need it. Segher ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-10 20:59 ` Segher Boessenkool @ 2007-08-10 22:24 ` Geoff Levand 2007-08-10 23:39 ` Segher Boessenkool 0 siblings, 1 reply; 27+ messages in thread From: Geoff Levand @ 2007-08-10 22:24 UTC (permalink / raw) To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger, David Gibson Segher Boessenkool wrote: >>>> Actually, after discussions with Stephen and Paulus, we decided not >>>> to >>>> take this route. In any case having Kbuild like versioning wouldn't >>>> actually help us any in integrating into a full Kbuild system. >>> >>> Can you elaborate why you decided not to? I'm just curious. >> >> We decided that since a formal dtc release was imminent, it would be >> simpler to make dtc a new kernel build requirement, > > For _all_ kernel builds? Most people building a powerpc > kernel don't need it. The dtc is run from the wrapper script, so if you build for a platform that uses a dts source file, then you'll need the dtc. If you don't build for one of those platforms, then you won't needed it. So a 'make allXXXconfig' needs the dtc to be installed since it builds platforms that use dts source files. -Geoff ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-10 22:24 ` Geoff Levand @ 2007-08-10 23:39 ` Segher Boessenkool 0 siblings, 0 replies; 27+ messages in thread From: Segher Boessenkool @ 2007-08-10 23:39 UTC (permalink / raw) To: Geoff Levand; +Cc: linuxppc-dev, Jon Loeliger, David Gibson >>> We decided that since a formal dtc release was imminent, it would be >>> simpler to make dtc a new kernel build requirement, >> >> For _all_ kernel builds? Most people building a powerpc >> kernel don't need it. > > The dtc is run from the wrapper script, so if you build for a platform > that uses a dts source file, then you'll need the dtc. That should be fine then. We'll see :-) Segher ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-10 2:59 ` David Gibson 2007-08-10 20:59 ` Segher Boessenkool @ 2007-08-11 0:52 ` Paul Mackerras 2007-08-11 1:35 ` Geoff Levand 2007-08-12 9:25 ` David Gibson 1 sibling, 2 replies; 27+ messages in thread From: Paul Mackerras @ 2007-08-11 0:52 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger David Gibson writes: > We decided that since a formal dtc release was imminent, it would be > simpler to make dtc a new kernel build requirement, rather than > integrate the substantial blob of dtc code into the kernel tree and > then have to deal with the maintenance / synchronization issues > between the in-kernel and upstream versions. Um, what I thought we decided was to ship a pre-built .dtb for ps3 (once its dts settles down), and make dtc a kernel build requirement only for embedded platforms. Paul. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-11 0:52 ` Paul Mackerras @ 2007-08-11 1:35 ` Geoff Levand 2007-08-12 9:26 ` David Gibson 2007-08-12 9:25 ` David Gibson 1 sibling, 1 reply; 27+ messages in thread From: Geoff Levand @ 2007-08-11 1:35 UTC (permalink / raw) To: Paul Mackerras; +Cc: linuxppc-dev, Jon Loeliger, David Gibson Paul Mackerras wrote: > David Gibson writes: > >> We decided that since a formal dtc release was imminent, it would be >> simpler to make dtc a new kernel build requirement, rather than >> integrate the substantial blob of dtc code into the kernel tree and >> then have to deal with the maintenance / synchronization issues >> between the in-kernel and upstream versions. > > Um, what I thought we decided was to ship a pre-built .dtb for ps3 > (once its dts settles down), and make dtc a kernel build requirement > only for embedded platforms. We could also ship a generated .S file (dtc -O asm -o ps3-dt.S ps3.dts), which would be easier to maintain in the source tree than a binary file, then use something like this in the wrapper script: ${CROSS}gcc -c -o ${platform}-dt.o ${platform}-dt.S ${CROSS}objcopy -O binary ${platform}-dt.o ${platform}.dtb Untested, but it seems like it would work. -Geoff ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-11 1:35 ` Geoff Levand @ 2007-08-12 9:26 ` David Gibson 2007-08-13 1:39 ` Stephen Rothwell 0 siblings, 1 reply; 27+ messages in thread From: David Gibson @ 2007-08-12 9:26 UTC (permalink / raw) To: Geoff Levand; +Cc: linuxppc-dev, Jon Loeliger, Paul Mackerras On Fri, Aug 10, 2007 at 06:35:46PM -0700, Geoff Levand wrote: > Paul Mackerras wrote: > > David Gibson writes: > > > >> We decided that since a formal dtc release was imminent, it would be > >> simpler to make dtc a new kernel build requirement, rather than > >> integrate the substantial blob of dtc code into the kernel tree and > >> then have to deal with the maintenance / synchronization issues > >> between the in-kernel and upstream versions. > > > > Um, what I thought we decided was to ship a pre-built .dtb for ps3 > > (once its dts settles down), and make dtc a kernel build requirement > > only for embedded platforms. > > We could also ship a generated .S file (dtc -O asm -o ps3-dt.S ps3.dts), > which would be easier to maintain in the source tree than a binary file, > then use something like this in the wrapper script: > > ${CROSS}gcc -c -o ${platform}-dt.o ${platform}-dt.S > ${CROSS}objcopy -O binary ${platform}-dt.o ${platform}.dtb > > Untested, but it seems like it would work. Yes, I'm aware of that option and am considering it. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-12 9:26 ` David Gibson @ 2007-08-13 1:39 ` Stephen Rothwell 0 siblings, 0 replies; 27+ messages in thread From: Stephen Rothwell @ 2007-08-13 1:39 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Loeliger, Paul Mackerras, Jon [-- Attachment #1: Type: text/plain, Size: 770 bytes --] On Sun, 12 Aug 2007 19:26:27 +1000 David Gibson <dwg@au1.ibm.com> wrote: > > On Fri, Aug 10, 2007 at 06:35:46PM -0700, Geoff Levand wrote: > > > > We could also ship a generated .S file (dtc -O asm -o ps3-dt.S > > ps3.dts), which would be easier to maintain in the source tree than a > > binary file, then use something like this in the wrapper script: > > > > ${CROSS}gcc -c -o ${platform}-dt.o ${platform}-dt.S > > ${CROSS}objcopy -O binary ${platform}-dt.o ${platform}.dtb > > > > Untested, but it seems like it would work. > > Yes, I'm aware of that option and am considering it. Seems like a better option than a binary blob ... -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-11 0:52 ` Paul Mackerras 2007-08-11 1:35 ` Geoff Levand @ 2007-08-12 9:25 ` David Gibson 1 sibling, 0 replies; 27+ messages in thread From: David Gibson @ 2007-08-12 9:25 UTC (permalink / raw) To: Paul Mackerras; +Cc: linuxppc-dev, Jon Loeliger On Sat, Aug 11, 2007 at 10:52:07AM +1000, Paul Mackerras wrote: > David Gibson writes: > > > We decided that since a formal dtc release was imminent, it would be > > simpler to make dtc a new kernel build requirement, rather than > > integrate the substantial blob of dtc code into the kernel tree and > > then have to deal with the maintenance / synchronization issues > > between the in-kernel and upstream versions. > > Um, what I thought we decided was to ship a pre-built .dtb for ps3 > (once its dts settles down), and make dtc a kernel build requirement > only for embedded platforms. Oh, yes, sorry forgot that detail. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-10 1:30 ` David Gibson 2007-08-10 1:37 ` Josh Boyer @ 2007-08-10 2:13 ` Geoff Levand 1 sibling, 0 replies; 27+ messages in thread From: Geoff Levand @ 2007-08-10 2:13 UTC (permalink / raw) To: Josh Boyer, linuxppc-dev, Jon Loeliger David Gibson wrote: >> Except didn't you say you were going to work with Stephen to get DTC >> into the kernel source itself? Keeping things similar to Kbuild might >> help in that effort. > > Actually, after discussions with Stephen and Paulus, we decided not to > take this route. Could you please let us know what was discussed, and what was proposed to solve the problem of build failures when dtc is not installed? -Geoff ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-25 16:12 DTC 1.0.0 Release Coming? Jon Loeliger 2007-07-26 3:05 ` David Gibson @ 2007-07-31 21:09 ` Segher Boessenkool 2007-08-01 23:35 ` Arnd Bergmann 2 siblings, 0 replies; 27+ messages in thread From: Segher Boessenkool @ 2007-07-31 21:09 UTC (permalink / raw) To: Jon Loeliger; +Cc: linuxppc-dev > I'd like to make an official DTC Version 1.0.0 release soon! > To that end, I've published a repo on jdl.com with a v1.0.0-rc1 > tag on it. I anticipate some updates to the Documentation before > a final 1.0.0 release still. However, if you have something > you would like to have be in The Real 1.0.0 release, please > let me know soon! It would be nice it it would compile on non-Linux systems. Not a showstopper, but it would be nice :-) Segher ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-07-25 16:12 DTC 1.0.0 Release Coming? Jon Loeliger 2007-07-26 3:05 ` David Gibson 2007-07-31 21:09 ` Segher Boessenkool @ 2007-08-01 23:35 ` Arnd Bergmann 2007-08-02 0:14 ` David Gibson 2 siblings, 1 reply; 27+ messages in thread From: Arnd Bergmann @ 2007-08-01 23:35 UTC (permalink / raw) To: linuxppc-dev; +Cc: Jon Loeliger On Wednesday 25 July 2007, Jon Loeliger wrote: > I'd like to make an official DTC Version 1.0.0 release soon! > To that end, I've published a repo on jdl.com with a v1.0.0-rc1 > tag on it. =A0I anticipate some updates to the Documentation before > a final 1.0.0 release still. =A0However, if you have something > you would like to have be in The Real 1.0.0 release, please > let me know soon! A bug has been reported in both fedora and debian about /usr/bin/ftdump conflicting with a file of the same name in freetype. Can we rename the binary in dtc to avoid this? Maybe /usr/bin/dtc-ftdump would be better. Arnd <>< http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D434890 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D249638 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: DTC 1.0.0 Release Coming? 2007-08-01 23:35 ` Arnd Bergmann @ 2007-08-02 0:14 ` David Gibson 0 siblings, 0 replies; 27+ messages in thread From: David Gibson @ 2007-08-02 0:14 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linuxppc-dev, Jon Loeliger On Thu, Aug 02, 2007 at 01:35:03AM +0200, Arnd Bergmann wrote: > On Wednesday 25 July 2007, Jon Loeliger wrote: > > I'd like to make an official DTC Version 1.0.0 release soon! > > To that end, I've published a repo on jdl.com with a v1.0.0-rc1 > > tag on it. I anticipate some updates to the Documentation before > > a final 1.0.0 release still. However, if you have something > > you would like to have be in The Real 1.0.0 release, please > > let me know soon! > > A bug has been reported in both fedora and debian about /usr/bin/ftdump > conflicting with a file of the same name in freetype. > > Can we rename the binary in dtc to avoid this? Maybe /usr/bin/dtc-ftdump > would be better. Better yet, just omit it, since it's really not very useful. That should be happening now that my "improved make install target" patch has been merged. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2007-08-13 1:39 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-07-25 16:12 DTC 1.0.0 Release Coming? Jon Loeliger 2007-07-26 3:05 ` David Gibson 2007-07-26 7:25 ` David Gibson 2007-07-26 13:04 ` Jon Loeliger 2007-07-26 14:27 ` David Gibson 2007-07-26 15:21 ` Jon Loeliger 2007-07-27 1:33 ` David Gibson 2007-07-27 2:00 ` David Gibson 2007-07-31 21:11 ` Segher Boessenkool 2007-08-01 1:19 ` David Gibson 2007-08-06 19:33 ` Segher Boessenkool 2007-08-06 13:48 ` Josh Boyer 2007-08-10 1:30 ` David Gibson 2007-08-10 1:37 ` Josh Boyer 2007-08-10 2:59 ` David Gibson 2007-08-10 20:59 ` Segher Boessenkool 2007-08-10 22:24 ` Geoff Levand 2007-08-10 23:39 ` Segher Boessenkool 2007-08-11 0:52 ` Paul Mackerras 2007-08-11 1:35 ` Geoff Levand 2007-08-12 9:26 ` David Gibson 2007-08-13 1:39 ` Stephen Rothwell 2007-08-12 9:25 ` David Gibson 2007-08-10 2:13 ` Geoff Levand 2007-07-31 21:09 ` Segher Boessenkool 2007-08-01 23:35 ` Arnd Bergmann 2007-08-02 0:14 ` David Gibson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).