Is there some issue with syncronizing the mirror?
On 8/19/21 9:13 AM, Andreas Tille wrote:
Is there some issue with syncronizing the mirror?
DSA disabled the UDD cronjob due to disk space usage, see:
https://lists.debian.org/debian-qa/2021/08/msg00000.html
See also: #992461
I just re-enabled the cronjobs handling the dumps, so that at least udd-mirror will keep updated.
On Thu, Aug 19, 2021 at 11:29:20AM +0200, Mattia Rizzolo wrote:
I just re-enabled the cronjobs handling the dumps, so that at least udd-mirror will keep updated.
Thanks a lot. That's very convenient since we relay on UDD to organise
the packages that need updates.
On Thu, Aug 19, 2021 at 03:04:22PM +0200, Andreas Tille wrote:
On Thu, Aug 19, 2021 at 11:29:20AM +0200, Mattia Rizzolo wrote:
I just re-enabled the cronjobs handling the dumps, so that at least udd-mirror will keep updated.
Thanks a lot. That's very convenient since we relay on UDD to organise
the packages that need updates.
Seems that upload_history in UDD itself is not updated:
Yes, that's included in the importers that are stopped for now.
I'm running the "upload-history" importer manually right now, so you
should see somethng appear soon, just for you :)
Thanks a lot. That's very convenient since we relay on UDD to organise the packages that need updates.
Seems that upload_history in UDD itself is not updated:
Yes, that's included in the importers that are stopped for now.
I'm running the "upload-history" importer manually right now, so you
should see somethng appear soon, just for you :)
Hi again,
On Sat, Aug 21, 2021 at 12:27:15PM +0200, Mattia Rizzolo wrote:
Thanks a lot. That's very convenient since we relay on UDD to organise the packages that need updates.
Seems that upload_history in UDD itself is not updated:
Yes, that's included in the importers that are stopped for now.
I'm running the "upload-history" importer manually right now, so you
should see somethng appear soon, just for you :)
I have no idea how much time the importer takes but I havn't seen any
change so far.
It takes 2-3 minutes. but when I mailed last time I had already run it
once, indeed this is the last record right now:
udd=> select source, version, date, distribution from upload_history order by date desc limit 1;
source | version | date | distribution ---------+---------+------------------------+--------------
tellico | 3.4.1-2 | 2021-08-21 10:03:46+00 | unstable
(1 row)
IOW, it looks "good" to me. I'm running it again now. however of
course it'll only pick the uploads until I run the command. Clearly
somebody needs to take out the time to look at what happened and re-cron
it all.
Hi guys,
Today I noticed an issue
$ LANG=C psql -P pager=off service=udd -c $'SELECT bapase.source as
"Source Name", bapase.upload_date as "Upload bapase",
upload_history.date as "Upload upload_history" FROM bapase JOIN
As I said, no dates in bapase. However, there is another problem here:
the last date for edb in upload_history is 2009-12-20 but 2013-07-03
in tracker.debian.org. The same for pal: 2011-12-13 in upload_history
and 2014-04-26 in tracker.
On Sun, Aug 22, 2021 at 05:43:19PM -0300, Eriberto Mota wrote:
Hi guys,
Today I noticed an issue
You reported true things, but I doubt this is in any way related to the current issue.
Are you saying these inconsistencies appeared just now? I'd suspect
those things have been broken for a decade already.
$ LANG=C psql -P pager=off service=udd -c $'SELECT bapase.source as
"Source Name", bapase.upload_date as "Upload bapase",
upload_history.date as "Upload upload_history" FROM bapase JOIN
Incidentally, I know nothing of bapase.
As I said, no dates in bapase. However, there is another problem here:
the last date for edb in upload_history is 2009-12-20 but 2013-07-03
in tracker.debian.org. The same for pal: 2011-12-13 in upload_history
and 2014-04-26 in tracker.
For these kind of bugs, remember that the upload_history is feeded via
the debian-devel-changes mails, parsed one by one. the implementation
of it has changed a couple of times over the many years (though it has
been the same for at least the last 7). So it's realistic to think that
a few uploads might be missing here and there.
Indeed, the upload_history implementation is fragile (or more correctly:
its data source is fragile). There are a few uploads whose emails to debian-devel-changes could not be parsed for some reason.
You can get the list of packages currently in unstable with no
corresponding upload in upload_history:
udd=> select s.source, s.version from sources s left join upload_history uh using (source, version) where s.release='sid' and uh.version is null order by source asc;
source | version ------------------------------+-----------------------------
binutils-z80 | 4
dvhtool | 1.0.1-5
edb | 1.31-3
kerneltop | 0.91-2
libmime-explode-perl | 0.39-3
libnet-jabber-loudmouth-perl | 0.07-3
libparse-exuberantctags-perl | 1.02-1
libsgml-parser-opensp-perl | 0.994-3
libshairport | 1.2.1~git20120510.cbed0c1-3
libsocket-linux-perl | 0.01-2
libtext-levenshteinxs-perl | 0.03-4
libxml-grddl-perl | 0.004-2
pal | 0.4.3-8.1
scheme2c | 2012.10.14-1
vowpal-wabbit | 7.3-1.1
(15 rows)
Lucas
Em seg., 23 de ago. de 2021 às 15:53, Lucas Nussbaum
<lucas@debian.org> escreveu:
Indeed, the upload_history implementation is fragile (or more correctly: its data source is fragile). There are a few uploads whose emails to debian-devel-changes could not be parsed for some reason.
You can get the list of packages currently in unstable with no corresponding upload in upload_history:
udd=> select s.source, s.version from sources s left join upload_history uh using (source, version) where s.release='sid' and uh.version is null order by source asc;
source | version ------------------------------+-----------------------------
binutils-z80 | 4
dvhtool | 1.0.1-5
edb | 1.31-3
kerneltop | 0.91-2
libmime-explode-perl | 0.39-3
libnet-jabber-loudmouth-perl | 0.07-3
libparse-exuberantctags-perl | 1.02-1
libsgml-parser-opensp-perl | 0.994-3
libshairport | 1.2.1~git20120510.cbed0c1-3
libsocket-linux-perl | 0.01-2
libtext-levenshteinxs-perl | 0.03-4
libxml-grddl-perl | 0.004-2
pal | 0.4.3-8.1
scheme2c | 2012.10.14-1
vowpal-wabbit | 7.3-1.1
(15 rows)
Lucas
Is possible/viable to insert the dates manually? I think it can fix
this inconsistency.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 70:56:42 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,625 |