Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Wolf Vollprecht
    @wolfv
    I guess that could also be automated, right?
    Ryan May
    @dopplershift
    Did something change in the bot? According to the logs, numpy failed the version migration, but nothing has changed in the recipe since the last successful autotick on March 28.
    Matthew R. Becker
    @beckermr
    hmmmm
    we put in one change but it should not have changed this
    Ryan May
    @dopplershift
    Well now that I'm capable of actually reading error messages:
    Matthew R. Becker
    @beckermr
    let's see if the bot fixes itself - could be an HTTP error
    Ryan May
    @dopplershift
    Looks like the last one worked
    Matthew R. Becker
    @beckermr
    nice
    Matthew R. Becker
    @beckermr
    The R migration is going to slam drone pretty hard
    Should we move some packages to emulated builds during it?
    Travis too
    maybe we should wait it out
    Uwe L. Korn
    @xhochy
    We can cross-compile nowadays, no need for emulation but that would need a more sophisticated migratory (i.e. the same code we do for the osx-arm64 migration).
    Matthew R. Becker
    @beckermr
    ah right
    plus testing goes off for that
    not sure how much we care
    let's let it ride
    Uwe L. Korn
    @xhochy
    We can test with QEMU. Builds are fast as native and testing is slow as with emulation. I think @isuruf at least started somewhere a PR to only skip tests on osx-arm64. Not sure where that went.
    I would though just wait though, it's hopefully just a weekend of slowish Drone and most feedstocks are already migrated away from Travis since the R 4.0 migration.
    Isuru Fernando
    @isuruf
    Should be a simple PR
    Matthew R. Becker
    @beckermr
    I did some hacking on the bot to make it tries prs without errors first. R migration was a bit stalled. Hooefully this helps
    Bradley Dice
    @bdice
    https://github.com/conda-forge/signac-feedstock/pull/18/commits/88318a3cd354a4567fdc9d3fd2843097e99c5ce1
    Any idea why the bot removed the v from our tag version? We had to fix it manually and I don't think we changed anything in our release naming conventions. PR: conda-forge/signac-feedstock#18
    Bradley Dice
    @bdice
    Nevermind. I talked with the person who made the release and we made a mistake with the tag. Autotick bot is in the clear, sorry for the false alarm!
    Matthew R. Becker
    @beckermr
    @ForgottenProgramme
    Ezequiel Pássaro
    @epassaro
    Hi! How many days should we wait to see if the bot auto-updates our package?
    Latest release was on Saturday
    Matthew R. Becker
    @beckermr
    it should have done that by now
    check our status page for errors in the version section
    if you don't see any, let us know and we can look more inside the bot internals
    Ezequiel Pássaro
    @epassaro
    ok!
    tardis-sn: click for details
    The recipe did not change in the version migration, a URL did not hash, or there is jinja2 syntax the bot cannot handle!
    
    Please check the URLs in your recipe with version '2021.7.18.0' to make sure they exist!
    
    We also found the following errors:
    
     - migrations do not work on versions not specified with jinja2
    Matthew R. Becker
    @beckermr
    right
    this line is version_tag
    so change this to version only
    and then put the release- part in the url
    then you can get rid of stuff like this too version_tag.replace('release-', '')
    and just use {{ version }}
    Ezequiel Pássaro
    @epassaro
    Ohh I see
    Thank you!
    Matthew R. Becker
    @beckermr
    ofc!
    Ezequiel Pássaro
    @epassaro
    do conda-forge automatically removes the release-2021.7.18 from tag?
    Matthew R. Becker
    @beckermr
    yes
    we strip all chars before the tag
    and find the first number
    Ezequiel Pássaro
    @epassaro
    excellent, thanks
    Michał Krassowski
    @krassowski
    Is it possible for the bot to update hashes of multiple packages on PyPI for multiple outputs at once? For example over on https://github.com/conda-forge/jupyter-lsp-feedstock/pulls?q=is%3Apr+is%3Aclosed we have a frontend package (jupyterlab-lsp) and a backend package (jupyter-lsp) both as independent sources from PyPI: https://github.com/conda-forge/jupyter-lsp-feedstock/blob/2271657b1ca951f166747fd5691adee7efabe152/recipe/meta.yaml#L1-L24 but the bot only updates one of those and we have to do the update of the other manually. Is there a solution to this, or an issue where this is tracked?
    (half of the time we release both front and back together, half of the time only front and very rarely only back).
    Matthew R. Becker
    @beckermr
    the issue here is the multiple versions in one feedstock