I'm not sure either
ries_ is now known as ries
hi! i'm making headway in the garage! it's a long way to go still, but it's moving in the right direction :-)
can't wait to get that machine home :-)
yay! and I'm making progress buying replacements for the things you're taking :-)
every morning on my way to work i glance at that logo we milled on it and i smile, i feel like a little schoolboy in love
it's a simple love... a little one-sided
like most of my school-boy loves then ;-)
jepler: did you see my email about tagging our tree? are you still opposed to it?
I'm getting stuff packed up - the tooling is in a big bucket and a big box
apparently you're getting about 5 gallons of tooling...
seb_kuzminsky: I blew it off, sorry
i havent decided yet whether i'll do the moving (with my bro & his big truck&trailer) or whether i'll hire a real rigger
jepler: no problem, it's not really urgent
it's just a small change that would make the buildbot debs a little prettier
hm and it looks like I failed a reading test in kim's message
off by 2
seb_kuzminsky: yeah it's hard to decide. depends on your trailer more than anything I think
seb_kuzminsky: you say it was an e-mail where you asked me to put tags? I can't find it..
I felt like I needed more truck hauling my lathe, and that was downhill and lighter than the bridgeport - you would have it worse
I was using a full size pickup but it was just a v6. I should have used our other truck but it wasn't feeling up to it at the moment.
cradek: his trailer is rated for 10k lbs, it's got brakes and a wood floor, and he says his truck's big enough for it
that sounds pretty easy then... 10k is a very big trailer.
jepler: it was (somewhat misguidedly) in reply to your "v2.4_branch created" email to emc-devel
ah there it is
currently we're not really using tags, but i think that's "the way" to get git revnos to be legible to humans
can you use the 7i48 with hostmot2 on a 5i20?
jt-plasma: no, it uses muxed encoders to the fpga, which is not supported in the hostmot2 driver yet
looks like you could use the dac part
it looks like the PWM inputs are not on the same pins as they are on the other servo cards
er, PWM outputs
oh dang, don't listen to me
jt-plasma: yeah, so you'd have to email jeff and ask him to make a firmware with custom pinouts ;-)
I have question: if I have driver +-10V connected to my dac boards (simmilar to mesanet) and it seems that servo stops when voltage is +0.1V. how can (could) I set offset for dac value?
in our machines servo has that parameter, but what if other driver will not have this ?
usually there's a knob to adjust on the servo amp
also check your ground wiring carefully - 0.1v seems like a lot of offset
I don't know exact values, I just wanted to know idea
I can build SV12IM_2X7I48_72 for 5i20
jepler: would that work with 2 7i37's and the 7i48?
jt-plasma: I think so (but remember, the quadrature counters won't work without hostmot2 driver work)
ok, that would not be an advantage then, I was thinking of someone with 5 axis would only need one 7i48 and have two 7i37's for I/O
anyhow, I went ahead and built that firmware: http://emergent.unpy.net/files/sandbox/sv12im_2x7i48_72.bit http://emergent.unpy.net/files/sandbox/sv12im_2x7i48_72.pin
dang that is fast as fast can be...
it's not a difficult process once the setup is done. and it's not like I tested that it works or anything like that
now we just need Seb to doctor up hostmot2 :)
* jt-plasma heads back to the other shop
* jepler tries to decide about idromv3-for-2.3
to push or not to push...
EMC: 03jepler 07v2_3_branch * rfa31aa7ab048 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: dont be so princess-y about the locations of things
EMC: 03jepler 07v2_3_branch * rd192ad936302 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: accept IDROM Type 2 and Type 3
EMC: 03jepler 07v2_3_branch * r133b51da34e4 10/debian/changelog: note new feature
The 7I48 can be supported by the existing driver (If the IDROM lies about the hardware)
but I've wanted to avoid that, as the muxed encoder counter has different timing contraints
based on pcw saying that the registers are compatible between regular and muxed encoder, I've whipped this together: http://emergent.unpy.net/files/sandbox/0001-untested-support-for-muxed-encoders.patch
it'll load that sv12im_2x7148_72 bitfile and shows plausible things in dmesg and halcmd, but I can't test beyond that
seb_kuzminsky: so you think I should tag v2.5.0-pre at 68a3312b5a4418a4b14258fcfe8c4a34a45d2144 and v2.4.0-pre at 9e8f7c44f0c52850528b3f78da1dab501657674f ?
(git rejects ~ in tags, so I can't tag with ~pre; but we want the ~ in VERSION or at least debian/changelog so that the package name sorts before v2.5.0)
jepler: that sounds pretty good, and i'll switch out the first "-" for a "~" when i make the version number
it might be good to add a human-controlled number to the pre, ie tag it "2.5.0-pre0" instead of "2.5.0-pre". This way we can have somewhat controlled pre-releases as we go, might be nice (or it might be useless, i'm not sure)
oh, and the tag should ideally not have the leading "v". It should be as close as possible to the string we want as the version number
$ dpkg --compare-versions 2.5.0~pre eq 2.5.0~pre0 && echo true
$ dpkg --compare-versions 2.5.0~pre lt 2.5.0~pre1 && echo true
anyway, I think we can go up to ~pre1 later if we want
how about this: tag 8dc56... as "2.4.0-pre0", tag 68a33... as "2.5.0-pre0", and tag d0cc2... as "2.5.0-pre1"
once those tags as in i'll fix the debian/update-dch-frmo-git script to use this new convention
will you be using annotated tags or lightweight?
git tag -s (signed annotated)
that way you don't have to specify --tags to git describe
so you think I should put pre0 and pre1 in the git tag even if it's not in VERSION?
and why do you want two 2.5.0-pre* tags?
currently we have over 900 commits since the previous tag, and the "git log | dch" part of building the deb takes almost 10 minutes to run
by having multiple -pre's, we can keep that time down to something reasonable
if it's too much hassle to make those -pre tags i can totally live withotu it
the asymmetry bothers me
oh between that and the VERSION
you can put the v in and i'll strip it off
the tag v2.4.0-pre0 will be miles away from where v2.4.0 development started, but v2.5.0 will be right there
you could tag v2.4.0-pre0 as where trunk/master opened again after the 2.3 freeze
then make v2.4.0-pre1 where the v2.4_branch was made
OK, how about this? http://pastebin.com/m3e5416ad
that looks good, let me do a few more tests here
also we can make update-dch-from-git nice and fast
[20:53:26] <jepler> http://pastebin.com/m2d3af6b5
emc2 (1:1:1:1:1:1:2.5.0~pre) hardy; urgency=low
hm that's not quite right
why are we using epochs in the version number at all?
we made a mistake in versioning once
$ grep '^emc2' debian/changelog
fortunately all my mistakes have been made in the past
er, I meant to have - in all those tags, not _
either one's fine by me
as long as it's not a v, ., or number ;-)
$ debian/update-dch-from-git ; head -1 debian/changelog
emc2 (1:2.5.0~pre0-52-g79c83be) hardy; urgency=low
i think the v2.5.0_pre1 tag in that pastebin is wrong, it should be v2.4.0_pre1
argh I'll never get it right at this rate
oh duh it is
no it's me that'll never get it
you did it right
is that version number a good one? It comes from stripping the leading "v" and turning -pre into ~pre
it seems to me that any ~pre will come before 2.5.0 in debian version numbering
agreed, the ~ character sorts last: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
I'm not sure what we will do if we want "alpha" or "beta", since ~alpha is older than ~pre
er, i meant "sorts first", ie, is a lesser version than anything else
let's just call then ~preX
$ dpkg --compare-versions v2.5.0~pre+cvs-import-833-g3378b86 gt v2.5.0~pre1 && echo true
yes that sucks
i'm planning to manually remove all *cvs-import* debs, and ask people to remove them by hand from their machines
or we could use something else to make the new pre packages sort newer, ~.pre or ~+pre
soemthing like ~+pre would make it seamless, but at the cost of adding some cruft
my preference would be to keep the version numbers as simple as we can, and if that means manual action for the folks running the buildbot debs, i'm ok with that
four distinct IPs have downloaded debs from the buildbot
two of them are me
the other two are 22.214.171.124 and 126.96.36.199
the 64. one is registered to isomedia, an isp in washington state
the 75. one is registered to tds.net, an isp in Wisconsin
so, meh, looks like only two people care about buildbot debs and we should probably not add cruft to keep those two people happy
you want to test this new update-dch-from-git or should I just commit & push it?
.. I just pushed the tags
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-02-11.txt
and I went ahead with update-dch-from-git as well
EMC: 03jepler 07master * rdb9020a8af04 10/debian/update-dch-from-git: Merge branch 'improved-git-dch'
EMC: 03jepler 07v2.4_branch * rd83451d6d0b4 10/debian/update-dch-from-git: Merge branch 'improved-git-dch' into v2.4_branch
EMC: 03jepler 07master * r1acdfcadd463 10/debian/update-dch-from-git: improve changelog generation from git: faster, better version number
then i will abort my commit ;-)
oops, did I step on your toes?
nah its fine
your dch updater is way better than mine anyway
it's fast anyway
ooh, i didnt know the "bash is sed" syntax you used to change -pre to ~pre, nice
"git describe --abbrev=0" gives you just the tag, without having to sedify the raw describe output
bummer, i guess the git on my hardy vms is too old
oops, what did I write that didn't work there?
installing git from the hardy ppa, will rebuild those in a few moments
seb_kuzminsky: what did I write that didn't work? incidentally, I have 188.8.131.52 from the git ppa..
the hardy git doesnt understand --match
yeah, match is made of win
i installed 184.108.40.206 from the ppa on the buildslaves that care
that looks better
is there no log to view from master-checkin?
jepler: right, master-checkin only triggers other builders, so it has no log
and it's not just master, it's master or v2.4_branch