On 21 May 2015 at 05:05, Wes Turner <wes.tur...@gmail.com> wrote: > > > On Wed, May 20, 2015 at 12:13 PM, Chris Barker <chris.bar...@noaa.gov> > wrote: >>>> >>>> The package includes its build recipe in info/recipe >>> >>> >>> very cool -- I hadn't seen that -- I'll go take a look at some packages >>> and see what I can find. >> >> >> Darn -- the recipe is not there in most (all?) of the packages that came >> from Anaconda -- probably due to the legacy issues David referred to. > > The other day, I upgraded the version of conda-recipes/arrow to v0.5.4, and > added ofxparse. > > I should probably create some sort of recurring cron task to show how far > behind stable the version number in the meta.yaml is. (see: conda skeleton > --version-compare issue/PR (GH:conda/conda-build))
https://release-monitoring.org/ is a public service for doing that (more info on supported upstream backends at https://release-monitoring.org/about, more info on the federated messaging protocol used to publish alerts at http://www.fedmsg.com/en/latest/) Anitya (the project powering release-monitoring.org) was built as the "monitoring" part of Fedora's upstream release notification pipeline: https://fedoraproject.org/wiki/Upstream_release_monitoring One of my hopes for the metadata extension system in PEP 426 is that we'll be able to define extensions like "fedora.repackage", "debian.repackage" or "conda.repackage" which include whatever additional info is needed to automate creation of a policy compliant downstream package in a format that's a purely additive complement to the upstream metadata, rather than being somewhat duplicative as is the case today with things like spec files, deb control files, and conda recipes. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig