Back
[07:29:46] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/config-cleanup bb774fe 06linuxcnc 10tcl/bin/pickconfig.tcl pickconfig: ignore nonexisting dirs in CONFIG_DIR * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb774fe
[07:29:47] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/config-cleanup b42db81 06linuxcnc 10configs/sim/gscreen/gladevcp-test.ui rearrange: provide gladevcp-test.ui * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b42db81
[08:05:40] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/config-cleanup 8d90ebb 06linuxcnc 10tcl/bin/pickconfig.tcl pickconfig: deeper search for ini files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8d90ebb
[14:15:05] <KGB-linuxcnc> 03Norbert Schechner 05master 078b655 06linuxcnc 10(15 files in 2 dirs) gmoccapy_0_9_9_6 - introduced plasma screen layout * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=078b655
[14:19:16] <KGB-linuxcnc> 03Norbert Schechner 05master 1791e0f 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py gmoccapy_0_9_9_6 - forgot to change release number * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1791e0f
[14:23:18] <cradek> norbert: now that you aren't separately maintaining gmoccapy, is there a reason to continue the release numbers? in the long view, it will be released whenever linuxcnc is released. in the short term, if you want people to report with what version they have a problem, asking for the git ref is the easiest way to do that. I think it's best to start thinking of linuxcnc and gmoccapy as a single combined project now.
[14:26:07] <norbert> cradek: If that is the usal way to do that, I will stop the release numbers, but IMHO, it is the easiest way to just ask the user what is the version number in the title bar, so I can look in my release notes and find out what changes has been done before and after that release.
[14:26:58] <alex_joni> maybe you can do it like AXIS then? include the git ref in the title bar?
[14:27:12] <seb_kuzminsky> that's a good way to do it
[14:27:29] <seb_kuzminsky> i think axis uses the info form the VERSION string, which the buildbot seeds with the git ref info
[14:27:39] <norbert> Ok, let me take a look to axis title bar
[14:29:04] <norbert> AXIS only tells AXIS 2.6.0~pre, that is not very usefull, isn't it?
[14:29:19] <alex_joni> I think that comes from VERSION
[14:29:30] <alex_joni> norbert: for compiled in place you're right
[14:29:37] <norbert> yes
[14:29:40] <alex_joni> but for packages that gets replaced with a proper number
[14:29:49] <alex_joni> (even if it's buildbot packages)
[14:30:03] <cradek> for user-built asking them to 'git describe' is really reasonable in my opinion
[14:30:46] <cradek> that gives you the exact ref (version of ALL files), where your manually-maintained versions do not
[14:31:47] <cradek> or else rip could maybe do something smarter with that shared version? it would be nice if it would be available for all guis.
[14:32:31] <norbert> OK, asking git describe gives me v2.5.3-2467-g179e0f
[14:32:51] <norbert> But I am on master, why 2.5?
[14:33:00] <cradek> the part after -g is the git ref. the rest is the most recent tag, and the number of revisions you are past that tag
[14:33:16] <cradek> there is no v2.6 related tags, so that is the latest one
[14:33:22] <alex_joni> maybe we could put this in the Makefile: GIT_VERSION := $(shell git describe --abbrev=4 --dirty --always)
[14:35:43] <norbert> But how to get the git version, before pushing? Otherwise I get not the latest one.
[14:36:21] <norbert> I do need that bevor pushing to include it the title bat, or can I get it from python code?
[14:36:43] <alex_joni> the idea is that the python code should make it happen automatically
[14:36:56] <norbert> yes, that would be fine
[14:37:21] <norbert> starting the gui, the release number may be added automatically
[14:38:16] <seb_kuzminsky> alex_joni: i'd prefer $(shell scripts/get-version-from-git), it does some smarter things that git describe doesnt
[14:38:56] <alex_joni> seb_kuzminsky: even better
[14:39:26] <alex_joni> sounds like we have a volunteer then
[14:39:50] <norbert> OK, is that me? I will try with supprocess ;-)
[14:40:07] <alex_joni> norbert: nah.. was talking about seb ;)
[14:40:24] <norbert> Oh I am glade not to have to work
[14:40:49] <alex_joni> but only for the Makefile part.. so it gets to 'older' GUIs like mini and tklinuxcnc
[14:41:01] <alex_joni> might be overthinking it though
[14:41:18] <seb_kuzminsky> there's currently a step in the package building that replaces VERSION with the output of that script
[14:41:52] <alex_joni> http://imagebin.org/281719
[14:43:34] <alex_joni> everything running on the BBB
[14:49:32] <cradek> do you have an X server on windows, or is AXIS running on the windows?
[14:49:54] <alex_joni> there's a portable Xserver on the BB, which gets executed on windows
[14:50:22] <cradek> hmm, that's both pragmatic and kind of nasty-feeling
[14:50:42] <cradek> is this your cute little metal box running it?
[14:50:45] <alex_joni> yeah
[14:50:48] <cradek> neat
[14:50:56] <cradek> that's sure a thing it seems people want
[14:51:01] <alex_joni> you just plug it in (to a win computer) and the config picker comes up
[14:51:34] <alex_joni> there's a ssh (key auth) + x forwarding in the background
[14:51:43] <cradek> wow
[14:52:08] <cradek> that sounds really convenient if you were in the habit of having windows computers around
[14:52:12] <alex_joni> I just put the pieces together.. they were all available
[14:54:26] <skunkworks> alex_joni, that is pretty cool!
[15:00:42] <alex_joni> skunkworks: yeah, hopefully that works on a couple PCs (haven't tried it much yet)
[15:06:18] <norbert> I just tried: release = os.popen("./scripts/get-version-from-git").readlines() but that make the start of the GUI about 2 seconds slower, any other idea
[15:06:33] <cradek> do it at build time, not run time
[15:07:21] <norbert> I do that starting the GUI, how do you mean at build time?
[15:07:36] <alex_joni> when the user does make
[15:07:57] <alex_joni> for python scripts there's a syntax checking and copying around (defined in the Submakefile)
[15:08:24] <norbert> Oh, than I do have to check the make file, that is realy not my stuff
[15:08:54] <norbert> And the user has to do a make, but many times for my little python code it is not needed
[15:09:26] <norbert> I will wait for sep ;-)
[18:05:03] <jepler> get-version-from-git wouldn't work in a package build anyway
[18:06:06] <jepler> python -c 'import linuxcnc; print linuxcnc.version'
[18:06:06] <jepler> 2.6.0~pre
[18:06:22] <jepler> you should use linuxcnc.version and if its value is not "good enough" for you then we can work on improving it
[18:15:37] <seb_kuzminsky> jepler: true, get-version-from-git is not included in the package, it's available at build-time and for run-in-place, but not when installed from the debian package
[18:21:37] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/config-cleanup 9bf26df 06linuxcnc 10(47 files in 15 dirs) rearrange: some configs housecleaning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9bf26df
[18:28:38] <jepler> possibly as I do here:
http://emergent.unpythonic.net/files/sandbox/improve-package-version.patches.mbox
[18:28:52] <jepler> after that one will see the git version in linuxcnc.version:
[18:28:52] <jepler> python -c 'import linuxcnc; print linuxcnc.version'
[18:28:52] <jepler> v2.6.0-pre0-4955-g20690e5
[18:29:02] <jepler> it potentially adds the earlier-mentioned 2 seconds to each build, though
[18:30:39] <seb_kuzminsky> why "PACKAGE_VERSION" instead of "LINUXCNC_VERSION"?
[19:37:55] <jepler> seb_kuzminsky: config.h already has a macro PACKAGE_VERSION
[19:38:02] <jepler> so this potentially replaces it with a better value
[19:38:24] <jepler> I have no idea why it's called PACKAGE_VERSION to begin with
[19:53:04] <seb_kuzminsky> ok