I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page.
Names of systems:
- pkgdb is the familiar Fedora Package DB https://admin.fedoraproject.org/pkgdb It provides some flags used by the other systems. - anitya is the web app running at https://release-monitoring.org It is responsible for scraping upstream release sites looking for new releases. - the-new-hotness is a backend daemon that responds to fedmsg messages about upstream releases.
The bugs filed in bugzilla look much the same as they did before, but for packagers there is one thing to note: the process of getting your package(s) registered for upstream release monitoring has changed. Please see the instructions[2] on the wiki page.
Old packages that were listed on the wiki page have been imported to release-monitoring.org and have had their monitoring flag set in pkgdb. New packages added to Fedora now have their monitoring flag set to True by default and a script attempts to map them to an upstream project in release-monitoring.org automatically.
If you want new upstream releases monitored for your package(s), you must:
- Add the upstream project to anitya[3]. - Map the upstream project to a Fedora package in anitya[3]. - Enable the monitoring flag for that Fedora package in pkgdb2[4].
Note also that it is now possible to get notifications about upstream releases without bugs being filed in bugzilla. To do this, add your projects to release-monitoring.org and configure your Fedora Notifications (FMN)[5] account while leaving the monitor flag set to False in pkgdb[4].
If you encounter bugs or have requests for enhancement, as always please do file them[6][7][8].. and if you're having problems with a particular package there is a place to list those[8] also on the wiki page.
[1] https://fedoraproject.org/wiki/Upstream_release_monitoring#Details [2] https://fedoraproject.org/wiki/Upstream_release_monitoring#TLDR.3B_Get_Packa... [3] https://release-monitoring.org [4] https://admin.fedoraproject.org/pkgdb [5] https://apps.fedoraproject.org/notifications [6] https://github.com/fedora-infra/anitya [7] https://github.com/fedora-infra/pkgdb2 [8] https://github.com/fedora-infra/the-new-hotness [9] https://fedoraproject.org/wiki/Upstream_release_monitoring#Requesting_Help
_______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Excerpts from Ralph Bean's message of 2015-02-21 06:36 +10:00:
I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page.
Nice work, this is looking great!
Is there any easy way I can check which of my packages *doesn't* yet have a valid mapping in Anitya, aside from checking each one by hand in the web UI?
I want to enable release monitoring on all my packages but I've lost track of which ones were correctly configured on the old wiki page.
Also, will Anitya warn me somehow if a configuration becomes invalid later (because upstream changed their hosting or similar)?
On Tue, Feb 24, 2015 at 09:59:24AM +1000, Dan Callaghan wrote:
Excerpts from Ralph Bean's message of 2015-02-21 06:36 +10:00:
I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page.
Nice work, this is looking great!
Is there any easy way I can check which of my packages *doesn't* yet have a valid mapping in Anitya, aside from checking each one by hand in the web UI?
It could be automated, but afaik, there is no tool (released) to do this yet, maybe you can convince Ralph to keep working on: https://github.com/ralphbean/ship-it as I believe it does part of what you want :)
I want to enable release monitoring on all my packages but I've lost track of which ones were correctly configured on the old wiki page.
Also, will Anitya warn me somehow if a configuration becomes invalid later (because upstream changed their hosting or similar)?
Not at the moment, but we could make anitya send a fedmsg message when it fails to retrieve correctly the information for a package. In the meanwhile, I try to go once in a while through the list of projects that failed to update: https://release-monitoring.org/projects/updates/failed
For example right now, I'm seeing 160 drupal related projects failing: https://release-monitoring.org/projects/updates/failed?log=drupal
Looks like the names need fixing :)
Pierre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 24.2.2015 v 14:25 Pierre-Yves Chibon napsal(a):
Weird pagination ....
Vít
On Wed, Feb 25, 2015 at 03:08:40PM +0100, Vít Ondruch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 24.2.2015 v 14:25 Pierre-Yves Chibon napsal(a):
Weird pagination ....
When you filter? Yes I found this out and it's fixed in git
Pierre
Dne 25.2.2015 v 15:23 Pierre-Yves Chibon napsal(a):
On Wed, Feb 25, 2015 at 03:08:40PM +0100, Vít Ondruch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 24.2.2015 v 14:25 Pierre-Yves Chibon napsal(a):
Weird pagination ....
When you filter?
I just opened the page and click to go forward, no filtering.
Yes I found this out and it's fixed in git
Thx.
Vít
On Fri, Feb 20, 2015 at 03:36:11PM -0500, Ralph Bean wrote:
I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page.
Names of systems:
- pkgdb is the familiar Fedora Package DB https://admin.fedoraproject.org/pkgdb It provides some flags used by the other systems.
- anitya is the web app running at https://release-monitoring.org It is responsible for scraping upstream release sites looking for new releases.
- the-new-hotness is a backend daemon that responds to fedmsg messages about upstream releases.
This is very cool! Thank you and congrats to the new release!
Matthias
On 02/20/2015 09:36 PM, Ralph Bean wrote:
I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page.
Names of systems:
- pkgdb is the familiar Fedora Package DB https://admin.fedoraproject.org/pkgdb It provides some flags used by the other systems.
- anitya is the web app running at https://release-monitoring.org It is responsible for scraping upstream release sites looking for new releases.
- the-new-hotness is a backend daemon that responds to fedmsg messages about upstream releases.
The bugs filed in bugzilla look much the same as they did before, but for packagers there is one thing to note: the process of getting your package(s) registered for upstream release monitoring has changed. Please see the instructions[2] on the wiki page.
Old packages that were listed on the wiki page have been imported to release-monitoring.org and have had their monitoring flag set in pkgdb. New packages added to Fedora now have their monitoring flag set to True by default and a script attempts to map them to an upstream project in release-monitoring.org automatically.
If you want new upstream releases monitored for your package(s), you must:
- Add the upstream project to anitya[3].
- Map the upstream project to a Fedora package in anitya[3].
- Enable the monitoring flag for that Fedora package in pkgdb2[4].
Note also that it is now possible to get notifications about upstream releases without bugs being filed in bugzilla. To do this, add your projects to release-monitoring.org and configure your Fedora Notifications (FMN)[5] account while leaving the monitor flag set to False in pkgdb[4].
If you encounter bugs or have requests for enhancement, as always please do file them[6][7][8].. and if you're having problems with a particular package there is a place to list those[8] also on the wiki page.
[1] https://fedoraproject.org/wiki/Upstream_release_monitoring#Details [2] https://fedoraproject.org/wiki/Upstream_release_monitoring#TLDR.3B_Get_Packa... [3] https://release-monitoring.org [4] https://admin.fedoraproject.org/pkgdb [5] https://apps.fedoraproject.org/notifications [6] https://github.com/fedora-infra/anitya [7] https://github.com/fedora-infra/pkgdb2 [8] https://github.com/fedora-infra/the-new-hotness [9] https://fedoraproject.org/wiki/Upstream_release_monitoring#Requesting_Help
devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Really nice and good work.
In our project called rebase-helper https://github.com/phracek/rebase-helper we would like to analyze a new upstream version against an old upstream version and let user now what is changed. E.g. Binaries are missing, soname bump change, header files are missing etc.
Is there any possibility how to integrate a tool (e.g. rebase-helper) to upstream release monitoring system?
Thanks for the good and hard work again.
On Tue, Feb 24, 2015 at 12:33:29PM +0100, Petr Hracek wrote:
On 02/20/2015 09:36 PM, Ralph Bean wrote: Names of systems:
- pkgdb is the familiar Fedora Package DB https://admin.fedoraproject.org/pkgdb It provides some flags used by the other systems.
- anitya is the web app running at https://release-monitoring.org It is responsible for scraping upstream release sites looking for new releases.
- the-new-hotness is a backend daemon that responds to fedmsg messages about upstream releases.
The bugs filed in bugzilla look much the same as they did before, but for packagers there is one thing to note: the process of getting your package(s) registered for upstream release monitoring has changed. Please see the instructions[2] on the wiki page.
Old packages that were listed on the wiki page have been imported to release-monitoring.org and have had their monitoring flag set in pkgdb. New packages added to Fedora now have their monitoring flag set to True by default and a script attempts to map them to an upstream project in release-monitoring.org automatically.
If you want new upstream releases monitored for your package(s), you must:
- Add the upstream project to anitya[3].
- Map the upstream project to a Fedora package in anitya[3].
- Enable the monitoring flag for that Fedora package in pkgdb2[4].
[1] https://fedoraproject.org/wiki/Upstream_release_monitoring#Details [2] https://fedoraproject.org/wiki/Upstream_release_monitoring#TLDR.3B_Get_Packa... [3] https://release-monitoring.org
Really nice and good work.
In our project called rebase-helper https://github.com/phracek/rebase-helper we would like to analyze a new upstream version against an old upstream version and let user now what is changed. E.g. Binaries are missing, soname bump change, header files are missing etc.
Is there any possibility how to integrate a tool (e.g. rebase-helper) to upstream release monitoring system?
I think the easiest for this is to rely on fedmsg to find out about the new releases. Looking further into rebase-helper maybe a better place to integrate it would be the-new-hotness as it seems to be pretty Fedora specific for anitya*.
Pierre
* Anitya isn't meant to be Fedora specific, on the contrary, we would like to have as many distros as possible.
On Tue, Feb 24, 2015 at 12:33:29PM +0100, Petr Hracek wrote:
In our project called rebase-helper https://github.com/phracek/rebase-helper we would like to analyze a new upstream version against an old upstream version and let user now what is changed. E.g. Binaries are missing, soname bump change, header files are missing etc.
Is there any possibility how to integrate a tool (e.g. rebase-helper) to upstream release monitoring system?
Wow. This looks great and I'd love to have it integrated into the-new-hotness (that's the Fedora-specific daemon that files bugs and tries scratch builds).
The relevant code is here: https://github.com/fedora-infra/the-new-hotness/blob/develop/hotness/buildsy...
Want to try your hand at adding it in? Stop by #fedora-apps when you have time to chat about it and we can work on the details if you like.
We're entering infrastructure Alpha freeze later today, so we wouldn't be able to push this out for a few weeks at the earliest.
On 02/24/2015 05:58 PM, Ralph Bean wrote:
On Tue, Feb 24, 2015 at 12:33:29PM +0100, Petr Hracek wrote:
In our project called rebase-helper https://github.com/phracek/rebase-helper we would like to analyze a new upstream version against an old upstream version and let user now what is changed. E.g. Binaries are missing, soname bump change, header files are missing etc.
Is there any possibility how to integrate a tool (e.g. rebase-helper) to upstream release monitoring system?
Wow. This looks great and I'd love to have it integrated into the-new-hotness (that's the Fedora-specific daemon that files bugs and tries scratch builds).
The relevant code is here: https://github.com/fedora-infra/the-new-hotness/blob/develop/hotness/buildsy...
Want to try your hand at adding it in? Stop by #fedora-apps when you have time to chat about it and we can work on the details if you like.
We're entering infrastructure Alpha freeze later today, so we wouldn't be able to push this out for a few weeks at the earliest.
Well, new version of rebase-helper (0.5.0) is going to be available soon.
I have looked at the relevant code and seems to be fine to integrated rebase-helper to the-new-hotness. I will provide a API to rebase-helper soon. I will inform you about it, though.
What rebase-helper needs is a directory with package and version.
On 02/24/2015 05:58 PM, Ralph Bean wrote:
On Tue, Feb 24, 2015 at 12:33:29PM +0100, Petr Hracek wrote:
In our project called rebase-helper https://github.com/phracek/rebase-helper we would like to analyze a new upstream version against an old upstream version and let user now what is changed. E.g. Binaries are missing, soname bump change, header files are missing etc.
Is there any possibility how to integrate a tool (e.g. rebase-helper) to upstream release monitoring system?
Wow. This looks great and I'd love to have it integrated into the-new-hotness (that's the Fedora-specific daemon that files bugs and tries scratch builds).
The relevant code is here: https://github.com/fedora-infra/the-new-hotness/blob/develop/hotness/buildsy...
Want to try your hand at adding it in? Stop by #fedora-apps when you have time to chat about it and we can work on the details if you like.
We're entering infrastructure Alpha freeze later today, so we wouldn't be able to push this out for a few weeks at the earliest.
rebase-helper is mostly finish for upstream monitoring system. I would like to ask you for some things. 1) Where the-new-hotness daemon is running? 2) Do you think that it is possible to install rebase-helper package on the system where the-new-hotness daemon runs? If not shall I start my own system where the rebase-helper will run? I suggest that first one option is the best. 3) In first case should I start my own daemon or the-new-hotness-daemon will call rebase-helper API? https://github.com/fedora-infra/the-new-hotness/blob/develop/hotness/buildsy...
Would it be possible to get an access to that machine. For testing purpose.
4) What parameters will be passed to rebase-helper? msg structure?
5) Rebase-helper currently builds an RPM packages with rpmbuild. But fedpkg is better I guess. Rebase-helper will build old and new packages with fedpkg scratch builds. Could you please advise me how to execute them with fedpkg? Of course I can read the-new-hotness daemon source and implemented by myself.
This looks cool.
On Fri, Feb 20, 2015 at 2:36 PM, Ralph Bean rbean@redhat.com wrote:
- Enable the monitoring flag for that Fedora package in pkgdb2[4].
I think this is the step people will forget to do. If there was at least a reminder on the release-monitoring website, that would be helpful.
On Tue, Feb 24, 2015 at 10:33:34AM -0600, Michael Catanzaro wrote:
This looks cool. On Fri, Feb 20, 2015 at 2:36 PM, Ralph Bean rbean@redhat.com wrote:
- Enable the monitoring flag for that Fedora package in pkgdb2[4].I think this is the step people will forget to do. If there was at least a reminder on the release-monitoring website, that would be helpful.
This is now `on` by default for every new package added to pkgdb. For the old one you will have to do it manually (or via a script using the API).
Pierre
On Tue, Feb 24, 2015 at 9:51 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Tue, Feb 24, 2015 at 10:33:34AM -0600, Michael Catanzaro wrote:
This looks cool. On Fri, Feb 20, 2015 at 2:36 PM, Ralph Bean rbean@redhat.com wrote:
- Enable the monitoring flag for that Fedora package in pkgdb2[4].I think this is the step people will forget to do. If there was at
least a
reminder on the release-monitoring website, that would be helpful.
This is now `on` by default for every new package added to pkgdb. For the old one you will have to do it manually (or via a script using the API).
Could a one time report be generated and sent to the mailing? Or is the list too long for that to be feasible?
Thanks, Dave
On Tue, Feb 24, 2015 at 11:42:49AM -0700, Dave Johansen wrote:
On Tue, Feb 24, 2015 at 9:51 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Tue, Feb 24, 2015 at 10:33:34AM -0600, Michael Catanzaro wrote: >A A This looks cool. >A A On Fri, Feb 20, 2015 at 2:36 PM, Ralph Bean <rbean@redhat.com> wrote: > >A A A - Enable the monitoring flag for that Fedora package in pkgdb2[4]. > >A A I think this is the step people will forget to do. If there was at least a >A A reminder on the release-monitoring website, that would be helpful. This is now `on` by default for every new package added to pkgdb. For the old one you will have to do it manually (or via a script using the API).Could a one time report be generated and sent to the mailing? Or is the list too long for that to be feasible?
Rather than doing a one-time script/report I wrote a script anyone can run as often as they would like:
http://blog.pingoured.fr/index.php?post/2015/02/25/Check-your-packages-in-pk...
Pierre
On Sun, Mar 01, 2015 at 01:58:24PM +0100, Michael Schwendt wrote:
On Fri, 20 Feb 2015 15:36:11 -0500, Ralph Bean wrote:
If you encounter bugs or have requests for enhancement, as always please do file them[6][7][8]..
Done. Thanks for a premature April Fool's prank. ;)
Heh, no problem. ;)
For those not in the know, this is in reference to: https://github.com/fedora-infra/the-new-hotness/issues/29
devel@lists.stg.fedoraproject.org
-
Dan Callaghan -
Dave Johansen -
Matthias Runge -
Michael Catanzaro -
Michael Schwendt -
Petr Hracek -
Pierre-Yves Chibon -
Ralph Bean -
Vít Ondruch