Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-9161

astrometry_net_data version has regressed to 8.0.0

    Details

    • Type: Bug
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: stack release
    • Labels:
      None

      Description

      As reported on the slack #dm-square channel, for unknown reasons the version of astrometry_net_data data appear in the w_2017_4 and w_2017_5 EUPS distrib tags has regressed to version 8.0.0. These are the first weekly tags since DM-9066. This is rather suprising as the 10.0 git tag on astrometry_net_data is from 2014.

        Attachments

          Issue Links

            Activity

            Hide
            swinbank John Swinbank added a comment -

            To be clear:

            • Setting $LSSTSW in ~/.bashrc is nothing to do with me and/or the shared stack. I don't know where that came from, but it's not a shared stack issue.
            • The shared stack code will not touch ~/.eups (it explicitly overrides the default EUPS behaviour). If something was screwing up the cache, it wasn't the shared stack, so you still have some digging to do. (Unless, of course, there's an EUPS bug which means it's not respecting $EUPS_USERDATA — I guess we can't rule that out).

            It'd be great if you could check with Science Pipelines before re-writing existing tags in future: existing installs of the changed tags are going to be different from new installs, which will make tracking down bugs harder. Thanks!

            Show
            swinbank John Swinbank added a comment - To be clear: Setting $LSSTSW in ~/.bashrc is nothing to do with me and/or the shared stack. I don't know where that came from, but it's not a shared stack issue. The shared stack code will not touch ~/.eups (it explicitly overrides the default EUPS behaviour). If something was screwing up the cache, it wasn't the shared stack, so you still have some digging to do. (Unless, of course, there's an EUPS bug which means it's not respecting $EUPS_USERDATA — I guess we can't rule that out). It'd be great if you could check with Science Pipelines before re-writing existing tags in future: existing installs of the changed tags are going to be different from new installs, which will make tracking down bugs harder. Thanks!
            Hide
            jhoblitt Joshua Hoblitt added a comment -

            You are correct that I made a bad assumption – all I know is someone other than me made a change. The joys of a party account.

            Show
            jhoblitt Joshua Hoblitt added a comment - You are correct that I made a bad assumption – all I know is someone other than me made a change. The joys of a party account.
            Hide
            swinbank John Swinbank added a comment -

            The joys of a party account

            Amen to that!

            Show
            swinbank John Swinbank added a comment - The joys of a party account Amen to that!
            Hide
            fritzm Fritz Mueller added a comment -

            erm... A few days ago, I had tried to revive the rebuild/publish tool environment on lsst-dev01 that I had been used to using on lsst-dev (before being redirected to use the jenkins jobs instead).

            Weird state in ~lsstsw/.eups etc may have been my fault – apologies

            Show
            fritzm Fritz Mueller added a comment - erm... A few days ago, I had tried to revive the rebuild/publish tool environment on lsst-dev01 that I had been used to using on lsst-dev (before being redirected to use the jenkins jobs instead). Weird state in ~lsstsw/.eups etc may have been my fault – apologies
            Hide
            jhoblitt Joshua Hoblitt added a comment -

            Fritz Mueller As an FYI, I've moved the credentials for versiondb into jenkins' internal credentials store and made some defensive changes to lsst/lsstsw to prevent multiple copies under ~lsstsw from automatically pushing and causing a conflict. Jenkins is effectively the only way to drive the canonical lsstsw install and I am hopeful that it will soon be migrated away.

            Show
            jhoblitt Joshua Hoblitt added a comment - Fritz Mueller As an FYI, I've moved the credentials for versiondb into jenkins' internal credentials store and made some defensive changes to lsst/lsstsw to prevent multiple copies under ~lsstsw from automatically pushing and causing a conflict. Jenkins is effectively the only way to drive the canonical lsstsw install and I am hopeful that it will soon be migrated away.

              People

              • Assignee:
                jhoblitt Joshua Hoblitt
                Reporter:
                jhoblitt Joshua Hoblitt
                Watchers:
                Colin Slater, Fritz Mueller, John Swinbank, Joshua Hoblitt
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: