From kon at iki.fi Mon Feb 4 17:06:57 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Tue, 05 Feb 2008 02:06:57 +0200 Subject: [elinks-dev] Bug#464073: elinks: 07_local-CGI-query-fix.diff patches the wrong function in 0.12 Message-ID: <87tzkocllq.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080205/2f877fba/attachment.bin From g68wmg402 at sneakemail.com Fri Feb 8 23:28:28 2008 From: g68wmg402 at sneakemail.com (Rob) Date: 9 Feb 2008 06:28:28 -0000 Subject: [elinks-dev] compile 1.1.4 rc0 with lua 5.0 on darwin 7.9/OS X? Message-ID: <13771-33740@sneakemail.com> Greetings, everyone. I have been trying to compile elinks with lua scripting, but for some reason, elinks is not recognizing my install of lua when I run configure. I have tried this with lua 5.0 (which is recommended on the elinks site) as well as 5.1 (which it seemed like configure tried to check for). Here is a link to my config.log file: http://www.freeshells.ch/~alexyeh/config.log From kon at iki.fi Sat Feb 9 01:53:51 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sat, 09 Feb 2008 10:53:51 +0200 Subject: [elinks-dev] compile 1.1.4 rc0 with lua 5.0 on darwin 7.9/OS X? In-Reply-To: <13771-33740@sneakemail.com> References: <13771-33740@sneakemail.com> Message-ID: <874pcifr34.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080209/6d166672/attachment.bin From g68wmg402 at sneakemail.com Sun Feb 10 01:38:03 2008 From: g68wmg402 at sneakemail.com (Rob) Date: 10 Feb 2008 08:38:03 -0000 Subject: [elinks-dev] compile 1.1.4 rc0 with lua 5.0 on darwin 7.9/OS X? Message-ID: <18651-35223@sneakemail.com> Thanks, Mr. Niemitalo? Here are the stdout messages from the lua 5.0 build: cd include; make all make[1]: Nothing to be done for `all'. cd src; make all gcc -O2 -Wall -I../include -c -o lapi.o lapi.c gcc -O2 -Wall -I../include -c -o lcode.o lcode.c gcc -O2 -Wall -I../include -c -o ldebug.o ldebug.c gcc -O2 -Wall -I../include -c -o ldo.o ldo.c gcc -O2 -Wall -I../include -c -o ldump.o ldump.c gcc -O2 -Wall -I../include -c -o lfunc.o lfunc.c gcc -O2 -Wall -I../include -c -o lgc.o lgc.c gcc -O2 -Wall -I../include -c -o llex.o llex.c gcc -O2 -Wall -I../include -c -o lmem.o lmem.c gcc -O2 -Wall -I../include -c -o lobject.o lobject.c gcc -O2 -Wall -I../include -c -o lopcodes.o lopcodes.c gcc -O2 -Wall -I../include -c -o lparser.o lparser.c gcc -O2 -Wall -I../include -c -o lstate.o lstate.c gcc -O2 -Wall -I../include -c -o lstring.o lstring.c gcc -O2 -Wall -I../include -c -o ltable.o ltable.c gcc -O2 -Wall -I../include -c -o ltests.o ltests.c gcc -O2 -Wall -I../include -c -o ltm.o ltm.c gcc -O2 -Wall -I../include -c -o lundump.o lundump.c gcc -O2 -Wall -I../include -c -o lvm.o lvm.c gcc -O2 -Wall -I../include -c -o lzio.o lzio.c ar rcu ../lib/liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltests.o ltm.o lundump.o lvm.o lzio.o ranlib ../lib/liblua.a ranlib: file: ../lib/liblua.a(ltests.o) has no symbols cd src/lib; make all gcc -O2 -Wall -I../../include -c -o lauxlib.o lauxlib.c gcc -O2 -Wall -I../../include -c -o lbaselib.o lbaselib.c gcc -O2 -Wall -I../../include -c -o ldblib.o ldblib.c gcc -O2 -Wall -I../../include -c -o liolib.o liolib.c gcc -O2 -Wall -I../../include -c -o lmathlib.o lmathlib.c gcc -O2 -Wall -I../../include -c -o ltablib.o ltablib.c gcc -O2 -Wall -I../../include -c -o lstrlib.o lstrlib.c gcc -O2 -Wall -I../../include -c -o loadlib.o loadlib.c ar rcu ../../lib/liblualib.a lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o ltablib.o lstrlib.o loadlib.o ranlib ../../lib/liblualib.a cd src/luac; make all gcc -O2 -Wall -I../../include -I.. -c -o luac.o luac.c gcc -O2 -Wall -I../../include -I.. -c -o print.o print.c gcc -o lopcodes.o -c -O2 -Wall -I../../include -I.. -DLUA_OPNAMES ../lopcodes.c gcc -o ../../bin/luac luac.o print.o lopcodes.o -L../../lib -llua -llualib -lm cd src/lua; make all gcc -O2 -Wall -I../../include -c -o lua.o lua.c gcc -o ../../bin/lua lua.o -L../../lib -llua -llualib -lm cd include; make all make[1]: Nothing to be done for `all'. cd src; make all make[1]: Nothing to be done for `all'. cd src/lib; make all make[1]: Nothing to be done for `all'. cd src/luac; make all make[1]: Nothing to be done for `all'. cd src/lua; make all make[1]: Nothing to be done for `all'. strip bin/* mkdir -p /usr/local/bin /usr/local/include /usr/local/lib /usr/local/man/man1 cp bin/* /usr/local/bin cp include/*.h /usr/local/include cp lib/*.a /usr/local/lib cp doc/*.1 /usr/local/man/man1 Here are the results from the elinks config.log: http://www.freeshells.ch/~alexyeh/config.log.1 exerpted: configure:17606: checking for Lua configure:17660: gcc -o conftest -g -O2 -Wall -rdynamic conftest.c -llua -llualib -lm -ldl -lz -lbz2 >&5 ld: table of contents for archive: /usr/local/lib/liblua.a is out of date; rerun ranlib(1) (can't load from it) ? The header message didn't appear this time, of course. From kon at iki.fi Sun Feb 10 04:57:30 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 10 Feb 2008 13:57:30 +0200 Subject: [elinks-dev] compile 1.1.4 rc0 with lua 5.0 on darwin 7.9/OS X? In-Reply-To: <18651-35223@sneakemail.com> References: <18651-35223@sneakemail.com> Message-ID: <87prv5c9cl.fsf@Astalo.kon.iki.fi> "Rob" writes: > Here are the stdout messages from the lua 5.0 build: I get the same on Mac OS 10.5.1 (Darwin 9.1.0, i386), except: > ar rcu ../lib/liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltests.o ltm.o lundump.o lvm.o lzio.o > ranlib ../lib/liblua.a > ranlib: file: ../lib/liblua.a(ltests.o) has no symbols Here I instead get: | ar rcu ../lib/liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltests.o ltm.o lundump.o lvm.o lzio.o | ranlib: file: ../lib/liblua.a(ltests.o) has no symbols | ranlib ../lib/liblua.a | ranlib: file: ../lib/liblua.a(ltests.o) has no symbols That is, ar ran ranlib on its own. So, it appears the ar utility has been modified between these Darwin versions, and perhaps ranlib too. I had no problem linking ELinks against liblua.a. Possibly the older ranlib got somehow confused at the "has no symbols" error and did not generate a correct table of contents. If this is the cause, you could perhaps work around the bug by editing lua-5.0/src/Makefile and removing ltests.o from OBJS, then removing and rebuilding liblua.a. Alternatively, add a dummy variable to ltests.c, outside #ifdef LUA_DEBUG. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080210/b0d84783/attachment.bin From g68wmg402 at sneakemail.com Wed Feb 13 15:26:09 2008 From: g68wmg402 at sneakemail.com (Rob) Date: 13 Feb 2008 22:26:09 -0000 Subject: [elinks-dev] compile 1.1.4 rc0 with lua 5.0 on darwin 7.9/OS X? Message-ID: <12610-75101@sneakemail.com> > [?] you could perhaps work around the bug by > editing lua-5.0/src/Makefile and removing ltests.o from OBJS, > then removing and rebuilding liblua.a. Alternatively, add a > dummy variable to ltests.c, outside #ifdef LUA_DEBUG. Same results as before. Thanks for the suggestions, though. Ultimately, I should probably just upgrade my OS? I just need a new computer first. From kon at iki.fi Sun Feb 24 13:38:40 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 24 Feb 2008 22:38:40 +0200 Subject: [elinks-dev] [patch/rfc] grafthistory: keep the downloaded pack, speed up git gc Message-ID: <878x1aqecv.fsf@Astalo.kon.iki.fi> To segregate the historical commits (can't remember why), I originally placed their pack in an alternate object store, but later I found that a *.keep file does the job as well. This gives a considerable speedup in git gc. It takes some more disk space but OTOH you might then run gc more often and have fewer loose objects. OK to push? grafthistory: keep the downloaded pack, speed up git gc --- commit df62c12c7e3a1153652d775101a1330f5b8156d8 tree 76b269ff5a291e6916713a0088881a2f6a1abdd3 parent 6139c2ffb5127a75aec176167e22298c693d339a author Kalle Olavi Niemitalo Sun, 24 Feb 2008 22:25:30 +0200 committer Kalle Olavi Niemitalo Sun, 24 Feb 2008 22:25:30 +0200 contrib/grafthistory.sh | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/contrib/grafthistory.sh b/contrib/grafthistory.sh index 447a638..7dd5ebc 100755 --- a/contrib/grafthistory.sh +++ b/contrib/grafthistory.sh @@ -19,6 +19,16 @@ cd "$GIT_DIR" echo "[grafthistory] Downloading the history" mkdir -p objects/pack cd objects/pack +# real user sys (tested in this order) +# 1m15.900s 0m59.732s 0m4.336s gc after clone&graft without *.keep +# 0m23.162s 0m17.549s 0m1.588s gc after clone&graft with *.keep +# 0m06.932s 0m04.440s 0m0.588s gc after clone&graft&gc with *.keep +# 0m32.214s 0m24.138s 0m2.284s gc after clone&graft&gc without *.keep +# Total size of .git/objects/pack/ was 90592 KiB without *.keep +# and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80% +# but increased disk space usage by 7.5%. +echo "ELinks history converted from CVS. Keep this pack separate to speed up git gc." \ + > pack-0d6c5c67aab3b9d5d9b245da5929c15d79124a48.keep # pack-0d6c5c67aab3b9d5d9b245da5929c15d79124a48.idx is 3163784 bytes long. # Downloading it takes less than 6 seconds here, whereas generating it # with git index-pack takes over 4 minutes (750 MHz Duron, git 1.5.4.1). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080224/b8585b4f/attachment.bin From kon at iki.fi Sun Feb 24 14:57:27 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 24 Feb 2008 23:57:27 +0200 Subject: [elinks-dev] Force protocol.http.compression = 1 again? Message-ID: <874pbyqapk.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080224/a094390a/attachment.bin From fonseca at diku.dk Wed Feb 27 03:05:41 2008 From: fonseca at diku.dk (Jonas Fonseca) Date: Wed, 27 Feb 2008 11:05:41 +0100 Subject: [elinks-dev] [patch/rfc] grafthistory: keep the downloaded pack, speed up git gc In-Reply-To: <878x1aqecv.fsf@Astalo.kon.iki.fi> References: <878x1aqecv.fsf@Astalo.kon.iki.fi> Message-ID: <20080227100541.GA26839@diku.dk> Kalle Olavi Niemitalo wrote Sun, Feb 24, 2008: > To segregate the historical commits (can't remember why), > I originally placed their pack in an alternate object store, > but later I found that a *.keep file does the job as well. > This gives a considerable speedup in git gc. It takes some > more disk space but OTOH you might then run gc more often > and have fewer loose objects. > > OK to push? Yes, please. It sounds like a very good idea. > +# real user sys (tested in this order) > +# 1m15.900s 0m59.732s 0m4.336s gc after clone&graft without *.keep > +# 0m23.162s 0m17.549s 0m1.588s gc after clone&graft with *.keep > +# 0m06.932s 0m04.440s 0m0.588s gc after clone&graft&gc with *.keep > +# 0m32.214s 0m24.138s 0m2.284s gc after clone&graft&gc without *.keep > +# Total size of .git/objects/pack/ was 90592 KiB without *.keep > +# and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80% > +# but increased disk space usage by 7.5%. Maybe without this? -- Jonas Fonseca From fonseca at diku.dk Wed Feb 27 05:36:28 2008 From: fonseca at diku.dk (Jonas Fonseca) Date: Wed, 27 Feb 2008 13:36:28 +0100 Subject: [elinks-dev] Force protocol.http.compression = 1 again? In-Reply-To: <874pbyqapk.fsf@Astalo.kon.iki.fi> References: <874pbyqapk.fsf@Astalo.kon.iki.fi> Message-ID: <20080227123628.GC3093@diku.dk> Kalle Olavi Niemitalo wrote Sun, Feb 24, 2008: > Commit d4cec950ecadb0c19206f28b0bf9c6d8992bc1e7 added > to src/protocol/http/http.c: > > #if !(defined(CONFIG_GZIP) || defined(CONFIG_BZIP2)) > #define COMP_NOTE "\nNote that this ELinks version has been compiled without compression\n" \ > "support anyway. This option will have no effect.\n" > #else > #define COMP_NOTE > #endif > INIT_OPT_BOOL("protocol.http", N_("Enable on-the-fly compression (experimental)"), > "compression", 0, 1, > N_("If enabled, the capability to receive compressed content (gzip and/or\n" > "bzip2) is announced to the server, which usually sends the reply\n" > "compressed, thus saving some bandwidth at slight CPU expense.\n" > "HOWEVER, please note that the ELinks implementation is unfortunately very\n" > "buggy and you may see incomplete pages, pages with garbage instead of\n" > "content, etc.!" COMP_NOTE)), Wouldn't it have been easier to just leave out the option completely? > Anyway, instead of putting the both versions of the whole string > inside #if, I'd like to revert this commit altogether. > With Witek's latest changes, compression is not so experimental > any more, I think. Can you find any site where it still fails? I haven't tested it personally, but I think it is the right thing to do. -- Jonas Fonseca From kon at iki.fi Wed Feb 27 11:53:12 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Wed, 27 Feb 2008 20:53:12 +0200 Subject: [elinks-dev] [patch/rfc] grafthistory: keep the downloaded pack, speed up git gc In-Reply-To: <20080227100541.GA26839@diku.dk> References: <878x1aqecv.fsf@Astalo.kon.iki.fi> <20080227100541.GA26839@diku.dk> Message-ID: <8763wa1baf.fsf_-_@Astalo.kon.iki.fi> Jonas Fonseca writes: >> +# Total size of .git/objects/pack/ was 90592 KiB without *.keep >> +# and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80% >> +# but increased disk space usage by 7.5%. > > Maybe without this? Why, is it too revealing? I thought a user might notice the *.keep file, check where it came from, and find those measurements. Then make an informed decision not to delete the file. Or perhaps the numbers should go in the *.keep file itself? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080227/269016da/attachment.bin From kon at iki.fi Wed Feb 27 12:10:38 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Wed, 27 Feb 2008 21:10:38 +0200 Subject: [elinks-dev] Force protocol.http.compression = 1 again? In-Reply-To: <20080227123628.GC3093@diku.dk> References: <874pbyqapk.fsf@Astalo.kon.iki.fi> <20080227123628.GC3093@diku.dk> Message-ID: <871w6y1ahd.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080227/01d9eb9a/attachment.bin From fonseca at diku.dk Wed Feb 27 12:19:37 2008 From: fonseca at diku.dk (Jonas Fonseca) Date: Wed, 27 Feb 2008 20:19:37 +0100 Subject: [elinks-dev] [patch/rfc] grafthistory: keep the downloaded pack, speed up git gc In-Reply-To: <8763wa1baf.fsf_-_@Astalo.kon.iki.fi> References: <878x1aqecv.fsf@Astalo.kon.iki.fi> <20080227100541.GA26839@diku.dk> <8763wa1baf.fsf_-_@Astalo.kon.iki.fi> Message-ID: <20080227191937.GA1038@diku.dk> Kalle Olavi Niemitalo wrote Wed, Feb 27, 2008: > Jonas Fonseca writes: > > >> +# Total size of .git/objects/pack/ was 90592 KiB without *.keep > >> +# and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80% > >> +# but increased disk space usage by 7.5%. > > > > Maybe without this? > > Why, is it too revealing? > I thought a user might notice the *.keep file, check where it > came from, and find those measurements. Then make an informed > decision not to delete the file. > Or perhaps the numbers should go in the *.keep file itself? It is just a suggestion; more information is not always better. You already mention in the keep file that it is a good idea to keep this file. -- Jonas Fonseca From kon at iki.fi Thu Feb 28 15:06:01 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Fri, 29 Feb 2008 00:06:01 +0200 Subject: [elinks-dev] please don't git describe in 0.12 Message-ID: <871w6wg2ie.fsf@Astalo.kon.iki.fi> In ELinks 0.11.3.GIT, there is: commit 36730c3c8389e0f31248b9fab0a0cb16b5562f1e Author: Jonas Fonseca Date: Tue Jan 22 13:21:29 2008 +0100 Use git tools instead of cogito for getting the build ID The build ID now includes both last tagged version, commit generation since last tagged version, as well as the leading characters of the commit ID and a flag for dirty working tree. Please do not apply this to ELinks 0.12.GIT. Firstly, it appears to consider the working tree dirty whenever I build ELinks outside the source directory. That would be easy to fix, though. The more annoying problem is that git describe happily picks whatever annotated tag is closest to the commit. I make use of many annotated tags that do not correspond to ELinks releases. For example, git cat-file tag bug/755/att380: | object 871a1befad3d9c37c59f228154d12fe37f594703 | type commit | tag bug/755/att380 | tagger Kalle Olavi Niemitalo 1185882530 +0300 | | Attachment 380 of ELinks bug 755, | "Crash when trying to load 401k.com login page" | | So, if I cherry-pick this change and I build ELinks, the About screen displays something like "bug/755/att380-268-ge3e894a-dirty". That is stupid because my bug/*/att* tags really stand for patches rather than for the resulting trees. With unreleased versions of Git, we could apparently use git describe --match "elinks-*" to consider ELinks releases only. But what should happen if the installed Git is older? I think the real solution to this would be for Git to define a way for .git/config to _exclude_ tags from git describe. Then I could upgrade to the required version and set the option, and ELinks would not have to care about Git versions or my tags. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080229/f8de4c91/attachment.bin From fonseca at diku.dk Thu Feb 28 16:35:45 2008 From: fonseca at diku.dk (Jonas Fonseca) Date: Fri, 29 Feb 2008 00:35:45 +0100 Subject: [elinks-dev] please don't git describe in 0.12 In-Reply-To: <871w6wg2ie.fsf@Astalo.kon.iki.fi> References: <871w6wg2ie.fsf@Astalo.kon.iki.fi> Message-ID: <20080228233545.GA12833@diku.dk> Kalle Olavi Niemitalo wrote Fri, Feb 29, 2008: > I think the real solution to this would be for Git to define > a way for .git/config to _exclude_ tags from git describe. > Then I could upgrade to the required version and set the option, > and ELinks would not have to care about Git versions or my tags. git describe --match "elinks-*" --match Only consider tags matching the given pattern (can be used to avoid leaking private tags made from the repository). -- Jonas Fonseca From kon at iki.fi Thu Feb 28 23:42:18 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Fri, 29 Feb 2008 08:42:18 +0200 Subject: [elinks-dev] please don't git describe in 0.12 In-Reply-To: <20080228233545.GA12833@diku.dk> References: <871w6wg2ie.fsf@Astalo.kon.iki.fi> <20080228233545.GA12833@diku.dk> Message-ID: <87oda0e01h.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080229/19b028af/attachment.bin From fonseca at diku.dk Fri Feb 29 00:52:44 2008 From: fonseca at diku.dk (Jonas Fonseca) Date: Fri, 29 Feb 2008 08:52:44 +0100 Subject: [elinks-dev] please don't git describe in 0.12 In-Reply-To: <87oda0e01h.fsf@Astalo.kon.iki.fi> References: <871w6wg2ie.fsf@Astalo.kon.iki.fi> <20080228233545.GA12833@diku.dk> <87oda0e01h.fsf@Astalo.kon.iki.fi> Message-ID: <20080229075244.GA19332@diku.dk> Kalle Olavi Niemitalo wrote Fri, Feb 29, 2008: > Jonas Fonseca writes: > > > git describe --match "elinks-*" > > > > --match > > Only consider tags matching the given pattern (can be used to avoid > > leaking private tags made from the repository). > > Now, which versions of Git support that? It seems to me that Git > 1.5.4.3 is the latest release and it recognizes no such option. > http://www.kernel.org/pub/software/scm/git/docs/v1.5.4.3/git-describe.html It was added in v1.5.4-rc1-21-g30ffa60. > Given that most people building ELinks probably do not have a > bleeding-edge Git installed (I currently don't), ELinks would > have to do something sane with older Git versions too. So just > adding the --match option to src/Makefile is not enough. Anyway, good old grep can probably also be used to pick a good candidate if you can get git-describe to list several tags. -- Jonas Fonseca From kon at iki.fi Fri Feb 29 02:00:32 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Fri, 29 Feb 2008 11:00:32 +0200 Subject: [elinks-dev] please don't git describe in 0.12 In-Reply-To: <20080229075244.GA19332@diku.dk> References: <871w6wg2ie.fsf@Astalo.kon.iki.fi> <20080228233545.GA12833@diku.dk> <87oda0e01h.fsf@Astalo.kon.iki.fi> <20080229075244.GA19332@diku.dk> Message-ID: <87oda0cf2n.fsf@Astalo.kon.iki.fi> Jonas Fonseca writes: > It was added in v1.5.4-rc1-21-g30ffa60. Kalle?Astalo:~/src/MIRROR/git 2$ git remote update [...] * [new tag] v1.5.4.2 -> v1.5.4.2 * [new tag] v1.5.4.3 -> v1.5.4.3 Kalle?Astalo:~/src/MIRROR/git 2$ git describe --contains v1.5.4-rc1-21-g30ffa60 undefined Kalle?Astalo:~/src/MIRROR/git 2$ git --no-pager grep "only consider tags matching" $(git tag) Kalle?Astalo:~/src/MIRROR/git 2$ So, that commit is not in any released version of Git. > Anyway, good old grep can probably also be used to pick a good candidate > if you can get git-describe to list several tags. I don't know if that is possible. Perhaps with --debug, but the format of that output might change. So then, the options appear to be: (a) Do not use git describe. Instead show the full SHA-1. (b) Make me suffer improper use of tags. (c) Make me move the tags out of .git/refs/tags/ so git describe doesn't see them. This might have undesirable side effects. (d) $(shell git describe --match "elinks-*" || git describe). Then make me upgrade Git to a version that supports --match. I would prefer postponing this until such a version is released. (e) $(shell git describe --match "elinks-*" || git rev-parse HEAD). (f) Change Git to let .git/config exclude patterns from git describe. Then make me upgrade Git to that version and add the option. I would prefer postponing this until such a version is released. The "next" branch in git.git supports git describe --match, so it seems likely that Git 1.5.5 will too. I propose we do (e) now and perhaps (d) after the Git 1.5.5 release. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080229/46009dcc/attachment.bin From fonseca at diku.dk Fri Feb 29 02:29:32 2008 From: fonseca at diku.dk (Jonas Fonseca) Date: Fri, 29 Feb 2008 10:29:32 +0100 Subject: [elinks-dev] please don't git describe in 0.12 In-Reply-To: <87oda0cf2n.fsf@Astalo.kon.iki.fi> References: <871w6wg2ie.fsf@Astalo.kon.iki.fi> <20080228233545.GA12833@diku.dk> <87oda0e01h.fsf@Astalo.kon.iki.fi> <20080229075244.GA19332@diku.dk> <87oda0cf2n.fsf@Astalo.kon.iki.fi> Message-ID: <20080229092932.GA31084@diku.dk> Kalle Olavi Niemitalo wrote Fri, Feb 29, 2008: > Jonas Fonseca writes: > > > It was added in v1.5.4-rc1-21-g30ffa60. > > Kalle???Astalo:~/src/MIRROR/git 2$ git describe --contains v1.5.4-rc1-21-g30ffa60 > undefined > > So, that commit is not in any released version of Git. fonseca at antimatter:~/src/git#next > echo OK OK > So then, the options appear to be: > (a) Do not use git describe. Instead show the full SHA-1. Well, let's just change to not use git describe, given that we already have the "tagged version info" from configure.in it doesn't have a lot of benefits apart from looking a little more friendly compared to 40 hex digits. I suppose you want to also remove the "-dirty" part. -- Jonas Fonseca From kon at iki.fi Fri Feb 29 15:27:56 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sat, 01 Mar 2008 00:27:56 +0200 Subject: [elinks-dev] please don't git describe in 0.12 In-Reply-To: <20080229092932.GA31084@diku.dk> References: <871w6wg2ie.fsf@Astalo.kon.iki.fi> <20080228233545.GA12833@diku.dk> <87oda0e01h.fsf@Astalo.kon.iki.fi> <20080229075244.GA19332@diku.dk> <87oda0cf2n.fsf@Astalo.kon.iki.fi> <20080229092932.GA31084@diku.dk> Message-ID: <87fxvb5rf7.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080301/d43cd414/attachment.bin