taskotron / task-upgradepath

#10 Depcheck fails to create per-update log
Closed: Fixed Opened by mkrizek.

Closed: Fixed
Reopen Issue

Depcheck (and possibly other checks) fails with:

IOError: [Errno 36] File name too long: u'/var/lib/taskotron/artifacts/ca8fdfc8-2c8f-11e5-9c7b-5254007dccf9/bomber-15.04.3-1.fc22,bovo-15.04.3-1.fc22,granatier-15.04.3-1.fc22,kajongg-15.04.3-1.fc22,kapman-15.04.3-1.fc22,katomic-15.04.3-1.fc22,kblackbox-15.04.3-1.fc22,kblocks-15.04.3-1.fc22,kbounce-15.04.3-1.fc22,kbrickbuster-15.04.3-1.fc22,kdiamond-15.04.3-1.fc22,kfourinline-15.04.3-1.fc22,kgoldrunner-15.04.3-1.fc22,kigo-15.04.3-1.fc22,killbots-15.04.3-1.fc22,kiriki-15.04.3-1.fc22,kjumpingcube-15.04.3-1.fc22,klickety-15.04.3-1.fc22,klines-15.04.3-1.fc22,kmahjongg-15.04.3-1.fc22,kmines-15.04.3-1.fc22,knavalbattle-15.04.3-1.fc22,knetwalk-15.04.3-1.fc22,kolf-15.04.3-1.fc22,kollision-15.04.3-1.fc22,konquest-15.04.3-1.fc22,kpat-15.04.3-1.fc22,kreversi-15.04.3-1.fc22,kshisen-14.12.3-3.fc22,ksirk-15.04.3-1.fc22,ksnakeduel-15.04.3-1.fc22,kspaceduel-15.04.3-1.fc22,ksquares-15.04.3-1.fc22,ksudoku-15.04.3-1.fc22,ktuberling-15.04.3-1.fc22,kubrick-15.04.3-1.fc22,libkdegames-15.04.3-1.fc22,libkmahjongg-14.12.3-2.fc22,lskat-15.04.3-1.fc22,palapeli-15.04.3-1.fc22,picmi-15.04.3-1.fc22.i386.log'

http://taskotron-dev.fedoraproject.org/taskmaster/builders/x86_64/builds/56863/steps/runtask/logs/taskotron.log

This ticket had assigned some Differential requests:
D458
D459
D457

The reason is that Linux allows only 255 characters for filenames on most filesystems. This will fail only for updates containing too many builds, before an update id is assigned. I'll provide a simple patch soon. I guess we should fix this before deploying artifacts to production.

I have looked at dev and the Bodhi update in question is now tested fine, and the logs are there:
http://taskotron-dev.fedoraproject.org/resultsdb/results/1689998
Metadata
None
None
None
None
Low
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.