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