On Thu, Oct 09, 2014 at 09:17:41AM -0700, Jason Gerecke wrote: > On Thu, Oct 9, 2014 at 6:41 AM, Ron <r...@debian.org> wrote: > > > > Hi, > > > > The SF downloads appear to be showing a 0.26.1 release tarball, > > but I'm not seeing a version bump commit, or tag in the SF git > > repo. Did someone just forget to push, or did the primary git > > tree move again while I wasn't looking ;? > > > > [last chance for non-critical updates for Debian Jessie is about > > a week or two away now, a snapshot with the recent clang fixes > > should migrate to testing today, but I just noticed there is > > supposedly an actually released version of that now too ...] > > > > Cheers, > > Ron > > > The release should be tagged on Sourceforge as > 'xf86-input-wacom-0.26.1'. We normally release from the 'master' > branch, but as this was an unscheduled bugfix we cherry-picked the > change to a branch directly off of 0.26.0 (avoiding having it include > other non-fix changes that were already on master).
hmm, something odd is going on then, since I can see that tag and the cherry picked commit here: http://sourceforge.net/p/linuxwacom/xf86-input-wacom/ci/9c83d997ccdba38fd02d5bf163f10cdc4f000a9b/log/ and if I do a fresh clone of the repo I see it too. But fetching it normally as an update to my existing repo doesn't seem to work at all. It's not pulled by: git fetch sf (but I am correctly up to date on master with 8f856 as its head) An explicit: git fetch sf xf86-input-wacom-0.26.1 did pull the extra commits, but it still thinks the tag doesn't exist by that name (git tag -l doesn't show it). I can look at them by hash ref though and see 9c83d9. If I checkout that ref, then switch back to the master branch again, git reports: $ git checkout master Warning: you are leaving 2 commits behind, not connected to any of your branches: 9c83d99 wacom 0.26.1 1f9f17b Strengthen condition that pad may never be arbitrated pointer control If you want to keep them by creating a new branch, this may be a good time to do so with: git branch new_branch_name 9c83d99 And I likewise see: $ git fsck dangling tag c50b55fcf0a2faf61ddbdbbfef3371051e65c30c Where c50b55 does appear to be the signed tag for 0.26.1 It appears that I can 'fix' it locally by creating a temporary branch at 9c83d9, doing another "git fetch sf", which then pulls the tag name, and then force deleting that temporary branch name again ... After that git fsck seems to think everything is fine now. Which sounds like we've possibly tickled a git bug by not leaving that as a named branch and only pinning it with the tag :) I'm on git 2.1.1 right now. Ron ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
