Le blog de pingou - Tag - anityaLe blog de pingou, ses actualités sur Fedora, ses RPMs, ses tests, son Linux... :-)
Pingou's weblog, his fedora's news, his RPMs, his tests, his Linux... :-)2022-02-17T10:46:15+01:00pingouurn:md5:66db5ce1ed1a80cb2f424695b4bb7780DotclearCheck packages in anitya and pkgdb2 for monitoringurn:md5:0ea9bd66560831a66c1a58bd5995c8c32015-05-07T12:26:00+01:002015-05-07T11:29:14+01:00Pierre-YvesGénéralanityaAstucesDocumentationFedoraFedora-planetpkgdb <p>A little while ago I <a href="http://blog.pingoured.fr/index.php?post/2015/02/25/Check-your-packages-in-pkgdb-and-anitya">presented a script allowing to search for the packages of a specified user</a> and see which are missing from either anitya or are not being monitored in pkgdb2.</p>
<p>This script however, only check someone's packages and someone time we want to check a number of packages at once, eventually, all the packages matching a given template.</p>
<p>This new script does just that:</p>
<pre> $ python pkgs_not_in_anitya_2.py 'drupal-*'
drupal-service_links Monitor=False Anitya=False
drupal-calendar Monitor=False Anitya=False
drupal-cck Monitor=False Anitya=False
drupal-date Monitor=False Anitya=False
drupal-workspace Monitor=False Anitya=False
drupal-views Monitor=False Anitya=False</pre>
<p>If you are interested, feel free to use <a href="http://blog.pingoured.fr/public/pkgs_not_in_anitya_2.py">the script</a></p>About SourceForge and anityaurn:md5:b0cac0056b13d8288eb65bc76a8d6fcc2015-02-25T10:17:00+00:002015-02-25T10:28:42+00:00Pierre-YvesGénéralanityaFedoraFedora-InfraFedora-planet <p>There are a couple of reports (<a href="https://github.com/fedora-infra/anitya/issue/80">1</a>
and <a href="https://blog.pingoured.fr/index.php?post/2015/02/25/">2</a>) about anitya not
doing its job properly for projects hosted on <a href="http://sourceforge.net">sourceforge.net</a>.</p>
<p>So here is a summary of the situation:</p>
<p>A project X on sourceforge.net, for example with a homepage sourceforge.net/projects/X,
releases multiples tarball named, X-1.2.tar.gz, libX-0.3.tar.gz and
libY-2.0.tar.gz.</p>
<p>So how to model this.</p>
<p>The original approach taken was: the project is named X, so in anitya we
should name it X and then the sourceforge backend in anitya allows to specify a
Sourceforge project allowing to search X, libX or libY in the rss feed of the X
project on SourceForge.
Problem: when adding libX or libY on anitya, the project and homepage are all
X and sourceforge.net/projects/X, while this is actually used to make project
uniques in anitya (in other words, adding libX and libY won't be allowed).</p>
<p>So this is the current situation and as you can see, it has problems (which
explains the two issues reported).</p>
<p><br /></p>
<p>What are the potential solutions?</p>
<p>1/ Extend the unique constraint</p>
<p>We could include the tarball name to search for in the unique constraint, which
would then change from: name+homepage to name+homepage+tarball</p>
<p>2/ Invert the use of name and tarball</p>
<p>Instead of having the project name be X with a tarball name libX, we could make
the project be libX and the tarball be X.</p>
<p>This sounds quite nice and easy, but looking at the project currently in anitya's
database, I found projects like:</p>
<pre> name | homepage | tarball
+ +
linuxwacom | http://sf.net/projects/linuxwacom/ | xf86-input-wacom
brutalchess (alpha) | http://sourceforge.net/p/brutalchess | brutalchess-alpha
chemical-mime | http://sourceforge.net/projects/chemical-mime | chemical-mime-data</pre>
<p>So for these, the tarball name would become the project name and they would be
pretty ugly.</p>
<p>I am not quite sure what is the best approach for this.</p>
<p>What do you think?</p>