fedorahosted.org is being taken down, so we need to update all SRC_URIs to point at either our own mirrors or the new upstream. meta/lib/oeqa/selftest/recipetool.py: checkvars['SRC_URI'] = 'https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.gz' meta/recipes-devtools/xmlto/xmlto_0.0.28.bb:SRC_URI = "https://fedorahosted.org/releases/x/m/xmlto/xmlto-${PV}.tar.gz \ meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb:SRC_URI = "http://fedorahosted.org/releases/c/h/chkconfig/${BPN}-${PV}.tar.bz2 \ meta/recipes-extended/cronie/cronie_1.5.1.bb:SRC_URI = "https://fedorahosted.org/releases/c/r/cronie/cronie-${PV}.tar.gz \ meta/recipes-extended/libuser/libuser_0.62.bb:SRC_URI = "https://fedorahosted.org/releases/l/i/libuser/libuser-${PV}.tar.xz \ meta/recipes-extended/logrotate/logrotate_3.9.1.bb:SRC_URI = "https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.gz meta/recipes-extended/newt/libnewt_0.52.19.bb:SRC_URI = "https://fedorahosted.org/releases/n/e/newt/newt-${PV}.tar.gz \ meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb:SRC_URI = "https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-${PV}.tar.gz
https://fedoraproject.org/wiki/Infrastructure/Fedorahosted-retirement has the context. Hopefully many projects are maintained and have moved, otherwise the unmaintained ones we should review in the 2.4 cycle to see if they can be removed.
Hi Ross, I will be working on this issue as a ramp up. There are many upstream sources (DEBIAN MIRROR, GNU MIRROR, YP MIRROR, etc). How do choose the SRC_URI for the recipes? Can you share some BKM?
Hi Ross, I find out some of the source thru filewatcher. Is it applicable to use in this fix? meta/lib/oeqa/selftest/recipetool.py: checkvars['SRC_URI'] = 'https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.gz' ftp://ftp.za.freebsd.org/slackware/slackware-13.0/source/a/logrotate/logrotate-3.7.4.tar.gz meta/recipes-devtools/xmlto/xmlto_0.0.28.bb:SRC_URI = "https://fedorahosted.org/releases/x/m/xmlto/xmlto-${PV}.tar.gz \ ftp://ftp.debian.com/debian/pool/main/x/xmlto/xmlto_0.0.28-0.1.debian.tar.xz meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb:SRC_URI = "http://fedorahosted.org/releases/c/h/chkconfig/${BPN}-${PV}.tar.bz2 \ ftp://mirrors.kernel.org/yocto/yocto/yocto-1.2/sources/chkconfig-1.3.58.tar.bz2 meta/recipes-extended/cronie/cronie_1.5.1.bb:SRC_URI = "https://fedorahosted.org/releases/c/r/cronie/cronie-${PV}.tar.gz \ ftp://ftp.ru.debian.org/gentoo-distfiles/distfiles/cronie-1.5.0.tar.gz meta/recipes-extended/libuser/libuser_0.62.bb:SRC_URI = "https://fedorahosted.org/releases/l/i/libuser/libuser-${PV}.tar.xz \ ftp://ftp.gnome.org/mirror/parrotsec.org/parrot/pool/main/libu/libuser/libuser_0.62~dfsg-0.1.debian.tar.xz meta/recipes-extended/logrotate/logrotate_3.9.1.bb:SRC_URI = "https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.gz ftp://ftp.us.horde.org/pub/linux/gentoo/distro/distfiles/logrotate-3.9.1.tar.gz meta/recipes-extended/newt/libnewt_0.52.19.bb:SRC_URI = "https://fedorahosted.org/releases/n/e/newt/newt-${PV}.tar.gz \ ftp://ftp.uk.freesbie.org/sites/distfiles.macports.org/libnewt/newt-0.52.19.tar.gz meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb:SRC_URI = "https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-${PV}.tar.gz ftp://mirrors.kernel.org/yocto/yocto/yocto-1.2/sources/liberation-fonts-1.04.tar.gz
Falling back to a mirror maintained by another distro is the worst case situation, especially if it's an arbitrary mirror of a mirror. As fedorahosted.org says, anything that is still maintained by Red Hat is likely to be on pagure.io. If we need to take an archive from e.g Debian then the BKM is to point at snapshot.debian.org. A bit of googling tells me that the new canonical locations for a few projects are: liberation-fonts: https://pagure.io/liberation-fonts logrotate: https://github.com/logrotate/logrotate newt: https://pagure.io/newt xmlto was on fedorahosted, but even the fedora packaging for it (http://pkgs.fedoraproject.org/cgit/rpms/xmlto.git/tree/xmlto.spec) still points there so presumably they haven't noticed yet either. For this we can use snapshot.debian.org, search for xmlto and you'll get the link http://snapshot.debian.org/archive/debian/20151121T033923Z/pool/main/x/xmlto/xmlto_0.0.28.orig.tar.bz2. The first step now is to verify that if you just change the SRC_URI and do eg 'bitbake xmlto -ccleanall ; bitbake xmlto' it re-downloads the tarball without checksum warnings, which verifies that the tarball is the same one we were expecting. Once 2.3 is released we can then look at further upgrades, I noticed that there have been some logrotate releases we haven't got.
Thanks Ross. I have a quick fix for xmlto on my github repo. https://github.com/rebeccasf/poky-dev/commit/f2cdc2da472b8724aa69fe3240e0ffecd0b32e20 My question: I found xmlto, libuser, libnewt and liberation-fonts tarball were archived in pagure.io. I having a dilemma on what is the most preferred way of committing the changes to OE-Core? Is it good to lump 4 recipes changes into single commit as they are similar: updating SRC_URI to pagure.io.? Or it is better to create 4 different commits?
As it's not a huge number of recipes, patch-per-recipe is easy to test and review.
(In reply to comment #4) > The first step now is to verify that if you just change the SRC_URI and do > eg 'bitbake xmlto -ccleanall ; bitbake xmlto' it re-downloads the tarball > without checksum warnings, which verifies that the tarball is the same one > we were expecting. One more check that would be nice to do (but can wait until the actual SRC_URIs are fixed): make sure that our automatic version checking still work after these changes. You'll need this in your local.conf to be able to run the check: INHERIT += "distrodata" Now this will do the check for xmlto: bitbake -c checkpkg xmlto It won't print anything: you'll have to look in $TMPDIR/log/ for the results (checkpkg.csv is always the last one). You should see a version number in UpVer column that shows the last upstream release. If you don't, we should fix that... Fixing the checks can wait after the SRC_URI fixes but please at least make a comment here in the bug if you find broken upstream version checks.
(In reply to comment #7) > You'll need this in your local.conf to be able to run the check: > INHERIT += "distrodata" > > Now this will do the check for xmlto: > bitbake -c checkpkg xmlto > It won't print anything: you'll have to look in $TMPDIR/log/ for the results > (checkpkg.csv is always the last one). > > You should see a version number in UpVer column that shows the last upstream > release. If you don't, we should fix that... Fixing the checks can wait > after the SRC_URI fixes but please at least make a comment here in the bug > if you find broken upstream version checks. Thanks! To help me understand more, I have tried the settings and checked checkpkg.csv Package Version Upver ... libnewt 0.52.19 0.52.20 ... It shows that there is an latest upstream version, so the follow-up work should update the version? If the UpVer is the same as my current version, it just means that we already getting latest and greatest, right?
(In reply to comment #8) > Thanks! To help me understand more, I have tried the settings and checked > checkpkg.csv > > Package Version Upver ... > libnewt 0.52.19 0.52.20 ... > > It shows that there is an latest upstream version, so the follow-up work > should update the version? If the UpVer is the same as my current version, > it just means that we already getting latest and greatest, right? The output tells us that the upstream check is working: it's figured out what the upstream version is (otherwise it would say "N/A" or something like that). So that's all good. You are correct that it also tells us that we are one patch version behind upstream. This should be fixed but only after the Pyro (2.3) release -- we don't do version upgrades at this point of the release unless there's a special reason.
(In reply to comment #9) > (In reply to comment #8) > > Thanks! To help me understand more, I have tried the settings and checked > > checkpkg.csv > > > > Package Version Upver ... > > libnewt 0.52.19 0.52.20 ... > > > > It shows that there is an latest upstream version, so the follow-up work > > should update the version? If the UpVer is the same as my current version, > > it just means that we already getting latest and greatest, right? > > The output tells us that the upstream check is working: it's figured out > what the upstream version is (otherwise it would say "N/A" or something like > that). So that's all good. > > You are correct that it also tells us that we are one patch version behind > upstream. This should be fixed but only after the Pyro (2.3) release -- we > don't do version upgrades at this point of the release unless there's a > special reason. just to take note. We updated all the SRC_URI. When checkpkg we find out cronie package having "N/A" on the UpVer volume. This package actually having more latest version in github.
(In reply to comment #10) > just to take note. > We updated all the SRC_URI. When checkpkg we find out cronie package having > "N/A" on the UpVer volume. This package actually having more latest version > in github. Try setting UPSTREAM_CHECK_URI to a url for a page that lists the releases. You should find other recipes doing that for github projects.